Table of Contents
Overview of Docker Networking
Docker networking gives containers a way to talk to each other, to the host, and to the outside world. Although containers feel isolated, they still rely on very normal networking concepts such as IP addresses, ports, and routing. Docker simply automates and standardizes how these pieces are created and connected.
By default, when you install Docker, it creates a basic network setup on the host. This setup lets containers get IP addresses, reach the internet, and accept incoming connections if you publish ports. Understanding this default behavior will help you avoid confusion when your containers cannot talk to each other or when a service is not reachable from your browser.
Docker networking is pluggable. That means Docker can support different kinds of networks with different behaviors, such as the default bridge network for single hosts, overlay networks for clusters, or none networking for very restricted containers. In this course, you will focus on the kinds of networks that are most useful for everyday development and small deployments, and you will see how each chapter in this section builds on the general ideas introduced here.
Important: Every container has its own network namespace. It has its own network interfaces, its own IP address, and its own view of open ports. Containers never automatically share the host network or each other’s networks unless you explicitly configure them to do so.
Default Networks Created by Docker
Right after installation, Docker creates several networks with special names. You can see them with the docker network ls command. The main ones you will work with are called bridge, host, and none. These networks are created even before you run any containers and exist as basic tools you can choose from.
The bridge network is the default network for containers on a single host. If you run a container and do not specify any network, Docker attaches it to this bridge. On Linux, this is implemented with a virtual Ethernet bridge device that connects containers together and routes traffic out to the host and beyond. On other platforms, Docker Desktop emulates this behavior so you still get a similar default network.
The host network removes the separation between container and host network stack. When a container joins the host network, it no longer gets its own isolated network namespace. Instead, it sees the same interfaces and ports as the host machine. This can be useful in some special cases, but it removes several isolation benefits.
The none network is the opposite. It gives the container a network namespace but no configured interfaces except for the loopback device. The container cannot talk to anything outside itself until you manually configure networking, which is usually reserved for advanced cases or for running tools that must be completely isolated.
Rule: If you do not specify a network when running a container, Docker attaches it to the default bridge network. Special networks named host and none change how isolated the container is. Bridge means isolated with its own IP, host means no isolation from the host network, and none means almost complete network isolation.
How Containers Get IP Addresses
When a container starts on a user defined network or on the default bridge, Docker acts as a small DHCP-like allocator. It assigns the container an IP address from the network’s IP range. Each network has its own address range, subnet mask, and internal gateway. These are automatically created if you use defaults, or they can be customized when you define networks yourself.
Inside the container, the application usually does not care about the low-level details. It simply binds to a port on 0.0.0.0 or on localhost and listens for connections. Other containers reach it using its container IP or, more commonly in user defined networks, its container name as a DNS hostname. Docker embeds a lightweight DNS server into each network that resolves container names within that network.
By separating each network into its own IP space, Docker makes it possible for different groups of containers to use the same port numbers without conflicts. For example, you can have one service listening on port 80 in one network and another service also listening on port 80 in a different network. These do not clash, because the containers are on different networks and have different IP addresses.
Key idea: IP addresses and ports are always local to a specific network namespace. Two containers can both listen on port 80 without conflict as long as they are not trying to use the same IP on the same network.
Container Network Isolation and Communication
Network isolation means a container cannot automatically see every other container or every port on the host. It can only see what its network connections allow. If two containers are attached to the same network, they can talk to each other over that network. If they are on different networks without routing configured, they cannot reach each other directly.
On the bridge network, containers can usually reach the outside internet if the host has internet access. Docker sets up NAT, which is network address translation, from the container IPs to the host’s IP. From the outside internet's perspective, it is the host that makes the outbound connection, not the containers directly.
For inbound traffic, such as when you want to open a web page running inside a container, Docker does not expose ports by default. You must explicitly publish or map ports. This means that if a container is compromised, random services inside it are not automatically reachable from outside. Only the ports you choose to publish become part of the host’s exposed surface.
This combination of isolation and controlled exposure is what makes containers practical for running many services on the same host. The same machine can run several containers that listen on the same internal ports, while only selected services have their ports mapped outward where users can reach them.
How Port Publishing Fits Into Networking
Port publishing acts as the bridge between the host network and the container network. When you run a container and use options to publish ports, Docker configures the host to listen on specific host ports and forward that traffic to the container’s internal IP and port. From the container side, nothing special is required. The application just listens as usual.
This is important because the container does not normally know which external port it is reachable on, or even if it is reachable from outside at all. The mapping from host:port to container:port is defined in the Docker configuration, not in the container. When a user goes to a browser and uses the host machine’s IP and port, Docker forwards that connection across the internal bridge network into the container.
Port publishing is completely independent from the internal networks that connect containers to each other. You could have a container that is only reachable from other containers and not from the host or internet by simply not publishing its ports. In a typical multi container application, only a small number of containers, such as a reverse proxy or an API gateway, need published ports. Others can stay internal and private on their networks.
Rule: Networks connect containers to each other, while port publishing connects the host to containers. A container can be reachable internally without any published ports, or it can be reachable from outside only through explicit port mappings.
DNS Resolution Between Containers
When several containers share a Docker network, Docker provides a DNS service on that network. Each container gets a hostname, which is usually the container name unless you override it. Other containers on the same network can use that hostname in URLs or configuration files and Docker will resolve it to the correct container IP.
This DNS behavior is especially convenient for multi container setups where services need to find each other dynamically. Unlike manually hard coding IP addresses, which may change when containers are recreated, using container names makes the system more robust. When a container stops and restarts, it can get a new IP, but as long as it keeps the same name in your configuration, other containers still connect using the name and do not need to know about the IP change.
The DNS service is also scoped per network. That means containers on one user defined network cannot automatically resolve the names of containers on another network. This supports the idea of network level isolation. Only containers that share a network get to resolve each other's names and talk directly.
Network Drivers and Extensibility
Under the hood, Docker uses network drivers to implement different kinds of behavior. The bridge driver provides the familiar single host network environment that looks like a small local network inside one machine. The host and none drivers manage the special host and none networks. Additional drivers, such as overlay, allow networking across multiple Docker hosts, which is more advanced and is used with clustering tools.
For most everyday development tasks, you focus on bridge based networks. These provide a balance of isolation and simplicity. You can define your own bridge networks with custom names, and attach containers to one or more of these networks according to how you want them to communicate. Other drivers become important when you move to orchestrators or specialized setups, which you will see later in the course when you look beyond simple single host layouts.
The extensibility of drivers means that Docker networking can integrate with many environments. Cloud platforms, third party plugins, and enterprise systems can offer their own drivers that plug into Docker. This makes the basic networking model you learn here still useful when the underlying implementation gets more sophisticated.
Key statement: Although different network drivers change how packets move, the main concepts stay the same. Containers join networks, get IPs, and use ports and DNS names to communicate.
Conceptual Summary for Further Chapters
The chapters that follow in this section will show you practical aspects of this model. Bridge networks will show how the default single host networking works in more detail. Port mapping will focus on how you reach containers from the outside. Container to container communication will rely on shared networks and Docker’s embedded DNS. Custom networks will show how you can design network layouts that separate concerns, such as front end and back end tiers.
All of these rest on the same basic ideas introduced here. Each container has an isolated network view. Networks group containers and let them talk. The host only sees what you expose through published ports or through special network modes. With this mental model, you will be able to reason about most Docker networking behaviors and understand why a container can or cannot talk to something else.