engine: regenerate cli docs for 27.0

Signed-off-by: David Karlsson <35727626+dvdksn@users.noreply.github.com>
This commit is contained in:
David Karlsson
2024-07-02 15:46:28 +02:00
parent ffe30bf98b
commit 0bf54cd2bb
20 changed files with 146 additions and 54 deletions

View File

@@ -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}