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

docs/reference/run.md: touch-up markdown 

- add code-fences with code-hints so that the right
  hightlighting is applied
- reduced number of "notes", either by combining some,
  or by changing some to regular text.
- use tables for some option lists

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit b73df4a231)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This commit is contained in:
Sebastiaan van Stijn 2020-04-19 17:10:31 +02:00
parent 6ba9a3e4c9
commit 9a1ba7d39a
No known key found for this signature in database
GPG Key ID: 76698F39D527CE8C
1 changed files with 348 additions and 198 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

464
docs/reference/run.md
View File

@ -48,7 +48,9 @@ other `docker` command.
To learn how to interpret the types of `[OPTIONS]`, see [*Option
types*](commandline/cli.md#option-types).
> **Note**: Depending on your Docker system configuration, you may be
> **Note**
>
> Depending on your Docker system configuration, you may be
> required to preface the `docker run` command with `sudo`. To avoid
> having to use `sudo` with the `docker` command, your system
> administrator can create a Unix group called `docker` and add users to
@ -128,19 +130,24 @@ If you do not specify `-a` then Docker will [attach to both stdout and stderr
You can specify to which of the three standard streams (`STDIN`, `STDOUT`,
`STDERR`) you'd like to connect instead, as in:
$ docker run -a stdin -a stdout -i -t ubuntu /bin/bash
```bash
$ docker run -a stdin -a stdout -i -t ubuntu /bin/bash
```
For interactive processes (like a shell), you must use `-i -t` together in
order to allocate a tty for the container process. `-i -t` is often written `-it`
as you'll see in later examples. Specifying `-t` is forbidden when the client
is receiving its standard input from a pipe, as in:
$ echo test | docker run -i busybox cat
```bash
$ echo test | docker run -i busybox cat
```
>**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 will not terminate on `SIGINT` or `SIGTERM` unless it is
>coded to do so.
> **Note**
>
> A process running as PID 1 inside a container is treated specially by Linux:
> it ignores any signal with the default action. As a result, the process will
> not terminate on `SIGINT` or `SIGTERM` unless it is coded to do so.
## Container identification
@ -161,8 +168,9 @@ container. If you specify a `name`, you can use it when referencing the
container within a Docker network. This works for both background and foreground
Docker containers.
> **Note**: Containers on the default bridge network must be linked to
> communicate by name.
> **Note**
>
> Containers on the default bridge network must be linked to communicate by name.
### PID equivalent
@ -188,7 +196,9 @@ the digest value is predictable and referenceable.
The following example runs a container from the `alpine` image with the
`sha256:9cacb71397b640eca97488cf08582ae4e4068513101088e9f96c9814bfda95e0` digest:
$ docker run alpine@sha256:9cacb71397b640eca97488cf08582ae4e4068513101088e9f96c9814bfda95e0 date
```bash
$ docker run alpine@sha256:9cacb71397b640eca97488cf08582ae4e4068513101088e9f96c9814bfda95e0 date
```
## PID settings (--pid)
@ -212,7 +222,7 @@ within the container.
Create this Dockerfile:
```
```dockerfile
FROM alpine:latest
RUN apk add --update htop && rm -rf /var/cache/apk/*
CMD ["htop"]
@ -226,7 +236,7 @@ $ docker build -t myhtop .
Use the following command to run `htop` inside a container:
```
```bash
$ docker run -it --rm --pid=host myhtop
```
@ -410,8 +420,10 @@ docker daemon. It is recommended to run containers in this mode when their
networking performance is critical, for example, a production Load Balancer
or a High Performance Web Server.
> **Note**: `--network="host"` gives the container full access to local system
> services such as D-bus and is therefore considered insecure.
> **Note**
>
> `--network="host"` gives the container full access to local system services
> such as D-bus and is therefore considered insecure.
#### Network: container
@ -426,9 +438,11 @@ Example running a Redis container with Redis binding to `localhost` then
running the `redis-cli` command and connecting to the Redis server over the
`localhost` interface.
$ docker run -d --name redis example/redis --bind 127.0.0.1
$ # use the redis container's network stack to access localhost
$ docker run --rm -it --network container:redis example/redis-cli -h 127.0.0.1
```bash
$ docker run -d --name redis example/redis --bind 127.0.0.1
$ # use the redis container's network stack to access localhost
$ docker run --rm -it --network container:redis example/redis-cli -h 127.0.0.1
```
#### User-defined network
@ -444,7 +458,7 @@ Engines can also communicate in this way.
The following example creates a network using the built-in `bridge` network
driver and running a container in the created network
```
```bash
$ docker network create -d bridge my-net
$ docker run --network=my-net -itd --name=container3 busybox
```
@ -455,24 +469,29 @@ Your container will have lines in `/etc/hosts` which define the hostname of the
container itself as well as `localhost` and a few other common things. The
`--add-host` flag can be used to add additional lines to `/etc/hosts`.
$ docker run -it --add-host db-static:86.75.30.9 ubuntu cat /etc/hosts
172.17.0.22 09d03f76bf2c
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
127.0.0.1 localhost
::1 localhost ip6-localhost ip6-loopback
86.75.30.9 db-static
```bash
$ docker run -it --add-host db-static:86.75.30.9 ubuntu cat /etc/hosts
172.17.0.22 09d03f76bf2c
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
127.0.0.1 localhost
::1 localhost ip6-localhost ip6-loopback
86.75.30.9 db-static
```
If a container is connected to the default bridge network and `linked`
with other containers, then the container's `/etc/hosts` file is updated
with the linked container's name.
> **Note** Since Docker may live update the container’s `/etc/hosts` file, there
may be situations when processes inside the container can end up reading an
empty or incomplete `/etc/hosts` file. In most cases, retrying the read again
should fix the problem.
> **Note**
>
> Since Docker may live update the container’s `/etc/hosts` file, there
> may be situations when processes inside the container can end up reading an
> empty or incomplete `/etc/hosts` file. In most cases, retrying the read again
> should fix the problem.
## Restart policies (--restart)
@ -548,18 +567,21 @@ will try forever to restart the container. The number of (attempted) restarts
for a container can be obtained via [`docker inspect`](commandline/inspect.md). For example, to get the number of restarts
for container "my-container";
{% raw %}
$ docker inspect -f "{{ .RestartCount }}" my-container
# 2
{% endraw %}
```bash
{% raw %}
$ docker inspect -f "{{ .RestartCount }}" my-container
# 2
{% endraw %}
```
Or, to get the last time the container was (re)started;
{% raw %}
$ docker inspect -f "{{ .State.StartedAt }}" my-container
# 2015-03-04T23:47:07.691840179Z
{% endraw %}
```bash
{% raw %}
$ docker inspect -f "{{ .State.StartedAt }}" my-container
# 2015-03-04T23:47:07.691840179Z
{% endraw %}
```
Combining `--restart` (restart policy) with the `--rm` (clean up) flag results
in an error. On container restart, attached clients are disconnected. See the
@ -567,12 +589,16 @@ examples on using the [`--rm` (clean up)](#clean-up-rm) flag later in this page.
### Examples
$ docker run --restart=always redis
```bash
$ docker run --restart=always redis
```
This will run the `redis` container with a restart policy of **always**
so that if the container exits, Docker will restart it.
$ docker run --restart=on-failure:10 redis
```bash
$ docker run --restart=on-failure:10 redis
```
This will run the `redis` container with a restart policy of **on-failure**
and a maximum restart count of 10. If the `redis` container exits with a
@ -588,27 +614,39 @@ the exit codes follow the `chroot` standard, see below:
**_125_** if the error is with Docker daemon **_itself_**
$ docker run --foo busybox; echo $?
# flag provided but not defined: --foo
See 'docker run --help'.
125
```bash
$ docker run --foo busybox; echo $?
flag provided but not defined: --foo
See 'docker run --help'.
125
```
**_126_** if the **_contained command_** cannot be invoked
$ docker run busybox /etc; echo $?
# docker: Error response from daemon: Container command '/etc' could not be invoked.
126
```bash
$ docker run busybox /etc; echo $?
docker: Error response from daemon: Container command '/etc' could not be invoked.
126
```
**_127_** if the **_contained command_** cannot be found
$ docker run busybox foo; echo $?
# docker: Error response from daemon: Container command 'foo' not found or does not exist.
127
```bash
$ docker run busybox foo; echo $?
docker: Error response from daemon: Container command 'foo' not found or does not exist.
127
```
**_Exit code_** of **_contained command_** otherwise
$ docker run busybox /bin/sh -c 'exit 3'; echo $?
# 3
```bash
$ docker run busybox /bin/sh -c 'exit 3'; echo $?
3
```
## Clean up (--rm)
@ -622,52 +660,74 @@ the container exits**, you can add the `--rm` flag:
--rm=false: Automatically remove the container when it exits
> **Note**: When 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 without a
name are removed. For example, with
`docker run --rm -v /foo -v awesome:/bar busybox top`, the volume for `/foo` will be removed,
but the volume for `/bar` will not. Volumes inherited via `--volumes-from` will be removed
with the same logic -- if the original volume was specified with a name it will **not** be removed.
> **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 without
> a name are removed. For example, when running:
>
> ```bash
> docker run --rm -v /foo -v awesome:/bar busybox top
> ```
>
> the volume for `/foo` will be removed, but the volume for `/bar` will not.
> Volumes inherited via `--volumes-from` will be removed with the same logic: if
> the original volume was specified with a name it will **not** be removed.
## Security configuration
--security-opt="label=user:USER" : Set the label user for the container
--security-opt="label=role:ROLE" : Set the label role for the container
--security-opt="label=type:TYPE" : Set the label type for the container
--security-opt="label=level:LEVEL" : Set the label level for the container
--security-opt="label=disable" : Turn off label confinement for the container
--security-opt="apparmor=PROFILE" : Set the apparmor profile to be applied to the container
--security-opt="no-new-privileges:true|false" : Disable/enable container processes from gaining new privileges
--security-opt="seccomp=unconfined" : Turn off seccomp confinement for the container
--security-opt="seccomp=profile.json": White listed syscalls seccomp Json file to be used as a seccomp filter
| Option | Description |
|:------------------------------------------|:--------------------------------------------------------------------------|
| `--security-opt="label=user:USER"` | Set the label user for the container |
| `--security-opt="label=role:ROLE"` | Set the label role for the container |
| `--security-opt="label=type:TYPE"` | Set the label type for the container |
| `--security-opt="label=level:LEVEL"` | Set the label level for the container |
| `--security-opt="label=disable"` | Turn off label confinement for the container |
| `--security-opt="apparmor=PROFILE"` | Set the apparmor profile to be applied to the container |
| `--security-opt="no-new-privileges:true"` | Disable container processes from gaining new privileges |
| `--security-opt="seccomp=unconfined"` | Turn off seccomp confinement for the container |
| `--security-opt="seccomp=profile.json"` | White-listed syscalls seccomp Json file to be used as a seccomp filter |
You can override the default labeling scheme for each container by specifying
the `--security-opt` flag. Specifying the level in the following command
allows you to share the same content between containers.
$ docker run --security-opt label=level:s0:c100,c200 -it fedora bash
```bash
$ docker run --security-opt label=level:s0:c100,c200 -it fedora bash
```
> **Note**: Automatic translation of MLS labels is not currently supported.
> **Note**
>
> Automatic translation of MLS labels is not currently supported.
To disable the security labeling for this container versus running with the
`--privileged` flag, use the following command:
$ docker run --security-opt label=disable -it fedora bash
```bash
$ docker run --security-opt label=disable -it fedora bash
```
If you want a tighter security policy on the processes within a container,
you can specify an alternate type for the container. You could run a container
that is only allowed to listen on Apache ports by executing the following
command:
$ docker run --security-opt label=type:svirt_apache_t -it centos bash
```bash
$ docker run --security-opt label=type:svirt_apache_t -it centos bash
```
> **Note**: You would have to write policy defining a `svirt_apache_t` type.
> **Note**
>
> You would have to write policy defining a `svirt_apache_t` type.
If you want to prevent your container processes from gaining additional
privileges, you can execute the following command:
$ docker run --security-opt no-new-privileges -it centos bash
```bash
$ docker run --security-opt no-new-privileges -it centos bash
```
This means that commands that raise privileges such as `su` or `sudo` will no longer work.
It also causes any seccomp filters to be applied later, after privileges have been dropped
@ -774,25 +834,33 @@ We have four ways to set user memory usage:
Examples:
$ docker run -it ubuntu:14.04 /bin/bash
```bash
$ docker run -it ubuntu:14.04 /bin/bash
```
We set nothing about memory, this means the processes in the container can use
as much memory and swap memory as they need.
$ docker run -it -m 300M --memory-swap -1 ubuntu:14.04 /bin/bash
```bash
$ docker run -it -m 300M --memory-swap -1 ubuntu:14.04 /bin/bash
```
We set memory limit and disabled swap memory limit, this means the processes in
the container can use 300M memory and as much swap memory as they need (if the
host supports swap memory).
$ docker run -it -m 300M ubuntu:14.04 /bin/bash
```bash
$ docker run -it -m 300M ubuntu:14.04 /bin/bash
```
We set memory limit only, this means the processes in the container can use
300M memory and 300M swap memory, by default, the total virtual memory size
(--memory-swap) will be set as double of memory, in this case, memory + swap
would be 2*300M, so processes can use 300M swap memory as well.
$ docker run -it -m 300M --memory-swap 1G ubuntu:14.04 /bin/bash
```bash
$ docker run -it -m 300M --memory-swap 1G ubuntu:14.04 /bin/bash
```
We set both memory and swap memory, so the processes in the container can use
300M memory and 700M swap memory.
@ -844,11 +912,15 @@ memory.
The following example limits the memory to 100M and disables the OOM killer for
this container:
$ docker run -it -m 100M --oom-kill-disable ubuntu:14.04 /bin/bash
```bash
$ docker run -it -m 100M --oom-kill-disable ubuntu:14.04 /bin/bash
```
The following example, illustrates a dangerous way to use the flag:
$ docker run -it --oom-kill-disable ubuntu:14.04 /bin/bash
```bash
$ docker run -it --oom-kill-disable ubuntu:14.04 /bin/bash
```
The container has unlimited memory which can cause the host to run out memory
and require killing system processes to free memory. The `--oom-score-adj`
@ -916,12 +988,16 @@ limit and "K" the kernel limit. There are three possible ways to set limits:
Examples:
$ docker run -it -m 500M --kernel-memory 50M ubuntu:14.04 /bin/bash
```bash
$ docker run -it -m 500M --kernel-memory 50M ubuntu:14.04 /bin/bash
```
We set memory and kernel memory, so the processes in the container can use
500M memory in total, in this 500M memory, it can be 50M kernel memory tops.
$ docker run -it --kernel-memory 50M ubuntu:14.04 /bin/bash
```bash
$ docker run -it --kernel-memory 50M ubuntu:14.04 /bin/bash
```
We set kernel memory without **-m**, so the processes in the container can
use as much memory as they want, but they can only use 50M kernel memory.
@ -936,7 +1012,9 @@ between 0 and 100. A value of 0 turns off anonymous page swapping. A value of
For example, you can set:
$ docker run -it --memory-swappiness=0 ubuntu:14.04 /bin/bash
```bash
$ docker run -it --memory-swappiness=0 ubuntu:14.04 /bin/bash
```
Setting the `--memory-swappiness` option is helpful when you want to retain the
container's working set and to avoid swapping performance penalties.
@ -985,7 +1063,9 @@ And usually `--cpu-period` should work with `--cpu-quota`.
Examples:
$ docker run -it --cpu-period=50000 --cpu-quota=25000 ubuntu:14.04 /bin/bash
```bash
$ docker run -it --cpu-period=50000 --cpu-quota=25000 ubuntu:14.04 /bin/bash
```
If there is 1 CPU, this means the container can get 50% CPU worth of run-time every 50ms.
@ -1004,11 +1084,15 @@ We can set cpus in which to allow execution for containers.
Examples:
$ docker run -it --cpuset-cpus="1,3" ubuntu:14.04 /bin/bash
```bash
$ docker run -it --cpuset-cpus="1,3" ubuntu:14.04 /bin/bash
```
This means processes in container can be executed on cpu 1 and cpu 3.
$ docker run -it --cpuset-cpus="0-2" ubuntu:14.04 /bin/bash
```bash
$ docker run -it --cpuset-cpus="0-2" ubuntu:14.04 /bin/bash
```
This means processes in container can be executed on cpu 0, cpu 1 and cpu 2.
@ -1017,12 +1101,16 @@ on NUMA systems.
Examples:
$ docker run -it --cpuset-mems="1,3" ubuntu:14.04 /bin/bash
```bash
$ docker run -it --cpuset-mems="1,3" ubuntu:14.04 /bin/bash
```
This example restricts the processes in the container to only use memory from
memory nodes 1 and 3.
$ docker run -it --cpuset-mems="0-2" ubuntu:14.04 /bin/bash
```bash
$ docker run -it --cpuset-mems="0-2" ubuntu:14.04 /bin/bash
```
This example restricts the processes in the container to only use memory from
memory nodes 0, 1 and 2.
@ -1043,19 +1131,25 @@ By default, all containers get the same proportion of block IO bandwidth
container's blkio weight relative to the weighting of all other running
containers using the `--blkio-weight` flag.
> **Note:** The blkio weight setting is only available for direct IO. Buffered IO
> is not currently supported.
> **Note:**
>
> The blkio weight setting is only available for direct IO. Buffered IO is not
> currently supported.
The `--blkio-weight` flag can set the weighting to a value between 10 to 1000.
For example, the commands below create two containers with different blkio
weight:
$ docker run -it --name c1 --blkio-weight 300 ubuntu:14.04 /bin/bash
$ docker run -it --name c2 --blkio-weight 600 ubuntu:14.04 /bin/bash
```bash
$ docker run -it --name c1 --blkio-weight 300 ubuntu:14.04 /bin/bash
$ docker run -it --name c2 --blkio-weight 600 ubuntu:14.04 /bin/bash
```
If you do block IO in the two containers at the same time, by, for example:
$ time dd if=/mnt/zerofile of=test.out bs=1M count=1024 oflag=direct
```bash
$ time dd if=/mnt/zerofile of=test.out bs=1M count=1024 oflag=direct
```
You'll find that the proportion of time is the same as the proportion of blkio
weights of the two containers.
@ -1064,9 +1158,11 @@ The `--blkio-weight-device="DEVICE_NAME:WEIGHT"` flag sets a specific device wei
The `DEVICE_NAME:WEIGHT` is a string containing a colon-separated device name and weight.
For example, to set `/dev/sda` device weight to `200`:
$ docker run -it \
```bash
$ docker run -it \
--blkio-weight-device "/dev/sda:200" \
ubuntu
```
If you specify both the `--blkio-weight` and `--blkio-weight-device`, Docker
uses the `--blkio-weight` as the default weight and uses `--blkio-weight-device`
@ -1074,22 +1170,28 @@ to override this default with a new value on a specific device.
The following example uses a default weight of `300` and overrides this default
on `/dev/sda` setting that weight to `200`:
$ docker run -it \
```bash
$ docker run -it \
--blkio-weight 300 \
--blkio-weight-device "/dev/sda:200" \
ubuntu
```
The `--device-read-bps` flag limits the read rate (bytes per second) from a device.
For example, this command creates a container and limits the read rate to `1mb`
per second from `/dev/sda`:
$ docker run -it --device-read-bps /dev/sda:1mb ubuntu
```bash
$ docker run -it --device-read-bps /dev/sda:1mb ubuntu
```
The `--device-write-bps` flag limits the write rate (bytes per second) to a device.
For example, this command creates a container and limits the write rate to `1mb`
per second for `/dev/sda`:
$ docker run -it --device-write-bps /dev/sda:1mb ubuntu
```bash
$ docker run -it --device-write-bps /dev/sda:1mb ubuntu
```
Both flags take limits in the `<device-path>:<limit>[unit]` format. Both read
and write rates must be a positive integer. You can specify the rate in `kb`
@ -1099,33 +1201,44 @@ The `--device-read-iops` flag limits read rate (IO per second) from a device.
For example, this command creates a container and limits the read rate to
`1000` IO per second from `/dev/sda`:
$ docker run -ti --device-read-iops /dev/sda:1000 ubuntu
```bash
$ docker run -ti --device-read-iops /dev/sda:1000 ubuntu
```
The `--device-write-iops` flag limits write rate (IO per second) to a device.
For example, this command creates a container and limits the write rate to
`1000` IO per second to `/dev/sda`:
$ docker run -ti --device-write-iops /dev/sda:1000 ubuntu
```bash
$ docker run -ti --device-write-iops /dev/sda:1000 ubuntu
```
Both flags take limits in the `<device-path>:<limit>` format. Both read and
write rates must be a positive integer.
## Additional groups
--group-add: Add additional groups to run as
```bash
--group-add: Add additional groups to run as
```
By default, the docker container process runs with the supplementary groups looked
up for the specified user. If one wants to add more to that list of groups, then
one can use this flag:
$ docker run --rm --group-add audio --group-add nogroup --group-add 777 busybox id
uid=0(root) gid=0(root) groups=10(wheel),29(audio),99(nogroup),777
```bash
$ docker run --rm --group-add audio --group-add nogroup --group-add 777 busybox id
uid=0(root) gid=0(root) groups=10(wheel),29(audio),99(nogroup),777
```
## Runtime privilege and Linux capabilities
--cap-add: Add Linux capabilities
--cap-drop: Drop Linux capabilities
--privileged=false: Give extended privileges to this container
--device=[]: Allows you to run devices inside the container without the --privileged flag.
| Option | Description |
|:---------------|:------------------------------------------------------------------------------|
| `--cap-add` | Add Linux capabilities |
| `--cap-drop` | Drop Linux capabilities |
| `--privileged` | Give extended privileges to this container |
| `--device=[]` | Allows you to run devices inside the container without the --privileged flag. |
By default, Docker containers are "unprivileged" and cannot, for
example, run a Docker daemon inside a Docker container. This is because
@ -1144,24 +1257,28 @@ If you want to limit access to a specific device or devices you can use
the `--device` flag. It allows you to specify one or more devices that
will be accessible within the container.
$ docker run --device=/dev/snd:/dev/snd ...
```bash
$ docker run --device=/dev/snd:/dev/snd ...
```
By default, the container will be able to `read`, `write`, and `mknod` these devices.
This can be overridden using a third `:rwm` set of options to each `--device` flag:
$ docker run --device=/dev/sda:/dev/xvdc --rm -it ubuntu fdisk /dev/xvdc
```bash
$ docker run --device=/dev/sda:/dev/xvdc --rm -it ubuntu fdisk /dev/xvdc
Command (m for help): q
$ docker run --device=/dev/sda:/dev/xvdc:r --rm -it ubuntu fdisk /dev/xvdc
You will not be able to write the partition table.
Command (m for help): q
$ docker run --device=/dev/sda:/dev/xvdc:r --rm -it ubuntu fdisk /dev/xvdc
You will not be able to write the partition table.
Command (m for help): q
Command (m for help): q
$ docker run --device=/dev/sda:/dev/xvdc:w --rm -it ubuntu fdisk /dev/xvdc
$ docker run --device=/dev/sda:/dev/xvdc:w --rm -it ubuntu fdisk /dev/xvdc
crash....
$ docker run --device=/dev/sda:/dev/xvdc:m --rm -it ubuntu fdisk /dev/xvdc
fdisk: unable to open /dev/xvdc: Operation not permitted
$ docker run --device=/dev/sda:/dev/xvdc:m --rm -it ubuntu fdisk /dev/xvdc
fdisk: unable to open /dev/xvdc: Operation not permitted
```
In addition to `--privileged`, the operator can have fine grain control over the
capabilities using `--cap-add` and `--cap-drop`. By default, Docker has a default
@ -1218,37 +1335,52 @@ Further reference information is available on the [capabilities(7) - Linux man p
Both flags support the value `ALL`, so if the
operator wants to have all capabilities but `MKNOD` they could use:
$ docker run --cap-add=ALL --cap-drop=MKNOD ...
```bash
$ docker run --cap-add=ALL --cap-drop=MKNOD ...
```
For interacting with the network stack, instead of using `--privileged` they
should use `--cap-add=NET_ADMIN` to modify the network interfaces.
$ docker run -it --rm ubuntu:14.04 ip link add dummy0 type dummy
RTNETLINK answers: Operation not permitted
$ docker run -it --rm --cap-add=NET_ADMIN ubuntu:14.04 ip link add dummy0 type dummy
```bash
$ docker run -it --rm ubuntu:14.04 ip link add dummy0 type dummy
RTNETLINK answers: Operation not permitted
$ docker run -it --rm --cap-add=NET_ADMIN ubuntu:14.04 ip link add dummy0 type dummy
```
To mount a FUSE based filesystem, you need to combine both `--cap-add` and
`--device`:
$ docker run --rm -it --cap-add SYS_ADMIN sshfs sshfs sven@10.10.10.20:/home/sven /mnt
fuse: failed to open /dev/fuse: Operation not permitted
$ docker run --rm -it --device /dev/fuse sshfs sshfs sven@10.10.10.20:/home/sven /mnt
fusermount: mount failed: Operation not permitted
$ docker run --rm -it --cap-add SYS_ADMIN --device /dev/fuse sshfs
# sshfs sven@10.10.10.20:/home/sven /mnt
The authenticity of host '10.10.10.20 (10.10.10.20)' can't be established.
ECDSA key fingerprint is 25:34:85:75:25:b0:17:46:05:19:04:93:b5:dd:5f:c6.
Are you sure you want to continue connecting (yes/no)? yes
sven@10.10.10.20's password:
root@30aa0cfaf1b5:/# ls -la /mnt/src/docker
total 1516
drwxrwxr-x 1 1000 1000 4096 Dec 4 06:08 .
drwxrwxr-x 1 1000 1000 4096 Dec 4 11:46 ..
-rw-rw-r-- 1 1000 1000 16 Oct 8 00:09 .dockerignore
-rwxrwxr-x 1 1000 1000 464 Oct 8 00:09 .drone.yml
drwxrwxr-x 1 1000 1000 4096 Dec 4 06:11 .git
-rw-rw-r-- 1 1000 1000 461 Dec 4 06:08 .gitignore
....
```bash
$ docker run --rm -it --cap-add SYS_ADMIN sshfs sshfs sven@10.10.10.20:/home/sven /mnt
fuse: failed to open /dev/fuse: Operation not permitted
$ docker run --rm -it --device /dev/fuse sshfs sshfs sven@10.10.10.20:/home/sven /mnt
fusermount: mount failed: Operation not permitted
$ docker run --rm -it --cap-add SYS_ADMIN --device /dev/fuse sshfs
# sshfs sven@10.10.10.20:/home/sven /mnt
The authenticity of host '10.10.10.20 (10.10.10.20)' can't be established.
ECDSA key fingerprint is 25:34:85:75:25:b0:17:46:05:19:04:93:b5:dd:5f:c6.
Are you sure you want to continue connecting (yes/no)? yes
sven@10.10.10.20's password:
root@30aa0cfaf1b5:/# ls -la /mnt/src/docker
total 1516
drwxrwxr-x 1 1000 1000 4096 Dec 4 06:08 .
drwxrwxr-x 1 1000 1000 4096 Dec 4 11:46 ..
-rw-rw-r-- 1 1000 1000 16 Oct 8 00:09 .dockerignore
-rwxrwxr-x 1 1000 1000 464 Oct 8 00:09 .drone.yml
drwxrwxr-x 1 1000 1000 4096 Dec 4 06:11 .git
-rw-rw-r-- 1 1000 1000 461 Dec 4 06:08 .gitignore
....
```
The default seccomp profile will adjust to the selected capabilities, in order to allow
use of facilities allowed by the capabilities, so you should not have to adjust this,
@ -1304,7 +1436,9 @@ Dockerfile instruction and how the operator can override that setting.
Recall the optional `COMMAND` in the Docker
commandline:
$ docker run [OPTIONS] IMAGE[:TAG|@DIGEST] [COMMAND] [ARG...]
```bash
$ docker run [OPTIONS] IMAGE[:TAG|@DIGEST] [COMMAND] [ARG...]
```
This command is optional because the person who created the `IMAGE` may
have already provided a default `COMMAND` using the Dockerfile `CMD`
@ -1317,7 +1451,9 @@ get appended as arguments to the `ENTRYPOINT`.
### ENTRYPOINT (default command to execute at runtime)
```bash
--entrypoint="": Overwrite the default entrypoint set by the image
```
The `ENTRYPOINT` of an image is similar to a `COMMAND` because it
specifies what executable to run when the container starts, but it is
@ -1331,18 +1467,26 @@ runtime by using a string to specify the new `ENTRYPOINT`. Here is an
example of how to run a shell in a container that has been set up to
automatically run something else (like `/usr/bin/redis-server`):
$ docker run -it --entrypoint /bin/bash example/redis
```bash
$ docker run -it --entrypoint /bin/bash example/redis
```
or two examples of how to pass more parameters to that ENTRYPOINT:
$ docker run -it --entrypoint /bin/bash example/redis -c ls -l
$ docker run -it --entrypoint /usr/bin/redis-cli example/redis --help
```bash
$ docker run -it --entrypoint /bin/bash example/redis -c ls -l
$ docker run -it --entrypoint /usr/bin/redis-cli example/redis --help
```
You can reset a containers entrypoint by passing an empty string, for example:
$ docker run -it --entrypoint="" mysql bash
```bash
$ docker run -it --entrypoint="" mysql bash
```
> **Note**: Passing `--entrypoint` will clear out any default command set on the
> **Note**
>
> Passing `--entrypoint` will clear out any default command set on the
> image (i.e. any `CMD` instruction in the Dockerfile used to build it).
### EXPOSE (incoming ports)
@ -1426,6 +1570,7 @@ current value of the named variable is propagated into the container's environme
```bash
$ export today=Wednesday
$ docker run -e "deep=purple" -e today --rm alpine env
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
HOSTNAME=d2219b854598
deep=purple
@ -1483,16 +1628,17 @@ Similarly the operator can set the **HOSTNAME** (Linux) or **COMPUTERNAME** (Win
Example:
{% raw %}
$ docker run --name=test -d \
```bash
{% raw %}
$ docker run --name=test -d \
--health-cmd='stat /etc/passwd || exit 1' \
--health-interval=2s \
busybox sleep 1d
$ sleep 2; docker inspect --format='{{.State.Health.Status}}' test
healthy
$ docker exec test rm /etc/passwd
$ sleep 2; docker inspect --format='{{json .State.Health}}' test
{
$ sleep 2; docker inspect --format='{{.State.Health.Status}}' test
healthy
$ docker exec test rm /etc/passwd
$ sleep 2; docker inspect --format='{{json .State.Health}}' test
{
"Status": "unhealthy",
"FailingStreak": 3,
"Log": [
@ -1527,8 +1673,9 @@ Example:
"Output": "stat: can't stat '/etc/passwd': No such file or directory\n"
}
]
}
{% endraw %}
}
{% endraw %}
```
The health status is also displayed in the `docker ps` output.
@ -1543,7 +1690,9 @@ The health status is also displayed in the `docker ps` output.
The example below mounts an empty tmpfs into the container with the `rw`,
`noexec`, `nosuid`, and `size=65536k` options.
$ docker run -d --tmpfs /run:rw,noexec,nosuid,size=65536k my_image
```bash
$ docker run -d --tmpfs /run:rw,noexec,nosuid,size=65536k my_image
```
### VOLUME (shared filesystems)
@ -1562,7 +1711,8 @@ The example below mounts an empty tmpfs into the container with the `rw`,
--volumes-from="": Mount all volumes from the given container(s)
> **Note**:
> **Note**
>
> When using systemd to manage the Docker daemon's start and stop, in the systemd
> unit file there is an option to control mount propagation for the Docker daemon
> itself, called `MountFlags`. The value of this setting may cause Docker to not