github.com/endocode/docker@v1.4.2-0.20160113120958-46eb4700391e/docs/userguide/networking/default_network/tools.md (about)

     1  <!--[metadata]>
     2  +++
     3  draft=true
     4  title = "Tools and Examples"
     5  keywords = ["docker, bridge, docker0, network"]
     6  [menu.main]
     7  parent = "smn_networking_def"
     8  +++
     9  <![end-metadata]-->
    10  
    11  <!--[metadata]>
    12  Dave Tucker instructed remove this.  We may want to add it back in later under another form. Labeled DRAFT for now. Won't be built.
    13  <![end-metadata]-->
    14  
    15  # Tools and examples
    16  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:
    17  - Jérôme Petazzoni has created a `pipework` shell script to help you
    18  
    19    connect together containers in arbitrarily complex scenarios:
    20  
    21    [https://github.com/jpetazzo/pipework](https://github.com/jpetazzo/pipework)
    22  
    23  - Brandon Rhodes has created a whole network topology of Docker
    24  
    25    containers for the next edition of Foundations of Python Network
    26  
    27    Programming that includes routing, NAT'd firewalls, and servers that
    28  
    29    offer HTTP, SMTP, POP, IMAP, Telnet, SSH, and FTP:
    30  
    31    [https://github.com/brandon-rhodes/fopnp/tree/m/playground](https://github.com/brandon-rhodes/fopnp/tree/m/playground)
    32  
    33  Both tools use networking commands very much like the ones you saw in the previous section, and will see in the following sections.
    34  
    35  # Building a point-to-point connection
    36  <a name="point-to-point"></a>
    37  
    38  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).
    39  
    40  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.
    41  
    42  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:
    43  
    44  ```
    45  # Start up two containers in two terminal windows
    46  
    47  $ docker run -i -t --rm --net=none base /bin/bash
    48  root@1f1f4c1f931a:/#
    49  
    50  $ docker run -i -t --rm --net=none base /bin/bash
    51  root@12e343489d2f:/#
    52  
    53  # Learn the container process IDs
    54  # and create their namespace entries
    55  
    56  $ docker inspect -f '{{.State.Pid}}' 1f1f4c1f931a
    57  2989
    58  $ docker inspect -f '{{.State.Pid}}' 12e343489d2f
    59  3004
    60  $ sudo mkdir -p /var/run/netns
    61  $ sudo ln -s /proc/2989/ns/net /var/run/netns/2989
    62  $ sudo ln -s /proc/3004/ns/net /var/run/netns/3004
    63  
    64  # Create the "peer" interfaces and hand them out
    65  
    66  $ sudo ip link add A type veth peer name B
    67  
    68  $ sudo ip link set A netns 2989
    69  $ sudo ip netns exec 2989 ip addr add 10.1.1.1/32 dev A
    70  $ sudo ip netns exec 2989 ip link set A up
    71  $ sudo ip netns exec 2989 ip route add 10.1.1.2/32 dev A
    72  
    73  $ sudo ip link set B netns 3004
    74  $ sudo ip netns exec 3004 ip addr add 10.1.1.2/32 dev B
    75  $ sudo ip netns exec 3004 ip link set B up
    76  $ sudo ip netns exec 3004 ip route add 10.1.1.1/32 dev B
    77  ```
    78  
    79  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.
    80  
    81  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.
    82  
    83  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.