Container DNS and service discovery in Docker - Practice Problems & Coding Challenges

Challenge - 5 Problems

💻 Command Output

intermediate

Docker container DNS resolution output

You have two Docker containers running on the same user-defined bridge network named mynetwork. Container A tries to ping Container B using its container name. What will be the output of the ping command inside Container A?

Docker

docker network create mynetwork

docker run -dit --name containerB --network mynetwork alpine sh

docker run -dit --name containerA --network mynetwork alpine sh

docker exec containerA ping -c 1 containerB

A

PING containerB (172.18.0.2): 56 data bytes
64 bytes from 172.18.0.2: seq=0 ttl=64 time=0.123 ms

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

B ping: bad address 'containerB'

C connect: Network is unreachable

D ping: unknown host containerB

💡 Hint

Containers on the same user-defined bridge network can resolve each other by container name.

Docker user-defined bridge networks provide built-in DNS resolution. Containers can reach each other by their container names as hostnames.

🧠 Conceptual

intermediate

Service discovery mechanism in Docker Swarm

Which of the following best describes how service discovery works in Docker Swarm mode?

A Docker Swarm requires manual editing of /etc/hosts files on each node for service discovery.

B Docker Swarm uses external DNS servers only and does not provide built-in service discovery.

C Docker Swarm uses an internal DNS server that resolves service names to the IP addresses of active service tasks.

D Docker Swarm uses multicast network broadcasts to discover services automatically.

💡 Hint

Think about how Docker Swarm manages multiple replicas of a service.

Docker Swarm includes an internal DNS server that automatically resolves service names to the IP addresses of the running tasks, enabling easy service discovery.

❓ Troubleshoot

advanced

Troubleshooting container DNS failure on default bridge network

You run two containers on the default Docker bridge network. Container A tries to ping Container B by its container name but fails with ping: unknown host containerB. What is the most likely cause?

A Containers on the default bridge network cannot resolve each other by container name because it lacks embedded DNS support.

B The containers are on different Docker hosts, so DNS resolution fails.

C The container names are case-sensitive and must be uppercase.

D The Docker daemon is not running, causing DNS failures.

💡 Hint

Consider the difference between default and user-defined bridge networks.

The default bridge network does not provide automatic DNS resolution by container name. Only user-defined bridge networks support this feature.

🔀 Workflow

advanced

Configuring service discovery with Docker Compose

Given the following Docker Compose snippet, what hostname should web service use to connect to the db service?

Docker

version: '3.8'
services:
  web:
    image: nginx
    depends_on:
      - db
  db:
    image: mysql
    environment:
      MYSQL_ROOT_PASSWORD: example

A web

B localhost

C mysql

D db

💡 Hint

Services in the same Docker Compose network can reach each other by service name.

Docker Compose creates a default network where services can resolve each other by their service names as hostnames.

✅ Best Practice

expert

Best practice for service discovery in multi-host Docker environments

In a multi-host Docker environment without Swarm, which approach is best to enable reliable service discovery across hosts?

A Use container names as hostnames and expect Docker to resolve them across hosts automatically.

B Use an external service discovery tool like Consul or etcd integrated with Docker containers.

C Rely on Docker's default bridge network DNS for cross-host discovery.

D Manually update /etc/hosts on all hosts with container IPs.

💡 Hint

Think about scalability and automation in multi-host setups.

Docker's default networking does not support cross-host DNS resolution without orchestration. External tools like Consul or etcd provide scalable, automated service discovery.

Practice

1. What does Docker's built-in DNS service provide for containers on the same user-defined network?

easy

A. It assigns static IP addresses to containers.

B. It allows containers to find each other by their container names.

C. It disables network communication between containers.

D. It automatically updates container images.

Solution

1. Step 1: Understand Docker user-defined networks

   User-defined networks enable containers to communicate using DNS names instead of IP addresses.

2. Step 2: Role of Docker DNS service

   Docker's DNS service resolves container names to their current IP addresses on the same network.

3. Final Answer:

   It allows containers to find each other by their container names. -> Option B

