mirror of https://github.com/docker/docs.git
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
parent
7e9d728df9
commit
d0fb9b16ed
|
|
@ -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
|
||||
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
|
||||
file](../builder.md#dockerignore-file)\n\n### Tag an image (-t)\n\n```bash\n$ docker
|
||||
build -t vieux/apache:2.0 .\n```\n\nThis will build like the previous example, but
|
||||
it will then tag the resulting\nimage. The repository name will be `vieux/apache`
|
||||
and the tag will be `2.0`.\n[Read more about valid tags](tag.md).\n\nYou can apply
|
||||
multiple tags to an image. For example, you can apply the `latest`\ntag to a newly
|
||||
built image and add another tag that references a specific\nversion.\nFor example,
|
||||
to tag an image both as `whenry/fedora-jboss:latest` and\n`whenry/fedora-jboss:v2.1`,
|
||||
use the following:\n\n```bash\n$ docker build -t whenry/fedora-jboss:latest -t whenry/fedora-jboss:v2.1
|
||||
.\n```\n\n### Specify a Dockerfile (-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,
|
||||
file](../builder.md#dockerignore-file).\n\nWhen using the [BuildKit backend](../builder.md#buildkit),
|
||||
`docker build` searches\nfor a `.dockerignore` file relative to the Dockerfile name.
|
||||
For example, running\n`docker build -f myapp.Dockerfile .` will first look for an
|
||||
ignore file named\n`myapp.Dockerfile.dockerignore`. If such a file is not found,
|
||||
the `.dockerignore`\nfile is used if present. Using a Dockerfile based `.dockerignore`
|
||||
is useful if a\nproject contains multiple Dockerfiles that expect to ignore different
|
||||
sets of\nfiles.\n\n\n### Tag an image (-t)\n\n```bash\n$ docker build -t vieux/apache:2.0
|
||||
.\n```\n\nThis will build like the previous example, but it will then tag the resulting\nimage.
|
||||
The repository name will be `vieux/apache` and the tag will be `2.0`.\n[Read more
|
||||
about valid tags](tag.md).\n\nYou can apply multiple tags to an image. For example,
|
||||
you can apply the `latest`\ntag to a newly built image and add another tag that
|
||||
references a specific\nversion.\nFor example, to tag an image both as `whenry/fedora-jboss:latest`
|
||||
and\n`whenry/fedora-jboss:v2.1`, use the following:\n\n```bash\n$ docker build -t
|
||||
whenry/fedora-jboss:latest -t whenry/fedora-jboss:v2.1 .\n```\n\n### Specify a Dockerfile
|
||||
(-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$
|
||||
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
|
||||
|
|
@ -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 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
|
||||
build-env .\n```\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
|
||||
build-env .\n```\n\n### Custom build outputs\n\nBy default, a local container image
|
||||
is created from the build result. The\n`--output` (or `-o`) flag allows you to override
|
||||
this behavior, and a specify a\ncustom exporter. For example, custom exporters allow
|
||||
you to export the build\nartifacts as files on the local filesystem instead of a
|
||||
Docker image, which can\nbe useful for generating local binaries, code generation
|
||||
etc.\n\nThe value for `--output` is a CSV-formatted string defining the exporter
|
||||
type\nand options. Currently, `local` and `tar` exporters are supported. The `local`\nexporter
|
||||
writes the resulting build files to a directory on the client side. The\n`tar` exporter
|
||||
is similar but writes the files as a single tarball (`.tar`).\n\nIf no type is specified,
|
||||
the value defaults to the output directory of the local\nexporter. Use a hyphen
|
||||
(`-`) to write the output tarball to standard output\n(`STDOUT`).\n\nThe following
|
||||
example builds an image using the current directory (`.`) as build\ncontext, and
|
||||
exports the files to a directory named `out` in the current directory.\nIf the directory
|
||||
does not exist, Docker creates the directory automatically:\n\n```bash\n$ docker
|
||||
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`
|
||||
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
|
||||
|
|
|
|||
|
|
@ -29,7 +29,7 @@ options:
|
|||
shorthand: v
|
||||
value_type: bool
|
||||
default_value: "false"
|
||||
description: Remove the volumes associated with the container
|
||||
description: Remove anonymous volumes associated with the container
|
||||
deprecated: false
|
||||
experimental: false
|
||||
experimentalcli: false
|
||||
|
|
|
|||
|
|
@ -1,176 +1,58 @@
|
|||
command: docker events
|
||||
short: Get real time events from the server
|
||||
long: |-
|
||||
Use `docker events` to get real-time events from the server. These events differ
|
||||
per Docker object type.
|
||||
|
||||
### Object types
|
||||
|
||||
#### Containers
|
||||
|
||||
Docker containers report the following events:
|
||||
|
||||
- `attach`
|
||||
- `commit`
|
||||
- `copy`
|
||||
- `create`
|
||||
- `destroy`
|
||||
- `detach`
|
||||
- `die`
|
||||
- `exec_create`
|
||||
- `exec_detach`
|
||||
- `exec_die`
|
||||
- `exec_start`
|
||||
- `export`
|
||||
- `health_status`
|
||||
- `kill`
|
||||
- `oom`
|
||||
- `pause`
|
||||
- `rename`
|
||||
- `resize`
|
||||
- `restart`
|
||||
- `start`
|
||||
- `stop`
|
||||
- `top`
|
||||
- `unpause`
|
||||
- `update`
|
||||
|
||||
#### Images
|
||||
|
||||
Docker images report the following events:
|
||||
|
||||
- `delete`
|
||||
- `import`
|
||||
- `load`
|
||||
- `pull`
|
||||
- `push`
|
||||
- `save`
|
||||
- `tag`
|
||||
- `untag`
|
||||
|
||||
#### Plugins
|
||||
|
||||
Docker plugins report the following events:
|
||||
|
||||
- `enable`
|
||||
- `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/ .
|
||||
long: "Use `docker events` to get real-time events from the server. These events differ\nper
|
||||
Docker object type. Different event types have different scopes. Local \nscoped
|
||||
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
|
||||
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-
|
||||
`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-
|
||||
`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-
|
||||
`import`\n- `load`\n- `pull`\n- `push`\n- `save`\n- `tag`\n- `untag`\n\n#### Plugins\n\nDocker
|
||||
plugins report the following events:\n\n- `enable`\n- `disable`\n- `install`\n-
|
||||
`remove`\n\n#### Volumes\n\nDocker volumes report the following events:\n\n- `create`\n-
|
||||
`destroy`\n- `mount`\n- `unmount`\n\n#### Networks\n\nDocker networks report the
|
||||
following events:\n\n- `create`\n- `connect`\n- `destroy`\n- `disconnect`\n- `remove`\n\n####
|
||||
Daemons\n\nDocker daemons report the following events:\n\n- `reload`\n\n#### Services\n\nDocker
|
||||
services report the following events:\n\n- `create`\n- `remove`\n- `update`\n\n####
|
||||
Nodes\n\nDocker nodes report the following events:\n\n- `create`\n- `remove`\n-
|
||||
`update`\n\n#### Secrets\n\nDocker secrets report the following events:\n\n- `create`\n-
|
||||
`remove`\n- `update`\n\n#### Configs\n\nDocker configs report the following events:\n\n-
|
||||
`create`\n- `remove`\n- `update`\n\n### Limiting, filtering, and formatting the
|
||||
output\n\n#### Limit events by time\n\nThe `--since` and `--until` parameters can
|
||||
be Unix timestamps, date formatted\ntimestamps, or Go duration strings (e.g. `10m`,
|
||||
`1h30m`) computed\nrelative to the client machine’s time. If you do not provide
|
||||
the `--since` option,\nthe command returns only new and/or live events. Supported
|
||||
formats for date\nformatted time stamps include RFC3339Nano, RFC3339, `2006-01-02T15:04:05`,\n`2006-01-02T15:04:05.999999999`,
|
||||
`2006-01-02Z07:00`, and `2006-01-02`. The local\ntimezone on the client will be
|
||||
used if you do not provide either a `Z` or a\n`+-00:00` timezone offset at the end
|
||||
of the timestamp. When providing Unix\ntimestamps enter seconds[.nanoseconds],
|
||||
where seconds is the number of seconds\nthat have elapsed since January 1, 1970
|
||||
(midnight UTC/GMT), not counting leap\nseconds (aka Unix epoch or Unix time), and
|
||||
the optional .nanoseconds field is a\nfraction of a second no more than nine digits
|
||||
long.\n\nOnly the last 1000 log events are returned. You can use filters to further
|
||||
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,
|
||||
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
|
||||
container=588a23dac085 --filter container=a8f7720b8c22` will display\nevents for
|
||||
container 588a23dac085 *OR* container a8f7720b8c22\n\nUsing multiple filters will
|
||||
be handled as a *AND*; for example\n`--filter container=588a23dac085 --filter event=start`
|
||||
will display events for\ncontainer container 588a23dac085 *AND* the event type is
|
||||
*start*\n\nThe currently supported filters are:\n\n* config (`config=<name or id>`)\n*
|
||||
container (`container=<name or id>`)\n* daemon (`daemon=<name or id>`)\n* event
|
||||
(`event=<event action>`)\n* image (`image=<repository or tag>`)\n* label (`label=<key>`
|
||||
or `label=<key>=<value>`)\n* network (`network=<name or id>`)\n* node (`node=<id>`)\n*
|
||||
plugin (`plugin=<name or id>`)\n* scope (`scope=<local or swarm>`)\n* secret (`secret=<name
|
||||
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*
|
||||
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/)
|
||||
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,
|
||||
please refer to http://jsonlines.org/ ."
|
||||
usage: docker events [OPTIONS]
|
||||
pname: docker
|
||||
plink: docker.yaml
|
||||
|
|
|
|||
|
|
@ -266,12 +266,12 @@ examples: |-
|
|||
|
||||
```bash
|
||||
$ docker network create -d overlay \
|
||||
--subnet=192.168.1.0/25 \
|
||||
--subnet=192.170.2.0/25 \
|
||||
--gateway=192.168.1.100 \
|
||||
--gateway=192.170.2.100 \
|
||||
--aux-address="my-router=192.168.1.5" --aux-address="my-switch=192.168.1.6" \
|
||||
--aux-address="my-printer=192.170.1.5" --aux-address="my-nas=192.170.1.6" \
|
||||
--subnet=192.168.10.0/25 \
|
||||
--subnet=192.168.20.0/25 \
|
||||
--gateway=192.168.10.100 \
|
||||
--gateway=192.168.20.100 \
|
||||
--aux-address="my-router=192.168.10.5" --aux-address="my-switch=192.168.10.6" \
|
||||
--aux-address="my-printer=192.168.20.5" --aux-address="my-nas=192.168.20.6" \
|
||||
my-multihost-network
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -1,8 +1,11 @@
|
|||
command: docker node demote
|
||||
short: Demote one or more nodes from manager in the swarm
|
||||
long: |-
|
||||
Demotes an existing manager so that it is no longer a manager. This command
|
||||
targets a docker engine that is a manager in the swarm.
|
||||
Demotes an existing manager so that it is no longer a manager.
|
||||
|
||||
> **Note**: This is a cluster management command, and must be executed on a swarm
|
||||
> 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...]
|
||||
pname: docker node
|
||||
plink: docker_node.yaml
|
||||
|
|
|
|||
|
|
@ -6,6 +6,10 @@ long: |-
|
|||
given template for each result. Go's
|
||||
[text/template](http://golang.org/pkg/text/template/) package describes all the
|
||||
details of the format.
|
||||
|
||||
> **Note**: This is a cluster management command, and must be executed on a swarm
|
||||
> manager node. To learn about managers and workers, refer to the [Swarm mode
|
||||
> section](https://docs.docker.com/engine/swarm/) in the documentation.
|
||||
usage: docker node inspect [OPTIONS] self|NODE [NODE...]
|
||||
pname: docker node
|
||||
plink: docker_node.yaml
|
||||
|
|
|
|||
|
|
@ -5,6 +5,10 @@ long: |-
|
|||
Lists all the nodes that the Docker Swarm manager knows about. You can filter
|
||||
using the `-f` or `--filter` flag. Refer to the [filtering](#filtering) section
|
||||
for more information about available filter options.
|
||||
|
||||
> **Note**: This is a cluster management command, and must be executed on a swarm
|
||||
> manager node. To learn about managers and workers, refer to the [Swarm mode
|
||||
> section](https://docs.docker.com/engine/swarm/) in the documentation.
|
||||
usage: docker node ls [OPTIONS]
|
||||
pname: docker node
|
||||
plink: docker_node.yaml
|
||||
|
|
|
|||
|
|
@ -1,6 +1,11 @@
|
|||
command: docker node promote
|
||||
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...]
|
||||
pname: docker node
|
||||
plink: docker_node.yaml
|
||||
|
|
|
|||
|
|
@ -1,8 +1,13 @@
|
|||
command: docker node ps
|
||||
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
|
||||
the `-f` or `--filter` flag. Refer to the [filtering](#filtering) section for more
|
||||
long: |-
|
||||
Lists all the tasks on a Node that Docker knows about. You can filter using the
|
||||
`-f` or `--filter` flag. Refer to the [filtering](#filtering) section for more
|
||||
information about available filter options.
|
||||
|
||||
> **Note**: This is a cluster management command, and must be executed on a swarm
|
||||
> manager node. To learn about managers and workers, refer to the [Swarm mode
|
||||
> section](https://docs.docker.com/engine/swarm/) in the documentation.
|
||||
usage: docker node ps [OPTIONS] [NODE...]
|
||||
pname: docker node
|
||||
plink: docker_node.yaml
|
||||
|
|
|
|||
|
|
@ -1,7 +1,12 @@
|
|||
command: docker node rm
|
||||
aliases: remove
|
||||
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...]
|
||||
pname: docker node
|
||||
plink: docker_node.yaml
|
||||
|
|
|
|||
|
|
@ -1,6 +1,11 @@
|
|||
command: docker node update
|
||||
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
|
||||
pname: docker node
|
||||
plink: docker_node.yaml
|
||||
|
|
|
|||
|
|
@ -2,14 +2,14 @@ command: docker pause
|
|||
short: Pause all processes within one or more containers
|
||||
long: |-
|
||||
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.
|
||||
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
|
||||
containers can be paused.
|
||||
|
||||
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.
|
||||
usage: docker pause CONTAINER [CONTAINER...]
|
||||
pname: docker
|
||||
|
|
|
|||
|
|
@ -81,389 +81,222 @@ options:
|
|||
experimentalcli: false
|
||||
kubernetes: false
|
||||
swarm: false
|
||||
examples: |-
|
||||
### Prevent truncating output
|
||||
|
||||
Running `docker ps --no-trunc` showing 2 linked containers.
|
||||
|
||||
```bash
|
||||
$ docker ps
|
||||
|
||||
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
|
||||
4c01db0b339c ubuntu:12.04 bash 17 seconds ago Up 16 seconds 3300-3310/tcp webapp
|
||||
d7886598dbe2 crosbymichael/redis:latest /redis-server --dir 33 minutes ago Up 33 minutes 6379/tcp redis,webapp/db
|
||||
```
|
||||
|
||||
### Show both running and stopped containers
|
||||
|
||||
The `docker ps` command only shows running containers by default. To see all
|
||||
containers, use the `-a` (or `--all`) flag:
|
||||
|
||||
```bash
|
||||
$ docker ps -a
|
||||
```
|
||||
|
||||
`docker ps` groups exposed ports into a single range if possible. E.g., a
|
||||
container that exposes TCP ports `100, 101, 102` displays `100-102/tcp` in
|
||||
the `PORTS` column.
|
||||
|
||||
### Filtering
|
||||
|
||||
The filtering flag (`-f` or `--filter`) format is a `key=value` pair. If there is more
|
||||
than one filter, then pass multiple flags (e.g. `--filter "foo=bar" --filter "bif=baz"`)
|
||||
|
||||
The currently supported filters are:
|
||||
|
||||
| Filter | Description |
|
||||
|:----------------------|:-------------------------------------------------------------------------------------------------------------------------------------|
|
||||
| `id` | Container's ID |
|
||||
| `name` | Container's name |
|
||||
| `label` | An arbitrary string representing either a key or a key-value pair. Expressed as `<key>` or `<key>=<value>` |
|
||||
| `exited` | An integer representing the container's exit code. Only useful with `--all`. |
|
||||
| `status` | One of `created`, `restarting`, `running`, `removing`, `paused`, `exited`, or `dead` |
|
||||
| `ancestor` | Filters containers which share a given image as an ancestor. Expressed as `<image-name>[:<tag>]`, `<image id>`, or `<image@digest>` |
|
||||
| `before` or `since` | Filters containers created before or after a given container ID or name |
|
||||
| `volume` | Filters running containers which have mounted a given volume or bind mount. |
|
||||
| `network` | Filters running containers connected to a given network. |
|
||||
| `publish` or `expose` | Filters containers which publish or expose a given port. Expressed as `<port>[/<proto>]` or `<startport-endport>/[<proto>]` |
|
||||
| `health` | Filters containers based on their healthcheck status. One of `starting`, `healthy`, `unhealthy` or `none`. |
|
||||
| `isolation` | Windows daemon only. One of `default`, `process`, or `hyperv`. |
|
||||
| `is-task` | Filters containers that are a "task" for a service. Boolean option (`true` or `false`) |
|
||||
|
||||
|
||||
#### label
|
||||
|
||||
The `label` filter matches containers based on the presence of a `label` alone or a `label` and a
|
||||
value.
|
||||
|
||||
The following filter matches containers with the `color` label regardless of its value.
|
||||
|
||||
```bash
|
||||
$ docker ps --filter "label=color"
|
||||
|
||||
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
|
||||
673394ef1d4c busybox "top" 47 seconds ago Up 45 seconds nostalgic_shockley
|
||||
d85756f57265 busybox "top" 52 seconds ago Up 51 seconds high_albattani
|
||||
```
|
||||
|
||||
The following filter matches containers with the `color` label with the `blue` value.
|
||||
|
||||
```bash
|
||||
$ docker ps --filter "label=color=blue"
|
||||
|
||||
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
|
||||
d85756f57265 busybox "top" About a minute ago Up About a minute high_albattani
|
||||
```
|
||||
|
||||
#### name
|
||||
|
||||
The `name` filter matches on all or part of a container's name.
|
||||
|
||||
The following filter matches all containers with a name containing the `nostalgic_stallman` string.
|
||||
|
||||
```bash
|
||||
$ docker ps --filter "name=nostalgic_stallman"
|
||||
|
||||
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
|
||||
9b6247364a03 busybox "top" 2 minutes ago Up 2 minutes nostalgic_stallman
|
||||
```
|
||||
|
||||
You can also filter for a substring in a name as this shows:
|
||||
|
||||
```bash
|
||||
$ docker ps --filter "name=nostalgic"
|
||||
|
||||
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
|
||||
715ebfcee040 busybox "top" 3 seconds ago Up 1 second i_am_nostalgic
|
||||
9b6247364a03 busybox "top" 7 minutes ago Up 7 minutes nostalgic_stallman
|
||||
673394ef1d4c busybox "top" 38 minutes ago Up 38 minutes nostalgic_shockley
|
||||
```
|
||||
|
||||
#### exited
|
||||
|
||||
The `exited` filter matches containers by exist status code. For example, to
|
||||
filter for containers that have exited successfully:
|
||||
|
||||
```bash
|
||||
$ docker ps -a --filter 'exited=0'
|
||||
|
||||
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
|
||||
ea09c3c82f6e registry:latest /srv/run.sh 2 weeks ago Exited (0) 2 weeks ago 127.0.0.1:5000->5000/tcp desperate_leakey
|
||||
106ea823fe4e fedora:latest /bin/sh -c 'bash -l' 2 weeks ago Exited (0) 2 weeks ago determined_albattani
|
||||
48ee228c9464 fedora:20 bash 2 weeks ago Exited (0) 2 weeks ago tender_torvalds
|
||||
```
|
||||
|
||||
#### Filter by exit signal
|
||||
|
||||
You can use a filter to locate containers that exited with status of `137`
|
||||
meaning a `SIGKILL(9)` killed them.
|
||||
|
||||
```none
|
||||
$ docker ps -a --filter 'exited=137'
|
||||
|
||||
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
|
||||
b3e1c0ed5bfe ubuntu:latest "sleep 1000" 12 seconds ago Exited (137) 5 seconds ago grave_kowalevski
|
||||
a2eb5558d669 redis:latest "/entrypoint.sh redi 2 hours ago Exited (137) 2 hours ago sharp_lalande
|
||||
```
|
||||
|
||||
Any of these events result in a `137` status:
|
||||
|
||||
* the `init` process of the container is killed manually
|
||||
* `docker kill` kills the container
|
||||
* Docker daemon restarts which kills all running containers
|
||||
|
||||
#### status
|
||||
|
||||
The `status` filter matches containers by status. You can filter using
|
||||
`created`, `restarting`, `running`, `removing`, `paused`, `exited` and `dead`. For example,
|
||||
to filter for `running` containers:
|
||||
|
||||
```bash
|
||||
$ docker ps --filter status=running
|
||||
|
||||
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
|
||||
715ebfcee040 busybox "top" 16 minutes ago Up 16 minutes i_am_nostalgic
|
||||
d5c976d3c462 busybox "top" 23 minutes ago Up 23 minutes top
|
||||
9b6247364a03 busybox "top" 24 minutes ago Up 24 minutes nostalgic_stallman
|
||||
```
|
||||
|
||||
To filter for `paused` containers:
|
||||
|
||||
```bash
|
||||
$ docker ps --filter status=paused
|
||||
|
||||
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
|
||||
673394ef1d4c busybox "top" About an hour ago Up About an hour (Paused) nostalgic_shockley
|
||||
```
|
||||
|
||||
#### ancestor
|
||||
|
||||
The `ancestor` filter matches containers based on its image or a descendant of
|
||||
it. The filter supports the following image representation:
|
||||
|
||||
- `image`
|
||||
- `image:tag`
|
||||
- `image:tag@digest`
|
||||
- `short-id`
|
||||
- `full-id`
|
||||
|
||||
If you don't specify a `tag`, the `latest` tag is used. For example, to filter
|
||||
for containers that use the latest `ubuntu` image:
|
||||
|
||||
```bash
|
||||
$ docker ps --filter ancestor=ubuntu
|
||||
|
||||
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
|
||||
919e1179bdb8 ubuntu-c1 "top" About a minute ago Up About a minute admiring_lovelace
|
||||
5d1e4a540723 ubuntu-c2 "top" About a minute ago Up About a minute admiring_sammet
|
||||
82a598284012 ubuntu "top" 3 minutes ago Up 3 minutes sleepy_bose
|
||||
bab2a34ba363 ubuntu "top" 3 minutes ago Up 3 minutes focused_yonath
|
||||
```
|
||||
|
||||
Match containers based on the `ubuntu-c1` image which, in this case, is a child
|
||||
of `ubuntu`:
|
||||
|
||||
```bash
|
||||
$ docker ps --filter ancestor=ubuntu-c1
|
||||
|
||||
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
|
||||
919e1179bdb8 ubuntu-c1 "top" About a minute ago Up About a minute admiring_lovelace
|
||||
```
|
||||
|
||||
Match containers based on the `ubuntu` version `12.04.5` image:
|
||||
|
||||
```bash
|
||||
$ docker ps --filter ancestor=ubuntu:12.04.5
|
||||
|
||||
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
|
||||
82a598284012 ubuntu:12.04.5 "top" 3 minutes ago Up 3 minutes sleepy_bose
|
||||
```
|
||||
|
||||
The following matches containers based on the layer `d0e008c6cf02` or an image
|
||||
that have this layer in its layer stack.
|
||||
|
||||
```bash
|
||||
$ docker ps --filter ancestor=d0e008c6cf02
|
||||
|
||||
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
|
||||
82a598284012 ubuntu:12.04.5 "top" 3 minutes ago Up 3 minutes sleepy_bose
|
||||
```
|
||||
|
||||
#### Create time
|
||||
|
||||
##### before
|
||||
|
||||
The `before` filter shows only containers created before the container with
|
||||
given id or name. For example, having these containers created:
|
||||
|
||||
```bash
|
||||
$ 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
|
||||
```
|
||||
examples: "### Prevent truncating output\n\nRunning `docker ps --no-trunc` showing
|
||||
2 linked containers.\n\n```bash\n$ docker ps\n\nCONTAINER ID IMAGE COMMAND
|
||||
\ CREATED STATUS PORTS NAMES\n4c01db0b339c
|
||||
\ ubuntu:12.04 bash 17 seconds ago Up
|
||||
16 seconds 3300-3310/tcp webapp\nd7886598dbe2 crosbymichael/redis:latest
|
||||
\ /redis-server --dir 33 minutes ago Up 33 minutes 6379/tcp redis,webapp/db\n```\n\n###
|
||||
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$
|
||||
docker ps -a\n```\n\n`docker ps` groups exposed ports into a single range if possible.
|
||||
E.g., a\ncontainer that exposes TCP ports `100, 101, 102` displays `100-102/tcp`
|
||||
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
|
||||
\ PORTS NAMES SIZE SIZE\ne90b8831a4b8
|
||||
\ nginx \"/bin/bash -c 'mkdir \" 11 weeks ago Up 4 hours my_nginx
|
||||
\ 35.58 kB (virtual 109.2 MB)\n00c6131c5e30 telegraf:1.5 \"/entrypoint.sh\"
|
||||
\ 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
|
||||
the _writable_ layer of each container\n * The \"virtual size\" is the total amount
|
||||
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
|
||||
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 filters
|
||||
are:\n\n| Filter | Description |\n|:----------------------|:-------------------------------------------------------------------------------------------------------------------------------------|\n|
|
||||
`id` | Container's ID |\n|
|
||||
`name` | Container's name |\n|
|
||||
`label` | An arbitrary string representing either a key or a key-value
|
||||
pair. Expressed as `<key>` or `<key>=<value>` |\n| `exited`
|
||||
\ | An integer representing the container's exit code. Only useful with
|
||||
`--all`. |\n| `status` |
|
||||
One of `created`, `restarting`, `running`, `removing`, `paused`, `exited`, or `dead`
|
||||
\ |\n| `ancestor` | Filters
|
||||
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
|
||||
created before or after a given container ID or name |\n|
|
||||
`volume` | Filters running containers which have mounted a given volume
|
||||
or bind mount. |\n| `network`
|
||||
\ | Filters running containers connected to a given network. |\n|
|
||||
`publish` or `expose` | Filters containers which publish or expose a given port.
|
||||
Expressed as `<port>[/<proto>]` or `<startport-endport>/[<proto>]` |\n|
|
||||
`health` | Filters containers based on their healthcheck status. One
|
||||
of `starting`, `healthy`, `unhealthy` or `none`. |\n|
|
||||
`isolation` | Windows daemon only. One of `default`, `process`, or `hyperv`.
|
||||
\ |\n| `is-task`
|
||||
\ | Filters containers that are a \"task\" for a service. Boolean option
|
||||
(`true` or `false`) |\n\n\n#### label\n\nThe
|
||||
`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
|
||||
ID IMAGE COMMAND CREATED STATUS PORTS
|
||||
\ NAMES\n673394ef1d4c busybox \"top\" 47
|
||||
seconds ago Up 45 seconds nostalgic_shockley\nd85756f57265
|
||||
\ busybox \"top\" 52 seconds ago Up 51 seconds
|
||||
\ high_albattani\n```\n\nThe following filter matches containers
|
||||
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
|
||||
\ NAMES\nd85756f57265 busybox \"top\" About
|
||||
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
|
||||
filter matches all containers with a name containing the `nostalgic_stallman` string.\n\n```bash\n$
|
||||
docker ps --filter \"name=nostalgic_stallman\"\n\nCONTAINER ID IMAGE COMMAND
|
||||
\ CREATED STATUS PORTS NAMES\n9b6247364a03
|
||||
\ busybox \"top\" 2 minutes ago Up 2 minutes
|
||||
\ nostalgic_stallman\n```\n\nYou can also filter for a
|
||||
substring in a name as this shows:\n\n```bash\n$ docker ps --filter \"name=nostalgic\"\n\nCONTAINER
|
||||
ID IMAGE COMMAND CREATED STATUS PORTS
|
||||
\ NAMES\n715ebfcee040 busybox \"top\" 3
|
||||
seconds ago Up 1 second i_am_nostalgic\n9b6247364a03
|
||||
\ busybox \"top\" 7 minutes ago Up 7 minutes
|
||||
\ nostalgic_stallman\n673394ef1d4c busybox \"top\"
|
||||
\ 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
|
||||
-a --filter 'exited=0'\n\nCONTAINER ID IMAGE COMMAND CREATED
|
||||
\ STATUS PORTS NAMES\nea09c3c82f6e
|
||||
\ 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
|
||||
\ /bin/sh -c 'bash -l' 2 weeks ago Exited (0) 2 weeks ago determined_albattani\n48ee228c9464
|
||||
\ fedora:20 bash 2 weeks ago Exited (0)
|
||||
2 weeks ago tender_torvalds\n```\n\n#### Filter by
|
||||
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
|
||||
'exited=137'\n\nCONTAINER ID IMAGE COMMAND CREATED
|
||||
\ STATUS PORTS NAMES\nb3e1c0ed5bfe
|
||||
\ ubuntu:latest \"sleep 1000\" 12 seconds ago Exited
|
||||
(137) 5 seconds ago grave_kowalevski\na2eb5558d669 redis:latest
|
||||
\ \"/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
|
||||
is killed manually\n* `docker kill` kills the container\n* Docker daemon restarts
|
||||
which kills all running containers\n\n#### status\n\nThe `status` filter matches
|
||||
containers by status. You can filter using\n`created`, `restarting`, `running`,
|
||||
`removing`, `paused`, `exited` and `dead`. For example,\nto filter for `running`
|
||||
containers:\n\n```bash\n$ docker ps --filter status=running\n\nCONTAINER ID IMAGE
|
||||
\ COMMAND CREATED STATUS PORTS
|
||||
\ NAMES\n715ebfcee040 busybox \"top\" 16
|
||||
minutes ago Up 16 minutes i_am_nostalgic\nd5c976d3c462
|
||||
\ busybox \"top\" 23 minutes ago Up 23 minutes
|
||||
\ top\n9b6247364a03 busybox \"top\"
|
||||
\ 24 minutes ago Up 24 minutes nostalgic_stallman\n```\n\nTo
|
||||
filter for `paused` containers:\n\n```bash\n$ docker ps --filter status=paused\n\nCONTAINER
|
||||
ID IMAGE COMMAND CREATED STATUS PORTS
|
||||
\ NAMES\n673394ef1d4c busybox \"top\" About
|
||||
an hour ago Up About an hour (Paused) nostalgic_shockley\n```\n\n####
|
||||
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-
|
||||
`image:tag`\n- `image:tag@digest`\n- `short-id`\n- `full-id`\n\nIf you don't specify
|
||||
a `tag`, the `latest` tag is used. For example, to filter\nfor containers that use
|
||||
the latest `ubuntu` image:\n\n```bash\n$ docker ps --filter ancestor=ubuntu\n\nCONTAINER
|
||||
ID IMAGE COMMAND CREATED STATUS PORTS
|
||||
\ NAMES\n919e1179bdb8 ubuntu-c1 \"top\" About
|
||||
a minute ago Up About a minute admiring_lovelace\n5d1e4a540723
|
||||
\ ubuntu-c2 \"top\" About a minute ago Up About
|
||||
a minute admiring_sammet\n82a598284012 ubuntu \"top\"
|
||||
\ 3 minutes ago Up 3 minutes sleepy_bose\nbab2a34ba363
|
||||
\ ubuntu \"top\" 3 minutes ago Up 3 minutes
|
||||
\ focused_yonath\n```\n\nMatch containers based on the
|
||||
`ubuntu-c1` image which, in this case, is a child\nof `ubuntu`:\n\n```bash\n$ docker
|
||||
ps --filter ancestor=ubuntu-c1\n\nCONTAINER ID IMAGE COMMAND
|
||||
\ CREATED STATUS PORTS NAMES\n919e1179bdb8
|
||||
\ ubuntu-c1 \"top\" About a minute ago Up About
|
||||
a minute admiring_lovelace\n```\n\nMatch containers based
|
||||
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
|
||||
minutes ago Up 3 minutes sleepy_bose\n```\n\nThe
|
||||
following matches containers based on the layer `d0e008c6cf02` or an image\nthat
|
||||
have this layer in its layer stack.\n\n```bash\n$ docker ps --filter ancestor=d0e008c6cf02\n\nCONTAINER
|
||||
ID IMAGE COMMAND CREATED STATUS PORTS
|
||||
\ NAMES\n82a598284012 ubuntu:12.04.5 \"top\" 3
|
||||
minutes ago Up 3 minutes sleepy_bose\n```\n\n####
|
||||
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
|
||||
created:\n\n```bash\n$ docker ps\n\nCONTAINER ID IMAGE COMMAND CREATED
|
||||
\ STATUS PORTS NAMES\n9c3527ed70ce busybox
|
||||
\ \"top\" 14 seconds ago Up 15 seconds desperate_dubinsky\n4aace5031105
|
||||
\ busybox \"top\" 48 seconds ago Up 49 seconds focused_hamilton\n6e63f6ff38b0
|
||||
\ busybox \"top\" About a minute ago Up About a minute distracted_fermat\n```\n\nFiltering
|
||||
with `before` would give:\n\n```bash\n$ docker ps -f before=9c3527ed70ce\n\nCONTAINER
|
||||
ID IMAGE COMMAND CREATED STATUS PORTS
|
||||
\ NAMES\n4aace5031105 busybox \"top\" About a minute
|
||||
ago Up About a minute focused_hamilton\n6e63f6ff38b0 busybox
|
||||
\ \"top\" About a minute ago Up About a minute distracted_fermat\n```\n\n#####
|
||||
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
|
||||
\ STATUS PORTS NAMES\n9c3527ed70ce busybox
|
||||
\ \"top\" 10 minutes ago Up 10 minutes desperate_dubinsky\n4aace5031105
|
||||
\ busybox \"top\" 10 minutes ago Up 10 minutes focused_hamilton\n```\n\n####
|
||||
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
|
||||
--format \"table {{.ID}}\\t{{.Mounts}}\"\nCONTAINER ID MOUNTS\n9c3527ed70ce
|
||||
\ 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
|
||||
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
|
||||
--name=test1 ubuntu top\n$ docker run -d --net=net2 --name=test2 ubuntu top\n\n$
|
||||
docker ps --filter network=net1\n\nCONTAINER ID IMAGE COMMAND CREATED
|
||||
\ STATUS PORTS NAMES\n9d4893ed80fe ubuntu
|
||||
\ \"top\" 10 minutes ago Up 10 minutes test1\n```\n\nThe
|
||||
network filter matches on both the network's name and id. The following\nexample
|
||||
shows all containers that are attached to the `net1` network, using\nthe network
|
||||
id as a filter;\n\n```bash\n$ docker network inspect --format \"{{.ID}}\" net1\n\n8c0b4110ae930dbe26b258de9bc34a03f98056ed6f27f991d32919bfe401d7c5\n\n$
|
||||
docker ps --filter network=8c0b4110ae930dbe26b258de9bc34a03f98056ed6f27f991d32919bfe401d7c5\n\nCONTAINER
|
||||
ID IMAGE COMMAND CREATED STATUS PORTS
|
||||
\ NAMES\n9d4893ed80fe ubuntu \"top\" 10 minutes
|
||||
ago Up 10 minutes test1\n```\n\n#### publish and
|
||||
expose\n\nThe `publish` and `expose` filters show only containers that have published
|
||||
or exposed port with a given port\nnumber, port range, and/or protocol. The default
|
||||
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
|
||||
top\n$ docker run -d --expose=8080 busybox top\n\n$ docker ps -a\n\nCONTAINER ID
|
||||
\ IMAGE COMMAND CREATED STATUS PORTS
|
||||
\ NAMES\n9833437217a5 busybox \"top\" 5
|
||||
seconds ago Up 4 seconds 8080/tcp dreamy_mccarthy\nfc7e477723b7
|
||||
\ 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
|
||||
\ NAMES\nfc7e477723b7 busybox \"top\" About
|
||||
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
|
||||
of `8000-8080`:\n```bash\n$ docker ps --filter expose=8000-8080/tcp\n\nCONTAINER
|
||||
ID IMAGE COMMAND CREATED STATUS PORTS
|
||||
\ NAMES\n9833437217a5 busybox \"top\" 21
|
||||
seconds ago Up 19 seconds 8080/tcp dreamy_mccarthy\n```\n\nThe
|
||||
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###
|
||||
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|
|
||||
Placeholder | Description |\n|:--------------|:------------------------------------------------------------------------------------------------|\n|
|
||||
`.ID` | Container ID |\n|
|
||||
`.Image` | Image ID |\n|
|
||||
`.Command` | Quoted command |\n|
|
||||
`.CreatedAt` | Time when the container was created. |\n|
|
||||
`.RunningFor` | Elapsed time since the container was started. |\n|
|
||||
`.Ports` | Exposed ports. |\n|
|
||||
`.Status` | Container status. |\n|
|
||||
`.Size` | Container disk size. |\n|
|
||||
`.Names` | Container names. |\n|
|
||||
`.Labels` | All labels assigned to the container. |\n|
|
||||
`.Label` | Value of a specific label for this container. For example `'{{.Label
|
||||
\"com.docker.swarm.cpu\"}}'` |\n| `.Mounts` | Names of the volumes mounted in
|
||||
this container. |\n| `.Networks`
|
||||
\ | 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
|
||||
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$
|
||||
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:
|
||||
/bin/sh -c #(nop) MA\n```\n\nTo list all running containers with their labels in
|
||||
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
|
||||
\ 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```"
|
||||
deprecated: false
|
||||
experimental: false
|
||||
experimentalcli: false
|
||||
|
|
|
|||
|
|
@ -29,7 +29,7 @@ options:
|
|||
shorthand: v
|
||||
value_type: bool
|
||||
default_value: "false"
|
||||
description: Remove the volumes associated with the container
|
||||
description: Remove anonymous volumes associated with the container
|
||||
deprecated: false
|
||||
experimental: false
|
||||
experimentalcli: false
|
||||
|
|
|
|||
|
|
@ -1090,6 +1090,11 @@ examples: |-
|
|||
The [Docker User Guide](https://docs.docker.com/engine/userguide/networking/default_network/dockerlinks/)
|
||||
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
|
||||
$ docker run --expose 80 ubuntu bash
|
||||
```
|
||||
|
|
@ -1422,7 +1427,7 @@ examples: |-
|
|||
flags for IPv4 address retrieval for a network device named `eth0`:
|
||||
|
||||
```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
|
||||
```
|
||||
|
||||
|
|
@ -1607,3 +1612,4 @@ experimental: false
|
|||
experimentalcli: false
|
||||
kubernetes: false
|
||||
swarm: false
|
||||
|
||||
|
|
|
|||
|
|
@ -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###
|
||||
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
|
||||
in the output:\n\n```bash\n$ docker search --stars=3 --no-trunc busybox\nNAME DESCRIPTION
|
||||
\ STARS
|
||||
in the output:\n\n```bash\n$ docker search --filter=stars=3 --no-trunc busybox\nNAME
|
||||
\ DESCRIPTION STARS
|
||||
\ OFFICIAL AUTOMATED\nbusybox Busybox base image. 325
|
||||
\ [OK] \nprogrium/busybox 50
|
||||
\ [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
|
||||
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
|
||||
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
|
||||
- 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
|
||||
|
|
@ -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
|
||||
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$
|
||||
docker search --filter is-automated busybox\n\nNAME DESCRIPTION
|
||||
docker search --filter is-automated=true busybox\n\nNAME DESCRIPTION
|
||||
\ STARS OFFICIAL AUTOMATED\nprogrium/busybox
|
||||
\ 50 [OK]\nradial/busyboxplus
|
||||
\ Full-chain, Internet enabled, busybox made... 8 [OK]\n```\n\n####
|
||||
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\"
|
||||
--filter \"stars=3\" busybox\n\nNAME DESCRIPTION STARS
|
||||
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
|
||||
\ OFFICIAL AUTOMATED\nprogrium/busybox 50
|
||||
\ [OK]\nradial/busyboxplus Full-chain, Internet enabled, busybox
|
||||
made... 8 [OK]\n```\n\n### Format the output\n\nThe formatting
|
||||
|
|
|
|||
|
|
@ -1,9 +1,13 @@
|
|||
command: docker secret create
|
||||
short: Create a secret from a file or STDIN as content
|
||||
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/).
|
||||
|
||||
> **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|-]
|
||||
pname: docker secret
|
||||
plink: docker_secret.yaml
|
||||
|
|
|
|||
|
|
@ -1,8 +1,7 @@
|
|||
command: docker secret inspect
|
||||
short: Display detailed information on one or more secrets
|
||||
long: |-
|
||||
Inspects the specified secret. This command has to be run targeting a manager
|
||||
node.
|
||||
Inspects the specified secret.
|
||||
|
||||
By default, this renders all results in a JSON array. If a format is specified,
|
||||
the given template will be executed for each result.
|
||||
|
|
@ -11,6 +10,10 @@ long: |-
|
|||
describes all the details of the format.
|
||||
|
||||
For detailed information about using secrets, refer to [manage sensitive data with Docker secrets](https://docs.docker.com/engine/swarm/secrets/).
|
||||
|
||||
> **Note**: This is a cluster management command, and must be executed on a swarm
|
||||
> manager node. To learn about managers and workers, refer to the [Swarm mode
|
||||
> section](https://docs.docker.com/engine/swarm/) in the documentation.
|
||||
usage: docker secret inspect [OPTIONS] SECRET [SECRET...]
|
||||
pname: docker secret
|
||||
plink: docker_secret.yaml
|
||||
|
|
|
|||
|
|
@ -5,6 +5,10 @@ long: |-
|
|||
Run this command on a manager node to list the secrets in the swarm.
|
||||
|
||||
For detailed information about using secrets, refer to [manage sensitive data with Docker secrets](https://docs.docker.com/engine/swarm/secrets/).
|
||||
|
||||
> **Note**: This is a cluster management command, and must be executed on a swarm
|
||||
> manager node. To learn about managers and workers, refer to the [Swarm mode
|
||||
> section](https://docs.docker.com/engine/swarm/) in the documentation.
|
||||
usage: docker secret ls [OPTIONS]
|
||||
pname: docker secret
|
||||
plink: docker_secret.yaml
|
||||
|
|
|
|||
|
|
@ -2,10 +2,13 @@ command: docker secret rm
|
|||
aliases: remove
|
||||
short: Remove one or more secrets
|
||||
long: |-
|
||||
Removes the specified secrets from the swarm. This command has to be run
|
||||
targeting a manager node.
|
||||
Removes the specified secrets from the swarm.
|
||||
|
||||
For detailed information about using secrets, refer to [manage sensitive data with Docker secrets](https://docs.docker.com/engine/swarm/secrets/).
|
||||
|
||||
> **Note**: This is a cluster management command, and must be executed on a swarm
|
||||
> manager node. To learn about managers and workers, refer to the [Swarm mode
|
||||
> section](https://docs.docker.com/engine/swarm/) in the documentation.
|
||||
usage: docker secret rm SECRET [SECRET...]
|
||||
pname: docker secret
|
||||
plink: docker_secret.yaml
|
||||
|
|
|
|||
|
|
@ -1,6 +1,11 @@
|
|||
command: docker service
|
||||
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
|
||||
pname: docker
|
||||
plink: docker.yaml
|
||||
|
|
|
|||
|
|
@ -1,8 +1,11 @@
|
|||
command: docker service create
|
||||
short: Create a new service
|
||||
long: |-
|
||||
Creates a service as described by the specified parameters. You must run this
|
||||
command on a manager node.
|
||||
Creates a service as described by the specified parameters.
|
||||
|
||||
> **Note**: This is a cluster management command, and must be executed on a swarm
|
||||
> manager node. To learn about managers and workers, refer to the [Swarm mode
|
||||
> section](https://docs.docker.com/engine/swarm/) in the documentation.
|
||||
usage: docker service create [OPTIONS] IMAGE [COMMAND] [ARG...]
|
||||
pname: docker service
|
||||
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
|
||||
\ --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
|
||||
are located in `/run/secrets` in the container. If no target is\nspecified, the
|
||||
name of the secret will be used as the in memory file in the\ncontainer. If a target
|
||||
is specified, that will be the filename. In the\nexample above, two files will
|
||||
be created: `/run/secrets/ssh` and\n`/run/secrets/app` for each of the secret targets
|
||||
specified.\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),
|
||||
are located in `/run/secrets` in the container if no target is specified.\nIf no
|
||||
target is specified, the name of the secret is used as the in memory file\nin the
|
||||
container. If a target is specified, that is used as the filename. In the\nexample
|
||||
above, two files are created: `/run/secrets/ssh` and\n`/run/secrets/app` for each
|
||||
of the secret targets specified.\n\n### Create a service with configs\n\nUse the
|
||||
`--config` flag to give a container access to a\n[config](config_create.md).\n\nCreate
|
||||
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.
|
||||
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
|
||||
|
|
@ -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#####
|
||||
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.
|
||||
Consider\na mount point `/mnt`, which is also mounted on `/tmp`. The propation settings\ncontrol
|
||||
whether a mount on `/tmp/a` would also be available on `/mnt/a`. Each\npropagation
|
||||
setting has a recursive counterpoint. In the case of recursion,\nconsider that `/tmp/a`
|
||||
is also mounted as `/foo`. The propagation settings\ncontrol whether `/mnt/a` and/or
|
||||
`/tmp/a` would exist.\n\nThe `bind-propagation` option defaults to `rprivate` for
|
||||
both bind mounts and\nvolume mounts, and is only configurable for bind mounts. In
|
||||
other words, named\nvolumes do not support bind propagation.\n\n- **`shared`**:
|
||||
Sub-mounts of the original mount are exposed to replica mounts,\n and
|
||||
sub-mounts of replica mounts are also propagated to the\n original
|
||||
Consider\na mount point `/mnt`, which is also mounted on `/tmp`. The propagation
|
||||
settings\ncontrol whether a mount on `/tmp/a` would also be available on `/mnt/a`.
|
||||
Each\npropagation setting has a recursive counterpoint. In the case of recursion,\nconsider
|
||||
that `/tmp/a` is also mounted as `/foo`. The propagation settings\ncontrol whether
|
||||
`/mnt/a` and/or `/tmp/a` would exist.\n\nThe `bind-propagation` option defaults
|
||||
to `rprivate` for both bind mounts and\nvolume mounts, and is only configurable
|
||||
for bind mounts. In other words, named\nvolumes do not support bind propagation.\n\n-
|
||||
**`shared`**: Sub-mounts of the original mount are exposed to replica mounts,\n
|
||||
\ 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
|
||||
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
|
||||
|
|
@ -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
|
||||
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
|
||||
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
|
||||
or Docker Engine labels as\nfollows:\n\n\n<table>\n <tr>\n <th>node attribute</th>\n
|
||||
\ <th>matches</th>\n <th>example</th>\n </tr>\n <tr>\n <td><tt>node.id</tt></td>\n
|
||||
\ <td>Node ID</td>\n <td><tt>node.id==2ivku8v2gvtg4</tt></td>\n </tr>\n <tr>\n
|
||||
\ <td><tt>node.hostname</tt></td>\n <td>Node hostname</td>\n <td><tt>node.hostname!=node-2</tt></td>\n
|
||||
\ </tr>\n <tr>\n <td><tt>node.role</tt></td>\n <td>Node role</td>\n <td><tt>node.role==manager</tt></td>\n
|
||||
\ </tr>\n <tr>\n <td><tt>node.labels</tt></td>\n <td>user defined node labels</td>\n
|
||||
\ <td><tt>node.labels.security==high</tt></td>\n </tr>\n <tr>\n <td><tt>engine.labels</tt></td>\n
|
||||
\ <td>Docker Engine's labels</td>\n <td><tt>engine.labels.operatingsystem==ubuntu
|
||||
14.04</tt></td>\n </tr>\n</table>\n\n\n`engine.labels` apply to Docker Engine labels
|
||||
like operating system,\ndrivers, etc. Swarm administrators add `node.labels` for
|
||||
operational purposes by\nusing the [`docker node update`](node_update.md) command.\n\nFor
|
||||
example, the following limits tasks for the redis service to nodes where the\nnode
|
||||
type label equals queue:\n\n```bash\n$ docker service create \\\n --name redis_2
|
||||
\\\n --constraint 'node.labels.type == queue' \\\n redis:3.0.6\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.
|
||||
or Docker Engine labels as\nfollows:\n\nnode attribute | matches |
|
||||
example\n---------------------|--------------------------------|-----------------------------------------------\n`node.id`
|
||||
\ | Node ID | `node.id==2ivku8v2gvtg4`\n`node.hostname`
|
||||
\ | Node hostname | `node.hostname!=node-2`\n`node.role` |
|
||||
Node role (`manager`/`worker`) | `node.role==manager`\n`node.platform.os` | Node
|
||||
operating system | `node.platform.os==windows`\n`node.platform.arch` |
|
||||
Node architecture | `node.platform.arch==x86_64`\n`node.labels` |
|
||||
User-defined node labels | `node.labels.security==high`\n`engine.labels` |
|
||||
Docker Engine's labels | `engine.labels.operatingsystem==ubuntu-14.04`\n\n\n`engine.labels`
|
||||
apply to Docker Engine labels like operating system, drivers,\netc. Swarm administrators
|
||||
add `node.labels` for operational purposes by using\nthe [`docker node update`](node_update.md)
|
||||
command.\n\nFor example, the following limits tasks for the redis service to nodes
|
||||
where the\nnode type label equals queue:\n\n```bash\n$ docker service create \\\n
|
||||
\ --name redis_2 \\\n --constraint node.platform.os==linux \\\n --constraint node.labels.type==queue
|
||||
\\\n redis:3.0.6\n```\n\nIf the service constraints exclude all nodes in the cluster,
|
||||
a message is printed\nthat no suitable node is found, but the scheduler will start
|
||||
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
|
||||
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
|
||||
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
|
||||
|
|
@ -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
|
||||
a service with `docker service update`, `--placement-pref-add`\nappends a new placement
|
||||
preference after all existing placement preferences.\n`--placement-pref-rm` removes
|
||||
an existing placement preference that matches the\nargument.\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
|
||||
an existing placement preference that matches the\nargument.\n\n### Specify memory
|
||||
requirements and constraints for a service (--reserve-memory and --limit-memory)\n\nIf
|
||||
your service needs a minimum amount of memory in order to run correctly,\nyou can
|
||||
use `--reserve-memory` to specify that the service should only be\nscheduled on
|
||||
a node with this much memory available to reserve. If no node is\navailable that
|
||||
meets the criteria, the task is not scheduled, but remains in a\npending state.\n\nThe
|
||||
following example requires that 4GB of memory be available and reservable\non a
|
||||
given node before scheduling the service to run on that node.\n\n```bash\n$ docker
|
||||
service create --reserve-memory=4GB --name=too-big nginx:alpine\n```\n\nThe managers
|
||||
won't schedule a set of containers on a single node whose combined\nreservations
|
||||
exceed the memory available on that node.\n\nAfter a task is scheduled and running,
|
||||
`--reserve-memory` does not enforce a\nmemory limit. Use `--limit-memory` to ensure
|
||||
that a task uses no more than a\ngiven amount of memory on a node. This example
|
||||
limits the amount of memory used\nby the task to 4GB. The task will be scheduled
|
||||
even if each of your nodes has\nonly 2GB of memory, because `--limit-memory` is
|
||||
an upper limit.\n\n```bash\n$ docker service create --limit-memory=4GB --name=too-big
|
||||
nginx:alpine\n```\n\nUsing `--reserve-memory` and `--limit-memory` does not guarantee
|
||||
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
|
||||
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:
|
||||
|
|
|
|||
|
|
@ -1,14 +1,17 @@
|
|||
command: docker service inspect
|
||||
short: Display detailed information on one or more services
|
||||
long: |-
|
||||
Inspects the specified service. This command has to be run targeting a manager
|
||||
node.
|
||||
Inspects the specified service.
|
||||
|
||||
By default, this renders all results in a JSON array. If a format is specified,
|
||||
the given template will be executed for each result.
|
||||
|
||||
Go's [text/template](http://golang.org/pkg/text/template/) package
|
||||
describes all the details of the format.
|
||||
|
||||
> **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...]
|
||||
pname: docker service
|
||||
plink: docker_service.yaml
|
||||
|
|
|
|||
|
|
@ -3,6 +3,10 @@ short: Fetch the logs of a service or task
|
|||
long: |-
|
||||
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
|
||||
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
|
||||
|
|
|
|||
|
|
@ -2,8 +2,11 @@ command: docker service ls
|
|||
aliases: list
|
||||
short: List services
|
||||
long: |-
|
||||
This command when run targeting a manager, lists services are running in the
|
||||
swarm.
|
||||
This command lists services are running in the swarm.
|
||||
|
||||
> **Note**: This is a cluster management command, and must be executed on a swarm
|
||||
> manager node. To learn about managers and workers, refer to the [Swarm mode
|
||||
> section](https://docs.docker.com/engine/swarm/) in the documentation.
|
||||
usage: docker service ls [OPTIONS]
|
||||
pname: docker service
|
||||
plink: docker_service.yaml
|
||||
|
|
|
|||
|
|
@ -1,8 +1,11 @@
|
|||
command: docker service ps
|
||||
short: List the tasks of one or more services
|
||||
long: |-
|
||||
Lists the tasks that are running as part of the specified services. This command
|
||||
has to be run targeting a manager node.
|
||||
Lists the tasks that are running as part of the specified services.
|
||||
|
||||
> **Note**: This is a cluster management command, and must be executed on a swarm
|
||||
> manager node. To learn about managers and workers, refer to the [Swarm mode
|
||||
> section](https://docs.docker.com/engine/swarm/) in the documentation.
|
||||
usage: docker service ps [OPTIONS] SERVICE [SERVICE...]
|
||||
pname: docker service
|
||||
plink: docker_service.yaml
|
||||
|
|
|
|||
|
|
@ -2,8 +2,11 @@ command: docker service rm
|
|||
aliases: remove
|
||||
short: Remove one or more services
|
||||
long: |-
|
||||
Removes the specified services from the swarm. This command has to be run
|
||||
targeting a manager node.
|
||||
Removes the specified services from the swarm.
|
||||
|
||||
> **Note**: This is a cluster management command, and must be executed on a swarm
|
||||
> manager node. To learn about managers and workers, refer to the [Swarm mode
|
||||
> section](https://docs.docker.com/engine/swarm/) in the documentation.
|
||||
usage: docker service rm SERVICE [SERVICE...]
|
||||
pname: docker service
|
||||
plink: docker_service.yaml
|
||||
|
|
|
|||
|
|
@ -1,8 +1,11 @@
|
|||
command: docker service rollback
|
||||
short: Revert changes to a service's configuration
|
||||
long: |-
|
||||
Roll back a specified service to its previous version from the swarm. This command must be run
|
||||
targeting a manager node.
|
||||
Roll back a specified service to its previous version from the swarm.
|
||||
|
||||
> **Note**: This is a cluster management command, and must be executed on a swarm
|
||||
> manager node. To learn about managers and workers, refer to the [Swarm mode
|
||||
> section](https://docs.docker.com/engine/swarm/) in the documentation.
|
||||
usage: docker service rollback [OPTIONS] SERVICE
|
||||
pname: docker service
|
||||
plink: docker_service.yaml
|
||||
|
|
|
|||
|
|
@ -6,6 +6,10 @@ long: |-
|
|||
services which are global mode. The command will return immediately, but the
|
||||
actual scaling of the service may take some time. To stop all replicas of a
|
||||
service while keeping the service active in the swarm you can set the scale to 0.
|
||||
|
||||
> **Note**: This is a cluster management command, and must be executed on a swarm
|
||||
> manager node. To learn about managers and workers, refer to the [Swarm mode
|
||||
> section](https://docs.docker.com/engine/swarm/) in the documentation.
|
||||
usage: docker service scale SERVICE=REPLICAS [SERVICE=REPLICAS...]
|
||||
pname: docker service
|
||||
plink: docker_service.yaml
|
||||
|
|
|
|||
|
|
@ -1,15 +1,19 @@
|
|||
command: docker service update
|
||||
short: Update a service
|
||||
long: |-
|
||||
Updates a service as described by the specified parameters. This command has to be run targeting a manager node.
|
||||
The parameters are the same as [`docker service create`](service_create.md). Please look at the description there
|
||||
for further information.
|
||||
Updates a service as described by the specified parameters. The parameters are
|
||||
the same as [`docker service create`](service_create.md). Refer to the description
|
||||
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
|
||||
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
|
||||
setting. However, the `--force` flag will cause the tasks to be recreated anyway. This can be used to perform a
|
||||
rolling restart without any changes to the service parameters.
|
||||
|
||||
> **Note**: This is a cluster management command, and must be executed on a swarm
|
||||
> manager node. To learn about managers and workers, refer to the [Swarm mode
|
||||
> section](https://docs.docker.com/engine/swarm/) in the documentation.
|
||||
usage: docker service update [OPTIONS] SERVICE
|
||||
pname: docker service
|
||||
plink: docker_service.yaml
|
||||
|
|
|
|||
|
|
@ -2,12 +2,24 @@ command: docker stack deploy
|
|||
aliases: up
|
||||
short: Deploy a new stack or update an existing stack
|
||||
long: |-
|
||||
Create and update a stack from a `compose` file on the swarm. This command has to
|
||||
be run targeting a manager node.
|
||||
Create and update a stack from a `compose` file on the swarm.
|
||||
|
||||
> **Note**: This is a cluster management command. When using swarm as an orchestrator,
|
||||
> this command must be executed on a swarm manager node. To learn about managers
|
||||
> and workers, refer to the [Swarm mode section](https://docs.docker.com/engine/swarm/)
|
||||
> in the documentation.
|
||||
usage: docker stack deploy [OPTIONS] STACK
|
||||
pname: docker stack
|
||||
plink: docker_stack.yaml
|
||||
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
|
||||
shorthand: c
|
||||
value_type: stringSlice
|
||||
|
|
@ -143,6 +155,34 @@ examples: |-
|
|||
9gc5m4met4he vossibility_logstash replicated 1/1 logstash@sha256:2dc8bddd1bb4a5a34e8ebaf73749f6413c101b2edef6617f2f7713926d2141fe
|
||||
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
|
||||
min_api_version: "1.25"
|
||||
experimental: false
|
||||
|
|
|
|||
|
|
@ -1,7 +1,13 @@
|
|||
command: docker stack ls
|
||||
aliases: list
|
||||
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]
|
||||
pname: docker stack
|
||||
plink: docker_stack.yaml
|
||||
|
|
|
|||
|
|
@ -1,8 +1,12 @@
|
|||
command: docker stack ps
|
||||
short: List the tasks in the stack
|
||||
long: |-
|
||||
Lists the tasks that are running as part of the specified stack. This
|
||||
command has to be run targeting a manager node.
|
||||
Lists the tasks that are running as part of the specified stack.
|
||||
|
||||
> **Note**: This is a cluster management command. When using swarm as an orchestrator,
|
||||
> this command must be executed on a swarm manager node. To learn about managers
|
||||
> and workers, refer to the [Swarm mode section](https://docs.docker.com/engine/swarm/)
|
||||
> in the documentation.
|
||||
usage: docker stack ps [OPTIONS] STACK
|
||||
pname: docker stack
|
||||
plink: docker_stack.yaml
|
||||
|
|
|
|||
|
|
@ -2,8 +2,12 @@ command: docker stack rm
|
|||
aliases: remove, down
|
||||
short: Remove one or more stacks
|
||||
long: |-
|
||||
Remove the stack from the swarm. This command has to be run targeting
|
||||
a manager node.
|
||||
Remove the stack from the swarm.
|
||||
|
||||
> **Note**: This is a cluster management command. When using swarm as an orchestrator,
|
||||
> this command must be executed on a swarm manager node. To learn about managers
|
||||
> and workers, refer to the [Swarm mode section](https://docs.docker.com/engine/swarm/)
|
||||
> in the documentation.
|
||||
usage: docker stack rm [OPTIONS] STACK [STACK...]
|
||||
pname: docker stack
|
||||
plink: docker_stack.yaml
|
||||
|
|
|
|||
|
|
@ -1,8 +1,12 @@
|
|||
command: docker stack services
|
||||
short: List the services in the stack
|
||||
long: |-
|
||||
Lists the services that are running as part of the specified stack. This
|
||||
command has to be run targeting a manager node.
|
||||
Lists the services that are running as part of the specified stack.
|
||||
|
||||
> **Note**: This is a cluster management command. When using swarm as an orchestrator,
|
||||
> this command must be executed on a swarm manager node. To learn about managers
|
||||
> and workers, refer to the [Swarm mode section](https://docs.docker.com/engine/swarm/)
|
||||
> in the documentation.
|
||||
usage: docker stack services [OPTIONS] STACK
|
||||
pname: docker stack
|
||||
plink: docker_stack.yaml
|
||||
|
|
|
|||
|
|
@ -1,7 +1,11 @@
|
|||
command: docker swarm ca
|
||||
short: Display and rotate the root CA
|
||||
long: View or rotate the current swarm CA certificate. This command must target a
|
||||
manager node.
|
||||
long: |-
|
||||
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]
|
||||
pname: docker swarm
|
||||
plink: docker_swarm.yaml
|
||||
|
|
|
|||
|
|
@ -5,6 +5,10 @@ long: |-
|
|||
used to reactivate a manager after its Docker daemon restarts if the autolock
|
||||
setting is turned on. The unlock key is printed at the time when autolock is
|
||||
enabled, and is also available from the `docker swarm unlock-key` command.
|
||||
|
||||
> **Note**: This is a cluster management command, and must be executed on a swarm
|
||||
> manager node. To learn about managers and workers, refer to the [Swarm mode
|
||||
> section](https://docs.docker.com/engine/swarm/) in the documentation.
|
||||
usage: docker swarm unlock
|
||||
pname: docker swarm
|
||||
plink: docker_swarm.yaml
|
||||
|
|
|
|||
|
|
@ -1,7 +1,11 @@
|
|||
command: docker swarm update
|
||||
short: Update the swarm
|
||||
long: Updates a swarm with new parameter values. This command must target a manager
|
||||
node.
|
||||
long: |-
|
||||
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]
|
||||
pname: docker swarm
|
||||
plink: docker_swarm.yaml
|
||||
|
|
|
|||
|
|
@ -2,10 +2,10 @@ command: docker unpause
|
|||
short: Unpause all processes within one or more containers
|
||||
long: |-
|
||||
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
|
||||
[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.
|
||||
usage: docker unpause CONTAINER [CONTAINER...]
|
||||
pname: docker
|
||||
|
|
|
|||
Loading…
Reference in New Issue