Docker Networks
Bridge Networks
The Docker bridge driver automatically installs rules in the host machine so that containers on different bridge networks cannot communicate directly with each other.
Bridge networks apply to containers running on the same Docker daemon host. For communication among containers running on different Docker daemon hosts, you can either manage routing at the OS level, or you can use an overlay network.
The default bridge network is considered a legacy detail of Docker and is not recommended for production use. Configuring it is a manual operation, and it has technical shortcomings.
User-defined bridge networks are best when you need multiple containers to communicate on the same Docker host.
Overlay Networks
Overlay networks are best when you need containers running on different Docker hosts to communicate, or when multiple applications work together using swarm services.
When you initialize a swarm or join a Docker host to an existing swarm, two new networks are created on that Docker host:
An overlay network called ingress, which handles control and data traffic related to swarm services. When you create a swarm service and do not connect it to a user-defined overlay network, it connects to the ingress network by default.
A bridge network called docker_gwbridge, which connects the individual Docker daemon to the other daemons participating in the swarm.
Containers can be connected to more than one network at a time. Containers can only communicate across networks they are each connected to.
The ingress network is created without the --attachable flag, which means that only swarm services can use it, and not standalone containers. You can connect standalone containers to user-defined overlay networks which are created with the --attachable flag. This gives standalone containers running on different Docker daemons the ability to communicate without the need to set up routing on the individual Docker daemon hosts.
Container discovery
For most situations, you should connect to the service name, which is load-balanced and handled by all containers (“tasks”) backing the service. To get a list of all tasks backing the service, do a DNS lookup for tasks.<service-name>.
Overlay networks are best when you need containers running on different Docker hosts to communicate, or when multiple applications work together using swarm services.
When you initialize a swarm or join a Docker host to an existing swarm, two new networks are created on that Docker host:
An overlay network called ingress, which handles control and data traffic related to swarm services. When you create a swarm service and do not connect it to a user-defined overlay network, it connects to the ingress network by default.
A bridge network called docker_gwbridge, which connects the individual Docker daemon to the other daemons participating in the swarm.
Containers can be connected to more than one network at a time. Containers can only communicate across networks they are each connected to.
The ingress network is created without the --attachable flag, which means that only swarm services can use it, and not standalone containers. You can connect standalone containers to user-defined overlay networks which are created with the --attachable flag. This gives standalone containers running on different Docker daemons the ability to communicate without the need to set up routing on the individual Docker daemon hosts.
Container discovery
For most situations, you should connect to the service name, which is load-balanced and handled by all containers (“tasks”) backing the service. To get a list of all tasks backing the service, do a DNS lookup for tasks.<service-name>.
Host Networks
Host networks are best when the network stack should not be isolated from the Docker host, but you want other aspects of the container to be isolated.
If you use the host network mode for a container, that container’s network stack is not isolated from the Docker host (the container shares the host’s networking namespace), and the container does not get its own IP-address allocated. For instance, if you run a container which binds to port 80 and you use host networking, the container’s application is available on port 80 on the host’s IP address.
Note: Given that the container does not have its own IP-address when using host mode networking, port-mapping does not take effect, and the -p, --publish, -P, and --publish-all option are ignored, producing a warning instead:
WARNING: Published ports are discarded when using host network mode
Host mode networking can be useful to optimize performance, as it does not require network address translation (NAT).
The host networking driver only works on Linux hosts, and is not supported on Docker Desktop for Mac, Docker Desktop for Windows, or Docker EE for Windows Server.
Host networks are best when the network stack should not be isolated from the Docker host, but you want other aspects of the container to be isolated.
If you use the host network mode for a container, that container’s network stack is not isolated from the Docker host (the container shares the host’s networking namespace), and the container does not get its own IP-address allocated. For instance, if you run a container which binds to port 80 and you use host networking, the container’s application is available on port 80 on the host’s IP address.
Note: Given that the container does not have its own IP-address when using host mode networking, port-mapping does not take effect, and the -p, --publish, -P, and --publish-all option are ignored, producing a warning instead:
WARNING: Published ports are discarded when using host network mode
Host mode networking can be useful to optimize performance, as it does not require network address translation (NAT).
The host networking driver only works on Linux hosts, and is not supported on Docker Desktop for Mac, Docker Desktop for Windows, or Docker EE for Windows Server.