kotovalexarian-likes-github/moby--moby
1
0
Fork 0
mirror of https://github.com/moby/moby.git synced 2022-11-09 12:21:53 -05:00
Code Releases Activity

Merge pull request #20265 from rhuss/patch-1

Browse source 
Fix some formatting
This commit is contained in:
Vincent Demeester 2016-02-12 17:23:17 +01:00
commit c312eab74e
1 changed files with 18 additions and 17 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

35
docs/userguide/networking/work-with-networks.md
View file

@ -62,7 +62,7 @@ $ docker network inspect simple-network
Unlike `bridge` networks, `overlay` networks require some pre-existing conditions
before you can create one. These conditions are:
* Access to a key-value store. Engine supports Consul Etcd, and ZooKeeper (Distributed store) key-value stores.
* Access to a key-value store. Engine supports Consul, Etcd, and ZooKeeper (Distributed store) key-value stores.
* A cluster of hosts with connectivity to the key-value store.
* A properly configured Engine `daemon` on each host in the swarm.
@ -312,6 +312,7 @@ lo Link encap:Local Loopback
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
```
On the `isolated_nw` which was user defined, the Docker embedded DNS server enables name resolution for other containers in the network. Inside of `container2` it is possible to ping `container3` by name.
@ -376,7 +377,7 @@ You can connect both running and non-running containers to a network. However,
### Linking containers in user-defined networks
In the above example, container_2 was able to resolve container_3's name automatically
In the above example, `container2` was able to resolve `container3`'s name automatically
in the user defined network `isolated_nw`, but the name resolution did not succeed
automatically in the default `bridge` network. This is expected in order to maintain
backward compatibility with [legacy link](default_network/dockerlinks.md).
@ -396,7 +397,7 @@ Comparing the above 4 functionalities with the non-default user-defined networks
* ability to dynamically attach and detach to multiple networks
* supports the `--link` option to provide name alias for the linked container
Continuing with the above example, create another container `container_4` in `isolated_nw`
Continuing with the above example, create another container `container4` in `isolated_nw`
with `--link` to provide additional name resolution using alias for other containers in
the same network.
@ -405,26 +406,26 @@ $ docker run --net=isolated_nw -itd --name=container4 --link container5:c5 busyb
01b5df970834b77a9eadbaff39051f237957bd35c4c56f11193e0594cfd5117c
```
With the help of `--link` container4 will be able to reach container5 using the
With the help of `--link` `container4` will be able to reach `container5` using the
aliased name `c5` as well.
Please note that while creating container4, we linked to a container named `container5`
Please note that while creating `container4`, we linked to a container named `container5`
which is not created yet. That is one of the differences in behavior between the
`legacy link` in default `bridge` network and the new `link` functionality in user defined
networks. The `legacy link` is static in nature and it hard-binds the container with the
alias and it doesn't tolerate linked container restarts. While the new `link` functionality
*legacy link* in default `bridge` network and the new *link* functionality in user defined
networks. The *legacy link* is static in nature and it hard-binds the container with the
alias and it doesn't tolerate linked container restarts. While the new *link* functionality
in user defined networks are dynamic in nature and supports linked container restarts
including tolerating ip-address changes on the linked container.
Now let us launch another container named `container5` linking container4 to c4.
Now let us launch another container named `container5` linking `container4` to c4.
```bash
$ docker run --net=isolated_nw -itd --name=container5 --link container4:c4 busybox
72eccf2208336f31e9e33ba327734125af00d1e1d2657878e2ee8154fbb23c7a
```
As expected, container4 will be able to reach container5 by both its container name and
its alias c5 and container5 will be able to reach container4 by its container name and
As expected, `container4` will be able to reach `container5` by both its container name and
its alias c5 and `container5` will be able to reach `container4` by its container name and
its alias c4.
```bash
@ -491,7 +492,7 @@ $ docker network create -d bridge --subnet 172.26.0.0/24 local_alias
76b7dc932e037589e6553f59f76008e5b76fa069638cd39776b890607f567aaa
```
let us connect container4 and container5 to the new network `local_alias`
let us connect `container4` and `container5` to the new network `local_alias`
```
$ docker network connect --link container5:foo local_alias container4
@ -525,7 +526,7 @@ round-trip min/avg/max = 0.070/0.081/0.097 ms
```
Note that the ping succeeds for both the aliases but on different networks.
Let us conclude this section by disconnecting container5 from the `isolated_nw`
Let us conclude this section by disconnecting `container5` from the `isolated_nw`
and observe the results
```
@ -550,9 +551,9 @@ round-trip min/avg/max = 0.070/0.081/0.097 ms
```
In conclusion, the new link functionality in user defined networks provides all the
benefits of legacy links while avoiding most of the well-known issues with `legacy links`.
benefits of legacy links while avoiding most of the well-known issues with *legacy links*.
One notable missing functionality compared to `legacy links` is the injection of
One notable missing functionality compared to *legacy links* is the injection of
environment variables. Though very useful, environment variable injection is static
in nature and must be injected when the container is started. One cannot inject
environment variables into a running container without significant effort and hence
@ -561,10 +562,10 @@ disconnect containers to/from a network.
### Network-scoped alias
While `links` provide private name resolution that is localized within a container,
While *link*s provide private name resolution that is localized within a container,
the network-scoped alias provides a way for a container to be discovered by an
alternate name by any other container within the scope of a particular network.
Unlike the `link` alias, which is defined by the consumer of a service, the
Unlike the *link* alias, which is defined by the consumer of a service, the
network-scoped alias is defined by the container that is offering the service
to the network.