Docker Certified Associate Exam Series (Part-5): Networking
In the previous blog of this 7-part series, we discussed Installation and Configuration. This blog dives into Networking.
Here are the six other blogs in the series:
- Docker Certified Associate Exam Series (Part-1): Container Orchestration
- Docker Certified Associate Exam Series (Part-2): Kubernetes
- Docker Certified Associate Exam Series (Part-3): Image Creation, Management, and Registry
- Docker Certified Associate Exam Series (Part-4): Installation and Configuration
- Docker Certified Associate Exam Series (Part-6): Docker Engine Security
- Docker Certified Associate Exam Series (Part-7): Docker Engine Storage & Volumes
What is Docker Network?
Docker network is a feature of the Docker platform that allows users to create and manage virtual networks for their containers. With the Docker network, developers can create multiple networks and attach containers to each network as needed. This enables the containers to communicate as if they were on the same physical network, regardless of their actual location.
In this part, we'll cover how to create and manage different types of networks in Docker.
Docker Network Types
Installing Docker on a host machine automatically creates three types of networks: none, bridge, and host networks.
- Bridge network: This is the default network that Docker attaches to containers once created. This is a private internal network whose IP address is typically 172.17.0.1 and assigns IP addresses in the 172.17.1 range to all containers attached. Isolated containers within the same host use these IP addresses to communicate. The bridge network cannot facilitate external communication unless container ports are exposed to ports on the host.
- Host network: This network helps eliminate isolation between containers and hosts, letting containers access the host’s IP address without having to expose any ports. With the host network, you cannot run multiple containers on the same host, as the host’s external port is common to all containers within the host.
- None network: The "none" network type in Docker is used to run a container in isolated mode, where the container is not attached to any network. This means that the container does not have network connectivity and cannot communicate with other containers or external hosts. The "none" network type can be useful in certain security or testing scenarios where network access needs to be restricted.
To specify the default network on which you want to run your container, define it as an attribute with the run command as shown below:
docker run -d --name wbeapp --network=none nginx
or
docker run -d --name webapp --network=host nginx
To display the network mode, run the command:
docker inspect webapp | grep NetworkMode
User-Defined Networks
By default, Docker attaches containers to the Bridge network. You can also create your own Docker networks using the network create
command as shown below:
docker network create --driver bridge --subnet 182.18.0.0/16 custom-isolated-network
The above command creates a Bridge network named custom-isolated-network with the address 182.18.0.0/16.
To list the networks available on a host, type the command:
docker network ls
To check the configuration settings of a network, use the command:
docker inspect custom-isolated-network
Embedded DNS
Containers within the same host can resolve and communicate with each other using container names, i.e:
mysql.connect(container-name)
This is made possible by an embedded DNS server present at the host on the address 127.0.0.1. This server creates a namespace for each container and connects them using virtual ethernet pairs.
Additional Networking Commands
Some of the common tasks you will carry out with networking commands include:
- Listing all available networks:
docker network ls
- Checking for additional network information, including subnets, gateways, drivers, and IP addresses:
docker network inspect <NETWORK NAME>
- Attaching a container to a custom network:
docker network connect <NETWORK NAME> <CONTAINER NAME>
- Detaching a container from a custom network:
docker network disconnect <NETWORK NAME> <CONTAINER NAME>
- Deleting a custom network:
docker network rm <NETWORK NAME>
- Removing all unused networks:
docker network prune
Demo-Docker Network
In this practical lab, you will test your grasp of networking commands in Docker. Some of the content you will cover includes:
- Listing the default available networks
- Obtaining details of networks
- Inspecting network connections in containers
- Creating custom networks
- Attaching & Detaching Containers
- Connecting to remote networks
- Deleting networks
Namespaces
Docker uses namespaces to isolate networks, containers, and processes within the same host. While a container cannot gain access to processes running in a different namespace, the host can view all processes running within its namespaces. A container should, therefore, ‘think’ that it is running on its 'own' host. The host can establish connectivity and communication between namespaces.
If you list the processes running within a container, you will only see one process. Inspecting processes as a root user on the host will return various processes, including the containers on the host.
The host has an ethernet interface, routing table, and an Address Resolution Protocol (ARP) table that enables communication with other hosts and processes.
Any time you create a container, the host assigns it a namespace. This namespace comes complete with its own interface, routing, and ARP tables.
- To create new namespaces on the host named red and blue, run the following commands respectively:
ip netns add red
ip netns add blue
- You list all namespaces in a host using the command:
ip netns
- To display the host interfaces, run the command:
ip link
- To check for interfaces within a namespace, run the command:
ip netns exec red ip link
- Alternatively, you could type the command:
ip -n red link
- To check IP addresses on the ARP table within a host, run the command:
arp
Since namespaces don’t connect to other processes or hosts, running the arp
command within a namespace will return no results:
ip netns exec red arp
To display the routing table within the host, run the route
command:
route
Naturally, namespaces cannot communicate with each other. To establish a connection between two namespaces, we use a virtual ethernet pair/pipe. To create these links for the red and blue namespaces we created earlier, use the command:
ip link add veth-red type veth peer name veth-blue
We can now attach each end of the link to the respective namespaces using the command:
ip link set veth-red netns red
ip link set veth-blue netns blue
Now, we assign IP addresses to the red and blue namespaces by using the commands:
ip -n red addr add 192.168.15.1/16 dev veth-red
ip -n blue addr add 192.168.15.2/16 dev veth-blue
These links are not yet active. To activate the connection, we bring up the links using the commands:
ip -n red link set veth-red up
ip -n blue link set veth-blue up
You can now check the connection between these namespaces:
ip netns exec red ping 192.168.15.2
ip netns exec blue ping 192.168.15.1
If you run the arp
command, it will display the details of the other namespace’s interface:
ip netns exec red arp
This process only applies when we are trying to connect two namespaces. With multiple namespaces, we will create a virtual network that provides a switch connection between multiple processes. There exist several switch solutions for Docker. For this exercise, we’ll use a Linux Bridge to connect various namespaces in a Docker host.
First, we create an interface named v-net-0 of type bridge, using the command:
ip link add v-net-0 type bridge
We then bring up this link using this command:
ip link set dev v-net-0 up
We’ll now connect namespaces to this interface by first deleting the virtual link we set up between the red and blue namespaces we created earlier.
ip -n red link del veth-red
This command deletes the entire connection between the two namespaces. We will now create new cable pairs that connect namespaces to the virtual network.
ip link add veth-red type veth peer name veth-red-br
ip link add veth-blue type veth peer name veth-blue-br
You can now attach one end of this link to the namespace:
ip link set veth-red netns red
ip link set veth-blue netns blue
We then connect the other ends of these links to the network:
ip link set veth-red-br master v-net-0
ip link set veth-blue-br master v-net-0
We then assign IP addresses to these links:
ip -n red addr add 192.168.15.1/24 dev veth-red
ip -n blue addr add 192.168.15.2/24 dev veth-blue
To activate these links, use the following commands to bring them up:
ip -n red link set veth-red up
ip -n blue link set veth-blue up
Now, assign an IP address to the host’s interface to establish connectivity between the host and namespaces:
ip addr add 192.168.15.5/24 dev v-net-0
We can now connect to the host from all namespaces. To verify this, run the ping command:
ping 192.168.15.5
This network is still private and cannot be accessed from outside the host. To connect your namespaces to an external network through the host’s ethernet port, define a gateway on the host’s routing table by running the command.
ip netns exec blue ip route add 192.168.1.0/24 via 192.168.15.5
This establishes a connection between the namespaces and external hosts. To fetch and display packets from the external host, you will add Network Address Translation (NAT) functionality to your host by typing the command:
iptables -t nat -A POSTROUTING -s 192.168.15.0/24 -j MASQUERADE
The NAT translator will send packets to the Local Area Network (LAN) using its own name and address. The destination network will then assume that requests are coming from the host but not the namespace. If the LAN is connected to the internet, we will add a default gateway to establish a connection between the host and the internet, using the command:
ip netns exec blue iproute add default via 192.168.15.5
Now, we can connect an external host to the namespace by adding a port that forwards traffic coming into the host’s incoming port to a namespace’s port:
iptables -t nat -A PREROUTING --dport 80 -to-destination 192.168.15.2:80 -j DNAT
Docker Networking Deep Dive
As outlined in the first section of this article, by default, Docker creates 3 types of networks.
- None network: With this network, containers are detached from their hosts and networks. Even containers sharing a host cannot communicate with each other.
- Host network: This network offers no isolation between containers and their hosts. If you have a web application container listening on port 80, it will be accessible from the host’s port 80 without requiring the publishing or mapping of ports. Two processes in this network cannot be active within the same host network since they share ports.
- Bridge network: This is the default network assigned to Docker containers and processes. It assigns IP addresses to all attached containers, allowing for communication. When a container is initiated, Docker attaches it to the default Bridge network. Docker knows this network as bridge, but the host names this network docker0. This network is assigned the IP address 172.17.0.1.
Whenever a container is initiated, Docker automatically creates and assigns it a Namespace. You can check for default networks in your host by running the command:
ip netns
To list the namespaces attached to a container, run the command:
docker inspect
When attaching containers to the bridge network, Docker uses a Virtual Ethernet Interface. To list all interfaces within a host, run the command:
ip link
To display interfaces attached to a specific namespace:
ip -n <namespace-ID> link
To check on the IP address assigned to a namespace:
ip -n <namespace-ID> addr
Docker creates a namespace every time a container is initiated. The interfaces of virtual ethernet pairs are paired up using odd and even numbers.
To enable external access to your namespaces, you will need to map/publish your ports using the command:
docker run -p 8080:80 nginx
With this command, the Nginx server is now accessible from the host’s IP address at port 8080. To access this server from an external host, run the following command:
curl http://192.168.1.0:8080
Docker can forward traffic to the container port by creating a NAT rule, which appends rules to the IP routing table and changes the destination port from 8080 to 80. This is what the NAT table for the above host will look like:
iptables \
-t nat \
-A DOCKER \
-j NAT \
--dport 8080 \
--to-destination 172.17.0.3:80
You can view these settings by running the iptables
command:
iptables -nvL -t nat
At Kodekloud, we offer a comprehensive Docker Associate Exam preparation course that explains all the Docker concepts in the certification's curriculum.
After each topic, you get interactive quizzes to help you internalize the concepts learned. At the end of the course, we have mock exams that will help familiarize you with the exam format, time management, and question types.
You can now proceed to the next part of this series: Docker Certified Associate Exam Series (Part-6): Docker Engine Security.
Here is the previous part of the Docker Certified Associate Exam Series: Docker Certified Associate Exam Series (Part-3): Image Creation, Management, and Registry
Research Questions & Conclusion
This concludes the Networking chapter of the DCA certification exam. Here is a quick quiz to help you assess your knowledge. Leave your answers in the comments below and tag us back.
Quick Tip – Questions below may include a mix of DOMC and MCQ types.
1. What IPTables chains does Docker modify to configure port mapping on a host?
[A] INPUT
[B] FORWARD
[C] DOCKER
[D] OUTPUT
2. Service Discovery allows containers and services to locate and communicate with each other using their names.
[A] True
[B] False
3. What is the command to create an overlay network driver called my-overlay with subnet 10.15.0.0/16?
[A] docker network create my-overlay
[B] docker network create --driver overlay --subnet 10.15.0.0/16 my-overlay
[C] docker network create -d overlay -subnet 10.15.0.0/16
[D] docker network create overlay my-overlay
4. The built-in DNS server in Docker always runs at IP address …
[A] 127.0.0.11
[B] 127.0.0.1
[C] 172.17.0.3
[D] 172.17.0.1
5. The … network disables all networking. Usually used in conjunction with a custom network driver
[A] host
[B] bridge
[C] overlay
[D] none
6. Host is the default network a container gets attached to.
[A] True
[B] False
7. What is the command to connect a running container with the name myapp to the existing bridge network my-net?
[A] docker container connect myapp my-net
[B] docker container attach myapp my-net
[C] docker network connect my-net myapp
[D] docker network connect myapp my-net
8. If you use the … network mode for a container, that container’s network stack is not isolated from the Docker host (the container shares the host’s networking namespace), and the container does not get its own IP-address allocated
[A] host
[B] bridge
[C] overlay
[D] NAT
9. Docker requires an external DNS server to be configured during installation to help the containers resolve each other using the container name.
[A] True
[B] False
By following this study guide till this part of the series, you have prepared yourself to handle all Docker Engine Networking questions and practical scenarios – and are, of course, a step closer to passing the DCA certification test.