Why custom networks matter in Docker - Why It Works

Introduction

When you run multiple containers, they need to talk to each other safely and without confusion. Custom networks let you control how containers connect and share data, avoiding conflicts and improving security.

When you want to isolate your app's containers from other containers on the same host.

When you need containers to communicate using easy-to-remember names instead of IP addresses.

When you want to control which containers can talk to each other to improve security.

When you run multiple projects on the same Docker host and want to keep their networks separate.

When you want to connect containers across multiple Docker hosts using overlay networks.

Commands

This command creates a new custom network named 'my-custom-network' so containers can join it and communicate securely.

Terminal

docker network create my-custom-network

Expected Output

a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6q7r8s9t0u1v2w3x4y5z6

Runs a container named 'app1' using the nginx image and connects it to the custom network for isolated communication.

Terminal

docker run -d --name app1 --network my-custom-network nginx

Expected Output

d1e2f3g4h5i6j7k8l9m0n1o2p3q4r5s6t7u8v9w0x1y2z3a4b5c6

→

--network - Connects the container to the specified custom network.

→

-d - Runs the container in detached mode (in the background).

Runs another container named 'app2' on the same custom network so it can communicate with 'app1' by name.

Terminal

docker run -d --name app2 --network my-custom-network nginx

Expected Output

e2f3g4h5i6j7k8l9m0n1o2p3q4r5s6t7u8v9w0x1y2z3a4b5c6d7

→

--network - Connects the container to the specified custom network.

→

-d - Runs the container in detached mode (in the background).

Shows details about the custom network, including which containers are connected and their IP addresses.

Terminal

docker network inspect my-custom-network

Expected Output

[

    {

        "Name": "my-custom-network",

        "Id": "a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6q7r8s9t0u1v2w3x4y5z6",

        "Created": "2024-06-01T12:00:00.000000000Z",

        "Scope": "local",

        "Driver": "bridge",

        "Containers": {

            "d1e2f3g4h5i6j7k8l9m0n1o2p3q4r5s6t7u8v9w0x1y2z3a4b5c6": {

                "Name": "app1",

                "IPv4Address": "172.18.0.2/16"

            },

            "e2f3g4h5i6j7k8l9m0n1o2p3q4r5s6t7u8v9w0x1y2z3a4b5c6d7": {

                "Name": "app2",

                "IPv4Address": "172.18.0.3/16"

            }

        }

    }

]

Runs a temporary container on the custom network to ping 'app1' by its container name, showing name-based communication works.

Terminal

docker run --rm --network my-custom-network busybox ping -c 3 app1

Expected Output

PING app1 (172.18.0.2): 56 data bytes

64 bytes from 172.18.0.2: seq=0 ttl=64 time=0.123 ms

64 bytes from 172.18.0.2: seq=1 ttl=64 time=0.110 ms

64 bytes from 172.18.0.2: seq=2 ttl=64 time=0.105 ms



--- app1 ping statistics ---

3 packets transmitted, 3 packets received, 0% packet loss

round-trip min/avg/max = 0.105/0.112/0.123 ms

→

--rm - Removes the container after it finishes running.

→

--network - Connects the container to the custom network.

Key Concept

If you remember nothing else from this pattern, remember: custom Docker networks let containers talk to each other safely and clearly by controlling who connects where.

Common Mistakes

Not specifying a network when running containers, so they end up on the default network and cannot communicate by name.

Containers on different networks or the default network cannot resolve each other's names, causing communication failures.

Always use the --network flag with your custom network name when running containers that need to talk to each other.

Trying to connect containers from different projects on the same default network, causing IP conflicts or accidental access.

The default network is shared and unmanaged, leading to conflicts and security risks.

Create separate custom networks for different projects to isolate their containers.

Summary

Create a custom Docker network to isolate and control container communication.

Run containers with the --network flag to connect them to the custom network.

Use docker network inspect to verify which containers are connected and their IPs.

Test container communication by pinging container names within the custom network.

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