Bridge Networks & DNS

Introduction

User-defined bridge networks are the bread and butter of multi-container apps. Containers attached to the same bridge can resolve each other by name via Docker's built-in DNS.

Purpose of this lesson

This lesson teaches Bridge Networks & DNS as an engineering decision: what problem it solves, when to use it, how to implement it safely, and what signals tell you it is failing.

Understanding the topic

Use this when containers must communicate, expose traffic, or persist state. Most real Docker incidents come from a wrong port, missing DNS name, unsafe bind mount, or data stored in the container writable layer.

Core concepts to understand:

• docker network create app-net
• docker run --network app-net --name db postgres
• docker run --network app-net --name api myapi
• Inside api: psql -h db -U postgres just works.

Visual explanation

Architecture or command flow to keep in mind:

docker network create app
docker network ls
docker network inspect app
docker run -d --network app --name redis redis:7
docker run -d --network app --name api myapi   # api can reach redis:6379

Step-by-step explanation

1. Run the command or manifest exactly once on a clean Docker host and read the output carefully.
2. Inspect the object Docker created: image, container, network, volume, port mapping, process, or registry tag.
3. Break one realistic assumption such as a missing port, bad tag, stopped daemon, wrong network, or deleted volume.
4. Use docker ps, logs, inspect, stats, and system df to locate the failure.
5. Write the final command or configuration into a repeatable script, Compose file, or CI job.

Informative example

Use the example below as a working baseline, then verify the runtime behavior instead of assuming the command or file is correct.

docker network create app
docker network ls
docker network inspect app
docker run -d --network app --name redis redis:7
docker run -d --network app --name api myapi   # api can reach redis:6379

A production-minded check usually includes docker ps, docker logs, docker inspect, and one validation from outside the container such as curl, a database connection, or a registry pull.

# Verification loop for Bridge Networks & DNS
docker ps -a
docker logs --tail=100 <container-name>
docker inspect <container-or-image-name>
docker system df

Real-world use

This is exactly what Compose generates for you — every docker compose up creates a project network and attaches all services to it.

Enterprise use cases

In a mature engineering organization, Bridge Networks & DNS is documented as a repeatable pattern with approved base images, ownership labels, CI checks, security expectations, rollback notes, and troubleshooting commands. The difference between a tutorial and production practice is that every container decision must be observable, reviewable, and reversible.

Best practices

• One network per logical app / stack.
• Remove unused networks with docker network prune.

Common mistakes

• Default bridge (the unnamed one) does NOT do automatic DNS — always create user-defined networks.

Debugging tips

• Start with docker ps and docker port to confirm whether the container is running and the expected host port is published.
• Inspect the network with docker network inspect and test DNS from another container on the same user-defined network.
• Remember that EXPOSE documents intent; -p or Compose ports publishes traffic to the host.

Optimization strategies

• Prefer explicit names, labels, tags, and networks so cleanup and debugging stay predictable.
• Pin versions for repeatability, then update intentionally through a scheduled base-image refresh.
• Use docker system df and targeted prune commands to control local and CI disk growth.

Advanced interview questions

Hands-on exercise

Create a small lab for Bridge Networks & DNS: run the example, inspect the created Docker object, intentionally introduce one mistake, and record the command that reveals the failure. The goal is not just to make the happy path work; it is to build operational reflexes.

# Hands-on lab scaffold
mkdir -p docker-bridge-networks-dns-lab
cd docker-bridge-networks-dns-lab

# Add the Dockerfile, compose.yml, or command from this lesson.
# Then run one happy-path test and one broken-path test.
docker version
docker info
docker system df

Summary

Bridge Networks & DNS matters because Docker is not only a packaging tool; it is a runtime, build, networking, storage, and delivery workflow. Treat each lesson as a production habit: make it repeatable, inspectable, secure, and easy to debug.