Why custom networks matter in Docker - Visual Breakdown

Process Flow - Why custom networks matter

Start Docker Containers

↓

Default Bridge Network

↓

Containers Can Communicate

↓

Limitations: No Isolation, No Custom Rules

↓

Create Custom Network

↓

Containers Connect to Custom Network

↓

Benefits: Isolation, Custom Rules, Easier Service Discovery

↓

Improved Security and Management

↓

End

Shows how Docker containers start on default networks, their limitations, and how creating custom networks improves isolation, security, and communication.

Execution Sample

Docker

docker network create my_custom_net

docker run -d --name container1 --network my_custom_net nginx

docker run -d --name container2 --network my_custom_net nginx

docker network inspect my_custom_net

Creates a custom Docker network, runs two containers attached to it, and inspects the network to see container connections.

Process Table

Step	Command	Action	Result/Output
1	docker network create my_custom_net	Create a new custom network named 'my_custom_net'	Network 'my_custom_net' created
2	docker run -d --name container1 --network my_custom_net nginx	Start container1 attached to 'my_custom_net'	Container1 running with network 'my_custom_net'
3	docker run -d --name container2 --network my_custom_net nginx	Start container2 attached to 'my_custom_net'	Container2 running with network 'my_custom_net'
4	docker network inspect my_custom_net	Show details of 'my_custom_net' including connected containers	{"Name":"my_custom_net","Containers":{"container1":{"Name":"container1"},"container2":{"Name":"container2"}}}
5	docker network inspect bridge	Show default bridge network containers	{"Name":"bridge","Containers":{}}
6	docker run -d --name container3 nginx	Start container3 on default bridge network	Container3 running with default bridge network
7	docker network inspect bridge	Show containers connected to default bridge network	{"Name":"bridge","Containers":{"container3":{"Name":"container3"}}}
8	Test connectivity container1 -> container2	Ping container2 from container1 over custom network	Success: containers communicate
9	Test connectivity container1 -> container3	Ping container3 from container1 over different networks	Fail: no direct communication
10	End	Custom network isolates containers and allows controlled communication	Custom network benefits demonstrated

💡 Execution stops after demonstrating container communication and network isolation benefits.

Status Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 6	Final
my_custom_net	not exist	created	exists with container1	exists with container1, container2	exists with container1, container2	exists with container1, container2
container1	not exist	not exist	running on my_custom_net	running on my_custom_net	running on my_custom_net	running on my_custom_net
container2	not exist	not exist	not exist	running on my_custom_net	running on my_custom_net	running on my_custom_net
container3	not exist	not exist	not exist	not exist	running on default bridge	running on default bridge

Key Moments - 3 Insights

Why can't containers on different networks communicate by default?

Containers on different Docker networks are isolated; as shown in execution_table rows 8 and 9, container1 can ping container2 on the same custom network but cannot reach container3 on the default bridge network.

What is the benefit of creating a custom network instead of using the default bridge?

Custom networks provide isolation and better control over container communication, as seen in execution_table rows 1-4 where containers connect only to 'my_custom_net' and can communicate securely.

Does creating a custom network automatically improve security?

Yes, because it isolates containers from others on the default network, limiting exposure. Execution_table rows 5-7 show default bridge network containers are separate from custom network containers.

Visual Quiz - 3 Questions

Look at the execution table, at which step is the custom network created?

A Step 1

B Step 2

C Step 4

D Step 6

💡 Hint

Check the 'Command' column for 'docker network create' in the execution_table.

According to the variable tracker, after which step does container2 start running on the custom network?

A After Step 2

B After Step 3

C After Step 1

D After Step 6

💡 Hint

Look at the 'container2' row in variable_tracker to see when it changes to running.

If container3 was started on the custom network instead of default bridge, what would change in the execution table?

A Step 6 would fail because container3 can't join custom network

B No change; container3 always on default bridge

C Step 6 would show container3 on 'my_custom_net' and step 9 ping would succeed

D Step 4 would show container3 connected to default bridge

💡 Hint

Refer to steps 6 and 9 in execution_table about container3's network and connectivity.

Concept Snapshot

Docker containers connect to networks to communicate.
Default bridge network allows basic communication but lacks isolation.
Custom networks isolate containers and enable secure, controlled communication.
Create custom networks with 'docker network create'.
Attach containers using '--network' option.
Custom networks improve security and service discovery.

Full Transcript

This visual execution shows why custom Docker networks matter. Containers start on the default bridge network, which allows communication but no isolation. Creating a custom network isolates containers and lets them communicate securely. The example creates a custom network 'my_custom_net', runs two containers attached to it, and inspects the network to confirm connections. Another container runs on the default bridge network. Connectivity tests show containers on the same custom network can communicate, but those on different networks cannot. This demonstrates how custom networks improve security and management in Docker environments.

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