docker
/
docs
mirror of https://github.com/docker/docs.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

merge conflict fixes

This commit is contained in:
John Mulhausen 2016-11-18 18:58:26 -08:00
parent 9bdefe1f07 2ede6ff7f0
commit 0060ef460a
163 changed files with 23361 additions and 42778 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

26
Dockerfile
View File

@ -1,8 +1,26 @@
FROM starefossen/github-pages
# Basic Git set-up for throwaway commits
RUN git config --global user.email "gordon@docker.com"
RUN git config --global user.name "Gordon"
# Clone the docs repo
RUN git clone https://www.github.com/docker/docker.github.io allv
# Get docker/docker ref docs from 1.12.x branch to be used in master builds
# Uses Github Subversion gateway to limit the checkout
RUN svn co https://github.com/docker/docker/branches/1.12.x/docs/reference allv/engine/reference
RUN svn co https://github.com/docker/docker/branches/1.12.x/docs/extend allv/engine/extend
# Can't use the svn trick to get a single file, use wget instead
RUN wget -O allv/engine/deprecated.md https://raw.githubusercontent.com/docker/docker/1.12.x/docs/deprecated.md
# Make a temporary commit for the files we added so we can check out other branches later
RUN git --git-dir=./allv/.git --work-tree=./allv add engine
RUN git --git-dir=./allv/.git --work-tree=./allv commit -m "Temporary commit"
# Create HTML for master
RUN jekyll build -s allv -d allvbuild
# Check out 1.4 branch, create HTML, tweak links
RUN git --git-dir=./allv/.git --work-tree=./allv checkout v1.4
RUN mkdir allvbuild/v1.4
RUN jekyll build -s allv -d allvbuild/v1.4
@ -10,6 +28,7 @@ RUN find allvbuild/v1.4 -type f -name '*.html' -print0 | xargs -0 sed -i 's#href
RUN find allvbuild/v1.4 -type f -name '*.html' -print0 | xargs -0 sed -i 's#src="/#src="/v1.4/#g'
RUN find allvbuild/v1.4 -type f -name '*.html' -print0 | xargs -0 sed -i 's#href="https://docs.docker.com/#href="/v1.4/#g'
# Check out 1.5 branch, create HTML, tweak links
RUN git --git-dir=./allv/.git --work-tree=./allv checkout v1.5
RUN mkdir allvbuild/v1.5
RUN jekyll build -s allv -d allvbuild/v1.5
@ -17,6 +36,7 @@ RUN find allvbuild/v1.5 -type f -name '*.html' -print0 | xargs -0 sed -i 's#href
RUN find allvbuild/v1.5 -type f -name '*.html' -print0 | xargs -0 sed -i 's#src="/#src="/v1.5/#g'
RUN find allvbuild/v1.5 -type f -name '*.html' -print0 | xargs -0 sed -i 's#href="https://docs.docker.com/#href="/v1.5/#g'
# Check out 1.6, create HTML, tweak links
RUN git --git-dir=./allv/.git --work-tree=./allv checkout v1.6
RUN mkdir allvbuild/v1.6
RUN jekyll build -s allv -d allvbuild/v1.6
@ -24,6 +44,7 @@ RUN find allvbuild/v1.6 -type f -name '*.html' -print0 | xargs -0 sed -i 's#href
RUN find allvbuild/v1.6 -type f -name '*.html' -print0 | xargs -0 sed -i 's#src="/#src="/v1.6/#g'
RUN find allvbuild/v1.6 -type f -name '*.html' -print0 | xargs -0 sed -i 's#href="https://docs.docker.com/#href="/v1.6/#g'
# Check out 1.7, create HTML, tweak links
RUN git --git-dir=./allv/.git --work-tree=./allv checkout v1.7
RUN mkdir allvbuild/v1.7
RUN jekyll build -s allv -d allvbuild/v1.7
@ -31,6 +52,7 @@ RUN find allvbuild/v1.7 -type f -name '*.html' -print0 | xargs -0 sed -i 's#href
RUN find allvbuild/v1.7 -type f -name '*.html' -print0 | xargs -0 sed -i 's#src="/#src="/v1.7/#g'
RUN find allvbuild/v1.7 -type f -name '*.html' -print0 | xargs -0 sed -i 's#href="https://docs.docker.com/#href="/v1.7/#g'
# Check out 1.8, create HTML, tweak links
RUN git --git-dir=./allv/.git --work-tree=./allv checkout v1.8
RUN mkdir allvbuild/v1.8
RUN jekyll build -s allv -d allvbuild/v1.8
@ -38,6 +60,7 @@ RUN find allvbuild/v1.8 -type f -name '*.html' -print0 | xargs -0 sed -i 's#href
RUN find allvbuild/v1.8 -type f -name '*.html' -print0 | xargs -0 sed -i 's#src="/#src="/v1.8/#g'
RUN find allvbuild/v1.8 -type f -name '*.html' -print0 | xargs -0 sed -i 's#href="https://docs.docker.com/#href="/v1.8/#g'
# Check out 1.9, create HTML, tweak links
RUN git --git-dir=./allv/.git --work-tree=./allv checkout v1.9
RUN mkdir allvbuild/v1.9
RUN jekyll build -s allv -d allvbuild/v1.9
@ -45,6 +68,7 @@ RUN find allvbuild/v1.9 -type f -name '*.html' -print0 | xargs -0 sed -i 's#href
RUN find allvbuild/v1.9 -type f -name '*.html' -print0 | xargs -0 sed -i 's#src="/#src="/v1.9/#g'
RUN find allvbuild/v1.9 -type f -name '*.html' -print0 | xargs -0 sed -i 's#href="https://docs.docker.com/#href="/v1.9/#g'
# Check out 1.10, create HTML, tweak links
RUN git --git-dir=./allv/.git --work-tree=./allv checkout v1.10
RUN mkdir allvbuild/v1.10
RUN jekyll build -s allv -d allvbuild/v1.10
@ -52,6 +76,7 @@ RUN find allvbuild/v1.10 -type f -name '*.html' -print0 | xargs -0 sed -i 's#hre
RUN find allvbuild/v1.10 -type f -name '*.html' -print0 | xargs -0 sed -i 's#src="/#src="/v1.10/#g'
RUN find allvbuild/v1.10 -type f -name '*.html' -print0 | xargs -0 sed -i 's#href="https://docs.docker.com/#href="/v1.10/#g'
# Check out 1.11, create HTML, tweak links
RUN git --git-dir=./allv/.git --work-tree=./allv checkout v1.11
RUN mkdir allvbuild/v1.11
RUN jekyll build -s allv -d allvbuild/v1.11
@ -59,4 +84,5 @@ RUN find allvbuild/v1.11 -type f -name '*.html' -print0 | xargs -0 sed -i 's#hre
RUN find allvbuild/v1.11 -type f -name '*.html' -print0 | xargs -0 sed -i 's#src="/#src="/v1.11/#g'
RUN find allvbuild/v1.11 -type f -name '*.html' -print0 | xargs -0 sed -i 's#href="https://docs.docker.com/#href="/v1.11/#g'
# Serve the site, which is now all static HTML
CMD jekyll serve -s /usr/src/app/allvbuild -d /_site --no-watch -H 0.0.0.0 -P 4000

8
_data/toc.yaml
View File

@ -1,6 +1,10 @@
toc:
- title: Welcome to the Docs
path: /
- sectiontitle: Docker ID
section:
- path: /docker-id/
title: Docker ID accounts
- sectiontitle: Docker Engine
section:
- sectiontitle: Install
@ -205,6 +209,8 @@ toc:
title: Apply rolling updates
- path: /engine/swarm/swarm-tutorial/drain-node/
title: Drain a node
- path: /engine/swarm/ingress/
title: Use swarm mode routing mesh
- sectiontitle: How swarm mode works
section:
- path: /engine/swarm/how-swarm-mode-works/nodes/
@ -769,6 +775,8 @@ toc:
title: Use your own certificates
- path: /datacenter/dtr/2.1/guides/configure/configure-storage/
title: Storage configuration
- path: /datacenter/dtr/2.1/guides/configure/use-nfs/
title: Use NFS
- sectiontitle: Monitor and troubleshoot
section:
- path: /datacenter/dtr/2.1/guides/monitor-troubleshoot/

6
_layouts/docs.html
View File

