A common use case for Docker is networked services, and Docker has its own networking model to let containers speak to both each other and the outside world.

Originally, Docker containers had to be networked together by hand, or exposed manually to the outside world. The current networking model lets containers find each other automatically on the same host (or across different hosts), and be exposed to the world at large in a more controlled way.

There are four basic ways that Docker supplies developers with networking for containers. The first two, bridge and overlay networks, cover the most common use cases in production. The other two, host and Macvlan networks, exist to cover less common cases.

Docker networking: Bridge networks

Bridge networks let containers running on the same Docker host communicate with each other. A new instance of Docker comes with an default bridge network named bridge, and by default all newly started containers connect to it.

The bridge network comes with many convenient out-of-the-box defaults, but they might need fine-tuning in production. For example, containers on bridge automatically have all ports exposed to each other, but none to the outside world. That’s useful for when you need to test communication between containers, but not for deploying a live service.