4. Quick Check:

   Docker DNS = container name resolution [OK]

Hint: Containers use names, not IPs, to find each other on user networks [OK]

Common Mistakes:

• Thinking Docker assigns static IPs by default
• Believing DNS disables container communication
• Confusing DNS with image updates

2. Which Docker command correctly creates a user-defined network named my-net to enable container DNS service discovery?

easy

A. docker network create my-net

B. docker create network my-net

C. docker network new my-net

D. docker network build my-net

Solution

1. Step 1: Identify correct Docker network creation syntax

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

2. Step 2: Verify options

   The options using 'docker network new', 'docker create network', and 'docker network build' have incorrect syntax; only docker network create my-net matches Docker syntax.

3. Final Answer:

   docker network create my-net -> Option A

4. Quick Check:

   Correct command = docker network create [OK]

Hint: Use 'docker network create' to make user-defined networks [OK]

Common Mistakes:

• Using 'docker create network' instead of 'docker network create'
• Confusing 'new' or 'build' with network creation
• 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 succeeds showing db IP address and response time.

B. Ping fails with 'unknown host db' error.

C. Ping succeeds but shows IP of web container.

D. Ping command is not available inside containers.

Solution

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

   Containers on the same user-defined network can resolve each other's names to IP addresses.

2. Step 2: Effect of ping command

   Running ping from web to db will resolve db to its IP and send ICMP packets successfully if db is running.

3. Final Answer:

   Ping succeeds showing db IP address and response time. -> Option A

4. Quick Check:

   Container DNS + ping = success if target running [OK]

Hint: Ping container name on same network to test DNS and connectivity [OK]

Common Mistakes:

• Assuming ping fails due to IP changes
• Confusing container names with hostnames outside network
• Believing ping is unavailable inside containers

4. You created two containers on a user-defined network, but web cannot resolve db by name. What is the most likely cause?

medium

A. The web container has no network interface.

B. The db container is stopped.

C. Docker daemon is not running.

D. Containers are on different Docker networks.

Solution

1. Step 1: Check network configuration

   Containers must be on the same user-defined network for DNS name resolution to work.

2. Step 2: Analyze failure cause

   If web cannot resolve db, they are likely on different networks, so DNS does not link them.

3. Final Answer:

   Containers are on different Docker networks. -> Option D

4. Quick Check:

   Different networks block DNS resolution [OK]

Hint: Ensure containers share the same user-defined network for DNS [OK]

Common Mistakes:

• Assuming stopped container causes DNS failure (it causes ping failure)
• Thinking Docker daemon status affects container DNS directly
• Believing container can lack network interface if running

5. You want to deploy a multi-container app with a web server and database. You want the web server to always connect to the database by name, even if the database container restarts and gets a new IP. Which Docker setup ensures this?

hard

A. Run containers on separate networks and link them with --link option.

B. Use the default bridge network and hardcode the database container's IP address in the web server config.

C. Create a user-defined network and run both containers attached to it; use the database container's name in the web server config.

D. Assign static IPs manually to both containers on the default network.

Solution

1. Step 1: Understand service discovery with user-defined networks

   User-defined networks provide automatic DNS resolution by container name, even if IPs change.

2. Step 2: Evaluate options for reliable name-based connection

   Create a user-defined network and run both containers attached to it; use the database container's name in the web server config. uses user-defined network and container names, which is the recommended way for service discovery.

3. Step 3: Why other options fail

   Default bridge network lacks automatic DNS; hardcoding IPs breaks if IP changes; --link is deprecated; static IPs are complex and error-prone.

4. Final Answer:

   Create a user-defined network and run both containers attached to it; use the database container's name in the web server config. -> Option C

5. Quick Check:

   User-defined network + container names = reliable service discovery [OK]

Hint: Use user-defined network and container names for stable service discovery [OK]

Common Mistakes:

• Hardcoding IP addresses instead of using container names
• Using default bridge network without DNS support
• Relying on deprecated --link option
• Manually assigning static IPs unnecessarily