@ -210,9 +210,9 @@ ng\:form {
{% if page.noratings != true %}
<div style="text-align: center; margin-top: 50px">
<img src="/images/chat.png" alt="chat icon" style="margin-right: 10px">
<b>Feedback?</b> Questions? Suggestions?<br/>
<a href="{{ editsource }}" class="nomunge">Edit this page</a>,
<a href="https://github.com/docker/docker.github.io/issues/new?title=Feedback for: {{ page.path }}&assignee={% if page.assignee %}{{ page.assignee }}{% else %}{{ page.defaultassignee }}{% endif %}&body=File: [{{ page.path }}](https://docs.docker.com{{ page.url }})" class="nomunge">file a ticket</a>, or rate this page:
<b>Feedback?</b> Suggestions? Can't find something in the docs?<br/>
<a href="https://github.com/docker/docker.github.io/edit/master/{{ page.path }}" class="nomunge">Edit this page</a> <span style="color:#D8E0E0">&#9679;</span>
<a href="https://github.com/docker/docker.github.io/issues/new?title=Feedback for: {{ page.path }}&assignee={% if page.assignee %}{{ page.assignee }}{% else %}{{ page.defaultassignee }}{% endif %}&body=File: [{{ page.path }}](https://docs.docker.com{{ page.url }})" class="nomunge">Request docs changes</a> <span style="color:#D8E0E0">&#9679;</span> <a href="https://www.docker.com/docker-support-services">Get support</a> <br />Rate this page:
<div id="pd_rating_holder_8453675"></div>
<script type="text/javascript">
PDRTJS_settings_8453675 = {

9
apidocs/cloud-api-source/source/includes/container.md
View File

@ -364,15 +364,6 @@ bridge | Creates a new network stack for the container on the docker bridge.
host | Uses the host network stack inside the container.
### Container Last Metric attributes
Attribute | Description
--------- | -----------
cpu | CPU percentage usage
memory | Memory usage in bytes
disk | Disk storage usage in bytes
### Container Link attributes
Attribute | Description

8
apidocs/cloud-api-source/source/includes/node.md
View File

@ -77,14 +77,6 @@ Upgrading | The node docker daemon is being upgraded. No actions allowed in this
Terminating | The node is being terminated in the cloud provider. No actions allowed in this state.
Terminated | The node has been terminated and is no longer present in the cloud provider. No actions allowed in this state.
### Node Last Metric attributes
Attribute | Description
--------- | -----------
cpu | CPU percentage usage
memory | Memory usage in bytes
disk | Disk storage usage in bytes
## List all nodes

22
apidocs/docker-cloud/includes/container.html
View File

@ -630,28 +630,6 @@
</tr>
</tbody></table>
<h3 id="container-last-metric-attributes">Container Last Metric attributes</h3>
<table><thead>
<tr>
<th>Attribute</th>
<th>Description</th>
</tr>
</thead><tbody>
<tr>
<td>cpu</td>
<td>CPU percentage usage</td>
</tr>
<tr>
<td>memory</td>
<td>Memory usage in bytes</td>
</tr>
<tr>
<td>disk</td>
<td>Disk storage usage in bytes</td>
</tr>
</tbody></table>
<h3 id="container-link-attributes">Container Link attributes</h3>
<table><thead>

22
apidocs/docker-cloud/includes/node.html
View File

@ -200,28 +200,6 @@
</tr>
</tbody></table>
<h3 id="node-last-metric-attributes">Node Last Metric attributes</h3>
<table><thead>
<tr>
<th>Attribute</th>
<th>Description</th>
</tr>
</thead><tbody>
<tr>
<td>cpu</td>
<td>CPU percentage usage</td>
</tr>
<tr>
<td>memory</td>
<td>Memory usage in bytes</td>
</tr>
<tr>
<td>disk</td>
<td>Disk storage usage in bytes</td>
</tr>
</tbody></table>
<h2 id="list-all-nodes">List all nodes</h2>
<pre class="highlight python"><code><span class="kn">import</span> <span class="nn">dockercloud</span>

44
apidocs/docker-cloud/index.html
View File

@ -1983,28 +1983,6 @@ docker-cloud tag <span class="nb">set</span> -t tag-2 7eaf7fff
</tr>
</tbody></table>
<h3 id="node-last-metric-attributes">Node Last Metric attributes</h3>
<table><thead>
<tr>
<th>Attribute</th>
<th>Description</th>
</tr>
</thead><tbody>
<tr>
<td>cpu</td>
<td>CPU percentage usage</td>
</tr>
<tr>
<td>memory</td>
<td>Memory usage in bytes</td>
</tr>
<tr>
<td>disk</td>
<td>Disk storage usage in bytes</td>
</tr>
</tbody></table>
<h2 id="list-all-nodes">List all nodes</h2>
<pre class="highlight python"><code><span class="kn">import</span> <span class="nn">dockercloud</span>
@ -5438,28 +5416,6 @@ docker-cloud tag <span class="nb">set</span> -t tag-2 7eaf7fff
</tr>
</tbody></table>
<h3 id="container-last-metric-attributes">Container Last Metric attributes</h3>
<table><thead>
<tr>
<th>Attribute</th>
<th>Description</th>
</tr>
</thead><tbody>
<tr>
<td>cpu</td>
<td>CPU percentage usage</td>
</tr>
<tr>
<td>memory</td>
<td>Memory usage in bytes</td>
</tr>
<tr>
<td>disk</td>
<td>Disk storage usage in bytes</td>
</tr>
</tbody></table>
<h3 id="container-link-attributes">Container Link attributes</h3>
<table><thead>

44
apidocs/layouts/single.html
View File

@ -1983,28 +1983,6 @@ docker-cloud tag <span class="nb">set</span> -t tag-2 7eaf7fff
</tr>
</tbody></table>
<h3 id="node-last-metric-attributes">Node Last Metric attributes</h3>
<table><thead>
<tr>
<th>Attribute</th>
<th>Description</th>
</tr>
</thead><tbody>
<tr>
<td>cpu</td>
<td>CPU percentage usage</td>
</tr>
<tr>
<td>memory</td>
<td>Memory usage in bytes</td>
</tr>
<tr>
<td>disk</td>
<td>Disk storage usage in bytes</td>
</tr>
</tbody></table>
<h2 id="list-all-nodes">List all nodes</h2>
<pre class="highlight python"><code><span class="kn">import</span> <span class="nn">dockercloud</span>
@ -5438,28 +5416,6 @@ docker-cloud tag <span class="nb">set</span> -t tag-2 7eaf7fff
</tr>
</tbody></table>
<h3 id="container-last-metric-attributes">Container Last Metric attributes</h3>
<table><thead>
<tr>
<th>Attribute</th>
<th>Description</th>
</tr>
</thead><tbody>
<tr>
<td>cpu</td>
<td>CPU percentage usage</td>
</tr>
<tr>
<td>memory</td>
<td>Memory usage in bytes</td>
</tr>
<tr>
<td>disk</td>
<td>Disk storage usage in bytes</td>
</tr>
</tbody></table>
<h3 id="container-link-attributes">Container Link attributes</h3>
<table><thead>

4
compose/compose-file.md
View File

@ -12,6 +12,8 @@ The Compose file is a [YAML](http://yaml.org/) file defining
[volumes](compose-file.md#volume-configuration-reference).
The default path for a Compose file is `./docker-compose.yml`.
>**Tip:** You can use either a `.yml` or `.yaml` extension for this file. They both work.
A service definition contains configuration which will be applied to each
container started for that service, much like passing command-line parameters to
`docker run`. Likewise, network and volume definitions are analogous to
@ -1309,4 +1311,4 @@ If you forget and use a single dollar sign (`$`), Compose interprets the value a
- [Get started with Django](django.md)
- [Get started with Rails](rails.md)
- [Get started with WordPress](wordpress.md)
- [Command line reference](./reference/index.md)
- [Command line reference](./reference/index.md)

4
compose/django.md
View File

@ -10,7 +10,7 @@ This quick-start guide demonstrates how to use Docker Compose to set up and run
### Define the project components
For this project, you need to create a Dockerfile, a Python dependencies file,
and a `docker-compose.yml` file.
and a `docker-compose.yml` file. (You can use either a `.yml` or `.yaml` extension for this file.)
1. Create an empty project directory.
@ -183,4 +183,4 @@ In this section, you set up the database connection for Django.
- [Get started with Rails](rails.md)
- [Get started with WordPress](wordpress.md)
- [Command line reference](./reference/index.md)
- [Compose file reference](compose-file.md)
- [Compose file reference](compose-file.md)

5
compose/rails.md
View File

@ -56,6 +56,9 @@ to link them together and expose the web app's port.
depends_on:
- db
>**Tip:** You can use either a `.yml` or `.yaml` extension for this file.
### Build the project
With those three files in place, you can now generate the Rails skeleton app
@ -163,4 +166,4 @@ up`.
- [Get started with Django](django.md)
- [Get started with WordPress](wordpress.md)
- [Command line reference](./reference/index.md)
- [Compose file reference](compose-file.md)
- [Compose file reference](compose-file.md)

4
compose/reference/overview.md
View File

@ -10,7 +10,7 @@ This page provides the usage information for the `docker-compose` Command.
You can also see this information by running `docker-compose --help` from the
command line.
```
```none
Define and run multi-container applications with Docker.
Usage:
@ -117,4 +117,4 @@ envvars.md#compose-project-name)
## Where to go next
* [CLI environment variables](envvars.md)
* [CLI environment variables](envvars.md)

37
compose/wordpress.md
View File

@ -4,8 +4,9 @@ keywords: documentation, docs, docker, compose, orchestration, containers
title: "Quickstart: Compose and WordPress"
---
You can use Docker Compose to easily run WordPress in an isolated environment built
with Docker containers. This quick-start guide demonstrates how to use Compose to set up and run WordPress. Before starting, you'll need to have
You can use Docker Compose to easily run WordPress in an isolated environment
built with Docker containers. This quick-start guide demonstrates how to use
Compose to set up and run WordPress. Before starting, you'll need to have
[Compose installed](install.md).
### Define the project
@ -14,7 +15,10 @@ with Docker containers. This quick-start guide demonstrates how to use Compose t
You can name the directory something easy for you to remember. This directory is the context for your application image. The directory should only contain resources to build that image.
This project directory will contain a `docker-compose.yaml` file which will be complete in itself for a good starter wordpress project.
This project directory will contain a `docker-compose.yml` file which will
be complete in itself for a good starter wordpress project.
>**Tip:** You can use either a `.yml` or `.yaml` extension for this file. They both work.
2. Change directories into your project directory.
@ -23,7 +27,7 @@ with Docker containers. This quick-start guide demonstrates how to use Compose t
cd my_wordpress/
3. Create a `docker-compose.yml` file that will start your
`Wordpress` blog and a separate `MySQL` instance with a volume
`WordPress` blog and a separate `MySQL` instance with a volume
mount for data persistence:
```none
@ -33,7 +37,7 @@ with Docker containers. This quick-start guide demonstrates how to use Compose t
db:
image: mysql:5.7
volumes:
- "./.data/db:/var/lib/mysql"
- db_data:/var/lib/mysql
restart: always
environment:
MYSQL_ROOT_PASSWORD: wordpress
@ -45,19 +49,17 @@ with Docker containers. This quick-start guide demonstrates how to use Compose t
depends_on:
- db
image: wordpress:latest
links:
- db
ports:
- "8000:80"
restart: always
environment:
WORDPRESS_DB_HOST: db:3306
WORDPRESS_DB_PASSWORD: wordpress
volumes:
db_data:
```
**NOTE**: The folder `./.data/db` will be automatically created in the project directory
alongside the `docker-compose.yml` which will persist any updates made by wordpress to the
database.
**NOTE**: The docker volume `db_data` will persist any updates made by wordpress to the database. [Learn more about docker volumes](../engine/tutorials/dockervolumes.md)
### Build the project
@ -89,14 +91,23 @@ This pulls the needed images, and starts the wordpress and database containers,
If you're using [Docker Machine](/machine/), then `docker-machine ip MACHINE_VM` gives you the machine address and you can open `http://MACHINE_VM_IP:8000` in a browser.
At this point, WordPress should be running on port `8000` of your Docker Host, and you can complete the "famous five-minute installation" as a WordPress administrator.
At this point, WordPress should be running on port `8000` of your Docker Host,
and you can complete the "famous five-minute installation" as a WordPress
administrator.
**NOTE**: The Wordpress site will not be immediately available on port `8000` because the containers are still being initialized and may take a couple of minutes before the first load.
**NOTE**: The WordPress site will not be immediately available on port `8000`
because the containers are still being initialized and may take a couple of
minutes before the first load.
![Choose language for WordPress install](images/wordpress-lang.png)
![WordPress Welcome](images/wordpress-welcome.png)
### Shutdown/Clean up
`docker-compose down` will remove the containers and default network, but
preserve your wordpress database. `docker-compose down --volumes` will remove
the containers, default network, and the wordpress database.
## More Compose documentation
- [User guide](index.md)
@ -105,4 +116,4 @@ At this point, WordPress should be running on port `8000` of your Docker Host, a
- [Get started with Django](django.md)
- [Get started with Rails](rails.md)
- [Command line reference](./reference/index.md)
- [Compose file reference](compose-file.md)
- [Compose file reference](compose-file.md)

22994
css/allcss.css
View File

File diff suppressed because one or more lines are too long

71
datacenter/dtr/2.1/guides/configure/use-nfs.md Normal file
View File

@ -0,0 +1,71 @@
---
title: Use NFS
description: Learn how to integrate Docker Trusted Registry with NFS
keywords: registry, dtr, storage, nfs
---
You can configure DTR to store Docker images in an NFS directory.
Before installing or configuring DTR to use an NFS directory, make sure that:
* The NFS server has been correctly configured
* The NFS server has a fixed IP address
* All hosts running DTR have the correct NFS libraries installed
To confirm that the hosts can connect to the NFS server, try to list the
directories exported by your NFS server:
```bash
showmount -e <nfsserver>
```
You should also try yo mount one of the exported directories:
```bash
mkdir /tmp/mydir && sudo mount -t nfs <nfs server>:<directory>
```
## Install DTR with NFS
One way to configure DTR to use an NFS directory is at install time:
```none
docker run -it --rm docker/dtr install \
--nfs-storage-url <nfs-storage-url> \
<other options>
```
The NFS storage URL should be in the format `nfs://<nfs server>/<directory>`.
When you join replicas to the DTR cluster, the replicas will pick up that
configuration, so you don't need to specify it again.
### Reconfigure DTR to use NFS
If you're upgrading from a previous version of DTR and are already using
NFS you can continue using the same configurations.
If you want to start using the new DTR built-in support for NFS you can
reconfigure DTR:
```none
docker run -it --rm docker/dtr reconfigure \
--nfs-storage-url <nfs-storage-url>
```
If you want to reconfigure DTR to stop using NFS storage, leave the option
in blank:
```none
docker run -it --rm docker/dtr reconfigure \
--nfs-storage-url ""
```
If the IP address of your NFS server changes, even if the DNS address is kept
the same, you should reconfigure DTR to stop using NFS storage, and then
add it back again.
## Where to go next
* [Configure where images are stored](configure-storage.md)

BIN
datacenter/dtr/2.1/guides/images/install-dtr-0.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 43 KiB

12
datacenter/dtr/2.1/guides/install/index.md
View File

@ -22,7 +22,11 @@ Since DTR requires Docker Universal Control Plane (UCP)
to run, you need to install UCP on all the nodes where you plan to install DTR.
[Learn how to install UCP](/datacenter/ucp/2.0/guides/installation/index.md).
Make sure all the nodes you plan on installing DTR are being managed by UCP.
DTR needs to be installed on a worker node that is being managed by UCP.
You can't install DTR on a standalone Docker Engine.
![](../images/install-dtr-0.png)
## Step 3. Install DTR
@ -68,14 +72,14 @@ browser, navigate to the address were you installed DTR.
After installing DTR, you should configure:
* The Domain Name used to access DTR,
* The certificates used for TLS communication,
* The storage backend to store the Docker images.
* The certificates used for TLS communication. [Learn more](../configure/configure-storage.md).
* The storage backend to store the Docker images. [Lean more](../configure/index.md).
To perform these configurations, navigate to the **Settings** page of DTR.
![](../images/install-dtr-3.png)
## Step 6. Test pushing and pulling
Now that you have a working installation of DTR, you should test that you can

8
datacenter/dtr/2.1/guides/release-notes.md
View File

@ -14,7 +14,7 @@ known issues for each DTR version.
You can then use [the upgrade instructions](install/upgrade.md),
to upgrade your installation to the latest release.
## DTR 2.1
## DTR 2.1.0
(10 Nov 2016)
@ -55,3 +55,9 @@ configuring where Docker images are stored
* Better integration with Filesystem storage driver to store Docker images
* Improved garbage collection performance and efficiency
* Improved health checking API for more granularity
**Known issues**
* When upgrading to this version, tag metadata is migrated to DTR's internal
database. Depending on how many images are stored in DTR this can take some
time to complete.

2
datacenter/ucp/1.1/install-sandbox.md
View File

@ -53,7 +53,7 @@ the correct ones for you environment. -->
>**Note**: The command examples in this page were tested for a macOS environment.
If you are in another, you may need to adjust to use analogous commands for your environment.
## Step 2. Verify the prerequisites
## Verify the prerequisites
This example requires that you have:

2
datacenter/ucp/1.1/installation/install-offline.md
View File

@ -22,7 +22,7 @@ all the images. Then you copy that package to the host where you’ll install UC
Docker Datacenter components:
```none
$ wget https://packages.docker.com/caas/ucp-1.1.3_dtr-2.0.3.tar.gz -O docker-datacenter.tar.gz
$ wget https://packages.docker.com/caas/ucp-1.1.4_dtr-2.0.4.tar.gz -O docker-datacenter.tar.gz
```
2. Transfer the package to the offline node.

10
datacenter/ucp/2.0/guides/high-availability/backups-and-disaster-recovery.md
View File

@ -46,15 +46,6 @@ $ docker run --rm -i --name ucp \
# Decrypt the backup and list its contents
$ gpg --decrypt /tmp/backup.tar | tar --list
Enter passphrase: secret
/ucp-client-root-ca/
./ucp-client-root-ca/cert.pem
./ucp-client-root-ca/config.json
./ucp-client-root-ca/key.pem
./ucp-cluster-root-ca/
# output snipped
```
## Restore command
@ -82,6 +73,7 @@ $ docker run --rm -i --name ucp \
The restore command can be used to create a new UCP cluster from a backup file.
After the restore operation is complete, the following data will be copied from
the backup file:
* Users, Teams and Permissions.
* Cluster Configuration, such as the default Controller Port or the KV store
timeout.

4
docker-cloud/builds/advanced.md
View File

@ -26,7 +26,7 @@ If you are using these build environment variables in a
`docker-compose.test.yml` file for automated testing, declare them in your `sut`
service's environment as shown below.
```yml
```none
sut:
build: .
command: run_tests.sh
@ -110,4 +110,4 @@ If you needed to give the resulting image multiple tags, or push the same image
```none
docker tag $IMAGE_NAME $DOCKER_REPO:$SOURCE_COMMIT
docker push $DOCKER_REPO:$SOURCE_COMMIT
```
```

56
docker-cloud/builds/automated-build.md
View File

@ -13,16 +13,16 @@ repository and automatically push the built image to your Docker
repositories.
When you set up automated builds (also called autobuilds), you create a list of
branches and tags of the images that you want to build. When you push code to a
source code branch (for example in Github) for one of those listed image tags,
the push uses a webhook to trigger a new build, which produces a Docker image.
The built image is then pushed to the Docker Cloud registry or to an external
registry.
branches and tags that you want to build into Docker images. When you push code
to a source code branch (for example in Github) for one of those listed image
tags, the push uses a webhook to trigger a new build, which produces a Docker
image. The built image is then pushed to the Docker Cloud registry or to an
external registry.
If you have automated tests configured, these run after building but before
pushing to the registry. You can use these tests to create a continuous
integration workflow. Automated tests do not push images to the registry on
their own. [Learn more about automated image testing here.](automated-testing.md)
integration workflow where a build that fails its tests does not push the built
image. Automated tests do not push images to the registry on their own. [Learn more about automated image testing here.](automated-testing.md)
You can also just use `docker push` to push pre-built images to these
repositories, even if you have automatic builds set up.
@ -31,7 +31,7 @@ repositories, even if you have automatic builds set up.
## Configure automated build settings
You can configure your repositories in Docker Cloud so that they automatically
You can configure repositories in Docker Cloud so that they automatically
build an image each time you push new code to your source provider. If you have
[automated tests](automated-testing.md) configured, the new image is only pushed
when the tests succeed.
@ -94,7 +94,8 @@ the code repository service where the image's source code is stored.
Only branches or tags with autobuild enabled are built, tested, *and* have
the resulting image pushed to the repository. Branches with autobuild
disabled will be built for test purposes (if enabled at the repository level), but not pushed.
disabled will be built for test purposes (if enabled at the repository
level), but the built Docker image is not pushed to the repository.
10. For each branch or tag, enable or disable the **Build Caching** toggle.
@ -124,18 +125,39 @@ should remain secret.
the build processes _only_ and should not be confused with the environment
values used by your service (for example to create service links).
## Check your active builds
You can view a summary of the last five builds for a repository from the repository's **General** tab. You can also click **Timeline** to view a list of all active builds, and expand each build to see their real-time logs. The **Builds** tab also displays a color coded bar chart of the build queue times and durations.
A summary of a repository's builds appears both on the repository **General**
tab, and in the **Builds** tab. The **Builds** tab also displays a color coded
bar chart of the build queue times and durations. Both views display the
pending, in progress, successful, and failed builds for any tag of the
repository.
Both views display the pending, in progress, successful, and failed builds
for any tag of the repository.
From either location, you can click a build job to view its build report. The
build report shows information about the build job including the source
repository and branch (or tag), the build duration, creation time and location,
and the user namespace the build occurred in.
You can click the **Cancel** button for pending builds and builds in progress.
If a build fails, the cancel button is replaced by a **Retry** button.
![screen showing a build report](images/build-report.png)
## Cancel or retry a build
While a build is queued or running, a **Cancel** icon appears next to its build
report link on the General tab and on the Builds tab. You can also click the
**Cancel** button from the build report page, or from the Timeline tab's logs
display for the build.
![list of builds showing the cancel icon](images/build-cancelicon.png)
If a build fails, a **Retry** icon appears next to the build report line on the
General and Builds tabs, and the build report page and Timeline logs also
display a **Retry** button.
![Timeline view showing the retry build button](images/retry-build.png)
> **Note**: If you are viewing the build details for a repository that belongs
to an Organization, the Cancel and Retry buttons only appear if you have `Read & Write` access to the repository.
![](images/cancel-build.png)
## Disable an automated build
@ -355,4 +377,4 @@ Docker Cloud's [Autotest](automated-testing.md) feature which
integrates seamlessly with autobuild and autoredeploy.
> **Note**: While the Autotest feature builds an image for testing purposes, it
does not push the resulting image to Docker Cloud or the external registry.
does not push the resulting image to Docker Cloud or the external registry.

15
docker-cloud/builds/automated-testing.md
View File

@ -6,9 +6,9 @@ redirect_from:
title: Automated repository tests
---
Docker Cloud can automatically test changes pushed to your source code
repositories using containers. You can enable `Autotest` on [any Docker Cloud repository](repos.md) to run tests at each push to the source code repository,
similar to a continuous integration testing service.
Docker Cloud can automatically test changes to your source code repositories
using containers. You can enable `Autotest` on [any Docker Cloud repository](repos.md) to run tests on each pull request to the source code
repository to create a continuous integration testing service.
Enabling `Autotest` builds an image for testing purposes, but does **not**
automatically push the built image to the Docker repository. If you want to push
@ -22,7 +22,7 @@ tests to be run.
For example:
```yml
```none
sut:
build: .
command: run_tests.sh
@ -78,8 +78,9 @@ Docker repository, regardless of the Autotest settings.
> **Note**: For security purposes, autotest on _external pull requests_ is
disabled on public repositories. If you select this option on a public
repository, tests will still run on pushes to the source code repository,
but not on pull requests.
repository, tests will still run on _internal_ pull requests (for example
from one branch into another inside the code repository) but not on for
external pull requests.
9. Click **Save** to save the settings, or click **Save and build** to save and
run an initial test.
@ -91,4 +92,4 @@ From the repository's details page, click **Timeline**.
From this tab you can see any pending, in-progress, successful, and failed
builds and test runs for the repository.
You can click any timeline entry to view the logs for each test run.
You can click any timeline entry to view the logs for each test run.

BIN
docker-cloud/builds/images/build-cancelicon.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 18 KiB

BIN
docker-cloud/builds/images/build-report.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 93 KiB

BIN
docker-cloud/builds/images/cancel-build.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 82 KiB

After

Width:  |  Height:  |  Size: 85 KiB

BIN
docker-cloud/builds/images/retry-build.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 94 KiB

5
docker-for-mac/troubleshoot.md
View File

@ -36,7 +36,10 @@ Docker Team:
![Diagnostic results only](images/settings-diagnostic-results-only.png)
* **Diagnose & Upload** - Runs diagnostics, shows results, and auto-uploads the diagnostic results to Docker. A diagnostic ID is auto-generated. You can refer to this ID when communicating with the Docker Team. Optionally, you can open an issue on GitHub using the uploaded results and ID as a basis.
* **Diagnose & Upload** - Runs diagnostics, shows results, and auto-uploads the
diagnostic results to Docker. A diagnostic ID is auto-generated. You can refer
to this ID when communicating with the Docker Team. Optionally, you can open
an issue on GitHub using the uploaded results and ID as a basis.
![Diagnostics & Feedback](images/settings-diagnose-id.png)

2
docker-for-windows/release-notes.md
View File

@ -22,7 +22,7 @@ about both kinds of releases, and download stable and beta product installers at
## Stable Release Notes
### Docker for Windows 1.13.3, 2016-11-09 (stable)
### Docker for Windows 1.12.3, 2016-11-09 (stable)
**New**

79
docker-for-windows/troubleshoot.md
View File

@ -122,15 +122,45 @@ local user is `samstevens` and the domain user is `merlin`.
See also, the related issue on GitHub, [Mounted volumes are empty in the container](https://github.com/docker/for-win/issues/25).
### Local security policies can block shared drives and cause login errors
You need permissions to mount shared drives in order to use the Docker for
Windows [shared drives](index.md#shared-drives) feature.
If local policy prevents this, you will get errors when you attempt to enable
shared drives on Docker. This is not something Docker can resolve, you do need
these permissions to use the feature.
Here are snip-its from example error messages:
```
Logon failure: the user has not been granted the requested logon type at
this computer.
[19:53:26.900][SambaShare ][Error ] Unable to mount C drive: mount
error(5): I/O error Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
mount: mounting //10.0.75.1/C on /c failed: Invalid argument
```
See also, <a href="https://github.com/docker/for-win/issues/98">Docker for Windows issue #98</a>.
### Understand symlinks limitations
Symlinks will work within and across containers. However, symlinks created outside of containers (for example, on the host) will not work. To learn more, see [Are symlinks supported?](faqs.md#are-symlinks-supported) in the FAQs.
### Avoid unexpected syntax errors, use Unix style line endings for files in containers
Any file destined to run inside a container must use Unix style `\n` line endings. This includes files referenced at the command line for builds and in RUN commands in Docker files.
Any file destined to run inside a container must use Unix style `\n` line
endings. This includes files referenced at the command line for builds and in
RUN commands in Docker files.
Docker containers and `docker build` run in a Unix environment, so files in containers must use Unix style line endings: `\n`, _not_ Windows style: `\r\n`. Keep this in mind when authoring files such as shell scripts using Windows tools, where the default is likely to be Windows style line endings. These commands ultimately get passed to Unix commands inside a Unix based container (for example, a shell script passed to `/bin/sh`). If Windows style line endings are used, `docker run` will fail with syntax errors.
Docker containers and `docker build` run in a Unix environment, so files in
containers must use Unix style line endings: `\n`, _not_ Windows style: `\r\n`.
Keep this in mind when authoring files such as shell scripts using Windows
tools, where the default is likely to be Windows style line endings. These
commands ultimately get passed to Unix commands inside a Unix based container
(for example, a shell script passed to `/bin/sh`). If Windows style line endings
are used, `docker run` will fail with syntax errors.
For an example of this issue and the resolution, see this issue on GitHub: <a href="https://github.com/docker/docker/issues/24388" target="_blank">Docker RUN fails to execute shell script (https://github.com/docker/docker/issues/24388)</a>.
@ -257,14 +287,25 @@ As an immediate workaround to this problem, reset the DNS server to use the Goog
We are currently investigating this issue.
#### Networking issues on pre Beta 10 versions
Docker for Windows Beta 10 and later fixed a number of issues around the networking setup. If you still experience networking issue, this may be related to previous Docker for Windows installations. In this case, please quit Docker for Windows and perform the following steps:
Docker for Windows Beta 10 and later fixed a number of issues around the
networking setup. If you still experience networking issue, this may be related
to previous Docker for Windows installations. In this case, please quit Docker
for Windows and perform the following steps:
##### 1. Remove multiple `DockerNAT` VMswitches
You might have multiple Internal VMSwitches called `DockerNAT`. You can view all VMSwitches either via the `Hyper-V Manager` sub-menu `Virtual Switch Manager` or from an elevated Powershell (run as Administrator) prompt by typing `Get-VMSwitch`. Simply delete all VMSwitches with `DockerNAT` in the name, either via the `Virtual Switch Manager` or by using `Remove-VMSwitch` powershell cmdlet.
You might have multiple Internal VMSwitches called `DockerNAT`. You can view all
VMSwitches either via the `Hyper-V Manager` sub-menu `Virtual Switch Manager` or
from an elevated Powershell (run as Administrator) prompt by typing
`Get-VMSwitch`. Simply delete all VMSwitches with `DockerNAT` in the name,
either via the `Virtual Switch Manager` or by using `Remove-VMSwitch` powershell
cmdlet.
##### 2. Remove lingering IP addresses
You might have lingering IP addresses on the system. They are supposed to get removed when you remove the associated VMSwitches, but sometimes this fails. Using `Remove-NetIPAddress 10.0.75.1` in an elevated Powershell prompt should remove them.
You might have lingering IP addresses on the system. They are supposed to get
removed when you remove the associated VMSwitches, but sometimes this fails.
Using `Remove-NetIPAddress 10.0.75.1` in an elevated Powershell prompt should
remove them.
##### 3. Remove stale NAT configurations
@ -277,21 +318,37 @@ You might have stale Network Adapters on the system. You should remove them with
$vmNetAdapter = Get-VMNetworkAdapter -ManagementOS -SwitchName DockerNAT
Get-NetAdapter "vEthernet (DockerNAT)" | ? { $_.DeviceID -ne $vmNetAdapter.DeviceID } | Disable-NetAdapter -Confirm:$False -PassThru | Rename-NetAdapter -NewName "Broken Docker Adapter"
Then you can remove them manually via the `devmgmt.msc` (aka Device Manager). You should see them as disabled Hyper-V Virtual Ethernet Adapter under the Network Adapter section. A right-click and selecting **uninstall** should remove the adapter.
Then you can remove them manually via the `devmgmt.msc` (aka Device Manager).
You should see them as disabled Hyper-V Virtual Ethernet Adapter under the
Network Adapter section. A right-click and selecting **uninstall** should remove
the adapter.
### NAT/IP configuration
By default, Docker for Windows uses an internal network prefix of `10.0.75.0/24`. Should this clash with your normal network setup, you can change the prefix from the **Settings** menu. See the [Network](index.md#network) topic under [Settings](index.md#docker-settings).
By default, Docker for Windows uses an internal network prefix of
`10.0.75.0/24`. Should this clash with your normal network setup, you can change
the prefix from the **Settings** menu. See the [Network](index.md#network) topic
under [Settings](index.md#docker-settings).
#### NAT/IP configuration issues on pre Beta 15 versions
As of Beta 15, Docker for Windows is no longer using a switch with a NAT configuration. The notes below are left here only for older Beta versions.
As of Beta 15, Docker for Windows is no longer using a switch with a NAT
configuration. The notes below are left here only for older Beta versions.
As of Beta14, networking for Docker for Windows is configurable through the UI. See the [Network](index.md#network) topic under [Settings](index.md#docker-settings).
As of Beta14, networking for Docker for Windows is configurable through the UI.
See the [Network](index.md#network) topic under
[Settings](index.md#docker-settings).
By default, Docker for Windows uses an internal Hyper-V switch with a NAT configuration with a `10.0.75.0/24` prefix. You can change the prefix used (as well as the DNS server) via the **Settings** menu as described in the [Network](index.md#network) topic.
By default, Docker for Windows uses an internal Hyper-V switch with a NAT
configuration with a `10.0.75.0/24` prefix. You can change the prefix used (as
well as the DNS server) via the **Settings** menu as described in the
[Network](index.md#network) topic.
If you have additional Hyper-V VMs and they are attached to their own NAT prefixes, the prefixes need to be managed carefully, due to limitation of the Windows NAT implementation. Specifically, Windows currently only allows a single internal NAT prefix. If you need additional prefixes for your other VMs, you can create a larger NAT prefix.
If you have additional Hyper-V VMs and they are attached to their own NAT
prefixes, the prefixes need to be managed carefully, due to limitation of the
Windows NAT implementation. Specifically, Windows currently only allows a single
internal NAT prefix. If you need additional prefixes for your other VMs, you can
create a larger NAT prefix.
To create a larger NAT prefix, do the following.

BIN
docker-id/images/login-cloud.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 30 KiB

50
docker-id/index.md Normal file
View File

@ -0,0 +1,50 @@
---
description: Sign up for a Docker ID and log in
keywords: accounts, docker ID, billing, paid plans, support, Cloud, Hub, Store, Forums, knowledge base, beta access
title: Docker ID accounts
---
Your free Docker ID grants you access to Docker services such as the Docker
Store, Docker Cloud, Docker Hub repositories, and some beta programs. Your
Docker ID becomes repository namespace used by hosted services such as Docker
Hub and Docker Cloud. All you need is an email address.
This account also allows you to log in to services such as the Docker Support
Center, the Docker Forums, and the Docker Success portal.
## Register for a Docker ID
Your Docker ID becomes your user namespace for hosted Docker services, and becomes your username on the Docker Forums. A Docker ID also
1. Go to the [Docker Cloud sign up page](https://cloud.docker.com).
2. Enter a username, a valid email address, and a password.
3. Click **Sign Up**.
Docker sends a verification email to the address you provided.
4. Click the link in the email to verify your address.
> **Note**: You cannot log in with your Docker ID until you verify your email address.
## Log in
Once you register and verify your Docker ID email address, you can log in
to Docker services.
For Docker Cloud, Hub, and Store, log in using the web interface.
![Login using the web interface](images/login-cloud.png)
You can also log in using the the `docker login` command. (You can read more about `docker login` [here](../engine/reference/commandline/login/).)
> **Note:** When you use the `docker login` command, your credentials are stored
in your home directory in `.docker/config.json`. The password is hashed in this
file.
## The Accounts API
Once you create and verify your Docker ID, you can also update it using the [Docker Accounts API](../engine/reference/api/docker_io_accounts_api/).

6
engine/admin/live-restore.md
View File

@ -10,6 +10,9 @@ containers remain running if the daemon becomes unavailable. The live restore
option helps reduce container downtime due to daemon crashes, planned outages,
or upgrades.
> **Note**: Live restore is not supported on Windows containers, but it does work
for Linux containers running on Windows.
## Enable the live restore option
There are two ways to enable the live restore setting to keep containers alive
@ -71,4 +74,5 @@ You can modify the kernel's buffer size by changing `/proc/sys/fs/pipe-max-size`
The live restore option is not compatible with Docker Engine swarm mode. When
the Docker Engine runs in swarm mode, the orchestration feature manages tasks
and keeps containers running according to a service specification.
and keeps containers running according to a service specification.

195
engine/deprecated.md
View File

@ -1,195 +0,0 @@
---
redirect_from:
- /engine/misc/deprecated/
description: Deprecated Features.
keywords:
- docker, documentation, about, technology, deprecate
title: Deprecated Engine features
---
The following list of features are deprecated in Engine.
To learn more about Docker Engine's deprecation policy,
see [Feature Deprecation Policy](index.md#feature-deprecation-policy).
### Three argument form in `docker import`
**Deprecated In Release: [v0.6.7](https://github.com/docker/docker/releases/tag/v0.6.7)**
**Removed In Release: [v1.12.0](https://github.com/docker/docker/releases/tag/v1.12.0)**
The `docker import` command format `file|URL|- [REPOSITORY [TAG]]` is deprecated since November 2013. It's no more supported.
### `-h` shorthand for `--help`
**Deprecated In Release: [v1.12.0](https://github.com/docker/docker/releases/tag/v1.12.0)**
**Target For Removal In Release: v1.15**
The shorthand (`-h`) is less common than `--help` on Linux and cannot be used
on all subcommands (due to it conflicting with, e.g. `-h` / `--hostname` on
`docker create`). For this reason, the `-h` shorthand was not printed in the
"usage" output of subcommands, nor documented, and is now marked "deprecated".
### `-e` and `--email` flags on `docker login`
**Deprecated In Release: [v1.11.0](https://github.com/docker/docker/releases/tag/v1.11.0)**
**Target For Removal In Release: v1.14**
The docker login command is removing the ability to automatically register for an account with the target registry if the given username doesn't exist. Due to this change, the email flag is no longer required, and will be deprecated.
### Separator (`:`) of `--security-opt` flag on `docker run`
**Deprecated In Release: [v1.11.0](https://github.com/docker/docker/releases/tag/v1.11.0)**
**Target For Removal In Release: v1.14**
The flag `--security-opt` doesn't use the colon separator(`:`) anymore to divide keys and values, it uses the equal symbol(`=`) for consistency with other similar flags, like `--storage-opt`.
### `/containers/(id or name)/copy` endpoint
**Deprecated In Release: [v1.8.0](https://github.com/docker/docker/releases/tag/v1.8.0)**
**Removed In Release: [v1.12.0](https://github.com/docker/docker/releases/tag/v1.12.0)**
The endpoint `/containers/(id or name)/copy` is deprecated in favor of `/containers/(id or name)/archive`.
### Ambiguous event fields in API
**Deprecated In Release: [v1.10.0](https://github.com/docker/docker/releases/tag/v1.10.0)**
The fields `ID`, `Status` and `From` in the events API have been deprecated in favor of a more rich structure.
See the events API documentation for the new format.
### `-f` flag on `docker tag`
**Deprecated In Release: [v1.10.0](https://github.com/docker/docker/releases/tag/v1.10.0)**
**Removed In Release: [v1.12.0](https://github.com/docker/docker/releases/tag/v1.12.0)**
To make tagging consistent across the various `docker` commands, the `-f` flag on the `docker tag` command is deprecated. It is not longer necessary to specify `-f` to move a tag from one image to another. Nor will `docker` generate an error if the `-f` flag is missing and the specified tag is already in use.
### HostConfig at API container start
**Deprecated In Release: [v1.10.0](https://github.com/docker/docker/releases/tag/v1.10.0)**
**Removed In Release: [v1.12.0](https://github.com/docker/docker/releases/tag/v1.12.0)**
Passing an `HostConfig` to `POST /containers/{name}/start` is deprecated in favor of
defining it at container creation (`POST /containers/create`).
### Docker ps 'before' and 'since' options
**Deprecated In Release: [v1.10.0](https://github.com/docker/docker/releases/tag/v1.10.0)**
**Removed In Release: [v1.12.0](https://github.com/docker/docker/releases/tag/v1.12.0)**
The `docker ps --before` and `docker ps --since` options are deprecated.
Use `docker ps --filter=before=...` and `docker ps --filter=since=...` instead.
### Docker search 'automated' and 'stars' options
**Deprecated in Release: [v1.12.0](https://github.com/docker/docker/releases/tag/v1.12.0)**
**Target For Removal In Release: v1.15**
The `docker search --automated` and `docker search --stars` options are deprecated.
Use `docker search --filter=is-automated=...` and `docker search --filter=stars=...` instead.
### Driver Specific Log Tags
**Deprecated In Release: [v1.9.0](https://github.com/docker/docker/releases/tag/v1.9.0)**
**Removed In Release: [v1.12.0](https://github.com/docker/docker/releases/tag/v1.12.0)**
Log tags are now generated in a standard way across different logging drivers.
Because of which, the driver specific log tag options `syslog-tag`, `gelf-tag` and
`fluentd-tag` have been deprecated in favor of the generic `tag` option.
```bash
{% raw %}
$ docker --log-driver=syslog --log-opt tag="{{.ImageName}}/{{.Name}}/{{.ID}}"
{% endraw %}
```
### LXC built-in exec driver
**Deprecated In Release: [v1.8.0](https://github.com/docker/docker/releases/tag/v1.8.0)**
**Removed In Release: [v1.10.0](https://github.com/docker/docker/releases/tag/v1.10.0)**
The built-in LXC execution driver, the lxc-conf flag, and API fields have been removed.
### Old Command Line Options
**Deprecated In Release: [v1.8.0](https://github.com/docker/docker/releases/tag/v1.8.0)**
**Removed In Release: [v1.10.0](https://github.com/docker/docker/releases/tag/v1.10.0)**
The flags `-d` and `--daemon` are deprecated in favor of the `daemon` subcommand:
```bash
$ docker daemon -H ...
```
The following single-dash (`-opt`) variant of certain command line options
are deprecated and replaced with double-dash options (`--opt`):
```none
docker attach -nostdin
docker attach -sig-proxy
docker build -no-cache
docker build -rm
docker commit -author
docker commit -run
docker events -since
docker history -notrunc
docker images -notrunc
docker inspect -format
docker ps -beforeId
docker ps -notrunc
docker ps -sinceId
docker rm -link
docker run -cidfile
docker run -dns
docker run -entrypoint
docker run -expose
docker run -link
docker run -lxc-conf
docker run -n
docker run -privileged
docker run -volumes-from
docker search -notrunc
docker search -stars
docker search -t
docker search -trusted
docker tag -force
```
The following double-dash options are deprecated and have no replacement:
```none
docker run --cpuset
docker run --networking
docker ps --since-id
docker ps --before-id
docker search --trusted
```
**Deprecated In Release: [v1.5.0](https://github.com/docker/docker/releases/tag/v1.5.0)**
**Removed In Release: [v1.12.0](https://github.com/docker/docker/releases/tag/v1.12.0)**
The single-dash (`-help`) was removed, in favor of the double-dash `--help`
```bash
$ docker -help
docker [COMMAND] -help
```
### Interacting with V1 registries
Version 1.9 adds a flag (`--disable-legacy-registry=false`) which prevents the docker daemon from `pull`, `push`, and `login` operations against v1 registries. Though disabled by default, this signals the intent to deprecate the v1 protocol.
### Docker Content Trust ENV passphrase variables name change
**Deprecated In Release: [v1.9.0](https://github.com/docker/docker/releases/tag/v1.9.0)**
**Removed In Release: [v1.12.0](https://github.com/docker/docker/releases/tag/v1.12.0)**
Since 1.9, Docker Content Trust Offline key has been renamed to Root key and the Tagging key has been renamed to Repository key. Due to this renaming, we're also changing the corresponding environment variables
- DOCKER_CONTENT_TRUST_OFFLINE_PASSPHRASE is now named DOCKER_CONTENT_TRUST_ROOT_PASSPHRASE
- DOCKER_CONTENT_TRUST_TAGGING_PASSPHRASE is now named DOCKER_CONTENT_TRUST_REPOSITORY_PASSPHRASE

BIN
engine/extend/images/authz_additional_info.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 45 KiB

BIN
engine/extend/images/authz_allow.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 33 KiB

BIN
engine/extend/images/authz_chunked.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 32 KiB

BIN
engine/extend/images/authz_connection_hijack.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 38 KiB

BIN
engine/extend/images/authz_deny.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 26 KiB

263
engine/extend/index.md
View File

@ -1,263 +0,0 @@
---
advisory: experimental
description: How develop and use a plugin with the managed plugin system
keywords:
- API, Usage, plugins, documentation, developer
title: Docker Engine managed plugin system
---
This document describes the plugin system available today in the **experimental
build** of Docker 1.12:
* [How to operate an existing plugin](index.md#how-to-operate-a-plugin)
* [How to develop a plugin](index.md#how-to-develop-a-plugin)
Unlike the legacy plugin system, you now manage plugins using Docker Engine:
* install plugins
* start plugins
* stop plugins
* remove plugins
The current Docker Engine plugin system only supports volume drivers. We are
adding more plugin driver types in the future releases.
For information on Docker Engine plugins generally available in Docker Engine
1.12 and earlier, refer to [Understand legacy Docker Engine plugins](legacy_plugins.md).
## How to operate a plugin
Plugins are distributed as Docker images, so develpers can host them on Docker
Hub or on a private registry.
You install the plugin using a single command: `docker plugin install <PLUGIN>`.
The `plugin install` command pulls the plugin from the Docker Hub or private
registry. If necessary the CLI prompts you to accept any privilige requriements.
For example the plugin may require access to a device on the host system.
Finally it enables the plugin.
Run `docker plugin ls` to check the status of installed plugins. The Engine
markes plugins that are started without issues as `ENABLED`.
After you install a plugin, the plugin behavior is the same as legacy plugins.
The following example demonstrates how to install the `sshfs` plugin and use it
to create a volume.
1. Install the `sshfs` plugin.
```bash
$ docker plugin install vieux/sshfs
Plugin "vieux/sshfs" is requesting the following privileges:
- network: [host]
- capabilities: [CAP_SYS_ADMIN]
Do you grant the above permissions? [y/N] y
vieux/sshfs
```
The plugin requests 2 privileges, the `CAP_SYS_ADMIN` capability to be able
to do mount inside the plugin and `host networking`.
2. Check for a value of `true` the `ENABLED` column to verify the plugin
started without error.
```bash
$ docker plugin ls
NAME TAG ENABLED
vieux/sshfs latest true
```
3. Create a volume using the plugin.
```bash
$ docker volume create \
-d vieux/sshfs \
--name sshvolume \
-o sshcmd=user@1.2.3.4:/remote
sshvolume
```
4. Use the volume `sshvolume`.
```bash
$ docker run -v sshvolume:/data busybox ls /data
<content of /remote on machine 1.2.3.4>
```
5. Verify the plugin successfully created the volume.
```bash
$ docker volume ls
DRIVER NAME
vieux/sshfs sshvolume
```
You can stop a plugin with the `docker plugin disable`
command or remove a plugin with `docker plugin remove`.
See the [command line reference](../reference/commandline/index.md) for more
information.
## How to develop a plugin
Plugin creation is currently a manual process. We plan to add automation in a
future release with a command such as `docker plugin build`.
This section describes the format of an existing enabled plugin. You have to
create and format the plugin files by hand.
Plugins are stored in `/var/lib/docker/plugins`. For instance:
```bash
# ls -la /var/lib/docker/plugins
total 20
drwx------ 4 root root 4096 Aug 8 18:03 .
drwx--x--x 12 root root 4096 Aug 8 17:53 ..
drwxr-xr-x 3 root root 4096 Aug 8 17:56 cd851ce43a403
-rw------- 1 root root 2107 Aug 8 18:03 plugins.json
```
`plugins.json` is an inventory of all installed plugins. For example:
```bash
# cat plugins.json
{
"cd851ce43a403": {
"plugin": {
"Manifest": {
"Args": {
"Value": null,
"Settable": null,
"Description": "",
"Name": ""
},
"Env": null,
"Devices": null,
"Mounts": null,
"Capabilities": [
"CAP_SYS_ADMIN"
],
"ManifestVersion": "v0",
"Description": "sshFS plugin for Docker",
"Documentation": "https://docs.docker.com/engine/extend/plugins/",
"Interface": {
"Socket": "sshfs.sock",
"Types": [
"docker.volumedriver/1.0"
]
},
"Entrypoint": [
"/go/bin/docker-volume-sshfs"
],
"Workdir": "",
"User": {},
"Network": {
"Type": "host"
}
},
"Config": {
"Devices": null,
"Args": null,
"Env": [],
"Mounts": []
},
"Active": true,
"Tag": "latest",
"Name": "vieux/sshfs",
"Id": "cd851ce43a403"
}
}
}
```
Each folder represents a plugin. For example:
```bash
# ls -la /var/lib/docker/plugins/cd851ce43a403
total 12
drwx------ 19 root root 4096 Aug 8 17:56 rootfs
-rw-r--r-- 1 root root 50 Aug 8 17:56 plugin-config.json
-rw------- 1 root root 347 Aug 8 17:56 manifest.json
```
`rootfs` represents the root filesystem of the plugin. In this example, it was
created from a Dockerfile as follows:
>**Note:** `/run/docker/plugins` is mandatory for docker to communicate with
the plugin._
```bash
$ git clone https://github.com/vieux/docker-volume-sshfs
$ cd docker-volume-sshfs
$ docker build -t rootfs .
$ id=$(docker create rootfs true) # id was cd851ce43a403 when the image was created
$ mkdir -p /var/lib/docker/plugins/$id/rootfs
$ docker export "$id" | tar -x -C /var/lib/docker/plugins/$id/rootfs
$ docker rm -vf "$id"
$ docker rmi rootfs
```
`manifest.json` describes the plugin and `plugin-config.json` contains some
runtime parameters. [See the Plugins Manifest reference](manifest.md). For example:
```bash
# cat manifest.json
{
"manifestVersion": "v0",
"description": "sshFS plugin for Docker",
"documentation": "https://docs.docker.com/engine/extend/plugins/",
"entrypoint": ["/go/bin/docker-volume-sshfs"],
"network": {
"type": "host"
},
"interface" : {
"types": ["docker.volumedriver/1.0"],
"socket": "sshfs.sock"
},
"capabilities": ["CAP_SYS_ADMIN"]
}
```
In this example, you can see the plugin is a volume driver, requires the
`CAP_SYS_ADMIN` capability, `host networking`, `/go/bin/docker-volume-sshfs` as
entrypoint and is going to use `/run/docker/plugins/sshfs.sock` to communicate
with the Docker Engine.
```bash
# cat plugin-config.json
{
"Devices": null,
"Args": null,
"Env": [],
"Mounts": []
}
```
This plugin doesn't require runtime parameters.
Both `manifest.json` and `plugin-config.json` are part of the `plugins.json`.
`manifest.json` is read-only and `plugin-config.json` is read-write.
To summarize, follow the steps below to create a plugin:
0. Choose a name for the plugin. Plugin name uses the same format as images,
for example: `<repo_name>/<name>`.
1. Create a rootfs in `/var/lib/docker/plugins/$id/rootfs`.
2. Create manifest.json file in `/var/lib/docker/plugins/$id/`.
3. Create a `plugin-config.json` if needed.
4. Create or add a section to `/var/lib/docker/plugins/plugins.json`. Use
`<user>/<name>` as “Name” and `$id` as “Id”.
5. Restart the Docker Engine.
6. Run `docker plugin ls`.
* If your plugin is listed as `ENABLED=true`, you can push it to the
registry.
* If the plugin is not listed or if `ENABLED=false`, something went wrong.
Check the daemon logs for errors.
7. If you are not already logged in, use `docker login` to authenticate against
a registry.
8. Run `docker plugin push <repo_name>/<name>` to push the plugin.

88
engine/extend/legacy_plugins.md
View File

@ -1,88 +0,0 @@
---
redirect_from:
- /engine/extend/plugins/
description: How to add additional functionality to Docker with plugins extensions
keywords:
- Examples, Usage, plugins, docker, documentation, user guide
title: Use Docker Engine plugins
---
This document describes the Docker Engine plugins generally available in Docker
Engine. To view information on plugins managed by Docker Engine currently in
experimental status, refer to [Docker Engine plugin system](index.md).
You can extend the capabilities of the Docker Engine by loading third-party
plugins. This page explains the types of plugins and provides links to several
volume and network plugins for Docker.
## Types of plugins
Plugins extend Docker's functionality. They come in specific types. For
example, a [volume plugin](plugins_volume.md) might enable Docker
volumes to persist across multiple Docker hosts and a
[network plugin](plugins_network.md) might provide network plumbing.
Currently Docker supports authorization, volume and network driver plugins. In the future it
will support additional plugin types.
## Installing a plugin
Follow the instructions in the plugin's documentation.
## Finding a plugin
The sections below provide an inexhaustive overview of available plugins.
<style>
#DocumentationText tr td:first-child { white-space: nowrap;}
</style>
### Network plugins
Plugin | Description
----------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
[Contiv Networking](https://github.com/contiv/netplugin) | An open source network plugin to provide infrastructure and security policies for a multi-tenant micro services deployment, while providing an integration to physical network for non-container workload. Contiv Networking implements the remote driver and IPAM APIs available in Docker 1.9 onwards.
[Kuryr Network Plugin](https://github.com/openstack/kuryr) | A network plugin is developed as part of the OpenStack Kuryr project and implements the Docker networking (libnetwork) remote driver API by utilizing Neutron, the OpenStack networking service. It includes an IPAM driver as well.
[Weave Network Plugin](https://www.weave.works/docs/net/latest/introducing-weave/) | A network plugin that creates a virtual network that connects your Docker containers - across multiple hosts or clouds and enables automatic discovery of applications. Weave networks are resilient, partition tolerant, secure and work in partially connected networks, and other adverse environments - all configured with delightful simplicity.
### Volume plugins
Plugin | Description
----------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
[Azure File Storage plugin](https://github.com/Azure/azurefile-dockervolumedriver) | Lets you mount Microsoft [Azure File Storage](https://azure.microsoft.com/blog/azure-file-storage-now-generally-available/) shares to Docker containers as volumes using the SMB 3.0 protocol. [Learn more](https://azure.microsoft.com/blog/persistent-docker-volumes-with-azure-file-storage/).
[Blockbridge plugin](https://github.com/blockbridge/blockbridge-docker-volume) | A volume plugin that provides access to an extensible set of container-based persistent storage options. It supports single and multi-host Docker environments with features that include tenant isolation, automated provisioning, encryption, secure deletion, snapshots and QoS.
[Contiv Volume Plugin](https://github.com/contiv/volplugin) | An open source volume plugin that provides multi-tenant, persistent, distributed storage with intent based consumption. It has support for Ceph and NFS.
[Convoy plugin](https://github.com/rancher/convoy) | A volume plugin for a variety of storage back-ends including device mapper and NFS. It's a simple standalone executable written in Go and provides the framework to support vendor-specific extensions such as snapshots, backups and restore.
[DRBD plugin](https://www.drbd.org/en/supported-projects/docker) | A volume plugin that provides highly available storage replicated by [DRBD](https://www.drbd.org). Data written to the docker volume is replicated in a cluster of DRBD nodes.
[Flocker plugin](https://clusterhq.com/docker-plugin/) | A volume plugin that provides multi-host portable volumes for Docker, enabling you to run databases and other stateful containers and move them around across a cluster of machines.
[gce-docker plugin](https://github.com/mcuadros/gce-docker) | A volume plugin able to attach, format and mount Google Compute [persistent-disks](https://cloud.google.com/compute/docs/disks/persistent-disks).
[GlusterFS plugin](https://github.com/calavera/docker-volume-glusterfs) | A volume plugin that provides multi-host volumes management for Docker using GlusterFS.
[Horcrux Volume Plugin](https://github.com/muthu-r/horcrux) | A volume plugin that allows on-demand, version controlled access to your data. Horcrux is an open-source plugin, written in Go, and supports SCP, [Minio](https://www.minio.io) and Amazon S3.
[HPE 3Par Volume Plugin](https://github.com/hpe-storage/python-hpedockerplugin/) | A volume plugin that supports HPE 3Par and StoreVirtual iSCSI storage arrays.
[IPFS Volume Plugin](http://github.com/vdemeester/docker-volume-ipfs) | An open source volume plugin that allows using an [ipfs](https://ipfs.io/) filesystem as a volume.
[Keywhiz plugin](https://github.com/calavera/docker-volume-keywhiz) | A plugin that provides credentials and secret management using Keywhiz as a central repository.
[Local Persist Plugin](https://github.com/CWSpear/local-persist) | A volume plugin that extends the default `local` driver's functionality by allowing you specify a mountpoint anywhere on the host, which enables the files to *always persist*, even if the volume is removed via `docker volume rm`.
[NetApp Plugin](https://github.com/NetApp/netappdvp) (nDVP) | A volume plugin that provides direct integration with the Docker ecosystem for the NetApp storage portfolio. The nDVP package supports the provisioning and management of storage resources from the storage platform to Docker hosts, with a robust framework for adding additional platforms in the future.
[Netshare plugin](https://github.com/ContainX/docker-volume-netshare) | A volume plugin that provides volume management for NFS 3/4, AWS EFS and CIFS file systems.
[OpenStorage Plugin](https://github.com/libopenstorage/openstorage) | A cluster-aware volume plugin that provides volume management for file and block storage solutions. It implements a vendor neutral specification for implementing extensions such as CoS, encryption, and snapshots. It has example drivers based on FUSE, NFS, NBD and EBS to name a few.
[Portworx Volume Plugin](https://github.com/portworx/px-dev) | A volume plugin that turns any server into a scale-out converged compute/storage node, providing container granular storage and highly available volumes across any node, using a shared-nothing storage backend that works with any docker scheduler.
[Quobyte Volume Plugin](https://github.com/quobyte/docker-volume) | A volume plugin that connects Docker to [Quobyte](http://www.quobyte.com/containers)'s data center file system, a general-purpose scalable and fault-tolerant storage platform.
[REX-Ray plugin](https://github.com/emccode/rexray) | A volume plugin which is written in Go and provides advanced storage functionality for many platforms including VirtualBox, EC2, Google Compute Engine, OpenStack, and EMC.
[Virtuozzo Storage and Ploop plugin](https://github.com/virtuozzo/docker-volume-ploop) | A volume plugin with support for Virtuozzo Storage distributed cloud file system as well as ploop devices.
[VMware vSphere Storage Plugin](https://github.com/vmware/docker-volume-vsphere) | Docker Volume Driver for vSphere enables customers to address persistent storage requirements for Docker containers in vSphere environments.
### Authorization plugins
Plugin | Description
------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
[Twistlock AuthZ Broker](https://github.com/twistlock/authz) | A basic extendable authorization plugin that runs directly on the host or inside a container. This plugin allows you to define user policies that it evaluates during authorization. Basic authorization is provided if Docker daemon is started with the --tlsverify flag (username is extracted from the certificate common name).
## Troubleshooting a plugin
If you are having problems with Docker after loading a plugin, ask the authors
of the plugin for help. The Docker team may not be able to assist you.
## Writing a plugin
If you are interested in writing a plugin for Docker, or seeing how they work
under the hood, see the [docker plugins reference](plugin_api.md).

215
engine/extend/manifest.md
View File

@ -1,215 +0,0 @@
---
advisory: experimental
redirect_from:
- /engine/extend/
description: How develop and use a plugin with the managed plugin system
keywords:
- API, Usage, plugins, documentation, developer
title: Plugin manifest version 0 of plugin V2
---
This document outlines the format of the V0 plugin manifest. The plugin
manifest described herein was introduced in the Docker daemon (experimental version) in the [v1.12.0
release](https://github.com/docker/docker/commit/f37117045c5398fd3dca8016ea8ca0cb47e7312b).
Plugin manifests describe the various constituents of a docker plugin. Plugin
manifests can be serialized to JSON format with the following media types:
Manifest Type | Media Type
------------- | -------------
manifest | "application/vnd.docker.plugin.v0+json"
## *Manifest* Field Descriptions
Manifest provides the base accessible fields for working with V0 plugin format
in the registry.
- **`manifestVersion`** *string*
version of the plugin manifest (This version uses V0)
- **`description`** *string*
description of the plugin
- **`documentation`** *string*
link to the documentation about the plugin
- **`interface`** *PluginInterface*
interface implemented by the plugins, struct consisting of the following fields
- **`types`** *string array*
types indicate what interface(s) the plugin currently implements.
currently supported:
- **docker.volumedriver/1.0**
- **`socket`** *string*
socket is the name of the socket the engine should use to communicate with the plugins.
the socket will be created in `/run/docker/plugins`.
- **`entrypoint`** *string array*
entrypoint of the plugin, see [`ENTRYPOINT`](../reference/builder.md#entrypoint)
- **`workdir`** *string*
workdir of the plugin, see [`WORKDIR`](../reference/builder.md#workdir)
- **`network`** *PluginNetwork*
network of the plugin, struct consisting of the following fields
- **`type`** *string*
network type.
currently supported:
- **bridge**
- **host**
- **none**
- **`capabilities`** *array*
capabilities of the plugin (*Linux only*), see list [`here`](https://github.com/opencontainers/runc/blob/master/libcontainer/SPEC.md#security)
- **`mounts`** *PluginMount array*
mount of the plugin, struct consisting of the following fields, see [`MOUNTS`](https://github.com/opencontainers/runtime-spec/blob/master/config.md#mounts)
- **`name`** *string*
name of the mount.
- **`description`** *string*
description of the mount.
- **`source`** *string*
source of the mount.
- **`destination`** *string*
destination of the mount.
- **`type`** *string*
mount type.
- **`options`** *string array*
options of the mount.
- **`devices`** *PluginDevice array*
device of the plugin, (*Linux only*), struct consisting of the following fields, see [`DEVICES`](https://github.com/opencontainers/runtime-spec/blob/master/config-linux.md#devices)
- **`name`** *string*
name of the device.
- **`description`** *string*
description of the device.
- **`path`** *string*
path of the device.
- **`env`** *PluginEnv array*
env of the plugin, struct consisting of the following fields
- **`name`** *string*
name of the env.
- **`description`** *string*
description of the env.
- **`value`** *string*
value of the env.
- **`args`** *PluginArgs*
args of the plugin, struct consisting of the following fields
- **`name`** *string*
name of the env.
- **`description`** *string*
description of the env.
- **`value`** *string array*
values of the args.
## Example Manifest
*Example showing the 'tiborvass/no-remove' plugin manifest.*
```
{
"manifestVersion": "v0",
"description": "A test plugin for Docker",
"documentation": "https://docs.docker.com/engine/extend/plugins/",
"entrypoint": ["plugin-no-remove", "/data"],
"interface" : {
"types": ["docker.volumedriver/1.0"],
"socket": "plugins.sock"
},
"network": {
"type": "host"
},
"mounts": [
{
"source": "/data",
"destination": "/data",
"type": "bind",
"options": ["shared", "rbind"]
},
{
"destination": "/foobar",
"type": "tmpfs"
}
],
"args": {
"name": "args",
"description": "command line arguments",
"value": []
},
"env": [
{
"name": "DEBUG",
"description": "If set, prints debug messages",
"value": "1"
}
],
"devices": [
{
"name": "device",
"description": "a host device to mount",
"path": "/dev/cpu_dma_latency"
}
]
}
```

188
engine/extend/plugin_api.md
View File

@ -1,188 +0,0 @@
---
redirect_from:
- /extend/plugin_api/
description: 'How to write Docker plugins extensions '
keywords:
- API, Usage, plugins, documentation, developer
title: Docker plugin API
---
Docker plugins are out-of-process extensions which add capabilities to the
Docker Engine.
This document describes the Docker Engine plugin API. To view information on
plugins managed by Docker Engine currently in experimental status, refer to
[Docker Engine plugin system](index.md).
This page is intended for people who want to develop their own Docker plugin.
If you just want to learn about or use Docker plugins, look
[here](legacy_plugins.md).
## What plugins are
A plugin is a process running on the same or a different host as the docker daemon,
which registers itself by placing a file on the same docker host in one of the plugin
directories described in [Plugin discovery](plugin_api.md#plugin-discovery).
Plugins have human-readable names, which are short, lowercase strings. For
example, `flocker` or `weave`.
Plugins can run inside or outside containers. Currently running them outside
containers is recommended.
## Plugin discovery
Docker discovers plugins by looking for them in the plugin directory whenever a
user or container tries to use one by name.
There are three types of files which can be put in the plugin directory.
* `.sock` files are UNIX domain sockets.
* `.spec` files are text files containing a URL, such as `unix:///other.sock` or `tcp://localhost:8080`.
* `.json` files are text files containing a full json specification for the plugin.
Plugins with UNIX domain socket files must run on the same docker host, whereas
plugins with spec or json files can run on a different host if a remote URL is specified.
UNIX domain socket files must be located under `/run/docker/plugins`, whereas
spec files can be located either under `/etc/docker/plugins` or `/usr/lib/docker/plugins`.
The name of the file (excluding the extension) determines the plugin name.
For example, the `flocker` plugin might create a UNIX socket at
`/run/docker/plugins/flocker.sock`.
You can define each plugin into a separated subdirectory if you want to isolate definitions from each other.
For example, you can create the `flocker` socket under `/run/docker/plugins/flocker/flocker.sock` and only
mount `/run/docker/plugins/flocker` inside the `flocker` container.
Docker always searches for unix sockets in `/run/docker/plugins` first. It checks for spec or json files under
`/etc/docker/plugins` and `/usr/lib/docker/plugins` if the socket doesn't exist. The directory scan stops as
soon as it finds the first plugin definition with the given name.
### JSON specification
This is the JSON format for a plugin:
```json
{
"Name": "plugin-example",
"Addr": "https://example.com/docker/plugin",
"TLSConfig": {
"InsecureSkipVerify": false,
"CAFile": "/usr/shared/docker/certs/example-ca.pem",
"CertFile": "/usr/shared/docker/certs/example-cert.pem",
"KeyFile": "/usr/shared/docker/certs/example-key.pem",
}
}
```
The `TLSConfig` field is optional and TLS will only be verified if this configuration is present.
## Plugin lifecycle
Plugins should be started before Docker, and stopped after Docker. For
example, when packaging a plugin for a platform which supports `systemd`, you
might use [`systemd` dependencies](
http://www.freedesktop.org/software/systemd/man/systemd.unit.html#Before=) to
manage startup and shutdown order.
When upgrading a plugin, you should first stop the Docker daemon, upgrade the
plugin, then start Docker again.
## Plugin activation
When a plugin is first referred to -- either by a user referring to it by name
(e.g. `docker run --volume-driver=foo`) or a container already configured to
use a plugin being started -- Docker looks for the named plugin in the plugin
directory and activates it with a handshake. See Handshake API below.
Plugins are *not* activated automatically at Docker daemon startup. Rather,
they are activated only lazily, or on-demand, when they are needed.
## Systemd socket activation
Plugins may also be socket activated by `systemd`. The official [Plugins helpers](https://github.com/docker/go-plugins-helpers)
natively supports socket activation. In order for a plugin to be socket activated it needs
a `service` file and a `socket` file.
The `service` file (for example `/lib/systemd/system/your-plugin.service`):
```
[Unit]
Description=Your plugin
Before=docker.service
After=network.target your-plugin.socket
Requires=your-plugin.socket docker.service
[Service]
ExecStart=/usr/lib/docker/your-plugin
[Install]
WantedBy=multi-user.target
```
The `socket` file (for example `/lib/systemd/system/your-plugin.socket`):
```
[Unit]
Description=Your plugin
[Socket]
ListenStream=/run/docker/plugins/your-plugin.sock
[Install]
WantedBy=sockets.target
```
This will allow plugins to be actually started when the Docker daemon connects to
the sockets they're listening on (for instance the first time the daemon uses them
or if one of the plugin goes down accidentally).
## API design
The Plugin API is RPC-style JSON over HTTP, much like webhooks.
Requests flow *from* the Docker daemon *to* the plugin. So the plugin needs to
implement an HTTP server and bind this to the UNIX socket mentioned in the
"plugin discovery" section.
All requests are HTTP `POST` requests.
The API is versioned via an Accept header, which currently is always set to
`application/vnd.docker.plugins.v1+json`.
## Handshake API
Plugins are activated via the following "handshake" API call.
### /Plugin.Activate
**Request:** empty body
**Response:**
```
{
"Implements": ["VolumeDriver"]
}
```
Responds with a list of Docker subsystems which this plugin implements.
After activation, the plugin will then be sent events from this subsystem.
Possible values are:
* [`authz`](plugins_authorization.md)
* [`NetworkDriver`](plugins_network.md)
* [`VolumeDriver`](plugins_volume.md)
## Plugin retries
Attempts to call a method on a plugin are retried with an exponential backoff
for up to 30 seconds. This may help when packaging plugins as containers, since
it gives plugin containers a chance to start up before failing any user
containers which depend on them.
## Plugins helpers
To ease plugins development, we're providing an `sdk` for each kind of plugins
currently supported by Docker at [docker/go-plugins-helpers](https://github.com/docker/go-plugins-helpers).

248
engine/extend/plugins_authorization.md
View File

@ -1,248 +0,0 @@
---
redirect_from:
- /engine/extend/authorization/
description: How to create authorization plugins to manage access control to your Docker daemon.
keywords:
- security, authorization, authentication, docker, documentation, plugin, extend
title: Create an authorization plugin
---
This document describes the Docker Engine plugins generally available in Docker
Engine. To view information on plugins managed by Docker Engine currently in
experimental status, refer to [Docker Engine plugin system](index.md).
Docker's out-of-the-box authorization model is all or nothing. Any user with
permission to access the Docker daemon can run any Docker client command. The
same is true for callers using Docker's remote API to contact the daemon. If you
require greater access control, you can create authorization plugins and add
them to your Docker daemon configuration. Using an authorization plugin, a
Docker administrator can configure granular access policies for managing access
to Docker daemon.
Anyone with the appropriate skills can develop an authorization plugin. These
skills, at their most basic, are knowledge of Docker, understanding of REST, and
sound programming knowledge. This document describes the architecture, state,
and methods information available to an authorization plugin developer.
## Basic principles
Docker's [plugin infrastructure](plugin_api.md) enables
extending Docker by loading, removing and communicating with
third-party components using a generic API. The access authorization subsystem
was built using this mechanism.
Using this subsystem, you don't need to rebuild the Docker daemon to add an
authorization plugin. You can add a plugin to an installed Docker daemon. You do
need to restart the Docker daemon to add a new plugin.
An authorization plugin approves or denies requests to the Docker daemon based
on both the current authentication context and the command context. The
authentication context contains all user details and the authentication method.
The command context contains all the relevant request data.
Authorization plugins must follow the rules described in [Docker Plugin API](plugin_api.md).
Each plugin must reside within directories described under the
[Plugin discovery](plugin_api.md#plugin-discovery) section.
**Note**: the abbreviations `AuthZ` and `AuthN` mean authorization and authentication
respectively.
## Default user authorization mechanism
If TLS is enabled in the [Docker daemon](../security/https.md), the default user authorization flow extracts the user details from the certificate subject name.
That is, the `User` field is set to the client certificate subject common name, and the `AuthenticationMethod` field is set to `TLS`.
## Basic architecture
You are responsible for registering your plugin as part of the Docker daemon
startup. You can install multiple plugins and chain them together. This chain
can be ordered. Each request to the daemon passes in order through the chain.
Only when all the plugins grant access to the resource, is the access granted.
When an HTTP request is made to the Docker daemon through the CLI or via the
remote API, the authentication subsystem passes the request to the installed
authentication plugin(s). The request contains the user (caller) and command
context. The plugin is responsible for deciding whether to allow or deny the
request.
The sequence diagrams below depict an allow and deny authorization flow:
![Authorization Allow flow](images/authz_allow.png)
![Authorization Deny flow](images/authz_deny.png)
Each request sent to the plugin includes the authenticated user, the HTTP
headers, and the request/response body. Only the user name and the
authentication method used are passed to the plugin. Most importantly, no user
credentials or tokens are passed. Finally, not all request/response bodies
are sent to the authorization plugin. Only those request/response bodies where
the `Content-Type` is either `text/*` or `application/json` are sent.
For commands that can potentially hijack the HTTP connection (`HTTP
Upgrade`), such as `exec`, the authorization plugin is only called for the
initial HTTP requests. Once the plugin approves the command, authorization is
not applied to the rest of the flow. Specifically, the streaming data is not
passed to the authorization plugins. For commands that return chunked HTTP
response, such as `logs` and `events`, only the HTTP request is sent to the
authorization plugins.
During request/response processing, some authorization flows might
need to do additional queries to the Docker daemon. To complete such flows,
plugins can call the daemon API similar to a regular user. To enable these
additional queries, the plugin must provide the means for an administrator to
configure proper authentication and security policies.
## Docker client flows
To enable and configure the authorization plugin, the plugin developer must
support the Docker client interactions detailed in this section.
### Setting up Docker daemon
Enable the authorization plugin with a dedicated command line flag in the
`--authorization-plugin=PLUGIN_ID` format. The flag supplies a `PLUGIN_ID`
value. This value can be the plugin’s socket or a path to a specification file.
```bash
$ dockerd --authorization-plugin=plugin1 --authorization-plugin=plugin2,...
```
Docker's authorization subsystem supports multiple `--authorization-plugin` parameters.
### Calling authorized command (allow)
```bash
$ docker pull centos
...
f1b10cd84249: Pull complete
...
```
### Calling unauthorized command (deny)
```bash
$ docker pull centos
...
docker: Error response from daemon: authorization denied by plugin PLUGIN_NAME: volumes are not allowed.
```
### Error from plugins
```bash
$ docker pull centos
...
docker: Error response from daemon: plugin PLUGIN_NAME failed with error: AuthZPlugin.AuthZReq: Cannot connect to the Docker daemon. Is the docker daemon running on this host?.
```
## API schema and implementation
In addition to Docker's standard plugin registration method, each plugin
should implement the following two methods:
* `/AuthZPlugin.AuthZReq` This authorize request method is called before the Docker daemon processes the client request.
* `/AuthZPlugin.AuthZRes` This authorize response method is called before the response is returned from Docker daemon to the client.
#### /AuthZPlugin.AuthZReq
**Request**:
```json
{
"User": "The user identification",
"UserAuthNMethod": "The authentication method used",
"RequestMethod": "The HTTP method",
"RequestURI": "The HTTP request URI",
"RequestBody": "Byte array containing the raw HTTP request body",
"RequestHeader": "Byte array containing the raw HTTP request header as a map[string][]string "
}
```
**Response**:
```json
{
"Allow": "Determined whether the user is allowed or not",
"Msg": "The authorization message",
"Err": "The error message if things go wrong"
}
```
#### /AuthZPlugin.AuthZRes
**Request**:
```json
{
"User": "The user identification",
"UserAuthNMethod": "The authentication method used",
"RequestMethod": "The HTTP method",
"RequestURI": "The HTTP request URI",
"RequestBody": "Byte array containing the raw HTTP request body",
"RequestHeader": "Byte array containing the raw HTTP request header as a map[string][]string",
"ResponseBody": "Byte array containing the raw HTTP response body",
"ResponseHeader": "Byte array containing the raw HTTP response header as a map[string][]string",
"ResponseStatusCode":"Response status code"
}
```
**Response**:
```json
{
"Allow": "Determined whether the user is allowed or not",
"Msg": "The authorization message",
"Err": "The error message if things go wrong"
}
```
### Request authorization
Each plugin must support two request authorization messages formats, one from the daemon to the plugin and then from the plugin to the daemon. The tables below detail the content expected in each message.
#### Daemon -> Plugin
Name | Type | Description
-----------------------|-------------------|-------------------------------------------------------
User | string | The user identification
Authentication method | string | The authentication method used
Request method | enum | The HTTP method (GET/DELETE/POST)
Request URI | string | The HTTP request URI including API version (e.g., v.1.17/containers/json)
Request headers | map[string]string | Request headers as key value pairs (without the authorization header)
Request body | []byte | Raw request body
#### Plugin -> Daemon
Name | Type | Description
--------|--------|----------------------------------------------------------------------------------
Allow | bool | Boolean value indicating whether the request is allowed or denied
Msg | string | Authorization message (will be returned to the client in case the access is denied)
Err | string | Error message (will be returned to the client in case the plugin encounter an error. The string value supplied may appear in logs, so should not include confidential information)
### Response authorization
The plugin must support two authorization messages formats, one from the daemon to the plugin and then from the plugin to the daemon. The tables below detail the content expected in each message.
#### Daemon -> Plugin
Name | Type | Description
----------------------- |------------------ |----------------------------------------------------
User | string | The user identification
Authentication method | string | The authentication method used
Request method | string | The HTTP method (GET/DELETE/POST)
Request URI | string | The HTTP request URI including API version (e.g., v.1.17/containers/json)
Request headers | map[string]string | Request headers as key value pairs (without the authorization header)
Request body | []byte | Raw request body
Response status code | int | Status code from the docker daemon
Response headers | map[string]string | Response headers as key value pairs
Response body | []byte | Raw docker daemon response body
#### Plugin -> Daemon
Name | Type | Description
--------|--------|----------------------------------------------------------------------------------
Allow | bool | Boolean value indicating whether the response is allowed or denied
Msg | string | Authorization message (will be returned to the client in case the access is denied)
Err | string | Error message (will be returned to the client in case the plugin encounter an error. The string value supplied may appear in logs, so should not include confidential information)

67
engine/extend/plugins_network.md
View File

@ -1,67 +0,0 @@
---
description: Network driver plugins.
keywords:
- Examples, Usage, plugins, docker, documentation, user guide
title: Use network plugins
---
This document describes Docker Engine network driver plugins generally
available in Docker Engine. To view information on plugins
managed by Docker Engine, refer to [Docker Engine plugin system](index.md).
Docker Engine network plugins enable Engine deployments to be extended to
support a wide range of networking technologies, such as VXLAN, IPVLAN, MACVLAN
or something completely different. Network driver plugins are supported via the
LibNetwork project. Each plugin is implemented as a "remote driver" for
LibNetwork, which shares plugin infrastructure with Engine. Effectively, network
driver plugins are activated in the same way as other plugins, and use the same
kind of protocol.
## Network driver plugins and swarm mode
Docker 1.12 adds support for cluster management and orchestration called
[swarm mode](../swarm/index.md). Docker Engine running in swarm mode currently
only supports the built-in overlay driver for networking. Therefore existing
networking plugins will not work in swarm mode.
When you run Docker Engine outside of swarm mode, all networking plugins that
worked in Docker 1.11 will continue to function normally. They do not require
any modification.
## Using network driver plugins
The means of installing and running a network driver plugin depend on the
particular plugin. So, be sure to install your plugin according to the
instructions obtained from the plugin developer.
Once running however, network driver plugins are used just like the built-in
network drivers: by being mentioned as a driver in network-oriented Docker
commands. For example,
$ docker network create --driver weave mynet
Some network driver plugins are listed in [plugins](legacy_plugins.md)
The `mynet` network is now owned by `weave`, so subsequent commands
referring to that network will be sent to the plugin,
$ docker run --network=mynet busybox top
## Write a network plugin
Network plugins implement the [Docker plugin
API](/extend/plugin_api/) and the network plugin protocol
## Network plugin protocol
The network driver protocol, in addition to the plugin activation call, is
documented as part of libnetwork:
[https://github.com/docker/libnetwork/blob/master/docs/remote.md](https://github.com/docker/libnetwork/blob/master/docs/remote.md).
# Related Information
To interact with the Docker maintainers and other interested users, see the IRC channel `#docker-network`.
- [Docker networks feature overview](../userguide/networking/index.md)
- The [LibNetwork](https://github.com/docker/libnetwork) project

262
engine/extend/plugins_volume.md
View File

@ -1,262 +0,0 @@
---
description: How to manage data with external volume plugins
keywords:
- Examples, Usage, volume, docker, data, volumes, plugin, api
title: Write a volume plugin
---
Docker Engine volume plugins enable Engine deployments to be integrated with
external storage systems, such as Amazon EBS, and enable data volumes to persist
beyond the lifetime of a single Engine host. See the
[plugin documentation](legacy_plugins.md) for more information.
## Changelog
### 1.12.0
- Add `Status` field to `VolumeDriver.Get` response ([#21006](https://github.com/docker/docker/pull/21006#))
- Add `VolumeDriver.Capabilities` to get capabilities of the volume driver([#22077](https://github.com/docker/docker/pull/22077))
### 1.10.0
- Add `VolumeDriver.Get` which gets the details about the volume ([#16534](https://github.com/docker/docker/pull/16534))
- Add `VolumeDriver.List` which lists all volumes owned by the driver ([#16534](https://github.com/docker/docker/pull/16534))
### 1.8.0
- Initial support for volume driver plugins ([#14659](https://github.com/docker/docker/pull/14659))
## Command-line changes
A volume plugin makes use of the `-v` and `--volume-driver` flag on the `docker run` command. The `-v` flag accepts a volume name and the `--volume-driver` flag a driver type, for example:
$ docker run -ti -v volumename:/data --volume-driver=flocker busybox sh
This command passes the `volumename` through to the volume plugin as a
user-given name for the volume. The `volumename` must not begin with a `/`.
By having the user specify a `volumename`, a plugin can associate the volume
with an external volume beyond the lifetime of a single container or container
host. This can be used, for example, to move a stateful container from one
server to another.
By specifying a `volumedriver` in conjunction with a `volumename`, users can use plugins such as [Flocker](https://clusterhq.com/docker-plugin/) to manage volumes external to a single host, such as those on EBS.
## Create a VolumeDriver
The container creation endpoint (`/containers/create`) accepts a `VolumeDriver`
field of type `string` allowing to specify the name of the driver. It's default
value of `"local"` (the default driver for local volumes).
## Volume plugin protocol
If a plugin registers itself as a `VolumeDriver` when activated, then it is
expected to provide writeable paths on the host filesystem for the Docker
daemon to provide to containers to consume.
The Docker daemon handles bind-mounting the provided paths into user
containers.
> **Note**: Volume plugins should *not* write data to the `/var/lib/docker/`
> directory, including `/var/lib/docker/volumes`. The `/var/lib/docker/`
> directory is reserved for Docker.
### /VolumeDriver.Create
**Request**:
```json
{
"Name": "volume_name",
"Opts": {}
}
```
Instruct the plugin that the user wants to create a volume, given a user
specified volume name. The plugin does not need to actually manifest the
volume on the filesystem yet (until Mount is called).
Opts is a map of driver specific options passed through from the user request.
**Response**:
```json
{
"Err": ""
}
```
Respond with a string error if an error occurred.
### /VolumeDriver.Remove
**Request**:
```json
{
"Name": "volume_name"
}
```
Delete the specified volume from disk. This request is issued when a user invokes `docker rm -v` to remove volumes associated with a container.
**Response**:
```json
{
"Err": ""
}
```
Respond with a string error if an error occurred.
### /VolumeDriver.Mount
**Request**:
```json
{
"Name": "volume_name",
"ID": "b87d7442095999a92b65b3d9691e697b61713829cc0ffd1bb72e4ccd51aa4d6c"
}
```
Docker requires the plugin to provide a volume, given a user specified volume
name. This is called once per container start. If the same volume_name is requested
more than once, the plugin may need to keep track of each new mount request and provision
at the first mount request and deprovision at the last corresponding unmount request.
`ID` is a unique ID for the caller that is requesting the mount.
**Response**:
```json
{
"Mountpoint": "/path/to/directory/on/host",
"Err": ""
}
```
Respond with the path on the host filesystem where the volume has been made
available, and/or a string error if an error occurred.
### /VolumeDriver.Path
**Request**:
```json
{
"Name": "volume_name"
}
```
Docker needs reminding of the path to the volume on the host.
**Response**:
```json
{
"Mountpoint": "/path/to/directory/on/host",
"Err": ""
}
```
Respond with the path on the host filesystem where the volume has been made
available, and/or a string error if an error occurred. `Mountpoint` is optional,
however the plugin may be queried again later if one is not provided.
### /VolumeDriver.Unmount
**Request**:
```json
{
"Name": "volume_name",
"ID": "b87d7442095999a92b65b3d9691e697b61713829cc0ffd1bb72e4ccd51aa4d6c"
}
```
Indication that Docker no longer is using the named volume. This is called once
per container stop. Plugin may deduce that it is safe to deprovision it at
this point.
`ID` is a unique ID for the caller that is requesting the mount.
**Response**:
```json
{
"Err": ""
}
```
Respond with a string error if an error occurred.
### /VolumeDriver.Get
**Request**:
```json
{
"Name": "volume_name"
}
```
Get the volume info.
**Response**:
```json
{
"Volume": {
"Name": "volume_name",
"Mountpoint": "/path/to/directory/on/host",
"Status": {}
},
"Err": ""
}
```
Respond with a string error if an error occurred. `Mountpoint` and `Status` are
optional.
### /VolumeDriver.List
**Request**:
```json
{}
```
Get the list of volumes registered with the plugin.
**Response**:
```json
{
"Volumes": [
{
"Name": "volume_name",
"Mountpoint": "/path/to/directory/on/host"
}
],
"Err": ""
}
```
Respond with a string error if an error occurred. `Mountpoint` is optional.
### /VolumeDriver.Capabilities
**Request**:
```json
{}
```
Get the list of capabilities the driver supports.
The driver is not required to implement this endpoint, however in such cases
the default values will be taken.
**Response**:
```json
{
"Capabilities": {
"Scope": "global"
}
}
```
Supported scopes are `global` and `local`. Any other value in `Scope` will be
ignored and assumed to be `local`. Scope allows cluster managers to handle the
volume differently, for instance with a scope of `global`, the cluster manager
knows it only needs to create the volume once instead of on every engine. More
capabilities may be added in the future.

13
engine/reference/api/README.md
View File

@ -1,13 +0,0 @@
---
published: false
---
This directory holds the authoritative specifications of APIs defined and implemented by Docker. Currently this includes:
* The remote API by which a docker node can be queried over HTTP
* The registry API by which a docker node can download and upload
images for storage and sharing
* The index search API by which a docker node can search the public
index for images to download
* The docker.io OAuth and accounts API which 3rd party services can
use to access account information

BIN
engine/reference/api/_static/io_oauth_authorization_page.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 38 KiB

12
engine/reference/api/docker-io_api.md
View File

@ -1,12 +0,0 @@
---
redirect_from:
- /reference/api/docker-io_api/
description: API Documentation for the Docker Hub API
published: false
keywords:
- API, Docker, index, REST, documentation, Docker Hub, registry
title: Docker Hub API
---
This API is deprecated as of 1.7. To view the old version, see the [Docker Hub
API](/v1.7/docker/reference/api/docker-io_api/) in the 1.7 documentation.

273
engine/reference/api/docker_io_accounts_api.md
View File

@ -1,273 +0,0 @@
---
redirect_from:
- /reference/api/docker_io_accounts_api/
description: API Documentation for docker.io accounts.
keywords:
- API, Docker, accounts, REST, documentation
title: Accounts API for docker.io
---
## Get a single user
`GET /api/v1.1/users/:username/`
Get profile info for the specified user.
Parameters:
- **username** – username of the user whose profile info is being
requested.
Request Headers:
- **Authorization** – required authentication credentials of
either type HTTP Basic or OAuth Bearer Token.
Status Codes:
- **200** – success, user data returned.
- **401** – authentication error.
- **403** – permission error, authenticated user must be the user
whose data is being requested, OAuth access tokens must have
`profile_read` scope.
- **404** – the specified username does not exist.
**Example request**:
GET /api/v1.1/users/janedoe/ HTTP/1.1
Host: www.docker.io
Accept: application/json
Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=
**Example response**:
HTTP/1.1 200 OK
Content-Type: application/json
{
"id": 2,
"username": "janedoe",
"url": "https://www.docker.io/api/v1.1/users/janedoe/",
"date_joined": "2014-02-12T17:58:01.431312Z",
"type": "User",
"full_name": "Jane Doe",
"location": "San Francisco, CA",
"company": "Success, Inc.",
"profile_url": "https://docker.io/",
"gravatar_url": "https://secure.gravatar.com/avatar/0212b397124be4acd4e7dea9aa357.jpg?s=80&r=g&d=mm"
"email": "jane.doe@example.com",
"is_active": true
}
## Update a single user
`PATCH /api/v1.1/users/:username/`
Update profile info for the specified user.
Parameters:
- **username** – username of the user whose profile info is being
updated.
Json Parameters:
- **full_name** (*string*) – (optional) the new name of the user.
- **location** (*string*) – (optional) the new location.
- **company** (*string*) – (optional) the new company of the user.
- **profile_url** (*string*) – (optional) the new profile url.
- **gravatar_email** (*string*) – (optional) the new Gravatar
email address.
Request Headers:
- **Authorization** – required authentication credentials of
either type HTTP Basic or OAuth Bearer Token.
- **Content-Type** – MIME Type of post data. JSON, url-encoded
form data, etc.
Status Codes:
- **200** – success, user data updated.
- **400** – post data validation error.
- **401** – authentication error.
- **403** – permission error, authenticated user must be the user
whose data is being updated, OAuth access tokens must have
`profile_write` scope.
- **404** – the specified username does not exist.
**Example request**:
PATCH /api/v1.1/users/janedoe/ HTTP/1.1
Host: www.docker.io
Accept: application/json
Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=
{
"location": "Private Island",
"profile_url": "http://janedoe.com/",
"company": "Retired",
}
**Example response**:
HTTP/1.1 200 OK
Content-Type: application/json
{
"id": 2,
"username": "janedoe",
"url": "https://www.docker.io/api/v1.1/users/janedoe/",
"date_joined": "2014-02-12T17:58:01.431312Z",
"type": "User",
"full_name": "Jane Doe",
"location": "Private Island",
"company": "Retired",
"profile_url": "http://janedoe.com/",
"gravatar_url": "https://secure.gravatar.com/avatar/0212b397124be4acd4e7dea9aa357.jpg?s=80&r=g&d=mm"
"email": "jane.doe@example.com",
"is_active": true
}
## List email addresses for a user
`GET /api/v1.1/users/:username/emails/`
List email info for the specified user.
Parameters:
- **username** – username of the user whose profile info is being
updated.
Request Headers:
- **Authorization** – required authentication credentials of
either type HTTP Basic or OAuth Bearer Token
Status Codes:
- **200** – success, user data updated.
- **401** – authentication error.
- **403** – permission error, authenticated user must be the user
whose data is being requested, OAuth access tokens must have
`email_read` scope.
- **404** – the specified username does not exist.
**Example request**:
GET /api/v1.1/users/janedoe/emails/ HTTP/1.1
Host: www.docker.io
Accept: application/json
Authorization: Bearer zAy0BxC1wDv2EuF3tGs4HrI6qJp6KoL7nM
**Example response**:
HTTP/1.1 200 OK
Content-Type: application/json
[
{
"email": "jane.doe@example.com",
"verified": true,
"primary": true
}
]
## Add email address for a user
`POST /api/v1.1/users/:username/emails/`
Add a new email address to the specified user's account. The email
address must be verified separately, a confirmation email is not
automatically sent.
Json Parameters:
- **email** (*string*) – email address to be added.
Request Headers:
- **Authorization** – required authentication credentials of
either type HTTP Basic or OAuth Bearer Token.
- **Content-Type** – MIME Type of post data. JSON, url-encoded
form data, etc.
Status Codes:
- **201** – success, new email added.
- **400** – data validation error.
- **401** – authentication error.
- **403** – permission error, authenticated user must be the user
whose data is being requested, OAuth access tokens must have
`email_write` scope.
- **404** – the specified username does not exist.
**Example request**:
POST /api/v1.1/users/janedoe/emails/ HTTP/1.1
Host: www.docker.io
Accept: application/json
Content-Type: application/json
Authorization: Bearer zAy0BxC1wDv2EuF3tGs4HrI6qJp6KoL7nM
{
"email": "jane.doe+other@example.com"
}
**Example response**:
HTTP/1.1 201 Created
Content-Type: application/json
{
"email": "jane.doe+other@example.com",
"verified": false,
"primary": false
}
## Delete email address for a user
`DELETE /api/v1.1/users/:username/emails/`
Delete an email address from the specified user's account. You
cannot delete a user's primary email address.
Json Parameters:
- **email** (*string*) – email address to be deleted.
Request Headers:
- **Authorization** – required authentication credentials of
either type HTTP Basic or OAuth Bearer Token.
- **Content-Type** – MIME Type of post data. JSON, url-encoded
form data, etc.
Status Codes:
- **204** – success, email address removed.
- **400** – validation error.
- **401** – authentication error.
- **403** – permission error, authenticated user must be the user
whose data is being requested, OAuth access tokens must have
`email_write` scope.
- **404** – the specified username or email address does not
exist.
**Example request**:
DELETE /api/v1.1/users/janedoe/emails/ HTTP/1.1
Host: www.docker.io
Accept: application/json
Content-Type: application/json
Authorization: Bearer zAy0BxC1wDv2EuF3tGs4HrI6qJp6KoL7nM
{
"email": "jane.doe+other@example.com"
}
**Example response**:
HTTP/1.1 204 NO CONTENT
Content-Length: 0

271
engine/reference/api/docker_remote_api.md
View File

@ -1,271 +0,0 @@
---
redirect_from:
- /reference/api/docker_remote_api/
description: API Documentation for Docker
keywords:
- API, Docker, rcli, REST, documentation
title: Docker Remote API
---
Docker's Remote API uses an open schema model. In this model, unknown
properties in incoming messages are ignored. Client applications need to take
this behavior into account to ensure they do not break when talking to newer
Docker daemons.
The API tends to be REST, but for some complex commands, like attach or pull,
the HTTP connection is hijacked to transport STDOUT, STDIN, and STDERR.
By default the Docker daemon listens on `unix:///var/run/docker.sock` and the
client must have `root` access to interact with the daemon. If a group named
`docker` exists on your system, `docker` applies ownership of the socket to the
group.
To connect to the Docker daemon with cURL you need to use cURL 7.40 or
later, as these versions have the `--unix-socket` flag available. To
run `curl` against the daemon on the default socket, use the
following:
curl --unix-socket /var/run/docker.sock http:/containers/json
If you have bound the Docker daemon to a different socket path or TCP
port, you would reference that in your cURL rather than the
default.
The current version of the API is v1.24 which means calling `/info` is the same
as calling `/v1.24/info`. To call an older version of the API use
`/v1.23/info`. If a newer daemon is installed, new properties may be returned
even when calling older versions of the API.
Use the table below to find the API version for a Docker version:
Docker version | API version | Changes
----------------|------------------------------------|------------------------------------------------------
1.12.x | [1.24](docker_remote_api_v1.24.md) | [API changes](docker_remote_api.md#v1-24-api-changes)
1.11.x | [1.23](docker_remote_api_v1.23.md) | [API changes](docker_remote_api.md#v1-23-api-changes)
1.10.x | [1.22](docker_remote_api_v1.22.md) | [API changes](docker_remote_api.md#v1-22-api-changes)
1.9.x | [1.21](docker_remote_api_v1.21.md) | [API changes](docker_remote_api.md#v1-21-api-changes)
1.8.x | [1.20](docker_remote_api_v1.20.md) | [API changes](docker_remote_api.md#v1-20-api-changes)
1.7.x | [1.19](docker_remote_api_v1.19.md) | [API changes](docker_remote_api.md#v1-19-api-changes)
1.6.x | [1.18](docker_remote_api_v1.18.md) | [API changes](docker_remote_api.md#v1-18-api-changes)
Refer to the [GitHub repository](
https://github.com/docker/docker/tree/master/docs/reference/api) for
older releases.
## Authentication
Authentication configuration is handled client side, so the
client has to send the `authConfig` as a `POST` in `/images/(name)/push`. The
`authConfig`, set as the `X-Registry-Auth` header, is currently a Base64 encoded
(JSON) string with the following structure:
```JSON
{"username": "string", "password": "string", "email": "string",
"serveraddress" : "string", "auth": ""}
```
Callers should leave the `auth` empty. The `serveraddress` is a domain/ip
without protocol. Throughout this structure, double quotes are required.
## Using Docker Machine with the API
If you are using `docker-machine`, the Docker daemon is on a host that
uses an encrypted TCP socket using TLS. This means, for Docker Machine users,
you need to add extra parameters to `curl` or `wget` when making test
API requests, for example:
```
curl --insecure \
--cert $DOCKER_CERT_PATH/cert.pem \
--key $DOCKER_CERT_PATH/key.pem \
https://YOUR_VM_IP:2376/images/json
wget --no-check-certificate --certificate=$DOCKER_CERT_PATH/cert.pem \
--private-key=$DOCKER_CERT_PATH/key.pem \
https://YOUR_VM_IP:2376/images/json -O - -q
```
## Docker Events
The following diagram depicts the container states accessible through the API.
![States](images/event_state.png)
Some container-related events are not affected by container state, so they are not included in this diagram. These events are:
* **export** emitted by `docker export`
* **exec_create** emitted by `docker exec`
* **exec_start** emitted by `docker exec` after **exec_create**
* **detach** emitted when client is detached from container process
* **exec_detach** emitted when client is detached from exec process
Running `docker rmi` emits an **untag** event when removing an image name. The `rmi` command may also emit **delete** events when images are deleted by ID directly or by deleting the last tag referring to the image.
> **Acknowledgment**: This diagram and the accompanying text were used with the permission of Matt Good and Gilder Labs. See Matt's original blog post [Docker Events Explained](https://gliderlabs.com/blog/2015/04/14/docker-events-explained/).
## Version history
This section lists each version from latest to oldest. Each listing includes a link to the full documentation set and the changes relevant in that release.
### v1.24 API changes
[Docker Remote API v1.24](docker_remote_api_v1.24.md) documentation
* `POST /containers/create` now takes `StorageOpt` field.
* `GET /info` now returns `SecurityOptions` field, showing if `apparmor`, `seccomp`, or `selinux` is supported.
* `GET /info` no longer returns the `ExecutionDriver` property. This property was no longer used after integration
with ContainerD in Docker 1.11.
* `GET /networks` now supports filtering by `label` and `driver`.
* `GET /containers/json` now supports filtering containers by `network` name or id.
* `POST /containers/create` now takes `IOMaximumBandwidth` and `IOMaximumIOps` fields. Windows daemon only.
* `POST /containers/create` now returns an HTTP 400 "bad parameter" message
if no command is specified (instead of an HTTP 500 "server error")
* `GET /images/search` now takes a `filters` query parameter.
* `GET /events` now supports a `reload` event that is emitted when the daemon configuration is reloaded.
* `GET /events` now supports filtering by daemon name or ID.
* `GET /events` now supports a `detach` event that is emitted on detaching from container process.
* `GET /events` now supports an `exec_detach ` event that is emitted on detaching from exec process.
* `GET /images/json` now supports filters `since` and `before`.
* `POST /containers/(id or name)/start` no longer accepts a `HostConfig`.
* `POST /images/(name)/tag` no longer has a `force` query parameter.
* `GET /images/search` now supports maximum returned search results `limit`.
* `POST /containers/{name:.*}/copy` is now removed and errors out starting from this API version.
* API errors are now returned as JSON instead of plain text.
* `POST /containers/create` and `POST /containers/(id)/start` allow you to configure kernel parameters (sysctls) for use in the container.
* `POST /containers/<container ID>/exec` and `POST /exec/<exec ID>/start`
no longer expects a "Container" field to be present. This property was not used
and is no longer sent by the docker client.
* `POST /containers/create/` now validates the hostname (should be a valid RFC 1123 hostname).
* `POST /containers/create/` `HostConfig.PidMode` field now accepts `container:<name|id>`,
to have the container join the PID namespace of an existing container.
### v1.23 API changes
[Docker Remote API v1.23](docker_remote_api_v1.23.md) documentation
* `GET /containers/json` returns the state of the container, one of `created`, `restarting`, `running`, `paused`, `exited` or `dead`.
* `GET /containers/json` returns the mount points for the container.
* `GET /networks/(name)` now returns an `Internal` field showing whether the network is internal or not.
* `GET /networks/(name)` now returns an `EnableIPv6` field showing whether the network has ipv6 enabled or not.
* `POST /containers/(name)/update` now supports updating container's restart policy.
* `POST /networks/create` now supports enabling ipv6 on the network by setting the `EnableIPv6` field (doing this with a label will no longer work).
* `GET /info` now returns `CgroupDriver` field showing what cgroup driver the daemon is using; `cgroupfs` or `systemd`.
* `GET /info` now returns `KernelMemory` field, showing if "kernel memory limit" is supported.
* `POST /containers/create` now takes `PidsLimit` field, if the kernel is >= 4.3 and the pids cgroup is supported.
* `GET /containers/(id or name)/stats` now returns `pids_stats`, if the kernel is >= 4.3 and the pids cgroup is supported.
* `POST /containers/create` now allows you to override usernamespaces remapping and use privileged options for the container.
* `POST /containers/create` now allows specifying `nocopy` for named volumes, which disables automatic copying from the container path to the volume.
* `POST /auth` now returns an `IdentityToken` when supported by a registry.
* `POST /containers/create` with both `Hostname` and `Domainname` fields specified will result in the container's hostname being set to `Hostname`, rather than `Hostname.Domainname`.
* `GET /volumes` now supports more filters, new added filters are `name` and `driver`.
* `GET /containers/(id or name)/logs` now accepts a `details` query parameter to stream the extra attributes that were provided to the containers `LogOpts`, such as environment variables and labels, with the logs.
* `POST /images/load` now returns progress information as a JSON stream, and has a `quiet` query parameter to suppress progress details.
### v1.22 API changes
[Docker Remote API v1.22](docker_remote_api_v1.22.md) documentation
* `POST /container/(name)/update` updates the resources of a container.
* `GET /containers/json` supports filter `isolation` on Windows.
* `GET /containers/json` now returns the list of networks of containers.
* `GET /info` Now returns `Architecture` and `OSType` fields, providing information
about the host architecture and operating system type that the daemon runs on.
* `GET /networks/(name)` now returns a `Name` field for each container attached to the network.
* `GET /version` now returns the `BuildTime` field in RFC3339Nano format to make it
consistent with other date/time values returned by the API.
* `AuthConfig` now supports a `registrytoken` for token based authentication
* `POST /containers/create` now has a 4M minimum value limit for `HostConfig.KernelMemory`
* Pushes initiated with `POST /images/(name)/push` and pulls initiated with `POST /images/create`
will be cancelled if the HTTP connection making the API request is closed before
the push or pull completes.
* `POST /containers/create` now allows you to set a read/write rate limit for a
device (in bytes per second or IO per second).
* `GET /networks` now supports filtering by `name`, `id` and `type`.
* `POST /containers/create` now allows you to set the static IPv4 and/or IPv6 address for the container.
* `POST /networks/(id)/connect` now allows you to set the static IPv4 and/or IPv6 address for the container.
* `GET /info` now includes the number of containers running, stopped, and paused.
* `POST /networks/create` now supports restricting external access to the network by setting the `Internal` field.
* `POST /networks/(id)/disconnect` now includes a `Force` option to forcefully disconnect a container from network
* `GET /containers/(id)/json` now returns the `NetworkID` of containers.
* `POST /networks/create` Now supports an options field in the IPAM config that provides options
for custom IPAM plugins.
* `GET /networks/{network-id}` Now returns IPAM config options for custom IPAM plugins if any
are available.
* `GET /networks/<network-id>` now returns subnets info for user-defined networks.
* `GET /info` can now return a `SystemStatus` field useful for returning additional information about applications
that are built on top of engine.
### v1.21 API changes
[Docker Remote API v1.21](docker_remote_api_v1.21.md) documentation
* `GET /volumes` lists volumes from all volume drivers.
* `POST /volumes/create` to create a volume.
* `GET /volumes/(name)` get low-level information about a volume.
* `DELETE /volumes/(name)` remove a volume with the specified name.
* `VolumeDriver` was moved from `config` to `HostConfig` to make the configuration portable.
* `GET /images/(name)/json` now returns information about an image's `RepoTags` and `RepoDigests`.
* The `config` option now accepts the field `StopSignal`, which specifies the signal to use to kill a container.
* `GET /containers/(id)/stats` will return networking information respectively for each interface.
* The `HostConfig` option now includes the `DnsOptions` field to configure the container's DNS options.
* `POST /build` now optionally takes a serialized map of build-time variables.
* `GET /events` now includes a `timenano` field, in addition to the existing `time` field.
* `GET /events` now supports filtering by image and container labels.
* `GET /info` now lists engine version information and return the information of `CPUShares` and `Cpuset`.
* `GET /containers/json` will return `ImageID` of the image used by container.
* `POST /exec/(name)/start` will now return an HTTP 409 when the container is either stopped or paused.
* `GET /containers/(name)/json` now accepts a `size` parameter. Setting this parameter to '1' returns container size information in the `SizeRw` and `SizeRootFs` fields.
* `GET /containers/(name)/json` now returns a `NetworkSettings.Networks` field,
detailing network settings per network. This field deprecates the
`NetworkSettings.Gateway`, `NetworkSettings.IPAddress`,
`NetworkSettings.IPPrefixLen`, and `NetworkSettings.MacAddress` fields, which
are still returned for backward-compatibility, but will be removed in a future version.
* `GET /exec/(id)/json` now returns a `NetworkSettings.Networks` field,
detailing networksettings per network. This field deprecates the
`NetworkSettings.Gateway`, `NetworkSettings.IPAddress`,
`NetworkSettings.IPPrefixLen`, and `NetworkSettings.MacAddress` fields, which
are still returned for backward-compatibility, but will be removed in a future version.
* The `HostConfig` option now includes the `OomScoreAdj` field for adjusting the
badness heuristic. This heuristic selects which processes the OOM killer kills
under out-of-memory conditions.
### v1.20 API changes
[Docker Remote API v1.20](docker_remote_api_v1.20.md) documentation
* `GET /containers/(id)/archive` get an archive of filesystem content from a container.
* `PUT /containers/(id)/archive` upload an archive of content to be extracted to
an existing directory inside a container's filesystem.
* `POST /containers/(id)/copy` is deprecated in favor of the above `archive`
endpoint which can be used to download files and directories from a container.
* The `hostConfig` option now accepts the field `GroupAdd`, which specifies a
list of additional groups that the container process will run as.
### v1.19 API changes
[Docker Remote API v1.19](docker_remote_api_v1.19.md) documentation
* When the daemon detects a version mismatch with the client, usually when
the client is newer than the daemon, an HTTP 400 is now returned instead
of a 404.
* `GET /containers/(id)/stats` now accepts `stream` bool to get only one set of stats and disconnect.
* `GET /containers/(id)/logs` now accepts a `since` timestamp parameter.
* `GET /info` The fields `Debug`, `IPv4Forwarding`, `MemoryLimit`, and
`SwapLimit` are now returned as boolean instead of as an int. In addition, the
end point now returns the new boolean fields `CpuCfsPeriod`, `CpuCfsQuota`, and
`OomKillDisable`.
* The `hostConfig` option now accepts the fields `CpuPeriod` and `CpuQuota`
* `POST /build` accepts `cpuperiod` and `cpuquota` options
### v1.18 API changes
[Docker Remote API v1.18](docker_remote_api_v1.18.md) documentation
* `GET /version` now returns `Os`, `Arch` and `KernelVersion`.
* `POST /containers/create` and `POST /containers/(id)/start`allow you to set ulimit settings for use in the container.
* `GET /info` now returns `SystemTime`, `HttpProxy`,`HttpsProxy` and `NoProxy`.
* `GET /images/json` added a `RepoDigests` field to include image digest information.
* `POST /build` can now set resource constraints for all containers created for the build.
* `CgroupParent` can be passed in the host config to setup container cgroups under a specific cgroup.
* `POST /build` closing the HTTP request cancels the build
* `POST /containers/(id)/exec` includes `Warnings` field to response.

2145
engine/reference/api/docker_remote_api_v1.18.md
View File

File diff suppressed because it is too large Load Diff

2225
engine/reference/api/docker_remote_api_v1.19.md
View File

File diff suppressed because it is too large Load Diff

2380
engine/reference/api/docker_remote_api_v1.20.md
View File

File diff suppressed because it is too large Load Diff

2951
engine/reference/api/docker_remote_api_v1.21.md
View File

File diff suppressed because it is too large Load Diff

3287
engine/reference/api/docker_remote_api_v1.22.md
View File

File diff suppressed because it is too large Load Diff

3403
engine/reference/api/docker_remote_api_v1.23.md
View File

File diff suppressed because it is too large Load Diff

5259
engine/reference/api/docker_remote_api_v1.24.md
View File

File diff suppressed because it is too large Load Diff

5295
engine/reference/api/docker_remote_api_v1.25.md
View File

File diff suppressed because it is too large Load Diff

15
engine/reference/api/hub_registry_spec.md
View File

@ -1,15 +0,0 @@
---
redirect_from:
- /reference/api/hub_registry_spec/
description: Documentation for docker Registry and Registry API
published: false
keywords:
- docker, registry, api, hub
title: Docker Hub and Registry v1
---
This API is deprecated as of 1.7. To view the old version, see the [go
here](/v1.7/docker/reference/api/hub_registry_spec/) in
the 1.7 documentation. If you want an overview of the current features in
Docker Hub or other image management features see the [image management
overview](../../userguide/eng-image/image_management.md) in the current documentation set.

1
engine/reference/api/images/event_state.gliffy
View File

File diff suppressed because one or more lines are too long

BIN
engine/reference/api/images/event_state.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 76 KiB

11
engine/reference/api/index.md
View File

@ -1,11 +0,0 @@
---
redirect_from:
- /reference/api/
description: Reference
keywords:
- Engine
title: API reference
---
* [Docker Remote API](docker_remote_api.md)
* [Docker Remote API client libraries](remote_api_client_libraries.md)

130
engine/reference/api/remote_api_client_libraries.md
View File

@ -1,130 +0,0 @@
---
redirect_from:
- /reference/api/remote_api_client_libraries/
description: Various client libraries available to use with the Docker remote API
keywords:
- API, Docker, index, registry, REST, documentation, clients, C#, Erlang, Go, Groovy, Java, JavaScript, Perl, PHP, Python, Ruby, Rust, Scala
title: Docker Remote API client libraries
---
These libraries make it easier to build applications on top of the Docker
Remote API with various programming languages. They have not been tested by the
Docker maintainers for compatibility, so if you run into any issues, file them
with the library maintainers.
<table border="1" class="docutils">
<colgroup>
<col width="29%">
<col width="23%">
<col width="48%">
</colgroup>
<thead valign="bottom">
<tr>
<th class="head">Language/Framework</th>
<th class="head">Name</th>
<th class="head">Repository</th>
</tr>
</thead>
<tbody valign = "top">
<tr>
<td>C#</td>
<td>Docker.DotNet</td>
<td><a class="reference external" href="https://github.com/ahmetalpbalkan/Docker.DotNet">https://github.com/ahmetalpbalkan/Docker.DotNet</a></td>
</tr>
<tr>
<td>C++</td>
<td>lasote/docker_client</td>
<td><a class="reference external" href="https://github.com/lasote/docker_client">https://github.com/lasote/docker_client</a></td>
</tr>
<tr>
<td>Erlang</td>
<td>erldocker</td>
<td><a class="reference external" href="https://github.com/proger/erldocker">https://github.com/proger/erldocker</a></td>
</tr>
<tr>
<td>Dart</td>
<td>bwu_docker</td>
<td><a class="reference external" href="https://github.com/bwu-dart/bwu_docker">https://github.com/bwu-dart/bwu_docker</a></td>
</tr>
<tr>
<td>Go</td>
<td>Docker Go client</td>
<td><a class="reference external" href="https://godoc.org/github.com/docker/docker/client">https://godoc.org/github.com/docker/docker/client</a></td>
</tr>
<tr>
<td>Gradle</td>
<td>gradle-docker-plugin</td>
<td><a class="reference external" href="https://github.com/gesellix/gradle-docker-plugin">https://github.com/gesellix/gradle-docker-plugin</a></td>
</tr>
<tr>
<td>Groovy</td>
<td>docker-client</td>
<td><a class="reference external" href="https://github.com/gesellix/docker-client">https://github.com/gesellix/docker-client</a></td>
</tr>
<tr>
<td>Haskell</td>
<td>docker-hs</td>
<td><a class="reference external" href="https://github.com/denibertovic/docker-hs">https://github.com/denibertovic/docker-hs</a></td>
</tr>
<tr>
<td>HTML (Web Components)</td>
<td>docker-elements</td>
<td><a class="reference external" href="https://github.com/kapalhq/docker-elements">https://github.com/kapalhq/docker-elements</a></td>
</tr>
<tr>
<td>Java</td>
<td>docker-java</td>
<td><a class="reference external" href="https://github.com/docker-java/docker-java">https://github.com/docker-java/docker-java</a></td>
</tr>
<tr>
<td>Java</td>
<td>docker-client</td>
<td><a class="reference external" href="https://github.com/spotify/docker-client">https://github.com/spotify/docker-client</a></td>
</tr>
<tr>
<td>NodeJS</td>
<td>dockerode</td>
<td><a class="reference external" href="https://github.com/apocas/dockerode">https://github.com/apocas/dockerode</a></td>
</tr>
<tr>
<td>Perl</td>
<td>Eixo::Docker</td>
<td><a class="reference external" href="https://github.com/alambike/eixo-docker">https://github.com/alambike/eixo-docker</a></td>
</tr>
<tr>
<td>PHP</td>
<td>Docker-PHP</td>
<td><a class="reference external" href="https://github.com/docker-php/docker-php">https://github.com/docker-php/docker-php</a></td>
</tr>
<tr>
<td>Python</td>
<td>docker-py</td>
<td><a class="reference external" href="https://github.com/docker/docker-py">https://github.com/docker/docker-py</a></td>
</tr>
<tr>
<td>Ruby</td>
<td>docker-api</td>
<td><a class="reference external" href="https://github.com/swipely/docker-api">https://github.com/swipely/docker-api</a></td>
</tr>
<tr>
<td>Rust</td>
<td>docker-rust</td>
<td><a class="reference external" href="https://github.com/abh1nav/docker-rust">https://github.com/abh1nav/docker-rust</a></td>
</tr>
<tr>
<td>Rust</td>
<td>shiplift</td>
<td><a class="reference external" href="https://github.com/softprops/shiplift">https://github.com/softprops/shiplift</a></td>
</tr>
<tr>
<td>Scala</td>
<td>tugboat</td>
<td><a class="reference external" href="https://github.com/softprops/tugboat">https://github.com/softprops/tugboat</a></td>
</tr>
<tr>
<td>Scala</td>
<td>reactive-docker</td>
<td><a class="reference external" href="https://github.com/almoehi/reactive-docker">https://github.com/almoehi/reactive-docker</a></td>
</tr>
</tbody>
</table>

1719
engine/reference/builder.md
View File

File diff suppressed because it is too large Load Diff

124
engine/reference/commandline/attach.md
View File

@ -1,124 +0,0 @@
---
redirect_from:
- /reference/commandline/attach/
description: The attach command description and usage
keywords:
- attach, running, container
title: docker attach
---
```markdown
Usage: docker attach [OPTIONS] CONTAINER
Attach to a running container
Options:
--detach-keys string Override the key sequence for detaching a container
--help Print usage
--no-stdin Do not attach STDIN
--sig-proxy Proxy all received signals to the process (default true)
```
The `docker attach` command allows you to attach to a running container using
the container's ID or name, either to view its ongoing output or to control it
interactively. You can attach to the same contained process multiple times
simultaneously, screen sharing style, or quickly view the progress of your
detached process.
To stop a container, use `CTRL-c`. This key sequence sends `SIGKILL` to the
container. If `--sig-proxy` is true (the default),`CTRL-c` sends a `SIGINT` to
the container. You can detach from a container and leave it running using the
`CTRL-p CTRL-q` key sequence.
> **Note:**
> A process running as PID 1 inside a container is treated specially by
> Linux: it ignores any signal with the default action. So, the process
> will not terminate on `SIGINT` or `SIGTERM` unless it is coded to do
> so.
It is forbidden to redirect the standard input of a `docker attach` command
while attaching to a tty-enabled container (i.e.: launched with `-t`).
While a client is connected to container's stdio using `docker attach`, Docker
uses a ~1MB memory buffer to maximize the throughput of the application. If
this buffer is filled, the speed of the API connection will start to have an
effect on the process output writing speed. This is similar to other
applications like SSH. Because of this, it is not recommended to run
performance critical applications that generate a lot of output in the
foreground over a slow client connection. Instead, users should use the
`docker logs` command to get access to the logs.
## Override the detach sequence
If you want, you can configure an override the Docker key sequence for detach.
This is useful if the Docker default sequence conflicts with key sequence you
use for other applications. There are two ways to define your own detach key
sequence, as a per-container override or as a configuration property on your
entire configuration.
To override the sequence for an individual container, use the
`--detach-keys="<sequence>"` flag with the `docker attach` command. The format of
the `<sequence>` is either a letter [a-Z], or the `ctrl-` combined with any of
the following:
* `a-z` (a single lowercase alpha character )
* `@` (at sign)
* `[` (left bracket)
* `\\` (two backward slashes)
* `_` (underscore)
* `^` (caret)
These `a`, `ctrl-a`, `X`, or `ctrl-\\` values are all examples of valid key
sequences. To configure a different configuration default key sequence for all
containers, see [**Configuration file** section](cli.md#configuration-files).
#### Examples
$ docker run -d --name topdemo ubuntu /usr/bin/top -b
$ docker attach topdemo
top - 02:05:52 up 3:05, 0 users, load average: 0.01, 0.02, 0.05
Tasks: 1 total, 1 running, 0 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.1%us, 0.2%sy, 0.0%ni, 99.7%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 373572k total, 355560k used, 18012k free, 27872k buffers
Swap: 786428k total, 0k used, 786428k free, 221740k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1 root 20 0 17200 1116 912 R 0 0.3 0:00.03 top
top - 02:05:55 up 3:05, 0 users, load average: 0.01, 0.02, 0.05
Tasks: 1 total, 1 running, 0 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.0%us, 0.2%sy, 0.0%ni, 99.8%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 373572k total, 355244k used, 18328k free, 27872k buffers
Swap: 786428k total, 0k used, 786428k free, 221776k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1 root 20 0 17208 1144 932 R 0 0.3 0:00.03 top
top - 02:05:58 up 3:06, 0 users, load average: 0.01, 0.02, 0.05
Tasks: 1 total, 1 running, 0 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.2%us, 0.3%sy, 0.0%ni, 99.5%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 373572k total, 355780k used, 17792k free, 27880k buffers
Swap: 786428k total, 0k used, 786428k free, 221776k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1 root 20 0 17208 1144 932 R 0 0.3 0:00.03 top
^C$
$ echo $?
0
$ docker ps -a | grep topdemo
7998ac8581f9 ubuntu:14.04 "/usr/bin/top -b" 38 seconds ago Exited (0) 21 seconds ago topdemo
And in this second example, you can see the exit code returned by the `bash`
process is returned by the `docker attach` command to its caller too:
$ docker run --name test -d -it debian
275c44472aebd77c926d4527885bb09f2f6db21d878c75f0a1c212c03d3bcfab
$ docker attach test
root@f38c87f2a42d:/# exit 13
exit
$ echo $?
13
$ docker ps -a | grep test
275c44472aeb debian:7 "/bin/bash" 26 seconds ago Exited (13) 17 seconds ago test

409
engine/reference/commandline/build.md
View File

@ -1,409 +0,0 @@
---
redirect_from:
- /reference/commandline/build/
description: The build command description and usage
keywords:
- build, docker, image
title: docker build
---
```markdown
Usage: docker build [OPTIONS] PATH | URL | -
Build an image from a Dockerfile
Options:
--build-arg value Set build-time variables (default [])
--cgroup-parent string Optional parent cgroup for the container
--cpu-period int Limit the CPU CFS (Completely Fair Scheduler) period
--cpu-quota int Limit the CPU CFS (Completely Fair Scheduler) quota
-c, --cpu-shares int CPU shares (relative weight)
--cpuset-cpus string CPUs in which to allow execution (0-3, 0,1)
--cpuset-mems string MEMs in which to allow execution (0-3, 0,1)
--disable-content-trust Skip image verification (default true)
-f, --file string Name of the Dockerfile (Default is 'PATH/Dockerfile')
--force-rm Always remove intermediate containers
--help Print usage
--isolation string Container isolation technology
--label value Set metadata for an image (default [])
-m, --memory string Memory limit
--memory-swap string Swap limit equal to memory plus swap: '-1' to enable unlimited swap
--no-cache Do not use cache when building the image
--pull Always attempt to pull a newer version of the image
-q, --quiet Suppress the build output and print image ID on success
--rm Remove intermediate containers after a successful build (default true)
--shm-size string Size of /dev/shm, default value is 64MB.
The format is `<number><unit>`. `number` must be greater than `0`.
Unit is optional and can be `b` (bytes), `k` (kilobytes), `m` (megabytes),
or `g` (gigabytes). If you omit the unit, the system uses bytes.
-t, --tag value Name and optionally a tag in the 'name:tag' format (default [])
--ulimit value Ulimit options (default [])
```
Builds Docker images from a Dockerfile and a "context". A build's context is
the files located in the specified `PATH` or `URL`. The build process can refer
to any of the files in the context. For example, your build can use an
[*ADD*](../builder.md#add) instruction to reference a file in the
context.
The `URL` parameter can refer to three kinds of resources: Git repositories,
pre-packaged tarball contexts and plain text files.
### Git repositories
When the `URL` parameter points to the location of a Git repository, the
repository acts as the build context. The system recursively clones the
repository and its submodules using a `git clone --depth 1 --recursive`
command. This command runs in a temporary directory on your local host. After
the command succeeds, the directory is sent to the Docker daemon as the
context. Local clones give you the ability to access private repositories using
local user credentials, VPN's, and so forth.
Git URLs accept context configuration in their fragment section, separated by a
colon `:`. The first part represents the reference that Git will check out,
this can be either a branch, a tag, or a commit SHA. The second part represents
a subdirectory inside the repository that will be used as a build context.
For example, run this command to use a directory called `docker` in the branch
`container`:
```bash
$ docker build https://github.com/docker/rootfs.git#container:docker
```
The following table represents all the valid suffixes with their build
contexts:
Build Syntax Suffix | Commit Used | Build Context Used
--------------------------------|-----------------------|-------------------
`myrepo.git` | `refs/heads/master` | `/`
`myrepo.git#mytag` | `refs/tags/mytag` | `/`
`myrepo.git#mybranch` | `refs/heads/mybranch` | `/`
`myrepo.git#abcdef` | `sha1 = abcdef` | `/`
`myrepo.git#:myfolder` | `refs/heads/master` | `/myfolder`
`myrepo.git#master:myfolder` | `refs/heads/master` | `/myfolder`
`myrepo.git#mytag:myfolder` | `refs/tags/mytag` | `/myfolder`
`myrepo.git#mybranch:myfolder` | `refs/heads/mybranch` | `/myfolder`
`myrepo.git#abcdef:myfolder` | `sha1 = abcdef` | `/myfolder`
### Tarball contexts
If you pass an URL to a remote tarball, the URL itself is sent to the daemon:
Instead of specifying a context, you can pass a single Dockerfile in the `URL`
or pipe the file in via `STDIN`. To pipe a Dockerfile from `STDIN`:
```bash
$ docker build http://server/context.tar.gz
The download operation will be performed on the host the Docker daemon is
running on, which is not necessarily the same host from which the build command
is being issued. The Docker daemon will fetch `context.tar.gz` and use it as the
build context. Tarball contexts must be tar archives conforming to the standard
`tar` UNIX format and can be compressed with any one of the 'xz', 'bzip2',
'gzip' or 'identity' (no compression) formats.
### Text files
Instead of specifying a context, you can pass a single `Dockerfile` in the
`URL` or pipe the file in via `STDIN`. To pipe a `Dockerfile` from `STDIN`:
```bash
$ docker build - < Dockerfile
```
With Powershell on Windows, you can run:
```powershell
Get-Content Dockerfile | docker build -
```
If you use `STDIN` or specify a `URL` pointing to a plain text file, the system
places the contents into a file called `Dockerfile`, and any `-f`, `--file`
option is ignored. In this scenario, there is no context.
By default the `docker build` command will look for a `Dockerfile` at the root
of the build context. The `-f`, `--file`, option lets you specify the path to
an alternative file to use instead. This is useful in cases where the same set
of files are used for multiple builds. The path must be to a file within the
build context. If a relative path is specified then it is interpreted as
relative to the root of the context.
In most cases, it's best to put each Dockerfile in an empty directory. Then,
add to that directory only the files needed for building the Dockerfile. To
increase the build's performance, you can exclude files and directories by
adding a `.dockerignore` file to that directory as well. For information on
creating one, see the [.dockerignore file](../builder.md#dockerignore-file).
If the Docker client loses connection to the daemon, the build is canceled.
This happens if you interrupt the Docker client with `CTRL-c` or if the Docker
client is killed for any reason. If the build initiated a pull which is still
running at the time the build is cancelled, the pull is cancelled as well.
## Return code
On a successful build, a return code of success `0` will be returned. When the
build fails, a non-zero failure code will be returned.
There should be informational output of the reason for failure output to
`STDERR`:
```bash
$ docker build -t fail .
Sending build context to Docker daemon 2.048 kB
Sending build context to Docker daemon
Step 1 : FROM busybox
---> 4986bf8c1536
Step 2 : RUN exit 13
---> Running in e26670ec7a0a
INFO[0000] The command [/bin/sh -c exit 13] returned a non-zero code: 13
$ echo $?
1
```
See also:
[*Dockerfile Reference*](../builder.md).
## Examples
### Build with PATH
```bash
$ docker build .
Uploading context 10240 bytes
Step 1 : FROM busybox
Pulling repository busybox
---> e9aa60c60128MB/2.284 MB (100%) endpoint: https://cdn-registry-1.docker.io/v1/
Step 2 : RUN ls -lh /
---> Running in 9c9e81692ae9
total 24
drwxr-xr-x 2 root root 4.0K Mar 12 2013 bin
drwxr-xr-x 5 root root 4.0K Oct 19 00:19 dev
drwxr-xr-x 2 root root 4.0K Oct 19 00:19 etc
drwxr-xr-x 2 root root 4.0K Nov 15 23:34 lib
lrwxrwxrwx 1 root root 3 Mar 12 2013 lib64 -> lib
dr-xr-xr-x 116 root root 0 Nov 15 23:34 proc
lrwxrwxrwx 1 root root 3 Mar 12 2013 sbin -> bin
dr-xr-xr-x 13 root root 0 Nov 15 23:34 sys
drwxr-xr-x 2 root root 4.0K Mar 12 2013 tmp
drwxr-xr-x 2 root root 4.0K Nov 15 23:34 usr
---> b35f4035db3f
Step 3 : CMD echo Hello world
---> Running in 02071fceb21b
---> f52f38b7823e
Successfully built f52f38b7823e
Removing intermediate container 9c9e81692ae9
Removing intermediate container 02071fceb21b
```
This example specifies that the `PATH` is `.`, and so all the files in the
local directory get `tar`d and sent to the Docker daemon. The `PATH` specifies
where to find the files for the "context" of the build on the Docker daemon.
Remember that the daemon could be running on a remote machine and that no
parsing of the Dockerfile happens at the client side (where you're running
`docker build`). That means that *all* the files at `PATH` get sent, not just
the ones listed to [*ADD*](../builder.md#add) in the Dockerfile.
The transfer of context from the local machine to the Docker daemon is what the
`docker` client means when you see the "Sending build context" message.
If you wish to keep the intermediate containers after the build is complete,
you must use `--rm=false`. This does not affect the build cache.
### Build with URL
```bash
$ docker build github.com/creack/docker-firefox
```
This will clone the GitHub repository and use the cloned repository as context.
The Dockerfile at the root of the repository is used as Dockerfile. You can
specify an arbitrary Git repository by using the `git://` or `git@` scheme.
```bash
$ docker build -f ctx/Dockerfile http://server/ctx.tar.gz
Downloading context: http://server/ctx.tar.gz [===================>] 240 B/240 B
Step 1 : FROM busybox
---> 8c2e06607696
Step 2 : ADD ctx/container.cfg /
---> e7829950cee3
Removing intermediate container b35224abf821
Step 3 : CMD /bin/ls
---> Running in fbc63d321d73
---> 3286931702ad
Removing intermediate container fbc63d321d73
Successfully built 377c409b35e4
```
This sends the URL `http://server/ctx.tar.gz` to the Docker daemon, which
downloads and extracts the referenced tarball. The `-f ctx/Dockerfile`
parameter specifies a path inside `ctx.tar.gz` to the `Dockerfile` that is used
to build the image. Any `ADD` commands in that `Dockerfile` that refer to local
paths must be relative to the root of the contents inside `ctx.tar.gz`. In the
example above, the tarball contains a directory `ctx/`, so the `ADD
ctx/container.cfg /` operation works as expected.
### Build with -
```bash
$ docker build - < Dockerfile
```
This will read a Dockerfile from `STDIN` without context. Due to the lack of a
context, no contents of any local directory will be sent to the Docker daemon.
Since there is no context, a Dockerfile `ADD` only works if it refers to a
remote URL.
```bash
$ docker build - < context.tar.gz
```
This will build an image for a compressed context read from `STDIN`. Supported
formats are: bzip2, gzip and xz.
### Usage of .dockerignore
```bash
$ docker build .
Uploading context 18.829 MB
Uploading context
Step 1 : FROM busybox
---> 769b9341d937
Step 2 : CMD echo Hello world
---> Using cache
---> 99cc1ad10469
Successfully built 99cc1ad10469
$ echo ".git" > .dockerignore
$ docker build .
Uploading context 6.76 MB
Uploading context
Step 1 : FROM busybox
---> 769b9341d937
Step 2 : CMD echo Hello world
---> Using cache
---> 99cc1ad10469
Successfully built 99cc1ad10469
```
This example shows the use of the `.dockerignore` file to exclude the `.git`
directory from the context. Its effect can be seen in the changed size of the
uploaded context. The builder reference contains detailed information on
[creating a .dockerignore file](../builder.md#dockerignore-file)
### Tag image (-t)
```bash
$ docker build -t vieux/apache:2.0 .
```
This will build like the previous example, but it will then tag the resulting
image. The repository name will be `vieux/apache` and the tag will be `2.0`.
[Read more about valid tags](tag.md).
You can apply multiple tags to an image. For example, you can apply the `latest`
tag to a newly built image and add another tag that references a specific
version.
For example, to tag an image both as `whenry/fedora-jboss:latest` and
`whenry/fedora-jboss:v2.1`, use the following:
```bash
$ docker build -t whenry/fedora-jboss:latest -t whenry/fedora-jboss:v2.1 .
```
### Specify Dockerfile (-f)
```bash
$ docker build -f Dockerfile.debug .
```
This will use a file called `Dockerfile.debug` for the build instructions
instead of `Dockerfile`.
```bash
$ docker build -f dockerfiles/Dockerfile.debug -t myapp_debug .
$ docker build -f dockerfiles/Dockerfile.prod -t myapp_prod .
```
The above commands will build the current build context (as specified by the
`.`) twice, once using a debug version of a `Dockerfile` and once using a
production version.
```bash
$ cd /home/me/myapp/some/dir/really/deep
$ docker build -f /home/me/myapp/dockerfiles/debug /home/me/myapp
$ docker build -f ../../../../dockerfiles/debug /home/me/myapp
```
These two `docker build` commands do the exact same thing. They both use the
contents of the `debug` file instead of looking for a `Dockerfile` and will use
`/home/me/myapp` as the root of the build context. Note that `debug` is in the
directory structure of the build context, regardless of how you refer to it on
the command line.
> **Note:**
> `docker build` will return a `no such file or directory` error if the
> file or directory does not exist in the uploaded context. This may
> happen if there is no context, or if you specify a file that is
> elsewhere on the Host system. The context is limited to the current
> directory (and its children) for security reasons, and to ensure
> repeatable builds on remote Docker hosts. This is also the reason why
> `ADD ../file` will not work.
### Optional parent cgroup (--cgroup-parent)
When `docker build` is run with the `--cgroup-parent` option the containers
used in the build will be run with the [corresponding `docker run`
flag](../run.md#specifying-custom-cgroups).
### Set ulimits in container (--ulimit)
Using the `--ulimit` option with `docker build` will cause each build step's
container to be started using those [`--ulimit`
flag values](./run.md#set-ulimits-in-container-ulimit).
### Set build-time variables (--build-arg)
You can use `ENV` instructions in a Dockerfile to define variable
values. These values persist in the built image. However, often
persistence is not what you want. Users want to specify variables differently
depending on which host they build an image on.
A good example is `http_proxy` or source versions for pulling intermediate
files. The `ARG` instruction lets Dockerfile authors define values that users
can set at build-time using the `--build-arg` flag:
```bash
$ docker build --build-arg HTTP_PROXY=http://10.20.30.2:1234 .
```
This flag allows you to pass the build-time variables that are
accessed like regular environment variables in the `RUN` instruction of the
Dockerfile. Also, these values don't persist in the intermediate or final images
like `ENV` values do.
Using this flag will not alter the output you see when the `ARG` lines from the
Dockerfile are echoed during the build process.
For detailed information on using `ARG` and `ENV` instructions, see the
[Dockerfile reference](../builder.md).
### Specify isolation technology for container (--isolation)
This option is useful in situations where you are running Docker containers on
Windows. The `--isolation=<value>` option sets a container's isolation
technology. On Linux, the only supported is the `default` option which uses
Linux namespaces. On Microsoft Windows, you can specify these values:
| Value | Description |
|-----------|---------------------------------------------------------------------------------------------------------------------------------------------------------------|
| `default` | Use the value specified by the Docker daemon's `--exec-opt` . If the `daemon` does not specify an isolation technology, Microsoft Windows uses `process` as its default value. |
| `process` | Namespace isolation only. |
| `hyperv` | Hyper-V hypervisor partition-based isolation. |
Specifying the `--isolation` flag without a value is the same as setting `--isolation="default"`.

222
engine/reference/commandline/cli.md
View File

@ -1,222 +0,0 @@
---
redirect_from:
- /reference/commandline/cli/
description: Docker's CLI command description and usage
keywords:
- Docker, Docker documentation, CLI, command line
title: Use the Docker Engine command-line
---
To list available commands, either run `docker` with no parameters
or execute `docker help`:
```bash
$ docker
Usage: docker [OPTIONS] COMMAND [arg...]
docker [ --help | -v | --version ]
A self-sufficient runtime for containers.
Options:
--config=~/.docker Location of client config files
-D, --debug Enable debug mode
-H, --host=[] Daemon socket(s) to connect to
-h, --help Print usage
-l, --log-level=info Set the logging level
--tls Use TLS; implied by --tlsverify
--tlscacert=~/.docker/ca.pem Trust certs signed only by this CA
--tlscert=~/.docker/cert.pem Path to TLS certificate file
--tlskey=~/.docker/key.pem Path to TLS key file
--tlsverify Use TLS and verify the remote
-v, --version Print version information and quit
Commands:
attach Attach to a running container
# […]
```
Depending on your Docker system configuration, you may be required to preface
each `docker` command with `sudo`. To avoid having to use `sudo` with the
`docker` command, your system administrator can create a Unix group called
`docker` and add users to it.
For more information about installing Docker or `sudo` configuration, refer to
the [installation](../../installation/index.md) instructions for your operating system.
## Environment variables
For easy reference, the following list of environment variables are supported
by the `docker` command line:
* `DOCKER_API_VERSION` The API version to use (e.g. `1.19`)
* `DOCKER_CONFIG` The location of your client configuration files.
* `DOCKER_CERT_PATH` The location of your authentication keys.
* `DOCKER_DRIVER` The graph driver to use.
* `DOCKER_HOST` Daemon socket to connect to.
* `DOCKER_NOWARN_KERNEL_VERSION` Prevent warnings that your Linux kernel is
unsuitable for Docker.
* `DOCKER_RAMDISK` If set this will disable 'pivot_root'.
* `DOCKER_TLS_VERIFY` When set Docker uses TLS and verifies the remote.
* `DOCKER_CONTENT_TRUST` When set Docker uses notary to sign and verify images.
Equates to `--disable-content-trust=false` for build, create, pull, push, run.
* `DOCKER_CONTENT_TRUST_SERVER` The URL of the Notary server to use. This defaults
to the same URL as the registry.
* `DOCKER_TMPDIR` Location for temporary Docker files.
Because Docker is developed using 'Go', you can also use any environment
variables used by the 'Go' runtime. In particular, you may find these useful:
* `HTTP_PROXY`
* `HTTPS_PROXY`
* `NO_PROXY`
These Go environment variables are case-insensitive. See the
[Go specification](http://golang.org/pkg/net/http/) for details on these
variables.
## Configuration files
By default, the Docker command line stores its configuration files in a
directory called `.docker` within your `$HOME` directory. However, you can
specify a different location via the `DOCKER_CONFIG` environment variable
or the `--config` command line option. If both are specified, then the
`--config` option overrides the `DOCKER_CONFIG` environment variable.
For example:
docker --config ~/testconfigs/ ps
Instructs Docker to use the configuration files in your `~/testconfigs/`
directory when running the `ps` command.
Docker manages most of the files in the configuration directory
and you should not modify them. However, you *can modify* the
`config.json` file to control certain aspects of how the `docker`
command behaves.
Currently, you can modify the `docker` command behavior using environment
variables or command-line options. You can also use options within
`config.json` to modify some of the same behavior. When using these
mechanisms, you must keep in mind the order of precedence among them. Command
line options override environment variables and environment variables override
properties you specify in a `config.json` file.
The `config.json` file stores a JSON encoding of several properties:
The property `HttpHeaders` specifies a set of headers to include in all messages
sent from the Docker client to the daemon. Docker does not try to interpret or
understand these header; it simply puts them into the messages. Docker does
not allow these headers to change any headers it sets for itself.
The property `psFormat` specifies the default format for `docker ps` output.
When the `--format` flag is not provided with the `docker ps` command,
Docker's client uses this property. If this property is not set, the client
falls back to the default table format. For a list of supported formatting
directives, see the
[**Formatting** section in the `docker ps` documentation](ps.md)
Once attached to a container, users detach from it and leave it running using
the using `CTRL-p CTRL-q` key sequence. This detach key sequence is customizable
using the `detachKeys` property. Specify a `<sequence>` value for the
property. The format of the `<sequence>` is a comma-separated list of either
a letter [a-Z], or the `ctrl-` combined with any of the following:
* `a-z` (a single lowercase alpha character )
* `@` (at sign)
* `[` (left bracket)
* `\\` (two backward slashes)
* `_` (underscore)
* `^` (caret)
Your customization applies to all containers started in with your Docker client.
Users can override your custom or the default key sequence on a per-container
basis. To do this, the user specifies the `--detach-keys` flag with the `docker
attach`, `docker exec`, `docker run` or `docker start` command.
The property `imagesFormat` specifies the default format for `docker images` output.
When the `--format` flag is not provided with the `docker images` command,
Docker's client uses this property. If this property is not set, the client
falls back to the default table format. For a list of supported formatting
directives, see the [**Formatting** section in the `docker images` documentation](images.md)
Following is a sample `config.json` file:
{% raw %}
{
"HttpHeaders": {
"MyHeader": "MyValue"
},
"psFormat": "table {{.ID}}\\t{{.Image}}\\t{{.Command}}\\t{{.Labels}}",
"imagesFormat": "table {{.ID}}\\t{{.Repository}}\\t{{.Tag}}\\t{{.CreatedAt}}",
"detachKeys": "ctrl-e,e"
}
{% endraw %}
### Notary
If using your own notary server and a self-signed certificate or an internal
Certificate Authority, you need to place the certificate at
`tls/<registry_url>/ca.crt` in your docker config directory.
Alternatively you can trust the certificate globally by adding it to your system's
list of root Certificate Authorities.
## Help
To list the help on any command just execute the command, followed by the
`--help` option.
$ docker run --help
Usage: docker run [OPTIONS] IMAGE [COMMAND] [ARG...]
Run a command in a new container
-a, --attach=[] Attach to STDIN, STDOUT or STDERR
--cpu-shares=0 CPU shares (relative weight)
...
## Option types
Single character command line options can be combined, so rather than
typing `docker run -i -t --name test busybox sh`,
you can write `docker run -it --name test busybox sh`.
### Boolean
Boolean options take the form `-d=false`. The value you see in the help text is
the default value which is set if you do **not** specify that flag. If you
specify a Boolean flag without a value, this will set the flag to `true`,
irrespective of the default value.
For example, running `docker run -d` will set the value to `true`, so your
container **will** run in "detached" mode, in the background.
Options which default to `true` (e.g., `docker build --rm=true`) can only be
set to the non-default value by explicitly setting them to `false`:
$ docker build --rm=false .
### Multi
You can specify options like `-a=[]` multiple times in a single command line,
for example in these commands:
$ docker run -a stdin -a stdout -i -t ubuntu /bin/bash
$ docker run -a stdin -a stdout -a stderr ubuntu /bin/ls
Sometimes, multiple options can call for a more complex value string as for
`-v`:
$ docker run -v /host:/container example/mysql
> **Note:**
> Do not use the `-t` and `-a stderr` options together due to
> limitations in the `pty` implementation. All `stderr` in `pty` mode
> simply goes to `stdout`.
### Strings and Integers
Options like `--name=""` expect a string, and they
can only be specified once. Options like `-c=0`
expect an integer, and they can only be specified once.

85
engine/reference/commandline/commit.md
View File

@ -1,85 +0,0 @@
---
redirect_from:
- /reference/commandline/commit/
description: The commit command description and usage
keywords:
- commit, file, changes
title: docker commit
---
```markdown
Usage: docker commit [OPTIONS] CONTAINER [REPOSITORY[:TAG]]
Create a new image from a container's changes
Options:
-a, --author string Author (e.g., "John Hannibal Smith <hannibal@a-team.com>")
-c, --change value Apply Dockerfile instruction to the created image (default [])
--help Print usage
-m, --message string Commit message
-p, --pause Pause container during commit (default true)
```
It can be useful to commit a container's file changes or settings into a new
image. This allows you debug a container by running an interactive shell, or to
export a working dataset to another server. Generally, it is better to use
Dockerfiles to manage your images in a documented and maintainable way.
[Read more about valid image names and tags](tag.md).
The commit operation will not include any data contained in
volumes mounted inside the container.
By default, the container being committed and its processes will be paused
while the image is committed. This reduces the likelihood of encountering data
corruption during the process of creating the commit. If this behavior is
undesired, set the `--pause` option to false.
The `--change` option will apply `Dockerfile` instructions to the image that is
created. Supported `Dockerfile` instructions:
`CMD`|`ENTRYPOINT`|`ENV`|`EXPOSE`|`LABEL`|`ONBUILD`|`USER`|`VOLUME`|`WORKDIR`
## Commit a container
$ docker ps
ID IMAGE COMMAND CREATED STATUS PORTS
c3f279d17e0a ubuntu:12.04 /bin/bash 7 days ago Up 25 hours
197387f1b436 ubuntu:12.04 /bin/bash 7 days ago Up 25 hours
$ docker commit c3f279d17e0a svendowideit/testimage:version3
f5283438590d
$ docker images
REPOSITORY TAG ID CREATED SIZE
svendowideit/testimage version3 f5283438590d 16 seconds ago 335.7 MB
## Commit a container with new configurations
{% raw %}
$ docker ps
ID IMAGE COMMAND CREATED STATUS PORTS
c3f279d17e0a ubuntu:12.04 /bin/bash 7 days ago Up 25 hours
197387f1b436 ubuntu:12.04 /bin/bash 7 days ago Up 25 hours
$ docker inspect -f "{{ .Config.Env }}" c3f279d17e0a
[HOME=/ PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin]
$ docker commit --change "ENV DEBUG true" c3f279d17e0a svendowideit/testimage:version3
f5283438590d
$ docker inspect -f "{{ .Config.Env }}" f5283438590d
[HOME=/ PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin DEBUG=true]
{% endraw %}
## Commit a container with new `CMD` and `EXPOSE` instructions
$ docker ps
ID IMAGE COMMAND CREATED STATUS PORTS
c3f279d17e0a ubuntu:12.04 /bin/bash 7 days ago Up 25 hours
197387f1b436 ubuntu:12.04 /bin/bash 7 days ago Up 25 hours
$ docker commit --change='CMD ["apachectl", "-DFOREGROUND"]' -c "EXPOSE 80" c3f279d17e0a svendowideit/testimage:version4
f5283438590d
$ docker run -d svendowideit/testimage:version4
89373736e2e7f00bc149bd783073ac43d0507da250e999f3f1036e0db60817c0
$ docker ps
ID IMAGE COMMAND CREATED STATUS PORTS
89373736e2e7 testimage:version4 "apachectl -DFOREGROU" 3 seconds ago Up 2 seconds 80/tcp
c3f279d17e0a ubuntu:12.04 /bin/bash 7 days ago Up 25 hours
197387f1b436 ubuntu:12.04 /bin/bash 7 days ago Up 25 hours

104
engine/reference/commandline/cp.md
View File

@ -1,104 +0,0 @@
---
redirect_from:
- /reference/commandline/cp/
description: The cp command description and usage
keywords:
- copy, container, files, folders
title: docker cp
---
```markdown
Usage: docker cp [OPTIONS] CONTAINER:SRC_PATH DEST_PATH|-
docker cp [OPTIONS] SRC_PATH|- CONTAINER:DEST_PATH
Copy files/folders between a container and the local filesystem
Use '-' as the source to read a tar archive from stdin
and extract it to a directory destination in a container.
Use '-' as the destination to stream a tar archive of a
container source to stdout.
Options:
-L, --follow-link Always follow symbol link in SRC_PATH
--help Print usage
```
The `docker cp` utility copies the contents of `SRC_PATH` to the `DEST_PATH`.
You can copy from the container's file system to the local machine or the
reverse, from the local filesystem to the container. If `-` is specified for
either the `SRC_PATH` or `DEST_PATH`, you can also stream a tar archive from
`STDIN` or to `STDOUT`. The `CONTAINER` can be a running or stopped container.
The `SRC_PATH` or `DEST_PATH` can be a file or directory.
The `docker cp` command assumes container paths are relative to the container's
`/` (root) directory. This means supplying the initial forward slash is optional;
The command sees `compassionate_darwin:/tmp/foo/myfile.txt` and
`compassionate_darwin:tmp/foo/myfile.txt` as identical. Local machine paths can
be an absolute or relative value. The command interprets a local machine's
relative paths as relative to the current working directory where `docker cp` is
run.
The `cp` command behaves like the Unix `cp -a` command in that directories are
copied recursively with permissions preserved if possible. Ownership is set to
the user and primary group at the destination. For example, files copied to a
container are created with `UID:GID` of the root user. Files copied to the local
machine are created with the `UID:GID` of the user which invoked the `docker cp`
command. If you specify the `-L` option, `docker cp` follows any symbolic link
in the `SRC_PATH`. `docker cp` does *not* create parent directories for
`DEST_PATH` if they do not exist.
Assuming a path separator of `/`, a first argument of `SRC_PATH` and second
argument of `DEST_PATH`, the behavior is as follows:
- `SRC_PATH` specifies a file
- `DEST_PATH` does not exist
- the file is saved to a file created at `DEST_PATH`
- `DEST_PATH` does not exist and ends with `/`
- Error condition: the destination directory must exist.
- `DEST_PATH` exists and is a file
- the destination is overwritten with the source file's contents
- `DEST_PATH` exists and is a directory
- the file is copied into this directory using the basename from
`SRC_PATH`
- `SRC_PATH` specifies a directory
- `DEST_PATH` does not exist
- `DEST_PATH` is created as a directory and the *contents* of the source
directory are copied into this directory
- `DEST_PATH` exists and is a file
- Error condition: cannot copy a directory to a file
- `DEST_PATH` exists and is a directory
- `SRC_PATH` does not end with `/.`
- the source directory is copied into this directory
- `SRC_PATH` does end with `/.`
- the *content* of the source directory is copied into this
directory
The command requires `SRC_PATH` and `DEST_PATH` to exist according to the above
rules. If `SRC_PATH` is local and is a symbolic link, the symbolic link, not
the target, is copied by default. To copy the link target and not the link, specify
the `-L` option.
A colon (`:`) is used as a delimiter between `CONTAINER` and its path. You can
also use `:` when specifying paths to a `SRC_PATH` or `DEST_PATH` on a local
machine, for example `file:name.txt`. If you use a `:` in a local machine path,
you must be explicit with a relative or absolute path, for example:
`/path/to/file:name.txt` or `./file:name.txt`
It is not possible to copy certain system files such as resources under
`/proc`, `/sys`, `/dev`, [tmpfs](run.md#mount-tmpfs-tmpfs), and mounts created by
the user in the container. However, you can still copy such files by manually
running `tar` in `docker exec`. For example (consider `SRC_PATH` and `DEST_PATH`
are directories):
$ docker exec foo tar Ccf $(dirname SRC_PATH) - $(basename SRC_PATH) | tar Cxf DEST_PATH -
or
$ tar Ccf $(dirname SRC_PATH) - $(basename SRC_PATH) | docker exec -i foo tar Cxf DEST_PATH -
Using `-` as the `SRC_PATH` streams the contents of `STDIN` as a tar archive.
The command extracts the content of the tar to the `DEST_PATH` in container's
filesystem. In this case, `DEST_PATH` must specify a directory. Using `-` as
the `DEST_PATH` streams the contents of the resource as a tar archive to `STDOUT`.

188
engine/reference/commandline/create.md
View File

@ -1,188 +0,0 @@
---
redirect_from:
- /reference/commandline/create/
description: The create command description and usage
keywords:
- docker, create, container
title: docker create
---
Creates a new container.
```markdown
Usage: docker create [OPTIONS] IMAGE [COMMAND] [ARG...]
Create a new container
Options:
--add-host value Add a custom host-to-IP mapping (host:ip) (default [])
-a, --attach value Attach to STDIN, STDOUT or STDERR (default [])
--blkio-weight value Block IO (relative weight), between 10 and 1000
--blkio-weight-device value Block IO weight (relative device weight) (default [])
--cap-add value Add Linux capabilities (default [])
--cap-drop value Drop Linux capabilities (default [])
--cgroup-parent string Optional parent cgroup for the container
--cidfile string Write the container ID to the file
--cpu-percent int CPU percent (Windows only)
--cpu-period int Limit CPU CFS (Completely Fair Scheduler) period
--cpu-quota int Limit CPU CFS (Completely Fair Scheduler) quota
-c, --cpu-shares int CPU shares (relative weight)
--cpuset-cpus string CPUs in which to allow execution (0-3, 0,1)
--cpuset-mems string MEMs in which to allow execution (0-3, 0,1)
--device value Add a host device to the container (default [])
--device-read-bps value Limit read rate (bytes per second) from a device (default [])
--device-read-iops value Limit read rate (IO per second) from a device (default [])
--device-write-bps value Limit write rate (bytes per second) to a device (default [])
--device-write-iops value Limit write rate (IO per second) to a device (default [])
--disable-content-trust Skip image verification (default true)
--dns value Set custom DNS servers (default [])
--dns-opt value Set DNS options (default [])
--dns-search value Set custom DNS search domains (default [])
--entrypoint string Overwrite the default ENTRYPOINT of the image
-e, --env value Set environment variables (default [])
--env-file value Read in a file of environment variables (default [])
--expose value Expose a port or a range of ports (default [])
--group-add value Add additional groups to join (default [])
--health-cmd string Command to run to check health
--health-interval duration Time between running the check
--health-retries int Consecutive failures needed to report unhealthy
--health-timeout duration Maximum time to allow one check to run
--help Print usage
-h, --hostname string Container host name
-i, --interactive Keep STDIN open even if not attached
--io-maxbandwidth string Maximum IO bandwidth limit for the system drive (Windows only)
--io-maxiops uint Maximum IOps limit for the system drive (Windows only)
--ip string Container IPv4 address (e.g. 172.30.100.104)
--ip6 string Container IPv6 address (e.g. 2001:db8::33)
--ipc string IPC namespace to use
--isolation string Container isolation technology
--kernel-memory string Kernel memory limit
-l, --label value Set meta data on a container (default [])
--label-file value Read in a line delimited file of labels (default [])
--link value Add link to another container (default [])
--link-local-ip value Container IPv4/IPv6 link-local addresses (default [])
--log-driver string Logging driver for the container
--log-opt value Log driver options (default [])
--mac-address string Container MAC address (e.g. 92:d0:c6:0a:29:33)
-m, --memory string Memory limit
--memory-reservation string Memory soft limit
--memory-swap string Swap limit equal to memory plus swap: '-1' to enable unlimited swap
--memory-swappiness int Tune container memory swappiness (0 to 100) (default -1)
--name string Assign a name to the container
--network-alias value Add network-scoped alias for the container (default [])
--network string Connect a container to a network (default "default")
'bridge': create a network stack on the default Docker bridge
'none': no networking
'container:<name|id>': reuse another container's network stack
'host': use the Docker host network stack
'<network-name>|<network-id>': connect to a user-defined network
--no-healthcheck Disable any container-specified HEALTHCHECK
--oom-kill-disable Disable OOM Killer
--oom-score-adj int Tune host's OOM preferences (-1000 to 1000)
--pid string PID namespace to use
--pids-limit int Tune container pids limit (set -1 for unlimited), kernel >= 4.3
--privileged Give extended privileges to this container
-p, --publish value Publish a container's port(s) to the host (default [])
-P, --publish-all Publish all exposed ports to random ports
--read-only Mount the container's root filesystem as read only
--restart string Restart policy to apply when a container exits (default "no")
Possible values are: no, on-failure[:max-retry], always, unless-stopped
--runtime string Runtime to use for this container
--security-opt value Security Options (default [])
--shm-size string Size of /dev/shm, default value is 64MB.
The format is `<number><unit>`. `number` must be greater than `0`.
Unit is optional and can be `b` (bytes), `k` (kilobytes), `m` (megabytes),
or `g` (gigabytes). If you omit the unit, the system uses bytes.
--stop-signal string Signal to stop a container, SIGTERM by default (default "SIGTERM")
--storage-opt value Storage driver options for the container (default [])
--sysctl value Sysctl options (default map[])
--tmpfs value Mount a tmpfs directory (default [])
-t, --tty Allocate a pseudo-TTY
--ulimit value Ulimit options (default [])
-u, --user string Username or UID (format: <name|uid>[:<group|gid>])
--userns string User namespace to use
'host': Use the Docker host user namespace
'': Use the Docker daemon user namespace specified by `--userns-remap` option.
--uts string UTS namespace to use
-v, --volume value Bind mount a volume (default []). The format
is `[host-src:]container-dest[:<options>]`.
The comma-delimited `options` are [rw|ro],
[z|Z], [[r]shared|[r]slave|[r]private], and
[nocopy]. The 'host-src' is an absolute path
or a name value.
--volume-driver string Optional volume driver for the container
--volumes-from value Mount volumes from the specified container(s) (default [])
-w, --workdir string Working directory inside the container
```
The `docker create` command creates a writeable container layer over the
specified image and prepares it for running the specified command. The
container ID is then printed to `STDOUT`. This is similar to `docker run -d`
except the container is never started. You can then use the
`docker start <container_id>` command to start the container at any point.
This is useful when you want to set up a container configuration ahead of time
so that it is ready to start when you need it. The initial status of the
new container is `created`.
Please see the [run command](run.md) section and the [Docker run reference](../run.md) for more details.
## Examples
$ docker create -t -i fedora bash
6d8af538ec541dd581ebc2a24153a28329acb5268abe5ef868c1f1a261221752
$ docker start -a -i 6d8af538ec5
bash-4.2#
As of v1.4.0 container volumes are initialized during the `docker create` phase
(i.e., `docker run` too). For example, this allows you to `create` the `data`
volume container, and then use it from another container:
$ docker create -v /data --name data ubuntu
240633dfbb98128fa77473d3d9018f6123b99c454b3251427ae190a7d951ad57
$ docker run --rm --volumes-from data ubuntu ls -la /data
total 8
drwxr-xr-x 2 root root 4096 Dec 5 04:10 .
drwxr-xr-x 48 root root 4096 Dec 5 04:11 ..
Similarly, `create` a host directory bind mounted volume container, which can
then be used from the subsequent container:
$ docker create -v /home/docker:/docker --name docker ubuntu
9aa88c08f319cd1e4515c3c46b0de7cc9aa75e878357b1e96f91e2c773029f03
$ docker run --rm --volumes-from docker ubuntu ls -la /docker
total 20
drwxr-sr-x 5 1000 staff 180 Dec 5 04:00 .
drwxr-xr-x 48 root root 4096 Dec 5 04:13 ..
-rw-rw-r-- 1 1000 staff 3833 Dec 5 04:01 .ash_history
-rw-r--r-- 1 1000 staff 446 Nov 28 11:51 .ashrc
-rw-r--r-- 1 1000 staff 25 Dec 5 04:00 .gitconfig
drwxr-sr-x 3 1000 staff 60 Dec 1 03:28 .local
-rw-r--r-- 1 1000 staff 920 Nov 28 11:51 .profile
drwx--S--- 2 1000 staff 460 Dec 5 00:51 .ssh
drwxr-xr-x 32 1000 staff 1140 Dec 5 04:01 docker
Set storage driver options per container.
$ docker create -it --storage-opt size=120G fedora /bin/bash
This (size) will allow to set the container rootfs size to 120G at creation time.
User cannot pass a size less than the Default BaseFS Size. This option is only
available for the `devicemapper`, `btrfs`, and `zfs` graph drivers.
### Specify isolation technology for container (--isolation)
This option is useful in situations where you are running Docker containers on
Windows. The `--isolation=<value>` option sets a container's isolation
technology. On Linux, the only supported is the `default` option which uses
Linux namespaces. On Microsoft Windows, you can specify these values:
| Value | Description |
|-----------|---------------------------------------------------------------------------------------------------------------------------------------------------------------|
| `default` | Use the value specified by the Docker daemon's `--exec-opt` . If the `daemon` does not specify an isolation technology, Microsoft Windows uses `process` as its default value if the
daemon is running on Windows server, or `hyperv` if running on Windows client. |
| `process` | Namespace isolation only. |
| `hyperv` | Hyper-V hypervisor partition-based isolation. |
Specifying the `--isolation` flag without a value is the same as setting `--isolation="default"`.

55
engine/reference/commandline/deploy.md
View File

@ -1,55 +0,0 @@
---
redirect_from:
- /reference/commandline/deploy/
advisory: experimental
description: The deploy command description and usage
keywords:
- stack, deploy
title: docker deploy
---
```markdown
Usage: docker deploy [OPTIONS] STACK
Create and update a stack from a Distributed Application Bundle (DAB)
Options:
--file string Path to a Distributed Application Bundle file (Default: STACK.dab)
--help Print usage
--with-registry-auth Send registry authentication details to swarm agents
```
Create and update a stack from a `dab` file. This command has to be
run targeting a manager node.
```bash
$ docker deploy vossibility-stack
Loading bundle from vossibility-stack.dab
Creating service vossibility-stack_elasticsearch
Creating service vossibility-stack_kibana
Creating service vossibility-stack_logstash
Creating service vossibility-stack_lookupd
Creating service vossibility-stack_nsqd
Creating service vossibility-stack_vossibility-collector
```
You can verify that the services were correctly created:
```bash
$ docker service ls
ID NAME REPLICAS IMAGE
COMMAND
29bv0vnlm903 vossibility-stack_lookupd 1 nsqio/nsq@sha256:eeba05599f31eba418e96e71e0984c3dc96963ceb66924dd37a47bf7ce18a662 /nsqlookupd
4awt47624qwh vossibility-stack_nsqd 1 nsqio/nsq@sha256:eeba05599f31eba418e96e71e0984c3dc96963ceb66924dd37a47bf7ce18a662 /nsqd --data-path=/data --lookupd-tcp-address=lookupd:4160
4tjx9biia6fs vossibility-stack_elasticsearch 1 elasticsearch@sha256:12ac7c6af55d001f71800b83ba91a04f716e58d82e748fa6e5a7359eed2301aa
7563uuzr9eys vossibility-stack_kibana 1 kibana@sha256:6995a2d25709a62694a937b8a529ff36da92ebee74bafd7bf00e6caf6db2eb03
9gc5m4met4he vossibility-stack_logstash 1 logstash@sha256:2dc8bddd1bb4a5a34e8ebaf73749f6413c101b2edef6617f2f7713926d2141fe logstash -f /etc/logstash/conf.d/logstash.conf
axqh55ipl40h vossibility-stack_vossibility-collector 1 icecrime/vossibility-collector@sha256:f03f2977203ba6253988c18d04061c5ec7aab46bca9dfd89a9a1fa4500989fba --config /config/config.toml --debug
```
## Related information
* [stack config](stack_config.md)
* [stack deploy](stack_deploy.md)
* [stack rm](stack_rm.md)
* [stack tasks](stack_tasks.md)

40
engine/reference/commandline/diff.md
View File

@ -1,40 +0,0 @@
---
redirect_from:
- /reference/commandline/diff/
description: The diff command description and usage
keywords:
- list, changed, files, container
title: docker diff
---
```markdown
Usage: docker diff CONTAINER
Inspect changes on a container's filesystem
Options:
--help Print usage
```
List the changed files and directories in a container᾿s filesystem
There are 3 events that are listed in the `diff`:
1. `A` - Add
2. `D` - Delete
3. `C` - Change
For example:
$ docker diff 7bb0e258aefe
C /dev
A /dev/kmsg
C /etc
A /etc/mtab
A /go
A /go/src
A /go/src/github.com
A /go/src/github.com/docker
A /go/src/github.com/docker/docker
A /go/src/github.com/docker/docker/.git
....

BIN
engine/reference/commandline/docker_images.gif
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 35 KiB

1292
engine/reference/commandline/dockerd.md
View File

File diff suppressed because it is too large Load Diff

179
engine/reference/commandline/events.md
View File

@ -1,179 +0,0 @@
---
redirect_from:
- /reference/commandline/events/
description: The events command description and usage
keywords:
- events, container, report
title: docker events
---
```markdown
Usage: docker events [OPTIONS]
Get real time events from the server
Options:
-f, --filter value Filter output based on conditions provided (default [])
--help Print usage
--since string Show all events created since timestamp
--until string Stream events until this timestamp
```
Docker containers report the following events:
attach, commit, copy, create, destroy, detach, die, exec_create, exec_detach, exec_start, export, health_status, kill, oom, pause, rename, resize, restart, start, stop, top, unpause, update
Docker images report the following events:
delete, import, load, pull, push, save, tag, untag
Docker plugins(experimental) report the following events:
install, enable, disable, remove
Docker volumes report the following events:
create, mount, unmount, destroy
Docker networks report the following events:
create, connect, disconnect, destroy
Docker daemon report the following events:
reload
The `--since` and `--until` parameters can be Unix timestamps, date formatted
timestamps, or Go duration strings (e.g. `10m`, `1h30m`) computed
relative to the client machine’s time. If you do not provide the `--since` option,
the command returns only new and/or live events. Supported formats for date
formatted time stamps include RFC3339Nano, RFC3339, `2006-01-02T15:04:05`,
`2006-01-02T15:04:05.999999999`, `2006-01-02Z07:00`, and `2006-01-02`. The local
timezone on the client will be used if you do not provide either a `Z` or a
`+-00:00` timezone offset at the end of the timestamp. When providing Unix
timestamps enter seconds[.nanoseconds], where seconds is the number of seconds
that have elapsed since January 1, 1970 (midnight UTC/GMT), not counting leap
seconds (aka Unix epoch or Unix time), and the optional .nanoseconds field is a
fraction of a second no more than nine digits long.
## Filtering
The filtering flag (`-f` or `--filter`) format is of "key=value". If you would
like to use multiple filters, pass multiple flags (e.g.,
`--filter "foo=bar" --filter "bif=baz"`)
Using the same filter multiple times will be handled as a *OR*; for example
`--filter container=588a23dac085 --filter container=a8f7720b8c22` will display
events for container 588a23dac085 *OR* container a8f7720b8c22
Using multiple filters will be handled as a *AND*; for example
`--filter container=588a23dac085 --filter event=start` will display events for
container container 588a23dac085 *AND* the event type is *start*
The currently supported filters are:
* container (`container=<name or id>`)
* event (`event=<event action>`)
* image (`image=<tag or id>`)
* plugin (experimental) (`plugin=<name or id>`)
* label (`label=<key>` or `label=<key>=<value>`)
* type (`type=<container or image or volume or network or daemon>`)
* volume (`volume=<name or id>`)
* network (`network=<name or id>`)
* daemon (`daemon=<name or id>`)
## Examples
You'll need two shells for this example.
**Shell 1: Listening for events:**
$ docker events
**Shell 2: Start and Stop containers:**
$ docker start 4386fb97867d
$ docker stop 4386fb97867d
$ docker stop 7805c1d35632
**Shell 1: (Again .. now showing events):**
2015-05-12T11:51:30.999999999Z07:00 container start 4386fb97867d (image=ubuntu-1:14.04)
2015-05-12T11:51:30.999999999Z07:00 container die 4386fb97867d (image=ubuntu-1:14.04)
2015-05-12T15:52:12.999999999Z07:00 container stop 4386fb97867d (image=ubuntu-1:14.04)
2015-05-12T15:53:45.999999999Z07:00 container die 7805c1d35632 (image=redis:2.8)
2015-05-12T15:54:03.999999999Z07:00 container stop 7805c1d35632 (image=redis:2.8)
**Show events in the past from a specified time:**
$ docker events --since 1378216169
2015-05-12T11:51:30.999999999Z07:00 container die 4386fb97867d (image=ubuntu-1:14.04)
2015-05-12T15:52:12.999999999Z07:00 container stop 4386fb97867d (image=ubuntu-1:14.04)
2015-05-12T15:53:45.999999999Z07:00 container die 7805c1d35632 (image=redis:2.8)
2015-05-12T15:54:03.999999999Z07:00 container stop 7805c1d35632 (image=redis:2.8)
$ docker events --since '2013-09-03'
2015-05-12T11:51:30.999999999Z07:00 container start 4386fb97867d (image=ubuntu-1:14.04)
2015-05-12T11:51:30.999999999Z07:00 container die 4386fb97867d (image=ubuntu-1:14.04)
2015-05-12T15:52:12.999999999Z07:00 container stop 4386fb97867d (image=ubuntu-1:14.04)
2015-05-12T15:53:45.999999999Z07:00 container die 7805c1d35632 (image=redis:2.8)
2015-05-12T15:54:03.999999999Z07:00 container stop 7805c1d35632 (image=redis:2.8)
$ docker events --since '2013-09-03T15:49:29'
2015-05-12T11:51:30.999999999Z07:00 container die 4386fb97867d (image=ubuntu-1:14.04)
2015-05-12T15:52:12.999999999Z07:00 container stop 4386fb97867d (image=ubuntu-1:14.04)
2015-05-12T15:53:45.999999999Z07:00 container die 7805c1d35632 (image=redis:2.8)
2015-05-12T15:54:03.999999999Z07:00 container stop 7805c1d35632 (image=redis:2.8)
This example outputs all events that were generated in the last 3 minutes,
relative to the current time on the client machine:
$ docker events --since '3m'
2015-05-12T11:51:30.999999999Z07:00 container die 4386fb97867d (image=ubuntu-1:14.04)
2015-05-12T15:52:12.999999999Z07:00 container stop 4386fb97867d (image=ubuntu-1:14.04)
2015-05-12T15:53:45.999999999Z07:00 container die 7805c1d35632 (image=redis:2.8)
2015-05-12T15:54:03.999999999Z07:00 container stop 7805c1d35632 (image=redis:2.8)
**Filter events:**
$ docker events --filter 'event=stop'
2014-05-10T17:42:14.999999999Z07:00 container stop 4386fb97867d (image=ubuntu-1:14.04)
2014-09-03T17:42:14.999999999Z07:00 container stop 7805c1d35632 (image=redis:2.8)
$ docker events --filter 'image=ubuntu-1:14.04'
2014-05-10T17:42:14.999999999Z07:00 container start 4386fb97867d (image=ubuntu-1:14.04)
2014-05-10T17:42:14.999999999Z07:00 container die 4386fb97867d (image=ubuntu-1:14.04)
2014-05-10T17:42:14.999999999Z07:00 container stop 4386fb97867d (image=ubuntu-1:14.04)
$ docker events --filter 'container=7805c1d35632'
2014-05-10T17:42:14.999999999Z07:00 container die 7805c1d35632 (image=redis:2.8)
2014-09-03T15:49:29.999999999Z07:00 container stop 7805c1d35632 (image= redis:2.8)
$ docker events --filter 'container=7805c1d35632' --filter 'container=4386fb97867d'
2014-09-03T15:49:29.999999999Z07:00 container die 4386fb97867d (image=ubuntu-1:14.04)
2014-05-10T17:42:14.999999999Z07:00 container stop 4386fb97867d (image=ubuntu-1:14.04)
2014-05-10T17:42:14.999999999Z07:00 container die 7805c1d35632 (image=redis:2.8)
2014-09-03T15:49:29.999999999Z07:00 container stop 7805c1d35632 (image=redis:2.8)
$ docker events --filter 'container=7805c1d35632' --filter 'event=stop'
2014-09-03T15:49:29.999999999Z07:00 container stop 7805c1d35632 (image=redis:2.8)
$ docker events --filter 'container=container_1' --filter 'container=container_2'
2014-09-03T15:49:29.999999999Z07:00 container die 4386fb97867d (image=ubuntu-1:14.04)
2014-05-10T17:42:14.999999999Z07:00 container stop 4386fb97867d (image=ubuntu-1:14.04)
2014-05-10T17:42:14.999999999Z07:00 container die 7805c1d35632 (imager=redis:2.8)
2014-09-03T15:49:29.999999999Z07:00 container stop 7805c1d35632 (image=redis:2.8)
$ docker events --filter 'type=volume'
2015-12-23T21:05:28.136212689Z volume create test-event-volume-local (driver=local)
2015-12-23T21:05:28.383462717Z volume mount test-event-volume-local (read/write=true, container=562fe10671e9273da25eed36cdce26159085ac7ee6707105fd534866340a5025, destination=/foo, driver=local, propagation=rprivate)
2015-12-23T21:05:28.650314265Z volume unmount test-event-volume-local (container=562fe10671e9273da25eed36cdce26159085ac7ee6707105fd534866340a5025, driver=local)
2015-12-23T21:05:28.716218405Z volume destroy test-event-volume-local (driver=local)
$ docker events --filter 'type=network'
2015-12-23T21:38:24.705709133Z network create 8b111217944ba0ba844a65b13efcd57dc494932ee2527577758f939315ba2c5b (name=test-event-network-local, type=bridge)
2015-12-23T21:38:25.119625123Z network connect 8b111217944ba0ba844a65b13efcd57dc494932ee2527577758f939315ba2c5b (name=test-event-network-local, container=b4be644031a3d90b400f88ab3d4bdf4dc23adb250e696b6328b85441abe2c54e, type=bridge)
$ docker events --filter 'type=plugin' (experimental)
2016-07-25T17:30:14.825557616Z plugin pull ec7b87f2ce84330fe076e666f17dfc049d2d7ae0b8190763de94e1f2d105993f (name=tiborvass/no-remove:latest)
2016-07-25T17:30:14.888127370Z plugin enable ec7b87f2ce84330fe076e666f17dfc049d2d7ae0b8190763de94e1f2d105993f (name=tiborvass/no-remove:latest)

55
engine/reference/commandline/exec.md
View File

@ -1,55 +0,0 @@
---
redirect_from:
- /reference/commandline/exec/
description: The exec command description and usage
keywords:
- command, container, run, execute
title: docker exec
---
```markdown
Usage: docker exec [OPTIONS] CONTAINER COMMAND [ARG...]
Run a command in a running container
-d, --detach Detached mode: run command in the background
--detach-keys Override the key sequence for detaching a container
--help Print usage
-i, --interactive Keep STDIN open even if not attached
--privileged Give extended privileges to the command
-t, --tty Allocate a pseudo-TTY
-u, --user Username or UID (format: <name|uid>[:<group|gid>])
```
The `docker exec` command runs a new command in a running container.
The command started using `docker exec` only runs while the container's primary
process (`PID 1`) is running, and it is not restarted if the container is
restarted.
If the container is paused, then the `docker exec` command will fail with an error:
$ docker pause test
test
$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
1ae3b36715d2 ubuntu:latest "bash" 17 seconds ago Up 16 seconds (Paused) test
$ docker exec test ls
FATA[0000] Error response from daemon: Container test is paused, unpause the container before exec
$ echo $?
1
## Examples
$ docker run --name ubuntu_bash --rm -i -t ubuntu bash
This will create a container named `ubuntu_bash` and start a Bash session.
$ docker exec -d ubuntu_bash touch /tmp/execWorks
This will create a new file `/tmp/execWorks` inside the running container
`ubuntu_bash`, in the background.
$ docker exec -it ubuntu_bash bash
This will create a new Bash session in the container `ubuntu_bash`.

35
engine/reference/commandline/export.md
View File

@ -1,35 +0,0 @@
---
redirect_from:
- /reference/commandline/export/
description: The export command description and usage
keywords:
- export, file, system, container
title: docker export
---
```markdown
Usage: docker export [OPTIONS] CONTAINER
Export a container's filesystem as a tar archive
Options:
--help Print usage
-o, --output string Write to a file, instead of STDOUT
```
The `docker export` command does not export the contents of volumes associated
with the container. If a volume is mounted on top of an existing directory in
the container, `docker export` will export the contents of the *underlying*
directory, not the contents of the volume.
Refer to [Backup, restore, or migrate data
volumes](../../tutorials/dockervolumes.md#backup-restore-or-migrate-data-volumes) in
the user guide for examples on exporting data in a volume.
## Examples
$ docker export red_panda > latest.tar
Or
$ docker export --output="latest.tar" red_panda

40
engine/reference/commandline/history.md
View File

@ -1,40 +0,0 @@
---
redirect_from:
- /reference/commandline/history/
description: The history command description and usage
keywords:
- docker, image, history
title: docker history
---
```markdown
Usage: docker history [OPTIONS] IMAGE
Show the history of an image
Options:
--help Print usage
-H, --human Print sizes and dates in human readable format (default true)
--no-trunc Don't truncate output
-q, --quiet Only show numeric IDs
```
To see how the `docker:latest` image was built:
$ docker history docker
IMAGE CREATED CREATED BY SIZE COMMENT
3e23a5875458 8 days ago /bin/sh -c #(nop) ENV LC_ALL=C.UTF-8 0 B
8578938dd170 8 days ago /bin/sh -c dpkg-reconfigure locales && loc 1.245 MB
be51b77efb42 8 days ago /bin/sh -c apt-get update && apt-get install 338.3 MB
4b137612be55 6 weeks ago /bin/sh -c #(nop) ADD jessie.tar.xz in / 121 MB
750d58736b4b 6 weeks ago /bin/sh -c #(nop) MAINTAINER Tianon Gravi <ad 0 B
511136ea3c5a 9 months ago 0 B Imported from -
To see how the `docker:apache` image was added to a container's base image:
$ docker history docker:scm
IMAGE CREATED CREATED BY SIZE COMMENT
2ac9d1098bf1 3 months ago /bin/bash 241.4 MB Added Apache to Fedora base image
88b42ffd1f7c 5 months ago /bin/sh -c #(nop) ADD file:1fd8d7f9f6557cafc7 373.7 MB
c69cab00d6ef 5 months ago /bin/sh -c #(nop) MAINTAINER Lokesh Mandvekar 0 B
511136ea3c5a 19 months ago 0 B Imported from -

277
engine/reference/commandline/images.md
View File

@ -1,277 +0,0 @@
---
redirect_from:
- /reference/commandline/images/
description: The images command description and usage
keywords:
- list, docker, images
title: docker images
---
```markdown
Usage: docker images [OPTIONS] [REPOSITORY[:TAG]]
List images
Options:
-a, --all Show all images (default hides intermediate images)
--digests Show digests
-f, --filter value Filter output based on conditions provided (default [])
- dangling=(true|false)
- label=<key> or label=<key>=<value>
- before=(<image-name>[:tag]|<image-id>|<image@digest>)
- since=(<image-name>[:tag]|<image-id>|<image@digest>)
--format string Pretty-print images using a Go template
--help Print usage
--no-trunc Don't truncate output
-q, --quiet Only show numeric IDs
```
The default `docker images` will show all top level
images, their repository and tags, and their size.
Docker images have intermediate layers that increase reusability,
decrease disk usage, and speed up `docker build` by
allowing each step to be cached. These intermediate layers are not shown
by default.
The `SIZE` is the cumulative space taken up by the image and all
its parent images. This is also the disk space used by the contents of the
Tar file created when you `docker save` an image.
An image will be listed more than once if it has multiple repository names
or tags. This single image (identifiable by its matching `IMAGE ID`)
uses up the `SIZE` listed only once.
### Listing the most recently created images
$ docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
<none> <none> 77af4d6b9913 19 hours ago 1.089 GB
committ latest b6fa739cedf5 19 hours ago 1.089 GB
<none> <none> 78a85c484f71 19 hours ago 1.089 GB
docker latest 30557a29d5ab 20 hours ago 1.089 GB
<none> <none> 5ed6274db6ce 24 hours ago 1.089 GB
postgres 9 746b819f315e 4 days ago 213.4 MB
postgres 9.3 746b819f315e 4 days ago 213.4 MB
postgres 9.3.5 746b819f315e 4 days ago 213.4 MB
postgres latest 746b819f315e 4 days ago 213.4 MB
### Listing images by name and tag
The `docker images` command takes an optional `[REPOSITORY[:TAG]]` argument
that restricts the list to images that match the argument. If you specify
`REPOSITORY`but no `TAG`, the `docker images` command lists all images in the
given repository.
For example, to list all images in the "java" repository, run this command :
$ docker images java
REPOSITORY TAG IMAGE ID CREATED SIZE
java 8 308e519aac60 6 days ago 824.5 MB
java 7 493d82594c15 3 months ago 656.3 MB
java latest 2711b1d6f3aa 5 months ago 603.9 MB
The `[REPOSITORY[:TAG]]` value must be an "exact match". This means that, for example,
`docker images jav` does not match the image `java`.
If both `REPOSITORY` and `TAG` are provided, only images matching that
repository and tag are listed. To find all local images in the "java"
repository with tag "8" you can use:
$ docker images java:8
REPOSITORY TAG IMAGE ID CREATED SIZE
java 8 308e519aac60 6 days ago 824.5 MB
If nothing matches `REPOSITORY[:TAG]`, the list is empty.
$ docker images java:0
REPOSITORY TAG IMAGE ID CREATED SIZE
## Listing the full length image IDs
$ docker images --no-trunc
REPOSITORY TAG IMAGE ID CREATED SIZE
<none> <none> sha256:77af4d6b9913e693e8d0b4b294fa62ade6054e6b2f1ffb617ac955dd63fb0182 19 hours ago 1.089 GB
committest latest sha256:b6fa739cedf5ea12a620a439402b6004d057da800f91c7524b5086a5e4749c9f 19 hours ago 1.089 GB
<none> <none> sha256:78a85c484f71509adeaace20e72e941f6bdd2b25b4c75da8693efd9f61a37921 19 hours ago 1.089 GB
docker latest sha256:30557a29d5abc51e5f1d5b472e79b7e296f595abcf19fe6b9199dbbc809c6ff4 20 hours ago 1.089 GB
<none> <none> sha256:0124422dd9f9cf7ef15c0617cda3931ee68346455441d66ab8bdc5b05e9fdce5 20 hours ago 1.089 GB
<none> <none> sha256:18ad6fad340262ac2a636efd98a6d1f0ea775ae3d45240d3418466495a19a81b 22 hours ago 1.082 GB
<none> <none> sha256:f9f1e26352f0a3ba6a0ff68167559f64f3e21ff7ada60366e2d44a04befd1d3a 23 hours ago 1.089 GB
tryout latest sha256:2629d1fa0b81b222fca63371ca16cbf6a0772d07759ff80e8d1369b926940074 23 hours ago 131.5 MB
<none> <none> sha256:5ed6274db6ceb2397844896966ea239290555e74ef307030ebb01ff91b1914df 24 hours ago 1.089 GB
## Listing image digests
Images that use the v2 or later format have a content-addressable identifier
called a `digest`. As long as the input used to generate the image is
unchanged, the digest value is predictable. To list image digest values, use
the `--digests` flag:
$ docker images --digests
REPOSITORY TAG DIGEST IMAGE ID CREATED SIZE
localhost:5000/test/busybox <none> sha256:cbbf2f9a99b47fc460d422812b6a5adff7dfee951d8fa2e4a98caa0382cfbdbf 4986bf8c1536 9 weeks ago 2.43 MB
When pushing or pulling to a 2.0 registry, the `push` or `pull` command
output includes the image digest. You can `pull` using a digest value. You can
also reference by digest in `create`, `run`, and `rmi` commands, as well as the
`FROM` image reference in a Dockerfile.
## Filtering
The filtering flag (`-f` or `--filter`) format is of "key=value". If there is more
than one filter, then pass multiple flags (e.g., `--filter "foo=bar" --filter "bif=baz"`)
The currently supported filters are:
* dangling (boolean - true or false)
* label (`label=<key>` or `label=<key>=<value>`)
* before (`<image-name>[:<tag>]`, `<image id>` or `<image@digest>`) - filters images created before given id or references
* since (`<image-name>[:<tag>]`, `<image id>` or `<image@digest>`) - filters images created since given id or references
##### Untagged images (dangling)
$ docker images --filter "dangling=true"
REPOSITORY TAG IMAGE ID CREATED SIZE
<none> <none> 8abc22fbb042 4 weeks ago 0 B
<none> <none> 48e5f45168b9 4 weeks ago 2.489 MB
<none> <none> bf747efa0e2f 4 weeks ago 0 B
<none> <none> 980fe10e5736 12 weeks ago 101.4 MB
<none> <none> dea752e4e117 12 weeks ago 101.4 MB
<none> <none> 511136ea3c5a 8 months ago 0 B
This will display untagged images, that are the leaves of the images tree (not
intermediary layers). These images occur when a new build of an image takes the
`repo:tag` away from the image ID, leaving it as `<none>:<none>` or untagged.
A warning will be issued if trying to remove an image when a container is presently
using it. By having this flag it allows for batch cleanup.
Ready for use by `docker rmi ...`, like:
$ docker rmi $(docker images -f "dangling=true" -q)
8abc22fbb042
48e5f45168b9
bf747efa0e2f
980fe10e5736
dea752e4e117
511136ea3c5a
NOTE: Docker will warn you if any containers exist that are using these untagged images.
##### Labeled images
The `label` filter matches images based on the presence of a `label` alone or a `label` and a
value.
The following filter matches images with the `com.example.version` label regardless of its value.
$ docker images --filter "label=com.example.version"
REPOSITORY TAG IMAGE ID CREATED SIZE
match-me-1 latest eeae25ada2aa About a minute ago 188.3 MB
match-me-2 latest dea752e4e117 About a minute ago 188.3 MB
The following filter matches images with the `com.example.version` label with the `1.0` value.
$ docker images --filter "label=com.example.version=1.0"
REPOSITORY TAG IMAGE ID CREATED SIZE
match-me latest 511136ea3c5a About a minute ago 188.3 MB
In this example, with the `0.1` value, it returns an empty set because no matches were found.
$ docker images --filter "label=com.example.version=0.1"
REPOSITORY TAG IMAGE ID CREATED SIZE
#### Before
The `before` filter shows only images created before the image with
given id or reference. For example, having these images:
$ docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
image1 latest eeae25ada2aa 4 minutes ago 188.3 MB
image2 latest dea752e4e117 9 minutes ago 188.3 MB
image3 latest 511136ea3c5a 25 minutes ago 188.3 MB
Filtering with `before` would give:
$ docker images --filter "before=image1"
REPOSITORY TAG IMAGE ID CREATED SIZE
image2 latest dea752e4e117 9 minutes ago 188.3 MB
image3 latest 511136ea3c5a 25 minutes ago 188.3 MB
#### Since
The `since` filter shows only images created after the image with
given id or reference. For example, having these images:
$ docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
image1 latest eeae25ada2aa 4 minutes ago 188.3 MB
image2 latest dea752e4e117 9 minutes ago 188.3 MB
image3 latest 511136ea3c5a 25 minutes ago 188.3 MB
Filtering with `since` would give:
$ docker images --filter "since=image3"
REPOSITORY TAG IMAGE ID CREATED SIZE
image1 latest eeae25ada2aa 4 minutes ago 188.3 MB
image2 latest dea752e4e117 9 minutes ago 188.3 MB
## Formatting
The formatting option (`--format`) will pretty print container output
using a Go template.
Valid placeholders for the Go template are listed below:
Placeholder | Description
---- | ----
`.ID` | Image ID
`.Repository` | Image repository
`.Tag` | Image tag
`.Digest` | Image digest
`.CreatedSince` | Elapsed time since the image was created.
`.CreatedAt` | Time when the image was created.
`.Size` | Image disk size.
When using the `--format` option, the `image` command will either
output the data exactly as the template declares or, when using the
`table` directive, will include column headers as well.
The following example uses a template without headers and outputs the
`ID` and `Repository` entries separated by a colon for all images:
{% raw %}
$ docker images --format "{{.ID}}: {{.Repository}}"
77af4d6b9913: <none>
b6fa739cedf5: committ
78a85c484f71: <none>
30557a29d5ab: docker
5ed6274db6ce: <none>
746b819f315e: postgres
746b819f315e: postgres
746b819f315e: postgres
746b819f315e: postgres
{% endraw %}
To list all images with their repository and tag in a table format you
can use:
{% raw %}
$ docker images --format "table {{.ID}}\t{{.Repository}}\t{{.Tag}}"
IMAGE ID REPOSITORY TAG
77af4d6b9913 <none> <none>
b6fa739cedf5 committ latest
78a85c484f71 <none> <none>
30557a29d5ab docker latest
5ed6274db6ce <none> <none>
746b819f315e postgres 9
746b819f315e postgres 9.3
746b819f315e postgres 9.3.5
746b819f315e postgres latest
{% endraw %}

67
engine/reference/commandline/import.md
View File

@ -1,67 +0,0 @@
---
redirect_from:
- /reference/commandline/import/
description: The import command description and usage
keywords:
- import, file, system, container
title: docker import
---
```markdown
Usage: docker import [OPTIONS] file|URL|- [REPOSITORY[:TAG]]
Import the contents from a tarball to create a filesystem image
Options:
-c, --change value Apply Dockerfile instruction to the created image (default [])
--help Print usage
-m, --message string Set commit message for imported image
```
You can specify a `URL` or `-` (dash) to take data directly from `STDIN`. The
`URL` can point to an archive (.tar, .tar.gz, .tgz, .bzip, .tar.xz, or .txz)
containing a filesystem or to an individual file on the Docker host. If you
specify an archive, Docker untars it in the container relative to the `/`
(root). If you specify an individual file, you must specify the full path within
the host. To import from a remote location, specify a `URI` that begins with the
`http://` or `https://` protocol.
The `--change` option will apply `Dockerfile` instructions to the image
that is created.
Supported `Dockerfile` instructions:
`CMD`|`ENTRYPOINT`|`ENV`|`EXPOSE`|`ONBUILD`|`USER`|`VOLUME`|`WORKDIR`
## Examples
**Import from a remote location:**
This will create a new untagged image.
$ docker import http://example.com/exampleimage.tgz
**Import from a local file:**
Import to docker via pipe and `STDIN`.
$ cat exampleimage.tgz | docker import - exampleimagelocal:new
Import with a commit message.
$ cat exampleimage.tgz | docker import --message "New image imported from tarball" - exampleimagelocal:new
Import to docker from a local archive.
$ docker import /path/to/exampleimage.tgz
**Import from a local directory:**
$ sudo tar -c . | docker import - exampleimagedir
**Import from a local directory with new configurations:**
$ sudo tar -c . | docker import --change "ENV DEBUG true" - exampleimagedir
Note the `sudo` in this example – you must preserve
the ownership of the files (especially root ownership) during the
archiving with tar. If you are not root (or the sudo command) when you
tar, then the ownerships might not get preserved.

135
engine/reference/commandline/index.md
View File

@ -1,135 +0,0 @@
---
redirect_from:
- /reference/commandline/
description: Docker's CLI command description and usage
keywords:
- Docker, Docker documentation, CLI, command line
title: The Docker commands
---
This section contains reference information on using Docker's command line
client. Each command has a reference page along with samples. If you are
unfamiliar with the command line, you should start by reading about how to [Use
the Docker command line](cli.md).
You start the Docker daemon with the command line. How you start the daemon
affects your Docker containers. For that reason you should also make sure to
read the [`dockerd`](dockerd.md) reference page.
### Docker management commands
| Command | Description |
|:--------|:-------------------------------------------------------------------|
| [dockerd](dockerd.md) | Launch the Docker daemon |
| [info](info.md) | Display system-wide information |
| [inspect](inspect.md)| Return low-level information on a container or image |
| [version](version.md) | Show the Docker version information |
### Image commands
| Command | Description |
|:--------|:-------------------------------------------------------------------|
| [build](build.md) | Build an image from a Dockerfile |
| [commit](commit.md) | Create a new image from a container's changes |
| [history](history.md) | Show the history of an image |
| [images](images.md) | List images |
| [import](import.md) | Import the contents from a tarball to create a filesystem image |
| [load](load.md) | Load an image from a tar archive or STDIN |
| [rmi](rmi.md) | Remove one or more images |
| [save](save.md) | Save images to a tar archive |
| [tag](tag.md) | Tag an image into a repository |
### Container commands
| Command | Description |
|:--------|:-------------------------------------------------------------------|
| [attach](attach.md) | Attach to a running container |
| [cp](cp.md) | Copy files/folders from a container to a HOSTDIR or to STDOUT |
| [create](create.md) | Create a new container |
| [diff](diff.md) | Inspect changes on a container's filesystem |
| [events](events.md) | Get real time events from the server |
| [exec](exec.md) | Run a command in a running container |
| [export](export.md) | Export a container's filesystem as a tar archive |
| [kill](kill.md) | Kill a running container |
| [logs](logs.md) | Fetch the logs of a container |
| [pause](pause.md) | Pause all processes within a container |
| [port](port.md) | List port mappings or a specific mapping for the container |
| [ps](ps.md) | List containers |
| [rename](rename.md) | Rename a container |
| [restart](restart.md) | Restart a running container |
| [rm](rm.md) | Remove one or more containers |
| [run](run.md) | Run a command in a new container |
| [start](start.md) | Start one or more stopped containers |
| [stats](stats.md) | Display a live stream of container(s) resource usage statistics |
| [stop](stop.md) | Stop a running container |
| [top](top.md) | Display the running processes of a container |
| [unpause](unpause.md) | Unpause all processes within a container |
| [update](update.md) | Update configuration of one or more containers |
| [wait](wait.md) | Block until a container stops, then print its exit code |
### Hub and registry commands
| Command | Description |
|:--------|:-------------------------------------------------------------------|
| [login](login.md) | Register or log in to a Docker registry |
| [logout](logout.md) | Log out from a Docker registry |
| [pull](pull.md) | Pull an image or a repository from a Docker registry |
| [push](push.md) | Push an image or a repository to a Docker registry |
| [search](search.md) | Search the Docker Hub for images |
### Network and connectivity commands
| Command | Description |
|:--------|:-------------------------------------------------------------------|
| [network connect](network_connect.md) | Connect a container to a network |
| [network create](network_create.md) | Create a new network |
| [network disconnect](network_disconnect.md) | Disconnect a container from a network |
| [network inspect](network_inspect.md) | Display information about a network |
| [network ls](network_ls.md) | Lists all the networks the Engine `daemon` knows about |
| [network rm](network_rm.md) | Removes one or more networks |
### Shared data volume commands
| Command | Description |
|:--------|:-------------------------------------------------------------------|
| [volume create](volume_create.md) | Creates a new volume where containers can consume and store data |
| [volume inspect](volume_inspect.md) | Display information about a volume |
| [volume ls](volume_ls.md) | Lists all the volumes Docker knows about |
| [volume rm](volume_rm.md) | Remove one or more volumes |
### Swarm node commands
| Command | Description |
|:--------|:-------------------------------------------------------------------|
| [node promote](node_promote.md) | Promote a node that is pending a promotion to manager |
| [node demote](node_demote.md) | Demotes an existing manager so that it is no longer a manager |
| [node inspect](node_inspect.md) | Inspect a node in the swarm |
| [node update](node_update.md) | Update attributes for a node |
| [node ps](node_ps.md) | List tasks running on a node |
| [node ls](node_ls.md) | List nodes in the swarm |
| [node rm](node_rm.md) | Remove one or more nodes from the swarm |
### Swarm swarm commands
| Command | Description |
|:--------|:-------------------------------------------------------------------|
| [swarm init](swarm_init.md) | Initialize a swarm |
| [swarm join](swarm_join.md) | Join a swarm as a manager node or worker node |
| [swarm leave](swarm_leave.md) | Remove the current node from the swarm |
| [swarm update](swarm_update.md) | Update attributes of a swarm |
| [swarm join-token](swarm_join_token.md) | Display or rotate join tokens |
### Swarm service commands
| Command | Description |
|:--------|:-------------------------------------------------------------------|
| [service create](service_create.md) | Create a new service |
| [service inspect](service_inspect.md) | Inspect a service |
| [service ls](service_ls.md) | List services in the swarm |
| [service rm](service_rm.md) | Remove a service from the swarm |
| [service scale](service_scale.md) | Set the number of replicas for the desired state of the service |
| [service ps](service_ps.md) | List the tasks of a service |
| [service update](service_update.md) | Update the attributes of a service |

143
engine/reference/commandline/info.md
View File

@ -1,143 +0,0 @@
---
redirect_from:
- /reference/commandline/info/
description: The info command description and usage
keywords:
- display, docker, information
title: docker info
---
```markdown
Usage: docker info
Display system-wide information
Options:
--help Print usage
```
This command displays system wide information regarding the Docker installation.
Information displayed includes the kernel version, number of containers and images.
The number of images shown is the number of unique images. The same image tagged
under different names is counted only once.
Depending on the storage driver in use, additional information can be shown, such
as pool name, data file, metadata file, data space used, total data space, metadata
space used, and total metadata space.
The data file is where the images are stored and the metadata file is where the
meta data regarding those images are stored. When run for the first time Docker
allocates a certain amount of data space and meta data space from the space
available on the volume where `/var/lib/docker` is mounted.
# Examples
## Display Docker system information
Here is a sample output for a daemon running on Ubuntu, using the overlay
storage driver and a node that is part of a 2-node swarm:
$ docker -D info
Containers: 14
Running: 3
Paused: 1
Stopped: 10
Images: 52
Server Version: 1.12.0-dev
Storage Driver: overlay
Backing Filesystem: extfs
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
Volume: local
Network: bridge null host overlay
Swarm:
NodeID: 0gac67oclbxq7
Is Manager: true
Managers: 2
Nodes: 2
Runtimes: default
Default Runtime: default
Security Options: apparmor seccomp
Kernel Version: 4.4.0-21-generic
Operating System: Ubuntu 16.04 LTS
OSType: linux
Architecture: x86_64
CPUs: 24
Total Memory: 62.86 GiB
Name: docker
ID: I54V:OLXT:HVMM:TPKO:JPHQ:CQCD:JNLC:O3BZ:4ZVJ:43XJ:PFHZ:6N2S
Docker Root Dir: /var/lib/docker
Debug mode (client): true
Debug mode (server): true
File Descriptors: 59
Goroutines: 159
System Time: 2016-04-26T10:04:06.14689342-04:00
EventsListeners: 0
Http Proxy: http://test:test@localhost:8080
Https Proxy: https://test:test@localhost:8080
No Proxy: localhost,127.0.0.1,docker-registry.somecorporation.com
Username: svendowideit
Registry: https://index.docker.io/v1/
WARNING: No swap limit support
Labels:
storage=ssd
staging=true
Insecure registries:
myinsecurehost:5000
127.0.0.0/8
The global `-D` option tells all `docker` commands to output debug information.
The example below shows the output for a daemon running on Red Hat Enterprise Linux,
using the devicemapper storage driver. As can be seen in the output, additional
information about the devicemapper storage driver is shown:
$ docker info
Containers: 14
Running: 3
Paused: 1
Stopped: 10
Untagged Images: 52
Server Version: 1.10.3
Storage Driver: devicemapper
Pool Name: docker-202:2-25583803-pool
Pool Blocksize: 65.54 kB
Base Device Size: 10.74 GB
Backing Filesystem: xfs
Data file: /dev/loop0
Metadata file: /dev/loop1
Data Space Used: 1.68 GB
Data Space Total: 107.4 GB
Data Space Available: 7.548 GB
Metadata Space Used: 2.322 MB
Metadata Space Total: 2.147 GB
Metadata Space Available: 2.145 GB
Udev Sync Supported: true
Deferred Removal Enabled: false
Deferred Deletion Enabled: false
Deferred Deleted Device Count: 0
Data loop file: /var/lib/docker/devicemapper/devicemapper/data
Metadata loop file: /var/lib/docker/devicemapper/devicemapper/metadata
Library Version: 1.02.107-RHEL7 (2015-12-01)
Execution Driver: native-0.2
Logging Driver: json-file
Plugins:
Volume: local
Network: null host bridge
Kernel Version: 3.10.0-327.el7.x86_64
Operating System: Red Hat Enterprise Linux Server 7.2 (Maipo)
OSType: linux
Architecture: x86_64
CPUs: 1
Total Memory: 991.7 MiB
Name: ip-172-30-0-91.ec2.internal
ID: I54V:OLXT:HVMM:TPKO:JPHQ:CQCD:JNLC:O3BZ:4ZVJ:43XJ:PFHZ:6N2S
Docker Root Dir: /var/lib/docker
Debug mode (client): false
Debug mode (server): false
Username: xyz
Registry: https://index.docker.io/v1/
Insecure registries:
myinsecurehost:5000
127.0.0.0/8

93
engine/reference/commandline/inspect.md
View File

@ -1,93 +0,0 @@
---
redirect_from:
- /reference/commandline/inspect/
description: The inspect command description and usage
keywords:
- inspect, container, json
title: docker inspect
---
```markdown
Usage: docker inspect [OPTIONS] CONTAINER|IMAGE|TASK [CONTAINER|IMAGE|TASK...]
Return low-level information on a container, image or task
-f, --format Format the output using the given go template
--help Print usage
-s, --size Display total file sizes if the type is container
values are "image" or "container" or "task
--type Return JSON for specified type, (e.g image, container or task)
```
By default, this will render all results in a JSON array. If the container and
image have the same name, this will return container JSON for unspecified type.
If a format is specified, the given template will be executed for each result.
Go's [text/template](http://golang.org/pkg/text/template/) package
describes all the details of the format.
## Examples
**Get an instance's IP address:**
For the most part, you can pick out any field from the JSON in a fairly
straightforward manner.
{% raw %}
$ docker inspect --format='{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' $INSTANCE_ID
{% endraw %}
**Get an instance's MAC address:**
For the most part, you can pick out any field from the JSON in a fairly
straightforward manner.
{% raw %}
$ docker inspect --format='{{range .NetworkSettings.Networks}}{{.MacAddress}}{{end}}' $INSTANCE_ID
{% endraw %}
**Get an instance's log path:**
{% raw %}
$ docker inspect --format='{{.LogPath}}' $INSTANCE_ID
{% endraw %}
**Get a Task's image name:**
{% raw %}
$ docker inspect --format='{{.Container.Spec.Image}}' $INSTANCE_ID
{% endraw %}
**List all port bindings:**
One can loop over arrays and maps in the results to produce simple text
output:
{% raw %}
$ docker inspect --format='{{range $p, $conf := .NetworkSettings.Ports}} {{$p}} -> {{(index $conf 0).HostPort}} {{end}}' $INSTANCE_ID
{% endraw %}
**Find a specific port mapping:**
The `.Field` syntax doesn't work when the field name begins with a
number, but the template language's `index` function does. The
`.NetworkSettings.Ports` section contains a map of the internal port
mappings to a list of external address/port objects. To grab just the
numeric public port, you use `index` to find the specific port map, and
then `index` 0 contains the first object inside of that. Then we ask for
the `HostPort` field to get the public address.
{% raw %}
$ docker inspect --format='{{(index (index .NetworkSettings.Ports "8787/tcp") 0).HostPort}}' $INSTANCE_ID
{% endraw %}
**Get a subsection in JSON format:**
If you request a field which is itself a structure containing other
fields, by default you get a Go-style dump of the inner values.
Docker adds a template function, `json`, which can be applied to get
results in JSON format.
{% raw %}
$ docker inspect --format='{{json .Config}}' $INSTANCE_ID
{% endraw %}

26
engine/reference/commandline/kill.md
View File

@ -1,26 +0,0 @@
---
redirect_from:
- /reference/commandline/kill/
description: The kill command description and usage
keywords:
- container, kill, signal
title: docker kill
---
```markdown
Usage: docker kill [OPTIONS] CONTAINER [CONTAINER...]
Kill one or more running containers
Options:
--help Print usage
-s, --signal string Signal to send to the container (default "KILL")
```
The main process inside the container will be sent `SIGKILL`, or any
signal specified with option `--signal`.
> **Note:**
> `ENTRYPOINT` and `CMD` in the *shell* form run as a subcommand of `/bin/sh -c`,
> which does not pass signals. This means that the executable is not the container’s PID 1
> and does not receive Unix signals.

45
engine/reference/commandline/load.md
View File

@ -1,45 +0,0 @@
---
redirect_from:
- /reference/commandline/load/
description: The load command description and usage
keywords:
- stdin, tarred, repository
title: docker load
---
```markdown
Usage: docker load [OPTIONS]
Load an image from a tar archive or STDIN
Options:
--help Print usage
-i, --input string Read from tar archive file, instead of STDIN.
The tarball may be compressed with gzip, bzip, or xz
-q, --quiet Suppress the load output but still outputs the imported images
```
Loads a tarred repository from a file or the standard input stream.
Restores both images and tags.
$ docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
$ docker load < busybox.tar.gz
# […]
Loaded image: busybox:latest
$ docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
busybox latest 769b9341d937 7 weeks ago 2.489 MB
$ docker load --input fedora.tar
# […]
Loaded image: fedora:rawhide
# […]
Loaded image: fedora:20
# […]
$ docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
busybox latest 769b9341d937 7 weeks ago 2.489 MB
fedora rawhide 0d20aec6529d 7 weeks ago 387 MB
fedora 20 58394af37342 7 weeks ago 385.5 MB
fedora heisenbug 58394af37342 7 weeks ago 385.5 MB
fedora latest 58394af37342 7 weeks ago 385.5 MB

114
engine/reference/commandline/login.md
View File

@ -1,114 +0,0 @@
---
redirect_from:
- /reference/commandline/login/
description: The login command description and usage
keywords:
- registry, login, image
title: docker login
---
```markdown
Usage: docker login [OPTIONS] [SERVER]
Log in to a Docker registry.
If no server is specified, the default is defined by the daemon.
Options:
--help Print usage
-p, --password string Password
-u, --username string Username
```
If you want to login to a self-hosted registry you can specify this by
adding the server name.
example:
$ docker login localhost:8080
`docker login` requires user to use `sudo` or be `root`, except when:
1. connecting to a remote daemon, such as a `docker-machine` provisioned `docker engine`.
2. user is added to the `docker` group. This will impact the security of your system; the `docker` group is `root` equivalent. See [Docker Daemon Attack Surface](/security/security/#docker-daemon-attack-surface) for details.
You can log into any public or private repository for which you have
credentials. When you log in, the command stores encoded credentials in
`$HOME/.docker/config.json` on Linux or `%USERPROFILE%/.docker/config.json` on Windows.
## Credentials store
The Docker Engine can keep user credentials in an external credentials store,
such as the native keychain of the operating system. Using an external store
is more secure than storing credentials in the Docker configuration file.
To use a credentials store, you need an external helper program to interact
with a specific keychain or external store. Docker requires the helper
program to be in the client's host `$PATH`.
This is the list of currently available credentials helpers and where
you can download them from:
- D-Bus Secret Service: https://github.com/docker/docker-credential-helpers/releases
- Apple macOS keychain: https://github.com/docker/docker-credential-helpers/releases
- Microsoft Windows Credential Manager: https://github.com/docker/docker-credential-helpers/releases
### Usage
You need to specify the credentials store in `$HOME/.docker/config.json`
to tell the docker engine to use it:
```json
{
"credsStore": "osxkeychain"
}
```
If you are currently logged in, run `docker logout` to remove
the credentials from the file and run `docker login` again.
### Protocol
Credential helpers can be any program or script that follows a very simple protocol.
This protocol is heavily inspired by Git, but it differs in the information shared.
The helpers always use the first argument in the command to identify the action.
There are only three possible values for that argument: `store`, `get`, and `erase`.
The `store` command takes a JSON payload from the standard input. That payload carries
the server address, to identify the credential, the user name, and either a password
or an identity token.
```json
{
"ServerURL": "https://index.docker.io/v1",
"Username": "david",
"Secret": "passw0rd1"
}
```
If the secret being stored is an identity token, the Username should be set to
`<token>`.
The `store` command can write error messages to `STDOUT` that the docker engine
will show if there was an issue.
The `get` command takes a string payload from the standard input. That payload carries
the server address that the docker engine needs credentials for. This is
an example of that payload: `https://index.docker.io/v1`.
The `get` command writes a JSON payload to `STDOUT`. Docker reads the user name
and password from this payload:
```json
{
"Username": "david",
"Secret": "passw0rd1"
}
```
The `erase` command takes a string payload from `STDIN`. That payload carries
the server address that the docker engine wants to remove credentials for. This is
an example of that payload: `https://index.docker.io/v1`.
The `erase` command can write error messages to `STDOUT` that the docker engine
will show if there was an issue.

22
engine/reference/commandline/logout.md
View File

@ -1,22 +0,0 @@
---
redirect_from:
- /reference/commandline/logout/
description: The logout command description and usage
keywords:
- logout, docker, registry
title: docker logout
---
```markdown
Usage: docker logout [SERVER]
Log out from a Docker registry.
If no server is specified, the default is defined by the daemon.
Options:
--help Print usage
```
For example:
$ docker logout localhost:8080

58
engine/reference/commandline/logs.md
View File

@ -1,58 +0,0 @@
---
redirect_from:
- /reference/commandline/logs/
description: The logs command description and usage
keywords:
- logs, retrieve, docker
title: docker logs
---
```markdown
Usage: docker logs [OPTIONS] CONTAINER
Fetch the logs of a container
Options:
--details Show extra details provided to logs
-f, --follow Follow log output
--help Print usage
--since string Show logs since timestamp
--tail string Number of lines to show from the end of the logs (default "all")
-t, --timestamps Show timestamps
```
The `docker logs` command batch-retrieves logs present at the time of execution.
> **Note**: this command is only functional for containers that are started with
> the `json-file` or `journald` logging driver.
For more information about selecting and configuring login-drivers, refer to
[Configure logging drivers](../../admin/logging/overview.md).
The `docker logs --follow` command will continue streaming the new output from
the container's `STDOUT` and `STDERR`.
Passing a negative number or a non-integer to `--tail` is invalid and the
value is set to `all` in that case.
The `docker logs --timestamps` command will add an [RFC3339Nano timestamp](https://golang.org/pkg/time/#pkg-constants)
, for example `2014-09-16T06:17:46.000000000Z`, to each
log entry. To ensure that the timestamps are aligned the
nano-second part of the timestamp will be padded with zero when necessary.
The `docker logs --details` command will add on extra attributes, such as
environment variables and labels, provided to `--log-opt` when creating the
container.
The `--since` option shows only the container logs generated after
a given date. You can specify the date as an RFC 3339 date, a UNIX
timestamp, or a Go duration string (e.g. `1m30s`, `3h`). Besides RFC3339 date
format you may also use RFC3339Nano, `2006-01-02T15:04:05`,
`2006-01-02T15:04:05.999999999`, `2006-01-02Z07:00`, and `2006-01-02`. The local
timezone on the client will be used if you do not provide either a `Z` or a
`+-00:00` timezone offset at the end of the timestamp. When providing Unix
timestamps enter seconds[.nanoseconds], where seconds is the number of seconds
that have elapsed since January 1, 1970 (midnight UTC/GMT), not counting leap
seconds (aka Unix epoch or Unix time), and the optional .nanoseconds field is a
fraction of a second no more than nine digits long. You can combine the
`--since` option with either or both of the `--follow` or `--tail` options.

94
engine/reference/commandline/network_connect.md
View File

@ -1,94 +0,0 @@
---
redirect_from:
- /reference/commandline/network_connect/
description: The network connect command description and usage
keywords:
- network, connect, user-defined
title: docker network connect
---
```markdown
Usage: docker network connect [OPTIONS] NETWORK CONTAINER
Connect a container to a network
Options:
--alias value Add network-scoped alias for the container (default [])
--help Print usage
--ip string IP Address
--ip6 string IPv6 Address
--link value Add link to another container (default [])
--link-local-ip value Add a link-local address for the container (default [])
```
Connects a container to a network. You can connect a container by name
or by ID. Once connected, the container can communicate with other containers in
the same network.
```bash
$ docker network connect multi-host-network container1
```
You can also use the `docker run --network=<network-name>` option to start a container and immediately connect it to a network.
```bash
$ docker run -itd --network=multi-host-network busybox
```
You can specify the IP address you want to be assigned to the container's interface.
```bash
$ docker network connect --ip 10.10.36.122 multi-host-network container2
```
You can use `--link` option to link another container with a preferred alias
```bash
$ docker network connect --link container1:c1 multi-host-network container2
```
`--alias` option can be used to resolve the container by another name in the network
being connected to.
```bash
$ docker network connect --alias db --alias mysql multi-host-network container2
```
You can pause, restart, and stop containers that are connected to a network.
Paused containers remain connected and can be revealed by a `network inspect`.
When the container is stopped, it does not appear on the network until you restart
it.
If specified, the container's IP address(es) is reapplied when a stopped
container is restarted. If the IP address is no longer available, the container
fails to start. One way to guarantee that the IP address is available is
to specify an `--ip-range` when creating the network, and choose the static IP
address(es) from outside that range. This ensures that the IP address is not
given to another container while this container is not on the network.
```bash
$ docker network create --subnet 172.20.0.0/16 --ip-range 172.20.240.0/20 multi-host-network
```
```bash
$ docker network connect --ip 172.20.128.2 multi-host-network container2
```
To verify the container is connected, use the `docker network inspect` command. Use `docker network disconnect` to remove a container from the network.
Once connected in network, containers can communicate using only another
container's IP address or name. For `overlay` networks or custom plugins that
support multi-host connectivity, containers connected to the same multi-host
network but launched from different Engines can also communicate in this way.
You can connect a container to one or more networks. The networks need not be the same type. For example, you can connect a single container bridge and overlay networks.
## Related information
* [network inspect](network_inspect.md)
* [network create](network_create.md)
* [network disconnect](network_disconnect.md)
* [network ls](network_ls.md)
* [network rm](network_rm.md)
* [Understand Docker container networks](../../userguide/networking/index.md)
* [Work with networks](../../userguide/networking/work-with-networks.md)

192
engine/reference/commandline/network_create.md
View File

@ -1,192 +0,0 @@
---
redirect_from:
- /reference/commandline/network_create/
description: The network create command description and usage
keywords:
- network, create
title: docker network create
---
```markdown
Usage: docker network create [OPTIONS] NETWORK
Create a network
Options:
--aux-address value Auxiliary IPv4 or IPv6 addresses used by Network
driver (default map[])
-d, --driver string Driver to manage the Network (default "bridge")
--gateway value IPv4 or IPv6 Gateway for the master subnet (default [])
--help Print usage
--internal Restrict external access to the network
--ip-range value Allocate container ip from a sub-range (default [])
--ipam-driver string IP Address Management Driver (default "default")
--ipam-opt value Set IPAM driver specific options (default map[])
--ipv6 Enable IPv6 networking
--label value Set metadata on a network (default [])
-o, --opt value Set driver specific options (default map[])
--subnet value Subnet in CIDR format that represents a
network segment (default [])
```
Creates a new network. The `DRIVER` accepts `bridge` or `overlay` which are the
built-in network drivers. If you have installed a third party or your own custom
network driver you can specify that `DRIVER` here also. If you don't specify the
`--driver` option, the command automatically creates a `bridge` network for you.
When you install Docker Engine it creates a `bridge` network automatically. This
network corresponds to the `docker0` bridge that Engine has traditionally relied
on. When you launch a new container with `docker run` it automatically connects to
this bridge network. You cannot remove this default bridge network, but you can
create new ones using the `network create` command.
```bash
$ docker network create -d bridge my-bridge-network
```
Bridge networks are isolated networks on a single Engine installation. If you
want to create a network that spans multiple Docker hosts each running an
Engine, you must create an `overlay` network. Unlike `bridge` networks, overlay
networks require some pre-existing conditions before you can create one. These
conditions are:
* Access to a key-value store. Engine supports Consul, Etcd, and ZooKeeper (Distributed store) key-value stores.
* A cluster of hosts with connectivity to the key-value store.
* A properly configured Engine `daemon` on each host in the cluster.
The `dockerd` options that support the `overlay` network are:
* `--cluster-store`
* `--cluster-store-opt`
* `--cluster-advertise`
To read more about these options and how to configure them, see ["*Get started
with multi-host network*"](../../userguide/networking/get-started-overlay.md).
While not required, it is a good idea to install Docker Swarm to
manage the cluster that makes up your network. Swarm provides sophisticated
discovery and server management tools that can assist your implementation.
Once you have prepared the `overlay` network prerequisites you simply choose a
Docker host in the cluster and issue the following to create the network:
```bash
$ docker network create -d overlay my-multihost-network
```
Network names must be unique. The Docker daemon attempts to identify naming
conflicts but this is not guaranteed. It is the user's responsibility to avoid
name conflicts.
## Connect containers
When you start a container, use the `--network` flag to connect it to a network.
This example adds the `busybox` container to the `mynet` network:
```bash
$ docker run -itd --network=mynet busybox
```
If you want to add a container to a network after the container is already
running, use the `docker network connect` subcommand.
You can connect multiple containers to the same network. Once connected, the
containers can communicate using only another container's IP address or name.
For `overlay` networks or custom plugins that support multi-host connectivity,
containers connected to the same multi-host network but launched from different
Engines can also communicate in this way.
You can disconnect a container from a network using the `docker network
disconnect` command.
## Specifying advanced options
When you create a network, Engine creates a non-overlapping subnetwork for the
network by default. This subnetwork is not a subdivision of an existing
network. It is purely for ip-addressing purposes. You can override this default
and specify subnetwork values directly using the `--subnet` option. On a
`bridge` network you can only create a single subnet:
```bash
$ docker network create --driver=bridge --subnet=192.168.0.0/16 br0
```
Additionally, you also specify the `--gateway` `--ip-range` and `--aux-address`
options.
```bash
$ docker network create \
--driver=bridge \
--subnet=172.28.0.0/16 \
--ip-range=172.28.5.0/24 \
--gateway=172.28.5.254 \
br0
```
If you omit the `--gateway` flag the Engine selects one for you from inside a
preferred pool. For `overlay` networks and for network driver plugins that
support it you can create multiple subnetworks.
```bash
$ docker network create -d overlay \
--subnet=192.168.0.0/16 \
--subnet=192.170.0.0/16 \
--gateway=192.168.0.100 \
--gateway=192.170.0.100 \
--ip-range=192.168.1.0/24 \
--aux-address="my-router=192.168.1.5" --aux-address="my-switch=192.168.1.6" \
--aux-address="my-printer=192.170.1.5" --aux-address="my-nas=192.170.1.6" \
my-multihost-network
```
Be sure that your subnetworks do not overlap. If they do, the network create
fails and Engine returns an error.
# Bridge driver options
When creating a custom network, the default network driver (i.e. `bridge`) has
additional options that can be passed. The following are those options and the
equivalent docker daemon flags used for docker0 bridge:
| Option | Equivalent | Description |
|--------------------------------------------------|-------------|-------------------------------------------------------|
| `com.docker.network.bridge.name` | - | bridge name to be used when creating the Linux bridge |
| `com.docker.network.bridge.enable_ip_masquerade` | `--ip-masq` | Enable IP masquerading |
| `com.docker.network.bridge.enable_icc` | `--icc` | Enable or Disable Inter Container Connectivity |
| `com.docker.network.bridge.host_binding_ipv4` | `--ip` | Default IP when binding container ports |
| `com.docker.network.driver.mtu` | `--mtu` | Set the containers network MTU |
The following arguments can be passed to `docker network create` for any
network driver, again with their approximate equivalents to `docker daemon`.
| Argument | Equivalent | Description |
|--------------|----------------|--------------------------------------------|
| `--gateway` | - | IPv4 or IPv6 Gateway for the master subnet |
| `--ip-range` | `--fixed-cidr` | Allocate IPs from a range |
| `--internal` | - | Restrict external access to the network |
| `--ipv6` | `--ipv6` | Enable IPv6 networking |
| `--subnet` | `--bip` | Subnet for network |
For example, let's use `-o` or `--opt` options to specify an IP address binding
when publishing ports:
```bash
$ docker network create \
-o "com.docker.network.bridge.host_binding_ipv4"="172.19.0.1" \
simple-network
```
### Network internal mode
By default, when you connect a container to an `overlay` network, Docker also
connects a bridge network to it to provide external connectivity. If you want
to create an externally isolated `overlay` network, you can specify the
`--internal` option.
## Related information
* [network inspect](network_inspect.md)
* [network connect](network_connect.md)
* [network disconnect](network_disconnect.md)
* [network ls](network_ls.md)
* [network rm](network_rm.md)
* [Understand Docker container networks](../../userguide/networking/index.md)

34
engine/reference/commandline/network_disconnect.md
View File

@ -1,34 +0,0 @@
---
redirect_from:
- /reference/commandline/network_disconnect/
description: The network disconnect command description and usage
keywords:
- network, disconnect, user-defined
title: docker network disconnect
---
```markdown
Usage: docker network disconnect [OPTIONS] NETWORK CONTAINER
Disconnect a container from a network
Options:
-f, --force Force the container to disconnect from a network
--help Print usage
```
Disconnects a container from a network. The container must be running to disconnect it from the network.
```bash
$ docker network disconnect multi-host-network container1
```
## Related information
* [network inspect](network_inspect.md)
* [network connect](network_connect.md)
* [network create](network_create.md)
* [network ls](network_ls.md)
* [network rm](network_rm.md)
* [Understand Docker container networks](../../userguide/networking/index.md)

119
engine/reference/commandline/network_inspect.md
View File

@ -1,119 +0,0 @@
---
redirect_from:
- /reference/commandline/network_inspect/
description: The network inspect command description and usage
keywords:
- network, inspect, user-defined
title: docker network inspect
---
```markdown
Usage: docker network inspect [OPTIONS] NETWORK [NETWORK...]
Display detailed information on one or more networks
Options:
-f, --format string Format the output using the given go template
--help Print usage
```
Returns information about one or more networks. By default, this command renders all results in a JSON object. For example, if you connect two containers to the default `bridge` network:
```bash
$ sudo docker run -itd --name=container1 busybox
f2870c98fd504370fb86e59f32cd0753b1ac9b69b7d80566ffc7192a82b3ed27
$ sudo docker run -itd --name=container2 busybox
bda12f8922785d1f160be70736f26c1e331ab8aaf8ed8d56728508f2e2fd4727
```
The `network inspect` command shows the containers, by id, in its
results. For networks backed by multi-host network driver, such as Overlay,
this command also shows the container endpoints in other hosts in the
cluster. These endpoints are represented as "ep-{endpoint-id}" in the output.
You can specify an alternate format to execute a given
template for each result. Go's
[text/template](http://golang.org/pkg/text/template/) package describes all the
details of the format.
```bash
$ sudo docker network inspect bridge
[
{
"Name": "bridge",
"Id": "b2b1a2cba717161d984383fd68218cf70bbbd17d328496885f7c921333228b0f",
"Scope": "local",
"Driver": "bridge",
"IPAM": {
"Driver": "default",
"Config": [
{
"Subnet": "172.17.42.1/16",
"Gateway": "172.17.42.1"
}
]
},
"Internal": false,
"Containers": {
"bda12f8922785d1f160be70736f26c1e331ab8aaf8ed8d56728508f2e2fd4727": {
"Name": "container2",
"EndpointID": "0aebb8fcd2b282abe1365979536f21ee4ceaf3ed56177c628eae9f706e00e019",
"MacAddress": "02:42:ac:11:00:02",
"IPv4Address": "172.17.0.2/16",
"IPv6Address": ""
},
"f2870c98fd504370fb86e59f32cd0753b1ac9b69b7d80566ffc7192a82b3ed27": {
"Name": "container1",
"EndpointID": "a00676d9c91a96bbe5bcfb34f705387a33d7cc365bac1a29e4e9728df92d10ad",
"MacAddress": "02:42:ac:11:00:01",
"IPv4Address": "172.17.0.1/16",
"IPv6Address": ""
}
},
"Options": {
"com.docker.network.bridge.default_bridge": "true",
"com.docker.network.bridge.enable_icc": "true",
"com.docker.network.bridge.enable_ip_masquerade": "true",
"com.docker.network.bridge.host_binding_ipv4": "0.0.0.0",
"com.docker.network.bridge.name": "docker0",
"com.docker.network.driver.mtu": "1500"
}
}
]
```
Returns the information about the user-defined network:
```bash
$ docker network create simple-network
69568e6336d8c96bbf57869030919f7c69524f71183b44d80948bd3927c87f6a
$ docker network inspect simple-network
[
{
"Name": "simple-network",
"Id": "69568e6336d8c96bbf57869030919f7c69524f71183b44d80948bd3927c87f6a",
"Scope": "local",
"Driver": "bridge",
"IPAM": {
"Driver": "default",
"Config": [
{
"Subnet": "172.22.0.0/16",
"Gateway": "172.22.0.1/16"
}
]
},
"Containers": {},
"Options": {}
}
]
```
## Related information
* [network disconnect ](network_disconnect.md)
* [network connect](network_connect.md)
* [network create](network_create.md)
* [network ls](network_ls.md)
* [network rm](network_rm.md)
* [Understand Docker container networks](../../userguide/networking/index.md)

176
engine/reference/commandline/network_ls.md
View File

@ -1,176 +0,0 @@
---
redirect_from:
- /reference/commandline/network_ls/
description: The network ls command description and usage
keywords:
- network, list, user-defined
title: docker network ls
---
```markdown
Usage: docker network ls [OPTIONS]
List networks
Aliases:
ls, list
Options:
-f, --filter value Provide filter values (i.e. 'dangling=true') (default [])
--help Print usage
--no-trunc Do not truncate the output
-q, --quiet Only display network IDs
```
Lists all the networks the Engine `daemon` knows about. This includes the
networks that span across multiple hosts in a cluster, for example:
```bash
$ sudo docker network ls
NETWORK ID NAME DRIVER
7fca4eb8c647 bridge bridge
9f904ee27bf5 none null
cf03ee007fb4 host host
78b03ee04fc4 multi-host overlay
```
Use the `--no-trunc` option to display the full network id:
```bash
docker network ls --no-trunc
NETWORK ID NAME DRIVER
18a2866682b85619a026c81b98a5e375bd33e1b0936a26cc497c283d27bae9b3 none null
c288470c46f6c8949c5f7e5099b5b7947b07eabe8d9a27d79a9cbf111adcbf47 host host
7b369448dccbf865d397c8d2be0cda7cf7edc6b0945f77d2529912ae917a0185 bridge bridge
95e74588f40db048e86320c6526440c504650a1ff3e9f7d60a497c4d2163e5bd foo bridge
63d1ff1f77b07ca51070a8c227e962238358bd310bde1529cf62e6c307ade161 dev bridge
```
## Filtering
The filtering flag (`-f` or `--filter`) format is a `key=value` pair. If there
is more than one filter, then pass multiple flags (e.g. `--filter "foo=bar" --filter "bif=baz"`).
Multiple filter flags are combined as an `OR` filter. For example,
`-f type=custom -f type=builtin` returns both `custom` and `builtin` networks.
The currently supported filters are:
* driver
* id (network's id)
* label (`label=<key>` or `label=<key>=<value>`)
* name (network's name)
* type (custom|builtin)
#### Driver
The `driver` filter matches networks based on their driver.
The following example matches networks with the `bridge` driver:
```bash
$ docker network ls --filter driver=bridge
NETWORK ID NAME DRIVER
db9db329f835 test1 bridge
f6e212da9dfd test2 bridge
```
#### ID
The `id` filter matches on all or part of a network's ID.
The following filter matches all networks with an ID containing the
`63d1ff1f77b0...` string.
```bash
$ docker network ls --filter id=63d1ff1f77b07ca51070a8c227e962238358bd310bde1529cf62e6c307ade161
NETWORK ID NAME DRIVER
63d1ff1f77b0 dev bridge
```
You can also filter for a substring in an ID as this shows:
```bash
$ docker network ls --filter id=95e74588f40d
NETWORK ID NAME DRIVER
95e74588f40d foo bridge
$ docker network ls --filter id=95e
NETWORK ID NAME DRIVER
95e74588f40d foo bridge
```
#### Label
The `label` filter matches networks based on the presence of a `label` alone or a `label` and a
value.
The following filter matches networks with the `usage` label regardless of its value.
```bash
$ docker network ls -f "label=usage"
NETWORK ID NAME DRIVER
db9db329f835 test1 bridge
f6e212da9dfd test2 bridge
```
The following filter matches networks with the `usage` label with the `prod` value.
```bash
$ docker network ls -f "label=usage=prod"
NETWORK ID NAME DRIVER
f6e212da9dfd test2 bridge
```
#### Name
The `name` filter matches on all or part of a network's name.
The following filter matches all networks with a name containing the `foobar` string.
```bash
$ docker network ls --filter name=foobar
NETWORK ID NAME DRIVER
06e7eef0a170 foobar bridge
```
You can also filter for a substring in a name as this shows:
```bash
$ docker network ls --filter name=foo
NETWORK ID NAME DRIVER
95e74588f40d foo bridge
06e7eef0a170 foobar bridge
```
#### Type
The `type` filter supports two values; `builtin` displays predefined networks
(`bridge`, `none`, `host`), whereas `custom` displays user defined networks.
The following filter matches all user defined networks:
```bash
$ docker network ls --filter type=custom
NETWORK ID NAME DRIVER
95e74588f40d foo bridge
63d1ff1f77b0 dev bridge
```
By having this flag it allows for batch cleanup. For example, use this filter
to delete all user defined networks:
```bash
$ docker network rm `docker network ls --filter type=custom -q`
```
A warning will be issued when trying to remove a network that has containers
attached.
## Related information
* [network disconnect ](network_disconnect.md)
* [network connect](network_connect.md)
* [network create](network_create.md)
* [network inspect](network_inspect.md)
* [network rm](network_rm.md)
* [Understand Docker container networks](../../userguide/networking/index.md)

50
engine/reference/commandline/network_rm.md
View File

@ -1,50 +0,0 @@
---
redirect_from:
- /reference/commandline/network_rm/
description: the network rm command description and usage
keywords:
- network, rm, user-defined
title: docker network rm
---
```markdown
Usage: docker network rm NETWORK [NETWORK...]
Remove one or more networks
Aliases:
rm, remove
Options:
--help Print usage
```
Removes one or more networks by name or identifier. To remove a network,
you must first disconnect any containers connected to it.
To remove the network named 'my-network':
```bash
$ docker network rm my-network
```
To delete multiple networks in a single `docker network rm` command, provide
multiple network names or ids. The following example deletes a network with id
`3695c422697f` and a network named `my-network`:
```bash
$ docker network rm 3695c422697f my-network
```
When you specify multiple networks, the command attempts to delete each in turn.
If the deletion of one network fails, the command continues to the next on the
list and tries to delete that. The command reports success or failure for each
deletion.
## Related information
* [network disconnect ](network_disconnect.md)
* [network connect](network_connect.md)
* [network create](network_create.md)
* [network ls](network_ls.md)
* [network inspect](network_inspect.md)
* [Understand Docker container networks](../../userguide/networking/index.md)

29
engine/reference/commandline/node_demote.md
View File

@ -1,29 +0,0 @@
---
redirect_from:
- /reference/commandline/node_demote/
description: The node demote command description and usage
keywords:
- node, demote
title: docker node demote
---
```markdown
Usage: docker node demote NODE [NODE...]
Demote one or more nodes from manager in the swarm
Options:
--help Print usage
```
Demotes an existing manager so that it is no longer a manager. This command targets a docker engine that is a manager in the swarm.
```bash
$ docker node demote <node name>
```
## Related information
* [node promote](node_promote.md)

127
engine/reference/commandline/node_inspect.md
View File

@ -1,127 +0,0 @@
---
redirect_from:
- /reference/commandline/node_inspect/
description: The node inspect command description and usage
keywords:
- node, inspect
title: docker node inspect
---
**Warning:** this command is part of the Swarm management feature introduced in Docker 1.12, and might be subject to non backward-compatible changes.
```markdown
Usage: docker node inspect [OPTIONS] self|NODE [NODE...]
Display detailed information on one or more nodes
Options:
-f, --format string Format the output using the given go template
--help Print usage
--pretty Print the information in a human friendly format.
```
Returns information about a node. By default, this command renders all results
in a JSON array. You can specify an alternate format to execute a
given template for each result. Go's
[text/template](http://golang.org/pkg/text/template/) package describes all the
details of the format.
Example output:
$ docker node inspect swarm-manager
[
{
"ID": "e216jshn25ckzbvmwlnh5jr3g",
"Version": {
"Index": 10
},
"CreatedAt": "2016-06-16T22:52:44.9910662Z",
"UpdatedAt": "2016-06-16T22:52:45.230878043Z",
"Spec": {
"Role": "manager",
"Availability": "active"
},
"Description": {
"Hostname": "swarm-manager",
"Platform": {
"Architecture": "x86_64",
"OS": "linux"
},
"Resources": {
"NanoCPUs": 1000000000,
"MemoryBytes": 1039843328
},
"Engine": {
"EngineVersion": "1.12.0",
"Plugins": [
{
"Type": "Volume",
"Name": "local"
},
{
"Type": "Network",
"Name": "overlay"
},
{
"Type": "Network",
"Name": "null"
},
{
"Type": "Network",
"Name": "host"
},
{
"Type": "Network",
"Name": "bridge"
},
{
"Type": "Network",
"Name": "overlay"
}
]
}
},
"Status": {
"State": "ready"
},
"ManagerStatus": {
"Leader": true,
"Reachability": "reachable",
"Addr": "168.0.32.137:2377"
}
}
]
{% raw %}
$ docker node inspect --format '{{ .ManagerStatus.Leader }}' self
false
{% endraw %}
$ docker node inspect --pretty self
ID: e216jshn25ckzbvmwlnh5jr3g
Hostname: swarm-manager
Joined at: 2016-06-16 22:52:44.9910662 +0000 utc
Status:
State: Ready
Availability: Active
Manager Status:
Address: 172.17.0.2:2377
Raft Status: Reachable
Leader: Yes
Platform:
Operating System: linux
Architecture: x86_64
Resources:
CPUs: 4
Memory: 7.704 GiB
Plugins:
Network: overlay, bridge, null, host, overlay
Volume: local
Engine Version: 1.12.0
## Related information
* [node update](node_update.md)
* [node ps](node_ps.md)
* [node ls](node_ls.md)
* [node rm](node_rm.md)

94
engine/reference/commandline/node_ls.md
View File

@ -1,94 +0,0 @@
---
redirect_from:
- /reference/commandline/node_ls/
description: The node ls command description and usage
keywords:
- node, list
title: docker node ls
---
**Warning:** this command is part of the Swarm management feature introduced in Docker 1.12, and might be subject to non backward-compatible changes.
```markdown
Usage: docker node ls [OPTIONS]
List nodes in the swarm
Aliases:
ls, list
Options:
-f, --filter value Filter output based on conditions provided
--help Print usage
-q, --quiet Only display IDs
```
Lists all the nodes that the Docker Swarm manager knows about. You can filter using the `-f` or `--filter` flag. Refer to the [filtering](node_ls.md#filtering) section for more information about available filter options.
Example output:
```bash
$ docker node ls
ID HOSTNAME STATUS AVAILABILITY MANAGER STATUS
1bcef6utixb0l0ca7gxuivsj0 swarm-worker2 Ready Active
38ciaotwjuritcdtn9npbnkuz swarm-worker1 Ready Active
e216jshn25ckzbvmwlnh5jr3g * swarm-manager1 Ready Active Leader
```
## Filtering
The filtering flag (`-f` or `--filter`) format is of "key=value". If there is more
than one filter, then pass multiple flags (e.g., `--filter "foo=bar" --filter "bif=baz"`)
The currently supported filters are:
* name
* id
* label
### name
The `name` filter matches on all or part of a node name.
The following filter matches the node with a name equal to `swarm-master` string.
```bash
$ docker node ls -f name=swarm-manager1
ID HOSTNAME STATUS AVAILABILITY MANAGER STATUS
e216jshn25ckzbvmwlnh5jr3g * swarm-manager1 Ready Active Leader
```
### id
The `id` filter matches all or part of a node's id.
```bash
$ docker node ls -f id=1
ID HOSTNAME STATUS AVAILABILITY MANAGER STATUS
1bcef6utixb0l0ca7gxuivsj0 swarm-worker2 Ready Active
```
#### label
The `label` filter matches tasks based on the presence of a `label` alone or a `label` and a
value.
The following filter matches nodes with the `usage` label regardless of its value.
```bash
$ docker node ls -f "label=foo"
ID HOSTNAME STATUS AVAILABILITY MANAGER STATUS
1bcef6utixb0l0ca7gxuivsj0 swarm-worker2 Ready Active
```
## Related information
* [node inspect](node_inspect.md)
* [node update](node_update.md)
* [node ps](node_ps.md)
* [node rm](node_rm.md)

Some files were not shown because too many files have changed in this diff Show More