mirror of https://github.com/docker/cli.git
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
parent
6ba9a3e4c9
commit
9a1ba7d39a
|
|
@ -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 \
|
||||
--blkio-weight-device "/dev/sda:200" \
|
||||
ubuntu
|
||||
```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 \
|
||||
--blkio-weight 300 \
|
||||
--blkio-weight-device "/dev/sda:200" \
|
||||
ubuntu
|
||||
```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
|
||||
crash....
|
||||
$ 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,52 +1628,54 @@ Similarly the operator can set the **HOSTNAME** (Linux) or **COMPUTERNAME** (Win
|
|||
|
||||
Example:
|
||||
|
||||
{% 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
|
||||
```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
|
||||
{
|
||||
"Status": "unhealthy",
|
||||
"FailingStreak": 3,
|
||||
"Log": [
|
||||
{
|
||||
"Status": "unhealthy",
|
||||
"FailingStreak": 3,
|
||||
"Log": [
|
||||
{
|
||||
"Start": "2016-05-25T17:22:04.635478668Z",
|
||||
"End": "2016-05-25T17:22:04.7272552Z",
|
||||
"ExitCode": 0,
|
||||
"Output": " File: /etc/passwd\n Size: 334 \tBlocks: 8 IO Block: 4096 regular file\nDevice: 32h/50d\tInode: 12 Links: 1\nAccess: (0664/-rw-rw-r--) Uid: ( 0/ root) Gid: ( 0/ root)\nAccess: 2015-12-05 22:05:32.000000000\nModify: 2015..."
|
||||
},
|
||||
{
|
||||
"Start": "2016-05-25T17:22:06.732900633Z",
|
||||
"End": "2016-05-25T17:22:06.822168935Z",
|
||||
"ExitCode": 0,
|
||||
"Output": " File: /etc/passwd\n Size: 334 \tBlocks: 8 IO Block: 4096 regular file\nDevice: 32h/50d\tInode: 12 Links: 1\nAccess: (0664/-rw-rw-r--) Uid: ( 0/ root) Gid: ( 0/ root)\nAccess: 2015-12-05 22:05:32.000000000\nModify: 2015..."
|
||||
},
|
||||
{
|
||||
"Start": "2016-05-25T17:22:08.823956535Z",
|
||||
"End": "2016-05-25T17:22:08.897359124Z",
|
||||
"ExitCode": 1,
|
||||
"Output": "stat: can't stat '/etc/passwd': No such file or directory\n"
|
||||
},
|
||||
{
|
||||
"Start": "2016-05-25T17:22:10.898802931Z",
|
||||
"End": "2016-05-25T17:22:10.969631866Z",
|
||||
"ExitCode": 1,
|
||||
"Output": "stat: can't stat '/etc/passwd': No such file or directory\n"
|
||||
},
|
||||
{
|
||||
"Start": "2016-05-25T17:22:12.971033523Z",
|
||||
"End": "2016-05-25T17:22:13.082015516Z",
|
||||
"ExitCode": 1,
|
||||
"Output": "stat: can't stat '/etc/passwd': No such file or directory\n"
|
||||
}
|
||||
]
|
||||
"Start": "2016-05-25T17:22:04.635478668Z",
|
||||
"End": "2016-05-25T17:22:04.7272552Z",
|
||||
"ExitCode": 0,
|
||||
"Output": " File: /etc/passwd\n Size: 334 \tBlocks: 8 IO Block: 4096 regular file\nDevice: 32h/50d\tInode: 12 Links: 1\nAccess: (0664/-rw-rw-r--) Uid: ( 0/ root) Gid: ( 0/ root)\nAccess: 2015-12-05 22:05:32.000000000\nModify: 2015..."
|
||||
},
|
||||
{
|
||||
"Start": "2016-05-25T17:22:06.732900633Z",
|
||||
"End": "2016-05-25T17:22:06.822168935Z",
|
||||
"ExitCode": 0,
|
||||
"Output": " File: /etc/passwd\n Size: 334 \tBlocks: 8 IO Block: 4096 regular file\nDevice: 32h/50d\tInode: 12 Links: 1\nAccess: (0664/-rw-rw-r--) Uid: ( 0/ root) Gid: ( 0/ root)\nAccess: 2015-12-05 22:05:32.000000000\nModify: 2015..."
|
||||
},
|
||||
{
|
||||
"Start": "2016-05-25T17:22:08.823956535Z",
|
||||
"End": "2016-05-25T17:22:08.897359124Z",
|
||||
"ExitCode": 1,
|
||||
"Output": "stat: can't stat '/etc/passwd': No such file or directory\n"
|
||||
},
|
||||
{
|
||||
"Start": "2016-05-25T17:22:10.898802931Z",
|
||||
"End": "2016-05-25T17:22:10.969631866Z",
|
||||
"ExitCode": 1,
|
||||
"Output": "stat: can't stat '/etc/passwd': No such file or directory\n"
|
||||
},
|
||||
{
|
||||
"Start": "2016-05-25T17:22:12.971033523Z",
|
||||
"End": "2016-05-25T17:22:13.082015516Z",
|
||||
"ExitCode": 1,
|
||||
"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
|
||||
|
|
|
|||
Loading…
Reference in New Issue