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.