Table of Contents
Why Networking Matters for Containers
Docker networking is what allows containers to talk to each other, to your host machine, and to the outside world like the internet. Without networking, containers would be isolated processes that can only do work inside their own filesystem. For any real application such as web servers, databases, or APIs, you need a clear mental model of how Docker connects things together.
At a high level, Docker creates virtual networks on your machine. Containers get virtual network interfaces inside these networks and can send traffic to each other as if they were on a small private LAN. Docker also manages how traffic is forwarded to and from the host and beyond.
In this chapter you will learn the basic ideas that appear again and again when you work with more specific networking topics in later chapters such as bridge networks, port mapping, and custom networks.
Fundamental Networking Concepts in Docker
Inside a container, most networking looks like it does on any Linux system. The container has its own IP address, network interfaces, and a routing table. The difference is that Docker creates and manages these things for you.
Each container receives:
A network namespace. This is an isolated view of the network stack. Processes in the container see their own interfaces and IP addresses and do not see the host interfaces directly.
A virtual network interface. Docker connects this interface to a Docker network. The network decides how the container can reach others and how others can reach it.
An IP address. On user defined bridge networks, each container gets a private IP such as 172.20.0.2. On the default bridge, it will also get an internal IP. Docker tracks these addresses and handles routing.
From inside a container, you can usually run commands like ping, curl, or wget to reach other containers or external hosts, as long as the network mode allows it.
Every container has its own isolated network namespace, which means it has its own IP addresses and interfaces that are separate from the host and from other containers by default.
Default Networks Created by Docker
When you install Docker and start the Docker engine, it automatically creates some built in networks. These are available without any extra configuration and form the foundation of Docker networking on a single host.
By default you will typically see three main networks:
A bridge network with the name bridge. This is the default network for containers when you do not specify anything else. It provides private networking on the host using network address translation so containers can talk out to the internet.
A host network with the name host. Containers on this network share the host network namespace. They do not get their own IP address, but instead use the host network directly.
A null network with the name none. This network disables all external networking for the container. The container will have a loopback interface only, with no connectivity to other containers or the host.
Later chapters will focus on bridge networks and custom networks. For now, recognize that Docker always has at least these three categories of connectivity available.
If you do not specify any network when you run a container, Docker attaches it to the default bridge network.
How Containers Reach the Outside World
Most applications need to reach resources outside the container, such as public APIs, package repositories, or other services on the internet. Docker makes outbound access straightforward.
Containers attached to a bridge style network can initiate connections to external hosts. Docker uses network address translation (NAT) on the host. This means that when a container at a private IP, for example 172.17.0.2, connects to an external server, the host rewrites the source address to its own IP and keeps track of that mapping. Replies from the external server come back to the host and are then forwarded to the correct container.
From the perspective of the outside world, the traffic appears to come from the host machine, not from the container. This is similar to how home routers allow multiple devices on a private LAN to access the internet.
Inbound traffic is different. External clients cannot automatically see containers on a bridge network. To let external clients reach a service inside a container, Docker must either publish ports or use other networking modes. The detailed behavior for exposing services is covered in the port mapping chapter, but at the basics level remember that outbound access is automatic while inbound is controlled.
Container to Container Communication Basics
Within the same Docker network, containers can usually reach each other directly. There are two common ways they do this.
The first way is by IP address. Docker assigns each container an IP on a given network. Containers can then connect to those IPs. However, hard coding IPs is fragile. Recreated containers can get new addresses.
The second way is by container name or network alias. On user defined bridge networks, Docker runs an internal DNS service. When a container looks up another container name, Docker resolves that to the correct IP for the target container on that network. This makes it much easier to connect services, because you can use stable names instead of numeric addresses.
If two containers are on different Docker networks and there are no special configurations, they cannot see each other. Networks are isolated segments by default. This isolation is useful for keeping unrelated services separate and for controlling which containers can interconnect.
Containers can talk to each other by name only if they share a Docker network that provides internal DNS resolution, such as a user defined bridge network.
Network Drivers at a Glance
Docker uses the idea of a network driver to define how networking behaves. Each driver type provides a different model and is suited for specific scenarios.
The bridge driver creates a private, software based Ethernet bridge on the host. Containers get private IPs and communicate through this virtual switch. This is the most common driver on a single host.
The host driver disables network isolation between container and host and uses the host network stack directly. This can reduce some overhead and simplify port use, but it also removes the separation between host and container ports.
The none driver removes external networking, which gives you a fully isolated container that can only talk to itself through the loopback interface.
There are also more advanced drivers, including ones provided by Docker itself and others via plugins. These can support multi host networking for clusters, encryption, or integration with cloud networking. Those are beyond basic Docker networking but rely on the same core ideas presented here.
Inspecting Networks and Understanding Their Information
As you work with Docker, you will often want to understand which networks exist and how containers are attached to them. Docker provides commands to list and inspect networks. Although the mechanics of running these commands are not the focus here, you should be aware of what kind of information they expose.
Each network has:
A name. For example bridge or my_app_network.
An ID. A unique identifier used internally by Docker.
A driver. Such as bridge, host, or none.
A subnet and gateway. These define the IP address range used on that network and the router address inside that range.
A list of connected containers. For each container, Docker records the container ID, the container name, its IPv4 or IPv6 addresses on that network, and any aliases that are resolvable through Docker internal DNS.
Reading this information is crucial when you troubleshoot connectivity issues or design how services should be segmented across different networks.
Basic Security and Isolation Ideas
Although detailed security practices are covered elsewhere, it is helpful to recognize the role that networking plays in isolation from the start.
By placing containers on separate networks, you can prevent direct communication between them unless you explicitly allow it. For example, you might put public facing web containers on one network that is reachable by clients through published ports, and keep internal data processing containers on another network that is never exposed externally.
The none network is the most isolated, since it removes external access entirely. The bridge networks provide isolation between Docker and the outside world, but containers on the same bridge can communicate freely unless additional firewall rules are used.
Treat each Docker network as a separate trust boundary, and only place containers that must communicate on the same network.
How These Basics Connect to Later Topics
The concepts in this chapter appear again in more focused networking topics.
Bridge networks build directly on the bridge driver and the idea of private IP subnets on a single host.
Port mapping uses the idea that external clients cannot directly see container IPs, so the host forwards specific ports into containers.
Container to container communication uses internal DNS and network scoping, so you can connect services by name.
Custom networks are simply user defined bridge networks with explicit subnets, names, and isolation rules.
With the basics of network namespaces, default networks, network drivers, and communication patterns in mind, you are prepared to explore these specific networking features step by step in the following chapters.