From f3cb808e9d7d870dc71510bdeecec15745bb44b5 Mon Sep 17 00:00:00 2001 From: John Gardiner Myers Date: Tue, 21 Jan 2014 22:08:11 -0800 Subject: [PATCH 1/2] Grammar and punctuation fixes Docker-DCO-1.1-Signed-off-by: John Gardiner Myers (github: johngmyers) --- docs/sources/use/networking.rst | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/sources/use/networking.rst b/docs/sources/use/networking.rst index 4e75fbc20..3b1606e2c 100644 --- a/docs/sources/use/networking.rst +++ b/docs/sources/use/networking.rst @@ -31,11 +31,11 @@ itself for this purpose. Thus, when the Docker daemon starts it : At runtime, a :ref:`specific kind of virtual -interface` is given to each containers which is then -bonded to the ``docker0`` bridge. Each containers also receives a +interface` is given to each container which is then +bonded to the ``docker0`` bridge. Each container also receives a dedicated IP address from the same range as ``docker0``. The ``docker0`` IP address is then used as the default gateway for the -containers. +container. .. code-block:: bash @@ -135,7 +135,7 @@ What's about the vethXXXX device? Well. Things get complicated here. The ``vethXXXX`` interface is the host side of a point-to-point link -between the host and the corresponding container, the other side of +between the host and the corresponding container; the other side of the link being materialized by the container's ``eth0`` interface. This pair (host ``vethXXX`` and container ``eth0``) are connected like a tube. Everything that comes in one side will come out From 1c06a9196451a595c71a47ba9fb4e9f4bc270746 Mon Sep 17 00:00:00 2001 From: John Gardiner Myers Date: Tue, 21 Jan 2014 22:24:04 -0800 Subject: [PATCH 2/2] Wording improvements Docker-DCO-1.1-Signed-off-by: John Gardiner Myers (github: johngmyers) --- docs/sources/use/networking.rst | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/docs/sources/use/networking.rst b/docs/sources/use/networking.rst index 3b1606e2c..431158cc3 100644 --- a/docs/sources/use/networking.rst +++ b/docs/sources/use/networking.rst @@ -8,7 +8,7 @@ Configure Networking Docker uses Linux bridge capabilities to provide network connectivity to containers. The ``docker0`` bridge interface is managed by Docker -itself for this purpose. Thus, when the Docker daemon starts it : +for this purpose. When the Docker daemon starts it : - creates the ``docker0`` bridge if not present - searches for an IP address range which doesn't overlap with an existing route @@ -34,7 +34,7 @@ At runtime, a :ref:`specific kind of virtual interface` is given to each container which is then bonded to the ``docker0`` bridge. Each container also receives a dedicated IP address from the same range as ``docker0``. The -``docker0`` IP address is then used as the default gateway for the +``docker0`` IP address is used as the default gateway for the container. .. code-block:: bash @@ -55,8 +55,8 @@ which is dedicated to the 52f811c5d3d6 container. How to use a specific IP address range --------------------------------------- -Docker will try hard to find an IP range which is not used by the -host. Even if it works for most cases, it's not bullet-proof and +Docker will try hard to find an IP range that is not used by the +host. Even though it works for most cases, it's not bullet-proof and sometimes you need to have more control over the IP addressing scheme. For this purpose, Docker allows you to manage the ``docker0`` bridge @@ -118,25 +118,25 @@ In this scenario: Container intercommunication ------------------------------- -Containers can communicate with each other according to the ``icc`` -parameter value of the Docker daemon. +The value of the Docker daemon's ``icc`` parameter determines whether +containers can communicate with each other over the bridge network. - The default, ``-icc=true`` allows containers to communicate with each other. - ``-icc=false`` means containers are isolated from each other. -Under the hood, ``iptables`` is used by Docker to either accept or +Docker uses ``iptables`` under the hood to either accept or drop communication between containers. .. _vethxxxx-device: -What's about the vethXXXX device? +What is the vethXXXX device? ----------------------------------- Well. Things get complicated here. The ``vethXXXX`` interface is the host side of a point-to-point link between the host and the corresponding container; the other side of -the link being materialized by the container's ``eth0`` +the link is the container's ``eth0`` interface. This pair (host ``vethXXX`` and container ``eth0``) are connected like a tube. Everything that comes in one side will come out the other side.