- IRC a direct line to our most knowledgeable Docker users; we have
+ IRC is a direct line to our most knowledgeable Docker users; we have
both the #docker and #docker-dev group on
irc.freenode.net.
IRC is a rich chat protocol but it can overwhelm new users. You can search
@@ -234,6 +234,8 @@ We are always open to suggestions on process improvements, and are always lookin
The docker-dev
group is for contributors and other people contributing to the Docker
project.
+ You can join them without an google account by sending an email to e.g. "docker-user+subscribe@googlegroups.com".
+ After receiving the join-request message, you can simply reply to that to confirm the subscribtion.
CONTAINER_NAME. When using --link
the embedded DNS will guarantee that localized lookup result only on that
container where the --link is used. This lets processes inside the new container
- connect to container without without having to know its name or IP.
+ connect to container without having to know its name or IP.
run a container gives the new
container's /etc/hosts an extra entry named
ALIAS that points to the IP address of the container
- identified by CONTAINER_NAME_or_ID. This lets processes
+ identified by CONTAINER_NAME_or_ID. This lets processes
inside the new container connect to the hostname ALIAS
without having to know its IP. The --link= option is
discussed in more detail below. Because Docker may assign a different IP
diff --git a/components/engine/docs/userguide/networking/default_network/options.md b/components/engine/docs/userguide/networking/default_network/options.md
deleted file mode 100644
index 612dffbc51..0000000000
--- a/components/engine/docs/userguide/networking/default_network/options.md
+++ /dev/null
@@ -1,141 +0,0 @@
-
-
-
-
-# Quick guide to the options
-Here is a quick list of the networking-related Docker command-line options, in case it helps you find the section below that you are looking for.
-
-Some networking command-line options can only be supplied to the Docker server when it starts up, and cannot be changed once it is running:
-- `-b BRIDGE` or `--bridge=BRIDGE` -- see
-
- [Building your own bridge](#bridge-building)
-
-- `--bip=CIDR` -- see
-
- [Customizing docker0](#docker0)
-
-- `--default-gateway=IP_ADDRESS` -- see
-
- [How Docker networks a container](#container-networking)
-
-- `--default-gateway-v6=IP_ADDRESS` -- see
-
- [IPv6](#ipv6)
-
-- `--fixed-cidr` -- see
-
- [Customizing docker0](#docker0)
-
-- `--fixed-cidr-v6` -- see
-
- [IPv6](#ipv6)
-
-- `-H SOCKET...` or `--host=SOCKET...` --
-
- This might sound like it would affect container networking,
-
- but it actually faces in the other direction:
-
- it tells the Docker server over what channels
-
- it should be willing to receive commands
-
- like "run container" and "stop container."
-
-- `--icc=true|false` -- see
-
- [Communication between containers](#between-containers)
-
-- `--ip=IP_ADDRESS` -- see
-
- [Binding container ports](#binding-ports)
-
-- `--ipv6=true|false` -- see
-
- [IPv6](#ipv6)
-
-- `--ip-forward=true|false` -- see
-
- [Communication between containers and the wider world](#the-world)
-
-- `--iptables=true|false` -- see
-
- [Communication between containers](#between-containers)
-
-- `--mtu=BYTES` -- see
-
- [Customizing docker0](#docker0)
-
-- `--userland-proxy=true|false` -- see
-
- [Binding container ports](#binding-ports)
-
-There are three networking options that can be supplied either at startup or when `docker run` is invoked. When provided at startup, set the default value that `docker run` will later use if the options are not specified:
-- `--dns=IP_ADDRESS...` -- see
-
- [Configuring DNS](#dns)
-
-- `--dns-search=DOMAIN...` -- see
-
- [Configuring DNS](#dns)
-
-- `--dns-opt=OPTION...` -- see
-
- [Configuring DNS](#dns)
-
-Finally, several networking options can only be provided when calling `docker run` because they specify something specific to one container:
-- `-h HOSTNAME` or `--hostname=HOSTNAME` -- see
-
- [Configuring DNS](#dns) and
-
- [How Docker networks a container](#container-networking)
-
-- `--link=CONTAINER_NAME_or_ID:ALIAS` -- see
-
- [Configuring DNS](#dns) and
-
- [Communication between containers](#between-containers)
-
-- `--net=bridge|none|container:NAME_or_ID|host` -- see
-
- [How Docker networks a container](#container-networking)
-
-- `--mac-address=MACADDRESS...` -- see
-
- [How Docker networks a container](#container-networking)
-
-- `-p SPEC` or `--publish=SPEC` -- see
-
- [Binding container ports](#binding-ports)
-
-- `-P` or `--publish-all=true|false` -- see
-
- [Binding container ports](#binding-ports)
-
-To supply networking options to the Docker server at startup, use the `DOCKER_OPTS` variable in the Docker upstart configuration file. For Ubuntu, edit the variable in `/etc/default/docker` or `/etc/sysconfig/docker` for CentOS.
-
-The following example illustrates how to configure Docker on Ubuntu to recognize a newly built bridge.
-
-Edit the `/etc/default/docker` file:
-
-```
-$ echo 'DOCKER_OPTS="-b=bridge0"' >> /etc/default/docker
-```
-
-Then restart the Docker server.
-
-```
-$ sudo service docker start
-```
-
-For additional information on bridges, see [building your own bridge](#building-your-own-bridge) later on this page.
diff --git a/components/engine/docs/userguide/networking/default_network/saveme.md b/components/engine/docs/userguide/networking/default_network/saveme.md
deleted file mode 100644
index f0ef85e8c0..0000000000
--- a/components/engine/docs/userguide/networking/default_network/saveme.md
+++ /dev/null
@@ -1,28 +0,0 @@
-
-
-
-
-
-## A Brief introduction to networking and docker
-When Docker starts, it creates a virtual interface named `docker0` on the host machine. It randomly chooses an address and subnet from the private range defined by [RFC 1918](http://tools.ietf.org/html/rfc1918) that are not in use on the host machine, and assigns it to `docker0`. Docker made the choice `172.17.42.1/16` when I started it a few minutes ago, for example -- a 16-bit netmask providing 65,534 addresses for the host machine and its containers. The MAC address is generated using the IP address allocated to the container to avoid ARP collisions, using a range from `02:42:ac:11:00:00` to `02:42:ac:11:ff:ff`.
-
-> **Note:** This document discusses advanced networking configuration and options for Docker. In most cases you won't need this information. If you're looking to get started with a simpler explanation of Docker networking and an introduction to the concept of container linking see the [Docker User Guide](dockerlinks.md).
-
-But `docker0` is no ordinary interface. It is a virtual _Ethernet bridge_ that automatically forwards packets between any other network interfaces that are attached to it. This lets containers communicate both with the host machine and with each other. Every time Docker creates a container, it creates a pair of "peer" interfaces that are like opposite ends of a pipe -- a packet sent on one will be received on the other. It gives one of the peers to the container to become its `eth0` interface and keeps the other peer, with a unique name like `vethAQI2QT`, out in the namespace of the host machine. By binding every `veth*` interface to the `docker0` bridge, Docker creates a virtual subnet shared between the host machine and every Docker container.
-
-The remaining sections of this document explain all of the ways that you can use Docker options and -- in advanced cases -- raw Linux networking commands to tweak, supplement, or entirely replace Docker's default networking configuration.
-
-## Editing networking config files
-Starting with Docker v.1.2.0, you can now edit `/etc/hosts`, `/etc/hostname` and `/etc/resolve.conf` in a running container. This is useful if you need to install bind or other services that might override one of those files.
-
-Note, however, that changes to these files will not be saved by `docker commit`, nor will they be saved during `docker run`. That means they won't be saved in the image, nor will they persist when a container is restarted; they will only "stick" in a running container.
diff --git a/components/engine/docs/userguide/networking/default_network/tools.md b/components/engine/docs/userguide/networking/default_network/tools.md
deleted file mode 100644
index 545c1e04c3..0000000000
--- a/components/engine/docs/userguide/networking/default_network/tools.md
+++ /dev/null
@@ -1,83 +0,0 @@
-
-
-
-
-# Tools and examples
-Before diving into the following sections on custom network topologies, you might be interested in glancing at a few external tools or examples of the same kinds of configuration. Here are two:
-- Jérôme Petazzoni has created a `pipework` shell script to help you
-
- connect together containers in arbitrarily complex scenarios:
-
- [https://github.com/jpetazzo/pipework](https://github.com/jpetazzo/pipework)
-
-- Brandon Rhodes has created a whole network topology of Docker
-
- containers for the next edition of Foundations of Python Network
-
- Programming that includes routing, NAT'd firewalls, and servers that
-
- offer HTTP, SMTP, POP, IMAP, Telnet, SSH, and FTP:
-
- [https://github.com/brandon-rhodes/fopnp/tree/m/playground](https://github.com/brandon-rhodes/fopnp/tree/m/playground)
-
-Both tools use networking commands very much like the ones you saw in the previous section, and will see in the following sections.
-
-# Building a point-to-point connection
-
-
-By default, Docker attaches all containers to the virtual subnet implemented by `docker0`. You can create containers that are each connected to some different virtual subnet by creating your own bridge as shown in [Building your own bridge](#bridge-building), starting each container with `docker run --net=none`, and then attaching the containers to your bridge with the shell commands shown in [How Docker networks a container](#container-networking).
-
-But sometimes you want two particular containers to be able to communicate directly without the added complexity of both being bound to a host-wide Ethernet bridge.
-
-The solution is simple: when you create your pair of peer interfaces, simply throw _both_ of them into containers, and configure them as classic point-to-point links. The two containers will then be able to communicate directly (provided you manage to tell each container the other's IP address, of course). You might adjust the instructions of the previous section to go something like this:
-
-```
-# Start up two containers in two terminal windows
-
-$ docker run -i -t --rm --net=none base /bin/bash
-root@1f1f4c1f931a:/#
-
-$ docker run -i -t --rm --net=none base /bin/bash
-root@12e343489d2f:/#
-
-# Learn the container process IDs
-# and create their namespace entries
-
-$ docker inspect -f '{{.State.Pid}}' 1f1f4c1f931a
-2989
-$ docker inspect -f '{{.State.Pid}}' 12e343489d2f
-3004
-$ sudo mkdir -p /var/run/netns
-$ sudo ln -s /proc/2989/ns/net /var/run/netns/2989
-$ sudo ln -s /proc/3004/ns/net /var/run/netns/3004
-
-# Create the "peer" interfaces and hand them out
-
-$ sudo ip link add A type veth peer name B
-
-$ sudo ip link set A netns 2989
-$ sudo ip netns exec 2989 ip addr add 10.1.1.1/32 dev A
-$ sudo ip netns exec 2989 ip link set A up
-$ sudo ip netns exec 2989 ip route add 10.1.1.2/32 dev A
-
-$ sudo ip link set B netns 3004
-$ sudo ip netns exec 3004 ip addr add 10.1.1.2/32 dev B
-$ sudo ip netns exec 3004 ip link set B up
-$ sudo ip netns exec 3004 ip route add 10.1.1.1/32 dev B
-```
-
-The two containers should now be able to ping each other and make connections successfully. Point-to-point links like this do not depend on a subnet nor a netmask, but on the bare assertion made by `ip route` that some other single IP address is connected to a particular network interface.
-
-Note that point-to-point links can be safely combined with other kinds of network connectivity -- there is no need to start the containers with `--net=none` if you want point-to-point links to be an addition to the container's normal networking instead of a replacement.
-
-A final permutation of this pattern is to create the point-to-point link between the Docker host and one container, which would allow the host to communicate with that one container on some single IP address and thus communicate "out-of-band" of the bridge that connects the other, more usual containers. But unless you have very specific networking needs that drive you to such a solution, it is probably far preferable to use `--icc=false` to lock down inter-container communication, as we explored earlier.
diff --git a/components/engine/docs/userguide/networking/dockernetworks.md b/components/engine/docs/userguide/networking/dockernetworks.md
index b9f1a63b44..1848e7a7a9 100644
--- a/components/engine/docs/userguide/networking/dockernetworks.md
+++ b/components/engine/docs/userguide/networking/dockernetworks.md
@@ -46,7 +46,7 @@ by default. You can see this bridge as part of a host's network stack by using
the `ifconfig` command on the host.
```
-ubuntu@ip-172-31-36-118:~$ ifconfig
+$ ifconfig
docker0 Link encap:Ethernet HWaddr 02:42:47:bc:3a:eb
inet addr:172.17.0.1 Bcast:0.0.0.0 Mask:255.255.0.0
inet6 addr: fe80::42:47ff:febc:3aeb/64 Scope:Link
@@ -60,16 +60,16 @@ docker0 Link encap:Ethernet HWaddr 02:42:47:bc:3a:eb
The `none` network adds a container to a container-specific network stack. That container lacks a network interface. Attaching to such a container and looking at it's stack you see this:
```
-ubuntu@ip-172-31-36-118:~$ docker attach nonenetcontainer
+$ docker attach nonenetcontainer
-/ # cat /etc/hosts
+root@0cb243cd1293:/# cat /etc/hosts
127.0.0.1 localhost
::1 localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
-/ # ifconfig
+root@0cb243cd1293:/# ifconfig
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
@@ -79,23 +79,24 @@ lo Link encap:Local Loopback
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
-/ #
+root@0cb243cd1293:/#
```
>**Note**: You can detach from the container and leave it running with `CTRL-p CTRL-q`.
The `host` network adds a container on the hosts network stack. You'll find the
network configuration inside the container is identical to the host.
-With the exception of the the `bridge` network, you really don't need to
+With the exception of the `bridge` network, you really don't need to
interact with these default networks. While you can list and inspect them, you
cannot remove them. They are required by your Docker installation. However, you
can add your own user-defined networks and these you can remove when you no
longer need them. Before you learn more about creating your own networks, it is
-worth looking at the `default` network a bit.
+worth looking at the default `bridge` network a bit.
### The default bridge network in detail
-The default bridge network is present on all Docker hosts. The `docker network inspect`
+The default `bridge` network is present on all Docker hosts. The `docker network inspect`
+command returns information about a network:
```
$ docker network inspect bridge
@@ -189,7 +190,7 @@ You can `attach` to a running `container` and investigate its configuration:
```
$ docker attach container1
-/ # ifconfig
+root@0cb243cd1293:/# ifconfig
ifconfig
eth0 Link encap:Ethernet HWaddr 02:42:AC:11:00:02
inet addr:172.17.0.2 Bcast:0.0.0.0 Mask:255.255.0.0
@@ -213,7 +214,7 @@ lo Link encap:Local Loopback
Then use `ping` for about 3 seconds to test the connectivity of the containers on this `bridge` network.
```
-/ # ping -w3 172.17.0.3
+root@0cb243cd1293:/# ping -w3 172.17.0.3
PING 172.17.0.3 (172.17.0.3): 56 data bytes
64 bytes from 172.17.0.3: seq=0 ttl=64 time=0.096 ms
64 bytes from 172.17.0.3: seq=1 ttl=64 time=0.080 ms
@@ -227,7 +228,7 @@ round-trip min/avg/max = 0.074/0.083/0.096 ms
Finally, use the `cat` command to check the `container1` network configuration:
```
-/ # cat /etc/hosts
+root@0cb243cd1293:/# cat /etc/hosts
172.17.0.2 3386a527aa08
127.0.0.1 localhost
::1 localhost ip6-localhost ip6-loopback
@@ -241,7 +242,7 @@ To detach from a `container1` and leave it running use `CTRL-p CTRL-q`.Then, att
```
$ docker attach container2
-/ # ifconfig
+root@0cb243cd1293:/# ifconfig
eth0 Link encap:Ethernet HWaddr 02:42:AC:11:00:03
inet addr:172.17.0.3 Bcast:0.0.0.0 Mask:255.255.0.0
inet6 addr: fe80::42:acff:fe11:3/64 Scope:Link
@@ -260,7 +261,7 @@ lo Link encap:Local Loopback
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
-/ # ping -w3 172.17.0.2
+root@0cb243cd1293:/# ping -w3 172.17.0.2
PING 172.17.0.2 (172.17.0.2): 56 data bytes
64 bytes from 172.17.0.2: seq=0 ttl=64 time=0.067 ms
64 bytes from 172.17.0.2: seq=1 ttl=64 time=0.075 ms
@@ -279,7 +280,7 @@ ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
```
-The default `docker0` bridge network supports the use of port mapping and `docker run --link` to allow communications between containers in the `docker0` network. These techniques are cumbersome to set up and prone to error. While they are still available to you as techniques, it is better to avoid them and define your own bridge networks instead.
+The default `docker0` bridge network supports the use of port mapping and `docker run --link` to allow communications between containers in the `docker0` network. These techniques are cumbersome to set up and prone to error. While they are still available to you as techniques, it is better to avoid them and define your own bridge networks instead.
## User-defined networks
@@ -421,7 +422,7 @@ Once you have several machines provisioned, you can use Docker Swarm to quickly
form them into a swarm which includes a discovery service as well.
To create an overlay network, you configure options on the `daemon` on each
-Docker Engine for use with `overlay` network. There are two options to set:
+Docker Engine for use with `overlay` network. There are three options to set:
@@ -483,7 +484,7 @@ built-in network drivers. For example:
$ docker network create --driver weave mynet
-You can inspect it, add containers too and from it, and so forth. Of course,
+You can inspect it, add containers to and from it, and so forth. Of course,
different plugins may make use of different technologies or frameworks. Custom
networks can include features not present in Docker's default networks. For more
information on writing plugins, see [Extending Docker](../../extend/index.md) and
diff --git a/components/engine/docs/userguide/networking/get-started-overlay.md b/components/engine/docs/userguide/networking/get-started-overlay.md
index 39d7da9169..89d5b2ca59 100644
--- a/components/engine/docs/userguide/networking/get-started-overlay.md
+++ b/components/engine/docs/userguide/networking/get-started-overlay.md
@@ -19,6 +19,7 @@ some pre-existing conditions before you can create one. These conditions are:
* Access to a key-value store. Docker 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 cluster.
+* Hosts within the cluster must have unique hostnames because the key-value store uses the hostnames to identify cluster members.
Though Docker Machine and Docker Swarm are not mandatory to experience Docker
multi-host networking, this example uses them to illustrate how they are
@@ -54,21 +55,20 @@ key-value stores. This example uses Consul.
instance using the [consul image from Docker
Hub](https://hub.docker.com/r/progrium/consul/). You'll do this in the next step.
-3. Start a `progrium/consul` container running on the `mh-keystore` machine.
+3. Set your local environment to the `mh-keystore` machine.
- $ docker $(docker-machine config mh-keystore) run -d \
+ $ eval "$(docker-machine env mh-keystore)"
+
+4. Start a `progrium/consul` container running on the `mh-keystore` machine.
+
+ $ docker run -d \
-p "8500:8500" \
-h "consul" \
progrium/consul -server -bootstrap
- A bash expansion `$(docker-machine config mh-keystore)` is used to pass the
- connection configuration to the `docker run` command. The client starts a
- `progrium/consul` image running in the `mh-keystore` machine. The server is
- called `consul` and is listening on port `8500`.
-
-4. Set your local environment to the `mh-keystore` machine.
-
- $ eval "$(docker-machine env mh-keystore)"
+ The client starts a `progrium/consul` image running in the
+ `mh-keystore` machine. The server is called `consul` and is
+ listening on port `8500`.
5. Run the `docker ps` command to see the `consul` container.
diff --git a/components/engine/docs/userguide/networking/work-with-networks.md b/components/engine/docs/userguide/networking/work-with-networks.md
index b668bc1c77..d2ac4693af 100644
--- a/components/engine/docs/userguide/networking/work-with-networks.md
+++ b/components/engine/docs/userguide/networking/work-with-networks.md
@@ -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.
@@ -111,7 +111,13 @@ The following are those options and the equivalent docker daemon flags used for
| `com.docker.network.bridge.enable_icc` | `--icc` | Enable or Disable Inter Container Connectivity |
| `com.docker.network.bridge.host_binding_ipv4` | `--ip` | Default IP when binding container ports |
| `com.docker.network.mtu` | `--mtu` | Set the containers network MTU |
-| `com.docker.network.enable_ipv6` | `--ipv6` | Enable IPv6 networking |
+
+The following arguments can be passed to `docker network create` for any network driver.
+
+| Argument | Equivalent | Description |
+|--------------|------------|------------------------------------------|
+| `--internal` | - | Restricts external access to the network |
+| `--ipv6` | `--ipv6` | Enable IPv6 networking |
For example, now let's use `-o` or `--opt` options to specify an IP address binding when publishing ports:
@@ -312,6 +318,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 +383,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 +403,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 +412,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 doesnt 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 +498,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 +532,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 +557,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 +568,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.
diff --git a/components/engine/docs/userguide/storagedriver/aufs-driver.md b/components/engine/docs/userguide/storagedriver/aufs-driver.md
index 76271cf0e1..4651e66e0c 100644
--- a/components/engine/docs/userguide/storagedriver/aufs-driver.md
+++ b/components/engine/docs/userguide/storagedriver/aufs-driver.md
@@ -148,7 +148,7 @@ layer IDs). Inside each file are the names of the directories that exist below
it in the stack
The command below shows the contents of a metadata file in
-`/var/lib/docker/aufs/layers/` that lists the the three directories that are
+`/var/lib/docker/aufs/layers/` that lists the three directories that are
stacked below it in the union mount. Remember, these directory names do no map
to image layer IDs with Docker 1.10 and higher.
diff --git a/components/engine/docs/userguide/storagedriver/imagesandcontainers.md b/components/engine/docs/userguide/storagedriver/imagesandcontainers.md
index e4293370f4..3f2594d3f6 100644
--- a/components/engine/docs/userguide/storagedriver/imagesandcontainers.md
+++ b/components/engine/docs/userguide/storagedriver/imagesandcontainers.md
@@ -110,7 +110,7 @@ single 8GB general purpose SSD EBS volume. The Docker data directory
centos latest c8a648134623 4 weeks ago 196.6 MB
ubuntu 15.04 c8be1ac8145a 7 weeks ago 131.3 MB
- $ du -hs /var/lib/docker
+ $ sudo du -hs /var/lib/docker
2.0G /var/lib/docker
$ time docker run --rm -v /var/lib/docker:/var/lib/docker docker/v1.10-migrator
@@ -275,12 +275,12 @@ image that you just pulled, make a change to it, and build a new image based on
command.
1. In an empty directory, create a simple `Dockerfile` that starts with the
-2. ubuntu:15.04 image.
+ ubuntu:15.04 image.
FROM ubuntu:15.04
2. Add a new file called "newfile" in the image's `/tmp` directory with the
-3. text "Hello world" in it.
+ text "Hello world" in it.
When you are done, the `Dockerfile` contains two lines:
@@ -291,7 +291,7 @@ command.
3. Save and close the file.
4. From a terminal in the same folder as your `Dockerfile`, run the following
-5. command:
+ command:
$ docker build -t changed-ubuntu .
Sending build context to Docker daemon 2.048 kB
@@ -310,14 +310,14 @@ command.
The output above shows a new image with image ID `94e6b7d2c720`.
5. Run the `docker images` command to verify the new `changed-ubuntu` image is
-6. in the Docker host's local storage area.
+ in the Docker host's local storage area.
REPOSITORY TAG IMAGE ID CREATED SIZE
changed-ubuntu latest 03b964f68d06 33 seconds ago 131.4 MB
ubuntu 15.04 013f3d01d247 6 weeks ago 131.3 MB
6. Run the `docker history` command to see which image layers were used to
-7. create the new `changed-ubuntu` image.
+ create the new `changed-ubuntu` image.
$ docker history changed-ubuntu
IMAGE CREATED CREATED BY SIZE COMMENT
diff --git a/components/engine/docs/userguide/storagedriver/index.md b/components/engine/docs/userguide/storagedriver/index.md
index 76671c7196..60d1255d77 100644
--- a/components/engine/docs/userguide/storagedriver/index.md
+++ b/components/engine/docs/userguide/storagedriver/index.md
@@ -25,7 +25,7 @@ Docker relies on driver technology to manage the storage and interactions associ
If you are new to Docker containers make sure you read ["Understand images, containers, and storage drivers"](imagesandcontainers.md) first. It explains key concepts and technologies that can help you when working with storage drivers.
-### Acknowledgement
+### Acknowledgment
The Docker storage driver material was created in large part by our guest author
Nigel Poulton with a bit of help from Docker's own Jérôme Petazzoni. In his
diff --git a/components/engine/docs/userguide/storagedriver/overlayfs-driver.md b/components/engine/docs/userguide/storagedriver/overlayfs-driver.md
index 9abc1dbe65..3f948f6bec 100644
--- a/components/engine/docs/userguide/storagedriver/overlayfs-driver.md
+++ b/components/engine/docs/userguide/storagedriver/overlayfs-driver.md
@@ -111,7 +111,7 @@ directories.
drwxr-xr-x 4 root root 4096 Oct 28 11:06 upper
drwx------ 3 root root 4096 Oct 28 11:06 work
-These four filesystem objects are all artefacts of OverlayFS. The "lower-id"
+These four filesystem objects are all artifacts of OverlayFS. The "lower-id"
file contains the ID of the top layer of the image the container is based on.
This is used by OverlayFS as the "lowerdir".
diff --git a/components/engine/docs/userguide/storagedriver/zfs-driver.md b/components/engine/docs/userguide/storagedriver/zfs-driver.md
index 3ecbb300d0..e55e7396f1 100644
--- a/components/engine/docs/userguide/storagedriver/zfs-driver.md
+++ b/components/engine/docs/userguide/storagedriver/zfs-driver.md
@@ -133,11 +133,11 @@ you should substitute your own values throughout the procedure.
1. If it is running, stop the Docker `daemon`.
-1. Install `the software-properties-common` package.
+1. Install the `software-properties-common` package.
This is required for the `add-apt-repository` command.
- $ sudo apt-get install software-properties-common
+ $ sudo apt-get install -y software-properties-common
Reading package lists... Done
Building dependency tree