Container to container communication in Docker - Step-by-Step Execution

Process Flow - Container to container communication

Start Containers

↓

Containers on same network?

No→Create Network

Yes↓

Container A sends request

↓

Network routes request

↓

Container B receives request

↓

Container B sends response

↓

Container A receives response

↓

Communication successful

Containers must be on the same Docker network to communicate. One container sends a request, the network routes it to the other container, which responds back.

Execution Sample

Docker

docker network create mynet

docker run -d --name containerA --network mynet alpine sleep 1000

docker run -d --name containerB --network mynet alpine sleep 1000

docker exec containerA ping -c 2 containerB

Create a network, start two containers on it, then ping from containerA to containerB to test communication.

Process Table

Step	Action	Command/Condition	Result/Output
1	Create network	docker network create mynet	Network 'mynet' created
2	Start containerA on mynet	docker run -d --name containerA --network mynet alpine sleep 1000	containerA running
3	Start containerB on mynet	docker run -d --name containerB --network mynet alpine sleep 1000	containerB running
4	Ping containerB from containerA	docker exec containerA ping -c 2 containerB	2 packets transmitted, 2 received, 0% packet loss
5	Communication success	Ping replies received	Container to container communication works

💡 Ping test completes successfully, confirming communication between containers on the same network

Status Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4	Final
Network 'mynet'	None	Created	Created	Created	Created	Created
containerA status	Not running	Not running	Running	Running	Running	Running
containerB status	Not running	Not running	Not running	Running	Running	Running
Ping result	No ping	No ping	No ping	No ping	2 packets received	Success

Key Moments - 3 Insights

Why do containers need to be on the same network to communicate?

Containers communicate over Docker networks. If they are on different networks, Docker isolates them, so the ping in step 4 would fail. See execution_table step 4 where ping succeeds only because both containers share 'mynet'.

What happens if you try to ping a container by name but it is not on the same network?

The ping command will fail because Docker's internal DNS cannot resolve container names across different networks. This is why in step 4, ping works only when both containers are on 'mynet'.

Why do we use 'docker exec' to run ping inside containerA?

'docker exec' runs commands inside a running container. Here, it lets us test communication from containerA's perspective by running ping inside it, as shown in step 4.

Visual Quiz - 3 Questions

Look at the execution table, what is the status of containerB after step 3?

A Paused

B Not running

C Running

D Exited

💡 Hint

Check the 'containerB status' row in variable_tracker after step 3

At which step does the network 'mynet' get created?

A Step 2

B Step 1

C Step 3

D Step 4

💡 Hint

Look at the 'Action' and 'Command' columns in execution_table for network creation

If containerA was not connected to 'mynet', what would happen at step 4?

A Ping would fail because containerB is unreachable

B Ping would succeed with 0% packet loss

C Ping would succeed but with packet loss

D Ping would not run because containerA is stopped

💡 Hint

Refer to key_moments about network isolation and ping failure

Concept Snapshot

Docker containers communicate over networks.
Containers must be on the same Docker network to reach each other by name.
Use 'docker network create' to make a network.
Start containers with '--network <name>' to connect them.
Use 'docker exec <container> ping <other_container>' to test communication.
If containers are on different networks, communication fails.

Full Transcript

To enable communication between Docker containers, they must be connected to the same Docker network. First, create a network using 'docker network create'. Then start containers with the '--network' option to attach them to this network. Inside one container, you can run commands like ping to the other container by its name. This works because Docker provides internal DNS resolution within the same network. If containers are on different networks, they cannot see each other and communication fails. Using 'docker exec' lets you run commands inside a running container to test connectivity. This step-by-step process ensures containers can talk to each other securely and easily.

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