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
|
@ -19,8 +19,7 @@ plugins.
|
|||
Plugins extend Docker's functionality. They come in specific types. For
|
||||
example, a [volume plugin](plugins_volume.md) might enable Docker
|
||||
volumes to persist across multiple Docker hosts and a
|
||||
[network plugin](plugins_network.md) might provide network plumbing
|
||||
using a favorite networking technology, such as vxlan overlay, ipvlan, EVPN, etc.
|
||||
[network plugin](plugins_network.md) might provide network plumbing.
|
||||
|
||||
Currently Docker supports volume and network driver plugins. In the future it
|
||||
will support additional plugin types.
|
||||
|
|
|
@ -1,7 +1,7 @@
|
|||
<!--[metadata]>
|
||||
+++
|
||||
title = "Docker network driver plugins"
|
||||
description = "Network drive plugins."
|
||||
description = "Network driver plugins."
|
||||
keywords = ["Examples, Usage, plugins, docker, documentation, user guide"]
|
||||
[menu.main]
|
||||
parent = "mn_extend"
|
||||
|
@ -11,41 +11,48 @@ weight=-1
|
|||
|
||||
# Docker network driver plugins
|
||||
|
||||
Docker supports network driver plugins via
|
||||
[LibNetwork](https://github.com/docker/libnetwork). Network driver plugins are
|
||||
implemented as "remote drivers" for LibNetwork, which shares plugin
|
||||
infrastructure with Docker. In effect this means that network driver plugins
|
||||
are activated in the same way as other plugins, and use the same kind of
|
||||
protocol.
|
||||
Docker network plugins enable Docker deployments to be extended to support a
|
||||
wide range of networking technologies, such as VXLAN, IPVLAN, MACVLAN or
|
||||
something completely different. Network driver plugins are supported via the
|
||||
LibNetwork project. Each plugin is implemented asa "remote driver" for
|
||||
LibNetwork, which shares plugin infrastructure with Docker. Effectively,
|
||||
network driver plugins are activated in the same way as other plugins, and use
|
||||
the same kind of protocol.
|
||||
|
||||
## Using network driver plugins
|
||||
|
||||
The means of installing and running a network driver plugin will depend on the
|
||||
particular plugin.
|
||||
The means of installing and running a network driver plugin depend on the
|
||||
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
|
||||
network drivers: by being mentioned as a driver in network-oriented Docker
|
||||
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)
|
||||
|
||||
The network thus created is owned by the plugin, so subsequent commands
|
||||
referring to that network will also be run through the plugin such as,
|
||||
The `mynet` network is now owned by `weave`, so subsequent commands
|
||||
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
|
||||
documented as part of LibNetwork:
|
||||
## Write a network plugin
|
||||
|
||||
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).
|
||||
|
||||
# Related GitHub PRs and issues
|
||||
# Related Information
|
||||
|
||||
Please record your feedback in the following issue, on the usual
|
||||
Google Groups, or the IRC channel #docker-network.
|
||||
To interact with the Docker maintainers and other interested users, se the IRC channel `#docker-network`.
|
||||
|
||||
- [#14083](https://github.com/docker/docker/issues/14083) Feedback on
|
||||
experimental networking features
|
||||
- [Docker networks feature overview](../userguide/networking/index.md)
|
||||
- The [LibNetwork](https://github.com/docker/libnetwork) project
|
||||
|
|
|
@ -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
|
||||
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
|
||||
to publish a range of ports or the `-P` flag to publish all of the exposed ports.
|
||||
You can expose one port number and publish it externally under another number.
|
||||
to publish a range of ports or the `-P` flag to publish all of the exposed
|
||||
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))
|
||||
and to set up port redirection on the host system when [using the -P flag](run.md#expose-incoming-ports).
|
||||
To set up port redirection on the host system, see [using the -P
|
||||
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
|
||||
|
||||
|
@ -507,8 +510,9 @@ and to set up port redirection on the host system when [using the -P flag](run.m
|
|||
ENV <key>=<value> ...
|
||||
|
||||
The `ENV` instruction sets the environment variable `<key>` to the value
|
||||
`<value>`. This value will be in the environment of all "descendent" `Dockerfile`
|
||||
commands and can be [replaced inline](#environment-replacement) in many as well.
|
||||
`<value>`. This value will be in the environment of all "descendent"
|
||||
`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>`,
|
||||
will set a single variable to a value. The entire string after the first
|
||||
|
|
|
@ -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
|
||||
interactively. You can attach to the same contained process multiple times
|
||||
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`
|
||||
(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-v6="" Container default gateway IPv6 address
|
||||
--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
|
||||
--dns=[] DNS server to use
|
||||
--dns-opt=[] DNS options to use
|
||||
|
@ -547,13 +547,16 @@ please check the [run](run.md) reference.
|
|||
|
||||
## Nodes discovery
|
||||
|
||||
`--cluster-advertise` specifies the 'host:port' combination that this particular
|
||||
daemon instance should use when advertising itself to the cluster. The daemon
|
||||
is reached by remote hosts on this 'host:port' combination.
|
||||
The `--cluster-advertise` option specifies the 'host:port' or `interface:port`
|
||||
combination that this particular daemon instance should use when advertising
|
||||
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 node within the cluster. Some Key/Value backends support mutual
|
||||
TLS, and the client TLS settings used by the daemon can be configured
|
||||
the node within the cluster. Some key-value backends support mutual
|
||||
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
|
||||
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
|
||||
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:**
|
||||
|
||||
For the most part, you can pick out any field from the JSON in a fairly
|
||||
straightforward manner.
|
||||
|
||||
$ docker inspect --format='{{.NetworkSettings.MacAddress}}' $INSTANCE_ID
|
||||
$ docker inspect '{{range .NetworkSettings.Networks}}{{.MacAddress}}{{end}}' $INSTANCE_ID
|
||||
|
||||
**Get an instance's log path:**
|
||||
|
||||
|
@ -58,7 +58,7 @@ output:
|
|||
The `.Field` syntax doesn't work when the field name begins with a
|
||||
number, but the template language's `index` function does. The
|
||||
`.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
|
||||
then `index` 0 contains the first object inside of that. Then we ask for
|
||||
the `HostPort` field to get the public address.
|
||||
|
|
|
@ -2,7 +2,7 @@
|
|||
+++
|
||||
title = "network connect"
|
||||
description = "The network connect command description and usage"
|
||||
keywords = ["network, connect"]
|
||||
keywords = ["network, connect, user-defined"]
|
||||
[menu.main]
|
||||
parent = "smn_cli"
|
||||
+++
|
||||
|
|
|
@ -2,7 +2,7 @@
|
|||
+++
|
||||
title = "network create"
|
||||
description = "The network create command description and usage"
|
||||
keywords = ["network create"]
|
||||
keywords = ["network, create"]
|
||||
[menu.main]
|
||||
parent = "smn_cli"
|
||||
+++
|
||||
|
|
|
@ -2,7 +2,7 @@
|
|||
+++
|
||||
title = "network disconnect"
|
||||
description = "The network disconnect command description and usage"
|
||||
keywords = ["network, disconnect"]
|
||||
keywords = ["network, disconnect, user-defined"]
|
||||
[menu.main]
|
||||
parent = "smn_cli"
|
||||
+++
|
||||
|
|
|
@ -2,7 +2,7 @@
|
|||
+++
|
||||
title = "network inspect"
|
||||
description = "The network inspect command description and usage"
|
||||
keywords = ["network, inspect"]
|
||||
keywords = ["network, inspect, user-defined"]
|
||||
[menu.main]
|
||||
parent = "smn_cli"
|
||||
+++
|
||||
|
|
|
@ -2,7 +2,7 @@
|
|||
+++
|
||||
title = "network ls"
|
||||
description = "The network ls command description and usage"
|
||||
keywords = ["network, list"]
|
||||
keywords = ["network, list, user-defined"]
|
||||
[menu.main]
|
||||
parent = "smn_cli"
|
||||
+++
|
||||
|
|
|
@ -2,7 +2,7 @@
|
|||
+++
|
||||
title = "network rm"
|
||||
description = "the network rm command description and usage"
|
||||
keywords = ["network, rm"]
|
||||
keywords = ["network, rm, user-defined"]
|
||||
[menu.main]
|
||||
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
|
||||
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
|
||||
[*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
|
||||
information about the `--expose`, `-p`, `-P` and `--link` parameters,
|
||||
and linking containers.
|
||||
For information on connecting a container to a network, see the ["*Docker network overview*"](../../userguide/networking/index.md).
|
||||
|
||||
## Examples
|
||||
|
||||
|
@ -185,16 +181,15 @@ manipulate the host's Docker daemon.
|
|||
|
||||
$ 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
|
||||
the host machine. The [Docker User Guide](../../userguide/dockerlinks.md)
|
||||
This binds port `8080` of the container to port `80` on `127.0.0.1` of the host
|
||||
machine. The [Docker User
|
||||
Guide](../../userguide/networking/default_network/dockerlinks.md)
|
||||
explains in detail how to manipulate ports in Docker.
|
||||
|
||||
$ docker run --expose 80 ubuntu bash
|
||||
|
||||
This exposes port `80` of the container for use within a link without
|
||||
publishing the port to the host system's interfaces. The [Docker User
|
||||
Guide](../../userguide/dockerlinks.md) explains in detail how to manipulate
|
||||
ports in Docker.
|
||||
This exposes port `80` of the container without publishing the port to the host
|
||||
system's interfaces.
|
||||
|
||||
### 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
|
||||
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
|
||||
created container with the alias `redis`. The new container can access the
|
||||
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:
|
||||
```bash
|
||||
$ docker run -itd --net=my-multihost-network busybox
|
||||
```
|
||||
|
||||
$ 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
|
||||
container.
|
||||
You can connect multiple containers to the same network. Once connected, the
|
||||
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)
|
||||
|
||||
|
@ -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.
|
||||
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.
|
||||
|
||||
### 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.
|
||||
|
|
|
@ -140,11 +140,9 @@ of the container performing additional operations after the container is created
|
|||
|
||||
## link
|
||||
|
||||
links provide an interface to connect Docker containers running on the same host
|
||||
to each other without exposing the hosts' network ports. When you set up a link,
|
||||
you create a conduit between a source container and a recipient container.
|
||||
The recipient can then access select data about the source. To create a link,
|
||||
you can use the `--link` flag.
|
||||
links provide a legacy interface to connect Docker containers running on the
|
||||
same host to each other without exposing the hosts' network ports. Use the
|
||||
Docker networks feature instead.
|
||||
|
||||
## 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.
|
||||
|
||||
*Also known as : VM*
|
||||
|
||||
|
|
|
@ -154,13 +154,14 @@ The operator can identify a container in three ways:
|
|||
- UUID short identifier ("f78375b1c487")
|
||||
- Name ("evil_ptolemy")
|
||||
|
||||
The UUID identifiers come from the Docker daemon, and if you do not
|
||||
assign a name to the container with `--name` then the daemon will also
|
||||
generate a random string name too. The name can become a handy way to
|
||||
add meaning to a container since you can use this name when defining
|
||||
[*links*](../userguide/dockerlinks.md) (or any
|
||||
other place you need to identify a container). This works for both
|
||||
background and foreground Docker containers.
|
||||
The UUID identifiers come from the Docker daemon. If you do not assign a
|
||||
container name with the `--name` option, then the daemon generates a random
|
||||
string name for you. Defining a `name` can be a handy way to add meaning to a
|
||||
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.
|
||||
|
||||
### 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
|
||||
`STDIN` and `STDOUT` only.
|
||||
|
||||
Publishing ports and linking to other containers will not work
|
||||
when `--net` is anything other than the default (bridge).
|
||||
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.
|
||||
|
||||
Your container will use the same DNS servers as the host by default, but
|
||||
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
|
||||
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
|
||||
|
||||
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
|
||||
$ 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
|
||||
their favorite network driver or external plugin. The driver used to create the
|
||||
network takes care of all the network plumbing requirements for the container
|
||||
connected to that network.
|
||||
You can create a network using a Docker network driver or an external network
|
||||
driver plugin. You can connect multiple containers to the same network. Once
|
||||
connected to a user-defined network, the containers can communicate easily using
|
||||
only another container's IP address or name.
|
||||
|
||||
Example creating a network using the inbuilt overlay network driver and running
|
||||
a container in the created network
|
||||
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.
|
||||
|
||||
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 run --net=multi-host-network -itd --name=container3 busybox
|
||||
$ docker network create -d overlay my-net
|
||||
$ docker run --net=my-net -itd --name=container3 busybox
|
||||
```
|
||||
|
||||
### Managing /etc/hosts
|
||||
|
@ -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
|
||||
and the exposed ports, use `docker port`.
|
||||
|
||||
If the operator uses `--link` when starting a new client container,
|
||||
then the client container can access the exposed port via a private
|
||||
networking interface. Docker will set some environment variables in the
|
||||
client container to help indicate which interface and port to use. For
|
||||
more information on linking, see [the guide on linking container
|
||||
together](../userguide/dockerlinks.md)
|
||||
If the operator uses `--link` when starting a new client container, then the
|
||||
client container can access the exposed port via a private networking interface.
|
||||
Linking is a legacy feature that is only supported on the default bridge
|
||||
network. You should prefer the Docker networks feature instead. For more
|
||||
information on this feature, see the [*Docker network
|
||||
overview*""](../userguide/networking/index.md)).
|
||||
|
||||
### ENV (environment variables)
|
||||
|
||||
|
@ -1227,11 +1234,6 @@ variables automatically:
|
|||
</tr>
|
||||
</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
|
||||
container by using one or more `-e` flags, even overriding those mentioned
|
||||
above, or already defined by the developer with a Dockerfile `ENV`:
|
||||
|
@ -1248,64 +1250,6 @@ above, or already defined by the developer with a Dockerfile `ENV`:
|
|||
|
||||
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)
|
||||
|
||||
-v=[]: Create a bind mount with: [host-dir:]container-dir[:<options>], where
|
||||
|
|
|
@ -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
|
||||
interactively. You can attach to the same contained process multiple times
|
||||
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`
|
||||
(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
|
||||
|
||||
**--cluster-advertise**=""
|
||||
Specifies the 'host:port' combination that this particular daemon instance should use when advertising
|
||||
itself to the cluster. The daemon is reached by remote hosts on this 'host:port' combination.
|
||||
Specifies the 'host:port' or `interface:port` combination that this particular
|
||||
daemon instance should use when advertising itself to the cluster. The daemon
|
||||
is reached through this value.
|
||||
|
||||
**--cluster-store-opt**=""
|
||||
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:
|
||||
|
||||
$ docker inspect --format='{{.NetworkSettings.IPAddress}}' d2cc496561d6
|
||||
$ docker inspect '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' d2cc496561d6
|
||||
172.17.0.2
|
||||
|
||||
## Listing all port bindings
|
||||
|
|
Loading…
Reference in New Issue