Why custom networks matter in Docker - See It in Action

Why Custom Networks Matter in Docker

📖 Scenario: You are setting up a small Docker environment where two containers need to communicate securely and efficiently. Using Docker's default network can sometimes cause issues with container isolation and name resolution. To solve this, you will create a custom Docker network and connect containers to it.

🎯 Goal: Build a Docker setup where two containers run on a custom network, allowing them to communicate by container name. This will show why custom networks matter for container communication and isolation.

📋 What You'll Learn

Create a custom Docker bridge network named my_custom_net

Run two containers named webapp and database connected to my_custom_net

Verify that webapp can ping database by container name

Show the network details to confirm the custom network is used

💡 Why This Matters

🌍 Real World

Custom Docker networks are used in real projects to isolate services, improve security, and enable containers to find each other by name without exposing ports externally.

💼 Career

Understanding Docker networking is essential for DevOps roles to manage containerized applications efficiently and securely.

1

Create a custom Docker network

Create a Docker bridge network called my_custom_net using the command docker network create my_custom_net.

Docker

# Create the custom network
# Your code here

Hint

Use the docker network create command with the network name my_custom_net.

2

Run two containers on the custom network

Run two containers named webapp and database using the alpine image. Connect both containers to the my_custom_net network using the --network my_custom_net option. Use the command docker run -dit --name webapp --network my_custom_net alpine sh for webapp and similarly for database.

Docker

docker network create my_custom_net
# Run the webapp container connected to my_custom_net
# Your code here

Hint

Use docker run with --name and --network my_custom_net to start each container.

3

Test container communication by name

Use docker exec to run the ping -c 1 database command inside the webapp container to verify it can reach the database container by name.

Docker

docker network create my_custom_net
docker run -dit --name webapp --network my_custom_net alpine sh
docker run -dit --name database --network my_custom_net alpine sh
# Test ping from webapp to database
# Your code here

Hint

Use docker exec to run ping inside the webapp container targeting database.

4

Show the custom network details

Use the command docker network inspect my_custom_net to display details of the custom network and confirm both containers are connected.

Docker

docker network create my_custom_net
docker run -dit --name webapp --network my_custom_net alpine sh
docker run -dit --name database --network my_custom_net alpine sh
docker exec webapp ping -c 1 database
# Inspect the custom network
# Your code here

Hint

Use docker network inspect with the network name my_custom_net.

Practice

1. Why is it important to create a custom Docker network instead of using the default network?

easy

A. It allows containers to communicate securely and isolate traffic.

B. It automatically increases container CPU usage.

C. It disables container communication completely.

D. It removes the need for container images.

Solution

1. Step 1: Understand default network limitations

   The default Docker network allows basic communication but lacks isolation and security controls.

2. Step 2: Benefits of custom networks

   Custom networks let you isolate containers and control which containers can talk to each other securely.

3. Final Answer:

   It allows containers to communicate securely and isolate traffic. -> Option A

4. Quick Check:

   Custom networks improve security and isolation = B [OK]

Hint: Custom networks isolate and secure container communication [OK]

Common Mistakes:

• Thinking default network is always secure
• Believing custom networks increase CPU usage
• Assuming custom networks disable communication

2. Which command correctly creates a new custom Docker network named my-net?

easy

A. docker network create my-net

B. docker create network my-net

C. docker network new my-net

D. docker net create my-net

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 each option

   Only docker network create my-net matches the correct syntax exactly.

3. Final Answer:

   docker network create my-net -> Option A

4. Quick Check:

   Correct command syntax = D [OK]

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

Common Mistakes:

• Swapping 'create' and 'network' order
• Using 'new' instead of 'create'
• Shortening 'network' to 'net' incorrectly

3. Given this Docker command sequence:

docker network create app-net
docker run -d --name web --network app-net nginx
docker run -d --name db --network app-net mysql

What will happen if the web container tries to connect to db using the container name?

medium

A. The connection will fail because containers need IP addresses.

B. The connection will succeed because both containers share the custom network.

C. The connection will fail because default network is required.

D. The connection will succeed only if ports are exposed.

Solution

1. Step 1: Understand container networking on custom networks

   Containers on the same custom network can reach each other by container name as DNS resolves names automatically.

2. Step 2: Analyze the command setup

   Both web and db are on app-net, so web can connect to db using its name.

3. Final Answer:

   The connection will succeed because both containers share the custom network. -> Option B

4. Quick Check:

   Same custom network enables name-based communication = A [OK]

Hint: Containers on same custom network communicate by name [OK]

Common Mistakes:

• Thinking IP addresses are always needed
• Assuming default network is required for name resolution
• Believing ports must be exposed for internal communication

4. You created a custom network with docker network create my-net and started two containers attached to it. But they cannot communicate by container name. What is the most likely cause?

medium

A. Docker daemon is not running.

B. The network was created with the wrong driver.

C. Containers need to be restarted twice.

D. Containers were started without specifying the network.

Solution

1. Step 1: Check container network attachment

   Containers must be started with --network my-net to join the custom network.

2. Step 2: Identify common mistake

   If containers are not attached to the custom network, they cannot resolve each other's names.

3. Final Answer:

   Containers were started without specifying the network. -> Option D

4. Quick Check:

   Containers must join network explicitly = C [OK]

Hint: Always use --network to attach containers to custom networks [OK]

Common Mistakes:

• Assuming network auto-attachment
• Blaming network driver without checking container config
• Restarting containers unnecessarily

5. You want to run three containers: frontend, backend, and database. You want frontend to communicate only with backend, and backend to communicate with database, but frontend should NOT talk directly to database. How can you achieve this using Docker custom networks?

hard

A. Run all containers on one custom network and rely on container names to restrict access.

B. Attach all containers to the default network and use firewall rules inside containers.

C. Create two custom networks: one for frontend-backend, another for backend-database, and attach containers accordingly.

D. Use host networking mode for all containers.

Solution

1. Step 1: Understand network isolation

   Docker networks isolate containers; containers on different networks cannot communicate unless attached to both.

2. Step 2: Design network setup

   Create two networks: one connecting frontend and backend, another connecting backend and database. Attach frontend and backend to first network, backend and database to second.

3. Step 3: Resulting communication

   Frontend can reach backend, backend can reach database, but frontend cannot reach database directly.

4. Final Answer:

   Create two custom networks: one for frontend-backend, another for backend-database, and attach containers accordingly. -> Option C

5. Quick Check:

   Separate networks control container communication = A [OK]

Hint: Use multiple custom networks to control container access [OK]

Common Mistakes:

• Using one network expecting access control by names
• Relying on default network for isolation
• Using host networking which disables isolation