Once you have microservices running inside containers, you need them to interact with each other. Since we are bridging the container sockets with some local sockets on the host, it is pretty transparent from an external client. Each host can have a public DNS or IP, and programs can simply use it to connect to the various services. In other words, a service deployed inside a container on host A can talk to a service deployed inside a container on host B ;as long as host A and B have a public address and expose the local sockets that are bridged with the containers sockets.

However, when two containers need to run on the same host, using the public DNS to make them interact with each other is less than optimal, particularly, if one of the containers is private to the host. For example, if you run a container in Docker for internal needs, like a caching service, its access should be restricted to the localhost.

To make this use case easier to implement, Docker provides a user-defined network feature, which lets you create local virtual networks. Containers can be added to them, and if they run with a --name option, Docker acts as a DNS resolver, and makes them available in those networks via their names.

Let's create a new runnerly network with the network command as follows:

$ docker network create -driver=bridge runnerly  
4a08e29d305b17f875a7d98053b77ea95503f620df580df03d83c6cd1011fb67 

Once this network is created, we can run containers in it, using the --net option. Let's run one container with the tokendealer name, like this:

$ docker run --rm --net=runnerly --name=tokendealer -v /tmp/logs:/logs -p 5555:8080 -it runnerly/tokendealer 
2017-05-18 19:42:46 circus[5] [INFO] Starting master on pid 5 
2017-05-18 19:42:46 circus[5] [INFO] sockets started 
2017-05-18 19:42:46 circus[5] [INFO] Arbiter now waiting for commands 
2017-05-18 19:42:46 circus[5] [INFO] nginx started 
2017-05-18 19:42:46 circus[5] [INFO] web started 

If we run a second container with the same image and a different name on the same network, it can ping the first container directly with its tokendealer name:

$ docker run --rm --net=runnerly --name=tokendealer2 -v /tmp/logs:/logs -p 8082:8080 -it runnerly/tokendealer ping tokendealer 
PING tokendealer (172.20.0.2): 56 data bytes 
64 bytes from 172.20.0.2: icmp_seq=0 ttl=64 time=0.474 ms 
64 bytes from 172.20.0.2: icmp_seq=1 ttl=64 time=0.177 ms 
64 bytes from 172.20.0.2: icmp_seq=2 ttl=64 time=0.218 ms 
^C 

Using dedicated Docker networks for your microservices container when you deploy them is good practice even if you have a single container running. You can always attach new containers within the same network, or tweak the network permissions from the shell.

Having to deploy several containers to run one microservice requires you to make sure that both containers are properly configured when launched.

To make that configuration easier, Docker has a high-level tool called Docker Compose, presented in the next section.