This rather massive tutorial contains a comprehensive explanation of how a Docker bridge network can be reproduced using common Linux command-line tools such as ip and iptables.

With a bottom-up approach, the tutorial starts with the basic concepts of Linux network namespaces and virtual Ethernet devices (veth pairs) and then moves on to illustrate the need for a "bridge" device to connect multiple network namespaces together and the involved routing and iptables rules.

It also covers the mechanisms of network address translation (NAT) and port forwarding, so the next time you run docker run -p 8080:80 nginx, you'll know what exactly is going on under the hood.

However, this tutorial might be too much to digest at once. So, if you feel that you're getting lost in the details, you can always start with solving the skill path's challenges and come back to the individual sections of this tutorial when/if you get stuck.

Docker (and similar container runtimes) gives the containerized application the illusion of running in a dedicated network environment. This is achieved by using Linux network namespaces that provide a fully isolated set of network devices, IP protocol stacks, routing tables, firewall rules, etc., for each container.

We'll start the practice section of this learning path with a simple challenge where you'll need to create a new network namespace using basic Linux commands.

Placing a container in its own network namespace to give the containerized application the illusion of a private network environment is a very powerful trick. However, such an isolation would be useless if it wasn't possible to communicate with the containerized apps.

In this challenge, you'll need to connect a newly created network namespace with the host's (root) network namespace using a virtual Ethernet device:

Connecting a new network namespace to the host's network namespace is relatively simple. However, containers rarely run in solitude. Most of the time, you'll find tens, if not hundreds, of containers running on a single server.

In this follow-up challenge, you'll learn about the extra complexity that arises when you need to connect not two but multiple network namespaces together, and how to overcome the problem using a bridge device:

Network devices connected to a single bridge network can communicate with each other on the link layer (L2). However, this doesn't suffice for containers to communicate with the outside world.

In this challenge, you'll learn how to set up network address translation (NAT) for a bridge network so that the containers can reach the outside world (e.g., the internet):

Every container connected to a bridge network usually gets an IP address from the bridge network's subnet. Within the same bridge network, containers can communicate with each other using this IP address, and you can also access the container from the host via this IP address. However, such an IP address usually is not reachable from the outside world.

The simplest way to expose a containerized application to the outside world is to "publish" the container's port to another port on one of the host's public interfaces. In this challenge, you'll learn how Docker (and similar container runtimes) implements it using a couple of iptables rules:

At this point, you should have a good understanding of all the moving parts involved in creating a Docker bridge network. The only thing left to do is to put all the pieces together and reproduce the Docker bridge network from scratch.

To prove your container networking mastery, solve this ultimate challenge:

Good luck!