Why custom networks matter in Docker - Performance Analysis

Time Complexity: Why custom networks matter

O(n)

Understanding Time Complexity

When using Docker, custom networks help containers talk to each other in a controlled way.

We want to see how the time to connect containers changes as we add more containers to a custom network.

Scenario Under Consideration

Analyze the time complexity of creating a custom Docker network and connecting multiple containers to it.

# Create a custom network
docker network create my_custom_network

# Run multiple containers attached to this network
for i in $(seq 1 5); do
  docker run -d --net my_custom_network --name container_$i alpine sleep 1000
 done

This code creates one custom network and then starts several containers connected to it.

Identify Repeating Operations

Look for repeated actions that affect time.

• Primary operation: Starting each container and attaching it to the custom network.
• How many times: Once per container, repeated for each container started.

How Execution Grows With Input

As you add more containers, the total time to start and connect them grows.

Input Size (n)	Approx. Operations
10	10 container starts and network attachments
100	100 container starts and network attachments
1000	1000 container starts and network attachments

Pattern observation: The time grows directly with the number of containers added.

Final Time Complexity

Time Complexity: O(n)

This means the time to connect containers grows in a straight line as you add more containers.

Common Mistake

[X] Wrong: "Adding more containers to a custom network happens instantly, no matter how many containers there are."

[OK] Correct: Each container needs to be started and connected, so the total time adds up with each container.

Interview Connect

Understanding how container networking scales helps you design systems that stay fast and reliable as they grow.

Self-Check

What if we used the default bridge network instead of a custom network? How would the time complexity change?

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