DEV Community

Cover image for Understanding Docker Networking: A Practical, Small-Scale Production Emulation
Faizan Firdousi
Faizan Firdousi

Posted on

Understanding Docker Networking: A Practical, Small-Scale Production Emulation

So I was as usual learning about Docker, and got to know that Docker networking is surprisingly powerful for containerized application design.

When you create a Docker container, it by default takes up the default bridge network, and the container is assigned a private IP by the internal IPAM (IP Address Management) driver automatically. But you can also create your own user-defined bridge network, and because of that, containers can talk to each other via their container names (service discovery), provided they are in the same network. In the default bridge network, containers can only communicate by IP address.

I tried creating a small production-style Docker architecture for understanding. Here you have four containers: an API server, web frontend, a database, and a reverse proxy, with three bridge networks: database, backend, and frontend, each playing a specific role in a microservices-like layout.

The API server is in both the database and backend networks, while the Nginx reverse proxy is in both the frontend and backend networks because it has to route traffic from one port to another. Containers in the same network can communicate and ping each other; others cannot unless you explicitly connect a container to multiple networks.

The database network is isolated and denied internet access using the --internal flag because it's a convenient way of securing your database. Although the containers inside this internal network can communicate with each other, they cannot access the internet, which adds an extra layer of security for sensitive data.

The rest of the containers get internet access in the classic but interesting way: each has its own private IP address and is connected to docker0 via virtual Ethernet pairs (veth pairs). The docker0 bridge acts like a virtual switch responsible for routing traffic between containers and the host’s network interface. This is fascinating because it feels like a small-scale simulation of how the internet works, except we have containers instead of physical devices.

Top comments (0)