mirror of https://github.com/docker/docs.git
vendor: v27.3.1 CLI reference
Signed-off-by: David Karlsson <35727626+dvdksn@users.noreply.github.com>
This commit is contained in:
parent
73856924f7
commit
5a427f8a8f
|
@ -101,8 +101,7 @@ long: |-
|
|||
$ docker run -v /host:/container example/mysql
|
||||
```
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> [!NOTE]
|
||||
> Do not use the `-t` and `-a stderr` options together due to
|
||||
> limitations in the `pty` implementation. All `stderr` in `pty` mode
|
||||
> simply goes to `stdout`.
|
||||
|
@ -162,8 +161,7 @@ long: |-
|
|||
[change the `.docker` directory](#change-the-docker-directory) section to use a
|
||||
different location.
|
||||
|
||||
> **Warning**
|
||||
>
|
||||
> [!WARNING]
|
||||
> The configuration file and other files inside the `~/.docker` configuration
|
||||
> directory may contain sensitive information, such as authentication information
|
||||
> for proxies or, depending on your credential store, credentials for your image
|
||||
|
@ -239,8 +237,7 @@ long: |-
|
|||
[environment variables](#environment-variables) and [HTTP/HTTPS proxy](/engine/daemon/proxy/#httphttps-proxy)
|
||||
sections for configuring proxy settings for the CLI and daemon.
|
||||
|
||||
> **Warning**
|
||||
>
|
||||
> [!WARNING]
|
||||
> Proxy settings may contain sensitive information (for example, if the proxy
|
||||
> requires authentication). Environment variables are stored as plain text in
|
||||
> the container's configuration, and as such can be inspected through the remote
|
||||
|
@ -608,8 +605,7 @@ examples: |-
|
|||
$ docker -H tcp://174.17.0.1:2376 ps
|
||||
```
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> [!NOTE]
|
||||
> By convention, the Docker daemon uses port `2376` for secure TLS connections,
|
||||
> and port `2375` for insecure, non-TLS connections.
|
||||
|
||||
|
|
|
@ -5,8 +5,7 @@ long: |-
|
|||
|
||||
For detailed information about using configs, refer to [store configuration data using Docker Configs](/engine/swarm/configs/).
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> [!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](/engine/swarm/) in the
|
||||
|
|
|
@ -11,8 +11,7 @@ long: |-
|
|||
|
||||
For detailed information about using configs, refer to [store configuration data using Docker Configs](/engine/swarm/configs/).
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> [!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](/engine/swarm/) in the
|
||||
|
|
|
@ -6,8 +6,7 @@ long: |-
|
|||
|
||||
For detailed information about using configs, refer to [store configuration data using Docker Configs](/engine/swarm/configs/).
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> [!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](/engine/swarm/) in the
|
||||
|
|
|
@ -6,8 +6,7 @@ long: |-
|
|||
|
||||
For detailed information about using configs, refer to [store configuration data using Docker Configs](/engine/swarm/configs/).
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> [!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](/engine/swarm/) in the
|
||||
|
@ -34,8 +33,7 @@ examples: |-
|
|||
sapth4csdo5b6wz2p5uimh5xg
|
||||
```
|
||||
|
||||
> **Warning**
|
||||
>
|
||||
> [!WARNING]
|
||||
> This command doesn't ask for confirmation before removing a config.
|
||||
{ .warning }
|
||||
deprecated: false
|
||||
|
|
|
@ -8,8 +8,7 @@ long: |-
|
|||
ID or name. This lets you view its output or control it interactively, as
|
||||
though the commands were running directly in your terminal.
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> [!NOTE]
|
||||
> The `attach` command displays the output of the container's `ENTRYPOINT` and
|
||||
> `CMD` process. This can appear as if the attach command is hung when in fact
|
||||
> the process may simply not be writing any output at that time.
|
||||
|
@ -22,8 +21,7 @@ long: |-
|
|||
the container. If the container was run with `-i` and `-t`, you can detach from
|
||||
a container and leave it running using the `CTRL-p CTRL-q` key sequence.
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> [!NOTE]
|
||||
> A process running as PID 1 inside a container is treated specially by
|
||||
> Linux: it ignores any signal with the default action. So, the process
|
||||
> doesn't terminate on `SIGINT` or `SIGTERM` unless it's coded to do so.
|
||||
|
|
|
@ -17,8 +17,7 @@ long: |-
|
|||
process. For example, the `SIGHUP` signal in most cases will be non-terminal,
|
||||
and the container will continue running after receiving the signal.
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> [!NOTE]
|
||||
> `ENTRYPOINT` and `CMD` in the *shell* form run as a child process of
|
||||
> `/bin/sh -c`, which does not pass signals. This means that the executable is
|
||||
> not the container’s PID 1 and does not receive Unix signals.
|
||||
|
|
|
@ -1260,8 +1260,7 @@ examples: |-
|
|||
those with `--network=host`, have their own UTS namespace. Setting `--uts` to
|
||||
`host` results in the container using the same UTS namespace as the host.
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> [!NOTE]
|
||||
> Docker disallows combining the `--hostname` and `--domainname` flags with
|
||||
> `--uts=host`. This is to prevent containers running in the host's UTS
|
||||
> namespace from attempting to change the hosts' configuration.
|
||||
|
@ -1319,8 +1318,7 @@ examples: |-
|
|||
do. This flag exists to allow special use-cases, like running Docker within
|
||||
Docker.
|
||||
|
||||
> **Warning**
|
||||
>
|
||||
> [!WARNING]
|
||||
> Use the `--privileged` flag with caution.
|
||||
> A container with `--privileged` is not a securely sandboxed process.
|
||||
> Containers in this mode can get a root shell on the host
|
||||
|
@ -1502,8 +1500,7 @@ examples: |-
|
|||
page](/network/) explains in detail how to publish ports
|
||||
with Docker.
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> [!NOTE]
|
||||
> If you don't specify an IP address (i.e., `-p 80:80` instead of `-p
|
||||
> 127.0.0.1:80:80`) when publishing a container's ports, Docker publishes the
|
||||
> port on all interfaces (address `0.0.0.0`) by default. These ports are
|
||||
|
@ -1684,8 +1681,7 @@ examples: |-
|
|||
connectivity, containers connected to the same multi-host network but launched
|
||||
from different Engines can also communicate in this way.
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> [!NOTE]
|
||||
> The default bridge network only allows containers to communicate with each other using
|
||||
> internal IP addresses. User-created bridge networks provide DNS resolution between
|
||||
> containers using container names.
|
||||
|
@ -1753,8 +1749,7 @@ examples: |-
|
|||
$ docker run -itd --network=name=my-net,\"driver-opt=com.docker.network.endpoint.sysctls=net.ipv4.conf.IFNAME.log_martians=1,net.ipv4.conf.IFNAME.forwarding=0\",ip=192.0.2.42 busybox
|
||||
```
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> [!NOTE]
|
||||
> Network drivers may restrict the sysctl settings that can be modified and, to protect
|
||||
> the operation of the network, new restrictions may be added in the future.
|
||||
|
||||
|
@ -1881,8 +1876,7 @@ examples: |-
|
|||
fdisk: unable to open /dev/xvdc: Operation not permitted
|
||||
```
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> [!NOTE]
|
||||
> The `--device` option cannot be safely used with ephemeral devices. You shouldn't
|
||||
> add block devices that may be removed to untrusted containers with `--device`.
|
||||
|
||||
|
@ -1904,15 +1898,13 @@ examples: |-
|
|||
PS C:\> docker run --device=class/86E0D1E0-8089-11D0-9CE4-08003E301F73 mcr.microsoft.com/windows/servercore:ltsc2019
|
||||
```
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> [!NOTE]
|
||||
> The `--device` option is only supported on process-isolated Windows containers,
|
||||
> and produces an error if the container isolation is `hyperv`.
|
||||
|
||||
#### CDI devices
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> [!NOTE]
|
||||
> The CDI feature is experimental, and potentially subject to change.
|
||||
> CDI is currently only supported for Linux containers.
|
||||
|
||||
|
@ -1979,8 +1971,7 @@ examples: |-
|
|||
$ cat somefile | docker run -i -a stdin mybuilder dobuild
|
||||
```
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> [!NOTE]
|
||||
> A process running as PID 1 inside a container is treated specially by
|
||||
> Linux: it ignores any signal with the default action. So, the process
|
||||
> doesn't terminate on `SIGINT` or `SIGTERM` unless it's coded to do so.
|
||||
|
@ -2093,7 +2084,8 @@ examples: |-
|
|||
Then, a user could ask `udev` to execute a script that would `docker exec my-container mknod newDevX c 42 <minor>`
|
||||
the required device when it is added.
|
||||
|
||||
> **Note**: You still need to explicitly add initially present devices to the
|
||||
> [!NOTE]
|
||||
> You still need to explicitly add initially present devices to the
|
||||
> `docker run` / `docker create` command.
|
||||
|
||||
### Access an NVIDIA GPU {#gpus}
|
||||
|
@ -2101,8 +2093,7 @@ examples: |-
|
|||
The `--gpus` flag allows you to access NVIDIA GPU resources. First you need to
|
||||
install the [nvidia-container-runtime](https://nvidia.github.io/nvidia-container-runtime/).
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> [!NOTE]
|
||||
> You can also specify a GPU as a CDI device with the `--device` flag, see
|
||||
> [CDI devices](#cdi-devices).
|
||||
|
||||
|
@ -2212,11 +2203,10 @@ examples: |-
|
|||
`--rm` flag:
|
||||
|
||||
```text
|
||||
--rm=false: Automatically remove the container when it exits
|
||||
--rm: Automatically remove the container when it exits
|
||||
```
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> [!NOTE]
|
||||
> If you set the `--rm` flag, Docker also removes the anonymous volumes
|
||||
> associated with the container when the container is removed. This is similar
|
||||
> to running `docker rm -v my-container`. Only volumes that are specified
|
||||
|
@ -2314,14 +2304,12 @@ examples: |-
|
|||
1024
|
||||
```
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> [!NOTE]
|
||||
> If you don't provide a hard limit value, Docker uses the soft limit value
|
||||
> for both values. If you don't provide any values, they are inherited from
|
||||
> the default `ulimits` set on the daemon.
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> [!NOTE]
|
||||
> The `as` option is deprecated.
|
||||
> In other words, the following script is not supported:
|
||||
>
|
||||
|
@ -2386,8 +2374,7 @@ examples: |-
|
|||
$ docker run --security-opt label=level:s0:c100,c200 -it fedora bash
|
||||
```
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> [!NOTE]
|
||||
> Automatic translation of MLS labels isn't supported.
|
||||
|
||||
To disable the security labeling for a container entirely, you can use
|
||||
|
@ -2405,8 +2392,7 @@ examples: |-
|
|||
$ docker run --security-opt label=type:svirt_apache_t -it ubuntu bash
|
||||
```
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> [!NOTE]
|
||||
> You would have to write policy defining a `svirt_apache_t` type.
|
||||
|
||||
To prevent your container processes from gaining additional privileges, you can
|
||||
|
@ -2527,8 +2513,7 @@ examples: |-
|
|||
$ docker run --sysctl net.ipv4.ip_forward=1 someimage
|
||||
```
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> [!NOTE]
|
||||
> Not all sysctls are namespaced. Docker does not support changing sysctls
|
||||
> inside of a container that also modify the host system. As the kernel
|
||||
> evolves we expect to see more sysctls become namespaced.
|
||||
|
|
|
@ -10,8 +10,7 @@ long: |-
|
|||
If you need more detailed information about a container's resource usage, use
|
||||
the `/containers/(id)/stats` API endpoint.
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> [!NOTE]
|
||||
> On Linux, the Docker CLI reports memory usage by subtracting cache usage from
|
||||
> the total memory usage. The API does not perform such a calculation but rather
|
||||
> provides the total memory usage and the amount from the cache so that clients
|
||||
|
@ -22,8 +21,7 @@ long: |-
|
|||
> field. On cgroup v2 hosts, the cache usage is defined as the value of
|
||||
> `inactive_file` field.
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> [!NOTE]
|
||||
> The `PIDS` column contains the number of processes and kernel threads created
|
||||
> by that container. Threads is the term used by Linux kernel. Other equivalent
|
||||
> terms are "lightweight process" or "kernel task", etc. A large number in the
|
||||
|
|
|
@ -13,8 +13,7 @@ long: |-
|
|||
4.6, you can only update `--kernel-memory` on a stopped container or on
|
||||
a running container with kernel memory initialized.
|
||||
|
||||
> **Warning**
|
||||
>
|
||||
> [!WARNING]
|
||||
> The `docker update` and `docker container update` commands are not supported
|
||||
> for Windows containers.
|
||||
{ .warning }
|
||||
|
@ -219,8 +218,7 @@ examples: |-
|
|||
If the container was started without `--kernel-memory` you need to stop
|
||||
the container before updating kernel memory.
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> [!NOTE]
|
||||
> The `--kernel-memory` option has been deprecated since Docker 20.10.
|
||||
|
||||
For example, if you started a container with this command:
|
||||
|
|
|
@ -2,8 +2,7 @@ command: docker image build
|
|||
aliases: docker image build, docker build, docker builder build
|
||||
short: Build an image from a Dockerfile
|
||||
long: |-
|
||||
> **Note**
|
||||
>
|
||||
> [!NOTE]
|
||||
> This page refers to the **legacy implementation** of `docker build`,
|
||||
> using the legacy (pre-BuildKit) build backend.
|
||||
> This configuration is only relevant if you're building Windows containers.
|
||||
|
@ -420,7 +419,7 @@ examples: |-
|
|||
|
||||
#### Overview
|
||||
|
||||
> **Note**
|
||||
> [!NOTE]
|
||||
> The `--squash` option is an experimental feature, and should not be considered
|
||||
> stable.
|
||||
|
||||
|
|
|
@ -92,6 +92,17 @@ options:
|
|||
experimentalcli: false
|
||||
kubernetes: false
|
||||
swarm: false
|
||||
- option: tree
|
||||
value_type: bool
|
||||
default_value: "false"
|
||||
description: List multi-platform images as a tree (EXPERIMENTAL)
|
||||
deprecated: false
|
||||
hidden: false
|
||||
min_api_version: "1.47"
|
||||
experimental: false
|
||||
experimentalcli: true
|
||||
kubernetes: false
|
||||
swarm: false
|
||||
inherited_options:
|
||||
- option: help
|
||||
value_type: bool
|
||||
|
|
|
@ -112,6 +112,7 @@ examples: |-
|
|||
format is the `label!=...` (`label!=<key>` or `label!=<key>=<value>`), which removes
|
||||
images without the specified labels.
|
||||
|
||||
> [!NOTE]
|
||||
> **Predicting what will be removed**
|
||||
>
|
||||
> If you are using positive filtering (testing for the existence of a label or
|
||||
|
@ -216,8 +217,7 @@ examples: |-
|
|||
$ docker image prune --filter="label!=maintainer=john"
|
||||
```
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> [!NOTE]
|
||||
> You are prompted for confirmation before the `prune` removes
|
||||
> anything, but you are not shown a list of what will potentially be removed.
|
||||
> In addition, `docker image ls` doesn't support negative filtering, so it
|
||||
|
|
|
@ -195,8 +195,7 @@ examples: |-
|
|||
LABEL org.opencontainers.image.authors="some maintainer <maintainer@example.com>"
|
||||
```
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> [!NOTE]
|
||||
> Using this feature "pins" an image to a specific version in time.
|
||||
> Docker does therefore not pull updated versions of an image, which may include
|
||||
> security updates. If you want to pull an updated image, you need to change the
|
||||
|
|
|
@ -73,6 +73,17 @@ options:
|
|||
experimentalcli: false
|
||||
kubernetes: false
|
||||
swarm: false
|
||||
- option: tree
|
||||
value_type: bool
|
||||
default_value: "false"
|
||||
description: List multi-platform images as a tree (EXPERIMENTAL)
|
||||
deprecated: false
|
||||
hidden: false
|
||||
min_api_version: "1.47"
|
||||
experimental: false
|
||||
experimentalcli: true
|
||||
kubernetes: false
|
||||
swarm: false
|
||||
inherited_options:
|
||||
- option: help
|
||||
value_type: bool
|
||||
|
|
|
@ -1,87 +1,35 @@
|
|||
command: docker login
|
||||
short: Log in to a registry
|
||||
long: Log in to a registry.
|
||||
usage: docker login [OPTIONS] [SERVER]
|
||||
pname: docker
|
||||
plink: docker.yaml
|
||||
options:
|
||||
- option: password
|
||||
shorthand: p
|
||||
value_type: string
|
||||
description: Password
|
||||
deprecated: false
|
||||
hidden: false
|
||||
experimental: false
|
||||
experimentalcli: false
|
||||
kubernetes: false
|
||||
swarm: false
|
||||
- option: password-stdin
|
||||
value_type: bool
|
||||
default_value: "false"
|
||||
description: Take the password from stdin
|
||||
details_url: '#password-stdin'
|
||||
deprecated: false
|
||||
hidden: false
|
||||
experimental: false
|
||||
experimentalcli: false
|
||||
kubernetes: false
|
||||
swarm: false
|
||||
- option: username
|
||||
shorthand: u
|
||||
value_type: string
|
||||
description: Username
|
||||
deprecated: false
|
||||
hidden: false
|
||||
experimental: false
|
||||
experimentalcli: false
|
||||
kubernetes: false
|
||||
swarm: false
|
||||
inherited_options:
|
||||
- option: help
|
||||
value_type: bool
|
||||
default_value: "false"
|
||||
description: Print usage
|
||||
deprecated: false
|
||||
hidden: true
|
||||
experimental: false
|
||||
experimentalcli: false
|
||||
kubernetes: false
|
||||
swarm: false
|
||||
examples: |-
|
||||
### Login to a self-hosted registry
|
||||
short: Authenticate to a registry
|
||||
long: |-
|
||||
Authenticate to a registry.
|
||||
|
||||
If you want to log in to a self-hosted registry you can specify this by
|
||||
adding the server name.
|
||||
You can authenticate to any public or private registry for which you have
|
||||
credentials. Authentication may be required for pulling and pushing images.
|
||||
Other commands, such as `docker scout` and `docker build`, may also require
|
||||
authentication to access subscription-only features or data related to your
|
||||
Docker organization.
|
||||
|
||||
```console
|
||||
$ docker login localhost:8080
|
||||
```
|
||||
Authentication credentials are stored in the configured [credential
|
||||
store](#credential-stores). If you use Docker Desktop, credentials are
|
||||
automatically saved to the native keychain of your operating system. If you're
|
||||
not using Docker Desktop, you can configure the credential store in the Docker
|
||||
configuration file, which is located at `$HOME/.docker/config.json` on Linux or
|
||||
`%USERPROFILE%/.docker/config.json` on Windows. If you don't configure a
|
||||
credential store, Docker stores credentials in the `config.json` file in a
|
||||
base64-encoded format. This method is less secure than configuring and using a
|
||||
credential store.
|
||||
|
||||
### Provide a password using STDIN (--password-stdin) {#password-stdin}
|
||||
`docker login` also supports [credential helpers](#credential-helpers) to help
|
||||
you handle credentials for specific registries.
|
||||
|
||||
To run the `docker login` command non-interactively, you can set the
|
||||
`--password-stdin` flag to provide a password through `STDIN`. Using
|
||||
`STDIN` prevents the password from ending up in the shell's history,
|
||||
or log-files.
|
||||
### Authentication methods
|
||||
|
||||
The following example reads a password from a file, and passes it to the
|
||||
`docker login` command using `STDIN`:
|
||||
|
||||
```console
|
||||
$ cat ~/my_password.txt | docker login --username foo --password-stdin
|
||||
```
|
||||
|
||||
### Privileged user requirement
|
||||
|
||||
`docker login` requires you to use `sudo` or be `root`, except when:
|
||||
|
||||
- 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](/engine/security/#docker-daemon-attack-surface) for details.
|
||||
|
||||
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.
|
||||
You can authenticate to a registry using a username and access token or
|
||||
password. Docker Hub also supports a web-based sign-in flow, which signs you in
|
||||
to your Docker account without entering your password. For Docker Hub, the
|
||||
`docker login` command uses a device code flow by default, unless the
|
||||
`--username` flag is specified. The device code flow is a secure way to sign
|
||||
in. See [Authenticate to Docker Hub using device code](#authenticate-to-docker-hub-with-web-based-login).
|
||||
|
||||
### Credential stores
|
||||
|
||||
|
@ -102,6 +50,10 @@ examples: |-
|
|||
- Microsoft Windows Credential Manager
|
||||
- [pass](https://www.passwordstore.org/)
|
||||
|
||||
With Docker Desktop, the credential store is already installed and configured
|
||||
for you. Unless you want to change the credential store used by Docker Desktop,
|
||||
you can skip the following steps.
|
||||
|
||||
#### Configure the credential store
|
||||
|
||||
You need to specify the credential store in `$HOME/.docker/config.json`
|
||||
|
@ -121,22 +73,22 @@ examples: |-
|
|||
#### Default behavior
|
||||
|
||||
By default, Docker looks for the native binary on each of the platforms, i.e.
|
||||
"osxkeychain" on macOS, "wincred" on windows, and "pass" on Linux. A special
|
||||
case is that on Linux, Docker will fall back to the "secretservice" binary if
|
||||
it cannot find the "pass" binary. If none of these binaries are present, it
|
||||
stores the credentials (i.e. password) in base64 encoding in the config files
|
||||
described above.
|
||||
`osxkeychain` on macOS, `wincred` on Windows, and `pass` on Linux. A special
|
||||
case is that on Linux, Docker will fall back to the `secretservice` binary if
|
||||
it cannot find the `pass` binary. If none of these binaries are present, it
|
||||
stores the base64-encoded credentials in the `config.json` configuration file.
|
||||
|
||||
#### Credential helper protocol
|
||||
|
||||
Credential helpers can be any program or script that follows a very simple protocol.
|
||||
This protocol is heavily inspired by Git, but it differs in the information shared.
|
||||
Credential helpers can be any program or script that implements the credential
|
||||
helper protocol. This protocol is inspired by Git, but differs in the
|
||||
information shared.
|
||||
|
||||
The helpers always use the first argument in the command to identify the action.
|
||||
There are only three possible values for that argument: `store`, `get`, and `erase`.
|
||||
|
||||
The `store` command takes a JSON payload from the standard input. That payload carries
|
||||
the server address, to identify the credential, the user name, and either a password
|
||||
the server address, to identify the credential, the username, and either a password
|
||||
or an identity token.
|
||||
|
||||
```json
|
||||
|
@ -176,10 +128,10 @@ examples: |-
|
|||
|
||||
### 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
|
||||
credential store (`credsStore` or the config file itself) will not be used for
|
||||
operations concerning credentials of the specified registries.
|
||||
Credential helpers are similar to [credential stores](#credential-stores), but
|
||||
act as the designated programs to handle credentials for specific registries.
|
||||
The default credential store will not be used for operations concerning
|
||||
credentials of the specified registries.
|
||||
|
||||
#### Configure credential helpers
|
||||
|
||||
|
@ -189,18 +141,137 @@ examples: |-
|
|||
Credential helpers are specified in a similar way to `credsStore`, but
|
||||
allow for multiple helpers to be configured at a time. Keys specify the
|
||||
registry domain, and values specify the suffix of the program to use
|
||||
(i.e. everything after `docker-credential-`).
|
||||
For example:
|
||||
(i.e. everything after `docker-credential-`). For example:
|
||||
|
||||
```json
|
||||
{
|
||||
"credHelpers": {
|
||||
"registry.example.com": "registryhelper",
|
||||
"awesomereg.example.org": "hip-star",
|
||||
"unicorn.example.io": "vcbait"
|
||||
"myregistry.example.com": "secretservice",
|
||||
"docker.internal.example": "pass",
|
||||
}
|
||||
}
|
||||
```
|
||||
usage: docker login [OPTIONS] [SERVER]
|
||||
pname: docker
|
||||
plink: docker.yaml
|
||||
options:
|
||||
- option: password
|
||||
shorthand: p
|
||||
value_type: string
|
||||
description: Password
|
||||
deprecated: false
|
||||
hidden: false
|
||||
experimental: false
|
||||
experimentalcli: false
|
||||
kubernetes: false
|
||||
swarm: false
|
||||
- option: password-stdin
|
||||
value_type: bool
|
||||
default_value: "false"
|
||||
description: Take the password from stdin
|
||||
details_url: '#password-stdin'
|
||||
deprecated: false
|
||||
hidden: false
|
||||
experimental: false
|
||||
experimentalcli: false
|
||||
kubernetes: false
|
||||
swarm: false
|
||||
- option: username
|
||||
shorthand: u
|
||||
value_type: string
|
||||
description: Username
|
||||
details_url: '#username'
|
||||
deprecated: false
|
||||
hidden: false
|
||||
experimental: false
|
||||
experimentalcli: false
|
||||
kubernetes: false
|
||||
swarm: false
|
||||
inherited_options:
|
||||
- option: help
|
||||
value_type: bool
|
||||
default_value: "false"
|
||||
description: Print usage
|
||||
deprecated: false
|
||||
hidden: true
|
||||
experimental: false
|
||||
experimentalcli: false
|
||||
kubernetes: false
|
||||
swarm: false
|
||||
examples: |-
|
||||
### Authenticate to Docker Hub with web-based login
|
||||
|
||||
By default, the `docker login` command authenticates to Docker Hub, using a
|
||||
device code flow. This flow lets you authenticate to Docker Hub without
|
||||
entering your password. Instead, you visit a URL in your web browser, enter a
|
||||
code, and authenticate.
|
||||
|
||||
```console
|
||||
$ docker login
|
||||
|
||||
USING WEB-BASED LOGIN
|
||||
To sign in with credentials on the command line, use 'docker login -u <username>'
|
||||
|
||||
Your one-time device confirmation code is: LNFR-PGCJ
|
||||
Press ENTER to open your browser or submit your device code here: https://login.docker.com/activate
|
||||
|
||||
Waiting for authentication in the browser…
|
||||
```
|
||||
|
||||
After entering the code in your browser, you are authenticated to Docker Hub
|
||||
using the account you're currently signed in with on the Docker Hub website or
|
||||
in Docker Desktop. If you aren't signed in, you are prompted to sign in after
|
||||
entering the device code.
|
||||
|
||||
### Authenticate to a self-hosted registry
|
||||
|
||||
If you want to authenticate to a self-hosted registry you can specify this by
|
||||
adding the server name.
|
||||
|
||||
```console
|
||||
$ docker login registry.example.com
|
||||
```
|
||||
|
||||
By default, the `docker login` command assumes that the registry listens on
|
||||
port 443 or 80. If the registry listens on a different port, you can specify it
|
||||
by adding the port number to the server name.
|
||||
|
||||
```console
|
||||
$ docker login registry.example.com:1337
|
||||
```
|
||||
|
||||
> [!NOTE]
|
||||
> Registry addresses should not include URL path components, only the hostname
|
||||
> and (optionally) the port. Registry addresses with URL path components may
|
||||
> result in an error. For example, `docker login registry.example.com/foo/`
|
||||
> is incorrect, while `docker login registry.example.com` is correct.
|
||||
>
|
||||
> The exception to this rule is the Docker Hub registry, which may use the
|
||||
> `/v1/` path component in the address for historical reasons.
|
||||
|
||||
### Authenticate to a registry with a username and password {#username}
|
||||
|
||||
To authenticate to a registry with a username and password, you can use the
|
||||
`--username` or `-u` flag. The following example authenticates to Docker Hub
|
||||
with the username `moby`. The password is entered interactively.
|
||||
|
||||
```console
|
||||
$ docker login -u moby
|
||||
```
|
||||
|
||||
### Provide a password using STDIN (--password-stdin) {#password-stdin}
|
||||
|
||||
To run the `docker login` command non-interactively, you can set the
|
||||
`--password-stdin` flag to provide a password through `STDIN`. Using
|
||||
`STDIN` prevents the password from ending up in the shell's history,
|
||||
or log-files.
|
||||
|
||||
The following example reads a password from a file, and passes it to the
|
||||
`docker login` command using `STDIN`:
|
||||
|
||||
```console
|
||||
$ cat ~/my_password.txt | docker login --username foo --password-stdin
|
||||
```
|
||||
deprecated: false
|
||||
hidden: false
|
||||
experimental: false
|
||||
|
|
|
@ -279,8 +279,7 @@ examples: |-
|
|||
$ docker manifest push --insecure myprivateregistry.mycompany.com/repo/image:tag
|
||||
```
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> [!NOTE]
|
||||
> The `--insecure` flag is not required to annotate a manifest list,
|
||||
> since annotations are to a locally-stored copy of a manifest list. You may also
|
||||
> skip the `--insecure` flag if you are performing a `docker manifest inspect`
|
||||
|
|
|
@ -135,8 +135,7 @@ examples: |-
|
|||
$ docker network connect --driver-opt=\"com.docker.network.endpoint.sysctls=net.ipv4.conf.IFNAME.log_martians=1,net.ipv4.conf.IFNAME.forwarding=0\" multi-host-network container2
|
||||
```
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> [!NOTE]
|
||||
> Network drivers may restrict the sysctl settings that can be modified and, to protect
|
||||
> the operation of the network, new restrictions may be added in the future.
|
||||
|
||||
|
|
|
@ -3,8 +3,7 @@ short: Demote one or more nodes from manager in the swarm
|
|||
long: |-
|
||||
Demotes an existing manager so that it is no longer a manager.
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> [!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](/engine/swarm/) in the documentation.
|
||||
|
|
|
@ -7,8 +7,7 @@ long: |-
|
|||
[text/template](https://pkg.go.dev/text/template) package describes all the
|
||||
details of the format.
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> [!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](/engine/swarm/) in the
|
||||
|
|
|
@ -6,8 +6,7 @@ long: |-
|
|||
using the `-f` or `--filter` flag. Refer to the [filtering](#filter) section
|
||||
for more information about available filter options.
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> [!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](/engine/swarm/) in the
|
||||
|
@ -75,8 +74,7 @@ examples: |-
|
|||
e216jshn25ckzbvmwlnh5jr3g * swarm-manager1 Ready Active Leader
|
||||
```
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> [!NOTE]
|
||||
> In the above example output, there is a hidden column of `.Self` that indicates
|
||||
> if the node is the same node as the current docker daemon. A `*` (e.g.,
|
||||
> `e216jshn25ckzbvmwlnh5jr3g *`) means this node is the current docker daemon.
|
||||
|
|
|
@ -3,8 +3,7 @@ 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.
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> [!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](/engine/swarm/) in the
|
||||
|
|
|
@ -5,8 +5,7 @@ long: |-
|
|||
`-f` or `--filter` flag. Refer to the [filtering](#filter) section for more
|
||||
information about available filter options.
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> [!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](/engine/swarm/) in the
|
||||
|
|
|
@ -4,8 +4,7 @@ short: Remove one or more nodes from the swarm
|
|||
long: |-
|
||||
Removes the specified nodes from a swarm.
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> [!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](/engine/swarm/) in the
|
||||
|
|
|
@ -3,8 +3,7 @@ short: Update a node
|
|||
long: |-
|
||||
Update metadata about a node, such as its availability, labels, or roles.
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> [!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](/engine/swarm/) in the
|
||||
|
|
|
@ -53,8 +53,7 @@ examples: |-
|
|||
/bar
|
||||
```
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> [!NOTE]
|
||||
> Since only `source` is settable in `mymount`,
|
||||
> `docker plugins set mymount=/bar myplugin` would work too.
|
||||
|
||||
|
@ -75,8 +74,7 @@ examples: |-
|
|||
/dev/bar
|
||||
```
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> [!NOTE]
|
||||
> Since only `path` is settable in `mydevice`,
|
||||
> `docker plugins set mydevice=/dev/bar myplugin` would work too.
|
||||
|
||||
|
|
|
@ -5,8 +5,7 @@ long: |-
|
|||
|
||||
For detailed information about using secrets, refer to [manage sensitive data with Docker secrets](/engine/swarm/secrets/).
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> [!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](/engine/swarm/) in the
|
||||
|
|
|
@ -11,8 +11,7 @@ long: |-
|
|||
|
||||
For detailed information about using secrets, refer to [manage sensitive data with Docker secrets](/engine/swarm/secrets/).
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> [!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](/engine/swarm/) in the
|
||||
|
|
|
@ -6,8 +6,7 @@ long: |-
|
|||
|
||||
For detailed information about using secrets, refer to [manage sensitive data with Docker secrets](/engine/swarm/secrets/).
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> [!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](/engine/swarm/) in the
|
||||
|
|
|
@ -6,8 +6,7 @@ long: |-
|
|||
|
||||
For detailed information about using secrets, refer to [manage sensitive data with Docker secrets](/engine/swarm/secrets/).
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> [!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](/engine/swarm/) in the
|
||||
|
@ -34,8 +33,7 @@ examples: |-
|
|||
sapth4csdo5b6wz2p5uimh5xg
|
||||
```
|
||||
|
||||
> **Warning**
|
||||
>
|
||||
> [!WARNING]
|
||||
> Unlike `docker rm`, this command does not ask for confirmation before removing
|
||||
> a secret.
|
||||
{ .warning }
|
||||
|
|
|
@ -3,8 +3,7 @@ short: Manage Swarm services
|
|||
long: |-
|
||||
Manage Swarm services.
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> [!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](/engine/swarm/) in the
|
||||
|
|
|
@ -3,8 +3,7 @@ short: Create a new service
|
|||
long: |-
|
||||
Creates a service as described by the specified parameters.
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> [!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](/engine/swarm/) in the
|
||||
|
|
|
@ -9,8 +9,7 @@ long: |-
|
|||
Go's [text/template](https://pkg.go.dev/text/template) package
|
||||
describes all the details of the format.
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> [!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](/engine/swarm/) in the
|
||||
|
|
|
@ -3,8 +3,7 @@ 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**
|
||||
>
|
||||
> [!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](/engine/swarm/) in the
|
||||
|
@ -15,8 +14,7 @@ long: |-
|
|||
for all of the containers in that service. If a task is passed, it will only
|
||||
display logs from that particular task.
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> [!NOTE]
|
||||
> This command is only functional for services that are started with
|
||||
> the `json-file` or `journald` logging driver.
|
||||
|
||||
|
|
|
@ -4,8 +4,7 @@ short: List services
|
|||
long: |-
|
||||
This command lists services that are running in the swarm.
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> [!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](/engine/swarm/) in the
|
||||
|
|
|
@ -3,8 +3,7 @@ short: List the tasks of one or more services
|
|||
long: |-
|
||||
Lists the tasks that are running as part of the specified services.
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> [!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](/engine/swarm/) in the
|
||||
|
|
|
@ -4,8 +4,7 @@ short: Remove one or more services
|
|||
long: |-
|
||||
Removes the specified services from the swarm.
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> [!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](/engine/swarm/) in the
|
||||
|
@ -37,8 +36,7 @@ examples: |-
|
|||
ID NAME MODE REPLICAS IMAGE
|
||||
```
|
||||
|
||||
> **Warning**
|
||||
>
|
||||
> [!WARNING]
|
||||
> Unlike `docker rm`, this command does not ask for confirmation before removing
|
||||
> a running service.
|
||||
deprecated: false
|
||||
|
|
|
@ -3,8 +3,7 @@ short: Revert changes to a service's configuration
|
|||
long: |-
|
||||
Roll back a specified service to its previous version from the swarm.
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> [!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](/engine/swarm/) in the
|
||||
|
|
|
@ -7,8 +7,7 @@ long: |-
|
|||
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**
|
||||
>
|
||||
> [!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](/engine/swarm/) in the
|
||||
|
|
|
@ -11,8 +11,7 @@ long: |-
|
|||
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**
|
||||
>
|
||||
> [!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](/engine/swarm/) in the
|
||||
|
|
|
@ -4,8 +4,7 @@ short: Deploy a new stack or update an existing stack
|
|||
long: |-
|
||||
Create and update a stack from a `compose` file on the swarm.
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> [!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](/engine/swarm/) in the
|
||||
|
|
|
@ -4,8 +4,7 @@ short: List stacks
|
|||
long: |-
|
||||
Lists the stacks.
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> [!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](/engine/swarm/) in the
|
||||
|
|
|
@ -3,8 +3,7 @@ short: List the tasks in the stack
|
|||
long: |-
|
||||
Lists the tasks that are running as part of the specified stack.
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> [!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](/engine/swarm/) in the
|
||||
|
|
|
@ -4,8 +4,7 @@ short: Remove one or more stacks
|
|||
long: |-
|
||||
Remove the stack from the swarm.
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> [!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](/engine/swarm/) in the
|
||||
|
|
|
@ -3,8 +3,7 @@ short: List the services in the stack
|
|||
long: |-
|
||||
Lists the services that are running as part of the specified stack.
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> [!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](/engine/swarm/) in the
|
||||
|
|
|
@ -3,8 +3,7 @@ short: Display and rotate the root CA
|
|||
long: |-
|
||||
View or rotate the current swarm CA certificate.
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> [!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](/engine/swarm/) in the
|
||||
|
@ -149,8 +148,7 @@ examples: |-
|
|||
|
||||
### Root CA rotation (--rotate) {#rotate}
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> [!NOTE]
|
||||
> Mirantis Kubernetes Engine (MKE), formerly known as Docker UCP, provides an external
|
||||
> certificate manager service for the swarm. If you run swarm on MKE, you shouldn't
|
||||
> rotate the CA certificates manually. Instead, contact Mirantis support if you need
|
||||
|
|
|
@ -7,8 +7,7 @@ long: |-
|
|||
[swarm join](/reference/cli/docker/swarm/join/). Nodes use the join token only when they join the
|
||||
swarm.
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> [!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](/engine/swarm/) in the
|
||||
|
|
|
@ -8,8 +8,7 @@ long: |-
|
|||
You can view or rotate the unlock key using `swarm unlock-key`. To view the key,
|
||||
run the `docker swarm unlock-key` command without any arguments:
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> [!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](/engine/swarm/) in the
|
||||
|
|
|
@ -6,8 +6,7 @@ long: |-
|
|||
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**
|
||||
>
|
||||
> [!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](/engine/swarm/) in the
|
||||
|
|
|
@ -3,8 +3,7 @@ short: Update the swarm
|
|||
long: |-
|
||||
Updates a swarm with new parameter values.
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> [!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](/engine/swarm/) in the
|
||||
|
|
|
@ -87,8 +87,7 @@ examples: |-
|
|||
* `UNIQUE SIZE` is the amount of space that's only used by a given image
|
||||
* `SIZE` is the virtual size of the image, it's the sum of `SHARED SIZE` and `UNIQUE SIZE`
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> [!NOTE]
|
||||
> Network information isn't shown, because it doesn't consume disk space.
|
||||
deprecated: false
|
||||
hidden: false
|
||||
|
|
Loading…
Reference in New Issue