The Container Network Model | DevOps Material | VisualPath

The Container Network Model

The CNM was introduced in Engine 1.9.0 (November 2015). The CNM adds the notion of a network, and a new top-level command to manipulate and see those networks: docker network.

What's in a network?
• Conceptually, a network is a virtual switch.
• It can be local (to a single Engine) or global (across multiple hosts).
• A network has an IP subnet associated with it.
• A network is managed by a driver.
• A network can have a custom IPAM (IP allocator).
• Containers with explicit names are discoverable via DNS.
• All the drivers that we have seen before are available.
• A new multi-host driver, overlay, is available out of the box.
• More drivers can be provided by plugins (OVS, VLAN...)
Creating a network
Let's create a network called dev.

The network is now visible with the network ls command:

Placing containers on a network

We will create a named container on this network. It will be reachable with its name, search.

$ docker run -d --name search --net dev elasticsearch
aec474a67e5d12490f503a9ab209cd6074f0b7ddcb12ee783476b3476ad2764a

Communication between containers

Now, create another container on this network.

$ docker run -ti --net dev alpine sh
Unable to find image 'alpine:latest'locally
latest: Pulling from library/alpine
2aecc7e1714b: Pull complete
Digest: sha256:0b94d1d1b5eb130dd0253374552445b39470653fb1a1ec2d81490948876e462c
Status: Downloaded newer image for alpine:latest
/ #

From this new container, we can resolve and ping the other one, using its assigned name:

/ # ping search
PING search (172.18.0.2): 56 data bytes
64 bytes from 172.18.0.2: seq=0 ttl=64 time=0.136 ms
64 bytes from 172.18.0.2: seq=1 ttl=64 time=0.063 ms
64 bytes from 172.18.0.2: seq=2 ttl=64 time=0.092 ms
3 packets transmitted, 3 received, 0% packet loss, time 2000ms rtt min/avg/max/mdev = 0.114/0.149/0.221/0.052 ms
root@0ecccdfa45ef:/#

Resolving container addresses

In Docker Engine 1.9, name resolution is implemented with /etc/hosts, and updating it each time containers are added/removed.
[root@0ecccdfa45ef /]# cat /etc/hosts
.0ecccdfa45ef
.localhost
::1 localhost ip6-localhost ip6-loopback fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix ff02::1 ip6-all nodes ff02::2 ip6-all routers
.search
.search.dev
In Docker Engine 1.10, this has been replaced by a dynamic resolver.
(This avoids race conditions when updating /etc/hosts.)
Connecting multiple containers together
• Let's try to run an application that requires two containers.
• The first container is a web server.
• The other one is a Redis data store.
• We will place them both on the dev network created before.
Running the web server
• The application is provided by the container image jpetazzo/trainingwheels.
• We don't know much about it so we will try to run it and see what happens!

Start the container, exposing all its ports:

$ docker run --net dev -d -P jpetazzo/trainingwheels

Check the port that has been allocated to it:

$ docker ps -l

Test the web server
• If we connect to the application now, we will see an error page:

• This is because the Redis service is not running.

• This container tries to resolve the name redis.
Note: we're not using an FQDN or an IP address here; just redis.
Start the data store
• We need to start a Redis container.
• That container must be on the same network as the web server.
• It must have the right name (redis) so the application can find it.
Start the container:

$ docker run --net dev --name redis -d redis

Test the web server again
• If we connect to the application now, we should see that the app is working correctly:

 • When the app tries to resolve redis, instead of getting a DNS error, it gets the IP address of our Redis container. 

For more information about Visualpath, visit www.visualpath.in and follow the company on Facebook and Twitter.