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

Merge pull request #2453 from thaJeztah/19.03_backport_fixup_markdown_and_links 

[19.03 backport] documentation changes
This commit is contained in:
Silvin Lubecki 2020-04-20 14:01:29 +02:00 committed by GitHub
parent 04533bd523 0d26cbf5b7
commit 05ad944d13
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
87 changed files with 2155 additions and 1388 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
docs/extend/index.md
View File

@ -24,8 +24,9 @@ plugins using Docker Engine.
For information about the legacy plugin system available in Docker Engine 1.12
and earlier, see [Understand legacy Docker Engine plugins](legacy_plugins.md).
> **Note**: Docker Engine managed plugins are currently not supported
on Windows daemons.
> **Note**
>
> Docker Engine managed plugins are currently not supported on Windows daemons.
## Installing and using a plugin
@ -45,7 +46,12 @@ operation, such as creating a volume.
In the following example, you install the `sshfs` plugin, verify that it is
enabled, and use it to create a volume.
> **Note**: This example is intended for instructional purposes only. Once the volume is created, your SSH password to the remote host will be exposed as plaintext when inspecting the volume. You should delete the volume as soon as you are done with the example.
> **Note**
>
> This example is intended for instructional purposes only. Once the volume is
> created, your SSH password to the remote host will be exposed as plaintext
> when inspecting the volume. You should delete the volume as soon as you are
> done with the example.
1. Install the `sshfs` plugin.

6
docs/extend/plugins_authorization.md
View File

