DNS resolution between containers in Docker - Mini Project: Build & Apply

DNS resolution between containers

📖 Scenario: You are setting up two Docker containers that need to talk to each other by name. This is common when you have multiple services working together, like a web app and a database.Docker allows containers to find each other by their container names if they are on the same network. You will create two containers, connect them to a user-defined network, and test that one container can reach the other by its name.

🎯 Goal: Build two Docker containers connected on the same network and verify that one container can resolve the other's name using DNS.

📋 What You'll Learn

Create a user-defined Docker network called my_network

Run two containers named container1 and container2 connected to my_network

Use the alpine image for both containers

Test DNS resolution inside container1 to reach container2 by name

💡 Why This Matters

🌍 Real World

In real projects, services like databases and web servers run in separate containers. They need to find each other by name to work together.

💼 Career

Understanding container networking and DNS resolution is essential for DevOps roles managing microservices and containerized applications.

1

Create a user-defined Docker network

Create a Docker network called my_network using the docker network create command.

Docker

# Create the Docker network my_network
# Your code here

Hint

Use the command docker network create my_network to create the network.

2

Run two containers connected to the network

Run two containers named container1 and container2 using the alpine image. Connect both containers to the my_network network. Use the --rm flag to remove containers after exit and run them in detached mode with -d. Use sleep 300 as the command to keep containers running.

Docker

docker network create my_network
# Run container1 connected to my_network
# Your code here

Hint

Use docker run -d --rm --name container1 --network my_network alpine sleep 300 and similarly for container2.

3

Test DNS resolution from container1 to container2

Use docker exec to run the ping -c 1 container2 command inside container1 to test if container2 can be resolved by name.

Docker

docker network create my_network
docker run -d --rm --name container1 --network my_network alpine sleep 300
docker run -d --rm --name container2 --network my_network alpine sleep 300
# Run ping command inside container1 to ping container2
# Your code here

Hint

Use docker exec container1 ping -c 1 container2 to test DNS resolution.

4

Verify the ping output shows successful DNS resolution

Run the full command to ping container2 from container1 and verify the output contains 1 packets transmitted, 1 packets received indicating successful DNS resolution.

Docker

docker network create my_network
docker run -d --rm --name container1 --network my_network alpine sleep 300
docker run -d --rm --name container2 --network my_network alpine sleep 300
docker exec container1 ping -c 1 container2
# Observe the output above for successful ping
# Your code here

Hint

Look for the line 1 packets transmitted, 1 packets received in the ping output.

Practice

1. What allows Docker containers on the same user-defined network to communicate using container names instead of IP addresses?

easy

A. Using container IP addresses only

B. Manual editing of /etc/hosts file

C. Docker's built-in DNS service

D. Exposing ports to the host machine

Solution

1. Step 1: Understand Docker networking basics

   Docker provides a built-in DNS service for containers on the same user-defined network.

2. Step 2: Recognize how containers resolve names

   Containers use this DNS service to resolve other container names to their IP addresses automatically.

3. Final Answer:

   Docker's built-in DNS service -> Option C

4. Quick Check:

   Docker DNS = container name resolution [OK]

Hint: User-defined networks enable DNS by default [OK]

Common Mistakes:

• Assuming default bridge network supports DNS resolution by name
• Thinking manual /etc/hosts editing is needed
• Using IP addresses instead of container names

2. Which Docker command correctly creates a user-defined network named mynetwork?

easy

A. docker network create mynetwork

B. docker create network mynetwork

C. docker network new mynetwork

D. docker network build mynetwork

Solution

1. Step 1: Recall Docker network creation syntax

   The correct command to create a network is docker network create <name>.

2. Step 2: Match the command with options

   docker network create mynetwork matches the correct syntax exactly.

3. Final Answer:

   docker network create mynetwork -> Option A

4. Quick Check:

   docker network create = create network [OK]

Hint: Use 'docker network create' to make new networks [OK]

Common Mistakes:

• Using 'docker create network' which is invalid syntax
• Confusing 'new' or 'build' with 'create'
• Omitting the network name

3. Given two containers web and db on the same user-defined network, what will be the output of docker exec web ping -c 1 db if db is running?

medium

A. ping: unknown host db

B. PING db (172.18.0.2): 56 data bytes
64 bytes from 172.18.0.2: icmp_seq=0 ttl=64 time=0.123 ms

--- db ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss

C. Error: container 'db' not found

D. Request timed out

Solution

1. Step 1: Understand DNS resolution on user-defined networks

   Containers on the same user-defined network resolve each other's names automatically.

2. Step 2: Predict ping command output

   Since db is running and reachable, ping will succeed and show reply details.

3. Final Answer:

   Successful ping output with reply from db's IP -> Option B

4. Quick Check:

   Same network + running container = ping success [OK]

Hint: Ping container name works if on same user network [OK]

Common Mistakes:

• Expecting 'unknown host' on user-defined network
• Confusing default bridge network behavior
• Assuming container must expose ports for ping

4. You created two containers on the default bridge network but ping db from web returns "unknown host db". What is the likely cause?

medium

A. The ping command is not installed in the web container

B. The db container is stopped

C. The web container has no network access

D. Containers are not on a user-defined network, so DNS resolution by name fails

Solution

1. Step 1: Recall default bridge network limitations

   Default bridge network does not support automatic DNS resolution by container name.

2. Step 2: Analyze the error message

   "unknown host db" means DNS lookup failed, likely because containers are not on a user-defined network.

3. Final Answer:

   Containers are not on a user-defined network, so DNS resolution by name fails -> Option D

4. Quick Check:

   Default bridge lacks DNS by name [OK]

Hint: Use user-defined networks for container name DNS [OK]

Common Mistakes:

• Assuming default bridge network supports DNS names
• Ignoring network configuration
• Blaming container stopped state without checking

5. You want two containers, app and cache, to communicate by name. You create a user-defined network mynet. Which sequence of commands correctly sets this up?

hard

A. docker network create mynet
docker run -d --name app --network mynet myappimage
docker run -d --name cache --network mynet mycacheimage

B. docker run -d --name app myappimage
docker run -d --name cache mycacheimage
docker network create mynet

C. docker network create mynet
docker run -d --name app myappimage
docker network connect mynet cache

D. docker run -d --name app --network bridge myappimage
docker run -d --name cache --network bridge mycacheimage

Solution

1. Step 1: Create a user-defined network

   Use docker network create mynet to create the network.

2. Step 2: Run containers attached to the network

   Start both containers with --network mynet to enable DNS resolution by name.

3. Final Answer:

   Create network first, then run containers with --network mynet -> Option A

4. Quick Check:

   User-defined network + containers attached = DNS by name [OK]

Hint: Create network first, then run containers on it [OK]

Common Mistakes:

• Running containers before creating network
• Using default bridge network instead of user-defined
• Not attaching containers to the same network