Guest24897
/
DockerCLI
mirror of https://github.com/docker/cli.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

docs: update for cgroup v2 and rootless 

Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
This commit is contained in:
Akihiro Suda 2020-06-24 19:09:15 +09:00
parent 87db43814b
commit beb23c9963
No known key found for this signature in database
GPG Key ID: 49524C6F9F638F1A
3 changed files with 11 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
docs/reference/commandline/dockerd.md
View File

@ -290,7 +290,7 @@ $ docker -H tcp://127.0.0.1:2375 pull ubuntu
### Daemon storage-driver ### Daemon storage-driver
On Linux, the Docker daemon has support for several different image layer storage On Linux, the Docker daemon has support for several different image layer storage
drivers: `aufs`, `devicemapper`, `btrfs`, `zfs`, `overlay` and `overlay2`. drivers: `aufs`, `devicemapper`, `btrfs`, `zfs`, `overlay`, `overlay2`, and `fuse-overlayfs`.
The `aufs` driver is the oldest, but is based on a Linux kernel patch-set that The `aufs` driver is the oldest, but is based on a Linux kernel patch-set that
is unlikely to be merged into the main kernel. These are also known to cause is unlikely to be merged into the main kernel. These are also known to cause
@ -341,6 +341,9 @@ to use it.
> Both `overlay` and `overlay2` are currently unsupported on `btrfs` > Both `overlay` and `overlay2` are currently unsupported on `btrfs`
> or any Copy on Write filesystem and should only be used over `ext4` partitions. > or any Copy on Write filesystem and should only be used over `ext4` partitions.
The `fuse-overlayfs` driver is similar to `overlay2` but works in userspace.
The `fuse-overlayfs` driver is expected to be used for [Rootless mode](https://docs.docker.com/engine/security/rootless/).
On Windows, the Docker daemon supports a single image layer storage driver On Windows, the Docker daemon supports a single image layer storage driver
depending on the image platform: `windowsfilter` for Windows images, and depending on the image platform: `windowsfilter` for Windows images, and
`lcow` for Linux containers on Windows. `lcow` for Linux containers on Windows.
@ -999,7 +1002,8 @@ single `native.cgroupdriver` option is available.
The `native.cgroupdriver` option specifies the management of the container's The `native.cgroupdriver` option specifies the management of the container's
cgroups. You can only specify `cgroupfs` or `systemd`. If you specify cgroups. You can only specify `cgroupfs` or `systemd`. If you specify
`systemd` and it is not available, the system errors out. If you omit the `systemd` and it is not available, the system errors out. If you omit the
`native.cgroupdriver` option,` cgroupfs` is used. `native.cgroupdriver` option,` cgroupfs` is used on cgroup v1 hosts, `systemd`
is used on cgroup v2 hosts with systemd available.
This example sets the `cgroupdriver` to `systemd`: This example sets the `cgroupdriver` to `systemd`:

2
man/docker-run.1.md
View File

@ -178,7 +178,7 @@ division of CPU shares:
Set the cgroup namespace mode for the container. Set the cgroup namespace mode for the container.
**host**: run the container in the host's cgroup namespace **host**: run the container in the host's cgroup namespace
**private**: run the container in its own private cgroup namespace **private**: run the container in its own private cgroup namespace
**""**: (unset) run the container in the host's cgroup namespace **""**: (unset) use the daemon's default configuration (**host** on cgroup v1, **private** on cgroup v2)
**--cgroup-parent**="" **--cgroup-parent**=""
Path to cgroups under which the cgroup for the container will be created. If the path is not absolute, the path is considered to be relative to the cgroups path of the init process. Cgroups will be created if they do not already exist. Path to cgroups under which the cgroup for the container will be created. If the path is not absolute, the path is considered to be relative to the cgroups path of the init process. Cgroups will be created if they do not already exist.

6
man/dockerd.8.md
View File

@ -181,7 +181,8 @@ $ sudo dockerd --add-runtime runc=runc --add-runtime custom=/usr/local/bin/my-ru
**--default-cgroupns-mode**="**host**|**private**" **--default-cgroupns-mode**="**host**|**private**"
Set the default cgroup namespace mode for newly created containers. The argument Set the default cgroup namespace mode for newly created containers. The argument
can either be **host** or **private**. If unset, this defaults to `host`. can either be **host** or **private**. If unset, this defaults to `host` on cgroup v1,
`private` on cgroup v2.
**--default-gateway**="" **--default-gateway**=""
IPv4 address of the container default gateway; this address must be part of IPv4 address of the container default gateway; this address must be part of
@ -833,7 +834,8 @@ option is available.
The `native.cgroupdriver` option specifies the management of the container's The `native.cgroupdriver` option specifies the management of the container's
cgroups. You can only specify `cgroupfs` or `systemd`. If you specify cgroups. You can only specify `cgroupfs` or `systemd`. If you specify
`systemd` and it is not available, the system errors out. If you omit the `systemd` and it is not available, the system errors out. If you omit the
`native.cgroupdriver` option,` cgroupfs` is used. `native.cgroupdriver` option,` cgroupfs` is used on cgroup v1 hosts, `systemd`
is used on cgroup v2 hosts with systemd available.
This example sets the `cgroupdriver` to `systemd`: This example sets the `cgroupdriver` to `systemd`: