Creating custom bridge networks in Docker - Mechanics & Internals

Overview - Creating Custom Bridge Networks

What is it?

Creating custom bridge networks in Docker means making your own private network where containers can talk to each other securely and efficiently. Unlike the default network Docker provides, a custom bridge network lets you control how containers connect and communicate. This helps organize containers better and avoid conflicts. It is like building your own private neighborhood for your containers.

Why it matters

Without custom bridge networks, all containers share the same default network, which can cause name conflicts and security issues. Custom networks let you isolate groups of containers, control communication, and assign meaningful names. This improves security, debugging, and scalability. Imagine a world where all devices in a city share one big network without any separation — chaos and confusion would happen. Custom bridge networks prevent that in Docker.

Where it fits

Before learning custom bridge networks, you should understand basic Docker concepts like containers, images, and the default Docker network. After mastering custom bridge networks, you can explore advanced networking topics like overlay networks, network plugins, and service discovery in Docker Swarm or Kubernetes.

Mental Model

Core Idea

A custom bridge network is a private virtual network that connects Docker containers, letting them communicate securely and with controlled settings.

Think of it like...

It's like creating a private gated community inside a city where only invited houses (containers) can talk to each other freely, separate from the noisy public roads (default network).

┌─────────────────────────────┐
│       Docker Host           │
│  ┌───────────────┐          │
│  │ Custom Bridge │          │
│  │   Network     │          │
│  ├─────┬─────┬───┤          │
│  │Cont1│Cont2│...│          │
│  └─────┴─────┴───┘          │
│                             │
│  Default Bridge Network      │
│  ┌───────────────┐          │
│  │ ContA, ContB  │          │
│  └───────────────┘          │
└─────────────────────────────┘

Build-Up - 7 Steps

1

Foundation

Understanding Docker Default Networks

Concept: Learn what the default Docker bridge network is and how containers connect by default.

Docker automatically creates a default bridge network named 'bridge'. When you start containers without specifying a network, they connect here. Containers on this network can communicate by IP but not by container name. This network is shared by all containers unless you specify otherwise.

Result

Containers connect to the default bridge network and can communicate using IP addresses but not container names.

Knowing the default network behavior helps you understand why custom networks are needed for better container communication and isolation.

2

Foundation

Basics of Docker Bridge Networks

Concept: Understand what a bridge network is and how it works in Docker.

A bridge network is a private internal network created on the Docker host. It acts like a virtual switch connecting containers. Containers on the same bridge network can communicate using container names as DNS. Docker manages IP address assignment and routing inside this network.

Result

Containers on the same bridge network can reach each other by name and IP, isolated from other networks.

Understanding bridge networks is key to controlling container communication and network isolation.

3

Intermediate

Creating a Custom Bridge Network

Concept: Learn how to create your own bridge network with Docker CLI.

Use the command: docker network create my_custom_network This creates a new bridge network named 'my_custom_network'. You can specify options like subnet, gateway, and driver. Containers connected to this network can communicate by name and are isolated from other networks.

Result

A new custom bridge network named 'my_custom_network' is created and ready for container connections.

Creating custom networks lets you organize containers into isolated groups with controlled communication.

4

Intermediate

Connecting Containers to Custom Networks

🤔Before reading on: Do you think containers connect to custom networks automatically or need explicit commands? Commit to your answer.

Concept: Learn how to attach containers to your custom bridge network at start or after creation.

To start a container on a custom network: docker run --network my_custom_network --name container1 alpine sleep 1000 To connect an existing container: docker network connect my_custom_network container1 To disconnect: docker network disconnect my_custom_network container1

Result

Containers are connected to the custom network and can communicate with others on the same network by name.

Knowing how to connect containers to networks explicitly gives you control over container communication and network layout.

5

Intermediate

Inspecting and Managing Networks

Concept: Learn how to view details and manage Docker networks.

Use docker network ls to list networks. Use docker network inspect my_custom_network to see connected containers, IP ranges, and settings. Use docker network rm my_custom_network to remove a network (only if no containers are connected).

Result

You can see network details and manage lifecycle of custom networks.

Inspecting networks helps debug connectivity issues and understand network structure.

6

Advanced

Customizing Network Subnets and Gateways

🤔Before reading on: Can you specify IP ranges when creating custom networks? Commit to yes or no.

Concept: Learn how to define your own IP address ranges and gateways for custom bridge networks.

Create a network with specific subnet and gateway: docker network create \ --subnet=192.168.100.0/24 \ --gateway=192.168.100.1 \ my_custom_network This controls IP allocation and avoids conflicts with other networks.

Result

Custom bridge network uses specified IP range and gateway for container IPs.

Controlling IP ranges prevents conflicts in complex environments and integrates Docker networks with existing infrastructure.

7

Advanced

Advanced Isolation and Security with Bridge Networks

🤔Before reading on: Do you think containers on the same bridge network are fully isolated by default? Commit to yes or no.

Concept: Explore how custom bridge networks affect container isolation and how to enhance security using network options.

Containers on the same bridge network can communicate freely. To restrict communication, use options like --internal to block external access or configure firewall rules on the host. Docker also supports network plugins for advanced security policies. Understanding these helps prevent unwanted container access.

Result

You can create networks that isolate containers from outside or restrict container-to-container communication as needed.

Knowing the limits of bridge network isolation helps design secure container environments and avoid accidental exposure.

Under the Hood

Docker creates a Linux bridge device on the host for each bridge network. Containers connect virtual Ethernet interfaces (veth pairs) to this bridge. The bridge acts like a virtual switch forwarding packets between containers. Docker runs an embedded DNS server to resolve container names to IPs within the network. IP addresses are allocated from the subnet range assigned to the network. Network namespaces isolate container network stacks.

Why designed this way?

The bridge network model leverages existing Linux networking features for simplicity and performance. Using Linux bridges and namespaces avoids reinventing networking while providing isolation. This design balances ease of use, flexibility, and integration with host networking. Alternatives like overlay networks add complexity but enable multi-host communication.

Docker Host Network Stack
┌─────────────────────────────┐
│        Linux Bridge         │
│  ┌───────────────┐          │
│  │  veth-peer1   │◄────┐    │
│  ├───────────────┤     │    │
│  │  veth-peer2   │◄────┼────┤
│  └───────────────┘     │    │
│         │              │    │
│  ┌───────────────┐     │    │
│  │ Container 1   │     │    │
│  │ Network Stack │     │    │
│  └───────────────┘     │    │
│                        │    │
│  ┌───────────────┐     │    │
│  │ Container 2   │     │    │
│  │ Network Stack │     │    │
│  └───────────────┘     │    │
└────────────────────────┴────┘

Myth Busters - 4 Common Misconceptions

Quick: Do containers on different custom bridge networks communicate by default? Commit yes or no.

Common Belief: Containers on different custom bridge networks can talk to each other automatically.

Reality: Containers on separate custom bridge networks cannot communicate unless connected to a common network or explicitly linked.

Why it matters: Assuming cross-network communication leads to failed service interactions and debugging confusion.

Quick: Does creating many custom bridge networks slow down Docker performance? Commit yes or no.

Common Belief: Creating many custom bridge networks significantly slows down Docker and container performance.

Reality: Docker efficiently manages multiple bridge networks with minimal performance impact on the host.

Why it matters: Avoiding custom networks due to performance fears limits container organization and security.

Quick: Are containers on the default bridge network able to resolve each other's names? Commit yes or no.

Common Belief: Containers on the default bridge network can resolve each other's container names automatically.

Reality: The default bridge network does not provide automatic DNS resolution for container names; containers must use IP addresses.

Why it matters: Expecting name resolution causes communication failures and wasted debugging time.

Quick: Does the --internal flag on a bridge network block all container communication? Commit yes or no.

Common Belief: Using --internal on a bridge network disables all container communication inside that network.

Reality: The --internal flag blocks external access to the network but allows containers inside to communicate normally.

Why it matters: Misunderstanding this leads to incorrect network security setups and unexpected container isolation.

Expert Zone

1

Custom bridge networks allow multiple networks per container, enabling complex multi-network setups for microservices.

2

Docker's embedded DNS server only resolves container names within the same network, so cross-network name resolution requires extra configuration.

3

Network options like --opt com.docker.network.bridge.enable_icc control inter-container communication, allowing fine-grained security policies.

When NOT to use

Custom bridge networks are limited to single-host communication. For multi-host or cluster-wide networking, use overlay networks or Kubernetes networking solutions instead.

Production Patterns

In production, teams create multiple custom bridge networks to isolate environments (dev, test, prod), separate database and app containers, and enforce security boundaries. They also automate network creation and container attachment in CI/CD pipelines.

Connections

Virtual Local Area Network (VLAN)

Custom bridge networks in Docker are similar to VLANs in physical networking, both isolate traffic within a shared infrastructure.

Understanding VLANs helps grasp how Docker isolates container traffic logically without separate physical hardware.

Linux Network Namespaces

Docker bridge networks rely on Linux network namespaces to isolate container network stacks.

Knowing namespaces clarifies how containers have independent network interfaces and routing tables.

Office Workspace Partitioning

Creating custom bridge networks is like partitioning an office into separate rooms for teams to work without disturbing each other.

This connection helps understand the importance of network isolation for security and organization.

Common Pitfalls

#1 Trying to connect containers on different custom bridge networks without linking or shared networks.

Wrong approach:

docker run --network network1 --name c1 alpine sleep 1000
docker run --network network2 --name c2 alpine sleep 1000
# Trying to ping c2 from c1 fails

Correct approach:

docker network connect network1 c2
# Now c1 can ping c2 by name

Root cause:

Misunderstanding that containers must share a network to communicate by name.

#2 Assuming containers on the default bridge network can resolve each other's names.

Wrong approach:

docker run --name c1 alpine sleep 1000
docker run --name c2 alpine sleep 1000
# From c1: ping c2 (fails)

Correct approach:

docker network create mynet
docker run --network mynet --name c1 alpine sleep 1000
docker run --network mynet --name c2 alpine sleep 1000
# From c1: ping c2 (succeeds)

