diff --git a/_data/engine-cli/docker_build.yaml b/_data/engine-cli/docker_build.yaml index 0e273252aa..89ff5275ce 100644 --- a/_data/engine-cli/docker_build.yaml +++ b/_data/engine-cli/docker_build.yaml @@ -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 diff --git a/_data/engine-cli/docker_container_rm.yaml b/_data/engine-cli/docker_container_rm.yaml index 0dbfa786f0..cce60569f6 100644 --- a/_data/engine-cli/docker_container_rm.yaml +++ b/_data/engine-cli/docker_container_rm.yaml @@ -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 diff --git a/_data/engine-cli/docker_events.yaml b/_data/engine-cli/docker_events.yaml index 080b082ca2..db0cc0a625 100644 --- a/_data/engine-cli/docker_events.yaml +++ b/_data/engine-cli/docker_events.yaml @@ -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=`) - * container (`container=`) - * daemon (`daemon=`) - * event (`event=`) - * image (`image=`) - * label (`label=` or `label==`) - * network (`network=`) - * node (`node=`) - * plugin (`plugin=`) - * scope (`scope=`) - * secret (`secret=`) - * service (`service=`) - * type (`type=`) - * volume (`volume=`) - - #### 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=`)\n* + container (`container=`)\n* daemon (`daemon=`)\n* event + (`event=`)\n* image (`image=`)\n* label (`label=` + or `label==`)\n* network (`network=`)\n* node (`node=`)\n* + plugin (`plugin=`)\n* scope (`scope=`)\n* secret (`secret=`)\n* service (`service=`)\n* type (`type=`)\n* + volume (`volume=`)\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 diff --git a/_data/engine-cli/docker_network_create.yaml b/_data/engine-cli/docker_network_create.yaml index 07cf13114b..4b5b086399 100644 --- a/_data/engine-cli/docker_network_create.yaml +++ b/_data/engine-cli/docker_network_create.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 ``` diff --git a/_data/engine-cli/docker_node_demote.yaml b/_data/engine-cli/docker_node_demote.yaml index 9d671e42a4..2194a100c8 100644 --- a/_data/engine-cli/docker_node_demote.yaml +++ b/_data/engine-cli/docker_node_demote.yaml @@ -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 diff --git a/_data/engine-cli/docker_node_inspect.yaml b/_data/engine-cli/docker_node_inspect.yaml index d0790e0617..3bd1f1dde5 100644 --- a/_data/engine-cli/docker_node_inspect.yaml +++ b/_data/engine-cli/docker_node_inspect.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 diff --git a/_data/engine-cli/docker_node_ls.yaml b/_data/engine-cli/docker_node_ls.yaml index 6e36337428..776309ae7d 100644 --- a/_data/engine-cli/docker_node_ls.yaml +++ b/_data/engine-cli/docker_node_ls.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 diff --git a/_data/engine-cli/docker_node_promote.yaml b/_data/engine-cli/docker_node_promote.yaml index d5dd2338aa..4b8c876104 100644 --- a/_data/engine-cli/docker_node_promote.yaml +++ b/_data/engine-cli/docker_node_promote.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 diff --git a/_data/engine-cli/docker_node_ps.yaml b/_data/engine-cli/docker_node_ps.yaml index f363e13e5e..f763c27525 100644 --- a/_data/engine-cli/docker_node_ps.yaml +++ b/_data/engine-cli/docker_node_ps.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 diff --git a/_data/engine-cli/docker_node_rm.yaml b/_data/engine-cli/docker_node_rm.yaml index 7133baa84e..d0abdd8477 100644 --- a/_data/engine-cli/docker_node_rm.yaml +++ b/_data/engine-cli/docker_node_rm.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 diff --git a/_data/engine-cli/docker_node_update.yaml b/_data/engine-cli/docker_node_update.yaml index a5ba4451fd..27befb40c3 100644 --- a/_data/engine-cli/docker_node_update.yaml +++ b/_data/engine-cli/docker_node_update.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 diff --git a/_data/engine-cli/docker_pause.yaml b/_data/engine-cli/docker_pause.yaml index 49714e66c0..b99213ce7d 100644 --- a/_data/engine-cli/docker_pause.yaml +++ b/_data/engine-cli/docker_pause.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 diff --git a/_data/engine-cli/docker_ps.yaml b/_data/engine-cli/docker_ps.yaml index 248e20a8aa..f3edd98ad0 100644 --- a/_data/engine-cli/docker_ps.yaml +++ b/_data/engine-cli/docker_ps.yaml @@ -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 `` or `=` | - | `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 `[:]`, ``, or `` | - | `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 `[/]` or `/[]` | - | `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 `` or `=` |\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 `[:]`, + \ ``, or `` |\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 `[/]` or `/[]` |\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 diff --git a/_data/engine-cli/docker_rm.yaml b/_data/engine-cli/docker_rm.yaml index 889a62aca8..c1d136a748 100644 --- a/_data/engine-cli/docker_rm.yaml +++ b/_data/engine-cli/docker_rm.yaml @@ -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 diff --git a/_data/engine-cli/docker_run.yaml b/_data/engine-cli/docker_run.yaml index 5ef06961f2..e316cdd269 100644 --- a/_data/engine-cli/docker_run.yaml +++ b/_data/engine-cli/docker_run.yaml @@ -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 + diff --git a/_data/engine-cli/docker_search.yaml b/_data/engine-cli/docker_search.yaml index 1244637a86..0087899e0a 100644 --- a/_data/engine-cli/docker_search.yaml +++ b/_data/engine-cli/docker_search.yaml @@ -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 diff --git a/_data/engine-cli/docker_secret_create.yaml b/_data/engine-cli/docker_secret_create.yaml index a7f3000a98..c69a6cbda0 100644 --- a/_data/engine-cli/docker_secret_create.yaml +++ b/_data/engine-cli/docker_secret_create.yaml @@ -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 diff --git a/_data/engine-cli/docker_secret_inspect.yaml b/_data/engine-cli/docker_secret_inspect.yaml index e0b3a6c01a..7699168eab 100644 --- a/_data/engine-cli/docker_secret_inspect.yaml +++ b/_data/engine-cli/docker_secret_inspect.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 diff --git a/_data/engine-cli/docker_secret_ls.yaml b/_data/engine-cli/docker_secret_ls.yaml index 9fba65db2f..7b99885cca 100644 --- a/_data/engine-cli/docker_secret_ls.yaml +++ b/_data/engine-cli/docker_secret_ls.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 diff --git a/_data/engine-cli/docker_secret_rm.yaml b/_data/engine-cli/docker_secret_rm.yaml index 1f5f500508..3b0e9db122 100644 --- a/_data/engine-cli/docker_secret_rm.yaml +++ b/_data/engine-cli/docker_secret_rm.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 diff --git a/_data/engine-cli/docker_service.yaml b/_data/engine-cli/docker_service.yaml index 918bd3b6b9..7ceb8cac18 100644 --- a/_data/engine-cli/docker_service.yaml +++ b/_data/engine-cli/docker_service.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 diff --git a/_data/engine-cli/docker_service_create.yaml b/_data/engine-cli/docker_service_create.yaml index 1c5ddd65d4..b356daa67b 100644 --- a/_data/engine-cli/docker_service_create.yaml +++ b/_data/engine-cli/docker_service_create.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.\n \n \n \n\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\n \n \n - \ \n \n \n \n \n - \ \n \n \n \n - \ \n \n \n - \ \n \n \n \n \n - \ \n \n \n \n - \ \n \n \n \n - \ \n \n \n
node attributematchesexample
node.idNode IDnode.id==2ivku8v2gvtg4
node.hostnameNode hostnamenode.hostname!=node-2
node.roleNode rolenode.role==manager
node.labelsuser defined node labelsnode.labels.security==high
engine.labelsDocker Engine's labelsengine.labels.operatingsystem==ubuntu - 14.04
\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: diff --git a/_data/engine-cli/docker_service_inspect.yaml b/_data/engine-cli/docker_service_inspect.yaml index 98bd4741b5..c770d4fccd 100644 --- a/_data/engine-cli/docker_service_inspect.yaml +++ b/_data/engine-cli/docker_service_inspect.yaml @@ -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 diff --git a/_data/engine-cli/docker_service_logs.yaml b/_data/engine-cli/docker_service_logs.yaml index d6a75a07bb..efc6fb7c52 100644 --- a/_data/engine-cli/docker_service_logs.yaml +++ b/_data/engine-cli/docker_service_logs.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 diff --git a/_data/engine-cli/docker_service_ls.yaml b/_data/engine-cli/docker_service_ls.yaml index 0407b5088f..3a44e8eb7f 100644 --- a/_data/engine-cli/docker_service_ls.yaml +++ b/_data/engine-cli/docker_service_ls.yaml @@ -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 diff --git a/_data/engine-cli/docker_service_ps.yaml b/_data/engine-cli/docker_service_ps.yaml index 1b61790b9d..6cd68235d0 100644 --- a/_data/engine-cli/docker_service_ps.yaml +++ b/_data/engine-cli/docker_service_ps.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 diff --git a/_data/engine-cli/docker_service_rm.yaml b/_data/engine-cli/docker_service_rm.yaml index 8d1e623d94..bdea2fc71b 100644 --- a/_data/engine-cli/docker_service_rm.yaml +++ b/_data/engine-cli/docker_service_rm.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 diff --git a/_data/engine-cli/docker_service_rollback.yaml b/_data/engine-cli/docker_service_rollback.yaml index 29e80c391e..987e183de0 100644 --- a/_data/engine-cli/docker_service_rollback.yaml +++ b/_data/engine-cli/docker_service_rollback.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 diff --git a/_data/engine-cli/docker_service_scale.yaml b/_data/engine-cli/docker_service_scale.yaml index f1208dbc24..f9c045f35a 100644 --- a/_data/engine-cli/docker_service_scale.yaml +++ b/_data/engine-cli/docker_service_scale.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 diff --git a/_data/engine-cli/docker_service_update.yaml b/_data/engine-cli/docker_service_update.yaml index 30c68c27cb..3cdb9ca452 100644 --- a/_data/engine-cli/docker_service_update.yaml +++ b/_data/engine-cli/docker_service_update.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 diff --git a/_data/engine-cli/docker_stack_deploy.yaml b/_data/engine-cli/docker_stack_deploy.yaml index 5f30bad704..ed7fcfee71 100644 --- a/_data/engine-cli/docker_stack_deploy.yaml +++ b/_data/engine-cli/docker_stack_deploy.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 diff --git a/_data/engine-cli/docker_stack_ls.yaml b/_data/engine-cli/docker_stack_ls.yaml index 6e72b6f387..a87057d575 100644 --- a/_data/engine-cli/docker_stack_ls.yaml +++ b/_data/engine-cli/docker_stack_ls.yaml @@ -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 diff --git a/_data/engine-cli/docker_stack_ps.yaml b/_data/engine-cli/docker_stack_ps.yaml index 0a07725782..50e6ca8803 100644 --- a/_data/engine-cli/docker_stack_ps.yaml +++ b/_data/engine-cli/docker_stack_ps.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 diff --git a/_data/engine-cli/docker_stack_rm.yaml b/_data/engine-cli/docker_stack_rm.yaml index 921809b5fa..15a6816800 100644 --- a/_data/engine-cli/docker_stack_rm.yaml +++ b/_data/engine-cli/docker_stack_rm.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 diff --git a/_data/engine-cli/docker_stack_services.yaml b/_data/engine-cli/docker_stack_services.yaml index 3c12920444..a53175666e 100644 --- a/_data/engine-cli/docker_stack_services.yaml +++ b/_data/engine-cli/docker_stack_services.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 diff --git a/_data/engine-cli/docker_swarm_ca.yaml b/_data/engine-cli/docker_swarm_ca.yaml index c4f4cac7dd..01ae67373b 100644 --- a/_data/engine-cli/docker_swarm_ca.yaml +++ b/_data/engine-cli/docker_swarm_ca.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 diff --git a/_data/engine-cli/docker_swarm_unlock.yaml b/_data/engine-cli/docker_swarm_unlock.yaml index 1c35a0d596..bf9aaf5a4b 100644 --- a/_data/engine-cli/docker_swarm_unlock.yaml +++ b/_data/engine-cli/docker_swarm_unlock.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 diff --git a/_data/engine-cli/docker_swarm_update.yaml b/_data/engine-cli/docker_swarm_update.yaml index b0dcdd2815..558076f2c3 100644 --- a/_data/engine-cli/docker_swarm_update.yaml +++ b/_data/engine-cli/docker_swarm_update.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 diff --git a/_data/engine-cli/docker_unpause.yaml b/_data/engine-cli/docker_unpause.yaml index 284bd5f2e9..a1221d2768 100644 --- a/_data/engine-cli/docker_unpause.yaml +++ b/_data/engine-cli/docker_unpause.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