Container to container communication in Docker - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

How do Docker containers communicate by default?

When you start two Docker containers without any special network settings, how do they communicate with each other?

A They cannot communicate unless you explicitly connect them to the same user-defined network.

B They communicate automatically using the host's IP address and ports.

C They share the same network namespace and can use localhost to communicate.

D They communicate through a default bridge network with automatic DNS resolution.

💡 Hint

Think about Docker's default network isolation and how containers are separated.

By default, Docker containers are connected to the default bridge network, but they cannot resolve each other by container name or communicate easily unless connected to a user-defined network.

💻 Command Output

intermediate

Output of Docker network inspect command

What is the output type of the command docker network inspect bridge?

Docker

docker network inspect bridge

A A table showing container IDs and their IP addresses.

B A plain text list of container names connected to the bridge network.

C An error message saying the bridge network does not exist.

D A JSON array describing the bridge network including connected containers and settings.

💡 Hint

Docker inspect commands usually return detailed information in a structured format.

The docker network inspect command returns detailed JSON data about the network, including containers connected and network settings.

❓ Configuration

advanced

Correct Docker Compose network configuration for container communication

Which Docker Compose snippet correctly enables two services to communicate by service name?

Docker

version: '3.8'
services:
  app:
    image: myapp
  db:
    image: mydb

A Add a user-defined network and connect both services to it explicitly.

B Use the default bridge network without any changes.

C Expose ports on both services without defining a network.

D Use host networking mode for both services.

💡 Hint

Think about how Docker Compose handles networks and service name resolution.

Docker Compose creates a default network for all services in the same file, but explicitly defining a user network ensures clear communication and control.

❓ Troubleshoot

advanced

Why can't containers communicate despite being on the same user-defined network?

You created a user-defined network and connected two containers to it, but they still cannot ping each other by container name. What is the most likely cause?

A The containers do not have the correct DNS settings to resolve container names.

B The containers are running on different Docker hosts without overlay network setup.

C Containers are using different network drivers incompatible with each other.

D The containers have firewall rules blocking ICMP packets.

💡 Hint

Consider if the containers are on the same physical or virtual machine.

Containers on different Docker hosts need an overlay network to communicate by name; user-defined bridge networks work only on the same host.

🔀 Workflow

expert

Order the steps to enable container-to-container communication using Docker networks

Arrange the steps in the correct order to allow two containers to communicate by name using Docker networks.

A 2,1,3,4

B 1,3,2,4

C 1,2,3,4

D 2,3,1,4

💡 Hint

Think about creating the network before running containers and then using names.

You must first create the network, then run containers attached to it, and finally use their names to communicate.

Practice

1. What is the simplest way for two Docker containers to communicate on the same host?

easy

A. Use a shared volume for communication

B. Use the host's IP address directly inside containers

C. Run containers with --network=none and use port mapping

D. Connect both containers to the same user-defined Docker network

Solution

1. Step 1: Understand Docker networking basics

   Docker containers on the same user-defined network can resolve each other by container name and communicate directly.

2. Step 2: Compare other options

   Using host IP or port mapping is less direct and --network=none disables networking. Shared volumes are for file sharing, not network communication.

3. Final Answer:

   Connect both containers to the same user-defined Docker network -> Option D

4. Quick Check:

   Same network enables container communication [OK]

Hint: Use a user-defined network for easy container communication [OK]

Common Mistakes:

• Using default bridge network without user-defined network
• Trying to communicate via host IP without port mapping
• Assuming shared volumes enable network communication

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 add 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: Check other options for syntax errors

   Options B, C, and D use incorrect verbs or commands not recognized by Docker.

3. Final Answer:

   docker network create mynetwork -> Option A

4. Quick Check:

   Correct command syntax = docker network create [OK]

Hint: Remember: 'docker network create' is the correct syntax [OK]

Common Mistakes:

• Using 'docker create network' instead of 'docker network create'
• Using 'docker network new' which is invalid
• Trying 'docker network add' which does not exist

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

medium

A. ping: unknown host db

B. PING db (172.18.0.2): 56 data bytes\n64 bytes from 172.18.0.2: icmp_seq=0 ttl=64 time=0.123 ms\n\n--- db ping statistics ---\n1 packets transmitted, 1 packets received, 0% packet loss

C. connect: Network is unreachable

D. Request timed out

Solution

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

   Containers on the same user-defined network can resolve each other by container name, so 'db' resolves to its IP.

2. Step 2: Predict ping command output

   Since 'db' is running and reachable, ping will succeed with a response showing bytes received and 0% packet loss.

3. Final Answer:

   Successful ping output with 1 packet transmitted and received -> Option B

4. Quick Check:

   Same network + running container = ping success [OK]

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

Common Mistakes:

• Assuming default bridge network supports container name resolution
• Expecting ping to fail without port mapping
• Confusing network unreachable with DNS resolution failure

4. You created two containers on a user-defined network but web cannot reach db. Which command helps you debug the network connectivity issue?

medium

A. docker ps -a

B. docker container logs web

C. docker network inspect mynetwork

D. docker volume ls

Solution

1. Step 1: Identify the tool to check network details

   docker network inspect shows connected containers and network settings, useful for debugging connectivity.

2. Step 2: Evaluate other commands

   docker container logsdocker ps -a lists containers; docker volume ls lists volumes, none show network details.

3. Final Answer:

   docker network inspect mynetwork -> Option C

4. Quick Check:

   Inspect network to debug connectivity [OK]

Hint: Use 'docker network inspect' to check container connections [OK]

Common Mistakes:

• Checking container logs instead of network info
• Listing volumes which are unrelated
• Assuming 'docker ps' shows network details

5. You want two containers, app and cache, to communicate securely without exposing ports to the host. Which approach achieves this?

hard

A. Connect both containers to the same user-defined network and communicate via container names

B. Expose ports on both containers and use localhost to connect

C. Use host networking mode for both containers

D. Share a volume and write/read data files for communication

Solution

1. Step 1: Understand secure container communication

   Using a user-defined network allows containers to communicate internally without exposing ports to the host, keeping communication private.

2. Step 2: Evaluate other options for security

   Exposing ports or using host networking exposes services outside the host or risks port conflicts. Sharing volumes is not network communication.

3. Final Answer:

   Connect both containers to the same user-defined network and communicate via container names -> Option A

4. Quick Check:

   User-defined network keeps communication internal and secure [OK]

Hint: Use user-defined network to avoid exposing ports externally [OK]

Common Mistakes:

• Exposing ports unnecessarily to the host
• Using host network mode which is less secure
• Confusing volume sharing with network communication