When it comes to Docker, understanding how containers communicate — both with each other and the outside world — is essential to building reliable applications. One of the most important pieces of that puzzle is Docker networking.
In this post, we'll take a hands-on tour through the Docker CLI to learn how to manage networks effectively. Then, we'll dive into two essential network types you’ll encounter often: bridge and host. Let's get started!
Before diving deeper into the types of networks, it's important to know how to manage networks using Docker's CLI tools.
Here's a quick tour of the essential commands:
# Create network
docker network create mynetwork
# List network
docker network ls
# Inspect network
docker inspect mynetwork
# Connecting a container to a network
docker network connect mynetwork <container_id>
# Disconnecting a network
docker network disconnect mynetwork <container_id>
# Remove network
docker network rm mynetwork
Imagine a research building with many labs.
In this type, each container is a separate lab room. Each lab has its own door and address. Scientists can move between labs in the same building (host system), but to reach the outside world (the internet), they must go through the main entrance - this is like port mapping in Docker.
Each room is still separate, so what happens in one rooom stays there without affecting the rest of the building. Similarly, in bridge mode, each container is isolated yet connected within a private virtual network.
By default, Docker uses a bridge network. It creates a virtual network (docker0) on the host and assigns an IP address (e.g 172.17.0.0/16) to each container. Containers on the same bridge can talk to each other directly. However, communicating with the host or the internet requires explicit port mapping.
Here's a simple example:
docker run -p 8080:80 nginx
The container is attached to Docker's default bridge network and port 8080 on the host is mapped to port 80 inside the container.
Open your browser and go to http://localhost:8080 to access the web server.
Now, imagine you're doing experiment in the building's main lobby, with no walls separating you from the rest of the building. Everyone in the building (host system) can interact directly, without separation.
In this mode, the containers use the host network stack. The containers share your machine IP address, and also could directly listen on a port of the host machine.
While this approach can offer better performance and simpler networking, it comes also with risks: This mode is less secure as the container running has direct access to the host network resources 😱
When a container runs on the bridge network, it's isolated from the host. If a container tries to connect to localhost (127.0.01), it talks to itself, not the host machine.
In some cases, you need a container to talk back to the host - for example, when running tests to let your containerized app to access services on your host machine (like the PostgreSQL container).
To solve this, you can add a specia entry to the containers /etc/hosts file:
extra_hosts:
- "DOCKER_HOST:host-gateway"
This maps DOCKER_HOST to the bridge gateway address, allowing the container to route traffic back to the host instead to itself.
An example of this setup in action can be found at: https://github.com/ricky-lim/pycontainer-demo
Choose your docker network mode based on your application's needs for isolation, performance, and host integration.
Bridge network offers private docker network isolation, and reserve host network for scenarios where direct access to the host netwrok is essential.
Use extra_hosts to bridge without to host, this enables controlled access from containers to the host without sacrificing the benefits of bridge isolation.