@ -53,8 +53,10 @@ Authorization plugins must follow the rules described in [Docker Plugin API](plu
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.
> **Note**
>
> The abbreviations `AuthZ` and `AuthN` mean authorization and authentication
> respectively.
## Default user authorization mechanism

8
docs/extend/plugins_metrics.md
View File

@ -18,9 +18,11 @@ Docker exposes internal metrics based on the prometheus format. Metrics plugins
enable accessing these metrics in a consistent way by providing a Unix
socket at a predefined path where the plugin can scrape the metrics.
> **Note**: that while the plugin interface for metrics is non-experimental, the naming
of the metrics and metric labels is still considered experimental and may change
in a future version.
> **Note**
>
> While the plugin interface for metrics is non-experimental, the naming of the
> metrics and metric labels is still considered experimental and may change in a
> future version.
## Creating a metrics plugin

8
docs/extend/plugins_volume.md
View File

@ -90,9 +90,11 @@ provide the Docker Daemon with writeable paths on the host filesystem. The Docke
daemon provides these paths to containers to consume. The Docker daemon makes
the volumes available by bind-mounting the provided paths into the 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.
> **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`

1076
docs/reference/builder.md
View File

File diff suppressed because it is too large Load Diff

17
docs/reference/commandline/build.md
View File

@ -78,12 +78,13 @@ that succeeds, the directory is sent to the Docker daemon as the context.
Local copy gives you the ability to access private repositories using local
user credentials, VPN's, and so forth.
> **Note:**
> **Note**
>
> If the `URL` parameter contains a fragment the system will recursively clone
> the repository and its submodules using a `git clone --recursive` command.
Git URLs accept context configuration in their fragment section, separated by a
colon `:`. The first part represents the reference that Git will check out,
colon (`:`). The first part represents the reference that Git will check out,
and can be either a branch, a tag, or a remote reference. The second part
represents a subdirectory inside the repository that will be used as a build
context.
@ -396,13 +397,13 @@ the command line.
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).
flag](../run.md#specify-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).
flag values](run.md#set-ulimits-in-container---ulimit).
### Set build-time variables (--build-arg)
@ -577,7 +578,9 @@ $ ls ./out
vndr
```
> **Note**: This feature requires the BuildKit backend. You can either
> **Note**
>
> This feature requires the BuildKit backend. You can either
> [enable BuildKit](../builder.md#buildkit) or use the [buildx](https://github.com/docker/buildx)
> plugin which provides more output type options.
@ -616,7 +619,9 @@ BuildKit automatically pulls the image from the registry if needed.
$ docker build --cache-from myname/myapp .
```
> **Note**: This feature requires the BuildKit backend. You can either
> **Note**
>
> This feature requires the BuildKit backend. You can either
> [enable BuildKit](../builder.md#buildkit) or use the [buildx](https://github.com/docker/buildx)
> plugin. The previous builder has limited support for reusing cache from
> pre-pulled images.

4
docs/reference/commandline/cli.md
View File

@ -402,7 +402,9 @@ Sometimes, multiple options can call for a more complex value string as for
$ docker run -v /host:/container example/mysql
```
> **Note**: Do not use the `-t` and `-a stderr` options together due to
> **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`.

2
docs/reference/commandline/cp.md
View File

@ -90,7 +90,7 @@ 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
`/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`. Both of the following examples do the same thing
in different ways (consider `SRC_PATH` and `DEST_PATH` are directories):

48
docs/reference/commandline/dockerd.md
View File

@ -107,10 +107,10 @@ type `dockerd`.
To run the daemon with debug output, use `dockerd -D` or add `"debug": true` to
the `daemon.json` file.
> **Note**: In Docker 1.13 and higher, enable experimental features by starting
> `dockerd` with the `--experimental` flag or adding `"experimental": true` to the
> `daemon.json` file. In earlier Docker versions, a different build was required
> to enable experimental features.
> **Enabling experimental features**
>
> Enable experimental features by starting `dockerd` with the `--experimental`
> flag or adding `"experimental": true` to the `daemon.json` file.
## Examples
@ -133,7 +133,9 @@ interface using its IP address: `-H tcp://192.168.59.103:2375`. It is
conventional to use port `2375` for un-encrypted, and port `2376` for encrypted
communication with the daemon.
> **Note**: If you're using an HTTPS encrypted socket, keep in mind that only
> **Note**
>
> If you're using an HTTPS encrypted socket, keep in mind that only
> TLS1.0 and greater are supported. Protocols SSLv3 and under are not
> supported anymore for security reasons.
@ -298,20 +300,24 @@ The `overlay` is a very fast union filesystem. It is now merged in the main
Linux kernel as of [3.18.0](https://lkml.org/lkml/2014/10/26/137). `overlay`
also supports page cache sharing, this means multiple containers accessing
the same file can share a single page cache entry (or entries), it makes
`overlay` as efficient with memory as `aufs` driver. Call
`dockerd -s overlay` to use it.
> **Note**: As promising as `overlay` is, the feature is still quite young and
> should not be used in production. Most notably, using `overlay` can cause
> excessive inode consumption (especially as the number of images grows), as
> well as being incompatible with the use of RPMs.
`overlay` as efficient with memory as `aufs` driver. Call `dockerd -s overlay`
to use it.
The `overlay2` uses the same fast union filesystem but takes advantage of
[additional features](https://lkml.org/lkml/2015/2/11/106) added in Linux
kernel 4.0 to avoid excessive inode consumption. Call `dockerd -s overlay2`
to use it.
> **Note**: Both `overlay` and `overlay2` are currently unsupported on `btrfs`
> **Note**
>
> The `overlay` storage driver can cause excessive inode consumption (especially
> as the number of images grows). We recommend using the `overlay2` storage
> driver instead.
> **Note**
>
> Both `overlay` and `overlay2` are currently unsupported on `btrfs`
> or any Copy on Write filesystem and should only be used over `ext4` partitions.
On Windows, the Docker daemon supports a single image layer storage driver
@ -458,7 +464,9 @@ $ sudo service docker start
##### `dm.loopdatasize`
> **Note**: This option configures devicemapper loopback, which should not
> **Note**
>
> This option configures devicemapper loopback, which should not
> be used in production.
Specifies the size to use when creating the loopback file for the
@ -474,7 +482,9 @@ $ sudo dockerd --storage-opt dm.loopdatasize=200G
##### `dm.loopmetadatasize`
> **Note**: This option configures devicemapper loopback, which should not
> **Note**
>
> This option configures devicemapper loopback, which should not
> be used in production.
Specifies the size to use when creating the loopback file for the
@ -621,7 +631,9 @@ $ sudo dockerd --storage-opt dm.override_udev_sync_check=true
When this value is `true`, the `devicemapper` continues and simply warns
you the errors are happening.
> **Note**: The ideal is to pursue a `docker` daemon and environment that does
> **Note**
>
> The ideal is to pursue a `docker` daemon and environment that does
> support synchronizing with `udev`. For further discussion on this
> topic, see [docker#4036](https://github.com/docker/docker/issues/4036).
> Otherwise, set this flag for migrating existing Docker daemons to
@ -953,7 +965,9 @@ This is the same example via the command line:
$ sudo dockerd --add-runtime runc=runc --add-runtime custom=/usr/local/bin/my-runc-replacement
```
> **Note**: Defining runtime arguments via the command line is not supported.
> **Note**
>
> Defining runtime arguments via the command line is not supported.
#### Options for the runtime

3
docs/reference/commandline/history.md
View File

@ -68,7 +68,8 @@ 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 `CreatedSince` entries separated by a colon for the `busybox` image:
`ID` and `CreatedSince` entries separated by a colon (`:`) for the `busybox`
image:
```bash
$ docker history --format "{{.ID}}: {{.CreatedSince}}" busybox

4
docs/reference/commandline/image_prune.md
View File

@ -190,7 +190,9 @@ This example removes images which have a maintainer label not set to `john`:
$ docker image prune --filter="label!=maintainer=john"
```
> **Note**: You are prompted for confirmation before the `prune` removes
> **Note**
>
> You are prompted for confirmation before the `prune` removes
> anything, but you are not shown a list of what will potentially be removed.
> In addition, `docker image ls` does not support negative filtering, so it
> difficult to predict what images will actually be removed.

5
docs/reference/commandline/images.md
View File

@ -184,8 +184,7 @@ dea752e4e117
511136ea3c5a
```
> **Note**: Docker warns you if any containers exist that are using these
> untagged images.
Docker warns you if any containers exist that are using these untagged images.
#### Show images with a given label
@ -309,7 +308,7 @@ 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:
`ID` and `Repository` entries separated by a colon (`:`) for all images:
```bash
$ docker images --format "{{.ID}}: {{.Repository}}"

5
docs/reference/commandline/import.md
View File

@ -81,9 +81,12 @@ archiving with tar. If you are not root (or the sudo command) when you
tar, then the ownerships might not get preserved.
## When the daemon supports multiple operating systems
If the daemon supports multiple operating systems, and the image being imported
does not match the default operating system, it may be necessary to add
`--platform`. This would be necessary when importing a Linux image into a Windows
daemon.
# docker import --platform=linux .\linuximage.tar
```bash
$ docker import --platform=linux .\linuximage.tar
```

4
docs/reference/commandline/kill.md
View File

@ -23,7 +23,9 @@ inside the container is sent `SIGKILL` signal (default), or the signal that is
specified with the `--signal` option. You can kill a container using the
container's ID, ID-prefix, or name.
> **Note**: `ENTRYPOINT` and `CMD` in the *shell* form run as a subcommand of
> **Note**
>
> `ENTRYPOINT` and `CMD` in the *shell* form run as a child process 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.

6
docs/reference/commandline/logs.md
View File

@ -25,8 +25,10 @@ Options:
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.
> **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 logging drivers, refer to
[Configure logging drivers](https://docs.docker.com/config/containers/logging/configure/).

7
docs/reference/commandline/manifest.md
View File

@ -40,7 +40,7 @@ to two images -- one for windows on amd64, and one for darwin on amd64.
### manifest inspect
```
```bash
manifest inspect --help
Usage: docker manifest inspect [OPTIONS] [MANIFEST_LIST] MANIFEST
@ -275,9 +275,10 @@ $ docker manifest create --insecure myprivateregistry.mycompany.com/repo/image:1
$ docker manifest push --insecure myprivateregistry.mycompany.com/repo/image:tag
```
> **Note**: the `--insecure` flag is not required to annotate a manifest list,
> **Note**
>
> The `--insecure` flag is not required to annotate a manifest list,
> since annotations are to a locally-stored copy of a manifest list. You may also
> skip the `--insecure` flag if you are performing a `docker manifest inspect`
> on a locally-stored manifest list. Be sure to keep in mind that locally-stored
> manifest lists are never used by the engine on a `docker pull`.

2
docs/reference/commandline/network.md
View File

@ -35,7 +35,7 @@ prune, connect, and disconnect networks.
* [network create](network_create.md)
* [network inspect](network_inspect.md)
* [network list](network_list.md)
* [network list](network_ls.md)
* [network rm](network_rm.md)
* [network prune](network_prune.md)
* [network connect](network_connect.md)

2
docs/reference/commandline/network_disconnect.md
View File

@ -24,7 +24,7 @@ disconnect it from the network.
## Examples
```bash
$ docker network disconnect multi-host-network container1
$ docker network disconnect multi-host-network container1
```

2
docs/reference/commandline/network_ls.md
View File

@ -221,7 +221,7 @@ output the data exactly as the template declares or, when using the
`table` directive, includes column headers as well.
The following example uses a template without headers and outputs the
`ID` and `Driver` entries separated by a colon for all networks:
`ID` and `Driver` entries separated by a colon (`:`) for all networks:
```bash
$ docker network ls --format "{{.ID}}: {{.Driver}}"

2
docs/reference/commandline/network_prune.md
View File

@ -96,7 +96,7 @@ f949d337b1f5 none null local
* [network ls](network_ls.md)
* [network inspect](network_inspect.md)
* [network rm](network_rm.md)
* [Understand Docker container networks](https://docs.docker.com/engine/userguide/networking/)
* [Understand Docker container networks](https://docs.docker.com/network/)
* [system df](system_df.md)
* [container prune](container_prune.md)
* [image prune](image_prune.md)

2
docs/reference/commandline/network_rm.md
View File

@ -56,4 +56,4 @@ deletion.
* [network ls](network_ls.md)
* [network inspect](network_inspect.md)
* [network prune](network_prune.md)
* [Understand Docker container networks](https://docs.docker.com/engine/userguide/networking/)
* [Understand Docker container networks](https://docs.docker.com/network/)

4
docs/reference/commandline/node_demote.md
View File

@ -20,7 +20,9 @@ Options:
Demotes an existing manager so that it is no longer a manager.
> **Note**: This is a cluster management command, and must be executed on a swarm
> **Note**
>
> This is a cluster management command, and must be executed on a swarm
> manager node. To learn about managers and workers, refer to the [Swarm mode
> section](https://docs.docker.com/engine/swarm/) in the documentation.

9
docs/reference/commandline/node_inspect.md
View File

@ -25,9 +25,12 @@ given template for each result. Go's
[text/template](http://golang.org/pkg/text/template/) package describes all the
details of the format.
> **Note**: This is a cluster management command, and must be executed on a swarm
> manager node. To learn about managers and workers, refer to the [Swarm mode
> section](https://docs.docker.com/engine/swarm/) in the documentation.
> **Note**
>
> This is a cluster management command, and must be executed on a swarm
> manager node. To learn about managers and workers, refer to the
> [Swarm mode section](https://docs.docker.com/engine/swarm/) in the
> documentation.
## Examples

31
docs/reference/commandline/node_ls.md
View File

@ -27,9 +27,12 @@ Lists all the nodes that the Docker Swarm manager knows about. You can filter
using the `-f` or `--filter` flag. Refer to the [filtering](#filtering) section
for more information about available filter options.
> **Note**: This is a cluster management command, and must be executed on a swarm
> manager node. To learn about managers and workers, refer to the [Swarm mode
> section](https://docs.docker.com/engine/swarm/) in the documentation.
> **Note**
>
> This is a cluster management command, and must be executed on a swarm
> manager node. To learn about managers and workers, refer to the
> [Swarm mode section](https://docs.docker.com/engine/swarm/) in the
> documentation.
## Examples
@ -41,10 +44,11 @@ ID HOSTNAME STATUS AVAILABILITY MANAGER STATU
38ciaotwjuritcdtn9npbnkuz swarm-worker1 Ready Active
e216jshn25ckzbvmwlnh5jr3g * swarm-manager1 Ready Active Leader
```
> **Note**:
> In the above example output, there is a hidden column of `.Self` that indicates if the
> node is the same node as the current docker daemon. A `*` (e.g., `e216jshn25ckzbvmwlnh5jr3g *`)
> means this node is the current docker daemon.
> **Note**
>
> In the above example output, there is a hidden column of `.Self` that indicates
> if the node is the same node as the current docker daemon. A `*` (e.g.,
> `e216jshn25ckzbvmwlnh5jr3g *`) means this node is the current docker daemon.
### Filtering
@ -54,11 +58,11 @@ than one filter, then pass multiple flags (e.g., `--filter "foo=bar" --filter "b
The currently supported filters are:
* [id](node_ls.md#id)
* [label](node_ls.md#label)
* [membership](node_ls.md#membership)
* [name](node_ls.md#name)
* [role](node_ls.md#role)
* [id](#id)
* [label](#label)
* [membership](#membership)
* [name](#name)
* [role](#role)
#### id
@ -148,7 +152,8 @@ output the data exactly as the template declares or, when using the
`table` directive, includes column headers as well.
The following example uses a template without headers and outputs the
`ID`, `Hostname`, and `TLS Status` entries separated by a colon for all nodes:
`ID`, `Hostname`, and `TLS Status` entries separated by a colon (`:`) for all
nodes:
```bash
$ docker node ls --format "{{.ID}}: {{.Hostname}} {{.TLSStatus}}"

9
docs/reference/commandline/node_promote.md
View File

@ -19,9 +19,12 @@ Options:
Promotes a node to manager. This command can only be executed on a manager node.
> **Note**: This is a cluster management command, and must be executed on a swarm
> manager node. To learn about managers and workers, refer to the [Swarm mode
> section](https://docs.docker.com/engine/swarm/) in the documentation.
> **Note**
>
> This is a cluster management command, and must be executed on a swarm
> manager node. To learn about managers and workers, refer to the
> [Swarm mode section](https://docs.docker.com/engine/swarm/) in the
> documentation.
## Examples

11
docs/reference/commandline/node_ps.md
View File

@ -27,9 +27,12 @@ Lists all the tasks on a Node that Docker knows about. You can filter using the
`-f` or `--filter` flag. Refer to the [filtering](#filtering) section for more
information about available filter options.
> **Note**: This is a cluster management command, and must be executed on a swarm
> manager node. To learn about managers and workers, refer to the [Swarm mode
> section](https://docs.docker.com/engine/swarm/) in the documentation.
> **Note**
>
> This is a cluster management command, and must be executed on a swarm
> manager node. To learn about managers and workers, refer to the
> [Swarm mode section](https://docs.docker.com/engine/swarm/) in the
> documentation.
## Examples
@ -127,7 +130,7 @@ output the data exactly as the template declares or, when using the
`table` directive, includes column headers as well.
The following example uses a template without headers and outputs the
`Name` and `Image` entries separated by a colon for all tasks:
`Name` and `Image` entries separated by a colon (`:`) for all tasks:
```bash
$ docker node ps --format "{{.Name}}: {{.Image}}"

9
docs/reference/commandline/node_rm.md
View File

@ -23,9 +23,12 @@ Options:
Removes the specified nodes from a swarm.
> **Note**: This is a cluster management command, and must be executed on a swarm
> manager node. To learn about managers and workers, refer to the [Swarm mode
> section](https://docs.docker.com/engine/swarm/) in the documentation.
> **Note**
>
> This is a cluster management command, and must be executed on a swarm
> manager node. To learn about managers and workers, refer to the
> [Swarm mode section](https://docs.docker.com/engine/swarm/) in the
> documentation.
## Examples

11
docs/reference/commandline/node_update.md
View File

@ -23,9 +23,12 @@ Options:
Update metadata about a node, such as its availability, labels, or roles.
> **Note**: This is a cluster management command, and must be executed on a swarm
> manager node. To learn about managers and workers, refer to the [Swarm mode
> section](https://docs.docker.com/engine/swarm/) in the documentation.
> **Note**
>
> This is a cluster management command, and must be executed on a swarm
> manager node. To learn about managers and workers, refer to the
> [Swarm mode section](https://docs.docker.com/engine/swarm/) in the
> documentation.
## Examples
@ -57,7 +60,7 @@ $ docker node update --label-add type=queue worker1
The labels you set for nodes using `docker node update` apply only to the node
entity within the swarm. Do not confuse them with the docker daemon labels for
[dockerd](https://docs.docker.com/engine/userguide/labels-custom-metadata/#daemon-labels).
[dockerd](dockerd.md).
For more information about labels, refer to [apply custom
metadata](https://docs.docker.com/engine/userguide/labels-custom-metadata/).

10
docs/reference/commandline/plugin_inspect.md
View File

@ -23,10 +23,17 @@ in a JSON array.
## Examples
### Inspect a plugin
```none
The following example example inspects the `tiborvass/sample-volume-plugin` plugin:
```bash
$ docker plugin inspect tiborvass/sample-volume-plugin:latest
```
Output is in JSON format (output below is formatted for readability):
```json
{
"Id": "8c74c978c434745c3ade82f1bc0acf38d04990eaf494fa507c16d9f1daa99c21",
"Name": "tiborvass/sample-volume-plugin:latest",
@ -134,7 +141,6 @@ $ docker plugin inspect tiborvass/sample-volume-plugin:latest
}
```
(output formatted for readability)
### Formatting the output

4
docs/reference/commandline/plugin_ls.md
View File

@ -76,7 +76,7 @@ using a Go template.
Valid placeholders for the Go template are listed below:
Placeholder | Description
---------------|------------------------------------------------------------------------------------------
-------------------|------------------------------------------------------------
`.ID` | Plugin ID
`.Name` | Plugin name
`.Description` | Plugin description
@ -88,7 +88,7 @@ output the data exactly as the template declares or, when using the
`table` directive, includes column headers as well.
The following example uses a template without headers and outputs the
`ID` and `Name` entries separated by a colon for all plugins:
`ID` and `Name` entries separated by a colon (`:`) for all plugins:
```bash
$ docker plugin ls --format "{{.ID}}: {{.Name}}"

13
docs/reference/commandline/plugin_set.md
View File

@ -32,10 +32,9 @@ by looking at the `Settable` field.
Here is an extract of a plugin manifest:
```
```json
{
"config": {
...
"args": {
"name": "myargs",
"settable": ["value"],
@ -68,8 +67,7 @@ Here is an extract of a plugin manifest:
"source": "/foo",
"type": "bind"
}
],
...
]
}
}
```
@ -111,7 +109,9 @@ $ docker plugin inspect -f '{{with $mount := index .Settings.Mounts 0}}{{$mount.
/bar
```
> **Note**: Since only `source` is settable in `mymount`,
> **Note**
>
> Since only `source` is settable in `mymount`,
> `docker plugins set mymount=/bar myplugin` would work too.
### Change a device path
@ -131,7 +131,8 @@ $ docker plugin inspect -f '{{with $device := index .Settings.Devices 0}}{{$devi
/dev/bar
```
> **Note**: Since only `path` is settable in `mydevice`,
> **Note**
> Since only `path` is settable in `mydevice`,
> `docker plugins set mydevice=/dev/bar myplugin` would work too.
### Change the source of the arguments

9
docs/reference/commandline/port.md
View File

@ -24,15 +24,24 @@ just a specific mapping:
```bash
$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
b650456536c7 busybox:latest top 54 minutes ago Up 54 minutes 0.0.0.0:1234->9876/tcp, 0.0.0.0:4321->7890/tcp test
$ docker port test
7890/tcp -> 0.0.0.0:4321
9876/tcp -> 0.0.0.0:1234
$ docker port test 7890/tcp
0.0.0.0:4321
$ docker port test 7890/udp
2014/06/24 11:53:36 Error: No public port '7890/udp' published for test
$ docker port test 7890
0.0.0.0:4321
```

5
docs/reference/commandline/ps.md
View File

@ -72,6 +72,7 @@ The `docker ps -s` command displays two different on-disk-sizes for each contain
```bash
$ docker ps -s
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES SIZE SIZE
e90b8831a4b8 nginx "/bin/bash -c 'mkdir " 11 weeks ago Up 4 hours my_nginx 35.58 kB (virtual 109.2 MB)
00c6131c5e30 telegraf:1.5 "/entrypoint.sh" 11 weeks ago Up 11 weeks my_telegraf 0 B (virtual 209.5 MB)
@ -310,10 +311,12 @@ a volume mounted in a specific path:
```bash
$ docker ps --filter volume=remote-volume --format "table {{.ID}}\t{{.Mounts}}"
CONTAINER ID MOUNTS
9c3527ed70ce remote-volume
$ docker ps --filter volume=/data --format "table {{.ID}}\t{{.Mounts}}"
CONTAINER ID MOUNTS
9c3527ed70ce remote-volume
```
@ -417,7 +420,7 @@ exactly as the template declares or, when using the `table` directive, includes
column headers as well.
The following example uses a template without headers and outputs the `ID` and
`Command` entries separated by a colon for all running containers:
`Command` entries separated by a colon (`:`) for all running containers:
```bash
$ docker ps --format "{{.ID}}: {{.Command}}"

18
docs/reference/commandline/pull.md
View File

@ -35,7 +35,7 @@ If you are behind an HTTP proxy server, for example in corporate settings,
before open a connect to registry, you may need to configure the Docker
daemon's proxy settings, using the `HTTP_PROXY`, `HTTPS_PROXY`, and `NO_PROXY`
environment variables. To set these environment variables on a host using
`systemd`, refer to the [control and configure Docker with systemd](https://docs.docker.com/engine/admin/systemd/#http-proxy)
`systemd`, refer to the [control and configure Docker with systemd](https://docs.docker.com/config/daemon/systemd/#httphttps-proxy)
for variables configuration.
### Concurrent downloads
@ -101,7 +101,7 @@ same image, their layers are stored only once and do not consume extra disk
space.
For more information about images, layers, and the content-addressable store,
refer to [understand images, containers, and storage drivers](https://docs.docker.com/engine/userguide/storagedriver/imagesandcontainers/).
refer to [understand images, containers, and storage drivers](https://docs.docker.com/storage/storagedriver/).
### Pull an image by digest (immutable identifier)
@ -163,7 +163,9 @@ FROM ubuntu@sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5
MAINTAINER some maintainer <maintainer@example.com>
```
> **Note**: Using this feature "pins" an image to a specific version in time.
> **Note**
>
> Using this feature "pins" an image to a specific version in time.
> Docker will therefore not pull updated versions of an image, which may include
> security updates. If you want to pull an updated image, you need to change the
> digest accordingly.
@ -240,7 +242,9 @@ a3ed95caeb02: Pulling fs layer
^C
```
> **Note**: Technically, the Engine terminates a pull operation when the
> connection between the Docker Engine daemon and the Docker Engine client
> initiating the pull is lost. If the connection with the Engine daemon is
> lost for other reasons than a manual interaction, the pull is also aborted.
> **Note**
>
> The Engine terminates a pull operation when the connection between the Docker
> Engine daemon and the Docker Engine client initiating the pull is lost. If the
> connection with the Engine daemon is lost for other reasons than a manual
> interaction, the pull is also aborted.

21
docs/reference/commandline/rm.md
View File

@ -22,8 +22,7 @@ Options:
### Remove a container
This will remove the container referenced under the link
`/redis`.
This removes the container referenced under the link `/redis`.
```bash
$ docker rm /redis
@ -33,7 +32,7 @@ $ docker rm /redis
### Remove a link specified with `--link` on the default bridge network
This will remove the underlying link between `/webapp` and the `/redis`
This removes the underlying link between `/webapp` and the `/redis`
containers on the default bridge network, removing all network communication
between the two containers. This does not apply when `--link` is used with
user-specified networks.
@ -46,7 +45,7 @@ $ docker rm --link /webapp/redis
### Force-remove a running container
This command will force-remove a running container.
This command force-removes a running container.
```bash
$ docker rm --force redis
@ -63,10 +62,9 @@ The main process inside the container referenced under the link `redis` will rec
$ docker rm $(docker ps -a -q)
```
This command will delete all stopped containers. The command
`docker ps -a -q` will return all existing container IDs and pass them to
the `rm` command which will delete them. Any running containers will not be
deleted.
This command deletes all stopped containers. The command
`docker ps -a -q` above returns all existing container IDs and passes them to
the `rm` command which deletes them. Running containers are not deleted.
### Remove a container and its volumes
@ -75,7 +73,7 @@ $ docker rm -v redis
redis
```
This command will remove the container and any volumes associated with it.
This command removes the container and any volumes associated with it.
Note that if a volume was specified with a name, it will not be removed.
### Remove a container and selectively remove volumes
@ -83,9 +81,10 @@ Note that if a volume was specified with a name, it will not be removed.
```bash
$ docker create -v awesome:/foo -v /bar --name hello redis
hello
$ docker rm -v hello
```
In this example, the volume for `/foo` will remain intact, but the volume for
`/bar` will be removed. The same behavior holds for volumes inherited with
In this example, the volume for `/foo` remains intact, but the volume for
`/bar` is removed. The same behavior holds for volumes inherited with
`--volumes-from`.

69
docs/reference/commandline/run.md
View File

@ -151,7 +151,7 @@ of all containers.
The `docker run` command can be used in combination with `docker commit` to
[*change the command that a container runs*](commit.md). There is additional detailed information about `docker run` in the [Docker run reference](../run.md).
For information on connecting a container to a network, see the ["*Docker network overview*"](https://docs.docker.com/engine/userguide/networking/).
For information on connecting a container to a network, see the ["*Docker network overview*"](https://docs.docker.com/network/).
## Examples
@ -278,8 +278,7 @@ $ docker run -t -i -v /var/run/docker.sock:/var/run/docker.sock -v /path/to/stat
```
By bind-mounting the docker unix socket and statically linked docker
binary (refer to [get the linux binary](
https://docs.docker.com/engine/installation/binaries/#/get-the-linux-binary)),
binary (refer to [get the linux binary](https://docs.docker.com/engine/install/binaries/#install-static-binaries)),
you give the container the full access to create and manipulate the host's
Docker daemon.
@ -307,7 +306,7 @@ docker run -v c:\foo:c: ...
docker run -v c:\foo:c:\existing-directory-with-contents ...
```
For in-depth information about volumes, refer to [manage data in containers](https://docs.docker.com/engine/tutorials/dockervolumes/)
For in-depth information about volumes, refer to [manage data in containers](https://docs.docker.com/storage/volumes/)
### Add bind mounts or volumes using the --mount flag
@ -318,7 +317,7 @@ mounts in a container.
The `--mount` flag supports most options that are supported by the `-v` or the
`--volume` flag, but uses a different syntax. For in-depth information on the
`--mount` flag, and a comparison between `--volume` and `--mount`, refer to
the [service create command reference](service_create.md#add-bind-mounts-or-volumes).
the [service create command reference](service_create.md#add-bind-mounts-volumes-or-memory-filesystems).
Even though there is no plan to deprecate `--volume`, usage of `--mount` is recommended.
@ -340,7 +339,7 @@ $ docker run -p 127.0.0.1:80:8080/tcp ubuntu bash
This binds port `8080` of the container to TCP port `80` on `127.0.0.1` of the host
machine. You can also specify `udp` and `sctp` ports.
The [Docker User Guide](https://docs.docker.com/engine/userguide/networking/default_network/dockerlinks/)
The [Docker User Guide](https://docs.docker.com/network/links/)
explains in detail how to manipulate ports in Docker.
Note that ports which are not bound to the host (i.e., `-p 80:80` instead of
@ -445,8 +444,8 @@ com.example.label3
You can load multiple label-files by supplying multiple `--label-file` flags.
For additional information on working with labels, see [*Labels - custom
metadata in Docker*](https://docs.docker.com/engine/userguide/labels-custom-metadata/) in the Docker User
Guide.
metadata in Docker*](https://docs.docker.com/config/labels-custom-metadata/) in
the Docker User Guide.
### Connect a container to a network (--network)
@ -472,9 +471,11 @@ 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.
> **Note**: Service discovery is unavailable on the default bridge network.
> Containers can communicate via their IP addresses by default. To communicate
> by name, they must be linked.
> **Note**
>
> Service discovery is unavailable on the default bridge network. Containers can
> communicate via their IP addresses by default. To communicate by name, they
> must be linked.
You can disconnect a container from a network using the `docker network
disconnect` command.
@ -575,9 +576,10 @@ $ docker run --device=/dev/sda:/dev/xvdc:m --rm -it ubuntu fdisk /dev/xvdc
fdisk: unable to open /dev/xvdc: Operation not permitted
```
> **Note**: `--device` cannot be safely used with ephemeral devices. Block devices
> that may be removed should not be added to untrusted containers with
> `--device`.
> **Note**
>
> The `--device` option cannot be safely used with ephemeral devices. Block devices
> that may be removed should not be added to untrusted containers with `--device`.
For Windows, the format of the string passed to the `--device` option is in
the form of `--device=<IdType>/<Id>`. Beginning with Windows Server 2019
@ -597,9 +599,11 @@ ports on the host visible in the container.
PS C:\> docker run --device=class/86E0D1E0-8089-11D0-9CE4-08003E301F73 mcr.microsoft.com/windows/servercore:ltsc2019
```
> **Note**: the `--device` option is only supported on process-isolated
> Windows containers. This option fails if the container isolation is `hyperv`
> or when running Linux Containers on Windows (LCOW).
> **Note**
>
> The `--device` option is only supported on process-isolated Windows containers.
> This option fails if the container isolation is `hyperv` or when running Linux
> Containers on Windows (LCOW).
### Access an NVIDIA GPU
@ -700,9 +704,11 @@ $ docker run --ulimit nofile=1024:1024 --rm debian sh -c "ulimit -n"
1024
```
> **Note**: If you do not provide a `hard limit`, the `soft limit` will be used
> for both values. If no `ulimits` are set, they will be inherited from
> the default `ulimits` set on the daemon. `as` option is disabled now.
> **Note**
>
> If you do not provide a `hard limit`, the `soft limit` is used
> for both values. If no `ulimits` are set, they are inherited from
> the default `ulimits` set on the daemon. The `as` option is disabled now.
> In other words, the following script is not supported:
>
> ```bash
@ -840,23 +846,22 @@ network namespace, run this command:
$ docker run --sysctl net.ipv4.ip_forward=1 someimage
```
> **Note**: Not all sysctls are namespaced. Docker does not support changing sysctls
> **Note**
>
> Not all sysctls are namespaced. Docker does not support changing sysctls
> inside of a container that also modify the host system. As the kernel
> evolves we expect to see more sysctls become namespaced.
#### Currently supported sysctls
- `IPC Namespace`:
IPC Namespace:
```none
kernel.msgmax, kernel.msgmnb, kernel.msgmni, kernel.sem, kernel.shmall, kernel.shmmax, kernel.shmmni, kernel.shm_rmid_forced
Sysctls beginning with fs.mqueue.*
```
- `kernel.msgmax`, `kernel.msgmnb`, `kernel.msgmni`, `kernel.sem`,
`kernel.shmall`, `kernel.shmmax`, `kernel.shmmni`, `kernel.shm_rmid_forced`.
- Sysctls beginning with `fs.mqueue.*`
- If you use the `--ipc=host` option these sysctls are not allowed.
If you use the `--ipc=host` option these sysctls will not be allowed.
Network Namespace:
- `Network Namespace`:
Sysctls beginning with net.*
If you use the `--network=host` option using these sysctls will not be allowed.
- Sysctls beginning with `net.*`
- If you use the `--network=host` option using these sysctls are not allowed.

17
docs/reference/commandline/search.md
View File

@ -26,11 +26,6 @@ Options:
Search [Docker Hub](https://hub.docker.com) for images
See [*Find Public Images on Docker Hub*](https://docs.docker.com/engine/tutorials/dockerrepos/#searching-for-images) for
more details on finding shared images from the command line.
> **Note**: Search queries return a maximum of 25 results.
## Examples
### Search images by name
@ -93,9 +88,9 @@ than one filter, then pass multiple flags (e.g. `--filter is-automated=true --fi
The currently supported filters are:
* stars (int - number of stars the image has)
* is-automated (boolean - true or false) - is the image automated or not
* is-official (boolean - true or false) - is the image official or not
- stars (int - number of stars the image has)
- is-automated (boolean - true or false) - is the image automated or not
- is-official (boolean - true or false) - is the image official or not
#### stars
@ -157,10 +152,9 @@ output the data exactly as the template declares. If you use the
`table` directive, column headers are included as well.
The following example uses a template without headers and outputs the
`Name` and `StarCount` entries separated by a colon for all images:
`Name` and `StarCount` entries separated by a colon (`:`) for all images:
```bash
{% raw %}
$ docker search --format "{{.Name}}: {{.StarCount}}" nginx
nginx: 5441
@ -173,13 +167,11 @@ bitnami/nginx: 23
evild/alpine-nginx: 14
million12/nginx: 9
maxexcloo/nginx: 7
{% endraw %}
```
This example outputs a table format:
```bash
{% raw %}
$ docker search --format "table {{.Name}}\t{{.IsAutomated}}\t{{.IsOfficial}}" nginx
NAME AUTOMATED OFFICIAL
@ -189,5 +181,4 @@ richarvey/nginx-php-fpm [OK]
jrcs/letsencrypt-nginx-proxy-companion [OK]
million12/nginx-php [OK]
webdevops/php-nginx [OK]
{% endraw %}
```

2
docs/reference/commandline/secret.md
View File

@ -32,5 +32,5 @@ Manage secrets.
* [secret create](secret_create.md)
* [secret inspect](secret_inspect.md)
* [secret list](secret_list.md)
* [secret list](secret_ls.md)
* [secret rm](secret_rm.md)

9
docs/reference/commandline/secret_create.md
View File

@ -22,9 +22,12 @@ Creates a secret using standard input or from a file for the secret content.
For detailed information about using secrets, refer to [manage sensitive data with Docker secrets](https://docs.docker.com/engine/swarm/secrets/).
> **Note**: This is a cluster management command, and must be executed on a swarm
> manager node. To learn about managers and workers, refer to the [Swarm mode
> section](https://docs.docker.com/engine/swarm/) in the documentation.
> **Note**
>
> This is a cluster management command, and must be executed on a swarm
> manager node. To learn about managers and workers, refer to the
> [Swarm mode section](https://docs.docker.com/engine/swarm/) in the
> documentation.
## Examples

9
docs/reference/commandline/secret_inspect.md
View File

@ -28,9 +28,12 @@ describes all the details of the format.
For detailed information about using secrets, refer to [manage sensitive data with Docker secrets](https://docs.docker.com/engine/swarm/secrets/).
> **Note**: This is a cluster management command, and must be executed on a swarm
> manager node. To learn about managers and workers, refer to the [Swarm mode
> section](https://docs.docker.com/engine/swarm/) in the documentation.
> **Note**
>
> This is a cluster management command, and must be executed on a swarm
> manager node. To learn about managers and workers, refer to the
> [Swarm mode section](https://docs.docker.com/engine/swarm/) in the
> documentation.
## Examples

17
docs/reference/commandline/secret_ls.md
View File

@ -27,9 +27,12 @@ Run this command on a manager node to list the secrets in the swarm.
For detailed information about using secrets, refer to [manage sensitive data with Docker secrets](https://docs.docker.com/engine/swarm/secrets/).
> **Note**: This is a cluster management command, and must be executed on a swarm
> manager node. To learn about managers and workers, refer to the [Swarm mode
> section](https://docs.docker.com/engine/swarm/) in the documentation.
> **Note**
>
> This is a cluster management command, and must be executed on a swarm
> manager node. To learn about managers and workers, refer to the
> [Swarm mode section](https://docs.docker.com/engine/swarm/) in the
> documentation.
## Examples
@ -49,9 +52,9 @@ than one filter, then pass multiple flags (e.g., `--filter "foo=bar" --filter "b
The currently supported filters are:
* [id](secret_ls.md#id) (secret's ID)
* [label](secret_ls.md#label) (`label=<key>` or `label=<key>=<value>`)
* [name](secret_ls.md#name) (secret's name)
- [id](#id) (secret's ID)
- [label](#label) (`label=<key>` or `label=<key>=<value>`)
- [name](#name) (secret's name)
#### id
@ -123,7 +126,7 @@ 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 `Name` entries separated by a colon for all images:
`ID` and `Name` entries separated by a colon (`:`) for all images:
```bash
$ docker secret ls --format "{{.ID}}: {{.Name}}"

15
docs/reference/commandline/secret_rm.md
View File

@ -24,9 +24,12 @@ Removes the specified secrets from the swarm.
For detailed information about using secrets, refer to [manage sensitive data with Docker secrets](https://docs.docker.com/engine/swarm/secrets/).
> **Note**: This is a cluster management command, and must be executed on a swarm
> manager node. To learn about managers and workers, refer to the [Swarm mode
> section](https://docs.docker.com/engine/swarm/) in the documentation.
> **Note**
>
> This is a cluster management command, and must be executed on a swarm
> manager node. To learn about managers and workers, refer to the
> [Swarm mode section](https://docs.docker.com/engine/swarm/) in the
> documentation.
## Examples
@ -37,8 +40,10 @@ $ docker secret rm secret.json
sapth4csdo5b6wz2p5uimh5xg
```
> **Warning**: Unlike `docker rm`, this command does not ask for confirmation
> before removing a secret.
> **Warning**
>
> Unlike `docker rm`, this command does not ask for confirmation before removing
> a secret.
## Related commands

9
docs/reference/commandline/service.md
View File

@ -31,6 +31,9 @@ Run 'docker service COMMAND --help' for more information on a command.
Manage services.
> **Note**: This is a cluster management command, and must be executed on a swarm
> manager node. To learn about managers and workers, refer to the [Swarm mode
> section](https://docs.docker.com/engine/swarm/) in the documentation.
> **Note**
>
> This is a cluster management command, and must be executed on a swarm
> manager node. To learn about managers and workers, refer to the
> [Swarm mode section](https://docs.docker.com/engine/swarm/) in the
> documentation.

36
docs/reference/commandline/service_create.md
View File

@ -85,9 +85,12 @@ Options:
Creates a service as described by the specified parameters.
> **Note**: This is a cluster management command, and must be executed on a swarm
> manager node. To learn about managers and workers, refer to the [Swarm mode
> section](https://docs.docker.com/engine/swarm/) in the documentation.
> **Note**
>
> This is a cluster management command, and must be executed on a swarm
> manager node. To learn about managers and workers, refer to the
> [Swarm mode section](https://docs.docker.com/engine/swarm/) in the
> documentation.
## Examples
@ -289,7 +292,7 @@ $ docker service create \
```
For more information about labels, refer to [apply custom
metadata](https://docs.docker.com/engine/userguide/labels-custom-metadata/).
metadata](https://docs.docker.com/config/labels-custom-metadata/).
### Add bind mounts, volumes or memory filesystems
@ -327,7 +330,7 @@ your web server containers when they start. To update the website, you just
update the named volume.
For more information about named volumes, see
[Data Volumes](https://docs.docker.com/engine/tutorials/dockervolumes/).
[Data Volumes](https://docs.docker.com/storage/volumes/).
The following table describes options which apply to both bind mounts and named
volumes in a service:
@ -342,14 +345,14 @@ volumes in a service:
<td><b>type</b></td>
<td></td>
<td>
<p>The type of mount, can be either <tt>volume</tt>, <tt>bind</tt>, <tt>tmpfs</tt>, or <tt>npipe</tt>. Defaults to <tt>volume</tt> if no type is specified.
<p>The type of mount, can be either <tt>volume</tt>, <tt>bind</tt>, <tt>tmpfs</tt>, or <tt>npipe</tt>. Defaults to <tt>volume</tt> if no type is specified.</p>
<ul>
<li><tt>volume</tt>: mounts a <a href="https://docs.docker.com/engine/reference/commandline/volume_create/">managed volume</a>
into the container.</li> <li><tt>bind</tt>:
bind-mounts a directory or file from the host into the container.</li>
<li><tt>tmpfs</tt>: mount a tmpfs in the container</li>
<li><tt>npipe</tt>: mounts named pipe from the host into the container (Windows containers only).</li>
</ul></p>
</ul>
</td>
</tr>
<tr>
@ -389,11 +392,11 @@ volumes in a service:
<td>
<p>The Engine mounts binds and volumes <tt>read-write</tt> unless <tt>readonly</tt> option
is given when mounting the bind or volume. Note that setting <tt>readonly</tt> for a
bind-mount does not make its submounts <tt>readonly</tt> on the current Linux implementation. See also <tt>bind-nonrecursive</tt>.
bind-mount does not make its submounts <tt>readonly</tt> on the current Linux implementation. See also <tt>bind-nonrecursive</tt>.</p>
<ul>
<li><tt>true</tt> or <tt>1</tt> or no value: Mounts the bind or volume read-only.</li>
<li><tt>false</tt> or <tt>0</tt>: Mounts the bind or volume read-write.</li>
</ul></p>
</ul>
</td>
</tr>
</table>
@ -417,14 +420,13 @@ The following options can only be used for bind mounts (`type=bind`):
<tr>
<td><b>consistency</b></td>
<td>
<p>The consistency requirements for the mount; one of
<p>The consistency requirements for the mount; one of </p>
<ul>
<li><tt>default</tt>: Equivalent to <tt>consistent</tt>.</li>
<li><tt>consistent</tt>: Full consistency. The container runtime and the host maintain an identical view of the mount at all times.</li>
<li><tt>cached</tt>: The host's view of the mount is authoritative. There may be delays before updates made on the host are visible within a container.</li>
<li><tt>delegated</tt>: The container runtime's view of the mount is authoritative. There may be delays before updates made in a container are visible on the host.</li>
</ul>
</p>
</td>
</tr>
<tr>
@ -506,7 +508,7 @@ The following options can only be used for named volumes (`type=volume`):
creation. For example,
<tt>volume-label=mylabel=hello-world,my-other-label=hello-mars</tt>. For more
information about labels, refer to
<a href="https://docs.docker.com/engine/userguide/labels-custom-metadata/">apply custom metadata</a>.
<a href="https://docs.docker.com/config/labels-custom-metadata/">apply custom metadata</a>.
</td>
</tr>
<tr>
@ -914,7 +916,7 @@ $ docker service create \
The swarm extends my-network to each node running the service.
Containers on the same network can access each other using
[service discovery](https://docs.docker.com/engine/swarm/networking/#use-swarm-mode-service-discovery).
[service discovery](https://docs.docker.com/network/overlay/#container-discovery).
Long form syntax of `--network` allows to specify list of aliases and driver options:
`--network name=my-network,alias=web1,driver-opt=field1=value1`
@ -924,7 +926,7 @@ Long form syntax of `--network` allows to specify list of aliases and driver opt
You can publish service ports to make them available externally to the swarm
using the `--publish` flag. The `--publish` flag can take two different styles
of arguments. The short version is positional, and allows you to specify the
published port and target port separated by a colon.
published port and target port separated by a colon (`:`).
```bash
$ docker service create --name my_web --replicas 3 --publish 8080:80 nginx
@ -1068,7 +1070,8 @@ In this example, we are going to set the template of the created containers base
service's name, the node's ID and hostname where it sits.
```bash
$ docker service create --name hosttempl \
$ docker service create \
--name hosttempl \
--hostname="{{.Node.Hostname}}-{{.Node.ID}}-{{.Service.Name}}"\
busybox top
@ -1105,7 +1108,8 @@ You can narrow the kind of nodes your task can land on through the using the
`--generic-resource` flag (if the nodes advertise these resources):
```bash
$ docker service create --name cuda \
$ docker service create \
--name cuda \
--generic-resource "NVIDIA-GPU=2" \
--generic-resource "SSD=1" \
nvidia/cuda

11
docs/reference/commandline/service_inspect.md
View File

@ -27,9 +27,12 @@ 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.
> **Note**: This is a cluster management command, and must be executed on a swarm
> manager node. To learn about managers and workers, refer to the [Swarm mode
> section](https://docs.docker.com/engine/swarm/) in the documentation.
> **Note**
>
> This is a cluster management command, and must be executed on a swarm
> manager node. To learn about managers and workers, refer to the
> [Swarm mode section](https://docs.docker.com/engine/swarm/) in the
> documentation.
## Examples
@ -48,7 +51,7 @@ dmu1ept4cxcf redis replicated 3/3 redis:3.0.6
Both `docker service inspect redis`, and `docker service inspect dmu1ept4cxcf`
produce the same result:
```none
```bash
$ docker service inspect redis
[

15
docs/reference/commandline/service_logs.md
View File

@ -26,20 +26,25 @@ Options:
The `docker service logs` command batch-retrieves logs present at the time of execution.
> **Note**: This is a cluster management command, and must be executed on a swarm
> manager node. To learn about managers and workers, refer to the [Swarm mode
> section](https://docs.docker.com/engine/swarm/) in the documentation.
> **Note**
>
> This is a cluster management command, and must be executed on a swarm
> manager node. To learn about managers and workers, refer to the
> [Swarm mode section](https://docs.docker.com/engine/swarm/) in the
> documentation.
The `docker service logs` command can be used with either the name or ID of a
service, or with the ID of a task. If a service is passed, it will display logs
for all of the containers in that service. If a task is passed, it will only
display logs from that particular task.
> **Note**: This command is only functional for services that are started with
> **Note**
>
> This command is only functional for services that are started with
> the `json-file` or `journald` logging driver.
For more information about selecting and configuring logging drivers, refer to
[Configure logging drivers](https://docs.docker.com/engine/admin/logging/overview/).
[Configure logging drivers](https://docs.docker.com/config/containers/logging/configure/).
The `docker service logs --follow` command will continue streaming the new output from
the service's `STDOUT` and `STDERR`.

11
docs/reference/commandline/service_ls.md
View File

@ -25,9 +25,12 @@ Options:
This command lists services are running in the swarm.
> **Note**: This is a cluster management command, and must be executed on a swarm
> manager node. To learn about managers and workers, refer to the [Swarm mode
> section](https://docs.docker.com/engine/swarm/) in the documentation.
> **Note**
>
> This is a cluster management command, and must be executed on a swarm
> manager node. To learn about managers and workers, refer to the
> [Swarm mode section](https://docs.docker.com/engine/swarm/) in the
> documentation.
## Examples
@ -138,7 +141,7 @@ output the data exactly as the template declares or, when using the
`table` directive, includes column headers as well.
The following example uses a template without headers and outputs the
`ID`, `Mode`, and `Replicas` entries separated by a colon for all services:
`ID`, `Mode`, and `Replicas` entries separated by a colon (`:`) for all services:
```bash
$ docker service ls --format "{{.ID}}: {{.Mode}} {{.Replicas}}"

11
docs/reference/commandline/service_ps.md
View File

@ -25,9 +25,12 @@ Options:
Lists the tasks that are running as part of the specified services.
> **Note**: This is a cluster management command, and must be executed on a swarm
> manager node. To learn about managers and workers, refer to the [Swarm mode
> section](https://docs.docker.com/engine/swarm/) in the documentation.
> **Note**
>
> This is a cluster management command, and must be executed on a swarm
> manager node. To learn about managers and workers, refer to the
> [Swarm mode section](https://docs.docker.com/engine/swarm/) in the
> documentation.
## Examples
@ -168,7 +171,7 @@ output the data exactly as the template declares or, when using the
`table` directive, includes column headers as well.
The following example uses a template without headers and outputs the
`Name` and `Image` entries separated by a colon for all tasks:
`Name` and `Image` entries separated by a colon (`:`) for all tasks:
```bash
$ docker service ps --format "{{.Name}}: {{.Image}}" top

15
docs/reference/commandline/service_rm.md
View File

@ -22,9 +22,12 @@ Options:
Removes the specified services from the swarm.
> **Note**: This is a cluster management command, and must be executed on a swarm
> manager node. To learn about managers and workers, refer to the [Swarm mode
> section](https://docs.docker.com/engine/swarm/) in the documentation.
> **Note**
>
> This is a cluster management command, and must be executed on a swarm
> manager node. To learn about managers and workers, refer to the
> [Swarm mode section](https://docs.docker.com/engine/swarm/) in the
> documentation.
## Examples
@ -40,8 +43,10 @@ $ docker service ls
ID NAME MODE REPLICAS IMAGE
```
> **Warning**: Unlike `docker rm`, this command does not ask for confirmation
> before removing a running service.
> **Warning**
>
> Unlike `docker rm`, this command does not ask for confirmation before removing
> a running service.
## Related commands

9
docs/reference/commandline/service_rollback.md
View File

@ -21,9 +21,12 @@ Options:
Roll back a specified service to its previous version from the swarm.
> **Note**: This is a cluster management command, and must be executed on a swarm
> manager node. To learn about managers and workers, refer to the [Swarm mode
> section](https://docs.docker.com/engine/swarm/) in the documentation.
> **Note**
>
> This is a cluster management command, and must be executed on a swarm
> manager node. To learn about managers and workers, refer to the
> [Swarm mode section](https://docs.docker.com/engine/swarm/) in the
> documentation.
## Examples

9
docs/reference/commandline/service_scale.md
View File

@ -24,9 +24,12 @@ services which are global mode. The command will return immediately, but the
actual scaling of the service may take some time. To stop all replicas of a
service while keeping the service active in the swarm you can set the scale to 0.
> **Note**: This is a cluster management command, and must be executed on a swarm
> manager node. To learn about managers and workers, refer to the [Swarm mode
> section](https://docs.docker.com/engine/swarm/) in the documentation.
> **Note**
>
> This is a cluster management command, and must be executed on a swarm
> manager node. To learn about managers and workers, refer to the
> [Swarm mode section](https://docs.docker.com/engine/swarm/) in the
> documentation.
## Examples

22
docs/reference/commandline/service_update.md
View File

@ -110,9 +110,12 @@ service requires recreating the tasks for it to take effect. For example, only c
setting. However, the `--force` flag will cause the tasks to be recreated anyway. This can be used to perform a
rolling restart without any changes to the service parameters.
> **Note**: This is a cluster management command, and must be executed on a swarm
> manager node. To learn about managers and workers, refer to the [Swarm mode
> section](https://docs.docker.com/engine/swarm/) in the documentation.
> **Note**
>
> This is a cluster management command, and must be executed on a swarm
> manager node. To learn about managers and workers, refer to the
> [Swarm mode section](https://docs.docker.com/engine/swarm/) in the
> documentation.
## Examples
@ -147,9 +150,8 @@ point, effectively removing the `test-data` volume. Each command returns the
service name.
- The `--mount-add` flag takes the same parameters as the `--mount` flag on
`service create`. Refer to the [volumes and
bind mounts](service_create.md#volumes-and-bind-mounts-mount) section in the
`service create` reference for details.
`service create`. Refer to the [volumes and bind mounts](service_create.md#add-bind-mounts-volumes-or-memory-filesystems)
section in the `service create` reference for details.
- The `--mount-rm` flag takes the `target` path of the mount.
@ -179,7 +181,7 @@ myservice
Use the `--publish-add` or `--publish-rm` flags to add or remove a published
port for a service. You can use the short or long syntax discussed in the
[docker service create](service_create/#publish-service-ports-externally-to-the-swarm)
[docker service create](service_create.md#publish-service-ports-externally-to-the-swarm--p---publish)
reference.
The following example adds a published service port to an existing service.
@ -194,7 +196,7 @@ $ docker service update \
Use the `--network-add` or `--network-rm` flags to add or remove a network for
a service. You can use the short or long syntax discussed in the
[docker service create](service_create/#attach-a-service-to-an-existing-network-network)
[docker service create](service_create.md#attach-a-service-to-an-existing-network---network)
reference.
The following example adds a new alias name to an existing service already connected to network my-network:
@ -288,13 +290,13 @@ $ docker service update \
### Update services using templates
Some flags of `service update` support the use of templating.
See [`service create`](./service_create.md#templating) for the reference.
See [`service create`](service_create.md#create-services-using-templates) for the reference.
### Specify isolation mode (Windows)
`service update` supports the same `--isolation` flag as `service create`
See [`service create`](./service_create.md) for the reference.
See [`service create`](service_create.md) for the reference.
## Related commands

10
docs/reference/commandline/stack_deploy.md
View File

@ -31,10 +31,12 @@ Options:
Create and update a stack from a `compose` file on the swarm.
> **Note**: This is a cluster management command. When using swarm as an orchestrator,
> this command must be executed on a swarm manager node. To learn about managers
> and workers, refer to the [Swarm mode section](https://docs.docker.com/engine/swarm/)
> in the documentation.
> **Note**
>
> This is a cluster management command, and must be executed on a swarm
> manager node. To learn about managers and workers, refer to the
> [Swarm mode section](https://docs.docker.com/engine/swarm/) in the
> documentation.
## Examples

12
docs/reference/commandline/stack_ls.md
View File

@ -26,10 +26,12 @@ Options:
Lists the stacks.
> **Note**: This is a cluster management command. When using swarm as an orchestrator,
> this command must be executed on a swarm manager node. To learn about managers
> and workers, refer to the [Swarm mode section](https://docs.docker.com/engine/swarm/)
> in the documentation.
> **Note**
>
> This is a cluster management command, and must be executed on a swarm
> manager node. To learn about managers and workers, refer to the
> [Swarm mode section](https://docs.docker.com/engine/swarm/) in the
> documentation.
## Examples
@ -61,7 +63,7 @@ the data exactly as the template declares or, when using the
`table` directive, includes column headers as well.
The following example uses a template without headers and outputs the
`Name` and `Services` entries separated by a colon for all stacks:
`Name` and `Services` entries separated by a colon (`:`) for all stacks:
```bash
$ docker stack ls --format "{{.Name}}: {{.Services}}"

12
docs/reference/commandline/stack_ps.md
View File

@ -27,10 +27,12 @@ Options:
Lists the tasks that are running as part of the specified stack.
> **Note**: This is a cluster management command. When using swarm as an orchestrator,
> this command must be executed on a swarm manager node. To learn about managers
> and workers, refer to the [Swarm mode section](https://docs.docker.com/engine/swarm/)
> in the documentation.
> **Note**
>
> This is a cluster management command, and must be executed on a swarm
> manager node. To learn about managers and workers, refer to the
> [Swarm mode section](https://docs.docker.com/engine/swarm/) in the
> documentation.
## Examples
@ -138,7 +140,7 @@ output the data exactly as the template declares or, when using the
`table` directive, includes column headers as well.
The following example uses a template without headers and outputs the
`Name` and `Image` entries separated by a colon for all tasks:
`Name` and `Image` entries separated by a colon (`:`) for all tasks:
```bash
$ docker stack ps --format "{{.Name}}: {{.Image}}" voting

10
docs/reference/commandline/stack_rm.md
View File

@ -25,10 +25,12 @@ Options:
Remove the stack from the swarm.
> **Note**: This is a cluster management command. When using swarm as an orchestrator,
> this command must be executed on a swarm manager node. To learn about managers
> and workers, refer to the [Swarm mode section](https://docs.docker.com/engine/swarm/)
> in the documentation.
> **Note**
>
> This is a cluster management command, and must be executed on a swarm
> manager node. To learn about managers and workers, refer to the
> [Swarm mode section](https://docs.docker.com/engine/swarm/) in the
> documentation.
## Examples

14
docs/reference/commandline/stack_services.md
View File

@ -25,10 +25,12 @@ Options:
Lists the services that are running as part of the specified stack.
> **Note**: This is a cluster management command. When using swarm as an orchestrator,
> this command must be executed on a swarm manager node. To learn about managers
> and workers, refer to the [Swarm mode section](https://docs.docker.com/engine/swarm/)
> in the documentation.
> **Note**
>
> This is a cluster management command, and must be executed on a swarm
> manager node. To learn about managers and workers, refer to the
> [Swarm mode section](https://docs.docker.com/engine/swarm/) in the
> documentation.
## Examples
@ -87,7 +89,7 @@ using a Go template.
Valid placeholders for the Go template are listed below:
Placeholder | Description
------------|------------------------------------------------------------------------------------------
------------|-------------------------------------------------------------------
`.ID` | Service ID
`.Name` | Service name
`.Mode` | Service mode (replicated, global)
@ -99,7 +101,7 @@ output the data exactly as the template declares or, when using the
`table` directive, includes column headers as well.
The following example uses a template without headers and outputs the
`ID`, `Mode`, and `Replicas` entries separated by a colon for all services:
`ID`, `Mode`, and `Replicas` entries separated by a colon (`:`) for all services:
```bash
$ docker stack services --format "{{.ID}}: {{.Mode}} {{.Replicas}}"

28
docs/reference/commandline/stats.md
View File

@ -21,13 +21,28 @@ Options:
## Description
The `docker stats` command returns a live data stream for running containers. To limit data to one or more specific containers, specify a list of container names or ids separated by a space. You can specify a stopped container but stopped containers do not return any data.
The `docker stats` command returns a live data stream for running containers. To
limit data to one or more specific containers, specify a list of container names
or ids separated by a space. You can specify a stopped container but stopped
containers do not return any data.
If you want more detailed information about a container's resource usage, use the `/containers/(id)/stats` API endpoint.
If you need more detailed information about a container's resource usage, use
the `/containers/(id)/stats` API endpoint.
> **Note**: On Linux, the Docker CLI reports memory usage by subtracting page cache usage from the total memory usage. The API does not perform such a calculation but rather provides the total memory usage and the amount from the page cache so that clients can use the data as needed.
> **Note**
>
> On Linux, the Docker CLI reports memory usage by subtracting page cache usage
> from the total memory usage. The API does not perform such a calculation but
> rather provides the total memory usage and the amount from the page cache so
> that clients can use the data as needed.
> **Note**: The `PIDS` column contains the number of processes and kernel threads created by that container. Threads is the term used by Linux kernel. Other equivalent terms are "lightweight process" or "kernel task", etc. A large number in the `PIDS` column combined with a small number of processes (as reported by `ps` or `top`) may indicate that something in the container is creating many threads.
> **Note**
>
> The `PIDS` column contains the number of processes and kernel threads created
> by that container. Threads is the term used by Linux kernel. Other equivalent
> terms are "lightweight process" or "kernel task", etc. A large number in the
> `PIDS` column combined with a small number of processes (as reported by `ps`
> or `top`) may indicate that something in the container is creating many threads.
## Examples
@ -129,7 +144,7 @@ outputs the data exactly as the template declares or, when using the
`table` directive, includes column headers as well.
The following example uses a template without headers and outputs the
`Container` and `CPUPerc` entries separated by a colon for all images:
`Container` and `CPUPerc` entries separated by a colon (`:`) for all images:
```bash
$ docker stats --format "{{.Container}}: {{.CPUPerc}}"
@ -161,6 +176,3 @@ On Windows:
"table {{.ID}}\t{{.Name}}\t{{.CPUPerc}}\t{{.MemUsage}}\t{{.NetIO}}\t{{.BlockIO}}"
> **Note**: On Docker 17.09 and older, the `{{.Container}}` column was used,
> instead of `{{.ID}}\t{{.Name}}`.

13
docs/reference/commandline/swarm_ca.md
View File

@ -26,9 +26,12 @@ Options:
View or rotate the current swarm CA certificate.
> **Note**: This is a cluster management command, and must be executed on a swarm
> manager node. To learn about managers and workers, refer to the [Swarm mode
> section](https://docs.docker.com/engine/swarm/) in the documentation.
> **Note**
>
> This is a cluster management command, and must be executed on a swarm
> manager node. To learn about managers and workers, refer to the
> [Swarm mode section](https://docs.docker.com/engine/swarm/) in the
> documentation.
## Examples
@ -111,7 +114,7 @@ progress of the rotation.
* [swarm init](swarm_init.md)
* [swarm join](swarm_join.md)
* [swarm join-token](swarm_join_token.md)
* [swarm join-token](swarm_join-token.md)
* [swarm leave](swarm_leave.md)
* [swarm unlock](swarm_unlock.md)
* [swarm unlock-key](swarm_unlock_key.md)
* [swarm unlock-key](swarm_unlock-key.md)

6
docs/reference/commandline/swarm_init.md
View File

@ -55,7 +55,7 @@ a new node to the swarm, the node joins as a worker or manager node based upon t
to [swarm join](swarm_join.md).
After you create the swarm, you can display or rotate the token using
[swarm join-token](swarm_join_token.md).
[swarm join-token](swarm_join-token.md).
### `--autolock`
@ -189,8 +189,8 @@ by passing `--availability=drain` to `docker swarm init`.
* [swarm ca](swarm_ca.md)
* [swarm join](swarm_join.md)
* [swarm join-token](swarm_join_token.md)
* [swarm join-token](swarm_join-token.md)
* [swarm leave](swarm_leave.md)
* [swarm unlock](swarm_unlock.md)
* [swarm unlock-key](swarm_unlock_key.md)
* [swarm unlock-key](swarm_unlock-key.md)
* [swarm update](swarm_update.md)

14
docs/reference/commandline/swarm_join-token.md
View File

@ -25,9 +25,12 @@ role. You pass the token using the `--token` flag when you run
[swarm join](swarm_join.md). Nodes use the join token only when they join the
swarm.
> **Note**: This is a cluster management command, and must be executed on a swarm
> manager node. To learn about managers and workers, refer to the [Swarm mode
> section](https://docs.docker.com/engine/swarm/) in the documentation.
> **Note**
>
> This is a cluster management command, and must be executed on a swarm
> manager node. To learn about managers and workers, refer to the
> [Swarm mode section](https://docs.docker.com/engine/swarm/) in the
> documentation.
## Examples
@ -39,6 +42,7 @@ the swarm:
```bash
$ docker swarm join-token worker
To add a worker to this swarm, run the following command:
docker swarm join \
@ -46,6 +50,7 @@ To add a worker to this swarm, run the following command:
172.17.0.2:2377
$ docker swarm join-token manager
To add a manager to this swarm, run the following command:
docker swarm join \
@ -57,6 +62,7 @@ Use the `--rotate` flag to generate a new join token for the specified role:
```bash
$ docker swarm join-token --rotate worker
Successfully rotated worker join token.
To add a worker to this swarm, run the following command:
@ -106,5 +112,5 @@ Only print the token. Do not print a complete command for joining.
* [swarm join](swarm_join.md)
* [swarm leave](swarm_leave.md)
* [swarm unlock](swarm_unlock.md)
* [swarm unlock-key](swarm_unlock_key.md)
* [swarm unlock-key](swarm_unlock-key.md)
* [swarm update](swarm_update.md)

4
docs/reference/commandline/swarm_join.md
View File

@ -117,8 +117,8 @@ by passing `--availability=drain` to `docker swarm join`.
* [swarm ca](swarm_ca.md)
* [swarm init](swarm_init.md)
* [swarm join-token](swarm_join_token.md)
* [swarm join-token](swarm_join-token.md)
* [swarm leave](swarm_leave.md)
* [swarm unlock](swarm_unlock.md)
* [swarm unlock-key](swarm_unlock_key.md)
* [swarm unlock-key](swarm_unlock-key.md)
* [swarm update](swarm_update.md)

6
docs/reference/commandline/swarm_leave.md
View File

@ -33,6 +33,7 @@ Consider the following swarm, as seen from the manager:
```bash
$ docker node ls
ID HOSTNAME STATUS AVAILABILITY MANAGER STATUS
7ln70fl22uw2dvjn2ft53m3q5 worker2 Ready Active
dkp8vy1dq1kxleu9g4u78tlag worker1 Ready Active
@ -43,6 +44,7 @@ To remove `worker2`, issue the following command from `worker2` itself:
```bash
$ docker swarm leave
Node left the default swarm.
```
@ -57,7 +59,7 @@ command.
* [node rm](node_rm.md)
* [swarm init](swarm_init.md)
* [swarm join](swarm_join.md)
* [swarm join-token](swarm_join_token.md)
* [swarm join-token](swarm_join-token.md)
* [swarm unlock](swarm_unlock.md)
* [swarm unlock-key](swarm_unlock_key.md)
* [swarm unlock-key](swarm_unlock-key.md)
* [swarm update](swarm_update.md)

13
docs/reference/commandline/swarm_unlock-key.md
View File

@ -26,9 +26,12 @@ swarm.
You can view or rotate the unlock key using `swarm unlock-key`. To view the key,
run the `docker swarm unlock-key` command without any arguments:
> **Note**: This is a cluster management command, and must be executed on a swarm
> manager node. To learn about managers and workers, refer to the [Swarm mode
> section](https://docs.docker.com/engine/swarm/) in the documentation.
> **Note**
>
> This is a cluster management command, and must be executed on a swarm
> manager node. To learn about managers and workers, refer to the
> [Swarm mode section](https://docs.docker.com/engine/swarm/) in the
> documentation.
## Examples
@ -49,6 +52,7 @@ key:
```bash
$ docker swarm unlock-key --rotate
Successfully rotated manager unlock key.
To unlock a swarm manager after it restarts, run the `docker swarm unlock`
@ -64,6 +68,7 @@ The `-q` (or `--quiet`) flag only prints the key:
```bash
$ docker swarm unlock-key -q
SWMKEY-1-7c37Cc8654o6p38HnroywCi19pllOnGtbdZEgtKxZu8
```
@ -81,7 +86,7 @@ Only print the unlock key, without instructions.
* [swarm ca](swarm_ca.md)
* [swarm init](swarm_init.md)
* [swarm join](swarm_join.md)
* [swarm join-token](swarm_join_token.md)
* [swarm join-token](swarm_join-token.md)
* [swarm leave](swarm_leave.md)
* [swarm unlock](swarm_unlock.md)
* [swarm update](swarm_update.md)

13
docs/reference/commandline/swarm_unlock.md
View File

@ -22,9 +22,12 @@ used to reactivate a manager after its Docker daemon restarts if the autolock
setting is turned on. The unlock key is printed at the time when autolock is
enabled, and is also available from the `docker swarm unlock-key` command.
> **Note**: This is a cluster management command, and must be executed on a swarm
> manager node. To learn about managers and workers, refer to the [Swarm mode
> section](https://docs.docker.com/engine/swarm/) in the documentation.
> **Note**
>
> This is a cluster management command, and must be executed on a swarm
> manager node. To learn about managers and workers, refer to the
> [Swarm mode section](https://docs.docker.com/engine/swarm/) in the
> documentation.
## Examples
@ -38,7 +41,7 @@ Please enter unlock key:
* [swarm ca](swarm_ca.md)
* [swarm init](swarm_init.md)
* [swarm join](swarm_join.md)
* [swarm join-token](swarm_join_token.md)
* [swarm join-token](swarm_join-token.md)
* [swarm leave](swarm_leave.md)
* [swarm unlock-key](swarm_unlock_key.md)
* [swarm unlock-key](swarm_unlock-key.md)
* [swarm update](swarm_update.md)

13
docs/reference/commandline/swarm_update.md
View File

@ -26,9 +26,12 @@ Options:
Updates a swarm with new parameter values.
> **Note**: This is a cluster management command, and must be executed on a swarm
> manager node. To learn about managers and workers, refer to the [Swarm mode
> section](https://docs.docker.com/engine/swarm/) in the documentation.
> **Note**
>
> This is a cluster management command, and must be executed on a swarm
> manager node. To learn about managers and workers, refer to the
> [Swarm mode section](https://docs.docker.com/engine/swarm/) in the
> documentation.
## Examples
@ -41,7 +44,7 @@ $ docker swarm update --cert-expiry 720h
* [swarm ca](swarm_ca.md)
* [swarm init](swarm_init.md)
* [swarm join](swarm_join.md)
* [swarm join-token](swarm_join_token.md)
* [swarm join-token](swarm_join-token.md)
* [swarm leave](swarm_leave.md)
* [swarm unlock](swarm_unlock.md)
* [swarm unlock-key](swarm_unlock_key.md)
* [swarm unlock-key](swarm_unlock-key.md)

7
docs/reference/commandline/system_df.md
View File

@ -66,8 +66,9 @@ my-named-vol 0
* `UNIQUE SIZE` is the amount of space that is only used by a given image
* `SIZE` is the virtual size of the image, it is the sum of `SHARED SIZE` and `UNIQUE SIZE`
> **Note**: Network information is not shown because it doesn't consume the disk
> space.
> **Note**
>
> Network information is not shown because it does not consume disk space.
## Performance
@ -98,7 +99,7 @@ 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
`Type` and `TotalCount` entries separated by a colon:
`Type` and `TotalCount` entries separated by a colon (`:`):
```bash
$ docker system df --format "{{.Type}}: {{.TotalCount}}"

20
docs/reference/commandline/system_events.md
View File

@ -175,7 +175,7 @@ $ docker stop test
**Shell 1: (Again .. now showing events):**
```none
```console
2017-01-05T00:35:58.859401177+08:00 container create 0fdb48addc82871eb34eb23a847cfd033dedd1a0a37bef2e6d9eb3870fc7ff37 (image=alpine:latest, name=test)
2017-01-05T00:36:04.703631903+08:00 network connect e2e1f5ceda09d4300f3a846f0acfaa9a8bb0d89e775eb744c5acecd60e0529e2 (container=0fdb...ff37, name=bridge, type=bridge)
2017-01-05T00:36:04.795031609+08:00 container start 0fdb...ff37 (image=alpine:latest, name=test)
@ -194,6 +194,7 @@ machine, using the following different time syntaxes:
```bash
$ docker system events --since 1483283804
2017-01-05T00:35:41.241772953+08:00 volume create testVol (driver=local)
2017-01-05T00:35:58.859401177+08:00 container create d9cd...4d70 (image=alpine:latest, name=test)
2017-01-05T00:36:04.703631903+08:00 network connect e2e1...29e2 (container=0fdb...ff37, name=bridge, type=bridge)
@ -204,6 +205,7 @@ $ docker system events --since 1483283804
2017-01-05T00:36:09.890214053+08:00 container stop 0fdb...ff37 (image=alpine:latest, name=test)
$ docker system events --since '2017-01-05'
2017-01-05T00:35:41.241772953+08:00 volume create testVol (driver=local)
2017-01-05T00:35:58.859401177+08:00 container create d9cd...4d70 (image=alpine:latest, name=test)
2017-01-05T00:36:04.703631903+08:00 network connect e2e1...29e2 (container=0fdb...ff37, name=bridge, type=bridge)
@ -214,6 +216,7 @@ $ docker system events --since '2017-01-05'
2017-01-05T00:36:09.890214053+08:00 container stop 0fdb...ff37 (image=alpine:latest, name=test)
$ docker system events --since '2013-09-03T15:49:29'
2017-01-05T00:35:41.241772953+08:00 volume create testVol (driver=local)
2017-01-05T00:35:58.859401177+08:00 container create d9cd...4d70 (image=alpine:latest, name=test)
2017-01-05T00:36:04.703631903+08:00 network connect e2e1...29e2 (container=0fdb...ff37, name=bridge, type=bridge)
@ -224,6 +227,7 @@ $ docker system events --since '2013-09-03T15:49:29'
2017-01-05T00:36:09.890214053+08:00 container stop 0fdb...ff37 (image=alpine:latest, name=test)
$ docker system events --since '10m'
2017-01-05T00:35:41.241772953+08:00 volume create testVol (driver=local)
2017-01-05T00:35:58.859401177+08:00 container create d9cd...4d70 (image=alpine:latest, name=test)
2017-01-05T00:36:04.703631903+08:00 network connect e2e1...29e2 (container=0fdb...ff37, name=bridge, type=bridge)
@ -325,12 +329,12 @@ Type=container Status=destroy ID=2ee349dac409e97974ce8d01b70d250b85e0ba8189299
#### Format as JSON
```none
$ docker system events --format '{{json .}}'
```bash
$ docker system events --format '{{json .}}'
{"status":"create","id":"196016a57679bf42424484918746a9474cd905dd993c4d0f4..
{"status":"attach","id":"196016a57679bf42424484918746a9474cd905dd993c4d0f4..
{"Type":"network","Action":"connect","Actor":{"ID":"1b50a5bf755f6021dfa78e..
{"status":"start","id":"196016a57679bf42424484918746a9474cd905dd993c4d0f42..
{"status":"resize","id":"196016a57679bf42424484918746a9474cd905dd993c4d0f4..
{"status":"create","id":"196016a57679bf42424484918746a9474cd905dd993c4d0f4..
{"status":"attach","id":"196016a57679bf42424484918746a9474cd905dd993c4d0f4..
{"Type":"network","Action":"connect","Actor":{"ID":"1b50a5bf755f6021dfa78e..
{"status":"start","id":"196016a57679bf42424484918746a9474cd905dd993c4d0f42..
{"status":"resize","id":"196016a57679bf42424484918746a9474cd905dd993c4d0f4..
```

14
docs/reference/commandline/system_prune.md
View File

@ -97,11 +97,13 @@ deleted: sha256:3a88a5c81eb5c283e72db2dbc6d65cbfd8e80b6c89bb6e714cfaaa0eed99c548
Total reclaimed space: 13.5 MB
```
> **Note**: The `--volumes` option was added in Docker 17.06.1. Older versions
> of Docker prune volumes by default, along with other Docker objects. On older
> versions, run `docker container prune`, `docker network prune`, and
> `docker image prune` separately to remove unused containers, networks, and
> images, without removing volumes.
> **Note**
>
> The `--volumes` option was added in Docker 17.06.1. Older versions of Docker
> prune volumes by default, along with other Docker objects. On older versions,
> run `docker container prune`, `docker network prune`, and `docker image prune`
> separately to remove unused containers, networks, and images, without removing
> volumes.
### Filtering
@ -138,7 +140,7 @@ containers, images, networks, and volumes without the specified labels.
* [volume inspect](volume_inspect.md)
* [volume rm](volume_rm.md)
* [volume prune](volume_prune.md)
* [Understand Data Volumes](https://docs.docker.com/engine/tutorials/dockervolumes/)
* [Understand Data Volumes](https://docs.docker.com/storage/volumes/)
* [system df](system_df.md)
* [container prune](container_prune.md)
* [image prune](image_prune.md)

2
docs/reference/commandline/tag.md
View File

@ -31,7 +31,7 @@ digits, underscores, periods and dashes. A tag name may not start with a
period or a dash and may contain a maximum of 128 characters.
You can group your images together using names and tags, and then upload them
to [*Share Images via Repositories*](https://docs.docker.com/engine/tutorials/dockerrepos/#/contributing-to-docker-hub).
to [*Share images on Docker Hub*](https://docs.docker.com/get-started/part3/).
## Examples

7
docs/reference/commandline/trust_inspect.md
View File

@ -149,6 +149,7 @@ display any signed tags.
```bash
$ docker trust inspect unsigned-img
No signatures or cannot access unsigned-img
```
@ -157,6 +158,7 @@ However, if other tags are signed in the same image repository,
```bash
$ docker trust inspect alpine:unsigned
[
{
"Name": "alpine:unsigned",
@ -190,6 +192,7 @@ signed tags in the repository:
```bash
$ docker trust inspect alpine
[
{
"Name": "alpine",
@ -254,6 +257,7 @@ and reports the results in an ordered list:
```bash
$ docker trust inspect alpine notary
[
{
"Name": "alpine",
@ -386,6 +390,7 @@ and specify their `KEYS`:
```bash
$ docker trust inspect --pretty my-image:purple
SIGNED TAG DIGEST SIGNERS
purple 941d3dba358621ce3c41ef67b47cf80f701ff80cdf46b5cc86587eaebfe45557 alice, bob, carol
@ -419,6 +424,7 @@ Root Key: a2489bcac7a79aa67b19b96c4a3bf0c675ffdf00c6d2fabe1a5df1115e80adce
```bash
$ docker trust inspect --pretty alpine
SIGNED TAG DIGEST SIGNERS
2.6 9ace551613070689a12857d62c30ef0daa9a376107ec0fff0e34786cedb3399b (Repo Admin)
2.7 9f08005dff552038f0ad2f46b8e65ff3d25641747d3912e3ea8da6785046561a (Repo Admin)
@ -440,6 +446,7 @@ Here's an example with signers that are set up by `docker trust` commands:
```bash
$ docker trust inspect --pretty my-image
SIGNED TAG DIGEST SIGNERS
red 852cc04935f930a857b630edc4ed6131e91b22073bcc216698842e44f64d2943 alice
blue f1c38dbaeeb473c36716f6494d803fbfbe9d8a76916f7c0093f227821e378197 alice, bob

8
docs/reference/commandline/trust_revoke.md
View File

@ -28,7 +28,7 @@ Here's an example of a repo with two signed tags:
```bash
$ docker trust view example/trust-demo
$ docker trust inspect --pretty example/trust-demo
SIGNED TAG DIGEST SIGNERS
red 852cc04935f930a857b630edc4ed6131e91b22073bcc216698842e44f64d2943 alice
blue f1c38dbaeeb473c36716f6494d803fbfbe9d8a76916f7c0093f227821e378197 alice, bob
@ -55,7 +55,7 @@ Successfully deleted signature for example/trust-demo:red
After revocation, the tag is removed from the list of released tags:
```bash
$ docker trust view example/trust-demo
$ docker trust inspect --pretty example/trust-demo
SIGNED TAG DIGEST SIGNERS
blue f1c38dbaeeb473c36716f6494d803fbfbe9d8a76916f7c0093f227821e378197 alice, bob
@ -75,7 +75,7 @@ Root Key: 3cb2228f6561e58f46dbc4cda4fcaff9d5ef22e865a94636f82450d1d2234949
When no tag is specified, `docker trust` revokes all signatures that you have a signing key for.
```bash
$ docker trust view example/trust-demo
$ docker trust inspect --pretty example/trust-demo
SIGNED TAG DIGEST SIGNERS
red 852cc04935f930a857b630edc4ed6131e91b22073bcc216698842e44f64d2943 alice
blue f1c38dbaeeb473c36716f6494d803fbfbe9d8a76916f7c0093f227821e378197 alice, bob
@ -103,7 +103,7 @@ Successfully deleted signature for example/trust-demo
All tags that have `alice`'s signature on them are removed from the list of released tags:
```bash
$ docker trust view example/trust-demo
$ docker trust inspect --pretty example/trust-demo
No signatures for example/trust-demo

24
docs/reference/commandline/trust_sign.md
View File

@ -28,7 +28,8 @@ Options:
Given an image:
```bash
$ docker trust view example/trust-demo
$ docker trust inspect --pretty example/trust-demo
SIGNED TAG DIGEST SIGNERS
v1 c24134c079c35e698060beabe110bb83ab285d0d978de7d92fed2c8c83570a41 (Repo Admin)
@ -41,6 +42,7 @@ Sign a new tag with `docker trust sign`:
```bash
$ docker trust sign example/trust-demo:v2
Signing and pushing trust metadata for example/trust-demo:v2
The push refers to a repository [docker.io/example/trust-demo]
eed4e566104a: Layer already exists
@ -56,10 +58,11 @@ Enter passphrase for repository key with ID 36d4c36:
Successfully signed docker.io/example/trust-demo:v2
```
Use `docker trust view` to list the new signature:
Use `docker trust inspect --pretty` to list the new signature:
```bash
$ docker trust view example/trust-demo
$ docker trust inspect --pretty example/trust-demo
SIGNED TAG DIGEST SIGNERS
v1 c24134c079c35e698060beabe110bb83ab285d0d978de7d92fed2c8c83570a41 (Repo Admin)
v2 8f6f460abf0436922df7eb06d28b3cdf733d2cac1a185456c26debbff0839c56 (Repo Admin)
@ -74,7 +77,7 @@ Root Key: 246d360f7c53a9021ee7d4259e3c5692f3f1f7ad4737b1ea8c7b8da741ad980b
Given an image:
```bash
$ docker trust view example/trust-demo
$ docker trust inspect --pretty example/trust-demo
No signatures for example/trust-demo
@ -94,6 +97,7 @@ Sign a new tag with `docker trust sign`:
```bash
$ docker trust sign example/trust-demo:v1
Signing and pushing trust metadata for example/trust-demo:v1
The push refers to a repository [docker.io/example/trust-demo]
26b126eb8632: Layer already exists
@ -107,10 +111,11 @@ Enter passphrase for delegation key with ID 27d42a8:
Successfully signed docker.io/example/trust-demo:v1
```
`docker trust view` lists the new signature:
`docker trust inspect --pretty` lists the new signature:
```bash
$ docker trust view example/trust-demo
$ docker trust inspect --pretty example/trust-demo
SIGNED TAG DIGEST SIGNERS
v1 74d4bfa917d55d53c7df3d2ab20a8d926874d61c3da5ef6de15dd2654fc467c4 alice
@ -130,12 +135,14 @@ Root Key: 3cb2228f6561e58f46dbc4cda4fcaff9d5ef22e865a94636f82450d1d2234949
When signing an image on a repo for the first time, `docker trust sign` sets up new keys before signing the image.
```bash
$ docker trust view example/trust-demo
$ docker trust inspect --pretty example/trust-demo
No signatures or cannot access example/trust-demo
```
```bash
$ docker trust sign example/trust-demo:v1
Signing and pushing trust metadata for example/trust-demo:v1
Enter passphrase for root key with ID 36cac18:
Enter passphrase for new repository key with ID 731396b:
@ -159,7 +166,8 @@ Successfully signed docker.io/example/trust-demo:v1
```
```bash
$ docker trust view example/trust-demo
$ docker trust inspect --pretty example/trust-demo
SIGNED TAG DIGEST SIGNERS
v1 8f6f460abf0436922df7eb06d28b3cdf733d2cac1a185456c26debbff0839c56 alice

36
docs/reference/commandline/trust_signer_add.md
View File

@ -27,7 +27,7 @@ Options:
To add a new signer, `alice`, to this repository:
```bash
$ docker trust view example/trust-demo
$ docker trust inspect --pretty example/trust-demo
No signatures for example/trust-demo
@ -51,10 +51,10 @@ $ docker trust signer add alice example/trust-demo --key alice.crt
Successfully added signer: alice to example/trust-demo
```
`docker trust view` now lists `alice` as a valid signer:
`docker trust inspect --pretty` now lists `alice` as a valid signer:
```bash
$ docker trust view example/trust-demo
$ docker trust inspect --pretty example/trust-demo
No signatures for example/trust-demo
@ -75,24 +75,26 @@ Root Key: 3cb2228f6561e58f46dbc4cda4fcaff9d5ef22e865a94636f82450d1d2234949
When adding a signer on a repo for the first time, `docker trust signer add` sets up a new repo if it doesn't exist.
```bash
$ docker trust view example/trust-demo
$ docker trust inspect --pretty example/trust-demo
No signatures or cannot access example/trust-demo
```
```bash
$ docker trust signer add alice example/trust-demo --key alice.crt
Initializing signed repository for example/trust-demo...
Enter passphrase for root key with ID 748121c:
Initializing signed repository for example/trust-demo...
Enter passphrase for root key with ID 748121c:
Enter passphrase for new repository key with ID 95b9e55:
Repeat passphrase for new repository key with ID 95b9e55:
Successfully initialized "example/trust-demo"
Adding signer "alice" to example/trust-demo...
Successfully added signer: alice to example/trust-demo
Successfully added signer: alice to example/trust-demo
```
```bash
$ docker trust view example/trust-demo
$ docker trust inspect --pretty example/trust-demo
No signatures for example/trust-demo
@ -112,7 +114,8 @@ Root Key: 748121c14bd1461f6c58cb3ef39087c8fdc7633bb11a98af844fd9a04e208103
## Add a signer to multiple repos
To add a signer, `alice`, to multiple repositories:
```bash
$ docker trust view example/trust-demo
$ docker trust inspect --pretty example/trust-demo
SIGNED TAG DIGEST SIGNERS
v1 74d4bfa917d55d53c7df3d2ab20a8d926874d61c3da5ef6de15dd2654fc467c4 bob
@ -126,7 +129,8 @@ Repository Key: ecc457614c9fc399da523a5f4e24fe306a0a6ee1cc79a10e4555b3c6ab02f71e
Root Key: 3cb2228f6561e58f46dbc4cda4fcaff9d5ef22e865a94636f82450d1d2234949
```
```bash
$ docker trust view example/trust-demo2
$ docker trust inspect --pretty example/trust-demo2
SIGNED TAG DIGEST SIGNERS
v1 74d4bfa917d55d53c7df3d2ab20a8d926874d61c3da5ef6de15dd2654fc467c4 bob
@ -143,6 +147,7 @@ Add `alice` to both repositories with a single `docker trust signer add` command
```bash
$ docker trust signer add alice example/trust-demo example/trust-demo2 --key alice.crt
Adding signer "alice" to example/trust-demo...
Enter passphrase for repository key with ID 95b9e55:
Successfully added signer: alice to example/trust-demo
@ -151,11 +156,13 @@ Adding signer "alice" to example/trust-demo2...
Enter passphrase for repository key with ID ece554f:
Successfully added signer: alice to example/trust-demo2
```
`docker trust view` now lists `alice` as a valid signer of both `example/trust-demo` and `example/trust-demo2`:
`docker trust inspect --pretty` now lists `alice` as a valid signer of both `example/trust-demo` and `example/trust-demo2`:
```bash
$ docker trust view example/trust-demo
$ docker trust inspect --pretty example/trust-demo
SIGNED TAG DIGEST SIGNERS
v1 74d4bfa917d55d53c7df3d2ab20a8d926874d61c3da5ef6de15dd2654fc467c4 bob
@ -169,8 +176,10 @@ Administrative keys for example/trust-demo:
Repository Key: 95b9e5514c9fc399da523a5f4e24fe306a0a6ee1cc79a10e4555b3c6ab02f71e
Root Key: 3cb2228f6561e58f46dbc4cda4fcaff9d5ef22e865a94636f82450d1d2234949
```
```bash
$ docker trust view example/trust-demo2
$ docker trust inspect --pretty example/trust-demo2
SIGNED TAG DIGEST SIGNERS
v1 74d4bfa917d55d53c7df3d2ab20a8d926874d61c3da5ef6de15dd2654fc467c4 bob
@ -190,6 +199,7 @@ Root Key: 3cb2228f6561e58f46dbc4cda4fcaff9d5ef22e865a94636f82450d1d2234949
```bash
$ docker trust signer add alice example/unauthorized example/authorized --key alice.crt
Adding signer "alice" to example/unauthorized...
you are not authorized to perform this operation: server returned 401.

20
docs/reference/commandline/trust_signer_remove.md
View File

@ -26,7 +26,7 @@ Options:
To remove an existing signer, `alice`, from this repository:
```bash
$ docker trust view example/trust-demo
$ docker trust inspect --pretty example/trust-demo
No signatures for example/trust-demo
@ -52,10 +52,10 @@ Enter passphrase for repository key with ID 642692c:
Successfully removed alice from example/trust-demo
```
`docker trust view` now does not list `alice` as a valid signer:
`docker trust inspect --pretty` now does not list `alice` as a valid signer:
```bash
$ docker trust view example/trust-demo
$ docker trust inspect --pretty example/trust-demo
No signatures for example/trust-demo
@ -75,7 +75,8 @@ Root Key: 3cb2228f6561e58f46dbc4cda4fcaff9d5ef22e865a94636f82450d1d2234949
To remove an existing signer, `alice`, from multiple repositories:
```bash
$ docker trust view example/trust-demo
$ docker trust inspect --pretty example/trust-demo
SIGNED TAG DIGEST SIGNERS
v1 74d4bfa917d55d53c7df3d2ab20a8d926874d61c3da5ef6de15dd2654fc467c4 alice, bob
@ -91,7 +92,8 @@ Root Key: 3cb2228f6561e58f46dbc4cda4fcaff9d5ef22e865a94636f82450d1d2234949
```
```bash
$ docker trust view example/trust-demo2
$ docker trust inspect --pretty example/trust-demo2
SIGNED TAG DIGEST SIGNERS
v1 74d4bfa917d55d53c7df3d2ab20a8d926874d61c3da5ef6de15dd2654fc467c4 alice, bob
@ -120,11 +122,12 @@ Enter passphrase for repository key with ID ece554f:
Successfully removed alice from example/trust-demo2
```
Run `docker trust view` to confirm that `alice` is no longer listed as a valid
Run `docker trust inspect --pretty` to confirm that `alice` is no longer listed as a valid
signer of either `example/trust-demo` or `example/trust-demo2`:
```bash
$ docker trust view example/trust-demo
$ docker trust inspect --pretty example/trust-demo
SIGNED TAG DIGEST SIGNERS
v1 74d4bfa917d55d53c7df3d2ab20a8d926874d61c3da5ef6de15dd2654fc467c4 bob
@ -139,7 +142,8 @@ Root Key: 3cb2228f6561e58f46dbc4cda4fcaff9d5ef22e865a94636f82450d1d2234949
```
```bash
$ docker trust view example/trust-demo2
$ docker trust inspect --pretty example/trust-demo2
SIGNED TAG DIGEST SIGNERS
v1 74d4bfa917d55d53c7df3d2ab20a8d926874d61c3da5ef6de15dd2654fc467c4 bob

6
docs/reference/commandline/update.md
View File

@ -43,8 +43,10 @@ options on a running or a stopped container. On kernel version older than
4.6, you can only update `--kernel-memory` on a stopped container or on
a running container with kernel memory initialized.
> **Warning**: The `docker update` and `docker container update` commands are
> not supported for Windows containers.
> **Warning**
>
> The `docker update` and `docker container update` commands are not supported
> for Windows containers.
{: .warning }
## Examples

40
docs/reference/commandline/version.md
View File

@ -33,20 +33,32 @@ describes all the details of the format.
$ docker version
Client:
Version: 1.8.0
API version: 1.20
Go version: go1.4.2
Git commit: f5bae0a
Built: Tue Jun 23 17:56:00 UTC 2015
OS/Arch: linux/amd64
Version: 19.03.8
API version: 1.40
Go version: go1.12.17
Git commit: afacb8b
Built: Wed Mar 11 01:21:11 2020
OS/Arch: darwin/amd64
Experimental: true
Server:
Version: 1.8.0
API version: 1.20
Go version: go1.4.2
Git commit: f5bae0a
Built: Tue Jun 23 17:56:00 UTC 2015
OS/Arch: linux/amd64
Engine:
Version: 19.03.8
API version: 1.40 (minimum version 1.12)
Go version: go1.12.17
Git commit: afacb8b
Built: Wed Mar 11 01:29:16 2020
OS/Arch: linux/amd64
Experimental: true
containerd:
Version: v1.2.13
GitCommit: 7ad184331fa3e55e52b890ea95e65ba581ae3429
runc:
Version: 1.0.0-rc10
GitCommit: dc9208a3303feef5b3839f4323d9beb36df0a9dd
docker-init:
Version: 0.18.0
GitCommit: fec3683
```
### Get the server version
@ -54,7 +66,7 @@ OS/Arch: linux/amd64
```bash
$ docker version --format '{{.Server.Version}}'
1.8.0
19.03.8
```
### Dump raw JSON data
@ -62,5 +74,5 @@ $ docker version --format '{{.Server.Version}}'
```bash
$ docker version --format '{{json .}}'
{"Client":{"Version":"1.8.0","ApiVersion":"1.20","GitCommit":"f5bae0a","GoVersion":"go1.4.2","Os":"linux","Arch":"amd64","BuildTime":"Tue Jun 23 17:56:00 UTC 2015"},"ServerOK":true,"Server":{"Version":"1.8.0","ApiVersion":"1.20","GitCommit":"f5bae0a","GoVersion":"go1.4.2","Os":"linux","Arch":"amd64","KernelVersion":"3.13.2-gentoo","BuildTime":"Tue Jun 23 17:56:00 UTC 2015"}}
{"Client":{"Platform":{"Name":"Docker Engine - Community"},"Version":"19.03.8","ApiVersion":"1.40","DefaultAPIVersion":"1.40","GitCommit":"afacb8b","GoVersion":"go1.12.17","Os":"darwin","Arch":"amd64","BuildTime":"Wed Mar 11 01:21:11 2020","Experimental":true},"Server":{"Platform":{"Name":"Docker Engine - Community"},"Components":[{"Name":"Engine","Version":"19.03.8","Details":{"ApiVersion":"1.40","Arch":"amd64","BuildTime":"Wed Mar 11 01:29:16 2020","Experimental":"true","GitCommit":"afacb8b","GoVersion":"go1.12.17","KernelVersion":"4.19.76-linuxkit","MinAPIVersion":"1.12","Os":"linux"}},{"Name":"containerd","Version":"v1.2.13","Details":{"GitCommit":"7ad184331fa3e55e52b890ea95e65ba581ae3429"}},{"Name":"runc","Version":"1.0.0-rc10","Details":{"GitCommit":"dc9208a3303feef5b3839f4323d9beb36df0a9dd"}},{"Name":"docker-init","Version":"0.18.0","Details":{"GitCommit":"fec3683"}}],"Version":"19.03.8","ApiVersion":"1.40","MinAPIVersion":"1.12","GitCommit":"afacb8b","GoVersion":"go1.12.17","Os":"linux","Arch":"amd64","KernelVersion":"4.19.76-linuxkit","Experimental":true,"BuildTime":"2020-03-11T01:29:16.000000000+00:00"}}
```

4
docs/reference/commandline/volume.md
View File

@ -33,7 +33,7 @@ prune volumes.
* [volume create](volume_create.md)
* [volume inspect](volume_inspect.md)
* [volume list](volume_list.md)
* [volume list](volume_ls.md)
* [volume rm](volume_rm.md)
* [volume prune](volume_prune.md)
* [Understand Data Volumes](https://docs.docker.com/engine/tutorials/dockervolumes/)
* [Understand Data Volumes](https://docs.docker.com/storage/volumes/)

2
docs/reference/commandline/volume_create.md
View File

@ -113,4 +113,4 @@ $ docker volume create --driver local \
* [volume ls](volume_ls.md)
* [volume rm](volume_rm.md)
* [volume prune](volume_prune.md)
* [Understand Data Volumes](https://docs.docker.com/engine/tutorials/dockervolumes/)
* [Understand Data Volumes](https://docs.docker.com/storage/volumes/)

21
docs/reference/commandline/volume_inspect.md
View File

@ -28,19 +28,26 @@ details of the format.
```bash
$ docker volume create
85bffb0677236974f93955d8ecc4df55ef5070117b0e53333cc1b443777be24d
8140a838303144125b4f54653b47ede0486282c623c3551fbc7f390cdc3e9cf5
$ docker volume inspect 85bffb0677236974f93955d8ecc4df55ef5070117b0e53333cc1b443777be24d
[
{
"Name": "85bffb0677236974f93955d8ecc4df55ef5070117b0e53333cc1b443777be24d",
"CreatedAt": "2020-04-19T11:00:21Z",
"Driver": "local",
"Mountpoint": "/var/lib/docker/volumes/85bffb0677236974f93955d8ecc4df55ef5070117b0e53333cc1b443777be24d/_data",
"Status": null
"Labels": {},
"Mountpoint": "/var/lib/docker/volumes/8140a838303144125b4f54653b47ede0486282c623c3551fbc7f390cdc3e9cf5/_data",
"Name": "8140a838303144125b4f54653b47ede0486282c623c3551fbc7f390cdc3e9cf5",
"Options": {},
"Scope": "local"
}
]
$ docker volume inspect --format '{{ .Mountpoint }}' 85bffb0677236974f93955d8ecc4df55ef5070117b0e53333cc1b443777be24d
/var/lib/docker/volumes/85bffb0677236974f93955d8ecc4df55ef5070117b0e53333cc1b443777be24d/_data
$ docker volume inspect --format '{{ .Mountpoint }}' 8140a838303144125b4f54653b47ede0486282c623c3551fbc7f390cdc3e9cf5
/var/lib/docker/volumes/8140a838303144125b4f54653b47ede0486282c623c3551fbc7f390cdc3e9cf5/_data
```
## Related commands
@ -49,4 +56,4 @@ $ docker volume inspect --format '{{ .Mountpoint }}' 85bffb0677236974f93955d8ecc
* [volume ls](volume_ls.md)
* [volume rm](volume_rm.md)
* [volume prune](volume_prune.md)
* [Understand Data Volumes](https://docs.docker.com/engine/tutorials/dockervolumes/)
* [Understand Data Volumes](https://docs.docker.com/storage/volumes/)

12
docs/reference/commandline/volume_ls.md
View File

@ -57,10 +57,10 @@ than one filter, then pass multiple flags (e.g., `--filter "foo=bar" --filter "b
The currently supported filters are:
* dangling (boolean - true or false, 0 or 1)
* driver (a volume driver's name)
* label (`label=<key>` or `label=<key>=<value>`)
* name (a volume's name)
- dangling (boolean - true or false, 0 or 1)
- driver (a volume driver's name)
- label (`label=<key>` or `label=<key>=<value>`)
- name (a volume's name)
#### dangling
@ -171,7 +171,7 @@ output the data exactly as the template declares or, when using the
`table` directive, includes column headers as well.
The following example uses a template without headers and outputs the
`Name` and `Driver` entries separated by a colon for all volumes:
`Name` and `Driver` entries separated by a colon (`:`) for all volumes:
```bash
$ docker volume ls --format "{{.Name}}: {{.Driver}}"
@ -187,4 +187,4 @@ vol3: local
* [volume inspect](volume_inspect.md)
* [volume rm](volume_rm.md)
* [volume prune](volume_prune.md)
* [Understand Data Volumes](https://docs.docker.com/engine/tutorials/dockervolumes/)
* [Understand Data Volumes](https://docs.docker.com/storage/volumes/)

2
docs/reference/commandline/volume_prune.md
View File

@ -56,7 +56,7 @@ volumes without the specified labels.
* [volume ls](volume_ls.md)
* [volume inspect](volume_inspect.md)
* [volume rm](volume_rm.md)
* [Understand Data Volumes](https://docs.docker.com/engine/tutorials/dockervolumes/)
* [Understand Data Volumes](https://docs.docker.com/storage/volumes/)
* [system df](system_df.md)
* [container prune](container_prune.md)
* [image prune](image_prune.md)

7
docs/reference/commandline/volume_rm.md
View File

@ -26,8 +26,9 @@ Remove one or more volumes. You cannot remove a volume that is in use by a conta
## Examples
```bash
$ docker volume rm hello
hello
$ docker volume rm hello
hello
```
## Related commands
@ -36,4 +37,4 @@ Remove one or more volumes. You cannot remove a volume that is in use by a conta
* [volume inspect](volume_inspect.md)
* [volume ls](volume_ls.md)
* [volume prune](volume_prune.md)
* [Understand Data Volumes](https://docs.docker.com/engine/tutorials/dockervolumes/)
* [Understand Data Volumes](https://docs.docker.com/storage/volumes/)

6
docs/reference/commandline/wait.md
View File

@ -15,8 +15,10 @@ Options:
--help Print usage
```
> **Note**: `docker wait` returns `0` when run against a container which had
> already exited before the `docker wait` command was run.
> **Note**
>
> `docker wait` returns `0` when run against a container which had already
> exited before the `docker wait` command was run.
## Examples

464
docs/reference/run.md
View File

@ -48,7 +48,9 @@ other `docker` command.
To learn how to interpret the types of `[OPTIONS]`, see [*Option
types*](commandline/cli.md#option-types).
> **Note**: Depending on your Docker system configuration, you may be
> **Note**
>
> Depending on your Docker system configuration, you may be
> required to preface the `docker run` 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
@ -128,19 +130,24 @@ If you do not specify `-a` then Docker will [attach to both stdout and stderr
You can specify to which of the three standard streams (`STDIN`, `STDOUT`,
`STDERR`) you'd like to connect instead, as in:
$ docker run -a stdin -a stdout -i -t ubuntu /bin/bash
```bash
$ docker run -a stdin -a stdout -i -t ubuntu /bin/bash
```
For interactive processes (like a shell), you must use `-i -t` together in
order to allocate a tty for the container process. `-i -t` is often written `-it`
as you'll see in later examples. Specifying `-t` is forbidden when the client
is receiving its standard input from a pipe, as in:
$ echo test | docker run -i busybox cat
```bash
$ echo test | docker run -i busybox cat
```
>**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.
> **Note**
>
> A process running as PID 1 inside a container is treated specially by Linux:
> it ignores any signal with the default action. As a result, the process will
> not terminate on `SIGINT` or `SIGTERM` unless it is coded to do so.
## Container identification
@ -161,8 +168,9 @@ container. If you specify a `name`, you can use it when referencing the
container within a Docker network. This works for both background and foreground
Docker containers.
> **Note**: Containers on the default bridge network must be linked to
> communicate by name.
> **Note**
>
> Containers on the default bridge network must be linked to communicate by name.
### PID equivalent
@ -188,7 +196,9 @@ the digest value is predictable and referenceable.
The following example runs a container from the `alpine` image with the
`sha256:9cacb71397b640eca97488cf08582ae4e4068513101088e9f96c9814bfda95e0` digest:
$ docker run alpine@sha256:9cacb71397b640eca97488cf08582ae4e4068513101088e9f96c9814bfda95e0 date
```bash
$ docker run alpine@sha256:9cacb71397b640eca97488cf08582ae4e4068513101088e9f96c9814bfda95e0 date
```
## PID settings (--pid)
@ -212,7 +222,7 @@ within the container.
Create this Dockerfile:
```
```dockerfile
FROM alpine:latest
RUN apk add --update htop && rm -rf /var/cache/apk/*
CMD ["htop"]
@ -226,7 +236,7 @@ $ docker build -t myhtop .
Use the following command to run `htop` inside a container:
```
```bash
$ docker run -it --rm --pid=host myhtop
```
@ -410,8 +420,10 @@ docker daemon. It is recommended to run containers in this mode when their
networking performance is critical, for example, a production Load Balancer
or a High Performance Web Server.
> **Note**: `--network="host"` gives the container full access to local system
> services such as D-bus and is therefore considered insecure.
> **Note**
>
> `--network="host"` gives the container full access to local system services
> such as D-bus and is therefore considered insecure.
#### Network: container
@ -426,9 +438,11 @@ Example running a Redis container with Redis binding to `localhost` then
running the `redis-cli` command and connecting to the Redis server over the
`localhost` interface.
$ docker run -d --name redis example/redis --bind 127.0.0.1
$ # use the redis container's network stack to access localhost
$ docker run --rm -it --network container:redis example/redis-cli -h 127.0.0.1
```bash
$ docker run -d --name redis example/redis --bind 127.0.0.1
$ # use the redis container's network stack to access localhost
$ docker run --rm -it --network container:redis example/redis-cli -h 127.0.0.1
```
#### User-defined network
@ -444,7 +458,7 @@ Engines can also communicate in this way.
The following example creates a network using the built-in `bridge` network
driver and running a container in the created network
```
```bash
$ docker network create -d bridge my-net
$ docker run --network=my-net -itd --name=container3 busybox
```
@ -455,24 +469,29 @@ Your container will have lines in `/etc/hosts` which define the hostname of the
container itself as well as `localhost` and a few other common things. The
`--add-host` flag can be used to add additional lines to `/etc/hosts`.
$ docker run -it --add-host db-static:86.75.30.9 ubuntu cat /etc/hosts
172.17.0.22 09d03f76bf2c
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
127.0.0.1 localhost
::1 localhost ip6-localhost ip6-loopback
86.75.30.9 db-static
```bash
$ docker run -it --add-host db-static:86.75.30.9 ubuntu cat /etc/hosts
172.17.0.22 09d03f76bf2c
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
127.0.0.1 localhost
::1 localhost ip6-localhost ip6-loopback
86.75.30.9 db-static
```
If a container is connected to the default bridge network and `linked`
with other containers, then the container's `/etc/hosts` file is updated
with the linked container's name.
> **Note** Since Docker may live update the container’s `/etc/hosts` file, there
may be situations when processes inside the container can end up reading an
empty or incomplete `/etc/hosts` file. In most cases, retrying the read again
should fix the problem.
> **Note**
>
> Since Docker may live update the container’s `/etc/hosts` file, there
> may be situations when processes inside the container can end up reading an
> empty or incomplete `/etc/hosts` file. In most cases, retrying the read again
> should fix the problem.
## Restart policies (--restart)
@ -548,18 +567,21 @@ will try forever to restart the container. The number of (attempted) restarts
for a container can be obtained via [`docker inspect`](commandline/inspect.md). For example, to get the number of restarts
for container "my-container";
{% raw %}
$ docker inspect -f "{{ .RestartCount }}" my-container
# 2
{% endraw %}
```bash
{% raw %}
$ docker inspect -f "{{ .RestartCount }}" my-container
# 2
{% endraw %}
```
Or, to get the last time the container was (re)started;
{% raw %}
$ docker inspect -f "{{ .State.StartedAt }}" my-container
# 2015-03-04T23:47:07.691840179Z
{% endraw %}
```bash
{% raw %}
$ docker inspect -f "{{ .State.StartedAt }}" my-container
# 2015-03-04T23:47:07.691840179Z
{% endraw %}
```
Combining `--restart` (restart policy) with the `--rm` (clean up) flag results
in an error. On container restart, attached clients are disconnected. See the
@ -567,12 +589,16 @@ examples on using the [`--rm` (clean up)](#clean-up-rm) flag later in this page.
### Examples
$ docker run --restart=always redis
```bash
$ docker run --restart=always redis
```
This will run the `redis` container with a restart policy of **always**
so that if the container exits, Docker will restart it.
$ docker run --restart=on-failure:10 redis
```bash
$ docker run --restart=on-failure:10 redis
```
This will run the `redis` container with a restart policy of **on-failure**
and a maximum restart count of 10. If the `redis` container exits with a
@ -588,27 +614,39 @@ the exit codes follow the `chroot` standard, see below:
**_125_** if the error is with Docker daemon **_itself_**
$ docker run --foo busybox; echo $?
# flag provided but not defined: --foo
See 'docker run --help'.
125
```bash
$ docker run --foo busybox; echo $?
flag provided but not defined: --foo
See 'docker run --help'.
125
```
**_126_** if the **_contained command_** cannot be invoked
$ docker run busybox /etc; echo $?
# docker: Error response from daemon: Container command '/etc' could not be invoked.
126
```bash
$ docker run busybox /etc; echo $?
docker: Error response from daemon: Container command '/etc' could not be invoked.
126
```
**_127_** if the **_contained command_** cannot be found
$ docker run busybox foo; echo $?
# docker: Error response from daemon: Container command 'foo' not found or does not exist.
127
```bash
$ docker run busybox foo; echo $?
docker: Error response from daemon: Container command 'foo' not found or does not exist.
127
```
**_Exit code_** of **_contained command_** otherwise
$ docker run busybox /bin/sh -c 'exit 3'; echo $?
# 3
```bash
$ docker run busybox /bin/sh -c 'exit 3'; echo $?
3
```
## Clean up (--rm)
@ -622,52 +660,74 @@ the container exits**, you can add the `--rm` flag:
--rm=false: Automatically remove the container when it exits
> **Note**: When you set the `--rm` flag, Docker also removes the anonymous volumes
associated with the container when the container is removed. This is similar
to running `docker rm -v my-container`. Only volumes that are specified without a
name are removed. For example, with
`docker run --rm -v /foo -v awesome:/bar busybox top`, the volume for `/foo` will be removed,
but the volume for `/bar` will not. Volumes inherited via `--volumes-from` will be removed
with the same logic -- if the original volume was specified with a name it will **not** be removed.
> **Note**
>
> If you set the `--rm` flag, Docker also removes the anonymous volumes
> associated with the container when the container is removed. This is similar
> to running `docker rm -v my-container`. Only volumes that are specified without
> a name are removed. For example, when running:
>
> ```bash
> docker run --rm -v /foo -v awesome:/bar busybox top
> ```
>
> the volume for `/foo` will be removed, but the volume for `/bar` will not.
> Volumes inherited via `--volumes-from` will be removed with the same logic: if
> the original volume was specified with a name it will **not** be removed.
## Security configuration
--security-opt="label=user:USER" : Set the label user for the container
--security-opt="label=role:ROLE" : Set the label role for the container
--security-opt="label=type:TYPE" : Set the label type for the container
--security-opt="label=level:LEVEL" : Set the label level for the container
--security-opt="label=disable" : Turn off label confinement for the container
--security-opt="apparmor=PROFILE" : Set the apparmor profile to be applied to the container
--security-opt="no-new-privileges:true|false" : Disable/enable container processes from gaining new privileges
--security-opt="seccomp=unconfined" : Turn off seccomp confinement for the container
--security-opt="seccomp=profile.json": White listed syscalls seccomp Json file to be used as a seccomp filter
| Option | Description |
|:------------------------------------------|:--------------------------------------------------------------------------|
| `--security-opt="label=user:USER"` | Set the label user for the container |
| `--security-opt="label=role:ROLE"` | Set the label role for the container |
| `--security-opt="label=type:TYPE"` | Set the label type for the container |
| `--security-opt="label=level:LEVEL"` | Set the label level for the container |
| `--security-opt="label=disable"` | Turn off label confinement for the container |
| `--security-opt="apparmor=PROFILE"` | Set the apparmor profile to be applied to the container |
| `--security-opt="no-new-privileges:true"` | Disable container processes from gaining new privileges |
| `--security-opt="seccomp=unconfined"` | Turn off seccomp confinement for the container |
| `--security-opt="seccomp=profile.json"` | White-listed syscalls seccomp Json file to be used as a seccomp filter |
You can override the default labeling scheme for each container by specifying
the `--security-opt` flag. Specifying the level in the following command
allows you to share the same content between containers.
$ docker run --security-opt label=level:s0:c100,c200 -it fedora bash
```bash
$ docker run --security-opt label=level:s0:c100,c200 -it fedora bash
```
> **Note**: Automatic translation of MLS labels is not currently supported.
> **Note**
>
> Automatic translation of MLS labels is not currently supported.
To disable the security labeling for this container versus running with the
`--privileged` flag, use the following command:
$ docker run --security-opt label=disable -it fedora bash
```bash
$ docker run --security-opt label=disable -it fedora bash
```
If you want a tighter security policy on the processes within a container,
you can specify an alternate type for the container. You could run a container
that is only allowed to listen on Apache ports by executing the following
command:
$ docker run --security-opt label=type:svirt_apache_t -it centos bash
```bash
$ docker run --security-opt label=type:svirt_apache_t -it centos bash
```
> **Note**: You would have to write policy defining a `svirt_apache_t` type.
> **Note**
>
> You would have to write policy defining a `svirt_apache_t` type.
If you want to prevent your container processes from gaining additional
privileges, you can execute the following command:
$ docker run --security-opt no-new-privileges -it centos bash
```bash
$ docker run --security-opt no-new-privileges -it centos bash
```
This means that commands that raise privileges such as `su` or `sudo` will no longer work.
It also causes any seccomp filters to be applied later, after privileges have been dropped
@ -774,25 +834,33 @@ We have four ways to set user memory usage:
Examples:
$ docker run -it ubuntu:14.04 /bin/bash
```bash
$ docker run -it ubuntu:14.04 /bin/bash
```
We set nothing about memory, this means the processes in the container can use
as much memory and swap memory as they need.
$ docker run -it -m 300M --memory-swap -1 ubuntu:14.04 /bin/bash
```bash
$ docker run -it -m 300M --memory-swap -1 ubuntu:14.04 /bin/bash
```
We set memory limit and disabled swap memory limit, this means the processes in
the container can use 300M memory and as much swap memory as they need (if the
host supports swap memory).
$ docker run -it -m 300M ubuntu:14.04 /bin/bash
```bash
$ docker run -it -m 300M ubuntu:14.04 /bin/bash
```
We set memory limit only, this means the processes in the container can use
300M memory and 300M swap memory, by default, the total virtual memory size
(--memory-swap) will be set as double of memory, in this case, memory + swap
would be 2*300M, so processes can use 300M swap memory as well.
$ docker run -it -m 300M --memory-swap 1G ubuntu:14.04 /bin/bash
```bash
$ docker run -it -m 300M --memory-swap 1G ubuntu:14.04 /bin/bash
```
We set both memory and swap memory, so the processes in the container can use
300M memory and 700M swap memory.
@ -844,11 +912,15 @@ memory.
The following example limits the memory to 100M and disables the OOM killer for
this container:
$ docker run -it -m 100M --oom-kill-disable ubuntu:14.04 /bin/bash
```bash
$ docker run -it -m 100M --oom-kill-disable ubuntu:14.04 /bin/bash
```
The following example, illustrates a dangerous way to use the flag:
$ docker run -it --oom-kill-disable ubuntu:14.04 /bin/bash
```bash
$ docker run -it --oom-kill-disable ubuntu:14.04 /bin/bash
```
The container has unlimited memory which can cause the host to run out memory
and require killing system processes to free memory. The `--oom-score-adj`
@ -916,12 +988,16 @@ limit and "K" the kernel limit. There are three possible ways to set limits:
Examples:
$ docker run -it -m 500M --kernel-memory 50M ubuntu:14.04 /bin/bash
```bash
$ docker run -it -m 500M --kernel-memory 50M ubuntu:14.04 /bin/bash
```
We set memory and kernel memory, so the processes in the container can use
500M memory in total, in this 500M memory, it can be 50M kernel memory tops.
$ docker run -it --kernel-memory 50M ubuntu:14.04 /bin/bash
```bash
$ docker run -it --kernel-memory 50M ubuntu:14.04 /bin/bash
```
We set kernel memory without **-m**, so the processes in the container can
use as much memory as they want, but they can only use 50M kernel memory.
@ -936,7 +1012,9 @@ between 0 and 100. A value of 0 turns off anonymous page swapping. A value of
For example, you can set:
$ docker run -it --memory-swappiness=0 ubuntu:14.04 /bin/bash
```bash
$ docker run -it --memory-swappiness=0 ubuntu:14.04 /bin/bash
```
Setting the `--memory-swappiness` option is helpful when you want to retain the
container's working set and to avoid swapping performance penalties.
@ -985,7 +1063,9 @@ And usually `--cpu-period` should work with `--cpu-quota`.
Examples:
$ docker run -it --cpu-period=50000 --cpu-quota=25000 ubuntu:14.04 /bin/bash
```bash
$ docker run -it --cpu-period=50000 --cpu-quota=25000 ubuntu:14.04 /bin/bash
```
If there is 1 CPU, this means the container can get 50% CPU worth of run-time every 50ms.
@ -1004,11 +1084,15 @@ We can set cpus in which to allow execution for containers.
Examples:
$ docker run -it --cpuset-cpus="1,3" ubuntu:14.04 /bin/bash
```bash
$ docker run -it --cpuset-cpus="1,3" ubuntu:14.04 /bin/bash
```
This means processes in container can be executed on cpu 1 and cpu 3.
$ docker run -it --cpuset-cpus="0-2" ubuntu:14.04 /bin/bash
```bash
$ docker run -it --cpuset-cpus="0-2" ubuntu:14.04 /bin/bash
```
This means processes in container can be executed on cpu 0, cpu 1 and cpu 2.
@ -1017,12 +1101,16 @@ on NUMA systems.
Examples:
$ docker run -it --cpuset-mems="1,3" ubuntu:14.04 /bin/bash
```bash
$ docker run -it --cpuset-mems="1,3" ubuntu:14.04 /bin/bash
```
This example restricts the processes in the container to only use memory from
memory nodes 1 and 3.
$ docker run -it --cpuset-mems="0-2" ubuntu:14.04 /bin/bash
```bash
$ docker run -it --cpuset-mems="0-2" ubuntu:14.04 /bin/bash
```
This example restricts the processes in the container to only use memory from
memory nodes 0, 1 and 2.
@ -1043,19 +1131,25 @@ By default, all containers get the same proportion of block IO bandwidth
container's blkio weight relative to the weighting of all other running
containers using the `--blkio-weight` flag.
> **Note:** The blkio weight setting is only available for direct IO. Buffered IO
> is not currently supported.
> **Note:**
>
> The blkio weight setting is only available for direct IO. Buffered IO is not
> currently supported.
The `--blkio-weight` flag can set the weighting to a value between 10 to 1000.
For example, the commands below create two containers with different blkio
weight:
$ docker run -it --name c1 --blkio-weight 300 ubuntu:14.04 /bin/bash
$ docker run -it --name c2 --blkio-weight 600 ubuntu:14.04 /bin/bash
```bash
$ docker run -it --name c1 --blkio-weight 300 ubuntu:14.04 /bin/bash
$ docker run -it --name c2 --blkio-weight 600 ubuntu:14.04 /bin/bash
```
If you do block IO in the two containers at the same time, by, for example:
$ time dd if=/mnt/zerofile of=test.out bs=1M count=1024 oflag=direct
```bash
$ time dd if=/mnt/zerofile of=test.out bs=1M count=1024 oflag=direct
```
You'll find that the proportion of time is the same as the proportion of blkio
weights of the two containers.
@ -1064,9 +1158,11 @@ The `--blkio-weight-device="DEVICE_NAME:WEIGHT"` flag sets a specific device wei
The `DEVICE_NAME:WEIGHT` is a string containing a colon-separated device name and weight.
For example, to set `/dev/sda` device weight to `200`:
$ docker run -it \
```bash
$ docker run -it \
--blkio-weight-device "/dev/sda:200" \
ubuntu
```
If you specify both the `--blkio-weight` and `--blkio-weight-device`, Docker
uses the `--blkio-weight` as the default weight and uses `--blkio-weight-device`
@ -1074,22 +1170,28 @@ to override this default with a new value on a specific device.
The following example uses a default weight of `300` and overrides this default
on `/dev/sda` setting that weight to `200`:
$ docker run -it \
```bash
$ docker run -it \
--blkio-weight 300 \
--blkio-weight-device "/dev/sda:200" \
ubuntu
```
The `--device-read-bps` flag limits the read rate (bytes per second) from a device.
For example, this command creates a container and limits the read rate to `1mb`
per second from `/dev/sda`:
$ docker run -it --device-read-bps /dev/sda:1mb ubuntu
```bash
$ docker run -it --device-read-bps /dev/sda:1mb ubuntu
```
The `--device-write-bps` flag limits the write rate (bytes per second) to a device.
For example, this command creates a container and limits the write rate to `1mb`
per second for `/dev/sda`:
$ docker run -it --device-write-bps /dev/sda:1mb ubuntu
```bash
$ docker run -it --device-write-bps /dev/sda:1mb ubuntu
```
Both flags take limits in the `<device-path>:<limit>[unit]` format. Both read
and write rates must be a positive integer. You can specify the rate in `kb`
@ -1099,33 +1201,44 @@ The `--device-read-iops` flag limits read rate (IO per second) from a device.
For example, this command creates a container and limits the read rate to
`1000` IO per second from `/dev/sda`:
$ docker run -ti --device-read-iops /dev/sda:1000 ubuntu
```bash
$ docker run -ti --device-read-iops /dev/sda:1000 ubuntu
```
The `--device-write-iops` flag limits write rate (IO per second) to a device.
For example, this command creates a container and limits the write rate to
`1000` IO per second to `/dev/sda`:
$ docker run -ti --device-write-iops /dev/sda:1000 ubuntu
```bash
$ docker run -ti --device-write-iops /dev/sda:1000 ubuntu
```
Both flags take limits in the `<device-path>:<limit>` format. Both read and
write rates must be a positive integer.
## Additional groups
--group-add: Add additional groups to run as
```bash
--group-add: Add additional groups to run as
```
By default, the docker container process runs with the supplementary groups looked
up for the specified user. If one wants to add more to that list of groups, then
one can use this flag:
$ docker run --rm --group-add audio --group-add nogroup --group-add 777 busybox id
uid=0(root) gid=0(root) groups=10(wheel),29(audio),99(nogroup),777
```bash
$ docker run --rm --group-add audio --group-add nogroup --group-add 777 busybox id
uid=0(root) gid=0(root) groups=10(wheel),29(audio),99(nogroup),777
```
## Runtime privilege and Linux capabilities
--cap-add: Add Linux capabilities
--cap-drop: Drop Linux capabilities
--privileged=false: Give extended privileges to this container
--device=[]: Allows you to run devices inside the container without the --privileged flag.
| Option | Description |
|:---------------|:------------------------------------------------------------------------------|
| `--cap-add` | Add Linux capabilities |
| `--cap-drop` | Drop Linux capabilities |
| `--privileged` | Give extended privileges to this container |
| `--device=[]` | Allows you to run devices inside the container without the --privileged flag. |
By default, Docker containers are "unprivileged" and cannot, for
example, run a Docker daemon inside a Docker container. This is because
@ -1144,24 +1257,28 @@ If you want to limit access to a specific device or devices you can use
the `--device` flag. It allows you to specify one or more devices that
will be accessible within the container.
$ docker run --device=/dev/snd:/dev/snd ...
```bash
$ docker run --device=/dev/snd:/dev/snd ...
```
By default, the container will be able to `read`, `write`, and `mknod` these devices.
This can be overridden using a third `:rwm` set of options to each `--device` flag:
$ docker run --device=/dev/sda:/dev/xvdc --rm -it ubuntu fdisk /dev/xvdc
```bash
$ docker run --device=/dev/sda:/dev/xvdc --rm -it ubuntu fdisk /dev/xvdc
Command (m for help): q
$ docker run --device=/dev/sda:/dev/xvdc:r --rm -it ubuntu fdisk /dev/xvdc
You will not be able to write the partition table.
Command (m for help): q
$ docker run --device=/dev/sda:/dev/xvdc:r --rm -it ubuntu fdisk /dev/xvdc
You will not be able to write the partition table.
Command (m for help): q
Command (m for help): q
$ docker run --device=/dev/sda:/dev/xvdc:w --rm -it ubuntu fdisk /dev/xvdc
$ docker run --device=/dev/sda:/dev/xvdc:w --rm -it ubuntu fdisk /dev/xvdc
crash....
$ docker run --device=/dev/sda:/dev/xvdc:m --rm -it ubuntu fdisk /dev/xvdc
fdisk: unable to open /dev/xvdc: Operation not permitted
$ docker run --device=/dev/sda:/dev/xvdc:m --rm -it ubuntu fdisk /dev/xvdc
fdisk: unable to open /dev/xvdc: Operation not permitted
```
In addition to `--privileged`, the operator can have fine grain control over the
capabilities using `--cap-add` and `--cap-drop`. By default, Docker has a default
@ -1218,37 +1335,52 @@ Further reference information is available on the [capabilities(7) - Linux man p
Both flags support the value `ALL`, so if the
operator wants to have all capabilities but `MKNOD` they could use:
$ docker run --cap-add=ALL --cap-drop=MKNOD ...
```bash
$ docker run --cap-add=ALL --cap-drop=MKNOD ...
```
For interacting with the network stack, instead of using `--privileged` they
should use `--cap-add=NET_ADMIN` to modify the network interfaces.
$ docker run -it --rm ubuntu:14.04 ip link add dummy0 type dummy
RTNETLINK answers: Operation not permitted
$ docker run -it --rm --cap-add=NET_ADMIN ubuntu:14.04 ip link add dummy0 type dummy
```bash
$ docker run -it --rm ubuntu:14.04 ip link add dummy0 type dummy
RTNETLINK answers: Operation not permitted
$ docker run -it --rm --cap-add=NET_ADMIN ubuntu:14.04 ip link add dummy0 type dummy
```
To mount a FUSE based filesystem, you need to combine both `--cap-add` and
`--device`:
$ docker run --rm -it --cap-add SYS_ADMIN sshfs sshfs sven@10.10.10.20:/home/sven /mnt
fuse: failed to open /dev/fuse: Operation not permitted
$ docker run --rm -it --device /dev/fuse sshfs sshfs sven@10.10.10.20:/home/sven /mnt
fusermount: mount failed: Operation not permitted
$ docker run --rm -it --cap-add SYS_ADMIN --device /dev/fuse sshfs
# sshfs sven@10.10.10.20:/home/sven /mnt
The authenticity of host '10.10.10.20 (10.10.10.20)' can't be established.
ECDSA key fingerprint is 25:34:85:75:25:b0:17:46:05:19:04:93:b5:dd:5f:c6.
Are you sure you want to continue connecting (yes/no)? yes
sven@10.10.10.20's password:
root@30aa0cfaf1b5:/# ls -la /mnt/src/docker
total 1516
drwxrwxr-x 1 1000 1000 4096 Dec 4 06:08 .
drwxrwxr-x 1 1000 1000 4096 Dec 4 11:46 ..
-rw-rw-r-- 1 1000 1000 16 Oct 8 00:09 .dockerignore
-rwxrwxr-x 1 1000 1000 464 Oct 8 00:09 .drone.yml
drwxrwxr-x 1 1000 1000 4096 Dec 4 06:11 .git
-rw-rw-r-- 1 1000 1000 461 Dec 4 06:08 .gitignore
....
```bash
$ docker run --rm -it --cap-add SYS_ADMIN sshfs sshfs sven@10.10.10.20:/home/sven /mnt
fuse: failed to open /dev/fuse: Operation not permitted
$ docker run --rm -it --device /dev/fuse sshfs sshfs sven@10.10.10.20:/home/sven /mnt
fusermount: mount failed: Operation not permitted
$ docker run --rm -it --cap-add SYS_ADMIN --device /dev/fuse sshfs
# sshfs sven@10.10.10.20:/home/sven /mnt
The authenticity of host '10.10.10.20 (10.10.10.20)' can't be established.
ECDSA key fingerprint is 25:34:85:75:25:b0:17:46:05:19:04:93:b5:dd:5f:c6.
Are you sure you want to continue connecting (yes/no)? yes
sven@10.10.10.20's password:
root@30aa0cfaf1b5:/# ls -la /mnt/src/docker
total 1516
drwxrwxr-x 1 1000 1000 4096 Dec 4 06:08 .
drwxrwxr-x 1 1000 1000 4096 Dec 4 11:46 ..
-rw-rw-r-- 1 1000 1000 16 Oct 8 00:09 .dockerignore
-rwxrwxr-x 1 1000 1000 464 Oct 8 00:09 .drone.yml
drwxrwxr-x 1 1000 1000 4096 Dec 4 06:11 .git
-rw-rw-r-- 1 1000 1000 461 Dec 4 06:08 .gitignore
....
```
The default seccomp profile will adjust to the selected capabilities, in order to allow
use of facilities allowed by the capabilities, so you should not have to adjust this,
@ -1304,7 +1436,9 @@ Dockerfile instruction and how the operator can override that setting.
Recall the optional `COMMAND` in the Docker
commandline:
$ docker run [OPTIONS] IMAGE[:TAG|@DIGEST] [COMMAND] [ARG...]
```bash
$ docker run [OPTIONS] IMAGE[:TAG|@DIGEST] [COMMAND] [ARG...]
```
This command is optional because the person who created the `IMAGE` may
have already provided a default `COMMAND` using the Dockerfile `CMD`
@ -1317,7 +1451,9 @@ get appended as arguments to the `ENTRYPOINT`.
### ENTRYPOINT (default command to execute at runtime)
```bash
--entrypoint="": Overwrite the default entrypoint set by the image
```
The `ENTRYPOINT` of an image is similar to a `COMMAND` because it
specifies what executable to run when the container starts, but it is
@ -1331,18 +1467,26 @@ runtime by using a string to specify the new `ENTRYPOINT`. Here is an
example of how to run a shell in a container that has been set up to
automatically run something else (like `/usr/bin/redis-server`):
$ docker run -it --entrypoint /bin/bash example/redis
```bash
$ docker run -it --entrypoint /bin/bash example/redis
```
or two examples of how to pass more parameters to that ENTRYPOINT:
$ docker run -it --entrypoint /bin/bash example/redis -c ls -l
$ docker run -it --entrypoint /usr/bin/redis-cli example/redis --help
```bash
$ docker run -it --entrypoint /bin/bash example/redis -c ls -l
$ docker run -it --entrypoint /usr/bin/redis-cli example/redis --help
```
You can reset a containers entrypoint by passing an empty string, for example:
$ docker run -it --entrypoint="" mysql bash
```bash
$ docker run -it --entrypoint="" mysql bash
```
> **Note**: Passing `--entrypoint` will clear out any default command set on the
> **Note**
>
> Passing `--entrypoint` will clear out any default command set on the
> image (i.e. any `CMD` instruction in the Dockerfile used to build it).
### EXPOSE (incoming ports)
@ -1426,6 +1570,7 @@ current value of the named variable is propagated into the container's environme
```bash
$ export today=Wednesday
$ docker run -e "deep=purple" -e today --rm alpine env
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
HOSTNAME=d2219b854598
deep=purple
@ -1483,16 +1628,17 @@ Similarly the operator can set the **HOSTNAME** (Linux) or **COMPUTERNAME** (Win
Example:
{% raw %}
$ docker run --name=test -d \
```bash
{% raw %}
$ docker run --name=test -d \
--health-cmd='stat /etc/passwd || exit 1' \
--health-interval=2s \
busybox sleep 1d
$ sleep 2; docker inspect --format='{{.State.Health.Status}}' test
healthy
$ docker exec test rm /etc/passwd
$ sleep 2; docker inspect --format='{{json .State.Health}}' test
{
$ sleep 2; docker inspect --format='{{.State.Health.Status}}' test
healthy
$ docker exec test rm /etc/passwd
$ sleep 2; docker inspect --format='{{json .State.Health}}' test
{
"Status": "unhealthy",
"FailingStreak": 3,
"Log": [
@ -1527,8 +1673,9 @@ Example:
"Output": "stat: can't stat '/etc/passwd': No such file or directory\n"
}
]
}
{% endraw %}
}
{% endraw %}
```
The health status is also displayed in the `docker ps` output.
@ -1543,7 +1690,9 @@ The health status is also displayed in the `docker ps` output.
The example below mounts an empty tmpfs into the container with the `rw`,
`noexec`, `nosuid`, and `size=65536k` options.
$ docker run -d --tmpfs /run:rw,noexec,nosuid,size=65536k my_image
```bash
$ docker run -d --tmpfs /run:rw,noexec,nosuid,size=65536k my_image
```
### VOLUME (shared filesystems)
@ -1562,7 +1711,8 @@ The example below mounts an empty tmpfs into the container with the `rw`,
--volumes-from="": Mount all volumes from the given container(s)
> **Note**:
> **Note**
>
> When using systemd to manage the Docker daemon's start and stop, in the systemd
> unit file there is an option to control mount propagation for the Docker daemon
> itself, called `MountFlags`. The value of this setting may cause Docker to not

5
docs/yaml/generate.go
View File

@ -21,7 +21,10 @@ func generateCliYaml(opts *options) error {
if err != nil {
return err
}
cmd := &cobra.Command{Use: "docker"}
cmd := &cobra.Command{
Use: "docker [OPTIONS] COMMAND [ARG...]",
Short: "The base command for the Docker CLI.",
}
commands.AddCommands(cmd, dockerCli)
disableFlagsInUseLine(cmd)
source := filepath.Join(opts.source, descriptionSourcePath)

337
experimental/vlan-networks.md
View File

@ -2,42 +2,67 @@
### Getting Started
The Ipvlan driver is currently in experimental mode in order to incubate Docker users use cases and vet the implementation to ensure a hardened, production ready driver in a future release. Libnetwork now gives users total control over both IPv4 and IPv6 addressing. The VLAN driver builds on top of that in giving operators complete control of layer 2 VLAN tagging and even Ipvlan L3 routing for users interested in underlay network integration. For overlay deployments that abstract away physical constraints see the [multi-host overlay ](https://docs.docker.com/engine/userguide/networking/get-started-overlay/) driver.
The Ipvlan driver is currently in experimental mode in order to incubate Docker
users use cases and vet the implementation to ensure a hardened, production ready
driver in a future release. Libnetwork now gives users total control over both
IPv4 and IPv6 addressing. The VLAN driver builds on top of that in giving
operators complete control of layer 2 VLAN tagging and even Ipvlan L3 routing
for users interested in underlay network integration. For overlay deployments
that abstract away physical constraints see the
[multi-host overlay](https://docs.docker.com/network/network-tutorial-overlay/)
driver.
Ipvlan is a new twist on the tried and true network virtualization technique. The Linux implementations are extremely lightweight because rather than using the traditional Linux bridge for isolation, they are simply associated to a Linux Ethernet interface or sub-interface to enforce separation between networks and connectivity to the physical network.
Ipvlan is a new twist on the tried and true network virtualization technique.
The Linux implementations are extremely lightweight because rather than using
the traditional Linux bridge for isolation, they are simply associated to a Linux
Ethernet interface or sub-interface to enforce separation between networks and
connectivity to the physical network.
Ipvlan offers a number of unique features and plenty of room for further innovations with the various modes. Two high level advantages of these approaches are, the positive performance implications of bypassing the Linux bridge and the simplicity of having fewer moving parts. Removing the bridge that traditionally resides in between the Docker host NIC and container interface leaves a simple setup consisting of container interfaces, attached directly to the Docker host interface. This result is easy access for external facing services as there is no need for port mappings in these scenarios.
Ipvlan offers a number of unique features and plenty of room for further
innovations with the various modes. Two high level advantages of these approaches
are, the positive performance implications of bypassing the Linux bridge and the
simplicity of having fewer moving parts. Removing the bridge that traditionally
resides in between the Docker host NIC and container interface leaves a simple
setup consisting of container interfaces, attached directly to the Docker host
interface. This result is easy access for external facing services as there is
no need for port mappings in these scenarios.
### Pre-Requisites
- The examples on this page are all single host and setup using Docker experimental builds that can be installed with the following instructions: [Install Docker experimental](https://github.com/docker/docker/tree/master/experimental)
- All of the examples can be performed on a single host running Docker. Any examples using a sub-interface like `eth0.10` can be replaced with `eth0` or any other valid parent interface on the Docker host. Sub-interfaces with a `.` are created on the fly. `-o parent` interfaces can also be left out of the `docker network create` all together and the driver will create a `dummy` interface that will enable local host connectivity to perform the examples.
- The examples on this page are all single host and require using Docker
experimental features to be enabled.
- All of the examples can be performed on a single host running Docker. Any
example using a sub-interface like `eth0.10` can be replaced with `eth0` or
any other valid parent interface on the Docker host. Sub-interfaces with a `.`
are created on the fly. `-o parent` interfaces can also be left out of the
`docker network create` all together and the driver will create a `dummy`
interface that will enable local host connectivity to perform the examples.
- Kernel requirements:
- To check your current kernel version, use `uname -r` to display your kernel version
- To check your current kernel version, use `uname -r`
- Ipvlan Linux kernel v4.2+ (support for earlier kernels exists but is buggy)
### Ipvlan L2 Mode Example Usage
An example of the ipvlan `L2` mode topology is shown in the following image. The driver is specified with `-d driver_name` option. In this case `-d ipvlan`.
An example of the ipvlan `L2` mode topology is shown in the following image.
The driver is specified with `-d driver_name` option. In this case `-d ipvlan`.
![Simple Ipvlan L2 Mode Example](images/ipvlan_l2_simple.png)
The parent interface in the next example `-o parent=eth0` is configured as followed:
The parent interface in the next example `-o parent=eth0` is configured as follows:
```
```bash
$ ip addr show eth0
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
inet 192.168.1.250/24 brd 192.168.1.255 scope global eth0
```
Use the network from the host's interface as the `--subnet` in the `docker network create`. The container will be attached to the same network as the host interface as set via the `-o parent=` option.
Use the network from the host's interface as the `--subnet` in the
`docker network create`. The container will be attached to the same network as
the host interface as set via the `-o parent=` option.
Create the ipvlan network and run a container attaching to it:
```
```bash
# Ipvlan (-o ipvlan_mode= Defaults to L2 mode if not specified)
$ docker network create -d ipvlan \
--subnet=192.168.1.0/24 \
@ -52,15 +77,22 @@ $ docker run --net=db_net -it --rm alpine /bin/sh
# they are intentionally filtered by Linux for additional isolation.
```
The default mode for Ipvlan is `l2`. If `-o ipvlan_mode=` are left unspecified, the default mode will be used. Similarly, if the `--gateway` is left empty, the first usable address on the network will be set as the gateway. For example, if the subnet provided in the network create is `--subnet=192.168.1.0/24` then the gateway the container receives is `192.168.1.1`.
The default mode for Ipvlan is `l2`. If `-o ipvlan_mode=` are left unspecified,
the default mode will be used. Similarly, if the `--gateway` is left empty, the
first usable address on the network will be set as the gateway. For example, if
the subnet provided in the network create is `--subnet=192.168.1.0/24` then the
gateway the container receives is `192.168.1.1`.
To help understand how this mode interacts with other hosts, the following figure shows the same layer 2 segment between two Docker hosts that applies to and Ipvlan L2 mode.
To help understand how this mode interacts with other hosts, the following
figure shows the same layer 2 segment between two Docker hosts that applies to
and Ipvlan L2 mode.
![Multiple Ipvlan Hosts](images/macvlan-bridge-ipvlan-l2.png)
The following will create the exact same network as the network `db_net` created prior, with the driver defaults for `--gateway=192.168.1.1` and `-o ipvlan_mode=l2`.
The following will create the exact same network as the network `db_net` created
prior, with the driver defaults for `--gateway=192.168.1.1` and `-o ipvlan_mode=l2`.
```
```bash
# Ipvlan (-o ipvlan_mode= Defaults to L2 mode if not specified)
$ docker network create -d ipvlan \
--subnet=192.168.1.0/24 \
@ -78,11 +110,19 @@ $ ping -c 4 ipv1
# they are intentionally filtered by Linux for additional isolation.
```
The drivers also support the `--internal` flag that will completely isolate containers on a network from any communications external to that network. Since network isolation is tightly coupled to the network's parent interface the result of leaving the `-o parent=` option off of a `docker network create` is the exact same as the `--internal` option. If the parent interface is not specified or the `--internal` flag is used, a netlink type `dummy` parent interface is created for the user and used as the parent interface effectively isolating the network completely.
The drivers also support the `--internal` flag that will completely isolate
containers on a network from any communications external to that network. Since
network isolation is tightly coupled to the network's parent interface the result
of leaving the `-o parent=` option off of a `docker network create` is the exact
same as the `--internal` option. If the parent interface is not specified or the
`--internal` flag is used, a netlink type `dummy` parent interface is created
for the user and used as the parent interface effectively isolating the network
completely.
The following two `docker network create` examples result in identical networks that you can attach container to:
The following two `docker network create` examples result in identical networks
that you can attach container to:
```
```bash
# Empty '-o parent=' creates an isolated network
$ docker network create -d ipvlan \
--subnet=192.168.10.0/24 isolated1
@ -107,27 +147,59 @@ $ docker exec -it cid3 /bin/sh
### Ipvlan 802.1q Trunk L2 Mode Example Usage
Architecturally, Ipvlan L2 mode trunking is the same as Macvlan with regard to gateways and L2 path isolation. There are nuances that can be advantageous for CAM table pressure in ToR switches, one MAC per port and MAC exhaustion on a host's parent NIC to name a few. The 802.1q trunk scenario looks the same. Both modes adhere to tagging standards and have seamless integration with the physical network for underlay integration and hardware vendor plugin integrations.
Architecturally, Ipvlan L2 mode trunking is the same as Macvlan with regard to
gateways and L2 path isolation. There are nuances that can be advantageous for
CAM table pressure in ToR switches, one MAC per port and MAC exhaustion on a
host's parent NIC to name a few. The 802.1q trunk scenario looks the same. Both
modes adhere to tagging standards and have seamless integration with the physical
network for underlay integration and hardware vendor plugin integrations.
Hosts on the same VLAN are typically on the same subnet and almost always are grouped together based on their security policy. In most scenarios, a multi-tier application is tiered into different subnets because the security profile of each process requires some form of isolation. For example, hosting your credit card processing on the same virtual network as the frontend webserver would be a regulatory compliance issue, along with circumventing the long standing best practice of layered defense in depth architectures. VLANs or the equivocal VNI (Virtual Network Identifier) when using the Overlay driver, are the first step in isolating tenant traffic.
Hosts on the same VLAN are typically on the same subnet and almost always are
grouped together based on their security policy. In most scenarios, a multi-tier
application is tiered into different subnets because the security profile of each
process requires some form of isolation. For example, hosting your credit card
processing on the same virtual network as the frontend webserver would be a
regulatory compliance issue, along with circumventing the long standing best
practice of layered defense in depth architectures. VLANs or the equivocal VNI
(Virtual Network Identifier) when using the Overlay driver, are the first step
in isolating tenant traffic.
![Docker VLANs in Depth](images/vlans-deeper-look.png)
The Linux sub-interface tagged with a vlan can either already exist or will be created when you call a `docker network create`. `docker network rm` will delete the sub-interface. Parent interfaces such as `eth0` are not deleted, only sub-interfaces with a netlink parent index > 0.
The Linux sub-interface tagged with a vlan can either already exist or will be
created when you call a `docker network create`. `docker network rm` will delete
the sub-interface. Parent interfaces such as `eth0` are not deleted, only
sub-interfaces with a netlink parent index > 0.
For the driver to add/delete the vlan sub-interfaces the format needs to be `interface_name.vlan_tag`. Other sub-interface naming can be used as the specified parent, but the link will not be deleted automatically when `docker network rm` is invoked.
For the driver to add/delete the vlan sub-interfaces the format needs to be
`interface_name.vlan_tag`. Other sub-interface naming can be used as the
specified parent, but the link will not be deleted automatically when
`docker network rm` is invoked.
The option to use either existing parent vlan sub-interfaces or let Docker manage them enables the user to either completely manage the Linux interfaces and networking or let Docker create and delete the Vlan parent sub-interfaces (netlink `ip link`) with no effort from the user.
The option to use either existing parent vlan sub-interfaces or let Docker manage
them enables the user to either completely manage the Linux interfaces and
networking or let Docker create and delete the Vlan parent sub-interfaces
(netlink `ip link`) with no effort from the user.
For example: use `eth0.10` to denote a sub-interface of `eth0` tagged with the vlan id of `10`. The equivalent `ip link` command would be `ip link add link eth0 name eth0.10 type vlan id 10`.
For example: use `eth0.10` to denote a sub-interface of `eth0` tagged with the
vlan id of `10`. The equivalent `ip link` command would be
`ip link add link eth0 name eth0.10 type vlan id 10`.
The example creates the vlan tagged networks and then start two containers to test connectivity between containers. Different Vlans cannot ping one another without a router routing between the two networks. The default namespace is not reachable per ipvlan design in order to isolate container namespaces from the underlying host.
The example creates the vlan tagged networks and then start two containers to
test connectivity between containers. Different Vlans cannot ping one another
without a router routing between the two networks. The default namespace is not
reachable per ipvlan design in order to isolate container namespaces from the
underlying host.
**Vlan ID 20**
In the first network tagged and isolated by the Docker host, `eth0.20` is the parent interface tagged with vlan id `20` specified with `-o parent=eth0.20`. Other naming formats can be used, but the links need to be added and deleted manually using `ip link` or Linux configuration files. As long as the `-o parent` exists anything can be used if compliant with Linux netlink.
In the first network tagged and isolated by the Docker host, `eth0.20` is the
parent interface tagged with vlan id `20` specified with `-o parent=eth0.20`.
Other naming formats can be used, but the links need to be added and deleted
manually using `ip link` or Linux configuration files. As long as the `-o parent`
exists anything can be used if compliant with Linux netlink.
```
```bash
# now add networks and hosts as you would normally by attaching to the master (sub)interface that is tagged
$ docker network create -d ipvlan \
--subnet=192.168.20.0/24 \
@ -141,9 +213,12 @@ $ docker run --net=ipvlan20 -it --name ivlan_test2 --rm alpine /bin/sh
**Vlan ID 30**
In the second network, tagged and isolated by the Docker host, `eth0.30` is the parent interface tagged with vlan id `30` specified with `-o parent=eth0.30`. The `ipvlan_mode=` defaults to l2 mode `ipvlan_mode=l2`. It can also be explicitly set with the same result as shown in the next example.
In the second network, tagged and isolated by the Docker host, `eth0.30` is the
parent interface tagged with vlan id `30` specified with `-o parent=eth0.30`. The
`ipvlan_mode=` defaults to l2 mode `ipvlan_mode=l2`. It can also be explicitly
set with the same result as shown in the next example.
```
```bash
# now add networks and hosts as you would normally by attaching to the master (sub)interface that is tagged.
$ docker network create -d ipvlan \
--subnet=192.168.30.0/24 \
@ -156,19 +231,25 @@ $ docker run --net=ipvlan30 -it --name ivlan_test3 --rm alpine /bin/sh
$ docker run --net=ipvlan30 -it --name ivlan_test4 --rm alpine /bin/sh
```
The gateway is set inside of the container as the default gateway. That gateway would typically be an external router on the network.
The gateway is set inside of the container as the default gateway. That gateway
would typically be an external router on the network.
```
```bash
$$ ip route
default via 192.168.30.1 dev eth0
192.168.30.0/24 dev eth0 src 192.168.30.2
```
Example: Multi-Subnet Ipvlan L2 Mode starting two containers on the same subnet and pinging one another. In order for the `192.168.114.0/24` to reach `192.168.116.0/24` it requires an external router in L2 mode. L3 mode can route between subnets that share a common `-o parent=`.
Example: Multi-Subnet Ipvlan L2 Mode starting two containers on the same subnet
and pinging one another. In order for the `192.168.114.0/24` to reach
`192.168.116.0/24` it requires an external router in L2 mode. L3 mode can route
between subnets that share a common `-o parent=`.
Secondary addresses on network routers are common as an address space becomes exhausted to add another secondary to an L3 vlan interface or commonly referred to as a "switched virtual interface" (SVI).
Secondary addresses on network routers are common as an address space becomes
exhausted to add another secondary to an L3 vlan interface or commonly referred
to as a "switched virtual interface" (SVI).
```
```bash
$ docker network create -d ipvlan \
--subnet=192.168.114.0/24 --subnet=192.168.116.0/24 \
--gateway=192.168.114.254 --gateway=192.168.116.254 \
@ -179,50 +260,87 @@ $ docker run --net=ipvlan114 --ip=192.168.114.10 -it --rm alpine /bin/sh
$ docker run --net=ipvlan114 --ip=192.168.114.11 -it --rm alpine /bin/sh
```
A key takeaway is, operators have the ability to map their physical network into their virtual network for integrating containers into their environment with no operational overhauls required. NetOps simply drops an 802.1q trunk into the Docker host. That virtual link would be the `-o parent=` passed in the network creation. For untagged (non-VLAN) links, it is as simple as `-o parent=eth0` or for 802.1q trunks with VLAN IDs each network gets mapped to the corresponding VLAN/Subnet from the network.
A key takeaway is, operators have the ability to map their physical network into
their virtual network for integrating containers into their environment with no
operational overhauls required. NetOps simply drops an 802.1q trunk into the
Docker host. That virtual link would be the `-o parent=` passed in the network
creation. For untagged (non-VLAN) links, it is as simple as `-o parent=eth0` or
for 802.1q trunks with VLAN IDs each network gets mapped to the corresponding
VLAN/Subnet from the network.
An example being, NetOps provides VLAN ID and the associated subnets for VLANs being passed on the Ethernet link to the Docker host server. Those values are simply plugged into the `docker network create` commands when provisioning the Docker networks. These are persistent configurations that are applied every time the Docker engine starts which alleviates having to manage often complex configuration files. The network interfaces can also be managed manually by being pre-created and docker networking will never modify them, simply use them as parent interfaces. Example mappings from NetOps to Docker network commands are as follows:
An example being, NetOps provides VLAN ID and the associated subnets for VLANs
being passed on the Ethernet link to the Docker host server. Those values are
simply plugged into the `docker network create` commands when provisioning the
Docker networks. These are persistent configurations that are applied every time
the Docker engine starts which alleviates having to manage often complex
configuration files. The network interfaces can also be managed manually by
being pre-created and docker networking will never modify them, simply use them
as parent interfaces. Example mappings from NetOps to Docker network commands
are as follows:
- VLAN: 10, Subnet: 172.16.80.0/24, Gateway: 172.16.80.1
- `--subnet=172.16.80.0/24 --gateway=172.16.80.1 -o parent=eth0.10`
- VLAN: 20, IP subnet: 172.16.50.0/22, Gateway: 172.16.50.1
- `--subnet=172.16.50.0/22 --gateway=172.16.50.1 -o parent=eth0.20 `
- VLAN: 30, Subnet: 10.1.100.0/16, Gateway: 10.1.100.1
- `--subnet=10.1.100.0/16 --gateway=10.1.100.1 -o parent=eth0.30`
### IPVlan L3 Mode Example
IPVlan will require routes to be distributed to each endpoint. The driver only builds the Ipvlan L3 mode port and attaches the container to the interface. Route distribution throughout a cluster is beyond the initial implementation of this single host scoped driver. In L3 mode, the Docker host is very similar to a router starting new networks in the container. They are on networks that the upstream network will not know about without route distribution. For those curious how Ipvlan L3 will fit into container networking see the following examples.
IPVlan will require routes to be distributed to each endpoint. The driver only
builds the Ipvlan L3 mode port and attaches the container to the interface. Route
distribution throughout a cluster is beyond the initial implementation of this
single host scoped driver. In L3 mode, the Docker host is very similar to a
router starting new networks in the container. They are on networks that the
upstream network will not know about without route distribution. For those
curious how Ipvlan L3 will fit into container networking see the following
examples.
![Docker Ipvlan L2 Mode](images/ipvlan-l3.png)
Ipvlan L3 mode drops all broadcast and multicast traffic. This reason alone makes Ipvlan L3 mode a prime candidate for those looking for massive scale and predictable network integrations. It is predictable and in turn will lead to greater uptimes because there is no bridging involved. Bridging loops have been responsible for high profile outages that can be hard to pinpoint depending on the size of the failure domain. This is due to the cascading nature of BPDUs (Bridge Port Data Units) that are flooded throughout a broadcast domain (VLAN) to find and block topology loops. Eliminating bridging domains, or at the least, keeping them isolated to a pair of ToRs (top of rack switches) will reduce hard to troubleshoot bridging instabilities. Ipvlan L2 modes is well suited for isolated VLANs only trunked into a pair of ToRs that can provide a loop-free non-blocking fabric. The next step further is to route at the edge via Ipvlan L3 mode that reduces a failure domain to a local host only.
Ipvlan L3 mode drops all broadcast and multicast traffic. This reason alone
makes Ipvlan L3 mode a prime candidate for those looking for massive scale and
predictable network integrations. It is predictable and in turn will lead to
greater uptimes because there is no bridging involved. Bridging loops have been
responsible for high profile outages that can be hard to pinpoint depending on
the size of the failure domain. This is due to the cascading nature of BPDUs
(Bridge Port Data Units) that are flooded throughout a broadcast domain (VLAN)
to find and block topology loops. Eliminating bridging domains, or at the least,
keeping them isolated to a pair of ToRs (top of rack switches) will reduce hard
to troubleshoot bridging instabilities. Ipvlan L2 modes is well suited for
isolated VLANs only trunked into a pair of ToRs that can provide a loop-free
non-blocking fabric. The next step further is to route at the edge via Ipvlan L3
mode that reduces a failure domain to a local host only.
- L3 mode needs to be on a separate subnet as the default namespace since it requires a netlink route in the default namespace pointing to the Ipvlan parent interface.
- L3 mode needs to be on a separate subnet as the default namespace since it
requires a netlink route in the default namespace pointing to the Ipvlan parent
interface.
- The parent interface used in this example is `eth0` and it is on the subnet
`192.168.1.0/24`. Notice the `docker network` is **not** on the same subnet
as `eth0`.
- Unlike ipvlan l2 modes, different subnets/networks can ping one another as
long as they share the same parent interface `-o parent=`.
- The parent interface used in this example is `eth0` and it is on the subnet `192.168.1.0/24`. Notice the `docker network` is **not** on the same subnet as `eth0`.
- Unlike ipvlan l2 modes, different subnets/networks can ping one another as long as they share the same parent interface `-o parent=`.
```
```bash
$$ ip a show eth0
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 00:50:56:39:45:2e brd ff:ff:ff:ff:ff:ff
inet 192.168.1.250/24 brd 192.168.1.255 scope global eth0
```
- A traditional gateway doesn't mean much to an L3 mode Ipvlan interface since there is no broadcast traffic allowed. Because of that, the container default gateway simply points to the containers `eth0` device. See below for CLI output of `ip route` or `ip -6 route` from inside an L3 container for details.
- A traditional gateway doesn't mean much to an L3 mode Ipvlan interface since
there is no broadcast traffic allowed. Because of that, the container default
gateway simply points to the containers `eth0` device. See below for CLI output
of `ip route` or `ip -6 route` from inside an L3 container for details.
The mode ` -o ipvlan_mode=l3` must be explicitly specified since the default ipvlan mode is `l2`.
The mode ` -o ipvlan_mode=l3` must be explicitly specified since the default
ipvlan mode is `l2`.
The following example does not specify a parent interface. The network drivers will create a dummy type link for the user rather than rejecting the network creation and isolating containers from only communicating with one another.
The following example does not specify a parent interface. The network drivers
will create a dummy type link for the user rather than rejecting the network
creation and isolating containers from only communicating with one another.
```
```bash
# Create the Ipvlan L3 network
$ docker network create -d ipvlan \
--subnet=192.168.214.0/24 \
@ -241,24 +359,36 @@ $ docker run --net=ipnet210 --ip=10.1.214.9 -it --rm alpine ping -c 2 192.168.21
```
Notice there is no `--gateway=` option in the network create. The field is ignored if one is specified `l3` mode. Take a look at the container routing table from inside of the container:
> **Note**
>
> Notice that there is no `--gateway=` option in the network create. The field
> is ignored if one is specified `l3` mode. Take a look at the container routing
> table from inside of the container:
>
> ```bash
> # Inside an L3 mode container
> $$ ip route
> default dev eth0
> 192.168.214.0/24 dev eth0 src 192.168.214.10
> ```
```
# Inside an L3 mode container
$$ ip route
default dev eth0
192.168.214.0/24 dev eth0 src 192.168.214.10
```
In order to ping the containers from a remote Docker host or the container be able to ping a remote host, the remote host or the physical network in between need to have a route pointing to the host IP address of the container's Docker host eth interface. More on this as we evolve the Ipvlan `L3` story.
In order to ping the containers from a remote Docker host or the container be
able to ping a remote host, the remote host or the physical network in between
need to have a route pointing to the host IP address of the container's Docker
host eth interface. More on this as we evolve the Ipvlan `L3` story.
### Dual Stack IPv4 IPv6 Ipvlan L2 Mode
- Not only does Libnetwork give you complete control over IPv4 addressing, but it also gives you total control over IPv6 addressing as well as feature parity between the two address families.
- Not only does Libnetwork give you complete control over IPv4 addressing, but
it also gives you total control over IPv6 addressing as well as feature parity
between the two address families.
- The next example will start with IPv6 only. Start two containers on the same VLAN `139` and ping one another. Since the IPv4 subnet is not specified, the default IPAM will provision a default IPv4 subnet. That subnet is isolated unless the upstream network is explicitly routing it on VLAN `139`.
- The next example will start with IPv6 only. Start two containers on the same
VLAN `139` and ping one another. Since the IPv4 subnet is not specified, the
default IPAM will provision a default IPv4 subnet. That subnet is isolated
unless the upstream network is explicitly routing it on VLAN `139`.
```
```bash
# Create a v6 network
$ docker network create -d ipvlan \
--subnet=2001:db8:abc2::/64 --gateway=2001:db8:abc2::22 \
@ -266,12 +396,11 @@ $ docker network create -d ipvlan \
# Start a container on the network
$ docker run --net=v6ipvlan139 -it --rm alpine /bin/sh
```
View the container eth0 interface and v6 routing table:
```
```bash
# Inside the IPv6 container
$$ ip a show eth0
75: eth0@if55: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default
@ -291,7 +420,7 @@ default via 2001:db8:abc2::22 dev eth0 metric 1024
Start a second container and ping the first container's v6 address.
```
```bash
# Test L2 connectivity over IPv6
$ docker run --net=v6ipvlan139 -it --rm alpine /bin/sh
@ -315,11 +444,13 @@ PING 2001:db8:abc2::1 (2001:db8:abc2::1): 56 data bytes
round-trip min/avg/max/stddev = 0.044/0.051/0.058/0.000 ms
```
The next example with setup a dual stack IPv4/IPv6 network with an example VLAN ID of `140`.
The next example with setup a dual stack IPv4/IPv6 network with an example
VLAN ID of `140`.
Next create a network with two IPv4 subnets and one IPv6 subnets, all of which have explicit gateways:
Next create a network with two IPv4 subnets and one IPv6 subnets, all of which
have explicit gateways:
```
```bash
$ docker network create -d ipvlan \
--subnet=192.168.140.0/24 --subnet=192.168.142.0/24 \
--gateway=192.168.140.1 --gateway=192.168.142.1 \
@ -330,7 +461,7 @@ $ docker network create -d ipvlan \
Start a container and view eth0 and both v4 & v6 routing tables:
```
```bash
$ docker run --net=ipvlan140 --ip6=2001:db8:abc2::51 -it --rm alpine /bin/sh
$ ip a show eth0
@ -353,23 +484,37 @@ $$ ip -6 route
default via 2001:db8:abc9::22 dev eth0 metric 1024
```
Start a second container with a specific `--ip4` address and ping the first host using IPv4 packets:
Start a second container with a specific `--ip4` address and ping the first host
using IPv4 packets:
```
```bash
$ docker run --net=ipvlan140 --ip=192.168.140.10 -it --rm alpine /bin/sh
```
**Note**: Different subnets on the same parent interface in Ipvlan `L2` mode cannot ping one another. That requires a router to proxy-arp the requests with a secondary subnet. However, Ipvlan `L3` will route the unicast traffic between disparate subnets as long as they share the same `-o parent` parent link.
> **Note**
>
> Different subnets on the same parent interface in Ipvlan `L2` mode cannot ping
> one another. That requires a router to proxy-arp the requests with a secondary
> subnet. However, Ipvlan `L3` will route the unicast traffic between disparate
> subnets as long as they share the same `-o parent` parent link.
### Dual Stack IPv4 IPv6 Ipvlan L3 Mode
**Example:** IpVlan L3 Mode Dual Stack IPv4/IPv6, Multi-Subnet w/ 802.1q Vlan Tag:118
As in all of the examples, a tagged VLAN interface does not have to be used. The sub-interfaces can be swapped with `eth0`, `eth1`, `bond0` or any other valid interface on the host other then the `lo` loopback.
As in all of the examples, a tagged VLAN interface does not have to be used. The
sub-interfaces can be swapped with `eth0`, `eth1`, `bond0` or any other valid
interface on the host other then the `lo` loopback.
The primary difference you will see is that L3 mode does not create a default route with a next-hop but rather sets a default route pointing to `dev eth` only since ARP/Broadcasts/Multicast are all filtered by Linux as per the design. Since the parent interface is essentially acting as a router, the parent interface IP and subnet needs to be different from the container networks. That is the opposite of bridge and L2 modes, which need to be on the same subnet (broadcast domain) in order to forward broadcast and multicast packets.
The primary difference you will see is that L3 mode does not create a default
route with a next-hop but rather sets a default route pointing to `dev eth` only
since ARP/Broadcasts/Multicast are all filtered by Linux as per the design. Since
the parent interface is essentially acting as a router, the parent interface IP
and subnet needs to be different from the container networks. That is the opposite
of bridge and L2 modes, which need to be on the same subnet (broadcast domain)
in order to forward broadcast and multicast packets.
```
```bash
# Create an IPv6+IPv4 Dual Stack Ipvlan L3 network
# Gateways for both v4 and v6 are set to a dev e.g. 'default dev eth0'
$ docker network create -d ipvlan \
@ -393,7 +538,7 @@ $ docker run --net=ipnet110 --ip6=2001:db8:abc6::50 --ip=192.168.112.50 -it --rm
Interface and routing table outputs are as follows:
```
```bash
$$ ip a show eth0
63: eth0@if59: <BROADCAST,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default
link/ether 00:50:56:2b:29:40 brd ff:ff:ff:ff:ff:ff
@ -415,9 +560,14 @@ $$ ip -6 route
default dev eth0 metric 1024
```
*Note:* There may be a bug when specifying `--ip6=` addresses when you delete a container with a specified v6 address and then start a new container with the same v6 address it throws the following like the address isn't properly being released to the v6 pool. It will fail to unmount the container and be left dead.
> *Note*
>
> There may be a bug when specifying `--ip6=` addresses when you delete a
> container with a specified v6 address and then start a new container with the
> same v6 address it throws the following like the address isn't properly being
> released to the v6 pool. It will fail to unmount the container and be left dead.
```
```console
docker: Error response from daemon: Address already in use.
```
@ -425,11 +575,16 @@ docker: Error response from daemon: Address already in use.
**Vlan ID 40**
If a user does not want the driver to create the vlan sub-interface it simply needs to exist prior to the `docker network create`. If you have sub-interface naming that is not `interface.vlan_id` it is honored in the `-o parent=` option again as long as the interface exists and is up.
If a user does not want the driver to create the vlan sub-interface it simply
needs to exist prior to the `docker network create`. If you have sub-interface
naming that is not `interface.vlan_id` it is honored in the `-o parent=` option
again as long as the interface exists and is up.
Links, when manually created, can be named anything as long as they exist when the network is created. Manually created links do not get deleted regardless of the name when the network is deleted with `docker network rm`.
Links, when manually created, can be named anything as long as they exist when
the network is created. Manually created links do not get deleted regardless of
the name when the network is deleted with `docker network rm`.
```
```bash
# create a new sub-interface tied to dot1q vlan 40
$ ip link add link eth0 name eth0.40 type vlan id 40
@ -449,7 +604,7 @@ $ docker run --net=ipvlan40 -it --name ivlan_test6 --rm alpine /bin/sh
**Example:** Vlan sub-interface manually created with any name:
```
```bash
# create a new sub interface tied to dot1q vlan 40
$ ip link add link eth0 name foo type vlan id 40
@ -468,8 +623,10 @@ $ docker run --net=ipvlan40 -it --name ivlan_test6 --rm alpine /bin/sh
Manually created links can be cleaned up with:
```
```bash
$ ip link del foo
```
As with all of the Libnetwork drivers, they can be mixed and matched, even as far as running 3rd party ecosystem drivers in parallel for maximum flexibility to the Docker user.
As with all of the Libnetwork drivers, they can be mixed and matched, even as
far as running 3rd party ecosystem drivers in parallel for maximum flexibility
to the Docker user.