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.