Understanding Docker Network and Container DNS

Docker provides network capabilities that allow containers to communicate with each other, with the host system, and with external networks. Understanding these capabilities is crucial when setting up services that interact with one another, like WordPress, MariaDB, Nginx, etc.

Docker Network

Docker creates a few default networks upon installation. These networks represent different network drivers that Docker supports:

Bridge: The default network driver. If you don’t specify a driver, this is the type of network you are creating. Containers connected to the same bridge network can communicate, and the bridge network itself is isolated from other networks.
Host: Removes any network isolation between the Docker host and the Docker containers. This can be useful in cases where you don’t want to network the overhead of the default bridged configuration.
Overlay: Used for Docker Swarm services. It allows swarm services to communicate with each other.
Macvlan: Assigns a MAC address to containers, making them appear as physical devices on the network. Useful for network architectures that require direct access to external networks, among other use cases.
None: Disables all networking.

Each container has a Private IP Address

We can use the docker inspect command to inspect our container's network settings.

docker inspect container-foo

In the JSON structure we should see these two key value pairs.

"Gateway": "172.18.0.1",
"IPAddress": "172.18.0.5",

IPAddress: This is the IP address assigned to the container within its Docker network. 172.18.0.5 is the container's private IP address. Other containers on the same Docker network can use this IP address to communicate with container-foo.
Gateway: This is the IP address of the default gateway for the container's network. It's the "doorway" that the container uses to send traffic outside of its own Docker network (e.g., to the internet or to other networks on the host machine).

Each container in the network has an IP address with the format 172.18.x.x.

For example, if we inspect another container within our docker network we might see something like this:

docker inspect container-bar

"Gateway": "172.18.0.1",
"IPAddress": "172.18.0.2",

Docker, by default, creates a bridge network named bridge (or sometimes docker0) and assigns a subnet from one of the private IP ranges to it. When you create containers without specifying a custom network, they are attached to this bridge network.

The 172.18.0.0/16 notation defines the subnet. Let's break it down:

172.18.0.0: This is the network address. It represents the start of the address range.
/16: This is the subnet mask in CIDR notation. It means that the first 16 bits of the IP address are used to identify the network, and the remaining 16 bits are used to identify hosts within that network.

What /16 means practically:

It provides 2¹⁶ (65,536) possible IP addresses within this network (172.18.0.0 to 172.18.255.255).
The gateway IP (172.18.0.1) is typically the first usable IP address in the subnet.
Container IPs like 172.18.0.5 are assigned from the available range within this subnet.

These IP addresses (172.16.0.0/12, 192.168.0.0/16, and 10.0.0.0/8) are designated as private IP addresses by RFC 1918. They are not routable on the public internet. This is important for Docker because:

Isolation: Containers have their own isolated network space, preventing direct conflicts with the host machine's network or other external networks.
Security: By default, containers are not directly accessible from the outside world unless you explicitly publish ports.
Flexibility: You can run multiple containers with overlapping IP addresses as long as they are on different Docker networks.

Custom Networks

Docker allows you to create custom networks (using docker network create). When you do this, you can specify the subnet you want to use. This provides more control over the network configuration. For example:

docker network create --subnet 192.168.10.0/24 my-custom-network

This would create a network named my-custom-network with the subnet 192.168.10.0/24 (allowing for 256 IP addresses).

Watch

Container DNS

When containers try to talk to each other, they can use the name of the other container as its domain name. Docker provides a built-in DNS server to containers, allowing containers to use container names as hostnames.

For instance, if you have a WordPress container named wp1 and a MariaDB container named db1, the WordPress application can reach the database using the hostname db1. Docker's internal DNS resolves that name to the appropriate IP address.

Examples:

1. WordPress and MariaDB:

Let’s say you create a Docker network named wp_network:

docker network create wp_network

You then launch a MariaDB container and a WordPress container:

docker run --name db1 --network wp_network -e MYSQL_ROOT_PASSWORD=easyPWD123 -d mariadb
docker run --name wp1 --network wp_network -e WORDPRESS_DB_HOST=db1 -e WORDPRESS_DB_USER=root -e WORDPRESS_DB_PASSWORD=12345678 -d wordpress

Here, WordPress will be able to connect to MariaDB using the hostname db1, because both containers are on the same Docker network, and Docker's internal DNS will resolve db1 to the correct IP within that network.

2. Nginx as a Reverse Proxy for WordPress:

Suppose you want to use Nginx as a reverse proxy in front of WordPress:

docker run --name nginx --network wp_network -v /path/to/nginx/conf:/etc/nginx/conf.d -d nginx

In your Nginx configuration, you can proxy requests to the hostname wp1:

location / {
    proxy_pass http://wp1;
    ...
}

Again, Docker's internal DNS will make sure that http://wp1 correctly points to the WordPress container's IP address.

Conclusion:

Understanding Docker's network capabilities and the internal DNS mechanism is essential when architecting applications using Docker. By leveraging Docker's networking features, you can create scalable, isolated, and maintainable applications with ease.