In the last post, we talked about why Docker is essential for keeping your work consistent. Today, we are opening up the floorboards to look at the plumbing. In the world of Docker, plumbing is Networking.
When you run a container, it feels like it is on its own island. However, to be useful, it needs to talk to the internet, the host machine, or other containers. Here is how that actually happens.
The Default Bridge (docker0)
By default, Docker creates a virtual bridge on your Linux host called docker0. Think of this as a virtual network switch.
When you start a container, Docker gives it a virtual ethernet pair (called veth). One end of this "cable" stays in the container as eth0, and the other end plugs into the docker0 bridge on your host. This is how the container gets its own IP address, usually something like 172.17.0.2.
Why the Default Bridge is Not Enough
While the default bridge works, it has a major downside: It does not support automatic DNS resolution.
If you have a "web" container and a "database" container on the default bridge, the web container cannot find the database by its name. You would have to use the specific IP address. Since container IPs change every time they restart, this is a nightmare to manage.
The Solution: User-Defined Networks
This is the "pro" way to do things in your home lab. You can create your own networks to get three main benefits:
- Automatic DNS Resolution: Containers can talk to each other using their names (e.g.,
mysqlorapi-server) instead of shifting IP addresses. - Better Isolation: You can keep your database on a private network and only expose your web server to the outside world.
- Dynamic Attachment: You can connect or disconnect containers from networks while they are still running.
Networking Cheat Sheet
Here are the commands you will use most often to manage your plumbing:
- Create a network:
docker network create my-network - List all networks:
docker network ls - Connect a running container:
docker network connect my-network my-container - Disconnect a container:
docker network disconnect my-network my-container - Remove a network:
docker network rm my-network
Wrapping Up
Understanding the plumbing makes debugging much easier. If your app cannot connect to its database, the first thing you should check is if they are on the same network.
In the next post, we are going to talk about The Memory. We will look at Volumes and Storage to make sure your data does not disappear when a container stops.
Happy Dockerizing!