mirror of https://github.com/docker/cli.git
Merge pull request #4715 from craig-osterhout/freshness-q4
docs: fix typos and update formatting
This commit is contained in:
commit
50ad446a68
|
@ -16,7 +16,7 @@ Remove unused images
|
|||
|
||||
## Description
|
||||
|
||||
Remove all dangling images. If `-a` is specified, will also remove all images not referenced by any container.
|
||||
Remove all dangling images. If `-a` is specified, also remove all images not referenced by any container.
|
||||
|
||||
## Examples
|
||||
|
||||
|
@ -89,10 +89,10 @@ images without the specified labels.
|
|||
> same filtering syntax to see which images match your filter.
|
||||
>
|
||||
> However, if you are using negative filtering (testing for the absence of a
|
||||
> label or that a label does *not* have a specific value), this type of filter
|
||||
> does not work with `docker image ls` so you cannot easily predict which images
|
||||
> label or that a label doesn't have a specific value), this type of filter
|
||||
> doesn't work with `docker image ls` so you cannot easily predict which images
|
||||
> will be removed. In addition, the confirmation prompt for `docker image prune`
|
||||
> always warns that *all* dangling images will be removed, even if you are using
|
||||
> always warns that all dangling images will be removed, even if you are using
|
||||
> `--filter`.
|
||||
|
||||
The following removes images created before `2017-01-04T00:00:00`:
|
||||
|
@ -190,7 +190,7 @@ $ docker image prune --filter="label!=maintainer=john"
|
|||
>
|
||||
> You are prompted for confirmation before the `prune` removes
|
||||
> anything, but you are not shown a list of what will potentially be removed.
|
||||
> In addition, `docker image ls` does not support negative filtering, so it
|
||||
> In addition, `docker image ls` doesn't support negative filtering, so it
|
||||
> difficult to predict what images will actually be removed.
|
||||
|
||||
## Related commands
|
||||
|
|
|
@ -65,7 +65,7 @@ that restricts the list to images that match the argument. If you specify
|
|||
`REPOSITORY`but no `TAG`, the `docker images` command lists all images in the
|
||||
given repository.
|
||||
|
||||
For example, to list all images in the "java" repository, run this command :
|
||||
For example, to list all images in the `java` repository, run the following command:
|
||||
|
||||
```console
|
||||
$ docker images java
|
||||
|
@ -76,12 +76,12 @@ java 7 493d82594c15 3 months ago
|
|||
java latest 2711b1d6f3aa 5 months ago 603.9 MB
|
||||
```
|
||||
|
||||
The `[REPOSITORY[:TAG]]` value must be an "exact match". This means that, for example,
|
||||
The `[REPOSITORY[:TAG]]` value must be an exact match. This means that, for example,
|
||||
`docker images jav` does not match the image `java`.
|
||||
|
||||
If both `REPOSITORY` and `TAG` are provided, only images matching that
|
||||
repository and tag are listed. To find all local images in the "java"
|
||||
repository with tag "8" you can use:
|
||||
repository and tag are listed. To find all local images in the `java`
|
||||
repository with tag `8` you can use:
|
||||
|
||||
```console
|
||||
$ docker images java:8
|
||||
|
@ -136,7 +136,7 @@ also reference by digest in `create`, `run`, and `rmi` commands, as well as the
|
|||
### <a name="filter"></a> Filtering (--filter)
|
||||
|
||||
The filtering flag (`-f` or `--filter`) format is of "key=value". If there is more
|
||||
than one filter, then pass multiple flags (e.g., `--filter "foo=bar" --filter "bif=baz"`)
|
||||
than one filter, then pass multiple flags (e.g., `--filter "foo=bar" --filter "bif=baz"`).
|
||||
|
||||
The currently supported filters are:
|
||||
|
||||
|
@ -166,7 +166,7 @@ intermediary layers). These images occur when a new build of an image takes the
|
|||
A warning will be issued if trying to remove an image when a container is presently
|
||||
using it. By having this flag it allows for batch cleanup.
|
||||
|
||||
You can use this in conjunction with `docker rmi ...`:
|
||||
You can use this in conjunction with `docker rmi`:
|
||||
|
||||
```console
|
||||
$ docker rmi $(docker images -f "dangling=true" -q)
|
||||
|
@ -216,7 +216,7 @@ REPOSITORY TAG IMAGE ID CREATED
|
|||
#### Filter images by time
|
||||
|
||||
The `before` filter shows only images created before the image with
|
||||
given id or reference. For example, having these images:
|
||||
a given ID or reference. For example, having these images:
|
||||
|
||||
```console
|
||||
$ docker images
|
||||
|
|
|
@ -38,7 +38,7 @@ exist with the same name, making the result ambiguous.
|
|||
To restrict `docker inspect` to a specific type of object, use the `--type`
|
||||
option.
|
||||
|
||||
The following example inspects a _volume_ named "myvolume"
|
||||
The following example inspects a volume named `myvolume`.
|
||||
|
||||
```console
|
||||
$ docker inspect --type=volume myvolume
|
||||
|
@ -117,7 +117,7 @@ the template language's `index` function does. The `.NetworkSettings.Ports`
|
|||
section contains a map of the internal port mappings to a list of external
|
||||
address/port objects. To grab just the numeric public port, you use `index` to
|
||||
find the specific port map, and then `index` 0 contains the first object inside
|
||||
of that. Then we ask for the `HostPort` field to get the public address.
|
||||
of that. Then, specify the `HostPort` field to get the public address.
|
||||
|
||||
```console
|
||||
$ docker inspect --format='{{(index (index .NetworkSettings.Ports "8787/tcp") 0).HostPort}}' $INSTANCE_ID
|
||||
|
|
|
@ -17,13 +17,13 @@ If no server is specified, the default is defined by the daemon.
|
|||
|
||||
## Description
|
||||
|
||||
Login to a registry.
|
||||
Log in to a registry.
|
||||
|
||||
## Examples
|
||||
|
||||
### Login to a self-hosted registry
|
||||
|
||||
If you want to login to a self-hosted registry you can specify this by
|
||||
If you want to log in to a self-hosted registry you can specify this by
|
||||
adding the server name.
|
||||
|
||||
```console
|
||||
|
@ -46,12 +46,12 @@ $ cat ~/my_password.txt | docker login --username foo --password-stdin
|
|||
|
||||
### Privileged user requirement
|
||||
|
||||
`docker login` requires user to use `sudo` or be `root`, except when:
|
||||
`docker login` requires you to use `sudo` or be `root`, except when:
|
||||
|
||||
1. connecting to a remote daemon, such as a `docker-machine` provisioned `docker engine`.
|
||||
2. user is added to the `docker` group. This will impact the security of your system; the `docker` group is `root` equivalent. See [Docker Daemon Attack Surface](https://docs.docker.com/engine/security/#docker-daemon-attack-surface) for details.
|
||||
- Connecting to a remote daemon, such as a `docker-machine` provisioned `docker engine`.
|
||||
- The user is added to the `docker` group. This will impact the security of your system; the `docker` group is `root` equivalent. See [Docker Daemon Attack Surface](https://docs.docker.com/engine/security/#docker-daemon-attack-surface) for details.
|
||||
|
||||
You can log into any public or private repository for which you have
|
||||
You can log in to any public or private repository for which you have
|
||||
credentials. When you log in, the command stores credentials in
|
||||
`$HOME/.docker/config.json` on Linux or `%USERPROFILE%/.docker/config.json` on
|
||||
Windows, via the procedure described below.
|
||||
|
@ -78,7 +78,7 @@ Helpers are available for the following credential stores:
|
|||
#### Configure the credential store
|
||||
|
||||
You need to specify the credential store in `$HOME/.docker/config.json`
|
||||
to tell the docker engine to use it. The value of the config property should be
|
||||
to tell the Docker Engine to use it. The value of the config property should be
|
||||
the suffix of the program to use (i.e. everything after `docker-credential-`).
|
||||
For example, to use `docker-credential-osxkeychain`:
|
||||
|
||||
|
@ -123,11 +123,11 @@ or an identity token.
|
|||
If the secret being stored is an identity token, the Username should be set to
|
||||
`<token>`.
|
||||
|
||||
The `store` command can write error messages to `STDOUT` that the docker engine
|
||||
The `store` command can write error messages to `STDOUT` that the Docker Engine
|
||||
will show if there was an issue.
|
||||
|
||||
The `get` command takes a string payload from the standard input. That payload carries
|
||||
the server address that the docker engine needs credentials for. This is
|
||||
the server address that the Docker Engine needs credentials for. This is
|
||||
an example of that payload: `https://index.docker.io/v1`.
|
||||
|
||||
The `get` command writes a JSON payload to `STDOUT`. Docker reads the user name
|
||||
|
@ -141,16 +141,16 @@ and password from this payload:
|
|||
```
|
||||
|
||||
The `erase` command takes a string payload from `STDIN`. That payload carries
|
||||
the server address that the docker engine wants to remove credentials for. This is
|
||||
the server address that the Docker Engine wants to remove credentials for. This is
|
||||
an example of that payload: `https://index.docker.io/v1`.
|
||||
|
||||
The `erase` command can write error messages to `STDOUT` that the docker engine
|
||||
The `erase` command can write error messages to `STDOUT` that the Docker Engine
|
||||
will show if there was an issue.
|
||||
|
||||
### Credential helpers
|
||||
|
||||
Credential helpers are similar to the credential store above, but act as the
|
||||
designated programs to handle credentials for *specific registries*. The default
|
||||
designated programs to handle credentials for specific registries. The default
|
||||
credential store (`credsStore` or the config file itself) will not be used for
|
||||
operations concerning credentials of the specified registries.
|
||||
|
||||
|
|
|
@ -33,9 +33,9 @@ For full details on using docker manifest lists, see the registry v2 specificati
|
|||
The `docker manifest` command by itself performs no action. In order to operate
|
||||
on a manifest or manifest list, one of the subcommands must be used.
|
||||
|
||||
A single manifest is information about an image, such as layers, size, and digest.
|
||||
The docker manifest command also gives users additional information such as the os
|
||||
and architecture an image was built for.
|
||||
A single manifest is information about an image, such as layers, size, and
|
||||
digest. The `docker manifest` command also gives you additional information,
|
||||
such as the OS and architecture an image was built for.
|
||||
|
||||
A manifest list is a list of image layers that is created by specifying one or
|
||||
more (ideally more than one) image names. It can then be used in the same way as
|
||||
|
@ -44,7 +44,7 @@ an image name in `docker pull` and `docker run` commands, for example.
|
|||
Ideally a manifest list is created from images that are identical in function for
|
||||
different os/arch combinations. For this reason, manifest lists are often referred
|
||||
to as "multi-arch images". However, a user could create a manifest list that points
|
||||
to two images -- one for windows on amd64, and one for darwin on amd64.
|
||||
to two images -- one for Windows on AMD64, and one for Darwin on AMD64.
|
||||
|
||||
### manifest inspect
|
||||
|
||||
|
@ -143,10 +143,10 @@ $ docker manifest inspect hello-world
|
|||
|
||||
### Inspect an image's manifest and get the os/arch info
|
||||
|
||||
The `docker manifest inspect` command takes an optional `--verbose` flag
|
||||
that gives you the image's name (Ref), and architecture and os (Platform).
|
||||
The `docker manifest inspect` command takes an optional `--verbose` flag that
|
||||
gives you the image's name (Ref), as well as the architecture and OS (Platform).
|
||||
|
||||
Just as with other docker commands that take image names, you can refer to an image with or
|
||||
Just as with other Docker commands that take image names, you can refer to an image with or
|
||||
without a tag, or by digest (e.g. `hello-world@sha256:f3b3b28a45160805bb16542c9531888519430e9e6d6ffc09d72261b0d26ff74f`).
|
||||
|
||||
Here is an example of inspecting an image's manifest with the `--verbose` flag:
|
||||
|
|
|
@ -50,7 +50,7 @@ $ docker network connect --ip 10.10.36.122 multi-host-network container2
|
|||
|
||||
### <a name="link"></a> Use the legacy `--link` option (--link)
|
||||
|
||||
You can use `--link` option to link another container with a preferred alias
|
||||
You can use `--link` option to link another container with a preferred alias.
|
||||
|
||||
```console
|
||||
$ docker network connect --link container1:c1 multi-host-network container2
|
||||
|
|
|
@ -34,7 +34,7 @@ built-in network drivers. If you have installed a third party or your own custom
|
|||
network driver you can specify that `DRIVER` here also. If you don't specify the
|
||||
`--driver` option, the command automatically creates a `bridge` network for you.
|
||||
When you install Docker Engine it creates a `bridge` network automatically. This
|
||||
network corresponds to the `docker0` bridge that Engine has traditionally relied
|
||||
network corresponds to the `docker0` bridge that Docker Engine has traditionally relied
|
||||
on. When you launch a new container with `docker run` it automatically connects to
|
||||
this bridge network. You cannot remove this default bridge network, but you can
|
||||
create new ones using the `network create` command.
|
||||
|
@ -43,8 +43,8 @@ create new ones using the `network create` command.
|
|||
$ docker network create -d bridge my-bridge-network
|
||||
```
|
||||
|
||||
Bridge networks are isolated networks on a single Engine installation. If you
|
||||
want to create a network that spans multiple Docker hosts each running an
|
||||
Bridge networks are isolated networks on a single Docker Engine installation. If you
|
||||
want to create a network that spans multiple Docker hosts each running Docker
|
||||
Engine, you must enable Swarm mode, and create an `overlay` network. To read more
|
||||
about overlay networks with Swarm mode, see ["*use overlay networks*"](https://docs.docker.com/network/overlay/).
|
||||
|
||||
|
@ -97,17 +97,17 @@ You can connect multiple containers to the same network. Once connected, the
|
|||
containers can communicate using only another container's IP address or name.
|
||||
For `overlay` networks or custom plugins that support multi-host connectivity,
|
||||
containers connected to the same multi-host network but launched from different
|
||||
Engines can also communicate in this way.
|
||||
daemons can also communicate in this way.
|
||||
|
||||
You can disconnect a container from a network using the `docker network
|
||||
disconnect` command.
|
||||
|
||||
### Specify advanced options
|
||||
|
||||
When you create a network, Engine creates a non-overlapping subnetwork for the
|
||||
network by default. This subnetwork is not a subdivision of an existing network.
|
||||
It is purely for ip-addressing purposes. You can override this default and
|
||||
specify subnetwork values directly using the `--subnet` option. On a
|
||||
When you create a network, Docker Engine creates a non-overlapping subnetwork
|
||||
for the network by default. This subnetwork is not a subdivision of an existing
|
||||
network. It is purely for ip-addressing purposes. You can override this default
|
||||
and specify subnetwork values directly using the `--subnet` option. On a
|
||||
`bridge` network you can only create a single subnet:
|
||||
|
||||
```console
|
||||
|
@ -126,8 +126,8 @@ $ docker network create \
|
|||
br0
|
||||
```
|
||||
|
||||
If you omit the `--gateway` flag the Engine selects one for you from inside a
|
||||
preferred pool. For `overlay` networks and for network driver plugins that
|
||||
If you omit the `--gateway` flag, Docker Engine selects one for you from inside
|
||||
a preferred pool. For `overlay` networks and for network driver plugins that
|
||||
support it you can create multiple subnetworks. This example uses two `/25`
|
||||
subnet mask to adhere to the current guidance of not having more than 256 IPs in
|
||||
a single overlay network. Each of the subnetworks has 126 usable addresses.
|
||||
|
@ -144,13 +144,13 @@ $ docker network create -d overlay \
|
|||
```
|
||||
|
||||
Be sure that your subnetworks do not overlap. If they do, the network create
|
||||
fails and Engine returns an error.
|
||||
fails and Docker Engine returns an error.
|
||||
|
||||
### Bridge driver options
|
||||
|
||||
When creating a custom network, the default network driver (i.e. `bridge`) has
|
||||
additional options that can be passed. The following are those options and the
|
||||
equivalent docker daemon flags used for docker0 bridge:
|
||||
equivalent Docker daemon flags used for docker0 bridge:
|
||||
|
||||
| Option | Equivalent | Description |
|
||||
|--------------------------------------------------|-------------|-------------------------------------------------------|
|
||||
|
@ -207,7 +207,7 @@ $ docker network create -d overlay \
|
|||
|
||||
### Run services on predefined networks
|
||||
|
||||
You can create services on the predefined docker networks `bridge` and `host`.
|
||||
You can create services on the predefined Docker networks `bridge` and `host`.
|
||||
|
||||
```console
|
||||
$ docker service create --name my-service \
|
||||
|
|
|
@ -44,8 +44,9 @@ redis.10.0tgctg8h8cech4w0k0gwrmr23 redis:3.0.6 swarm-manager1 Running
|
|||
|
||||
### <a name="filter"></a> Filtering (--filter)
|
||||
|
||||
The filtering flag (`-f` or `--filter`) format is of "key=value". If there is more
|
||||
than one filter, then pass multiple flags (e.g., `--filter "foo=bar" --filter "bif=baz"`)
|
||||
The filtering flag (`-f` or `--filter`) format is of "key=value". If there is
|
||||
more than one filter, then pass multiple flags (e.g., `--filter "foo=bar"
|
||||
--filter "bif=baz"`).
|
||||
|
||||
The currently supported filters are:
|
||||
|
||||
|
|
|
@ -42,7 +42,7 @@ Node swarm-node-02 removed from swarm
|
|||
Removes the specified nodes from the swarm, but only if the nodes are in the
|
||||
down state. If you attempt to remove an active node you will receive an error:
|
||||
|
||||
```non
|
||||
```console
|
||||
$ docker node rm swarm-node-03
|
||||
|
||||
Error response from daemon: rpc error: code = 9 desc = node swarm-node-03 is not
|
||||
|
|
|
@ -14,8 +14,8 @@ Create a plugin from a rootfs and configuration. Plugin data directory must cont
|
|||
|
||||
## Description
|
||||
|
||||
Creates a plugin. Before creating the plugin, prepare the plugin's root filesystem as well as
|
||||
[the config.json](../../extend/config.md)
|
||||
Creates a plugin. Before creating the plugin, prepare the plugin's root
|
||||
filesystem as well as the [config.json](../../extend/config.md).
|
||||
|
||||
## Examples
|
||||
|
||||
|
|
|
@ -20,7 +20,7 @@ Install a plugin
|
|||
Installs and enables a plugin. Docker looks first for the plugin on your Docker
|
||||
host. If the plugin does not exist locally, then the plugin is pulled from
|
||||
the registry. Note that the minimum required registry version to distribute
|
||||
plugins is 2.3.0
|
||||
plugins is 2.3.0.
|
||||
|
||||
## Examples
|
||||
|
||||
|
|
|
@ -38,7 +38,7 @@ ID NAME DESCRIPTION
|
|||
### <a name="filter"></a> Filtering (--filter)
|
||||
|
||||
The filtering flag (`-f` or `--filter`) format is of "key=value". If there is more
|
||||
than one filter, then pass multiple flags (e.g., `--filter "foo=bar" --filter "bif=baz"`)
|
||||
than one filter, then pass multiple flags (e.g., `--filter "foo=bar" --filter "bif=baz"`).
|
||||
|
||||
The currently supported filters are:
|
||||
|
||||
|
|
|
@ -20,8 +20,8 @@ Remove one or more plugins
|
|||
|
||||
Removes a plugin. You cannot remove a plugin if it is enabled, you must disable
|
||||
a plugin using the [`docker plugin disable`](plugin_disable.md) before removing
|
||||
it (or use --force, use of force is not recommended, since it can affect
|
||||
functioning of running containers using the plugin).
|
||||
it, or use `--force`. Use of `--force` is not recommended, since it can affect
|
||||
functioning of running containers using the plugin.
|
||||
|
||||
## Examples
|
||||
|
||||
|
|
|
@ -123,6 +123,7 @@ $ docker plugin inspect -f '{{with $device := index .Settings.Devices 0}}{{$devi
|
|||
```
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> Since only `path` is settable in `mydevice`,
|
||||
> `docker plugins set mydevice=/dev/bar myplugin` would work too.
|
||||
|
||||
|
|
|
@ -70,7 +70,7 @@ For more information, refer to the [container size on disk](https://docs.docker.
|
|||
### <a name="filter"></a> Filtering (--filter)
|
||||
|
||||
The `--filter` (or `-f`) flag 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"`)
|
||||
than one filter, then pass multiple flags (e.g. `--filter "foo=bar" --filter "bif=baz"`).
|
||||
|
||||
The currently supported filters are:
|
||||
|
||||
|
@ -264,7 +264,7 @@ CONTAINER ID IMAGE COMMAND CREATED
|
|||
##### before
|
||||
|
||||
The `before` filter shows only containers created before the container with
|
||||
given id or name. For example, having these containers created:
|
||||
a given ID or name. For example, having these containers created:
|
||||
|
||||
```console
|
||||
$ docker ps
|
||||
|
@ -287,8 +287,8 @@ CONTAINER ID IMAGE COMMAND CREATED STATUS
|
|||
|
||||
##### 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:
|
||||
The `since` filter shows only containers created since the container with a given
|
||||
ID or name. For example, with the same containers as in `before` filter:
|
||||
|
||||
```console
|
||||
$ docker ps -f since=6e63f6ff38b0
|
||||
|
@ -318,7 +318,7 @@ CONTAINER ID MOUNTS
|
|||
#### network
|
||||
|
||||
The `network` filter shows only containers that are connected to a network with
|
||||
a given name or id.
|
||||
a given name or ID.
|
||||
|
||||
The following filter matches all containers that are connected to a network
|
||||
with a name containing `net1`.
|
||||
|
@ -333,9 +333,9 @@ CONTAINER ID IMAGE COMMAND CREATED STATUS
|
|||
9d4893ed80fe ubuntu "top" 10 minutes ago Up 10 minutes test1
|
||||
```
|
||||
|
||||
The network filter matches on both the network's name and id. The following
|
||||
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;
|
||||
the network ID as a filter:
|
||||
|
||||
```console
|
||||
$ docker network inspect --format "{{.ID}}" net1
|
||||
|
|
|
@ -95,7 +95,7 @@ debian latest 4eacea30377a 8 days ago 124MB
|
|||
Docker uses a content-addressable image store, and the image ID is a SHA256
|
||||
digest covering the image's configuration and layers. In the example above,
|
||||
`debian:bookworm` and `debian:latest` have the same image ID because they are
|
||||
the *same* image tagged with different names. Because they are the same image,
|
||||
the same image tagged with different names. Because they are the same image,
|
||||
their layers are stored only once and do not consume extra disk space.
|
||||
|
||||
For more information about images, layers, and the content-addressable store,
|
||||
|
@ -112,7 +112,7 @@ For example, `docker pull ubuntu:22.04` pulls the latest version of the Ubuntu
|
|||
|
||||
In some cases you don't want images to be updated to newer versions, but prefer
|
||||
to use a fixed version of an image. Docker enables you to pull an image by its
|
||||
*digest*. When pulling an image by digest, you specify *exactly* which version
|
||||
digest. When pulling an image by digest, you specify exactly which version
|
||||
of an image to pull. Doing so, allows you to "pin" an image to that version,
|
||||
and guarantee that the image you're using is always the same.
|
||||
|
||||
|
@ -136,7 +136,7 @@ above, the digest of the image is:
|
|||
sha256:26c68657ccce2cb0a31b330cb0be2b5e108d467f641c62e13ab40cbec258c68d
|
||||
```
|
||||
|
||||
Docker also prints the digest of an image when *pushing* to a registry. This
|
||||
Docker also prints the digest of an image when pushing to a registry. This
|
||||
may be useful if you want to pin to a version of the image you just pushed.
|
||||
|
||||
A digest takes the place of the tag when pulling an image, for example, to
|
||||
|
@ -189,7 +189,7 @@ registry is allowed to be accessed over an insecure connection. Refer to the
|
|||
|
||||
### <a name="all-tags"></a> Pull a repository with multiple images (-a, --all-tags)
|
||||
|
||||
By default, `docker pull` pulls a *single* image from the registry. A repository
|
||||
By default, `docker pull` pulls a single image from the registry. A repository
|
||||
can contain multiple images. To pull all images from a repository, provide the
|
||||
`-a` (or `--all-tags`) option when using `docker pull`.
|
||||
|
||||
|
|
|
@ -80,7 +80,7 @@ the `docker rm` command:
|
|||
$ docker rm $(docker ps --filter status=exited -q)
|
||||
```
|
||||
|
||||
Or, using the `xargs` Linux utility;
|
||||
Or, using the `xargs` Linux utility:
|
||||
|
||||
```console
|
||||
$ docker ps --filter status=exited -q | xargs docker rm
|
||||
|
|
|
@ -78,7 +78,7 @@ value is set, the default is set by the daemon.
|
|||
### <a name="filter"></a> Filtering (--filter)
|
||||
|
||||
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 is-official=true --filter stars=3`)
|
||||
than one filter, then pass multiple flags (e.g. `--filter is-official=true --filter stars=3`).
|
||||
|
||||
The currently supported filters are:
|
||||
|
||||
|
|
|
@ -36,7 +36,7 @@ For detailed information about using secrets, refer to [manage sensitive data wi
|
|||
|
||||
### Inspect a secret by name or ID
|
||||
|
||||
You can inspect a secret, either by its *name*, or *ID*
|
||||
You can inspect a secret, either by its name or ID.
|
||||
|
||||
For example, given the following secret:
|
||||
|
||||
|
@ -75,7 +75,7 @@ The output is in JSON format, for example:
|
|||
|
||||
### <a name="format"></a> Format the output (--format)
|
||||
|
||||
You can use the --format option to obtain specific information about a
|
||||
You can use the `--format` option to obtain specific information about a
|
||||
secret. The following example command outputs the creation time of the
|
||||
secret.
|
||||
|
||||
|
|
|
@ -45,7 +45,7 @@ mem02h8n73mybpgqjf0kfi1n0 test_secret 3 seconds ago 3 se
|
|||
### <a name="filter"></a> Filtering (--filter)
|
||||
|
||||
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"`)
|
||||
than one filter, then pass multiple flags (e.g., `--filter "foo=bar" --filter "bif=baz"`).
|
||||
|
||||
The currently supported filters are:
|
||||
|
||||
|
|
|
@ -36,6 +36,7 @@ sapth4csdo5b6wz2p5uimh5xg
|
|||
>
|
||||
> Unlike `docker rm`, this command does not ask for confirmation before removing
|
||||
> a secret.
|
||||
{ .warning }
|
||||
|
||||
|
||||
## Related commands
|
||||
|
|
|
@ -132,7 +132,7 @@ $ docker service create \
|
|||
|
||||
This passes the login token from your local client to the swarm nodes where the
|
||||
service is deployed, using the encrypted WAL logs. With this information, the
|
||||
nodes are able to log into the registry and pull the image.
|
||||
nodes are able to log in to the registry and pull the image.
|
||||
|
||||
### <a name="replicas"></a> Create a service with 5 replica tasks (--replicas)
|
||||
|
||||
|
@ -147,7 +147,7 @@ $ docker service create --name redis --replicas=5 redis:3.0.6
|
|||
|
||||
The above command sets the *desired* number of tasks for the service. Even
|
||||
though the command returns immediately, actual scaling of the service may take
|
||||
some time. The `REPLICAS` column shows both the *actual* and *desired* number
|
||||
some time. The `REPLICAS` column shows both the actual and desired number
|
||||
of replica tasks for the service.
|
||||
|
||||
In the following example the desired state is `5` replicas, but the current
|
||||
|
@ -300,8 +300,8 @@ metadata](https://docs.docker.com/config/labels-custom-metadata/).
|
|||
|
||||
Docker supports three different kinds of mounts, which allow containers to read
|
||||
from or write to files or directories, either on the host operating system, or
|
||||
on memory filesystems. These types are _data volumes_ (often referred to simply
|
||||
as volumes), _bind mounts_, _tmpfs_, and _named pipes_.
|
||||
on memory filesystems. These types are data volumes (often referred to simply
|
||||
as volumes), bind mounts, tmpfs, and named pipes.
|
||||
|
||||
A **bind mount** makes a file or directory on the host available to the
|
||||
container it is mounted within. A bind mount may be either read-only or
|
||||
|
@ -403,7 +403,7 @@ volumes in a service:
|
|||
</tr>
|
||||
</table>
|
||||
|
||||
#### Options for Bind Mounts
|
||||
#### Options for bind mounts
|
||||
|
||||
The following options can only be used for bind mounts (`type=bind`):
|
||||
|
||||
|
|
|
@ -20,7 +20,7 @@ List services
|
|||
|
||||
## Description
|
||||
|
||||
This command lists services are running in the swarm.
|
||||
This command lists services that are running in the swarm.
|
||||
|
||||
> **Note**
|
||||
>
|
||||
|
@ -43,7 +43,7 @@ iwe3278osahj mongo global 7/7 mongo:3.3
|
|||
hh08h9uu8uwr job replicated-job 1/1 (3/5 completed) nginx:latest
|
||||
```
|
||||
|
||||
The `REPLICAS` column shows both the *actual* and *desired* number of tasks for
|
||||
The `REPLICAS` column shows both the actual and desired number of tasks for
|
||||
the service. If the service is in `replicated-job` or `global-job`, it will
|
||||
additionally show the completion status of the job as completed tasks over
|
||||
total tasks the job will execute.
|
||||
|
@ -51,7 +51,7 @@ total tasks the job will execute.
|
|||
### <a name="filter"></a> Filtering (--filter)
|
||||
|
||||
The filtering flag (`-f` or `--filter`) format is of "key=value". If there is more
|
||||
than one filter, then pass multiple flags (e.g., `--filter "foo=bar" --filter "bif=baz"`)
|
||||
than one filter, then pass multiple flags (e.g., `--filter "foo=bar" --filter "bif=baz"`).
|
||||
|
||||
The currently supported filters are:
|
||||
|
||||
|
@ -62,7 +62,7 @@ The currently supported filters are:
|
|||
|
||||
#### id
|
||||
|
||||
The `id` filter matches all or part of a service's id.
|
||||
The `id` filter matches all or part of a service's ID.
|
||||
|
||||
```console
|
||||
$ docker service ls -f "id=0bcjw"
|
||||
|
|
|
@ -49,7 +49,7 @@ bk658fpbex0d redis.2 redis:3.0.5 worker2 Running Running 9 seconds
|
|||
8eaxrb2fqpbn redis.10 redis:3.0.5 manager1 Running Running 8 seconds
|
||||
```
|
||||
|
||||
In addition to _running_ tasks, the output also shows the task history. For
|
||||
In addition to running tasks, the output also shows the task history. For
|
||||
example, after updating the service to use the `redis:3.0.6` image, the output
|
||||
may look like this:
|
||||
|
||||
|
@ -73,10 +73,11 @@ The number of items in the task history is determined by the
|
|||
change the task history retention limit using the
|
||||
[`docker swarm update`](swarm_update.md) command.
|
||||
|
||||
When deploying a service, docker resolves the digest for the service's
|
||||
image, and pins the service to that digest. The digest is not shown by
|
||||
default, but is printed if `--no-trunc` is used. The `--no-trunc` option
|
||||
also shows the non-truncated task ID, and error-messages, as can be seen below;
|
||||
When deploying a service, docker resolves the digest for the service's image,
|
||||
and pins the service to that digest. The digest is not shown by default, but is
|
||||
printed if `--no-trunc` is used. The `--no-trunc` option also shows the
|
||||
non-truncated task ID, and error messages, as can be seen in the following
|
||||
example:
|
||||
|
||||
```console
|
||||
$ docker service ps --no-trunc redis
|
||||
|
|
|
@ -229,7 +229,7 @@ ID NAME MODE REPLICAS IMAGE
|
|||
|
||||
```
|
||||
|
||||
Roll back the `web` service...
|
||||
The following example rolls back the `web` service:
|
||||
|
||||
```console
|
||||
$ docker service update --rollback web
|
||||
|
|
|
@ -21,13 +21,13 @@ Outputs the final Compose file, after doing the merges and interpolations of the
|
|||
|
||||
The following command outputs the result of the merge and interpolation of two Compose files.
|
||||
|
||||
```bash
|
||||
```console
|
||||
$ docker stack config --compose-file docker-compose.yml --compose-file docker-compose.prod.yml
|
||||
```
|
||||
|
||||
The Compose file can also be provided as standard input with `--compose-file -`:
|
||||
|
||||
```bash
|
||||
```console
|
||||
$ cat docker-compose.yml | docker stack config --compose-file -
|
||||
```
|
||||
|
||||
|
@ -38,7 +38,7 @@ For example, when you want to pipe the output of this command back to `stack dep
|
|||
|
||||
If you have a regex for a redirect route in an environment variable for your webserver you would use two `$` signs to prevent `stack deploy` from interpolating `${1}`.
|
||||
|
||||
```bash
|
||||
```yaml
|
||||
service: webserver
|
||||
environment:
|
||||
REDIRECT_REGEX=http://host/redirect/$${1}
|
||||
|
@ -49,7 +49,7 @@ with `REDIRECT_REGEX=http://host/redirect/${1}`, but then when piping it back to
|
|||
command it will be interpolated again and result in undefined behavior.
|
||||
That is why, when piping the output back to `stack deploy` one should always prefer the `--skip-interpolation` option.
|
||||
|
||||
```
|
||||
```console
|
||||
$ docker stack config --compose-file web.yml --compose-file web.prod.yml --skip-interpolation | docker stack deploy --compose-file -
|
||||
```
|
||||
|
||||
|
|
|
@ -34,7 +34,7 @@ Create and update a stack from a `compose` file on the swarm.
|
|||
|
||||
### <a name="compose-file"></a> Compose file (--compose-file)
|
||||
|
||||
The `deploy` command supports compose file version `3.0` and above.
|
||||
The `deploy` command supports Compose file version `3.0` and above.
|
||||
|
||||
```console
|
||||
$ docker stack deploy --compose-file docker-compose.yml vossibility
|
||||
|
|
|
@ -203,7 +203,7 @@ t72q3z038jehe1wbh9gdum076 voting_redis.2 redis:alpine@sha256:9cd405cd1e
|
|||
### <a name="quiet"></a> Only display task IDs (-q, --quiet)
|
||||
|
||||
The `-q ` or `--quiet` option only shows IDs of the tasks in the stack.
|
||||
This example outputs all task IDs of the "voting" stack;
|
||||
This example outputs all task IDs of the `voting` stack:
|
||||
|
||||
```console
|
||||
$ docker stack ps -q voting
|
||||
|
@ -219,7 +219,7 @@ t72q3z038jeh
|
|||
|
||||
This option can be used to perform batch operations. For example, you can use
|
||||
the task IDs as input for other commands, such as `docker inspect`. The
|
||||
following example inspects all tasks of the "voting" stack;
|
||||
following example inspects all tasks of the `voting` stack:
|
||||
|
||||
```console
|
||||
$ docker inspect $(docker stack ps -q voting)
|
||||
|
|
|
@ -85,14 +85,14 @@ b95a83497c91 awesome_brattain 0.28% 5.629MiB / 1.952GiB
|
|||
67b2525d8ad1 foobar 0.00% 1.727MiB / 1.952GiB 0.09% 2.48kB / 0B 4.11MB / 0B 2
|
||||
```
|
||||
|
||||
Running `docker stats` on container with name nginx and getting output in `json` format.
|
||||
Running `docker stats` on container with name `nginx` and getting output in `json` format.
|
||||
|
||||
```console
|
||||
$ docker stats nginx --no-stream --format "{{ json . }}"
|
||||
{"BlockIO":"0B / 13.3kB","CPUPerc":"0.03%","Container":"nginx","ID":"ed37317fbf42","MemPerc":"0.24%","MemUsage":"2.352MiB / 982.5MiB","Name":"nginx","NetIO":"539kB / 606kB","PIDs":"2"}
|
||||
```
|
||||
|
||||
Running `docker stats` with customized format on all (Running and Stopped) containers.
|
||||
Running `docker stats` with customized format on all (running and stopped) containers.
|
||||
|
||||
```console
|
||||
$ docker stats --all --format "table {{.Container}}\t{{.CPUPerc}}\t{{.MemUsage}}" fervent_panini 5acfcb1b4fd1 humble_visvesvaraya big_heisenberg
|
||||
|
|
|
@ -46,7 +46,7 @@ a running container with kernel memory initialized.
|
|||
>
|
||||
> The `docker update` and `docker container update` commands are not supported
|
||||
> for Windows containers.
|
||||
{: .warning }
|
||||
{ .warning }
|
||||
|
||||
## Examples
|
||||
|
||||
|
@ -75,7 +75,7 @@ $ docker update --cpu-shares 512 -m 300M abebf7571666 hopeful_morse
|
|||
You can update a container's kernel memory limit using the `--kernel-memory`
|
||||
option. On kernel version older than 4.6, this option can be updated on a
|
||||
running container only if the container was started with `--kernel-memory`.
|
||||
If the container was started *without* `--kernel-memory` you need to stop
|
||||
If the container was started without `--kernel-memory` you need to stop
|
||||
the container before updating kernel memory.
|
||||
|
||||
> **Note**
|
||||
|
@ -94,7 +94,7 @@ You can update kernel memory while the container is running:
|
|||
$ docker update --kernel-memory 80M test
|
||||
```
|
||||
|
||||
If you started a container *without* kernel memory initialized:
|
||||
If you started a container without kernel memory initialized:
|
||||
|
||||
```console
|
||||
$ docker run -dit --name test2 --memory 300M ubuntu bash
|
||||
|
@ -119,6 +119,6 @@ To update restart policy for one or more containers:
|
|||
$ docker update --restart=on-failure:3 abebf7571666 hopeful_morse
|
||||
```
|
||||
|
||||
Note that if the container is started with "--rm" flag, you cannot update the restart
|
||||
Note that if the container is started with `--rm` flag, you cannot update the restart
|
||||
policy for it. The `AutoRemove` and `RestartPolicy` are mutually exclusive for the
|
||||
container.
|
||||
|
|
|
@ -25,9 +25,9 @@ number of the Docker CLI you are using.
|
|||
### Default output
|
||||
|
||||
The default output renders all version information divided into two sections;
|
||||
the "Client" section contains information about the Docker CLI and client
|
||||
components, and the "Server" section contains information about the Docker
|
||||
Engine and components used by the Engine, such as the "Containerd" and "Runc"
|
||||
the `Client` section contains information about the Docker CLI and client
|
||||
components, and the `Server` section contains information about the Docker
|
||||
Engine and components used by the Docker Engine, such as the containerd and runc
|
||||
OCI Runtimes.
|
||||
|
||||
The information shown may differ depending on how you installed Docker and
|
||||
|
@ -70,10 +70,10 @@ Server: Docker Desktop 4.19.0 (12345)
|
|||
|
||||
Docker uses a client/server architecture, which allows you to use the Docker CLI
|
||||
on your local machine to control a Docker Engine running on a remote machine,
|
||||
which can be (for example) a machine running in the Cloud or inside a Virtual Machine.
|
||||
which can be (for example) a machine running in the cloud or inside a virtual machine.
|
||||
|
||||
The following example switches the Docker CLI to use a [context](context.md)
|
||||
named "remote-test-server", which runs an older version of the Docker Engine
|
||||
named `remote-test-server`, which runs an older version of the Docker Engine
|
||||
on a Linux server:
|
||||
|
||||
```console
|
||||
|
@ -117,7 +117,7 @@ CLI is connecting with. When connecting with the Docker Engine, the Docker CLI
|
|||
and Docker Engine perform API version negotiation, and select the highest API
|
||||
version that is supported by both the Docker CLI and the Docker Engine.
|
||||
|
||||
For example, if the CLI is connecting with a Docker 19.03 engine, it downgrades
|
||||
For example, if the CLI is connecting with Docker Engine version 19.03, it downgrades
|
||||
to API version 1.40 (refer to the [API version matrix](https://docs.docker.com/engine/api/#api-version-matrix)
|
||||
to learn about the supported API versions for Docker Engine):
|
||||
|
||||
|
|
Loading…
Reference in New Issue