Skip to main content

Docker Networking Fundamentals

Introduction​

Docker networking is a core concept enabling communication both between containers and with the outside world. Mastering Docker networking is crucial for building scalable, secure, and reliable containerized applications. In this lesson, you'll learn how Docker handles networking, explore its built-in network drivers, work with custom networks, and understand best practices and common pitfalls.

Table of Contents​

  1. Docker Networking Overview
  2. Network Drivers Explained
  3. Working with Docker Networks
  4. Container Communication Scenarios
  5. Exposing Containers to the Host
  6. Use Cases and Best Practices
  7. Common Mistakes and Pitfalls
  8. Summary
  9. Quiz

Docker Networking Overview​

When you start a container, Docker automatically connects it to a network. This allows:

  • Communication between containers
  • Communication between containers and the host
  • Access to external networks (like the internet)

Docker abstracts much of this complexity using network drivers, giving you flexibility and control over your containerized applications' communication.

Network Drivers Explained​

Docker includes several built-in network drivers:

1. bridge (default)​

  • Purpose: Isolated networks on a single Docker host.
  • Use case: Typical for most standalone applications.

2. host​

  • Purpose: Removes network isolation; container shares the host's network stack.
  • Use case: High-performance networking or when containers must listen on network interfaces directly.

3. none​

  • Purpose: Disables all networking.
  • Use case: Security or testing scenarios where no network access is required.

4. overlay​

  • Purpose: Enables multi-host networking (requires Docker Swarm).
  • Use case: Distributed applications across multiple Docker hosts.

5. macvlan​

  • Purpose: Assigns a MAC address to a container, making it appear as a physical device on the network.
  • Use case: Containers needing to be directly accessible on the physical network.

Example: Listing available network drivers

docker network ls

Working with Docker Networks​

Inspecting the Default Network​

When you run a container without specifying a network, it connects to the default bridge network.

docker network inspect bridge

Creating a Custom Bridge Network​

Custom networks provide better DNS-based service discovery and isolation.

docker network create my-custom-network

Run containers attached to the custom network:

docker run -d --name app1 --network my-custom-network nginx
docker run -d --name app2 --network my-custom-network alpine sleep 9999

Now, app2 can reach app1 by container name:

docker exec app2 ping -c 3 app1

Connecting/Disconnecting Containers​

Connect an existing container:

docker network connect my-custom-network app2

Disconnect a container:

docker network disconnect my-custom-network app2

Container Communication Scenarios​

Containers on the Same Network​

  • Can communicate using container names as hostnames.
  • Example: Microservices architecture where services discover each other.

Containers on Different Networks​

  • Cannot communicate unless connected to the same network.
  • Enhances security and isolation.

Exposing Containers to the Host​

Containers often need to receive traffic from outside Docker (e.g., web servers).

Publishing Ports​

Expose a container's port to the host using the -p flag:

docker run -d -p 8080:80 nginx
  • Host port 8080 maps to container port 80.

Host vs. Bridge Networking​

  • bridge: Containers get a private IP, and ports must be published for host access.
  • host: Container uses the host's network directly (no port publishing needed).

Example: Host networking (Linux only):

docker run --network host nginx

Use Cases and Best Practices​

  • Service Discovery: Use user-defined bridge networks for DNS-based discovery between containers.
  • Isolation: Use separate networks for different application tiers.
  • Multi-Host Networking: Use overlay networks (with Docker Swarm) for distributed applications.
  • Security: Only publish necessary ports; use none or custom networks for sensitive workloads.

Common Mistakes and Pitfalls​

  • Publishing Ports Unnecessarily: Avoid exposing all ports to the host unless required.
  • Relying on Default Bridge for Production: The default bridge network has limitations (e.g., no automatic service discovery).
  • Ignoring Network Isolation: Connecting all containers to the same network can create security risks.
  • Forgetting to Connect to Custom Networks: Containers on different networks cannot communicate.

Summary​

Docker networking is essential for building connected, scalable containerized applications. You learned about different network drivers, how to create and use custom networks, container communication patterns, and best practices for exposing and securing containerized services. Understanding these fundamentals enables you to design robust and secure Docker-based systems.

Quiz​

1. What is the default Docker network driver used when you run a container without specifying a network?
A) host
B) bridge
C) overlay
D) none

Answer: B) bridge

2. How can containers discover and communicate with each other by name?
A) By using the host network
B) By connecting to the default bridge
C) By connecting to a user-defined bridge network
D) Only via published ports

Answer: C) By connecting to a user-defined bridge network

3. Which network driver would you use to run containers that need to be directly accessible on the physical network with their own MAC addresses?
A) overlay
B) bridge
C) macvlan
D) none

Answer: C) macvlan

4. True or False: Containers on different custom bridge networks can communicate with each other by default.

Answer: False

5. What is a common security mistake when exposing container ports?
A) Using a custom network
B) Publishing only required ports
C) Publishing unnecessary ports to the host
D) Using DNS for service discovery

Answer: C) Publishing unnecessary ports to the host

End of Lesson