Root cause:

Not knowing default bridge network lacks embedded DNS for container names.

#3 Removing a network while containers are still connected to it.

Wrong approach:

docker network rm mynet
# Error: network is in use by containers

Correct approach:

docker network disconnect mynet container1
# Then remove network
docker network rm mynet

Root cause:

Not disconnecting containers before deleting the network.

Key Takeaways

Custom bridge networks let you create private, isolated networks for Docker containers to communicate securely and clearly.

Containers must share the same network to communicate by container name; different networks isolate traffic completely.

You can customize IP ranges and gateways in custom networks to avoid conflicts and integrate with existing infrastructure.

Docker uses Linux bridges and network namespaces under the hood to provide isolation and connectivity efficiently.

Understanding network isolation and management is essential for building secure, scalable containerized applications.

Practice

1. What is the main purpose of creating a custom bridge network in Docker?

easy

A. To increase the CPU usage of containers

B. To allow containers to communicate privately and securely

C. To automatically update container images

D. To create a backup of container data

Solution

1. Step 1: Understand Docker networking basics

   Docker uses networks to connect containers. The default bridge network is shared and less secure.

2. Step 2: Purpose of custom bridge networks

   Custom bridge networks isolate containers, allowing private and secure communication between them.

3. Final Answer:

   To allow containers to communicate privately and securely -> Option B

4. Quick Check:

   Custom bridge network = private container communication [OK]

Hint: Custom bridge = private container communication [OK]

Common Mistakes:

• Thinking custom bridge increases CPU usage
• Confusing network creation with image updates
• Assuming it creates data backups

2. Which of the following is the correct command to create a custom bridge network named my_bridge?

easy

A. docker network create --driver bridge my_bridge

B. docker create network bridge my_bridge

C. docker network new --type bridge my_bridge

D. docker bridge create network my_bridge

Solution

1. Step 1: Recall Docker network creation syntax

   The correct syntax is docker network create --driver bridge NETWORK_NAME.

2. Step 2: Match the command with the syntax

   docker network create --driver bridge my_bridge matches the correct syntax exactly for creating a bridge network named my_bridge.

3. Final Answer:

   docker network create --driver bridge my_bridge -> Option A

4. Quick Check:

   Correct syntax = docker network create --driver bridge [OK]

Hint: Use 'docker network create --driver bridge NAME' [OK]

Common Mistakes:

• Using wrong command order
• Missing --driver flag
• Using 'new' or 'create' incorrectly

3. Given the command docker network create --driver bridge isolated_net, what will be the output of docker network ls related to this network?

medium

A. No change; the network list remains the same

B. An error message saying 'driver not found' will appear

C. The default bridge network will be removed

D. A new network named 'isolated_net' with driver 'bridge' will appear in the list

Solution

1. Step 1: Understand the effect of the create command

   The command creates a new bridge network named 'isolated_net'.

2. Step 2: Check the network list after creation

   Running docker network ls shows all networks including the newly created 'isolated_net' with driver 'bridge'.

3. Final Answer:

   A new network named 'isolated_net' with driver 'bridge' will appear in the list -> Option D

4. Quick Check:

   New bridge network appears in list [OK]

Hint: New bridge network shows in 'docker network ls' [OK]

Common Mistakes:

• Expecting an error for valid driver
• Thinking default bridge is removed
• Assuming no change in network list

4. You ran docker network create --driver bridge without specifying a network name. What is the likely result?

medium

A. Docker creates a network named 'bridge' by default

B. Docker creates a network with a random generated name

C. Docker throws an error about missing network name

D. Docker creates the default bridge network again

Solution

1. Step 1: Check required arguments for network creation

   The docker network create command requires a network name after options.

2. Step 2: Result of missing network name

   Omitting the network name causes Docker to throw an error indicating the missing argument.

3. Final Answer:

   Docker throws an error about missing network name -> Option C

4. Quick Check:

   Missing name causes error [OK]

Hint: Always specify network name after options [OK]

Common Mistakes:

• Assuming Docker auto-generates network name
• Thinking 'bridge' is default name created
• Confusing with default bridge network

5. You want two containers to communicate only with each other and not with other containers on the host. Which steps correctly create and use a custom bridge network named private_net?

hard

A. Create network with docker network create --driver bridge private_net and run containers with --network private_net

B. Run containers with --link option without creating a network

C. Use default bridge network and assign static IPs manually

D. Create network with docker network create private_net without specifying driver

Solution

1. Step 1: Create a custom bridge network

   Use docker network create --driver bridge private_net to create an isolated network.

2. Step 2: Run containers attached to this network

   Start containers with --network private_net so they communicate only within this network.

3. Final Answer:

   Create network with 'docker network create --driver bridge private_net' and run containers with '--network private_net' -> Option A

4. Quick Check:

   Custom bridge + --network = isolated container communication [OK]

Hint: Create bridge network then run containers with --network [OK]

Common Mistakes:

• Using --link which is deprecated
• Relying on default bridge for isolation
• Omitting --driver option causing default driver