mirror of
https://github.com/docker/docs.git
synced 2026-03-27 14:28:47 +07:00
engine: regenerate cli docs for 27.0
Signed-off-by: David Karlsson <35727626+dvdksn@users.noreply.github.com>
This commit is contained in:
@@ -900,7 +900,8 @@ options:
|
||||
- option: rm
|
||||
value_type: bool
|
||||
default_value: "false"
|
||||
description: Automatically remove the container when it exits
|
||||
description: |
|
||||
Automatically remove the container and its associated anonymous volumes when it exits
|
||||
details_url: '#rm'
|
||||
deprecated: false
|
||||
hidden: false
|
||||
@@ -1189,14 +1190,7 @@ examples: |-
|
||||
2. Install `htop` in the container:
|
||||
|
||||
```console
|
||||
/ # apk add htop
|
||||
fetch https://dl-cdn.alpinelinux.org/alpine/v3.18/main/aarch64/APKINDEX.tar.gz
|
||||
fetch https://dl-cdn.alpinelinux.org/alpine/v3.18/community/aarch64/APKINDEX.tar.gz
|
||||
(1/3) Installing ncurses-terminfo-base (6.4_p20230506-r0)
|
||||
(2/3) Installing libncursesw (6.4_p20230506-r0)
|
||||
(3/3) Installing htop (3.2.2-r1)
|
||||
Executing busybox-1.36.1-r2.trigger
|
||||
OK: 9 MiB in 18 packages
|
||||
/ # apk add --quiet htop
|
||||
```
|
||||
|
||||
3. Invoke the `htop` command.
|
||||
@@ -1682,7 +1676,24 @@ examples: |-
|
||||
|
||||
To start a container and connect it to a network, use the `--network` option.
|
||||
|
||||
The following commands create a network named `my-net` and adds a `busybox` container
|
||||
If you want to add a running container to a network use the `docker network connect` subcommand.
|
||||
|
||||
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.
|
||||
|
||||
> **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.
|
||||
|
||||
You can disconnect a container from a network using the `docker network
|
||||
disconnect` command.
|
||||
|
||||
The following commands create a network named `my-net` and add a `busybox` container
|
||||
to the `my-net` network.
|
||||
|
||||
```console
|
||||
@@ -1699,24 +1710,56 @@ examples: |-
|
||||
$ docker run -itd --network=my-net --ip=192.0.2.69 busybox
|
||||
```
|
||||
|
||||
If you want to add a running container to a network use the `docker network connect` subcommand.
|
||||
To connect the container to more than one network, repeat the `--network` option.
|
||||
|
||||
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.
|
||||
```console
|
||||
$ docker network create --subnet 192.0.2.0/24 my-net1
|
||||
$ docker network create --subnet 192.0.3.0/24 my-net2
|
||||
$ docker run -itd --network=my-net1 --network=my-net2 busybox
|
||||
```
|
||||
|
||||
To specify options when connecting to more than one network, use the extended syntax
|
||||
for the `--network` flag. Comma-separated options that can be specified in the extended
|
||||
`--network` syntax are:
|
||||
|
||||
| Option | Top-level Equivalent | Description |
|
||||
|-----------------|---------------------------------------|-------------------------------------------------|
|
||||
| `name` | | The name of the network (mandatory) |
|
||||
| `alias` | `--network-alias` | Add network-scoped alias for the container |
|
||||
| `ip` | `--ip` | IPv4 address (e.g., 172.30.100.104) |
|
||||
| `ip6` | `--ip6` | IPv6 address (e.g., 2001:db8::33) |
|
||||
| `mac-address` | `--mac-address` | Container MAC address (e.g., 92:d0:c6:0a:29:33) |
|
||||
| `link-local-ip` | `--link-local-ip` | Container IPv4/IPv6 link-local addresses |
|
||||
| `driver-opt` | `docker network connect --driver-opt` | Network driver options |
|
||||
|
||||
```console
|
||||
$ docker network create --subnet 192.0.2.0/24 my-net1
|
||||
$ docker network create --subnet 192.0.3.0/24 my-net2
|
||||
$ docker run -itd --network=name=my-net1,ip=192.0.2.42 --network=name=my-net2,ip=192.0.3.42 busybox
|
||||
```
|
||||
|
||||
`sysctl` settings that start with `net.ipv4.`, `net.ipv6.` or `net.mpls.` can be
|
||||
set per-interface using `driver-opt` label `com.docker.network.endpoint.sysctls`.
|
||||
The interface name must be the string `IFNAME`.
|
||||
|
||||
To set more than one `sysctl` for an interface, quote the whole `driver-opt` field,
|
||||
remembering to escape the quotes for the shell if necessary. For example, if the
|
||||
interface to `my-net` is given name `eth0`, the following example sets sysctls
|
||||
`net.ipv4.conf.eth0.log_martians=1` and `net.ipv4.conf.eth0.forwarding=0`, and
|
||||
assigns the IPv4 address `192.0.2.42`.
|
||||
|
||||
```console
|
||||
$ docker network create --subnet 192.0.2.0/24 my-net
|
||||
$ 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**
|
||||
>
|
||||
> The default bridge network only allow containers to communicate with each other using
|
||||
> internal IP addresses. User-created bridge networks provide DNS resolution between
|
||||
> containers using container names.
|
||||
> 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.
|
||||
|
||||
You can disconnect a container from a network using the `docker network
|
||||
disconnect` command.
|
||||
|
||||
For more information on connecting a container to a network when using the `run` command, see the ["*Docker network overview*"](/network/).
|
||||
For more information on connecting a container to a network when using the `run` command,
|
||||
see the [Docker network overview](/network/).
|
||||
|
||||
### Mount volumes from container (--volumes-from) {#volumes-from}
|
||||
|
||||
@@ -1870,17 +1913,19 @@ examples: |-
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> This is experimental feature and as such doesn't represent a stable API.
|
||||
> The CDI feature is experimental, and potentially subject to change.
|
||||
> CDI is currently only supported for Linux containers.
|
||||
|
||||
Container Device Interface (CDI) is a
|
||||
[standardized](https://github.com/cncf-tags/container-device-interface/blob/main/SPEC.md)
|
||||
mechanism for container runtimes to create containers which are able to
|
||||
interact with third party devices.
|
||||
[Container Device Interface
|
||||
(CDI)](https://github.com/cncf-tags/container-device-interface/blob/main/SPEC.md)
|
||||
is a standardized mechanism for container runtimes to create containers which
|
||||
are able to interact with third party devices.
|
||||
|
||||
With CDI, device configurations are defined using a JSON file. In addition to
|
||||
enabling the container to interact with the device node, it also lets you
|
||||
specify additional configuration for the device, such as kernel modules, host
|
||||
libraries, and environment variables.
|
||||
With CDI, device configurations are declaratively defined using a JSON or YAML
|
||||
file. In addition to enabling the container to interact with the device node,
|
||||
it also lets you specify additional configuration for the device, such as
|
||||
environment variables, host mounts (such as shared objects), and executable
|
||||
hooks.
|
||||
|
||||
You can reference a CDI device with the `--device` flag using the
|
||||
fully-qualified name of the device, as shown in the following example:
|
||||
@@ -1892,10 +1937,10 @@ examples: |-
|
||||
This starts an `ubuntu` container with access to the specified CDI device,
|
||||
`vendor.com/class=device-name`, assuming that:
|
||||
|
||||
- A valid CDI specification (JSON file) for the requested device is available
|
||||
on the system running the daemon, in one of the configured CDI specification
|
||||
directories.
|
||||
- The CDI feature has been enabled on the daemon side, see [Enable CDI
|
||||
- A valid CDI specification (JSON or YAML file) for the requested device is
|
||||
available on the system running the daemon, in one of the configured CDI
|
||||
specification directories.
|
||||
- The CDI feature has been enabled in the daemon; see [Enable CDI
|
||||
devices](/reference/cli/dockerd/#enable-cdi-devices).
|
||||
|
||||
### Attach to STDIN/STDOUT/STDERR (-a, --attach) {#attach}
|
||||
|
||||
Reference in New Issue
Block a user