mirror of https://github.com/docker/cli.git
First pass at consolidating
Removing old networking.md Updating dockernetworks.md with images Adding information on network plugins Adding blurb about links to docker networking Updating the working documentation Adding Overlay Getting Started Downplaying links by removing refs/examples, adding refs/examples for network. Updating getting started to reflect networks not links Pulling out old network material Updating per discussion with Madhu to add Default docs section Updating with bridge default Fix bad merge Updating with new cluster-advertise behavior Update working and NetworkSettings examples Correcting example for default bridge discovery behavior Entering comments Fixing broken Markdown Syntax Updating with comments Updating all the links Signed-off-by: Mary Anthony <mary@docker.com>
This commit is contained in:
parent
05242a4c60
commit
02a859b9f3
|
@ -18,9 +18,8 @@ plugins.
|
||||||
|
|
||||||
Plugins extend Docker's functionality. They come in specific types. For
|
Plugins extend Docker's functionality. They come in specific types. For
|
||||||
example, a [volume plugin](plugins_volume.md) might enable Docker
|
example, a [volume plugin](plugins_volume.md) might enable Docker
|
||||||
volumes to persist across multiple Docker hosts and a
|
volumes to persist across multiple Docker hosts and a
|
||||||
[network plugin](plugins_network.md) might provide network plumbing
|
[network plugin](plugins_network.md) might provide network plumbing.
|
||||||
using a favorite networking technology, such as vxlan overlay, ipvlan, EVPN, etc.
|
|
||||||
|
|
||||||
Currently Docker supports volume and network driver plugins. In the future it
|
Currently Docker supports volume and network driver plugins. In the future it
|
||||||
will support additional plugin types.
|
will support additional plugin types.
|
||||||
|
|
|
@ -1,7 +1,7 @@
|
||||||
<!--[metadata]>
|
<!--[metadata]>
|
||||||
+++
|
+++
|
||||||
title = "Docker network driver plugins"
|
title = "Docker network driver plugins"
|
||||||
description = "Network drive plugins."
|
description = "Network driver plugins."
|
||||||
keywords = ["Examples, Usage, plugins, docker, documentation, user guide"]
|
keywords = ["Examples, Usage, plugins, docker, documentation, user guide"]
|
||||||
[menu.main]
|
[menu.main]
|
||||||
parent = "mn_extend"
|
parent = "mn_extend"
|
||||||
|
@ -11,41 +11,48 @@ weight=-1
|
||||||
|
|
||||||
# Docker network driver plugins
|
# Docker network driver plugins
|
||||||
|
|
||||||
Docker supports network driver plugins via
|
Docker network plugins enable Docker deployments to be extended to support a
|
||||||
[LibNetwork](https://github.com/docker/libnetwork). Network driver plugins are
|
wide range of networking technologies, such as VXLAN, IPVLAN, MACVLAN or
|
||||||
implemented as "remote drivers" for LibNetwork, which shares plugin
|
something completely different. Network driver plugins are supported via the
|
||||||
infrastructure with Docker. In effect this means that network driver plugins
|
LibNetwork project. Each plugin is implemented asa "remote driver" for
|
||||||
are activated in the same way as other plugins, and use the same kind of
|
LibNetwork, which shares plugin infrastructure with Docker. Effectively,
|
||||||
protocol.
|
network driver plugins are activated in the same way as other plugins, and use
|
||||||
|
the same kind of protocol.
|
||||||
|
|
||||||
## Using network driver plugins
|
## Using network driver plugins
|
||||||
|
|
||||||
The means of installing and running a network driver plugin will depend on the
|
The means of installing and running a network driver plugin depend on the
|
||||||
particular plugin.
|
particular plugin. So, be sure to install your plugin according to the
|
||||||
|
instructions obtained from the plugin developer.
|
||||||
|
|
||||||
Once running however, network driver plugins are used just like the built-in
|
Once running however, network driver plugins are used just like the built-in
|
||||||
network drivers: by being mentioned as a driver in network-oriented Docker
|
network drivers: by being mentioned as a driver in network-oriented Docker
|
||||||
commands. For example,
|
commands. For example,
|
||||||
|
|
||||||
docker network create -d weave mynet
|
$ docker network create --driver weave mynet
|
||||||
|
|
||||||
Some network driver plugins are listed in [plugins](plugins.md)
|
Some network driver plugins are listed in [plugins](plugins.md)
|
||||||
|
|
||||||
The network thus created is owned by the plugin, so subsequent commands
|
The `mynet` network is now owned by `weave`, so subsequent commands
|
||||||
referring to that network will also be run through the plugin such as,
|
referring to that network will be sent to the plugin,
|
||||||
|
|
||||||
docker run --net=mynet busybox top
|
$ docker run --net=mynet busybox top
|
||||||
|
|
||||||
## Network driver plugin protocol
|
|
||||||
|
|
||||||
The network driver protocol, additional to the plugin activation call, is
|
## Write a network plugin
|
||||||
documented as part of LibNetwork:
|
|
||||||
|
Network plugins implement the [Docker plugin
|
||||||
|
API](https://docs.docker.com/extend/plugin_api/) and the network plugin protocol
|
||||||
|
|
||||||
|
## Network plugin protocol
|
||||||
|
|
||||||
|
The network driver protocol, in addition to the plugin activation call, is
|
||||||
|
documented as part of libnetwork:
|
||||||
[https://github.com/docker/libnetwork/blob/master/docs/remote.md](https://github.com/docker/libnetwork/blob/master/docs/remote.md).
|
[https://github.com/docker/libnetwork/blob/master/docs/remote.md](https://github.com/docker/libnetwork/blob/master/docs/remote.md).
|
||||||
|
|
||||||
# Related GitHub PRs and issues
|
# Related Information
|
||||||
|
|
||||||
Please record your feedback in the following issue, on the usual
|
To interact with the Docker maintainers and other interested users, se the IRC channel `#docker-network`.
|
||||||
Google Groups, or the IRC channel #docker-network.
|
|
||||||
|
|
||||||
- [#14083](https://github.com/docker/docker/issues/14083) Feedback on
|
- [Docker networks feature overview](../userguide/networking/index.md)
|
||||||
experimental networking features
|
- The [LibNetwork](https://github.com/docker/libnetwork) project
|
||||||
|
|
|
@ -43,7 +43,7 @@ Dockerfile.
|
||||||
|
|
||||||
>**Warning**: Do not use your root directory, `/`, as the `PATH` as it causes
|
>**Warning**: Do not use your root directory, `/`, as the `PATH` as it causes
|
||||||
>the build to transfer the entire contents of your hard drive to the Docker
|
>the build to transfer the entire contents of your hard drive to the Docker
|
||||||
>daemon.
|
>daemon.
|
||||||
|
|
||||||
To use a file in the build context, the `Dockerfile` refers to the file specified
|
To use a file in the build context, the `Dockerfile` refers to the file specified
|
||||||
in an instruction, for example, a `COPY` instruction. To increase the build's
|
in an instruction, for example, a `COPY` instruction. To increase the build's
|
||||||
|
@ -159,7 +159,7 @@ Example (parsed representation is displayed after the `#`):
|
||||||
ADD . $foo # ADD . /bar
|
ADD . $foo # ADD . /bar
|
||||||
COPY \$foo /quux # COPY $foo /quux
|
COPY \$foo /quux # COPY $foo /quux
|
||||||
|
|
||||||
Environment variables are supported by the following list of instructions in
|
Environment variables are supported by the following list of instructions in
|
||||||
the `Dockerfile`:
|
the `Dockerfile`:
|
||||||
|
|
||||||
* `ADD`
|
* `ADD`
|
||||||
|
@ -177,7 +177,7 @@ as well as:
|
||||||
* `ONBUILD` (when combined with one of the supported instructions above)
|
* `ONBUILD` (when combined with one of the supported instructions above)
|
||||||
|
|
||||||
> **Note**:
|
> **Note**:
|
||||||
> prior to 1.4, `ONBUILD` instructions did **NOT** support environment
|
> prior to 1.4, `ONBUILD` instructions did **NOT** support environment
|
||||||
> variable, even when combined with any of the instructions listed above.
|
> variable, even when combined with any of the instructions listed above.
|
||||||
|
|
||||||
Environment variable substitution will use the same value for each variable
|
Environment variable substitution will use the same value for each variable
|
||||||
|
@ -187,7 +187,7 @@ throughout the entire command. In other words, in this example:
|
||||||
ENV abc=bye def=$abc
|
ENV abc=bye def=$abc
|
||||||
ENV ghi=$abc
|
ENV ghi=$abc
|
||||||
|
|
||||||
will result in `def` having a value of `hello`, not `bye`. However,
|
will result in `def` having a value of `hello`, not `bye`. However,
|
||||||
`ghi` will have a value of `bye` because it is not part of the same command
|
`ghi` will have a value of `bye` because it is not part of the same command
|
||||||
that set `abc` to `bye`.
|
that set `abc` to `bye`.
|
||||||
|
|
||||||
|
@ -354,13 +354,13 @@ RUN /bin/bash -c 'source $HOME/.bashrc ; echo $HOME'
|
||||||
> Unlike the *shell* form, the *exec* form does not invoke a command shell.
|
> Unlike the *shell* form, the *exec* form does not invoke a command shell.
|
||||||
> This means that normal shell processing does not happen. For example,
|
> This means that normal shell processing does not happen. For example,
|
||||||
> `RUN [ "echo", "$HOME" ]` will not do variable substitution on `$HOME`.
|
> `RUN [ "echo", "$HOME" ]` will not do variable substitution on `$HOME`.
|
||||||
> If you want shell processing then either use the *shell* form or execute
|
> If you want shell processing then either use the *shell* form or execute
|
||||||
> a shell directly, for example: `RUN [ "sh", "-c", "echo", "$HOME" ]`.
|
> a shell directly, for example: `RUN [ "sh", "-c", "echo", "$HOME" ]`.
|
||||||
|
|
||||||
The cache for `RUN` instructions isn't invalidated automatically during
|
The cache for `RUN` instructions isn't invalidated automatically during
|
||||||
the next build. The cache for an instruction like
|
the next build. The cache for an instruction like
|
||||||
`RUN apt-get dist-upgrade -y` will be reused during the next build. The
|
`RUN apt-get dist-upgrade -y` will be reused during the next build. The
|
||||||
cache for `RUN` instructions can be invalidated by using the `--no-cache`
|
cache for `RUN` instructions can be invalidated by using the `--no-cache`
|
||||||
flag, for example `docker build --no-cache`.
|
flag, for example `docker build --no-cache`.
|
||||||
|
|
||||||
See the [`Dockerfile` Best Practices
|
See the [`Dockerfile` Best Practices
|
||||||
|
@ -399,8 +399,8 @@ the executable, in which case you must specify an `ENTRYPOINT`
|
||||||
instruction as well.
|
instruction as well.
|
||||||
|
|
||||||
> **Note**:
|
> **Note**:
|
||||||
> If `CMD` is used to provide default arguments for the `ENTRYPOINT`
|
> If `CMD` is used to provide default arguments for the `ENTRYPOINT`
|
||||||
> instruction, both the `CMD` and `ENTRYPOINT` instructions should be specified
|
> instruction, both the `CMD` and `ENTRYPOINT` instructions should be specified
|
||||||
> with the JSON array format.
|
> with the JSON array format.
|
||||||
|
|
||||||
> **Note**:
|
> **Note**:
|
||||||
|
@ -411,7 +411,7 @@ instruction as well.
|
||||||
> Unlike the *shell* form, the *exec* form does not invoke a command shell.
|
> Unlike the *shell* form, the *exec* form does not invoke a command shell.
|
||||||
> This means that normal shell processing does not happen. For example,
|
> This means that normal shell processing does not happen. For example,
|
||||||
> `CMD [ "echo", "$HOME" ]` will not do variable substitution on `$HOME`.
|
> `CMD [ "echo", "$HOME" ]` will not do variable substitution on `$HOME`.
|
||||||
> If you want shell processing then either use the *shell* form or execute
|
> If you want shell processing then either use the *shell* form or execute
|
||||||
> a shell directly, for example: `CMD [ "sh", "-c", "echo", "$HOME" ]`.
|
> a shell directly, for example: `CMD [ "sh", "-c", "echo", "$HOME" ]`.
|
||||||
|
|
||||||
When used in the shell or exec formats, the `CMD` instruction sets the command
|
When used in the shell or exec formats, the `CMD` instruction sets the command
|
||||||
|
@ -461,7 +461,7 @@ An image can have more than one label. To specify multiple labels,
|
||||||
Docker recommends combining labels into a single `LABEL` instruction where
|
Docker recommends combining labels into a single `LABEL` instruction where
|
||||||
possible. Each `LABEL` instruction produces a new layer which can result in an
|
possible. Each `LABEL` instruction produces a new layer which can result in an
|
||||||
inefficient image if you use many labels. This example results in a single image
|
inefficient image if you use many labels. This example results in a single image
|
||||||
layer.
|
layer.
|
||||||
|
|
||||||
LABEL multi.label1="value1" multi.label2="value2" other="value3"
|
LABEL multi.label1="value1" multi.label2="value2" other="value3"
|
||||||
|
|
||||||
|
@ -470,7 +470,7 @@ The above can also be written as:
|
||||||
LABEL multi.label1="value1" \
|
LABEL multi.label1="value1" \
|
||||||
multi.label2="value2" \
|
multi.label2="value2" \
|
||||||
other="value3"
|
other="value3"
|
||||||
|
|
||||||
Labels are additive including `LABEL`s in `FROM` images. If Docker
|
Labels are additive including `LABEL`s in `FROM` images. If Docker
|
||||||
encounters a label/key that already exists, the new value overrides any previous
|
encounters a label/key that already exists, the new value overrides any previous
|
||||||
labels with identical keys.
|
labels with identical keys.
|
||||||
|
@ -494,12 +494,15 @@ To view an image's labels, use the `docker inspect` command.
|
||||||
The `EXPOSE` instruction informs Docker that the container listens on the
|
The `EXPOSE` instruction informs Docker that the container listens on the
|
||||||
specified network ports at runtime. `EXPOSE` does not make the ports of the
|
specified network ports at runtime. `EXPOSE` does not make the ports of the
|
||||||
container accessible to the host. To do that, you must use either the `-p` flag
|
container accessible to the host. To do that, you must use either the `-p` flag
|
||||||
to publish a range of ports or the `-P` flag to publish all of the exposed ports.
|
to publish a range of ports or the `-P` flag to publish all of the exposed
|
||||||
You can expose one port number and publish it externally under another number.
|
ports. You can expose one port number and publish it externally under another
|
||||||
|
number.
|
||||||
Docker uses exposed and published ports to interconnect containers using links
|
|
||||||
(see [Linking containers together](../userguide/dockerlinks.md))
|
To set up port redirection on the host system, see [using the -P
|
||||||
and to set up port redirection on the host system when [using the -P flag](run.md#expose-incoming-ports).
|
flag](run.md#expose-incoming-ports). The Docker network feature supports
|
||||||
|
creating networks without the need to expose ports within the network, for
|
||||||
|
detailed information see the [overview of this
|
||||||
|
feature](../userguide/networking/index.md)).
|
||||||
|
|
||||||
## ENV
|
## ENV
|
||||||
|
|
||||||
|
@ -507,17 +510,18 @@ and to set up port redirection on the host system when [using the -P flag](run.m
|
||||||
ENV <key>=<value> ...
|
ENV <key>=<value> ...
|
||||||
|
|
||||||
The `ENV` instruction sets the environment variable `<key>` to the value
|
The `ENV` instruction sets the environment variable `<key>` to the value
|
||||||
`<value>`. This value will be in the environment of all "descendent" `Dockerfile`
|
`<value>`. This value will be in the environment of all "descendent"
|
||||||
commands and can be [replaced inline](#environment-replacement) in many as well.
|
`Dockerfile` commands and can be [replaced inline](#environment-replacement) in
|
||||||
|
many as well.
|
||||||
|
|
||||||
The `ENV` instruction has two forms. The first form, `ENV <key> <value>`,
|
The `ENV` instruction has two forms. The first form, `ENV <key> <value>`,
|
||||||
will set a single variable to a value. The entire string after the first
|
will set a single variable to a value. The entire string after the first
|
||||||
space will be treated as the `<value>` - including characters such as
|
space will be treated as the `<value>` - including characters such as
|
||||||
spaces and quotes.
|
spaces and quotes.
|
||||||
|
|
||||||
The second form, `ENV <key>=<value> ...`, allows for multiple variables to
|
The second form, `ENV <key>=<value> ...`, allows for multiple variables to
|
||||||
be set at one time. Notice that the second form uses the equals sign (=)
|
be set at one time. Notice that the second form uses the equals sign (=)
|
||||||
in the syntax, while the first form does not. Like command line parsing,
|
in the syntax, while the first form does not. Like command line parsing,
|
||||||
quotes and backslashes can be used to include spaces within values.
|
quotes and backslashes can be used to include spaces within values.
|
||||||
|
|
||||||
For example:
|
For example:
|
||||||
|
@ -531,7 +535,7 @@ and
|
||||||
ENV myDog Rex The Dog
|
ENV myDog Rex The Dog
|
||||||
ENV myCat fluffy
|
ENV myCat fluffy
|
||||||
|
|
||||||
will yield the same net results in the final container, but the first form
|
will yield the same net results in the final container, but the first form
|
||||||
is preferred because it produces a single cache layer.
|
is preferred because it produces a single cache layer.
|
||||||
|
|
||||||
The environment variables set using `ENV` will persist when a container is run
|
The environment variables set using `ENV` will persist when a container is run
|
||||||
|
@ -555,8 +559,8 @@ whitespace)
|
||||||
The `ADD` instruction copies new files, directories or remote file URLs from `<src>`
|
The `ADD` instruction copies new files, directories or remote file URLs from `<src>`
|
||||||
and adds them to the filesystem of the container at the path `<dest>`.
|
and adds them to the filesystem of the container at the path `<dest>`.
|
||||||
|
|
||||||
Multiple `<src>` resource may be specified but if they are files or
|
Multiple `<src>` resource may be specified but if they are files or
|
||||||
directories then they must be relative to the source directory that is
|
directories then they must be relative to the source directory that is
|
||||||
being built (the context of the build).
|
being built (the context of the build).
|
||||||
|
|
||||||
Each `<src>` may contain wildcards and matching will be done using Go's
|
Each `<src>` may contain wildcards and matching will be done using Go's
|
||||||
|
@ -619,8 +623,8 @@ guide](../articles/dockerfile_best-practices.md#build-cache) for more informatio
|
||||||
appropriate filename can be discovered in this case (`http://example.com`
|
appropriate filename can be discovered in this case (`http://example.com`
|
||||||
will not work).
|
will not work).
|
||||||
|
|
||||||
- If `<src>` is a directory, the entire contents of the directory are copied,
|
- If `<src>` is a directory, the entire contents of the directory are copied,
|
||||||
including filesystem metadata.
|
including filesystem metadata.
|
||||||
|
|
||||||
> **Note**:
|
> **Note**:
|
||||||
> The directory itself is not copied, just its contents.
|
> The directory itself is not copied, just its contents.
|
||||||
|
@ -640,7 +644,7 @@ guide](../articles/dockerfile_best-practices.md#build-cache) for more informatio
|
||||||
at `<dest>/base(<src>)`.
|
at `<dest>/base(<src>)`.
|
||||||
|
|
||||||
- If multiple `<src>` resources are specified, either directly or due to the
|
- If multiple `<src>` resources are specified, either directly or due to the
|
||||||
use of a wildcard, then `<dest>` must be a directory, and it must end with
|
use of a wildcard, then `<dest>` must be a directory, and it must end with
|
||||||
a slash `/`.
|
a slash `/`.
|
||||||
|
|
||||||
- If `<dest>` does not end with a trailing slash, it will be considered a
|
- If `<dest>` does not end with a trailing slash, it will be considered a
|
||||||
|
@ -688,8 +692,8 @@ All new files and directories are created with a UID and GID of 0.
|
||||||
`docker build` is to send the context directory (and subdirectories) to the
|
`docker build` is to send the context directory (and subdirectories) to the
|
||||||
docker daemon.
|
docker daemon.
|
||||||
|
|
||||||
- If `<src>` is a directory, the entire contents of the directory are copied,
|
- If `<src>` is a directory, the entire contents of the directory are copied,
|
||||||
including filesystem metadata.
|
including filesystem metadata.
|
||||||
|
|
||||||
> **Note**:
|
> **Note**:
|
||||||
> The directory itself is not copied, just its contents.
|
> The directory itself is not copied, just its contents.
|
||||||
|
@ -700,7 +704,7 @@ All new files and directories are created with a UID and GID of 0.
|
||||||
at `<dest>/base(<src>)`.
|
at `<dest>/base(<src>)`.
|
||||||
|
|
||||||
- If multiple `<src>` resources are specified, either directly or due to the
|
- If multiple `<src>` resources are specified, either directly or due to the
|
||||||
use of a wildcard, then `<dest>` must be a directory, and it must end with
|
use of a wildcard, then `<dest>` must be a directory, and it must end with
|
||||||
a slash `/`.
|
a slash `/`.
|
||||||
|
|
||||||
- If `<dest>` does not end with a trailing slash, it will be considered a
|
- If `<dest>` does not end with a trailing slash, it will be considered a
|
||||||
|
@ -729,7 +733,7 @@ Command line arguments to `docker run <image>` will be appended after all
|
||||||
elements in an *exec* form `ENTRYPOINT`, and will override all elements specified
|
elements in an *exec* form `ENTRYPOINT`, and will override all elements specified
|
||||||
using `CMD`.
|
using `CMD`.
|
||||||
This allows arguments to be passed to the entry point, i.e., `docker run <image> -d`
|
This allows arguments to be passed to the entry point, i.e., `docker run <image> -d`
|
||||||
will pass the `-d` argument to the entry point.
|
will pass the `-d` argument to the entry point.
|
||||||
You can override the `ENTRYPOINT` instruction using the `docker run --entrypoint`
|
You can override the `ENTRYPOINT` instruction using the `docker run --entrypoint`
|
||||||
flag.
|
flag.
|
||||||
|
|
||||||
|
@ -760,10 +764,10 @@ When you run the container, you can see that `top` is the only process:
|
||||||
%Cpu(s): 0.1 us, 0.1 sy, 0.0 ni, 99.7 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
|
%Cpu(s): 0.1 us, 0.1 sy, 0.0 ni, 99.7 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
|
||||||
KiB Mem: 2056668 total, 1616832 used, 439836 free, 99352 buffers
|
KiB Mem: 2056668 total, 1616832 used, 439836 free, 99352 buffers
|
||||||
KiB Swap: 1441840 total, 0 used, 1441840 free. 1324440 cached Mem
|
KiB Swap: 1441840 total, 0 used, 1441840 free. 1324440 cached Mem
|
||||||
|
|
||||||
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
|
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
|
||||||
1 root 20 0 19744 2336 2080 R 0.0 0.1 0:00.04 top
|
1 root 20 0 19744 2336 2080 R 0.0 0.1 0:00.04 top
|
||||||
|
|
||||||
To examine the result further, you can use `docker exec`:
|
To examine the result further, you can use `docker exec`:
|
||||||
|
|
||||||
$ docker exec -it test ps aux
|
$ docker exec -it test ps aux
|
||||||
|
@ -867,7 +871,7 @@ sys 0m 0.03s
|
||||||
> Unlike the *shell* form, the *exec* form does not invoke a command shell.
|
> Unlike the *shell* form, the *exec* form does not invoke a command shell.
|
||||||
> This means that normal shell processing does not happen. For example,
|
> This means that normal shell processing does not happen. For example,
|
||||||
> `ENTRYPOINT [ "echo", "$HOME" ]` will not do variable substitution on `$HOME`.
|
> `ENTRYPOINT [ "echo", "$HOME" ]` will not do variable substitution on `$HOME`.
|
||||||
> If you want shell processing then either use the *shell* form or execute
|
> If you want shell processing then either use the *shell* form or execute
|
||||||
> a shell directly, for example: `ENTRYPOINT [ "sh", "-c", "echo", "$HOME" ]`.
|
> a shell directly, for example: `ENTRYPOINT [ "sh", "-c", "echo", "$HOME" ]`.
|
||||||
> Variables that are defined in the `Dockerfile`using `ENV`, will be substituted by
|
> Variables that are defined in the `Dockerfile`using `ENV`, will be substituted by
|
||||||
> the `Dockerfile` parser.
|
> the `Dockerfile` parser.
|
||||||
|
@ -941,12 +945,12 @@ and marks it as holding externally mounted volumes from native host or other
|
||||||
containers. The value can be a JSON array, `VOLUME ["/var/log/"]`, or a plain
|
containers. The value can be a JSON array, `VOLUME ["/var/log/"]`, or a plain
|
||||||
string with multiple arguments, such as `VOLUME /var/log` or `VOLUME /var/log
|
string with multiple arguments, such as `VOLUME /var/log` or `VOLUME /var/log
|
||||||
/var/db`. For more information/examples and mounting instructions via the
|
/var/db`. For more information/examples and mounting instructions via the
|
||||||
Docker client, refer to
|
Docker client, refer to
|
||||||
[*Share Directories via Volumes*](../userguide/dockervolumes.md#mount-a-host-directory-as-a-data-volume)
|
[*Share Directories via Volumes*](../userguide/dockervolumes.md#mount-a-host-directory-as-a-data-volume)
|
||||||
documentation.
|
documentation.
|
||||||
|
|
||||||
The `docker run` command initializes the newly created volume with any data
|
The `docker run` command initializes the newly created volume with any data
|
||||||
that exists at the specified location within the base image. For example,
|
that exists at the specified location within the base image. For example,
|
||||||
consider the following Dockerfile snippet:
|
consider the following Dockerfile snippet:
|
||||||
|
|
||||||
FROM ubuntu
|
FROM ubuntu
|
||||||
|
@ -955,7 +959,7 @@ consider the following Dockerfile snippet:
|
||||||
VOLUME /myvol
|
VOLUME /myvol
|
||||||
|
|
||||||
This Dockerfile results in an image that causes `docker run`, to
|
This Dockerfile results in an image that causes `docker run`, to
|
||||||
create a new mount point at `/myvol` and copy the `greeting` file
|
create a new mount point at `/myvol` and copy the `greeting` file
|
||||||
into the newly created volume.
|
into the newly created volume.
|
||||||
|
|
||||||
> **Note**:
|
> **Note**:
|
||||||
|
|
|
@ -22,7 +22,7 @@ The `docker attach` command allows you to attach to a running container using
|
||||||
the container's ID or name, either to view its ongoing output or to control it
|
the container's ID or name, either to view its ongoing output or to control it
|
||||||
interactively. You can attach to the same contained process multiple times
|
interactively. You can attach to the same contained process multiple times
|
||||||
simultaneously, screen sharing style, or quickly view the progress of your
|
simultaneously, screen sharing style, or quickly view the progress of your
|
||||||
daemonized process.
|
detached process.
|
||||||
|
|
||||||
You can detach from the container and leave it running with `CTRL-p CTRL-q`
|
You can detach from the container and leave it running with `CTRL-p CTRL-q`
|
||||||
(for a quiet exit) or with `CTRL-c` if `--sig-proxy` is false.
|
(for a quiet exit) or with `CTRL-c` if `--sig-proxy` is false.
|
||||||
|
|
|
@ -23,7 +23,7 @@ weight = -1
|
||||||
--default-gateway="" Container default gateway IPv4 address
|
--default-gateway="" Container default gateway IPv4 address
|
||||||
--default-gateway-v6="" Container default gateway IPv6 address
|
--default-gateway-v6="" Container default gateway IPv6 address
|
||||||
--cluster-store="" URL of the distributed storage backend
|
--cluster-store="" URL of the distributed storage backend
|
||||||
--cluster-advertise="" Address of the daemon instance to advertise
|
--cluster-advertise="" Address of the daemon instance on the cluster
|
||||||
--cluster-store-opt=map[] Set cluster options
|
--cluster-store-opt=map[] Set cluster options
|
||||||
--dns=[] DNS server to use
|
--dns=[] DNS server to use
|
||||||
--dns-opt=[] DNS options to use
|
--dns-opt=[] DNS options to use
|
||||||
|
@ -547,13 +547,16 @@ please check the [run](run.md) reference.
|
||||||
|
|
||||||
## Nodes discovery
|
## Nodes discovery
|
||||||
|
|
||||||
`--cluster-advertise` specifies the 'host:port' combination that this particular
|
The `--cluster-advertise` option specifies the 'host:port' or `interface:port`
|
||||||
daemon instance should use when advertising itself to the cluster. The daemon
|
combination that this particular daemon instance should use when advertising
|
||||||
is reached by remote hosts on this 'host:port' combination.
|
itself to the cluster. The daemon is reached by remote hosts through this value.
|
||||||
|
If you specify an interface, make sure it includes the IP address of the actual
|
||||||
|
Docker host. For Engine installation created through `docker-machine`, the
|
||||||
|
interface is typically `eth1`.
|
||||||
|
|
||||||
The daemon uses [libkv](https://github.com/docker/libkv/) to advertise
|
The daemon uses [libkv](https://github.com/docker/libkv/) to advertise
|
||||||
the node within the cluster. Some Key/Value backends support mutual
|
the node within the cluster. Some key-value backends support mutual
|
||||||
TLS, and the client TLS settings used by the daemon can be configured
|
TLS. To configure the client TLS settings used by the daemon can be configured
|
||||||
using the `--cluster-store-opt` flag, specifying the paths to PEM encoded
|
using the `--cluster-store-opt` flag, specifying the paths to PEM encoded
|
||||||
files. For example:
|
files. For example:
|
||||||
|
|
||||||
|
|
|
@ -33,14 +33,14 @@ describes all the details of the format.
|
||||||
For the most part, you can pick out any field from the JSON in a fairly
|
For the most part, you can pick out any field from the JSON in a fairly
|
||||||
straightforward manner.
|
straightforward manner.
|
||||||
|
|
||||||
$ docker inspect --format='{{.NetworkSettings.IPAddress}}' $INSTANCE_ID
|
$ docker inspect --format='{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' $INSTANCE_ID
|
||||||
|
|
||||||
**Get an instance's MAC Address:**
|
**Get an instance's MAC Address:**
|
||||||
|
|
||||||
For the most part, you can pick out any field from the JSON in a fairly
|
For the most part, you can pick out any field from the JSON in a fairly
|
||||||
straightforward manner.
|
straightforward manner.
|
||||||
|
|
||||||
$ docker inspect --format='{{.NetworkSettings.MacAddress}}' $INSTANCE_ID
|
$ docker inspect '{{range .NetworkSettings.Networks}}{{.MacAddress}}{{end}}' $INSTANCE_ID
|
||||||
|
|
||||||
**Get an instance's log path:**
|
**Get an instance's log path:**
|
||||||
|
|
||||||
|
@ -58,7 +58,7 @@ output:
|
||||||
The `.Field` syntax doesn't work when the field name begins with a
|
The `.Field` syntax doesn't work when the field name begins with a
|
||||||
number, but the template language's `index` function does. The
|
number, but the template language's `index` function does. The
|
||||||
`.NetworkSettings.Ports` section contains a map of the internal port
|
`.NetworkSettings.Ports` section contains a map of the internal port
|
||||||
mappings to a list of external address/port objects, so to grab just the
|
mappings to a list of external address/port objects. To grab just the
|
||||||
numeric public port, you use `index` to find the specific port map, and
|
numeric public port, you use `index` to find the specific port map, and
|
||||||
then `index` 0 contains the first object inside of that. Then we ask for
|
then `index` 0 contains the first object inside of that. Then we ask for
|
||||||
the `HostPort` field to get the public address.
|
the `HostPort` field to get the public address.
|
||||||
|
|
|
@ -2,7 +2,7 @@
|
||||||
+++
|
+++
|
||||||
title = "network connect"
|
title = "network connect"
|
||||||
description = "The network connect command description and usage"
|
description = "The network connect command description and usage"
|
||||||
keywords = ["network, connect"]
|
keywords = ["network, connect, user-defined"]
|
||||||
[menu.main]
|
[menu.main]
|
||||||
parent = "smn_cli"
|
parent = "smn_cli"
|
||||||
+++
|
+++
|
||||||
|
|
|
@ -2,7 +2,7 @@
|
||||||
+++
|
+++
|
||||||
title = "network create"
|
title = "network create"
|
||||||
description = "The network create command description and usage"
|
description = "The network create command description and usage"
|
||||||
keywords = ["network create"]
|
keywords = ["network, create"]
|
||||||
[menu.main]
|
[menu.main]
|
||||||
parent = "smn_cli"
|
parent = "smn_cli"
|
||||||
+++
|
+++
|
||||||
|
@ -55,7 +55,7 @@ The `docker daemon` options that support the `overlay` network are:
|
||||||
|
|
||||||
To read more about these options and how to configure them, see ["*Get started
|
To read more about these options and how to configure them, see ["*Get started
|
||||||
with multi-host network*"](../../userguide/networking/get-started-overlay.md).
|
with multi-host network*"](../../userguide/networking/get-started-overlay.md).
|
||||||
|
|
||||||
It is also a good idea, though not required, that you install Docker Swarm on to
|
It is also a good idea, though not required, that you install Docker Swarm on to
|
||||||
manage the cluster that makes up your network. Swarm provides sophisticated
|
manage the cluster that makes up your network. Swarm provides sophisticated
|
||||||
discovery and server management that can assist your implementation.
|
discovery and server management that can assist your implementation.
|
||||||
|
|
|
@ -2,7 +2,7 @@
|
||||||
+++
|
+++
|
||||||
title = "network disconnect"
|
title = "network disconnect"
|
||||||
description = "The network disconnect command description and usage"
|
description = "The network disconnect command description and usage"
|
||||||
keywords = ["network, disconnect"]
|
keywords = ["network, disconnect, user-defined"]
|
||||||
[menu.main]
|
[menu.main]
|
||||||
parent = "smn_cli"
|
parent = "smn_cli"
|
||||||
+++
|
+++
|
||||||
|
|
|
@ -2,7 +2,7 @@
|
||||||
+++
|
+++
|
||||||
title = "network inspect"
|
title = "network inspect"
|
||||||
description = "The network inspect command description and usage"
|
description = "The network inspect command description and usage"
|
||||||
keywords = ["network, inspect"]
|
keywords = ["network, inspect, user-defined"]
|
||||||
[menu.main]
|
[menu.main]
|
||||||
parent = "smn_cli"
|
parent = "smn_cli"
|
||||||
+++
|
+++
|
||||||
|
|
|
@ -2,7 +2,7 @@
|
||||||
+++
|
+++
|
||||||
title = "network ls"
|
title = "network ls"
|
||||||
description = "The network ls command description and usage"
|
description = "The network ls command description and usage"
|
||||||
keywords = ["network, list"]
|
keywords = ["network, list, user-defined"]
|
||||||
[menu.main]
|
[menu.main]
|
||||||
parent = "smn_cli"
|
parent = "smn_cli"
|
||||||
+++
|
+++
|
||||||
|
|
|
@ -2,7 +2,7 @@
|
||||||
+++
|
+++
|
||||||
title = "network rm"
|
title = "network rm"
|
||||||
description = "the network rm command description and usage"
|
description = "the network rm command description and usage"
|
||||||
keywords = ["network, rm"]
|
keywords = ["network, rm, user-defined"]
|
||||||
[menu.main]
|
[menu.main]
|
||||||
parent = "smn_cli"
|
parent = "smn_cli"
|
||||||
+++
|
+++
|
||||||
|
|
|
@ -86,14 +86,10 @@ specified image, and then `starts` it using the specified command. That is,
|
||||||
previous changes intact using `docker start`. See `docker ps -a` to view a list
|
previous changes intact using `docker start`. See `docker ps -a` to view a list
|
||||||
of all containers.
|
of all containers.
|
||||||
|
|
||||||
There is detailed information about `docker run` in the [Docker run reference](run.md).
|
|
||||||
|
|
||||||
The `docker run` command can be used in combination with `docker commit` to
|
The `docker run` command can be used in combination with `docker commit` to
|
||||||
[*change the command that a container runs*](commit.md).
|
[*change the command that a container runs*](commit.md). There is additional detailed information about `docker run` in the [Docker run reference](../run.md).
|
||||||
|
|
||||||
See the [Docker User Guide](../../userguide/dockerlinks.md) for more detailed
|
For information on connecting a container to a network, see the ["*Docker network overview*"](../../userguide/networking/index.md).
|
||||||
information about the `--expose`, `-p`, `-P` and `--link` parameters,
|
|
||||||
and linking containers.
|
|
||||||
|
|
||||||
## Examples
|
## Examples
|
||||||
|
|
||||||
|
@ -185,16 +181,15 @@ manipulate the host's Docker daemon.
|
||||||
|
|
||||||
$ docker run -p 127.0.0.1:80:8080 ubuntu bash
|
$ docker run -p 127.0.0.1:80:8080 ubuntu bash
|
||||||
|
|
||||||
This binds port `8080` of the container to port `80` on `127.0.0.1` of
|
This binds port `8080` of the container to port `80` on `127.0.0.1` of the host
|
||||||
the host machine. The [Docker User Guide](../../userguide/dockerlinks.md)
|
machine. The [Docker User
|
||||||
|
Guide](../../userguide/networking/default_network/dockerlinks.md)
|
||||||
explains in detail how to manipulate ports in Docker.
|
explains in detail how to manipulate ports in Docker.
|
||||||
|
|
||||||
$ docker run --expose 80 ubuntu bash
|
$ docker run --expose 80 ubuntu bash
|
||||||
|
|
||||||
This exposes port `80` of the container for use within a link without
|
This exposes port `80` of the container without publishing the port to the host
|
||||||
publishing the port to the host system's interfaces. The [Docker User
|
system's interfaces.
|
||||||
Guide](../../userguide/dockerlinks.md) explains in detail how to manipulate
|
|
||||||
ports in Docker.
|
|
||||||
|
|
||||||
### Set environment variables (-e, --env, --env-file)
|
### Set environment variables (-e, --env, --env-file)
|
||||||
|
|
||||||
|
@ -302,21 +297,29 @@ For additional information on working with labels, see [*Labels - custom
|
||||||
metadata in Docker*](../../userguide/labels-custom-metadata.md) in the Docker User
|
metadata in Docker*](../../userguide/labels-custom-metadata.md) in the Docker User
|
||||||
Guide.
|
Guide.
|
||||||
|
|
||||||
### Add link to another container (--link)
|
### Connect a container to a network (--net)
|
||||||
|
|
||||||
$ docker run --link /redis:redis --name console ubuntu bash
|
When you start a container use the `--net` flag to connect it to a network.
|
||||||
|
This adds the `busybox` container to the `mynet` network.
|
||||||
|
|
||||||
The `--link` flag will link the container named `/redis` into the newly
|
```bash
|
||||||
created container with the alias `redis`. The new container can access the
|
$ docker run -itd --net=my-multihost-network busybox
|
||||||
network and environment of the `redis` container via environment variables.
|
```
|
||||||
The `--link` flag will also just accept the form `<name or id>` in which case
|
|
||||||
the alias will match the name. For instance, you could have written the previous
|
|
||||||
example as:
|
|
||||||
|
|
||||||
$ docker run --link redis --name console ubuntu bash
|
If you want to add a running container to a network use the `docker network connect` subcommand.
|
||||||
|
|
||||||
The `--name` flag will assign the name `console` to the newly created
|
You can connect multiple containers to the same network. Once connected, the
|
||||||
container.
|
containers can communicate easily need 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**: Service discovery is unavailable on the default bridge network.
|
||||||
|
Containers can communicate via their IP addresses by default. To communicate
|
||||||
|
by name, they must be linked.
|
||||||
|
|
||||||
|
You can disconnect a container from a network using the `docker network
|
||||||
|
disconnect` command.
|
||||||
|
|
||||||
### Mount volumes from container (--volumes-from)
|
### Mount volumes from container (--volumes-from)
|
||||||
|
|
||||||
|
@ -537,34 +540,3 @@ the three processes quota set for the `daemon` user.
|
||||||
The `--stop-signal` flag sets the system call signal that will be sent to the container to exit.
|
The `--stop-signal` flag sets the system call signal that will be sent to the container to exit.
|
||||||
This signal can be a valid unsigned number that matches a position in the kernel's syscall table, for instance 9,
|
This signal can be a valid unsigned number that matches a position in the kernel's syscall table, for instance 9,
|
||||||
or a signal name in the format SIGNAME, for instance SIGKILL.
|
or a signal name in the format SIGNAME, for instance SIGKILL.
|
||||||
|
|
||||||
### A complete example
|
|
||||||
|
|
||||||
$ docker run -d --name static static-web-files sh
|
|
||||||
$ docker run -d --expose=8098 --name riak riakserver
|
|
||||||
$ docker run -d -m 100m -e DEVELOPMENT=1 -e BRANCH=example-code -v $(pwd):/app/bin:ro --name app appserver
|
|
||||||
$ docker run -d -p 1443:443 --dns=10.0.0.1 --dns-search=dev.org -v /var/log/httpd --volumes-from static --link riak --link app -h www.sven.dev.org --name web webserver
|
|
||||||
$ docker run -t -i --rm --volumes-from web -w /var/log/httpd busybox tail -f access.log
|
|
||||||
|
|
||||||
This example shows five containers that might be set up to test a web
|
|
||||||
application change:
|
|
||||||
|
|
||||||
1. Start a pre-prepared volume image `static-web-files` (in the background)
|
|
||||||
that has CSS, image and static HTML in it, (with a `VOLUME` instruction in
|
|
||||||
the Dockerfile to allow the web server to use those files);
|
|
||||||
2. Start a pre-prepared `riakserver` image, give the container name `riak` and
|
|
||||||
expose port `8098` to any containers that link to it;
|
|
||||||
3. Start the `appserver` image, restricting its memory usage to 100MB, setting
|
|
||||||
two environment variables `DEVELOPMENT` and `BRANCH` and bind-mounting the
|
|
||||||
current directory (`$(pwd)`) in the container in read-only mode as `/app/bin`;
|
|
||||||
4. Start the `webserver`, mapping port `443` in the container to port `1443` on
|
|
||||||
the Docker server, setting the DNS server to `10.0.0.1` and DNS search
|
|
||||||
domain to `dev.org`, creating a volume to put the log files into (so we can
|
|
||||||
access it from another container), then importing the files from the volume
|
|
||||||
exposed by the `static` container, and linking to all exposed ports from
|
|
||||||
`riak` and `app`. Lastly, we set the hostname to `web.sven.dev.org` so its
|
|
||||||
consistent with the pre-generated SSL certificate;
|
|
||||||
5. Finally, we create a container that runs `tail -f access.log` using the logs
|
|
||||||
volume from the `web` container, setting the workdir to `/var/log/httpd`. The
|
|
||||||
`--rm` option means that when the container exits, the container's layer is
|
|
||||||
removed.
|
|
||||||
|
|
|
@ -135,16 +135,14 @@ after the container is created.
|
||||||
## libnetwork
|
## libnetwork
|
||||||
|
|
||||||
libnetwork provides a native Go implementation for creating and managing container
|
libnetwork provides a native Go implementation for creating and managing container
|
||||||
network namespaces and other network resources. It manage the networking lifecycle
|
network namespaces and other network resources. It manage the networking lifecycle
|
||||||
of the container performing additional operations after the container is created.
|
of the container performing additional operations after the container is created.
|
||||||
|
|
||||||
## link
|
## link
|
||||||
|
|
||||||
links provide an interface to connect Docker containers running on the same host
|
links provide a legacy interface to connect Docker containers running on the
|
||||||
to each other without exposing the hosts' network ports. When you set up a link,
|
same host to each other without exposing the hosts' network ports. Use the
|
||||||
you create a conduit between a source container and a recipient container.
|
Docker networks feature instead.
|
||||||
The recipient can then access select data about the source. To create a link,
|
|
||||||
you can use the `--link` flag.
|
|
||||||
|
|
||||||
## Machine
|
## Machine
|
||||||
|
|
||||||
|
@ -221,4 +219,3 @@ Compared to to containers, a Virtual Machine is heavier to run, provides more is
|
||||||
gets its own set of resources and does minimal sharing.
|
gets its own set of resources and does minimal sharing.
|
||||||
|
|
||||||
*Also known as : VM*
|
*Also known as : VM*
|
||||||
|
|
||||||
|
|
|
@ -154,13 +154,14 @@ The operator can identify a container in three ways:
|
||||||
- UUID short identifier ("f78375b1c487")
|
- UUID short identifier ("f78375b1c487")
|
||||||
- Name ("evil_ptolemy")
|
- Name ("evil_ptolemy")
|
||||||
|
|
||||||
The UUID identifiers come from the Docker daemon, and if you do not
|
The UUID identifiers come from the Docker daemon. If you do not assign a
|
||||||
assign a name to the container with `--name` then the daemon will also
|
container name with the `--name` option, then the daemon generates a random
|
||||||
generate a random string name too. The name can become a handy way to
|
string name for you. Defining a `name` can be a handy way to add meaning to a
|
||||||
add meaning to a container since you can use this name when defining
|
container. If you specify a `name`, you can use it when referencing the
|
||||||
[*links*](../userguide/dockerlinks.md) (or any
|
container within a Docker network. This works for both background and foreground
|
||||||
other place you need to identify a container). This works for both
|
Docker containers.
|
||||||
background and foreground Docker containers.
|
|
||||||
|
**Note**: Containers on the default bridge network must be linked to communicate by name.
|
||||||
|
|
||||||
### PID equivalent
|
### PID equivalent
|
||||||
|
|
||||||
|
@ -259,8 +260,7 @@ with `docker run --net none` which disables all incoming and outgoing
|
||||||
networking. In cases like this, you would perform I/O through files or
|
networking. In cases like this, you would perform I/O through files or
|
||||||
`STDIN` and `STDOUT` only.
|
`STDIN` and `STDOUT` only.
|
||||||
|
|
||||||
Publishing ports and linking to other containers will not work
|
Publishing ports and linking to other containers only works with the the default (bridge). The linking feature is a legacy feature. You should always prefer using Docker network drivers over linking.
|
||||||
when `--net` is anything other than the default (bridge).
|
|
||||||
|
|
||||||
Your container will use the same DNS servers as the host by default, but
|
Your container will use the same DNS servers as the host by default, but
|
||||||
you can override this with `--dns`.
|
you can override this with `--dns`.
|
||||||
|
@ -331,6 +331,9 @@ container's namespaces in addition to the `loopback` interface. An IP
|
||||||
address will be allocated for containers on the bridge's network and
|
address will be allocated for containers on the bridge's network and
|
||||||
traffic will be routed though this bridge to the container.
|
traffic will be routed though this bridge to the container.
|
||||||
|
|
||||||
|
Containers can communicate via their IP addresses by default. To communicate by
|
||||||
|
name, they must be linked.
|
||||||
|
|
||||||
#### Network: host
|
#### Network: host
|
||||||
|
|
||||||
With the network set to `host` a container will share the host's
|
With the network set to `host` a container will share the host's
|
||||||
|
@ -366,19 +369,23 @@ running the `redis-cli` command and connecting to the Redis server over the
|
||||||
$ # use the redis container's network stack to access localhost
|
$ # use the redis container's network stack to access localhost
|
||||||
$ docker run --rm -it --net container:redis example/redis-cli -h 127.0.0.1
|
$ docker run --rm -it --net container:redis example/redis-cli -h 127.0.0.1
|
||||||
|
|
||||||
#### Network: User-Created NETWORK
|
#### User-defined network
|
||||||
|
|
||||||
In addition to all the above special networks, user can create a network using
|
You can create a network using a Docker network driver or an external network
|
||||||
their favorite network driver or external plugin. The driver used to create the
|
driver plugin. You can connect multiple containers to the same network. Once
|
||||||
network takes care of all the network plumbing requirements for the container
|
connected to a user-defined network, the containers can communicate easily using
|
||||||
connected to that network.
|
only another container's IP address or name.
|
||||||
|
|
||||||
Example creating a network using the inbuilt overlay network driver and running
|
For `overlay` networks or custom plugins that support multi-host connectivity,
|
||||||
a container in the created network
|
containers connected to the same multi-host network but launched from different
|
||||||
|
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
|
||||||
|
|
||||||
```
|
```
|
||||||
$ docker network create -d overlay multi-host-network
|
$ docker network create -d overlay my-net
|
||||||
$ docker run --net=multi-host-network -itd --name=container3 busybox
|
$ docker run --net=my-net -itd --name=container3 busybox
|
||||||
```
|
```
|
||||||
|
|
||||||
### Managing /etc/hosts
|
### Managing /etc/hosts
|
||||||
|
@ -510,8 +517,8 @@ the container exits**, you can add the `--rm` flag:
|
||||||
|
|
||||||
--rm=false: Automatically remove the container when it exits (incompatible with -d)
|
--rm=false: Automatically remove the container when it exits (incompatible with -d)
|
||||||
|
|
||||||
> **Note**: When you set the `--rm` flag, Docker also removes the volumes
|
> **Note**: When you set the `--rm` flag, Docker also removes the volumes
|
||||||
associated with the container when the container is removed. This is similar
|
associated with the container when the container is removed. This is similar
|
||||||
to running `docker rm -v my-container`.
|
to running `docker rm -v my-container`.
|
||||||
|
|
||||||
## Security configuration
|
## Security configuration
|
||||||
|
@ -664,7 +671,7 @@ same as the hard memory limit.
|
||||||
|
|
||||||
Memory reservation is a soft-limit feature and does not guarantee the limit
|
Memory reservation is a soft-limit feature and does not guarantee the limit
|
||||||
won't be exceeded. Instead, the feature attempts to ensure that, when memory is
|
won't be exceeded. Instead, the feature attempts to ensure that, when memory is
|
||||||
heavily contended for, memory is allocated based on the reservation hints/setup.
|
heavily contended for, memory is allocated based on the reservation hints/setup.
|
||||||
|
|
||||||
The following example limits the memory (`-m`) to 500M and sets the memory
|
The following example limits the memory (`-m`) to 500M and sets the memory
|
||||||
reservation to 200M.
|
reservation to 200M.
|
||||||
|
@ -1186,12 +1193,12 @@ specifies `EXPOSE 80` in the Dockerfile). At runtime, the port might be
|
||||||
bound to 42800 on the host. To find the mapping between the host ports
|
bound to 42800 on the host. To find the mapping between the host ports
|
||||||
and the exposed ports, use `docker port`.
|
and the exposed ports, use `docker port`.
|
||||||
|
|
||||||
If the operator uses `--link` when starting a new client container,
|
If the operator uses `--link` when starting a new client container, then the
|
||||||
then the client container can access the exposed port via a private
|
client container can access the exposed port via a private networking interface.
|
||||||
networking interface. Docker will set some environment variables in the
|
Linking is a legacy feature that is only supported on the default bridge
|
||||||
client container to help indicate which interface and port to use. For
|
network. You should prefer the Docker networks feature instead. For more
|
||||||
more information on linking, see [the guide on linking container
|
information on this feature, see the [*Docker network
|
||||||
together](../userguide/dockerlinks.md)
|
overview*""](../userguide/networking/index.md)).
|
||||||
|
|
||||||
### ENV (environment variables)
|
### ENV (environment variables)
|
||||||
|
|
||||||
|
@ -1227,11 +1234,6 @@ variables automatically:
|
||||||
</tr>
|
</tr>
|
||||||
</table>
|
</table>
|
||||||
|
|
||||||
The container may also include environment variables defined
|
|
||||||
as a result of the container being linked with another container. See
|
|
||||||
the [*Container Links*](../userguide/dockerlinks.md#connect-with-the-linking-system)
|
|
||||||
section for more details.
|
|
||||||
|
|
||||||
Additionally, the operator can **set any environment variable** in the
|
Additionally, the operator can **set any environment variable** in the
|
||||||
container by using one or more `-e` flags, even overriding those mentioned
|
container by using one or more `-e` flags, even overriding those mentioned
|
||||||
above, or already defined by the developer with a Dockerfile `ENV`:
|
above, or already defined by the developer with a Dockerfile `ENV`:
|
||||||
|
@ -1248,69 +1250,11 @@ above, or already defined by the developer with a Dockerfile `ENV`:
|
||||||
|
|
||||||
Similarly the operator can set the **hostname** with `-h`.
|
Similarly the operator can set the **hostname** with `-h`.
|
||||||
|
|
||||||
`--link <name or id>:alias` also sets environment variables, using the *alias* string to
|
|
||||||
define environment variables within the container that give the IP and PORT
|
|
||||||
information for connecting to the service container. Let's imagine we have a
|
|
||||||
container running Redis:
|
|
||||||
|
|
||||||
# Start the service container, named redis-name
|
|
||||||
$ docker run -d --name redis-name dockerfiles/redis
|
|
||||||
4241164edf6f5aca5b0e9e4c9eccd899b0b8080c64c0cd26efe02166c73208f3
|
|
||||||
|
|
||||||
# The redis-name container exposed port 6379
|
|
||||||
$ docker ps
|
|
||||||
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
|
|
||||||
4241164edf6f $ dockerfiles/redis:latest /redis-stable/src/re 5 seconds ago Up 4 seconds 6379/tcp redis-name
|
|
||||||
|
|
||||||
# Note that there are no public ports exposed since we didn᾿t use -p or -P
|
|
||||||
$ docker port 4241164edf6f 6379
|
|
||||||
2014/01/25 00:55:38 Error: No public port '6379' published for 4241164edf6f
|
|
||||||
|
|
||||||
Yet we can get information about the Redis container's exposed ports
|
|
||||||
with `--link`. Choose an alias that will form a
|
|
||||||
valid environment variable!
|
|
||||||
|
|
||||||
$ docker run --rm --link redis-name:redis_alias --entrypoint /bin/bash dockerfiles/redis -c export
|
|
||||||
declare -x HOME="/"
|
|
||||||
declare -x HOSTNAME="acda7f7b1cdc"
|
|
||||||
declare -x OLDPWD
|
|
||||||
declare -x PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
|
|
||||||
declare -x PWD="/"
|
|
||||||
declare -x REDIS_ALIAS_NAME="/distracted_wright/redis"
|
|
||||||
declare -x REDIS_ALIAS_PORT="tcp://172.17.0.32:6379"
|
|
||||||
declare -x REDIS_ALIAS_PORT_6379_TCP="tcp://172.17.0.32:6379"
|
|
||||||
declare -x REDIS_ALIAS_PORT_6379_TCP_ADDR="172.17.0.32"
|
|
||||||
declare -x REDIS_ALIAS_PORT_6379_TCP_PORT="6379"
|
|
||||||
declare -x REDIS_ALIAS_PORT_6379_TCP_PROTO="tcp"
|
|
||||||
declare -x SHLVL="1"
|
|
||||||
declare -x container="lxc"
|
|
||||||
|
|
||||||
And we can use that information to connect from another container as a client:
|
|
||||||
|
|
||||||
$ docker run -i -t --rm --link redis-name:redis_alias --entrypoint /bin/bash dockerfiles/redis -c '/redis-stable/src/redis-cli -h $REDIS_ALIAS_PORT_6379_TCP_ADDR -p $REDIS_ALIAS_PORT_6379_TCP_PORT'
|
|
||||||
172.17.0.32:6379>
|
|
||||||
|
|
||||||
Docker will also map the private IP address to the alias of a linked
|
|
||||||
container by inserting an entry into `/etc/hosts`. You can use this
|
|
||||||
mechanism to communicate with a linked container by its alias:
|
|
||||||
|
|
||||||
$ docker run -d --name servicename busybox sleep 30
|
|
||||||
$ docker run -i -t --link servicename:servicealias busybox ping -c 1 servicealias
|
|
||||||
|
|
||||||
If you restart the source container (`servicename` in this case), the recipient
|
|
||||||
container's `/etc/hosts` entry will be automatically updated.
|
|
||||||
|
|
||||||
> **Note**:
|
|
||||||
> Unlike host entries in the `/etc/hosts` file, IP addresses stored in the
|
|
||||||
> environment variables are not automatically updated if the source container is
|
|
||||||
> restarted. We recommend using the host entries in `/etc/hosts` to resolve the
|
|
||||||
> IP address of linked containers.
|
|
||||||
|
|
||||||
### VOLUME (shared filesystems)
|
### VOLUME (shared filesystems)
|
||||||
|
|
||||||
-v=[]: Create a bind mount with: [host-dir:]container-dir[:<options>], where
|
-v=[]: Create a bind mount with: [host-dir:]container-dir[:<options>], where
|
||||||
options are comma delimited and selected from [rw|ro] and [z|Z].
|
options are comma delimited and selected from [rw|ro] and [z|Z].
|
||||||
If 'host-dir' is missing, then docker creates a new volume.
|
If 'host-dir' is missing, then docker creates a new volume.
|
||||||
If neither 'rw' or 'ro' is specified then the volume is mounted
|
If neither 'rw' or 'ro' is specified then the volume is mounted
|
||||||
in read-write mode.
|
in read-write mode.
|
||||||
--volumes-from="": Mount all volumes from the given container(s)
|
--volumes-from="": Mount all volumes from the given container(s)
|
||||||
|
@ -1325,17 +1269,17 @@ one or more `VOLUME`'s associated with an image, but only the operator
|
||||||
can give access from one container to another (or from a container to a
|
can give access from one container to another (or from a container to a
|
||||||
volume mounted on the host).
|
volume mounted on the host).
|
||||||
|
|
||||||
The `container-dir` must always be an absolute path such as `/src/docs`.
|
The `container-dir` must always be an absolute path such as `/src/docs`.
|
||||||
The `host-dir` can either be an absolute path or a `name` value. If you
|
The `host-dir` can either be an absolute path or a `name` value. If you
|
||||||
supply an absolute path for the `host-dir`, Docker bind-mounts to the path
|
supply an absolute path for the `host-dir`, Docker bind-mounts to the path
|
||||||
you specify. If you supply a `name`, Docker creates a named volume by that `name`.
|
you specify. If you supply a `name`, Docker creates a named volume by that `name`.
|
||||||
|
|
||||||
A `name` value must start with start with an alphanumeric character,
|
A `name` value must start with start with an alphanumeric character,
|
||||||
followed by `a-z0-9`, `_` (underscore), `.` (period) or `-` (hyphen).
|
followed by `a-z0-9`, `_` (underscore), `.` (period) or `-` (hyphen).
|
||||||
An absolute path starts with a `/` (forward slash).
|
An absolute path starts with a `/` (forward slash).
|
||||||
|
|
||||||
For example, you can specify either `/foo` or `foo` for a `host-dir` value.
|
For example, you can specify either `/foo` or `foo` for a `host-dir` value.
|
||||||
If you supply the `/foo` value, Docker creates a bind-mount. If you supply
|
If you supply the `/foo` value, Docker creates a bind-mount. If you supply
|
||||||
the `foo` specification, Docker creates a named volume.
|
the `foo` specification, Docker creates a named volume.
|
||||||
|
|
||||||
### USER
|
### USER
|
||||||
|
|
|
@ -1,4 +1,4 @@
|
||||||
# Docker Experimental Features
|
# Docker Experimental Features
|
||||||
|
|
||||||
This page contains a list of features in the Docker engine which are
|
This page contains a list of features in the Docker engine which are
|
||||||
experimental. Experimental features are **not** ready for production. They are
|
experimental. Experimental features are **not** ready for production. They are
|
||||||
|
|
|
@ -16,7 +16,7 @@ The **docker attach** command allows you to attach to a running container using
|
||||||
the container's ID or name, either to view its ongoing output or to control it
|
the container's ID or name, either to view its ongoing output or to control it
|
||||||
interactively. You can attach to the same contained process multiple times
|
interactively. You can attach to the same contained process multiple times
|
||||||
simultaneously, screen sharing style, or quickly view the progress of your
|
simultaneously, screen sharing style, or quickly view the progress of your
|
||||||
daemonized process.
|
detached process.
|
||||||
|
|
||||||
You can detach from the container (and leave it running) with `CTRL-p CTRL-q`
|
You can detach from the container (and leave it running) with `CTRL-p CTRL-q`
|
||||||
(for a quiet exit) or `CTRL-c` which will send a `SIGKILL` to the container.
|
(for a quiet exit) or `CTRL-c` which will send a `SIGKILL` to the container.
|
||||||
|
|
|
@ -81,8 +81,9 @@ format.
|
||||||
URL of the distributed storage backend
|
URL of the distributed storage backend
|
||||||
|
|
||||||
**--cluster-advertise**=""
|
**--cluster-advertise**=""
|
||||||
Specifies the 'host:port' combination that this particular daemon instance should use when advertising
|
Specifies the 'host:port' or `interface:port` combination that this particular
|
||||||
itself to the cluster. The daemon is reached by remote hosts on this 'host:port' combination.
|
daemon instance should use when advertising itself to the cluster. The daemon
|
||||||
|
is reached through this value.
|
||||||
|
|
||||||
**--cluster-store-opt**=""
|
**--cluster-store-opt**=""
|
||||||
Specifies options for the Key/Value store.
|
Specifies options for the Key/Value store.
|
||||||
|
|
|
@ -194,7 +194,7 @@ To get information on a container use its ID or instance name:
|
||||||
|
|
||||||
To get the IP address of a container use:
|
To get the IP address of a container use:
|
||||||
|
|
||||||
$ docker inspect --format='{{.NetworkSettings.IPAddress}}' d2cc496561d6
|
$ docker inspect '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' d2cc496561d6
|
||||||
172.17.0.2
|
172.17.0.2
|
||||||
|
|
||||||
## Listing all port bindings
|
## Listing all port bindings
|
||||||
|
|
Loading…
Reference in New Issue