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

engine: update reference docs with latest changes from 19.03 branch 

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This commit is contained in:
Sebastiaan van Stijn 2020-02-10 17:40:20 +01:00
parent 7e9d728df9
commit d0fb9b16ed
No known key found for this signature in database
GPG Key ID: 76698F39D527CE8C
39 changed files with 713 additions and 698 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

133
_data/engine-cli/docker_build.yaml
View File

@ -481,21 +481,27 @@ examples: "### Build with PATH\n\n```bash\n$ docker build .\n\nUploading context
example shows the use of the `.dockerignore` file to exclude the `.git`\ndirectory example shows the use of the `.dockerignore` file to exclude the `.git`\ndirectory
from the context. Its effect can be seen in the changed size of the\nuploaded context. from the context. Its effect can be seen in the changed size of the\nuploaded context.
The builder reference contains detailed information on\n[creating a .dockerignore The builder reference contains detailed information on\n[creating a .dockerignore
file](../builder.md#dockerignore-file)\n\n### Tag an image (-t)\n\n```bash\n$ docker file](../builder.md#dockerignore-file).\n\nWhen using the [BuildKit backend](../builder.md#buildkit),
build -t vieux/apache:2.0 .\n```\n\nThis will build like the previous example, but `docker build` searches\nfor a `.dockerignore` file relative to the Dockerfile name.
it will then tag the resulting\nimage. The repository name will be `vieux/apache` For example, running\n`docker build -f myapp.Dockerfile .` will first look for an
and the tag will be `2.0`.\n[Read more about valid tags](tag.md).\n\nYou can apply ignore file named\n`myapp.Dockerfile.dockerignore`. If such a file is not found,
multiple tags to an image. For example, you can apply the `latest`\ntag to a newly the `.dockerignore`\nfile is used if present. Using a Dockerfile based `.dockerignore`
built image and add another tag that references a specific\nversion.\nFor example, is useful if a\nproject contains multiple Dockerfiles that expect to ignore different
to tag an image both as `whenry/fedora-jboss:latest` and\n`whenry/fedora-jboss:v2.1`, sets of\nfiles.\n\n\n### Tag an image (-t)\n\n```bash\n$ docker build -t vieux/apache:2.0
use the following:\n\n```bash\n$ docker build -t whenry/fedora-jboss:latest -t whenry/fedora-jboss:v2.1 .\n```\n\nThis will build like the previous example, but it will then tag the resulting\nimage.
.\n```\n\n### Specify a Dockerfile (-f)\n\n```bash\n$ docker build -f Dockerfile.debug The repository name will be `vieux/apache` and the tag will be `2.0`.\n[Read more
.\n```\n\nThis will use a file called `Dockerfile.debug` for the build instructions\ninstead about valid tags](tag.md).\n\nYou can apply multiple tags to an image. For example,
of `Dockerfile`.\n\n```bash\n$ curl example.com/remote/Dockerfile | docker build you can apply the `latest`\ntag to a newly built image and add another tag that
-f - .\n```\n\nThe above command will use the current directory as the build context references a specific\nversion.\nFor example, to tag an image both as `whenry/fedora-jboss:latest`
and read\na Dockerfile from stdin.\n\n```bash\n$ docker build -f dockerfiles/Dockerfile.debug and\n`whenry/fedora-jboss:v2.1`, use the following:\n\n```bash\n$ docker build -t
-t myapp_debug .\n$ docker build -f dockerfiles/Dockerfile.prod -t myapp_prod .\n```\n\nThe whenry/fedora-jboss:latest -t whenry/fedora-jboss:v2.1 .\n```\n\n### Specify a Dockerfile
above commands will build the current build context (as specified by the\n`.`) twice, (-f)\n\n```bash\n$ docker build -f Dockerfile.debug .\n```\n\nThis will use a file
called `Dockerfile.debug` for the build instructions\ninstead of `Dockerfile`.\n\n```bash\n$
curl example.com/remote/Dockerfile | docker build -f - .\n```\n\nThe above command
will use the current directory as the build context and read\na Dockerfile from
stdin.\n\n```bash\n$ docker build -f dockerfiles/Dockerfile.debug -t myapp_debug
.\n$ docker build -f dockerfiles/Dockerfile.prod -t myapp_prod .\n```\n\nThe above
commands will build the current build context (as specified by the\n`.`) twice,
once using a debug version of a `Dockerfile` and once using a\nproduction version.\n\n```bash\n$ once using a debug version of a `Dockerfile` and once using a\nproduction version.\n\n```bash\n$
cd /home/me/myapp/some/dir/really/deep\n$ docker build -f /home/me/myapp/dockerfiles/debug cd /home/me/myapp/some/dir/really/deep\n$ docker build -f /home/me/myapp/dockerfiles/debug
/home/me/myapp\n$ docker build -f ../../../../dockerfiles/debug /home/me/myapp\n```\n\nThese /home/me/myapp\n$ docker build -f ../../../../dockerfiles/debug /home/me/myapp\n```\n\nThese
@ -554,21 +560,88 @@ examples: "### Build with PATH\n\n```bash\n$ docker build .\n\nUploading context
stage by name as a final stage for the resulting\nimage. Commands after the target stage by name as a final stage for the resulting\nimage. Commands after the target
stage will be skipped.\n\n```Dockerfile\nFROM debian AS build-env\n...\n\nFROM alpine stage will be skipped.\n\n```Dockerfile\nFROM debian AS build-env\n...\n\nFROM alpine
AS production-env\n...\n```\n\n```bash\n$ docker build -t mybuildimage --target AS production-env\n...\n```\n\n```bash\n$ docker build -t mybuildimage --target
build-env .\n```\n\n### Squash an image's layers (--squash) (experimental)\n\n#### build-env .\n```\n\n### Custom build outputs\n\nBy default, a local container image
Overview\n\nOnce the image is built, squash the new layers into a new image with is created from the build result. The\n`--output` (or `-o`) flag allows you to override
a single\nnew layer. Squashing does not destroy any existing image, rather it creates this behavior, and a specify a\ncustom exporter. For example, custom exporters allow
a new\nimage with the content of the squashed layers. This effectively makes it you to export the build\nartifacts as files on the local filesystem instead of a
look\nlike all `Dockerfile` commands were created with a single layer. The build\ncache Docker image, which can\nbe useful for generating local binaries, code generation
is preserved with this method.\n\nThe `--squash` option is an experimental feature, etc.\n\nThe value for `--output` is a CSV-formatted string defining the exporter
and should not be considered\nstable.\n\n\nSquashing layers can be beneficial if type\nand options. Currently, `local` and `tar` exporters are supported. The `local`\nexporter
your Dockerfile produces multiple layers\nmodifying the same files, for example, writes the resulting build files to a directory on the client side. The\n`tar` exporter
files that are created in one step, and\nremoved in another step. For other use-cases, is similar but writes the files as a single tarball (`.tar`).\n\nIf no type is specified,
squashing images may actually have\na negative impact on performance; when pulling the value defaults to the output directory of the local\nexporter. Use a hyphen
an image consisting of multiple\nlayers, layers can be pulled in parallel, and allows (`-`) to write the output tarball to standard output\n(`STDOUT`).\n\nThe following
sharing layers between\nimages (saving space).\n\nFor most use cases, multi-stage example builds an image using the current directory (`.`) as build\ncontext, and
builds are a better alternative, as they give more\nfine-grained control over your exports the files to a directory named `out` in the current directory.\nIf the directory
build, and can take advantage of future\noptimizations in the builder. Refer to does not exist, Docker creates the directory automatically:\n\n```bash\n$ docker
the [use multi-stage builds](https://docs.docker.com/develop/develop-images/multistage-build/)\nsection build -o out .\n```\n\nThe example above uses the short-hand syntax, omitting the
`type` options, and\nthus uses the default (`local`) exporter. The example below
shows the equivalent\nusing the long-hand CSV syntax, specifying both `type` and
`dest` (destination\npath):\n\n```bash\n$ docker build --output type=local,dest=out
.\n```\n\nUse the `tar` type to export the files as a `.tar` archive: \n\n```bash\n$
docker build --output type=tar,dest=out.tar .\n```\n\nThe example below shows the
equivalent when using the short-hand syntax. In this\ncase, `-` is specified as
destination, which automatically selects the `tar` type,\nand writes the output
tarball to standard output, which is then redirected to\nthe `out.tar` file:\n\n```bash\ndocker
build -o - . > out.tar\n```\n\nThe `--output` option exports all files from the
target stage. A common pattern\nfor exporting only specific files is to do multi-stage
builds and to copy the\ndesired files to a new scratch stage with [`COPY --from`](../builder.md#copy).\n\nThe
example `Dockerfile` below uses a separate stage to collect the\nbuild-artifacts
for exporting:\n\n```Dockerfile\nFROM golang AS build-stage\nRUN go get -u github.com/LK4D4/vndr\n\nFROM
scratch AS export-stage\nCOPY --from=build-stage /go/bin/vndr /\n```\n\nWhen building
the Dockerfile with the `-o` option, only the files from the final\nstage are exported
to the `out` directory, in this case, the `vndr` binary:\n\n```bash\n$ docker build
-o out .\n\n[+] Building 2.3s (7/7) FINISHED\n => [internal] load build definition
from Dockerfile 0.1s\n
=> => transferring dockerfile: 176B 0.0s\n
=> [internal] load .dockerignore 0.0s\n
=> => transferring context: 2B 0.0s\n
=> [internal] load metadata for docker.io/library/golang:latest 1.6s\n
=> [build-stage 1/2] FROM docker.io/library/golang@sha256:2df96417dca0561bf1027742dcc5b446a18957cd28eba6aa79269f23f1846d3f
\ 0.0s\n => => resolve docker.io/library/golang@sha256:2df96417dca0561bf1027742dcc5b446a18957cd28eba6aa79269f23f1846d3f
\ 0.0s\n => CACHED [build-stage 2/2] RUN go get -u github.com/LK4D4/vndr
\ 0.0s\n => [export-stage
1/1] COPY --from=build-stage /go/bin/vndr / 0.2s\n
=> exporting to client 0.4s\n
=> => copying files 10.30MB 0.3s\n\n$
ls ./out\nvndr\n```\n\n> **Note**: This feature requires the BuildKit backend. You
can either\n> [enable BuildKit](../builder.md#buildkit) or use the [buildx](https://github.com/docker/buildx)\n>
plugin which provides more output type options.\n\n### Specifying external cache
sources\n\nIn addition to local build cache, the builder can reuse the cache generated
from\nprevious builds with the `--cache-from` flag pointing to an image in the registry.\n\nTo
use an image as a cache source, cache metadata needs to be written into the\nimage
on creation. This can be done by setting `--build-arg BUILDKIT_INLINE_CACHE=1`\nwhen
building the image. After that, the built image can be used as a cache source\nfor
subsequent builds.\n\nUpon importing the cache, the builder will only pull the JSON
metadata from the\nregistry and determine possible cache hits based on that information.
If there\nis a cache hit, the matched layers are pulled into the local environment.\n\nIn
addition to images, the cache can also be pulled from special cache manifests\ngenerated
by [`buildx`](https://github.com/docker/buildx) or the BuildKit CLI\n(`buildctl`).
These manifests (when built with the `type=registry` and `mode=max`\noptions) allow
pulling layer data for intermediate stages in multi-stage builds.\n\nThe following
example builds an image with inline-cache metadata and pushes it\nto a registry,
then uses the image as a cache source on another machine:\n\n```bash\n$ docker build
-t myname/myapp --build-arg BUILDKIT_INLINE_CACHE=1 .\n$ docker push myname/myapp\n```\n\nAfter
pushing the image, the image is used as cache source on another machine.\nBuildKit
automatically pulls the image from the registry if needed.\n\n```bash\n# on another
machine\n$ docker build --cache-from myname/myapp .\n```\n\n> **Note**: This feature
requires the BuildKit backend. You can either\n> [enable BuildKit](../builder.md#buildkit)
or use the [buildx](https://github.com/docker/buildx)\n> plugin. The previous builder
has limited support for reusing cache from\n> pre-pulled images.\n\n### Squash an
image's layers (--squash) (experimental)\n\n#### Overview\n\nOnce the image is built,
squash the new layers into a new image with a single\nnew layer. Squashing does
not destroy any existing image, rather it creates a new\nimage with the content
of the squashed layers. This effectively makes it look\nlike all `Dockerfile` commands
were created with a single layer. The build\ncache is preserved with this method.\n\nThe
`--squash` option is an experimental feature, and should not be considered\nstable.\n\n\nSquashing
layers can be beneficial if your Dockerfile produces multiple layers\nmodifying
the same files, for example, files that are created in one step, and\nremoved in
another step. For other use-cases, squashing images may actually have\na negative
impact on performance; when pulling an image consisting of multiple\nlayers, layers
can be pulled in parallel, and allows sharing layers between\nimages (saving space).\n\nFor
most use cases, multi-stage builds are a better alternative, as they give more\nfine-grained
control over your build, and can take advantage of future\noptimizations in the
builder. Refer to the [use multi-stage builds](https://docs.docker.com/develop/develop-images/multistage-build/)\nsection
in the userguide for more information.\n\n\n#### Known limitations\n\nThe `--squash` in the userguide for more information.\n\n\n#### Known limitations\n\nThe `--squash`
option has a number of known limitations:\n\n- When squashing layers, the resulting option has a number of known limitations:\n\n- When squashing layers, the resulting
image cannot take advantage of layer\n sharing with other images, and may use significantly image cannot take advantage of layer\n sharing with other images, and may use significantly

2
_data/engine-cli/docker_container_rm.yaml
View File

@ -29,7 +29,7 @@ options:
shorthand: v shorthand: v
value_type: bool value_type: bool
default_value: "false" default_value: "false"
description: Remove the volumes associated with the container description: Remove anonymous volumes associated with the container
deprecated: false deprecated: false
experimental: false experimental: false
experimentalcli: false experimentalcli: false

224
_data/engine-cli/docker_events.yaml
View File

@ -1,176 +1,58 @@
command: docker events command: docker events
short: Get real time events from the server short: Get real time events from the server
long: |- long: "Use `docker events` to get real-time events from the server. These events differ\nper
Use `docker events` to get real-time events from the server. These events differ Docker object type. Different event types have different scopes. Local \nscoped
per Docker object type. events are only seen on the node they take place on, and swarm scoped \nevents are
seen on all managers.\n\nOnly the last 1000 log events are returned. You can use
### Object types filters to further limit \nthe number of events returned.\n\n### Object types\n\n####
Containers\n\nDocker containers report the following events:\n\n- `attach`\n- `commit`\n-
#### Containers `copy`\n- `create`\n- `destroy`\n- `detach`\n- `die`\n- `exec_create`\n- `exec_detach`\n-
`exec_die`\n- `exec_start`\n- `export`\n- `health_status`\n- `kill`\n- `oom`\n-
Docker containers report the following events: `pause`\n- `rename`\n- `resize`\n- `restart`\n- `start`\n- `stop`\n- `top`\n- `unpause`\n-
`update`\n\n#### Images\n\nDocker images report the following events:\n\n- `delete`\n-
- `attach` `import`\n- `load`\n- `pull`\n- `push`\n- `save`\n- `tag`\n- `untag`\n\n#### Plugins\n\nDocker
- `commit` plugins report the following events:\n\n- `enable`\n- `disable`\n- `install`\n-
- `copy` `remove`\n\n#### Volumes\n\nDocker volumes report the following events:\n\n- `create`\n-
- `create` `destroy`\n- `mount`\n- `unmount`\n\n#### Networks\n\nDocker networks report the
- `destroy` following events:\n\n- `create`\n- `connect`\n- `destroy`\n- `disconnect`\n- `remove`\n\n####
- `detach` Daemons\n\nDocker daemons report the following events:\n\n- `reload`\n\n#### Services\n\nDocker
- `die` services report the following events:\n\n- `create`\n- `remove`\n- `update`\n\n####
- `exec_create` Nodes\n\nDocker nodes report the following events:\n\n- `create`\n- `remove`\n-
- `exec_detach` `update`\n\n#### Secrets\n\nDocker secrets report the following events:\n\n- `create`\n-
- `exec_die` `remove`\n- `update`\n\n#### Configs\n\nDocker configs report the following events:\n\n-
- `exec_start` `create`\n- `remove`\n- `update`\n\n### Limiting, filtering, and formatting the
- `export` output\n\n#### Limit events by time\n\nThe `--since` and `--until` parameters can
- `health_status` be Unix timestamps, date formatted\ntimestamps, or Go duration strings (e.g. `10m`,
- `kill` `1h30m`) computed\nrelative to the client machine’s time. If you do not provide
- `oom` the `--since` option,\nthe command returns only new and/or live events. Supported
- `pause` formats for date\nformatted time stamps include RFC3339Nano, RFC3339, `2006-01-02T15:04:05`,\n`2006-01-02T15:04:05.999999999`,
- `rename` `2006-01-02Z07:00`, and `2006-01-02`. The local\ntimezone on the client will be
- `resize` used if you do not provide either a `Z` or a\n`+-00:00` timezone offset at the end
- `restart` of the timestamp. When providing Unix\ntimestamps enter seconds[.nanoseconds],
- `start` where seconds is the number of seconds\nthat have elapsed since January 1, 1970
- `stop` (midnight UTC/GMT), not counting leap\nseconds (aka Unix epoch or Unix time), and
- `top` the optional .nanoseconds field is a\nfraction of a second no more than nine digits
- `unpause` long.\n\nOnly the last 1000 log events are returned. You can use filters to further
- `update` limit \nthe number of events returned.\n\n#### Filtering\n\nThe filtering flag (`-f`
or `--filter`) format is of \"key=value\". If you would\nlike to use multiple filters,
#### Images pass multiple flags (e.g.,\n`--filter \"foo=bar\" --filter \"bif=baz\"`)\n\nUsing
the same filter multiple times will be handled as a *OR*; for example\n`--filter
Docker images report the following events: container=588a23dac085 --filter container=a8f7720b8c22` will display\nevents for
container 588a23dac085 *OR* container a8f7720b8c22\n\nUsing multiple filters will
- `delete` be handled as a *AND*; for example\n`--filter container=588a23dac085 --filter event=start`
- `import` will display events for\ncontainer container 588a23dac085 *AND* the event type is
- `load` *start*\n\nThe currently supported filters are:\n\n* config (`config=<name or id>`)\n*
- `pull` container (`container=<name or id>`)\n* daemon (`daemon=<name or id>`)\n* event
- `push` (`event=<event action>`)\n* image (`image=<repository or tag>`)\n* label (`label=<key>`
- `save` or `label=<key>=<value>`)\n* network (`network=<name or id>`)\n* node (`node=<id>`)\n*
- `tag` plugin (`plugin=<name or id>`)\n* scope (`scope=<local or swarm>`)\n* secret (`secret=<name
- `untag` or id>`)\n* service (`service=<name or id>`)\n* type (`type=<container or image
or volume or network or daemon or plugin or service or node or secret or config>`)\n*
#### Plugins volume (`volume=<name>`)\n\n#### Format\n\nIf a format (`--format`) is specified,
the given template will be executed\ninstead of the default\nformat. Go's [text/template](http://golang.org/pkg/text/template/)
Docker plugins report the following events: package\ndescribes all the details of the format.\n\nIf a format is set to `{{json
.}}`, the events are streamed as valid JSON\nLines. For information about JSON Lines,
- `enable` please refer to http://jsonlines.org/ ."
- `disable`
- `install`
- `remove`
#### Volumes
Docker volumes report the following events:
- `create`
- `destroy`
- `mount`
- `unmount`
#### Networks
Docker networks report the following events:
- `create`
- `connect`
- `destroy`
- `disconnect`
- `remove`
#### Daemons
Docker daemons report the following events:
- `reload`
#### Services
Docker services report the following events:
- `create`
- `remove`
- `update`
#### Nodes
Docker nodes report the following events:
- `create`
- `remove`
- `update`
#### Secrets
Docker secrets report the following events:
- `create`
- `remove`
- `update`
#### Configs
Docker configs report the following events:
- `create`
- `remove`
- `update`
### Limiting, filtering, and formatting the output
#### Limit events by time
The `--since` and `--until` parameters can be Unix timestamps, date formatted
timestamps, or Go duration strings (e.g. `10m`, `1h30m`) computed
relative to the client machine’s time. If you do not provide the `--since` option,
the command returns only new and/or live events. Supported formats for date
formatted time stamps include RFC3339Nano, RFC3339, `2006-01-02T15:04:05`,
`2006-01-02T15:04:05.999999999`, `2006-01-02Z07:00`, and `2006-01-02`. The local
timezone on the client will be used if you do not provide either a `Z` or a
`+-00:00` timezone offset at the end of the timestamp. When providing Unix
timestamps enter seconds[.nanoseconds], where seconds is the number of seconds
that have elapsed since January 1, 1970 (midnight UTC/GMT), not counting leap
seconds (aka Unix epoch or Unix time), and the optional .nanoseconds field is a
fraction of a second no more than nine digits long.
#### Filtering
The filtering flag (`-f` or `--filter`) format is of "key=value". If you would
like to use multiple filters, pass multiple flags (e.g.,
`--filter "foo=bar" --filter "bif=baz"`)
Using the same filter multiple times will be handled as a *OR*; for example
`--filter container=588a23dac085 --filter container=a8f7720b8c22` will display
events for container 588a23dac085 *OR* container a8f7720b8c22
Using multiple filters will be handled as a *AND*; for example
`--filter container=588a23dac085 --filter event=start` will display events for
container container 588a23dac085 *AND* the event type is *start*
The currently supported filters are:
* config (`config=<name or id>`)
* container (`container=<name or id>`)
* daemon (`daemon=<name or id>`)
* event (`event=<event action>`)
* image (`image=<repository or tag>`)
* label (`label=<key>` or `label=<key>=<value>`)
* network (`network=<name or id>`)
* node (`node=<id>`)
* plugin (`plugin=<name or id>`)
* scope (`scope=<local or swarm>`)
* secret (`secret=<name or id>`)
* service (`service=<name or id>`)
* type (`type=<container or image or volume or network or daemon or plugin or service or node or secret or config>`)
* volume (`volume=<name>`)
#### Format
If a format (`--format`) is specified, the given template will be executed
instead of the default
format. Go's [text/template](http://golang.org/pkg/text/template/) package
describes all the details of the format.
If a format is set to `{{json .}}`, the events are streamed as valid JSON
Lines. For information about JSON Lines, please refer to http://jsonlines.org/ .
usage: docker events [OPTIONS] usage: docker events [OPTIONS]
pname: docker pname: docker
plink: docker.yaml plink: docker.yaml

12
_data/engine-cli/docker_network_create.yaml
View File

@ -266,12 +266,12 @@ examples: |-
```bash ```bash
$ docker network create -d overlay \ $ docker network create -d overlay \
--subnet=192.168.1.0/25 \ --subnet=192.168.10.0/25 \
--subnet=192.170.2.0/25 \ --subnet=192.168.20.0/25 \
--gateway=192.168.1.100 \ --gateway=192.168.10.100 \
--gateway=192.170.2.100 \ --gateway=192.168.20.100 \
--aux-address="my-router=192.168.1.5" --aux-address="my-switch=192.168.1.6" \ --aux-address="my-router=192.168.10.5" --aux-address="my-switch=192.168.10.6" \
--aux-address="my-printer=192.170.1.5" --aux-address="my-nas=192.170.1.6" \ --aux-address="my-printer=192.168.20.5" --aux-address="my-nas=192.168.20.6" \
my-multihost-network my-multihost-network
``` ```

7
_data/engine-cli/docker_node_demote.yaml
View File

@ -1,8 +1,11 @@
command: docker node demote command: docker node demote
short: Demote one or more nodes from manager in the swarm short: Demote one or more nodes from manager in the swarm
long: |- long: |-
Demotes an existing manager so that it is no longer a manager. This command Demotes an existing manager so that it is no longer a manager.
targets a docker engine that is a manager 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.
usage: docker node demote NODE [NODE...] usage: docker node demote NODE [NODE...]
pname: docker node pname: docker node
plink: docker_node.yaml plink: docker_node.yaml

4
_data/engine-cli/docker_node_inspect.yaml
View File

@ -6,6 +6,10 @@ long: |-
given template for each result. Go's given template for each result. Go's
[text/template](http://golang.org/pkg/text/template/) package describes all the [text/template](http://golang.org/pkg/text/template/) package describes all the
details of the format. 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.
usage: docker node inspect [OPTIONS] self|NODE [NODE...] usage: docker node inspect [OPTIONS] self|NODE [NODE...]
pname: docker node pname: docker node
plink: docker_node.yaml plink: docker_node.yaml

4
_data/engine-cli/docker_node_ls.yaml
View File

@ -5,6 +5,10 @@ long: |-
Lists all the nodes that the Docker Swarm manager knows about. You can filter 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 using the `-f` or `--filter` flag. Refer to the [filtering](#filtering) section
for more information about available filter options. 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.
usage: docker node ls [OPTIONS] usage: docker node ls [OPTIONS]
pname: docker node pname: docker node
plink: docker_node.yaml plink: docker_node.yaml

7
_data/engine-cli/docker_node_promote.yaml
View File

@ -1,6 +1,11 @@
command: docker node promote command: docker node promote
short: Promote one or more nodes to manager in the swarm short: Promote one or more nodes to manager in the swarm
long: Promotes a node to manager. This command can only be executed on a manager node. long: |-
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.
usage: docker node promote NODE [NODE...] usage: docker node promote NODE [NODE...]
pname: docker node pname: docker node
plink: docker_node.yaml plink: docker_node.yaml

9
_data/engine-cli/docker_node_ps.yaml
View File

@ -1,8 +1,13 @@
command: docker node ps command: docker node ps
short: List tasks running on one or more nodes, defaults to current node short: List tasks running on one or more nodes, defaults to current node
long: Lists all the tasks on a Node that Docker knows about. You can filter using long: |-
the `-f` or `--filter` flag. Refer to the [filtering](#filtering) section for more 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. 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.
usage: docker node ps [OPTIONS] [NODE...] usage: docker node ps [OPTIONS] [NODE...]
pname: docker node pname: docker node
plink: docker_node.yaml plink: docker_node.yaml

7
_data/engine-cli/docker_node_rm.yaml
View File

@ -1,7 +1,12 @@
command: docker node rm command: docker node rm
aliases: remove aliases: remove
short: Remove one or more nodes from the swarm short: Remove one or more nodes from the swarm
long: When run from a manager node, removes the specified nodes from a swarm. long: |-
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.
usage: docker node rm [OPTIONS] NODE [NODE...] usage: docker node rm [OPTIONS] NODE [NODE...]
pname: docker node pname: docker node
plink: docker_node.yaml plink: docker_node.yaml

7
_data/engine-cli/docker_node_update.yaml
View File

@ -1,6 +1,11 @@
command: docker node update command: docker node update
short: Update a node short: Update a node
long: Update metadata about a node, such as its availability, labels, or roles. long: |-
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.
usage: docker node update [OPTIONS] NODE usage: docker node update [OPTIONS] NODE
pname: docker node pname: docker node
plink: docker_node.yaml plink: docker_node.yaml

6
_data/engine-cli/docker_pause.yaml
View File

@ -2,14 +2,14 @@ command: docker pause
short: Pause all processes within one or more containers short: Pause all processes within one or more containers
long: |- long: |-
The `docker pause` command suspends all processes in the specified containers. The `docker pause` command suspends all processes in the specified containers.
On Linux, this uses the cgroups freezer. Traditionally, when suspending a process On Linux, this uses the freezer cgroup. Traditionally, when suspending a process
the `SIGSTOP` signal is used, which is observable by the process being suspended. the `SIGSTOP` signal is used, which is observable by the process being suspended.
With the cgroups freezer the process is unaware, and unable to capture, With the freezer cgroup the process is unaware, and unable to capture,
that it is being suspended, and subsequently resumed. On Windows, only Hyper-V that it is being suspended, and subsequently resumed. On Windows, only Hyper-V
containers can be paused. containers can be paused.
See the See the
[cgroups freezer documentation](https://www.kernel.org/doc/Documentation/cgroup-v1/freezer-subsystem.txt) [freezer cgroup documentation](https://www.kernel.org/doc/Documentation/cgroup-v1/freezer-subsystem.txt)
for further details. for further details.
usage: docker pause CONTAINER [CONTAINER...] usage: docker pause CONTAINER [CONTAINER...]
pname: docker pname: docker

599
_data/engine-cli/docker_ps.yaml
View File

@ -81,389 +81,222 @@ options:
experimentalcli: false experimentalcli: false
kubernetes: false kubernetes: false
swarm: false swarm: false
examples: |- examples: "### Prevent truncating output\n\nRunning `docker ps --no-trunc` showing
### Prevent truncating output 2 linked containers.\n\n```bash\n$ docker ps\n\nCONTAINER ID IMAGE COMMAND
\ CREATED STATUS PORTS NAMES\n4c01db0b339c
Running `docker ps --no-trunc` showing 2 linked containers. \ ubuntu:12.04 bash 17 seconds ago Up
16 seconds 3300-3310/tcp webapp\nd7886598dbe2 crosbymichael/redis:latest
```bash \ /redis-server --dir 33 minutes ago Up 33 minutes 6379/tcp redis,webapp/db\n```\n\n###
$ docker ps Show both running and stopped containers\n\nThe `docker ps` command only shows running
containers by default. To see all\ncontainers, use the `-a` (or `--all`) flag:\n\n```bash\n$
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES docker ps -a\n```\n\n`docker ps` groups exposed ports into a single range if possible.
4c01db0b339c ubuntu:12.04 bash 17 seconds ago Up 16 seconds 3300-3310/tcp webapp E.g., a\ncontainer that exposes TCP ports `100, 101, 102` displays `100-102/tcp`
d7886598dbe2 crosbymichael/redis:latest /redis-server --dir 33 minutes ago Up 33 minutes 6379/tcp redis,webapp/db in\nthe `PORTS` column.\n\n### Show disk usage by container\n\nThe `docker ps -s`
``` command displays two different on-disk-sizes for each container:\n\n```bash\n$ docker
ps -s\nCONTAINER ID IMAGE COMMAND CREATED STATUS
### Show both running and stopped containers \ PORTS NAMES SIZE SIZE\ne90b8831a4b8
\ nginx \"/bin/bash -c 'mkdir \" 11 weeks ago Up 4 hours my_nginx
The `docker ps` command only shows running containers by default. To see all \ 35.58 kB (virtual 109.2 MB)\n00c6131c5e30 telegraf:1.5 \"/entrypoint.sh\"
containers, use the `-a` (or `--all`) flag: \ 11 weeks ago Up 11 weeks my_telegraf 0 B (virtual 209.5 MB)\n```\n
\ * The \"size\" information shows the amount of data (on disk) that is used for
```bash the _writable_ layer of each container\n * The \"virtual size\" is the total amount
$ docker ps -a of disk-space used for the read-only _image_ data used by the container and the
``` writable layer.\n \nFor more information, refer to the [container size on disk](https://docs.docker.com/storage/storagedriver/#container-size-on-disk)
section.\n\n\n### Filtering\n\nThe filtering flag (`-f` or `--filter`) format is
`docker ps` groups exposed ports into a single range if possible. E.g., a a `key=value` pair. If there is more\nthan one filter, then pass multiple flags
container that exposes TCP ports `100, 101, 102` displays `100-102/tcp` in (e.g. `--filter \"foo=bar\" --filter \"bif=baz\"`)\n\nThe currently supported filters
the `PORTS` column. are:\n\n| Filter | Description |\n|:----------------------|:-------------------------------------------------------------------------------------------------------------------------------------|\n|
`id` | Container's ID |\n|
### Filtering `name` | Container's name |\n|
`label` | An arbitrary string representing either a key or a key-value
The filtering flag (`-f` or `--filter`) format is a `key=value` pair. If there is more pair. Expressed as `<key>` or `<key>=<value>` |\n| `exited`
than one filter, then pass multiple flags (e.g. `--filter "foo=bar" --filter "bif=baz"`) \ | An integer representing the container's exit code. Only useful with
`--all`. |\n| `status` |
The currently supported filters are: One of `created`, `restarting`, `running`, `removing`, `paused`, `exited`, or `dead`
\ |\n| `ancestor` | Filters
| Filter | Description | containers which share a given image as an ancestor. Expressed as `<image-name>[:<tag>]`,
|:----------------------|:-------------------------------------------------------------------------------------------------------------------------------------| \ `<image id>`, or `<image@digest>` |\n| `before` or `since` | Filters containers
| `id` | Container's ID | created before or after a given container ID or name |\n|
| `name` | Container's name | `volume` | Filters running containers which have mounted a given volume
| `label` | An arbitrary string representing either a key or a key-value pair. Expressed as `<key>` or `<key>=<value>` | or bind mount. |\n| `network`
| `exited` | An integer representing the container's exit code. Only useful with `--all`. | \ | Filters running containers connected to a given network. |\n|
| `status` | One of `created`, `restarting`, `running`, `removing`, `paused`, `exited`, or `dead` | `publish` or `expose` | Filters containers which publish or expose a given port.
| `ancestor` | Filters containers which share a given image as an ancestor. Expressed as `<image-name>[:<tag>]`, `<image id>`, or `<image@digest>` | Expressed as `<port>[/<proto>]` or `<startport-endport>/[<proto>]` |\n|
| `before` or `since` | Filters containers created before or after a given container ID or name | `health` | Filters containers based on their healthcheck status. One
| `volume` | Filters running containers which have mounted a given volume or bind mount. | of `starting`, `healthy`, `unhealthy` or `none`. |\n|
| `network` | Filters running containers connected to a given network. | `isolation` | Windows daemon only. One of `default`, `process`, or `hyperv`.
| `publish` or `expose` | Filters containers which publish or expose a given port. Expressed as `<port>[/<proto>]` or `<startport-endport>/[<proto>]` | \ |\n| `is-task`
| `health` | Filters containers based on their healthcheck status. One of `starting`, `healthy`, `unhealthy` or `none`. | \ | Filters containers that are a \"task\" for a service. Boolean option
| `isolation` | Windows daemon only. One of `default`, `process`, or `hyperv`. | (`true` or `false`) |\n\n\n#### label\n\nThe
| `is-task` | Filters containers that are a "task" for a service. Boolean option (`true` or `false`) | `label` filter matches containers based on the presence of a `label` alone or a
`label` and a\nvalue.\n\nThe following filter matches containers with the `color`
label regardless of its value.\n\n```bash\n$ docker ps --filter \"label=color\"\n\nCONTAINER
#### label ID IMAGE COMMAND CREATED STATUS PORTS
\ NAMES\n673394ef1d4c busybox \"top\" 47
The `label` filter matches containers based on the presence of a `label` alone or a `label` and a seconds ago Up 45 seconds nostalgic_shockley\nd85756f57265
value. \ busybox \"top\" 52 seconds ago Up 51 seconds
\ high_albattani\n```\n\nThe following filter matches containers
The following filter matches containers with the `color` label regardless of its value. with the `color` label with the `blue` value.\n\n```bash\n$ docker ps --filter \"label=color=blue\"\n\nCONTAINER
ID IMAGE COMMAND CREATED STATUS PORTS
```bash \ NAMES\nd85756f57265 busybox \"top\" About
$ docker ps --filter "label=color" a minute ago Up About a minute high_albattani\n```\n\n####
name\n\nThe `name` filter matches on all or part of a container's name.\n\nThe following
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES filter matches all containers with a name containing the `nostalgic_stallman` string.\n\n```bash\n$
673394ef1d4c busybox "top" 47 seconds ago Up 45 seconds nostalgic_shockley docker ps --filter \"name=nostalgic_stallman\"\n\nCONTAINER ID IMAGE COMMAND
d85756f57265 busybox "top" 52 seconds ago Up 51 seconds high_albattani \ CREATED STATUS PORTS NAMES\n9b6247364a03
``` \ busybox \"top\" 2 minutes ago Up 2 minutes
\ nostalgic_stallman\n```\n\nYou can also filter for a
The following filter matches containers with the `color` label with the `blue` value. substring in a name as this shows:\n\n```bash\n$ docker ps --filter \"name=nostalgic\"\n\nCONTAINER
ID IMAGE COMMAND CREATED STATUS PORTS
```bash \ NAMES\n715ebfcee040 busybox \"top\" 3
$ docker ps --filter "label=color=blue" seconds ago Up 1 second i_am_nostalgic\n9b6247364a03
\ busybox \"top\" 7 minutes ago Up 7 minutes
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES \ nostalgic_stallman\n673394ef1d4c busybox \"top\"
d85756f57265 busybox "top" About a minute ago Up About a minute high_albattani \ 38 minutes ago Up 38 minutes nostalgic_shockley\n```\n\n####
``` exited\n\nThe `exited` filter matches containers by exist status code. For example,
to\nfilter for containers that have exited successfully:\n\n```bash\n$ docker ps
#### name -a --filter 'exited=0'\n\nCONTAINER ID IMAGE COMMAND CREATED
\ STATUS PORTS NAMES\nea09c3c82f6e
The `name` filter matches on all or part of a container's name. \ registry:latest /srv/run.sh 2 weeks ago Exited (0)
2 weeks ago 127.0.0.1:5000->5000/tcp desperate_leakey\n106ea823fe4e fedora:latest
The following filter matches all containers with a name containing the `nostalgic_stallman` string. \ /bin/sh -c 'bash -l' 2 weeks ago Exited (0) 2 weeks ago determined_albattani\n48ee228c9464
\ fedora:20 bash 2 weeks ago Exited (0)
```bash 2 weeks ago tender_torvalds\n```\n\n#### Filter by
$ docker ps --filter "name=nostalgic_stallman" exit signal\n\nYou can use a filter to locate containers that exited with status
of `137`\nmeaning a `SIGKILL(9)` killed them.\n\n```none\n$ docker ps -a --filter
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 'exited=137'\n\nCONTAINER ID IMAGE COMMAND CREATED
9b6247364a03 busybox "top" 2 minutes ago Up 2 minutes nostalgic_stallman \ STATUS PORTS NAMES\nb3e1c0ed5bfe
``` \ ubuntu:latest \"sleep 1000\" 12 seconds ago Exited
(137) 5 seconds ago grave_kowalevski\na2eb5558d669 redis:latest
You can also filter for a substring in a name as this shows: \ \"/entrypoint.sh redi 2 hours ago Exited (137) 2 hours ago sharp_lalande\n```\n\nAny
of these events result in a `137` status:\n\n* the `init` process of the container
```bash is killed manually\n* `docker kill` kills the container\n* Docker daemon restarts
$ docker ps --filter "name=nostalgic" which kills all running containers\n\n#### status\n\nThe `status` filter matches
containers by status. You can filter using\n`created`, `restarting`, `running`,
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES `removing`, `paused`, `exited` and `dead`. For example,\nto filter for `running`
715ebfcee040 busybox "top" 3 seconds ago Up 1 second i_am_nostalgic containers:\n\n```bash\n$ docker ps --filter status=running\n\nCONTAINER ID IMAGE
9b6247364a03 busybox "top" 7 minutes ago Up 7 minutes nostalgic_stallman \ COMMAND CREATED STATUS PORTS
673394ef1d4c busybox "top" 38 minutes ago Up 38 minutes nostalgic_shockley \ NAMES\n715ebfcee040 busybox \"top\" 16
``` minutes ago Up 16 minutes i_am_nostalgic\nd5c976d3c462
\ busybox \"top\" 23 minutes ago Up 23 minutes
#### exited \ top\n9b6247364a03 busybox \"top\"
\ 24 minutes ago Up 24 minutes nostalgic_stallman\n```\n\nTo
The `exited` filter matches containers by exist status code. For example, to filter for `paused` containers:\n\n```bash\n$ docker ps --filter status=paused\n\nCONTAINER
filter for containers that have exited successfully: ID IMAGE COMMAND CREATED STATUS PORTS
\ NAMES\n673394ef1d4c busybox \"top\" About
```bash an hour ago Up About an hour (Paused) nostalgic_shockley\n```\n\n####
$ docker ps -a --filter 'exited=0' ancestor\n\nThe `ancestor` filter matches containers based on its image or a descendant
of\nit. The filter supports the following image representation:\n\n- `image`\n-
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES `image:tag`\n- `image:tag@digest`\n- `short-id`\n- `full-id`\n\nIf you don't specify
ea09c3c82f6e registry:latest /srv/run.sh 2 weeks ago Exited (0) 2 weeks ago 127.0.0.1:5000->5000/tcp desperate_leakey a `tag`, the `latest` tag is used. For example, to filter\nfor containers that use
106ea823fe4e fedora:latest /bin/sh -c 'bash -l' 2 weeks ago Exited (0) 2 weeks ago determined_albattani the latest `ubuntu` image:\n\n```bash\n$ docker ps --filter ancestor=ubuntu\n\nCONTAINER
48ee228c9464 fedora:20 bash 2 weeks ago Exited (0) 2 weeks ago tender_torvalds ID IMAGE COMMAND CREATED STATUS PORTS
``` \ NAMES\n919e1179bdb8 ubuntu-c1 \"top\" About
a minute ago Up About a minute admiring_lovelace\n5d1e4a540723
#### Filter by exit signal \ ubuntu-c2 \"top\" About a minute ago Up About
a minute admiring_sammet\n82a598284012 ubuntu \"top\"
You can use a filter to locate containers that exited with status of `137` \ 3 minutes ago Up 3 minutes sleepy_bose\nbab2a34ba363
meaning a `SIGKILL(9)` killed them. \ ubuntu \"top\" 3 minutes ago Up 3 minutes
\ focused_yonath\n```\n\nMatch containers based on the
```none `ubuntu-c1` image which, in this case, is a child\nof `ubuntu`:\n\n```bash\n$ docker
$ docker ps -a --filter 'exited=137' ps --filter ancestor=ubuntu-c1\n\nCONTAINER ID IMAGE COMMAND
\ CREATED STATUS PORTS NAMES\n919e1179bdb8
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES \ ubuntu-c1 \"top\" About a minute ago Up About
b3e1c0ed5bfe ubuntu:latest "sleep 1000" 12 seconds ago Exited (137) 5 seconds ago grave_kowalevski a minute admiring_lovelace\n```\n\nMatch containers based
a2eb5558d669 redis:latest "/entrypoint.sh redi 2 hours ago Exited (137) 2 hours ago sharp_lalande on the `ubuntu` version `12.04.5` image:\n\n```bash\n$ docker ps --filter ancestor=ubuntu:12.04.5\n\nCONTAINER
``` ID IMAGE COMMAND CREATED STATUS PORTS
\ NAMES\n82a598284012 ubuntu:12.04.5 \"top\" 3
Any of these events result in a `137` status: minutes ago Up 3 minutes sleepy_bose\n```\n\nThe
following matches containers based on the layer `d0e008c6cf02` or an image\nthat
* the `init` process of the container is killed manually have this layer in its layer stack.\n\n```bash\n$ docker ps --filter ancestor=d0e008c6cf02\n\nCONTAINER
* `docker kill` kills the container ID IMAGE COMMAND CREATED STATUS PORTS
* Docker daemon restarts which kills all running containers \ NAMES\n82a598284012 ubuntu:12.04.5 \"top\" 3
minutes ago Up 3 minutes sleepy_bose\n```\n\n####
#### status Create time\n\n##### before\n\nThe `before` filter shows only containers created
before the container with\ngiven id or name. For example, having these containers
The `status` filter matches containers by status. You can filter using created:\n\n```bash\n$ docker ps\n\nCONTAINER ID IMAGE COMMAND CREATED
`created`, `restarting`, `running`, `removing`, `paused`, `exited` and `dead`. For example, \ STATUS PORTS NAMES\n9c3527ed70ce busybox
to filter for `running` containers: \ \"top\" 14 seconds ago Up 15 seconds desperate_dubinsky\n4aace5031105
\ busybox \"top\" 48 seconds ago Up 49 seconds focused_hamilton\n6e63f6ff38b0
```bash \ busybox \"top\" About a minute ago Up About a minute distracted_fermat\n```\n\nFiltering
$ docker ps --filter status=running with `before` would give:\n\n```bash\n$ docker ps -f before=9c3527ed70ce\n\nCONTAINER
ID IMAGE COMMAND CREATED STATUS PORTS
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES \ NAMES\n4aace5031105 busybox \"top\" About a minute
715ebfcee040 busybox "top" 16 minutes ago Up 16 minutes i_am_nostalgic ago Up About a minute focused_hamilton\n6e63f6ff38b0 busybox
d5c976d3c462 busybox "top" 23 minutes ago Up 23 minutes top \ \"top\" About a minute ago Up About a minute distracted_fermat\n```\n\n#####
9b6247364a03 busybox "top" 24 minutes ago Up 24 minutes nostalgic_stallman since\n\nThe `since` filter shows only containers created since the container with
``` given\nid or name. For example, with the same containers as in `before` filter:\n\n```bash\n$
docker ps -f since=6e63f6ff38b0\n\nCONTAINER ID IMAGE COMMAND CREATED
To filter for `paused` containers: \ STATUS PORTS NAMES\n9c3527ed70ce busybox
\ \"top\" 10 minutes ago Up 10 minutes desperate_dubinsky\n4aace5031105
```bash \ busybox \"top\" 10 minutes ago Up 10 minutes focused_hamilton\n```\n\n####
$ docker ps --filter status=paused volume\n\nThe `volume` filter shows only containers that mount a specific volume
or have\na volume mounted in a specific path:\n\n```bash\n$ docker ps --filter volume=remote-volume
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES --format \"table {{.ID}}\\t{{.Mounts}}\"\nCONTAINER ID MOUNTS\n9c3527ed70ce
673394ef1d4c busybox "top" About an hour ago Up About an hour (Paused) nostalgic_shockley \ remote-volume\n\n$ docker ps --filter volume=/data --format \"table {{.ID}}\\t{{.Mounts}}\"\nCONTAINER
``` ID MOUNTS\n9c3527ed70ce remote-volume\n```\n\n#### network\n\nThe
`network` filter shows only containers that are connected to a network with\na given
#### ancestor name or id.\n\nThe following filter matches all containers that are connected to
a network\nwith a name containing `net1`.\n\n```bash\n$ docker run -d --net=net1
The `ancestor` filter matches containers based on its image or a descendant of --name=test1 ubuntu top\n$ docker run -d --net=net2 --name=test2 ubuntu top\n\n$
it. The filter supports the following image representation: docker ps --filter network=net1\n\nCONTAINER ID IMAGE COMMAND CREATED
\ STATUS PORTS NAMES\n9d4893ed80fe ubuntu
- `image` \ \"top\" 10 minutes ago Up 10 minutes test1\n```\n\nThe
- `image:tag` network filter matches on both the network's name and id. The following\nexample
- `image:tag@digest` shows all containers that are attached to the `net1` network, using\nthe network
- `short-id` id as a filter;\n\n```bash\n$ docker network inspect --format \"{{.ID}}\" net1\n\n8c0b4110ae930dbe26b258de9bc34a03f98056ed6f27f991d32919bfe401d7c5\n\n$
- `full-id` docker ps --filter network=8c0b4110ae930dbe26b258de9bc34a03f98056ed6f27f991d32919bfe401d7c5\n\nCONTAINER
ID IMAGE COMMAND CREATED STATUS PORTS
If you don't specify a `tag`, the `latest` tag is used. For example, to filter \ NAMES\n9d4893ed80fe ubuntu \"top\" 10 minutes
for containers that use the latest `ubuntu` image: ago Up 10 minutes test1\n```\n\n#### publish and
expose\n\nThe `publish` and `expose` filters show only containers that have published
```bash or exposed port with a given port\nnumber, port range, and/or protocol. The default
$ docker ps --filter ancestor=ubuntu protocol is `tcp` when not specified.\n\nThe following filter matches all containers
that have published port of 80:\n\n```bash\n$ docker run -d --publish=80 busybox
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES top\n$ docker run -d --expose=8080 busybox top\n\n$ docker ps -a\n\nCONTAINER ID
919e1179bdb8 ubuntu-c1 "top" About a minute ago Up About a minute admiring_lovelace \ IMAGE COMMAND CREATED STATUS PORTS
5d1e4a540723 ubuntu-c2 "top" About a minute ago Up About a minute admiring_sammet \ NAMES\n9833437217a5 busybox \"top\" 5
82a598284012 ubuntu "top" 3 minutes ago Up 3 minutes sleepy_bose seconds ago Up 4 seconds 8080/tcp dreamy_mccarthy\nfc7e477723b7
bab2a34ba363 ubuntu "top" 3 minutes ago Up 3 minutes focused_yonath \ busybox \"top\" 50 seconds ago Up 50 seconds
``` \ 0.0.0.0:32768->80/tcp admiring_roentgen\n\n$ docker ps --filter publish=80\n\nCONTAINER
ID IMAGE COMMAND CREATED STATUS PORTS
Match containers based on the `ubuntu-c1` image which, in this case, is a child \ NAMES\nfc7e477723b7 busybox \"top\" About
of `ubuntu`: a minute ago Up About a minute 0.0.0.0:32768->80/tcp admiring_roentgen\n```\n\nThe
following filter matches all containers that have exposed TCP port in the range
```bash of `8000-8080`:\n```bash\n$ docker ps --filter expose=8000-8080/tcp\n\nCONTAINER
$ docker ps --filter ancestor=ubuntu-c1 ID IMAGE COMMAND CREATED STATUS PORTS
\ NAMES\n9833437217a5 busybox \"top\" 21
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES seconds ago Up 19 seconds 8080/tcp dreamy_mccarthy\n```\n\nThe
919e1179bdb8 ubuntu-c1 "top" About a minute ago Up About a minute admiring_lovelace following filter matches all containers that have exposed UDP port `80`:\n```bash\n$
``` docker ps --filter publish=80/udp\n\nCONTAINER ID IMAGE COMMAND
\ CREATED STATUS PORTS NAMES\n```\n\n###
Match containers based on the `ubuntu` version `12.04.5` image: Formatting\n\nThe formatting option (`--format`) pretty-prints container output
using a Go\ntemplate.\n\nValid placeholders for the Go template are listed below:\n\n|
```bash Placeholder | Description |\n|:--------------|:------------------------------------------------------------------------------------------------|\n|
$ docker ps --filter ancestor=ubuntu:12.04.5 `.ID` | Container ID |\n|
`.Image` | Image ID |\n|
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES `.Command` | Quoted command |\n|
82a598284012 ubuntu:12.04.5 "top" 3 minutes ago Up 3 minutes sleepy_bose `.CreatedAt` | Time when the container was created. |\n|
``` `.RunningFor` | Elapsed time since the container was started. |\n|
`.Ports` | Exposed ports. |\n|
The following matches containers based on the layer `d0e008c6cf02` or an image `.Status` | Container status. |\n|
that have this layer in its layer stack. `.Size` | Container disk size. |\n|
`.Names` | Container names. |\n|
```bash `.Labels` | All labels assigned to the container. |\n|
$ docker ps --filter ancestor=d0e008c6cf02 `.Label` | Value of a specific label for this container. For example `'{{.Label
\"com.docker.swarm.cpu\"}}'` |\n| `.Mounts` | Names of the volumes mounted in
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES this container. |\n| `.Networks`
82a598284012 ubuntu:12.04.5 "top" 3 minutes ago Up 3 minutes sleepy_bose \ | Names of the networks attached to this container. |\n\nWhen
``` using the `--format` option, the `ps` command will either output the data\nexactly
as the template declares or, when using the `table` directive, includes\ncolumn
#### Create time headers as well.\n\nThe following example uses a template without headers and outputs
the `ID` and\n`Command` entries separated by a colon for all running containers:\n\n```bash\n$
##### before docker ps --format \"{{.ID}}: {{.Command}}\"\n\na87ecb4f327c: /bin/sh -c #(nop)
MA\n01946d9d34d8: /bin/sh -c #(nop) MA\nc1d3b0166030: /bin/sh -c yum -y up\n41d50ecd2f57:
The `before` filter shows only containers created before the container with /bin/sh -c #(nop) MA\n```\n\nTo list all running containers with their labels in
given id or name. For example, having these containers created: a table format you can use:\n\n```bash\n$ docker ps --format \"table {{.ID}}\\t{{.Labels}}\"\n\nCONTAINER
ID LABELS\na87ecb4f327c com.docker.swarm.node=ubuntu,com.docker.swarm.storage=ssd\n01946d9d34d8\nc1d3b0166030
```bash \ com.docker.swarm.node=debian,com.docker.swarm.cpu=6\n41d50ecd2f57 com.docker.swarm.node=fedora,com.docker.swarm.cpu=3,com.docker.swarm.storage=ssd\n```"
$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
9c3527ed70ce busybox "top" 14 seconds ago Up 15 seconds desperate_dubinsky
4aace5031105 busybox "top" 48 seconds ago Up 49 seconds focused_hamilton
6e63f6ff38b0 busybox "top" About a minute ago Up About a minute distracted_fermat
```
Filtering with `before` would give:
```bash
$ docker ps -f before=9c3527ed70ce
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
4aace5031105 busybox "top" About a minute ago Up About a minute focused_hamilton
6e63f6ff38b0 busybox "top" About a minute ago Up About a minute distracted_fermat
```
##### since
The `since` filter shows only containers created since the container with given
id or name. For example, with the same containers as in `before` filter:
```bash
$ docker ps -f since=6e63f6ff38b0
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
9c3527ed70ce busybox "top" 10 minutes ago Up 10 minutes desperate_dubinsky
4aace5031105 busybox "top" 10 minutes ago Up 10 minutes focused_hamilton
```
#### volume
The `volume` filter shows only containers that mount a specific volume or have
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
```
#### network
The `network` filter shows only containers that are connected to a network with
a given name or id.
The following filter matches all containers that are connected to a network
with a name containing `net1`.
```bash
$ docker run -d --net=net1 --name=test1 ubuntu top
$ docker run -d --net=net2 --name=test2 ubuntu top
$ docker ps --filter network=net1
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
9d4893ed80fe ubuntu "top" 10 minutes ago Up 10 minutes test1
```
The network filter matches on both the network's name and id. The following
example shows all containers that are attached to the `net1` network, using
the network id as a filter;
```bash
$ docker network inspect --format "{{.ID}}" net1
8c0b4110ae930dbe26b258de9bc34a03f98056ed6f27f991d32919bfe401d7c5
$ docker ps --filter network=8c0b4110ae930dbe26b258de9bc34a03f98056ed6f27f991d32919bfe401d7c5
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
9d4893ed80fe ubuntu "top" 10 minutes ago Up 10 minutes test1
```
#### publish and expose
The `publish` and `expose` filters show only containers that have published or exposed port with a given port
number, port range, and/or protocol. The default protocol is `tcp` when not specified.
The following filter matches all containers that have published port of 80:
```bash
$ docker run -d --publish=80 busybox top
$ docker run -d --expose=8080 busybox top
$ docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
9833437217a5 busybox "top" 5 seconds ago Up 4 seconds 8080/tcp dreamy_mccarthy
fc7e477723b7 busybox "top" 50 seconds ago Up 50 seconds 0.0.0.0:32768->80/tcp admiring_roentgen
$ docker ps --filter publish=80
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
fc7e477723b7 busybox "top" About a minute ago Up About a minute 0.0.0.0:32768->80/tcp admiring_roentgen
```
The following filter matches all containers that have exposed TCP port in the range of `8000-8080`:
```bash
$ docker ps --filter expose=8000-8080/tcp
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
9833437217a5 busybox "top" 21 seconds ago Up 19 seconds 8080/tcp dreamy_mccarthy
```
The following filter matches all containers that have exposed UDP port `80`:
```bash
$ docker ps --filter publish=80/udp
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
```
### Formatting
The formatting option (`--format`) pretty-prints container output using a Go
template.
Valid placeholders for the Go template are listed below:
| Placeholder | Description |
|:--------------|:------------------------------------------------------------------------------------------------|
| `.ID` | Container ID |
| `.Image` | Image ID |
| `.Command` | Quoted command |
| `.CreatedAt` | Time when the container was created. |
| `.RunningFor` | Elapsed time since the container was started. |
| `.Ports` | Exposed ports. |
| `.Status` | Container status. |
| `.Size` | Container disk size. |
| `.Names` | Container names. |
| `.Labels` | All labels assigned to the container. |
| `.Label` | Value of a specific label for this container. For example `'{{.Label "com.docker.swarm.cpu"}}'` |
| `.Mounts` | Names of the volumes mounted in this container. |
| `.Networks` | Names of the networks attached to this container. |
When using the `--format` option, the `ps` command will either 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
`Command` entries separated by a colon for all running containers:
```bash
$ docker ps --format "{{.ID}}: {{.Command}}"
a87ecb4f327c: /bin/sh -c #(nop) MA
01946d9d34d8: /bin/sh -c #(nop) MA
c1d3b0166030: /bin/sh -c yum -y up
41d50ecd2f57: /bin/sh -c #(nop) MA
```
To list all running containers with their labels in a table format you can use:
```bash
$ docker ps --format "table {{.ID}}\t{{.Labels}}"
CONTAINER ID LABELS
a87ecb4f327c com.docker.swarm.node=ubuntu,com.docker.swarm.storage=ssd
01946d9d34d8
c1d3b0166030 com.docker.swarm.node=debian,com.docker.swarm.cpu=6
41d50ecd2f57 com.docker.swarm.node=fedora,com.docker.swarm.cpu=3,com.docker.swarm.storage=ssd
```
deprecated: false deprecated: false
experimental: false experimental: false
experimentalcli: false experimentalcli: false

2
_data/engine-cli/docker_rm.yaml
View File

@ -29,7 +29,7 @@ options:
shorthand: v shorthand: v
value_type: bool value_type: bool
default_value: "false" default_value: "false"
description: Remove the volumes associated with the container description: Remove anonymous volumes associated with the container
deprecated: false deprecated: false
experimental: false experimental: false
experimentalcli: false experimentalcli: false

8
_data/engine-cli/docker_run.yaml
View File

@ -1090,6 +1090,11 @@ examples: |-
The [Docker User Guide](https://docs.docker.com/engine/userguide/networking/default_network/dockerlinks/) The [Docker User Guide](https://docs.docker.com/engine/userguide/networking/default_network/dockerlinks/)
explains in detail how to manipulate ports in Docker. 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
`-p 127.0.0.1:80:80`) will be accessible from the outside. This also applies if
you configured UFW to block this specific port, as Docker manages his
own iptables rules. [Read more](https://docs.docker.com/network/iptables/)
```bash ```bash
$ docker run --expose 80 ubuntu bash $ docker run --expose 80 ubuntu bash
``` ```
@ -1422,7 +1427,7 @@ examples: |-
flags for IPv4 address retrieval for a network device named `eth0`: flags for IPv4 address retrieval for a network device named `eth0`:
```bash ```bash
$ HOSTIP=`ip -4 addr show scope global dev eth0 | grep inet | awk '{print \$2}' | cut -d / -f 1` $ HOSTIP=`ip -4 addr show scope global dev eth0 | grep inet | awk '{print $2}' | cut -d / -f 1 | sed -n 1p`
$ docker run --add-host=docker:${HOSTIP} --rm -it debian $ docker run --add-host=docker:${HOSTIP} --rm -it debian
``` ```
@ -1607,3 +1612,4 @@ experimental: false
experimentalcli: false experimentalcli: false
kubernetes: false kubernetes: false
swarm: false swarm: false

12
_data/engine-cli/docker_search.yaml
View File

@ -94,8 +94,8 @@ examples: "### Search images by name\n\nThis example displays images with a name
\ 0 [OK]\nmarclop/busybox-solr\n```\n\n### \ 0 [OK]\nmarclop/busybox-solr\n```\n\n###
Display non-truncated description (--no-trunc)\n\nThis example displays images with Display non-truncated description (--no-trunc)\n\nThis example displays images with
a name containing 'busybox',\nat least 3 stars and the description isn't truncated a name containing 'busybox',\nat least 3 stars and the description isn't truncated
in the output:\n\n```bash\n$ docker search --stars=3 --no-trunc busybox\nNAME DESCRIPTION in the output:\n\n```bash\n$ docker search --filter=stars=3 --no-trunc busybox\nNAME
\ STARS \ DESCRIPTION STARS
\ OFFICIAL AUTOMATED\nbusybox Busybox base image. 325 \ OFFICIAL AUTOMATED\nbusybox Busybox base image. 325
\ [OK] \nprogrium/busybox 50 \ [OK] \nprogrium/busybox 50
\ [OK]\nradial/busyboxplus Full-chain, Internet enabled, busybox \ [OK]\nradial/busyboxplus Full-chain, Internet enabled, busybox
@ -104,7 +104,7 @@ examples: "### Search images by name\n\nThis example displays images with a name
returned by a search. This value could\nbe in the range between 1 and 100. The default returned by a search. This value could\nbe in the range between 1 and 100. The default
value of `--limit` is 25.\n\n### Filtering\n\nThe filtering flag (`-f` or `--filter`) value of `--limit` is 25.\n\n### Filtering\n\nThe filtering flag (`-f` or `--filter`)
format is a `key=value` pair. If there is more\nthan one filter, then pass multiple format is a `key=value` pair. If there is more\nthan one filter, then pass multiple
flags (e.g. `--filter \"foo=bar\" --filter \"bif=baz\"`)\n\nThe currently supported flags (e.g. `--filter is-automated=true --filter stars=3`)\n\nThe currently supported
filters are:\n\n* stars (int - number of stars the image has)\n* is-automated (boolean filters are:\n\n* stars (int - number of stars the image has)\n* is-automated (boolean
- true or false) - is the image automated or not\n* is-official (boolean - true - true or false) - is the image automated or not\n* is-official (boolean - true
or false) - is the image official or not\n\n#### stars\n\nThis example displays or false) - is the image official or not\n\n#### stars\n\nThis example displays
@ -115,13 +115,13 @@ examples: "### Search images by name\n\nThis example displays images with a name
\ [OK]\nradial/busyboxplus Full-chain, Internet enabled, busybox \ [OK]\nradial/busyboxplus Full-chain, Internet enabled, busybox
made... 8 [OK]\n```\n\n#### is-automated\n\nThis example displays made... 8 [OK]\n```\n\n#### is-automated\n\nThis example displays
images with a name containing 'busybox'\nand are automated builds:\n\n```bash\n$ images with a name containing 'busybox'\nand are automated builds:\n\n```bash\n$
docker search --filter is-automated busybox\n\nNAME DESCRIPTION docker search --filter is-automated=true busybox\n\nNAME DESCRIPTION
\ STARS OFFICIAL AUTOMATED\nprogrium/busybox \ STARS OFFICIAL AUTOMATED\nprogrium/busybox
\ 50 [OK]\nradial/busyboxplus \ 50 [OK]\nradial/busyboxplus
\ Full-chain, Internet enabled, busybox made... 8 [OK]\n```\n\n#### \ Full-chain, Internet enabled, busybox made... 8 [OK]\n```\n\n####
is-official\n\nThis example displays images with a name containing 'busybox', at is-official\n\nThis example displays images with a name containing 'busybox', at
least\n3 stars and are official builds:\n\n```bash\n$ docker search --filter \"is-official=true\" least\n3 stars and are official builds:\n\n```bash\n$ docker search --filter is-official=true
--filter \"stars=3\" busybox\n\nNAME DESCRIPTION STARS --filter stars=3 busybox\n\nNAME DESCRIPTION STARS
\ OFFICIAL AUTOMATED\nprogrium/busybox 50 \ OFFICIAL AUTOMATED\nprogrium/busybox 50
\ [OK]\nradial/busyboxplus Full-chain, Internet enabled, busybox \ [OK]\nradial/busyboxplus Full-chain, Internet enabled, busybox
made... 8 [OK]\n```\n\n### Format the output\n\nThe formatting made... 8 [OK]\n```\n\n### Format the output\n\nThe formatting

6
_data/engine-cli/docker_secret_create.yaml
View File

@ -1,9 +1,13 @@
command: docker secret create command: docker secret create
short: Create a secret from a file or STDIN as content short: Create a secret from a file or STDIN as content
long: |- long: |-
Creates a secret using standard input or from a file for the secret content. You must run this command on a manager node. 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/). 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.
usage: docker secret create [OPTIONS] SECRET [file|-] usage: docker secret create [OPTIONS] SECRET [file|-]
pname: docker secret pname: docker secret
plink: docker_secret.yaml plink: docker_secret.yaml

7
_data/engine-cli/docker_secret_inspect.yaml
View File

@ -1,8 +1,7 @@
command: docker secret inspect command: docker secret inspect
short: Display detailed information on one or more secrets short: Display detailed information on one or more secrets
long: |- long: |-
Inspects the specified secret. This command has to be run targeting a manager Inspects the specified secret.
node.
By default, this renders all results in a JSON array. If a format is specified, By default, this renders all results in a JSON array. If a format is specified,
the given template will be executed for each result. the given template will be executed for each result.
@ -11,6 +10,10 @@ long: |-
describes all the details of the format. 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/). 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.
usage: docker secret inspect [OPTIONS] SECRET [SECRET...] usage: docker secret inspect [OPTIONS] SECRET [SECRET...]
pname: docker secret pname: docker secret
plink: docker_secret.yaml plink: docker_secret.yaml

4
_data/engine-cli/docker_secret_ls.yaml
View File

@ -5,6 +5,10 @@ long: |-
Run this command on a manager node to list the secrets in the swarm. 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/). 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.
usage: docker secret ls [OPTIONS] usage: docker secret ls [OPTIONS]
pname: docker secret pname: docker secret
plink: docker_secret.yaml plink: docker_secret.yaml

7
_data/engine-cli/docker_secret_rm.yaml
View File

@ -2,10 +2,13 @@ command: docker secret rm
aliases: remove aliases: remove
short: Remove one or more secrets short: Remove one or more secrets
long: |- long: |-
Removes the specified secrets from the swarm. This command has to be run Removes the specified secrets from the swarm.
targeting a manager node.
For detailed information about using secrets, refer to [manage sensitive data with Docker secrets](https://docs.docker.com/engine/swarm/secrets/). 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.
usage: docker secret rm SECRET [SECRET...] usage: docker secret rm SECRET [SECRET...]
pname: docker secret pname: docker secret
plink: docker_secret.yaml plink: docker_secret.yaml

7
_data/engine-cli/docker_service.yaml
View File

@ -1,6 +1,11 @@
command: docker service command: docker service
short: Manage services short: Manage services
long: Manage services. long: |-
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.
usage: docker service usage: docker service
pname: docker pname: docker
plink: docker.yaml plink: docker.yaml

184
_data/engine-cli/docker_service_create.yaml
View File

@ -1,8 +1,11 @@
command: docker service create command: docker service create
short: Create a new service short: Create a new service
long: |- long: |-
Creates a service as described by the specified parameters. You must run this Creates a service as described by the specified parameters.
command 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.
usage: docker service create [OPTIONS] IMAGE [COMMAND] [ARG...] usage: docker service create [OPTIONS] IMAGE [COMMAND] [ARG...]
pname: docker service pname: docker service
plink: docker_service.yaml plink: docker_service.yaml
@ -646,13 +649,27 @@ examples: "### Create a service\n\n```bash\n$ docker service create --name redis
docker service create --name redis \\\n --secret source=ssh-key,target=ssh \\\n docker service create --name redis \\\n --secret source=ssh-key,target=ssh \\\n
\ --secret source=app-key,target=app,uid=1000,gid=1001,mode=0400 \\\n redis:3.0.6\n\n4cdgfyky7ozwh3htjfw0d12qv\n```\n\nTo \ --secret source=app-key,target=app,uid=1000,gid=1001,mode=0400 \\\n redis:3.0.6\n\n4cdgfyky7ozwh3htjfw0d12qv\n```\n\nTo
grant a service access to multiple secrets, use multiple `--secret` flags.\n\nSecrets grant a service access to multiple secrets, use multiple `--secret` flags.\n\nSecrets
are located in `/run/secrets` in the container. If no target is\nspecified, the are located in `/run/secrets` in the container if no target is specified.\nIf no
name of the secret will be used as the in memory file in the\ncontainer. If a target target is specified, the name of the secret is used as the in memory file\nin the
is specified, that will be the filename. In the\nexample above, two files will container. If a target is specified, that is used as the filename. In the\nexample
be created: `/run/secrets/ssh` and\n`/run/secrets/app` for each of the secret targets above, two files are created: `/run/secrets/ssh` and\n`/run/secrets/app` for each
specified.\n\n### Create a service with a rolling update policy\n\n```bash\n$ docker of the secret targets specified.\n\n### Create a service with configs\n\nUse the
service create \\\n --replicas 10 \\\n --name redis \\\n --update-delay 10s \\\n `--config` flag to give a container access to a\n[config](config_create.md).\n\nCreate
\ --update-parallelism 2 \\\n redis:3.0.6\n```\n\nWhen you run a [service update](service_update.md), a service with a config. The config will be mounted into `redis-config`,\nbe owned
by the user who runs the command inside the container (often `root`),\nand have
file mode `0444` or world-readable. You can specify the `uid` and `gid`\nas numerical
IDs or names. When using names, the provided group/user names must\npre-exist in
the container. The `mode` is specified as a 4-number sequence such\nas `0755`.\n\n```bash\n$
docker service create --name=redis --config redis-conf redis:3.0.6\n```\n\nCreate
a service with a config and specify the target location and file mode:\n\n```bash\n$
docker service create --name redis \\\n --config source=redis-conf,target=/etc/redis/redis.conf,mode=0400
redis:3.0.6\n```\n\nTo grant a service access to multiple configs, use multiple
`--config` flags.\n\nConfigs are located in `/` in the container if no target is
specified. If no\ntarget is specified, the name of the config is used as the name
of the file in\nthe container. If a target is specified, that is used as the filename.\n\n###
Create a service with a rolling update policy\n\n```bash\n$ docker service create
\\\n --replicas 10 \\\n --name redis \\\n --update-delay 10s \\\n --update-parallelism
2 \\\n redis:3.0.6\n```\n\nWhen you run a [service update](service_update.md),
the scheduler updates a\nmaximum of 2 tasks at a time, with `10s` between updates. the scheduler updates a\nmaximum of 2 tasks at a time, with `10s` between updates.
For more information,\nrefer to the [rolling updates\ntutorial](https://docs.docker.com/engine/swarm/swarm-tutorial/rolling-update/).\n\n### For more information,\nrefer to the [rolling updates\ntutorial](https://docs.docker.com/engine/swarm/swarm-tutorial/rolling-update/).\n\n###
Set environment variables (-e, --env)\n\nThis sets an environment variable for all Set environment variables (-e, --env)\n\nThis sets an environment variable for all
@ -753,15 +770,15 @@ examples: "### Create a service\n\n```bash\n$ docker service create --name redis
Enables recursive bind-mount.</li>\n </ul>\n </td>\n </tr>\n</table>\n\n##### Enables recursive bind-mount.</li>\n </ul>\n </td>\n </tr>\n</table>\n\n#####
Bind propagation\n\nBind propagation refers to whether or not mounts created within Bind propagation\n\nBind propagation refers to whether or not mounts created within
a given\nbind mount or named volume can be propagated to replicas of that mount. a given\nbind mount or named volume can be propagated to replicas of that mount.
Consider\na mount point `/mnt`, which is also mounted on `/tmp`. The propation settings\ncontrol Consider\na mount point `/mnt`, which is also mounted on `/tmp`. The propagation
whether a mount on `/tmp/a` would also be available on `/mnt/a`. Each\npropagation settings\ncontrol whether a mount on `/tmp/a` would also be available on `/mnt/a`.
setting has a recursive counterpoint. In the case of recursion,\nconsider that `/tmp/a` Each\npropagation setting has a recursive counterpoint. In the case of recursion,\nconsider
is also mounted as `/foo`. The propagation settings\ncontrol whether `/mnt/a` and/or that `/tmp/a` is also mounted as `/foo`. The propagation settings\ncontrol whether
`/tmp/a` would exist.\n\nThe `bind-propagation` option defaults to `rprivate` for `/mnt/a` and/or `/tmp/a` would exist.\n\nThe `bind-propagation` option defaults
both bind mounts and\nvolume mounts, and is only configurable for bind mounts. In to `rprivate` for both bind mounts and\nvolume mounts, and is only configurable
other words, named\nvolumes do not support bind propagation.\n\n- **`shared`**: for bind mounts. In other words, named\nvolumes do not support bind propagation.\n\n-
Sub-mounts of the original mount are exposed to replica mounts,\n and **`shared`**: Sub-mounts of the original mount are exposed to replica mounts,\n
sub-mounts of replica mounts are also propagated to the\n original \ and sub-mounts of replica mounts are also propagated to the\n original
mount.\n- **`slave`**: similar to a shared mount, but only in one direction. If mount.\n- **`slave`**: similar to a shared mount, but only in one direction. If
the\n original mount exposes a sub-mount, the replica mount can see the\n original mount exposes a sub-mount, the replica mount can see
it.\n However, if the replica mount exposes a sub-mount, the original\n it.\n However, if the replica mount exposes a sub-mount, the original\n
@ -848,27 +865,42 @@ examples: "### Create a service\n\n```bash\n$ docker service create --name redis
in the swarm.\n\nThe following command creates a global service:\n\n```bash\n$ docker in the swarm.\n\nThe following command creates a global service:\n\n```bash\n$ docker
service create \\\n --name redis_2 \\\n --mode global \\\n redis:3.0.6\n```\n\n### service create \\\n --name redis_2 \\\n --mode global \\\n redis:3.0.6\n```\n\n###
Specify service constraints (--constraint)\n\nYou can limit the set of nodes where Specify service constraints (--constraint)\n\nYou can limit the set of nodes where
a task can be scheduled by defining\nconstraint expressions. Multiple constraints a task can be scheduled by defining\nconstraint expressions. Constraint expressions
can either use a _match_ (`==`)\nor _exclude_ (`!=`) rule. Multiple constraints
find nodes that satisfy every\nexpression (AND match). Constraints can match node find nodes that satisfy every\nexpression (AND match). Constraints can match node
or Docker Engine labels as\nfollows:\n\n\n<table>\n <tr>\n <th>node attribute</th>\n or Docker Engine labels as\nfollows:\n\nnode attribute | matches |
\ <th>matches</th>\n <th>example</th>\n </tr>\n <tr>\n <td><tt>node.id</tt></td>\n example\n---------------------|--------------------------------|-----------------------------------------------\n`node.id`
\ <td>Node ID</td>\n <td><tt>node.id==2ivku8v2gvtg4</tt></td>\n </tr>\n <tr>\n \ | Node ID | `node.id==2ivku8v2gvtg4`\n`node.hostname`
\ <td><tt>node.hostname</tt></td>\n <td>Node hostname</td>\n <td><tt>node.hostname!=node-2</tt></td>\n \ | Node hostname | `node.hostname!=node-2`\n`node.role` |
\ </tr>\n <tr>\n <td><tt>node.role</tt></td>\n <td>Node role</td>\n <td><tt>node.role==manager</tt></td>\n Node role (`manager`/`worker`) | `node.role==manager`\n`node.platform.os` | Node
\ </tr>\n <tr>\n <td><tt>node.labels</tt></td>\n <td>user defined node labels</td>\n operating system | `node.platform.os==windows`\n`node.platform.arch` |
\ <td><tt>node.labels.security==high</tt></td>\n </tr>\n <tr>\n <td><tt>engine.labels</tt></td>\n Node architecture | `node.platform.arch==x86_64`\n`node.labels` |
\ <td>Docker Engine's labels</td>\n <td><tt>engine.labels.operatingsystem==ubuntu User-defined node labels | `node.labels.security==high`\n`engine.labels` |
14.04</tt></td>\n </tr>\n</table>\n\n\n`engine.labels` apply to Docker Engine labels Docker Engine's labels | `engine.labels.operatingsystem==ubuntu-14.04`\n\n\n`engine.labels`
like operating system,\ndrivers, etc. Swarm administrators add `node.labels` for apply to Docker Engine labels like operating system, drivers,\netc. Swarm administrators
operational purposes by\nusing the [`docker node update`](node_update.md) command.\n\nFor add `node.labels` for operational purposes by using\nthe [`docker node update`](node_update.md)
example, the following limits tasks for the redis service to nodes where the\nnode command.\n\nFor example, the following limits tasks for the redis service to nodes
type label equals queue:\n\n```bash\n$ docker service create \\\n --name redis_2 where the\nnode type label equals queue:\n\n```bash\n$ docker service create \\\n
\\\n --constraint 'node.labels.type == queue' \\\n redis:3.0.6\n```\n\n### Specify \ --name redis_2 \\\n --constraint node.platform.os==linux \\\n --constraint node.labels.type==queue
service placement preferences (--placement-pref)\n\nYou can set up the service to \\\n redis:3.0.6\n```\n\nIf the service constraints exclude all nodes in the cluster,
divide tasks evenly over different categories of\nnodes. One example of where this a message is printed\nthat no suitable node is found, but the scheduler will start
can be useful is to balance tasks over a set\nof datacenters or availability zones. a reconciliation\nloop and deploy the service once a suitable node becomes available.\n\nIn
the example below, no node satisfying the constraint was found, causing the\nservice
to not reconcile with the desired state:\n\n```bash\n$ docker service create \\\n
\ --name web \\\n --constraint node.labels.region==east \\\n nginx:alpine\n\nlx1wrhhpmbbu0wuk0ybws30bc\noverall
progress: 0 out of 1 tasks\n1/1: no suitable node (scheduling constraints not satisfied
on 5 nodes)\n\n$ docker service ls\nID NAME MODE REPLICAS
\ IMAGE PORTS\nb6lww17hrr4e web replicated 0/1 nginx:alpine\n```\n\nAfter
adding the `region=east` label to a node in the cluster, the service\nreconciles,
and the desired number of replicas are deployed:\n\n```bash\n$ docker node update
--label-add region=east yswe2dm4c5fdgtsrli1e8ya5l \nyswe2dm4c5fdgtsrli1e8ya5l\n\n$
docker service ls\nID NAME MODE REPLICAS IMAGE PORTS\nb6lww17hrr4e
\ web replicated 1/1 nginx:alpine\n```\n\n### Specify service
placement preferences (--placement-pref)\n\nYou can set up the service to divide
tasks evenly over different categories of\nnodes. One example of where this can
be useful is to balance tasks over a set\nof datacenters or availability zones.
The example below illustrates this:\n\n```bash\n$ docker service create \\\n --replicas The example below illustrates this:\n\n```bash\n$ docker service create \\\n --replicas
9 \\\n --name redis_2 \\\n --placement-pref 'spread=node.labels.datacenter' \\\n 9 \\\n --name redis_2 \\\n --placement-pref spread=node.labels.datacenter \\\n
\ redis:3.0.6\n```\n\nThis uses `--placement-pref` with a `spread` strategy (currently \ redis:3.0.6\n```\n\nThis uses `--placement-pref` with a `spread` strategy (currently
the only\nsupported strategy) to spread tasks evenly over the values of the `datacenter`\nnode the only\nsupported strategy) to spread tasks evenly over the values of the `datacenter`\nnode
label. In this example, we assume that every node has a `datacenter` node\nlabel label. In this example, we assume that every node has a `datacenter` node\nlabel
@ -904,24 +936,66 @@ examples: "### Create a service\n\n```bash\n$ docker service create --name redis
\ --placement-pref 'spread=node.labels.rack' \\\n redis:3.0.6\n```\n\nWhen updating \ --placement-pref 'spread=node.labels.rack' \\\n redis:3.0.6\n```\n\nWhen updating
a service with `docker service update`, `--placement-pref-add`\nappends a new placement a service with `docker service update`, `--placement-pref-add`\nappends a new placement
preference after all existing placement preferences.\n`--placement-pref-rm` removes preference after all existing placement preferences.\n`--placement-pref-rm` removes
an existing placement preference that matches the\nargument.\n\n### Specify maximum an existing placement preference that matches the\nargument.\n\n### Specify memory
replicas per node (--replicas-max-per-node)\n\nUse the `--replicas-max-per-node` requirements and constraints for a service (--reserve-memory and --limit-memory)\n\nIf
flag to set the maximum number of replica tasks that can run on a node.\nThe following your service needs a minimum amount of memory in order to run correctly,\nyou can
command creates a nginx service with 2 replica tasks but only one replica task per use `--reserve-memory` to specify that the service should only be\nscheduled on
node.\n\nOne example where this can be useful is to balance tasks over a set of a node with this much memory available to reserve. If no node is\navailable that
data centers together with `--placement-pref`\nand let `--replicas-max-per-node` meets the criteria, the task is not scheduled, but remains in a\npending state.\n\nThe
setting make sure that replicas are not migrated to another datacenter during\nmaintenance following example requires that 4GB of memory be available and reservable\non a
or datacenter failure.\n\nThe example below illustrates this:\n\n```bash\n$ docker given node before scheduling the service to run on that node.\n\n```bash\n$ docker
service create \\\n --name nginx \\\n --replicas 2 \\\n --replicas-max-per-node service create --reserve-memory=4GB --name=too-big nginx:alpine\n```\n\nThe managers
1 \\\n --placement-pref 'spread=node.labels.datacenter' \\\n nginx\n```\n\n### won't schedule a set of containers on a single node whose combined\nreservations
Attach a service to an existing network (--network)\n\nYou can use overlay networks exceed the memory available on that node.\n\nAfter a task is scheduled and running,
to connect one or more services within the swarm.\n\nFirst, create an overlay network `--reserve-memory` does not enforce a\nmemory limit. Use `--limit-memory` to ensure
on a manager node the docker network create\ncommand:\n\n```bash\n$ docker network that a task uses no more than a\ngiven amount of memory on a node. This example
create --driver overlay my-network\n\netjpu59cykrptrgw0z0hk5snf\n```\n\nAfter you limits the amount of memory used\nby the task to 4GB. The task will be scheduled
create an overlay network in swarm mode, all manager nodes have\naccess to the network.\n\nWhen even if each of your nodes has\nonly 2GB of memory, because `--limit-memory` is
you create a service and pass the `--network` flag to attach the service to\nthe an upper limit.\n\n```bash\n$ docker service create --limit-memory=4GB --name=too-big
overlay network:\n\n```bash\n$ docker service create \\\n --replicas 3 \\\n --network nginx:alpine\n```\n\nUsing `--reserve-memory` and `--limit-memory` does not guarantee
my-network \\\n --name my-web \\\n nginx\n\n716thylsndqma81j6kkkb5aus\n```\n\nThe that Docker\nwill not use more memory on your host than you want. For instance,
you could\ncreate many services, the sum of whose memory usage could exhaust the
available\nmemory.\n\nYou can prevent this scenario from exhausting the available
memory by taking\ninto account other (non-containerized) software running on the
host as well. If\n`--reserve-memory` is greater than or equal to `--limit-memory`,
Docker won't\nschedule a service on a host that doesn't have enough memory. `--limit-memory`\nwill
limit the service's memory to stay within that limit, so if every service\nhas a
memory-reservation and limit set, Docker services will be less likely to\nsaturate
the host. Other non-service containers or applications running directly\non the
Docker host could still exhaust memory.\n\nThere is a downside to this approach.
Reserving memory also means that you may\nnot make optimum use of the memory available
on the node. Consider a service\nthat under normal circumstances uses 100MB of memory,
but depending on load can\n\"peak\" at 500MB. Reserving 500MB for that service (to
guarantee can have 500MB\nfor those \"peaks\") results in 400MB of memory being
wasted most of the time.\n\nIn short, you can take a more conservative or more flexible
approach:\n\n- **Conservative**: reserve 500MB, and limit to 500MB. Basically you're
now\n treating the service containers as VMs, and you may be losing a big advantage\n
\ containers, which is greater density of services per host.\n\n- **Flexible**:
limit to 500MB in the assumption that if the service requires\n more than 500MB,
it is malfunctioning. Reserve something between the 100MB\n \"normal\" requirement
and the 500MB \"peak\" requirement\". This assumes that when\n this service is
at \"peak\", other services or non-container workloads probably\n won't be.\n\nThe
approach you take depends heavily on the memory-usage patterns of your\nworkloads.
You should test under normal and peak conditions before settling\non an approach.\n\nOn
Linux, you can also limit a service's overall memory footprint on a given\nhost
at the level of the host operating system, using `cgroups` or other\nrelevant operating
system tools.\n\n### Specify maximum replicas per node (--replicas-max-per-node)\n\nUse
the `--replicas-max-per-node` flag to set the maximum number of replica tasks that
can run on a node.\nThe following command creates a nginx service with 2 replica
tasks but only one replica task per node.\n\nOne example where this can be useful
is to balance tasks over a set of data centers together with `--placement-pref`\nand
let `--replicas-max-per-node` setting make sure that replicas are not migrated to
another datacenter during\nmaintenance or datacenter failure.\n\nThe example below
illustrates this:\n\n```bash\n$ docker service create \\\n --name nginx \\\n --replicas
2 \\\n --replicas-max-per-node 1 \\\n --placement-pref 'spread=node.labels.datacenter'
\\\n nginx\n```\n\n### Attach a service to an existing network (--network)\n\nYou
can use overlay networks to connect one or more services within the swarm.\n\nFirst,
create an overlay network on a manager node the docker network create\ncommand:\n\n```bash\n$
docker network create --driver overlay my-network\n\netjpu59cykrptrgw0z0hk5snf\n```\n\nAfter
you create an overlay network in swarm mode, all manager nodes have\naccess to the
network.\n\nWhen you create a service and pass the `--network` flag to attach the
service to\nthe overlay network:\n\n```bash\n$ docker service create \\\n --replicas
3 \\\n --network my-network \\\n --name my-web \\\n nginx\n\n716thylsndqma81j6kkkb5aus\n```\n\nThe
swarm extends my-network to each node running the service.\n\nContainers on the swarm extends my-network to each node running the service.\n\nContainers on the
same network can access each other using\n[service discovery](https://docs.docker.com/engine/swarm/networking/#use-swarm-mode-service-discovery).\n\nLong same network can access each other using\n[service discovery](https://docs.docker.com/engine/swarm/networking/#use-swarm-mode-service-discovery).\n\nLong
form syntax of `--network` allows to specify list of aliases and driver options: form syntax of `--network` allows to specify list of aliases and driver options:

7
_data/engine-cli/docker_service_inspect.yaml
View File

@ -1,14 +1,17 @@
command: docker service inspect command: docker service inspect
short: Display detailed information on one or more services short: Display detailed information on one or more services
long: |- long: |-
Inspects the specified service. This command has to be run targeting a manager Inspects the specified service.
node.
By default, this renders all results in a JSON array. If a format is specified, By default, this renders all results in a JSON array. If a format is specified,
the given template will be executed for each result. the given template will be executed for each result.
Go's [text/template](http://golang.org/pkg/text/template/) package Go's [text/template](http://golang.org/pkg/text/template/) package
describes all the details of the format. 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.
usage: docker service inspect [OPTIONS] SERVICE [SERVICE...] usage: docker service inspect [OPTIONS] SERVICE [SERVICE...]
pname: docker service pname: docker service
plink: docker_service.yaml plink: docker_service.yaml

4
_data/engine-cli/docker_service_logs.yaml
View File

@ -3,6 +3,10 @@ short: Fetch the logs of a service or task
long: |- long: |-
The `docker service logs` command batch-retrieves logs present at the time of execution. 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.
The `docker service logs` command can be used with either the name or ID of a 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 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 for all of the containers in that service. If a task is passed, it will only

7
_data/engine-cli/docker_service_ls.yaml
View File

@ -2,8 +2,11 @@ command: docker service ls
aliases: list aliases: list
short: List services short: List services
long: |- long: |-
This command when run targeting a manager, lists services are running in the This command lists services are running in the swarm.
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.
usage: docker service ls [OPTIONS] usage: docker service ls [OPTIONS]
pname: docker service pname: docker service
plink: docker_service.yaml plink: docker_service.yaml

7
_data/engine-cli/docker_service_ps.yaml
View File

@ -1,8 +1,11 @@
command: docker service ps command: docker service ps
short: List the tasks of one or more services short: List the tasks of one or more services
long: |- long: |-
Lists the tasks that are running as part of the specified services. This command Lists the tasks that are running as part of the specified services.
has to be run targeting 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.
usage: docker service ps [OPTIONS] SERVICE [SERVICE...] usage: docker service ps [OPTIONS] SERVICE [SERVICE...]
pname: docker service pname: docker service
plink: docker_service.yaml plink: docker_service.yaml

7
_data/engine-cli/docker_service_rm.yaml
View File

@ -2,8 +2,11 @@ command: docker service rm
aliases: remove aliases: remove
short: Remove one or more services short: Remove one or more services
long: |- long: |-
Removes the specified services from the swarm. This command has to be run Removes the specified services from the swarm.
targeting 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.
usage: docker service rm SERVICE [SERVICE...] usage: docker service rm SERVICE [SERVICE...]
pname: docker service pname: docker service
plink: docker_service.yaml plink: docker_service.yaml

7
_data/engine-cli/docker_service_rollback.yaml
View File

@ -1,8 +1,11 @@
command: docker service rollback command: docker service rollback
short: Revert changes to a service's configuration short: Revert changes to a service's configuration
long: |- long: |-
Roll back a specified service to its previous version from the swarm. This command must be run Roll back a specified service to its previous version from the swarm.
targeting 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.
usage: docker service rollback [OPTIONS] SERVICE usage: docker service rollback [OPTIONS] SERVICE
pname: docker service pname: docker service
plink: docker_service.yaml plink: docker_service.yaml

4
_data/engine-cli/docker_service_scale.yaml
View File

@ -6,6 +6,10 @@ long: |-
services which are global mode. The command will return immediately, but the 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 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. 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.
usage: docker service scale SERVICE=REPLICAS [SERVICE=REPLICAS...] usage: docker service scale SERVICE=REPLICAS [SERVICE=REPLICAS...]
pname: docker service pname: docker service
plink: docker_service.yaml plink: docker_service.yaml

10
_data/engine-cli/docker_service_update.yaml
View File

@ -1,15 +1,19 @@
command: docker service update command: docker service update
short: Update a service short: Update a service
long: |- long: |-
Updates a service as described by the specified parameters. This command has to be run targeting a manager node. Updates a service as described by the specified parameters. The parameters are
The parameters are the same as [`docker service create`](service_create.md). Please look at the description there the same as [`docker service create`](service_create.md). Refer to the description
for further information. there for further information.
Normally, updating a service will only cause the service's tasks to be replaced with new ones if a change to the Normally, updating a service will only cause the service's tasks to be replaced with new ones if a change to the
service requires recreating the tasks for it to take effect. For example, only changing the service requires recreating the tasks for it to take effect. For example, only changing the
`--update-parallelism` setting will not recreate the tasks, because the individual tasks are not affected by this `--update-parallelism` setting will not recreate the tasks, because the individual tasks are not affected by this
setting. However, the `--force` flag will cause the tasks to be recreated anyway. This can be used to perform a 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. 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.
usage: docker service update [OPTIONS] SERVICE usage: docker service update [OPTIONS] SERVICE
pname: docker service pname: docker service
plink: docker_service.yaml plink: docker_service.yaml

44
_data/engine-cli/docker_stack_deploy.yaml
View File

@ -2,12 +2,24 @@ command: docker stack deploy
aliases: up aliases: up
short: Deploy a new stack or update an existing stack short: Deploy a new stack or update an existing stack
long: |- long: |-
Create and update a stack from a `compose` file on the swarm. This command has to Create and update a stack from a `compose` file on the swarm.
be run targeting a manager node.
> **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.
usage: docker stack deploy [OPTIONS] STACK usage: docker stack deploy [OPTIONS] STACK
pname: docker stack pname: docker stack
plink: docker_stack.yaml plink: docker_stack.yaml
options: options:
- option: bundle-file
value_type: string
description: Path to a Distributed Application Bundle file
deprecated: false
experimental: true
experimentalcli: false
kubernetes: false
swarm: true
- option: compose-file - option: compose-file
shorthand: c shorthand: c
value_type: stringSlice value_type: stringSlice
@ -143,6 +155,34 @@ examples: |-
9gc5m4met4he vossibility_logstash replicated 1/1 logstash@sha256:2dc8bddd1bb4a5a34e8ebaf73749f6413c101b2edef6617f2f7713926d2141fe 9gc5m4met4he vossibility_logstash replicated 1/1 logstash@sha256:2dc8bddd1bb4a5a34e8ebaf73749f6413c101b2edef6617f2f7713926d2141fe
axqh55ipl40h vossibility_vossibility-collector replicated 1/1 icecrime/vossibility-collector@sha256:f03f2977203ba6253988c18d04061c5ec7aab46bca9dfd89a9a1fa4500989fba axqh55ipl40h vossibility_vossibility-collector replicated 1/1 icecrime/vossibility-collector@sha256:f03f2977203ba6253988c18d04061c5ec7aab46bca9dfd89a9a1fa4500989fba
``` ```
### DAB file
```bash
$ docker stack deploy --bundle-file vossibility-stack.dab vossibility
Loading bundle from vossibility-stack.dab
Creating service vossibility_elasticsearch
Creating service vossibility_kibana
Creating service vossibility_logstash
Creating service vossibility_lookupd
Creating service vossibility_nsqd
Creating service vossibility_vossibility-collector
```
You can verify that the services were correctly created:
```bash
$ docker service ls
ID NAME MODE REPLICAS IMAGE
29bv0vnlm903 vossibility_lookupd replicated 1/1 nsqio/nsq@sha256:eeba05599f31eba418e96e71e0984c3dc96963ceb66924dd37a47bf7ce18a662
4awt47624qwh vossibility_nsqd replicated 1/1 nsqio/nsq@sha256:eeba05599f31eba418e96e71e0984c3dc96963ceb66924dd37a47bf7ce18a662
4tjx9biia6fs vossibility_elasticsearch replicated 1/1 elasticsearch@sha256:12ac7c6af55d001f71800b83ba91a04f716e58d82e748fa6e5a7359eed2301aa
7563uuzr9eys vossibility_kibana replicated 1/1 kibana@sha256:6995a2d25709a62694a937b8a529ff36da92ebee74bafd7bf00e6caf6db2eb03
9gc5m4met4he vossibility_logstash replicated 1/1 logstash@sha256:2dc8bddd1bb4a5a34e8ebaf73749f6413c101b2edef6617f2f7713926d2141fe
axqh55ipl40h vossibility_vossibility-collector replicated 1/1 icecrime/vossibility-collector@sha256:f03f2977203ba6253988c18d04061c5ec7aab46bca9dfd89a9a1fa4500989fba
```
deprecated: false deprecated: false
min_api_version: "1.25" min_api_version: "1.25"
experimental: false experimental: false

8
_data/engine-cli/docker_stack_ls.yaml
View File

@ -1,7 +1,13 @@
command: docker stack ls command: docker stack ls
aliases: list aliases: list
short: List stacks short: List stacks
long: Lists the stacks. long: |-
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.
usage: docker stack ls [OPTIONS] usage: docker stack ls [OPTIONS]
pname: docker stack pname: docker stack
plink: docker_stack.yaml plink: docker_stack.yaml

8
_data/engine-cli/docker_stack_ps.yaml
View File

@ -1,8 +1,12 @@
command: docker stack ps command: docker stack ps
short: List the tasks in the stack short: List the tasks in the stack
long: |- long: |-
Lists the tasks that are running as part of the specified stack. This Lists the tasks that are running as part of the specified stack.
command has to be run targeting a manager node.
> **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.
usage: docker stack ps [OPTIONS] STACK usage: docker stack ps [OPTIONS] STACK
pname: docker stack pname: docker stack
plink: docker_stack.yaml plink: docker_stack.yaml

8
_data/engine-cli/docker_stack_rm.yaml
View File

@ -2,8 +2,12 @@ command: docker stack rm
aliases: remove, down aliases: remove, down
short: Remove one or more stacks short: Remove one or more stacks
long: |- long: |-
Remove the stack from the swarm. This command has to be run targeting Remove the stack from the swarm.
a manager node.
> **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.
usage: docker stack rm [OPTIONS] STACK [STACK...] usage: docker stack rm [OPTIONS] STACK [STACK...]
pname: docker stack pname: docker stack
plink: docker_stack.yaml plink: docker_stack.yaml

8
_data/engine-cli/docker_stack_services.yaml
View File

@ -1,8 +1,12 @@
command: docker stack services command: docker stack services
short: List the services in the stack short: List the services in the stack
long: |- long: |-
Lists the services that are running as part of the specified stack. This Lists the services that are running as part of the specified stack.
command has to be run targeting a manager node.
> **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.
usage: docker stack services [OPTIONS] STACK usage: docker stack services [OPTIONS] STACK
pname: docker stack pname: docker stack
plink: docker_stack.yaml plink: docker_stack.yaml

8
_data/engine-cli/docker_swarm_ca.yaml
View File

@ -1,7 +1,11 @@
command: docker swarm ca command: docker swarm ca
short: Display and rotate the root CA short: Display and rotate the root CA
long: View or rotate the current swarm CA certificate. This command must target a long: |-
manager node. 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.
usage: docker swarm ca [OPTIONS] usage: docker swarm ca [OPTIONS]
pname: docker swarm pname: docker swarm
plink: docker_swarm.yaml plink: docker_swarm.yaml

4
_data/engine-cli/docker_swarm_unlock.yaml
View File

@ -5,6 +5,10 @@ long: |-
used to reactivate a manager after its Docker daemon restarts if the autolock 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 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. 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.
usage: docker swarm unlock usage: docker swarm unlock
pname: docker swarm pname: docker swarm
plink: docker_swarm.yaml plink: docker_swarm.yaml

8
_data/engine-cli/docker_swarm_update.yaml
View File

@ -1,7 +1,11 @@
command: docker swarm update command: docker swarm update
short: Update the swarm short: Update the swarm
long: Updates a swarm with new parameter values. This command must target a manager long: |-
node. 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.
usage: docker swarm update [OPTIONS] usage: docker swarm update [OPTIONS]
pname: docker swarm pname: docker swarm
plink: docker_swarm.yaml plink: docker_swarm.yaml

4
_data/engine-cli/docker_unpause.yaml
View File

@ -2,10 +2,10 @@ command: docker unpause
short: Unpause all processes within one or more containers short: Unpause all processes within one or more containers
long: |- long: |-
The `docker unpause` command un-suspends all processes in the specified containers. The `docker unpause` command un-suspends all processes in the specified containers.
On Linux, it does this using the cgroups freezer. On Linux, it does this using the freezer cgroup.
See the See the
[cgroups freezer documentation](https://www.kernel.org/doc/Documentation/cgroup-v1/freezer-subsystem.txt) [freezer cgroup documentation](https://www.kernel.org/doc/Documentation/cgroup-v1/freezer-subsystem.txt)
for further details. for further details.
usage: docker unpause CONTAINER [CONTAINER...] usage: docker unpause CONTAINER [CONTAINER...]
pname: docker pname: docker