2. Standalone Docker Networking
2.1 Default Bridge Network
3. User-defined Bridge Networks
3.1 The Host Network
3.2 Macvlan Network
4. Distributed Networking
4.1 Overlay Networks
5. Docker Network Plugins
Docker can be used in various use cases: the standalone mode, using Docker Compose, in a single host, or by deploying containers and connecting Docker engines across multiple hosts. The user can use Docker containers with the default network, the host network, or other types of more advanced networks like overlays. This depends on the use case and/or the adopted technologies.
In this tutorial, we are going to understand the different types of container networking. We are also going to study containers networking. We will see different types of networking, and finally, we will understand how to extend Docker networking using plugins. This article is the second part of a series. For part I, check out this article. We also have resources on Kubernetes Networking and monitoring Docker containers with cAdvisor, for some great further reading.
After a fresh Docker installation, you can find a default bridge network up and running.
We can see it by typing docker network ls:
If you use ifconfig command, you will also notice that this network interface is called "docker0":
All Docker installations have this network. If you run a container, say, Nginx, it will be attached by default to the bridge network:
docker run -dit --name nginx nginx:latest
You can check the containers running inside a network, by using the "inspect" command:
Docker uses a software-based bridge network which allows containers connected to the same bridge network to communicate while isolating them from other containers not running in the same bridge network.
Let's see how containers running in the same bridge network can connect to each other. Let's create two containers for testing purposes:
These are the IP addresses of our containers:
Let's try to ping a container from another one using one of these IP addresses. For example, ping the container named "busybox1" from "busybox2", using its IP 172.17.0.3.
So, containers on the same bridge can see each other using their IPs. What if I want to use the containers' name instead of the IP.
We can understand that containers running on the same bridge network are able to see each other using their IP addresses. On the other hand, the default bridge network does not support automatic service discovery.
Using the Docker CLI, it is possible to create other networks. You can create a second bridge network using:
docker network create my_bridge --driver bridge
Now, attach "busybox1" and "busybox2" to the same network:
Retry pinging "busybox1" using its name:
We can conclude that only user-defined bridge networks support automatic service discovery. If you need to use service discovery with containers, don't use the default bridge, create a new one.
A container running in the host network matches the networking configurations of the host.
If we take the example of an Nginx image, we can notice that it exposes the port 80.
If we run the container, we should normally publish the port 80 on another port, say 8080.
docker run -dit -p 8080:80 nginx:latest
The container is now accessible on port 8080:
When we run the same container on the host network, published ports will be ignored since the port 80 of the host will be used in all cases. If you run:
docker run -dit --name nginx_host --network host -p 8080:80 nginx:latest
Docker will show a warning:
WARNING: Published ports are discarded when using host network mode
Let's remove this container and re-run it without publishing its ports:
You can now run a "curl" on the port 80 of the host machine to check that the web server responds:
Since there is no network address translation (NAT), running a container on the host network can optimize performance. When you run a container on the host network, its network will not be isolated from the host, and it will not get its own IP; these are the limits of this type of network.
If you are, for instance, developing an application to monitor traffic, which is expected to be directly connected to the underlying physical network, you can use the macvlan network driver. This driver assigns a MAC address to each container's virtual network interface.
When you create a macvlan network, you need to specify the parent, which is the used host interface through which the traffic is physically routed.
In some cases, you need to isolate a container even from ingoing/outgoing traffic, you can use this type of network that lacks a network interface.
The only interface the container will have is the local loopback interface (127.0.0.1).
Your container platform may have different hosts, and in each there are some containers running. These containers may need to communicate with each other. This is when overlay networks are useful.
The overlay network is a distributed network created among multiple Docker daemons in different hosts. All containers connected to this network can communicate.
Docker Swarm, for example, uses overlay networking to handle the traffic between swarm services.
In order to test this, let's create 3 Docker Machines (a manager + 2 workers):
After configuring a different shell for each of these machines (using eval $(docker-machine env <machine_name>), you initialize Swarm on the manager, using the following command:
docker swarm init --advertise-addr <IP_address>
Don't forget to execute the join command on both workers:
docker swarm join --token xxxx <IP_address>:2377
If you list the networks on each host using docker network ls, you will notice the existence of an overlay ingress network:
o5dnttidp8yq ingress overlay swarm
On the manager, create a new service with three replicas:
To see the swarm nodes where your service has been deployed, use docker service ps nginx.
In my case, I have a container running in each of my nodes.
If you inspect the ingress networking using docker inspect ingress, you will be able to see the list of peers (swam nodes) connected to the same network:
The ingress network is a particular type of overlay network created by default.
When we create a service without connecting it to a user-defined overlay network, it connects by default to this ingress network. Using Nginx, here is an example of a service running without a user-defined overlay network but connected by default to the ingress network.
There are other types of use cases that need new types of networks. You may also want to use another technology to manage your overlay networks and VXLAN tunnels.
Docker networking is extensible and allows using plugins to extend the features provided by default.
You can use or develop networking plugins. You can also find some verified networking plugins on Docker Hub.
Each plugin has different use cases and installation procedures. For example, Weave Net is a virtual Docker network that connects containers across a cluster of hosts and enables automatic discovery.
To install it, you can follow the official instructions on the Docker Hub:
You can create a Weave Net network and make it attachable using:
Then, create containers using the same network:
docker run -dit --rm --network=my_custom_network -p 8080:80 nginx
Part III of this series is all about Kubernetes Networking, check it out here. If you missed part I, check it out here. If you're interested in monitoring your Docker containers, learn how to do it in our article about monitoring Docker with cAdvisor. Also, check out our blog post on Monitoring Kubernetes with Prometheus.