Why custom networks matter in Docker - Challenge Your Understanding

Challenge - 5 Problems

🧠 Conceptual

intermediate

Why use custom Docker networks?

Which of the following is the main reason to create a custom Docker network instead of using the default bridge network?

A To isolate containers and control communication between them

B To increase container CPU usage automatically

C To enable containers to run without Docker installed

D To reduce the size of Docker images

💡 Hint

Think about how containers talk to each other and how you can control that.

Custom networks allow you to isolate containers and control which containers can communicate, improving security and organization.

💻 Command Output

intermediate

Output of listing Docker networks

What is the output of the command docker network ls after creating a custom network named my_custom_net?

Docker

docker network create my_custom_net
docker network ls

A

NETWORK ID   NAME           DRIVER    SCOPE
<id>         bridge         bridge    local
<id>         host           host      local
<id>         none           null      local
<id>         my_custom_net  bridge    local

B Error: network my_custom_net not found

C

NETWORK ID   NAME           DRIVER    SCOPE
<id>         bridge         overlay   local
<id>         my_custom_net  host      local

D No networks found

💡 Hint

Custom networks appear alongside default networks with the same driver unless specified otherwise.

When you create a custom network with the default bridge driver, it appears in the list along with default networks like bridge, host, and none.

🔀 Workflow

advanced

Connecting containers to a custom network

You have two containers: app and db. You want them to communicate securely using a custom network named secure_net. Which sequence of commands correctly sets this up?

A

docker network create secure_net
docker network connect secure_net app
docker network connect secure_net db

B

docker network create secure_net
docker run --network=secure_net app
docker run --network=secure_net db

C

docker network create secure_net
docker run app
docker run db

D

docker network create secure_net
docker network disconnect bridge app
docker network disconnect bridge db
docker network connect secure_net app
docker network connect secure_net db

💡 Hint

Think about how to start containers directly attached to a network.

Starting containers with --network=secure_net attaches them to the custom network immediately, enabling secure communication.

❓ Troubleshoot

advanced

Why can't containers communicate on default bridge network?

You started two containers on the default bridge network but they cannot ping each other by container name. What is the most likely reason?

A Docker daemon is not running

B Containers must be on the host network to communicate

C The default bridge network does not support automatic DNS resolution between containers

D Containers need to share the same image to communicate

💡 Hint

Think about how container names resolve to IP addresses on different networks.

The default bridge network does not provide automatic DNS resolution for container names, so containers cannot reach each other by name without custom networks.

✅ Best Practice

expert

Best practice for Docker network security

Which practice best improves security when using Docker networks in a multi-container application?

A Run all containers with host networking to improve performance

B Use the default bridge network for all containers to simplify setup

C Disable Docker networking to prevent all container communication

D Create separate custom networks for different application components and restrict container connections accordingly

💡 Hint

Think about isolating parts of your app to limit access.

Separating containers into custom networks limits communication to only what is necessary, reducing attack surface and improving security.

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