Docker - Day4

When working with Docker, running a single container is simple. But real-world applications usually consist of multiple services like:

• A web frontend

• An API service

• A database backend

• A caching layer

All of these need to communicate with each other—securely, efficiently, and sometimes across different hosts. That’s why Docker networking is essential.

By default, Docker containers are isolated environments. This means they:

• ❌ Cannot talk to each other

• ❌ Cannot talk to the host (unless explicitly allowed)

• ❌ Cannot access the external internet or other networks without configuration

To make containers work together in production scenarios, custom Docker networking is required.

Here’s why Docker networking matters:

• ✅ Inter-container communication: Services like web apps, databases, and caches often need to talk to each other.

• ✅ External connectivity: Some containers need internet access or need to expose services to the outside world.

• ✅ Multi-host communication: In a distributed system or Docker Swarm, containers on different hosts must communicate.

• ✅ Security and isolation: Proper network configuration ensures that only authorized containers or systems can talk to each other.

• ✅ Load balancing and service discovery: Networking enables multiple instances of a service to share the load and be discoverable.

Simply put, Docker networking lets your containers behave like real networked apps, with isolation and control baked in.

Different Types of Networking:

1. Bridge Network (Default for standalone containers)

• When you run docker run without specifying a network, Docker connects your container to the default bridge network (docker0).

• It is a private internal network created by Docker on the host, each container gets a private IP address within this network.

• Containers can communicate with each other using this internal network.

• Docker uses Network Address Translation (NAT) to route outbound traffic to the internet.

• You can also create a custom bridge (docker network create) for better DNS-based name resolution and isolation.

Use Case:

• Single-host apps like frontend-backend-database stacks

• Isolated testing environments

✅ Pros:

• Built-in NAT for internet access

• Simple and secure (isolated from host)

• Can define custom bridge networks for better control

❌ Cons:

• Doesn’t work across multiple Docker hosts

• Requires port mapping to expose services to host

2. Host Network

• When using --network host, Docker doesn't assign a separate network interface to the container. The container binds to ports on the host directly

• Container shares the same IP address and network stack as the host. this removes isolation between the Docker container and the host’s network..

Use Case:

• Low-latency applications (e.g., real-time monitoring, high-performance servers)

• Avoid NAT overhead

✅ Pros:

• Better performance (no NAT layer)

• Direct access to host network

❌ Cons:

• No network isolation

• Port conflicts (multiple containers can't bind same ports)

• Not available on Windows and Mac

3. Overlay Network (Swarm mode only)

• A distributed network that spans across multiple Docker hosts. Docker uses VXLAN tunneling to encapsulate traffic between hosts.

• Used in Docker Swarm to allow services on different hosts to communicate securely, each service is reachable by DNS name inside the overlay.

• Requires Docker Swarm mode (docker swarm init, docker service create).

Use Case:

• Microservices that run across multiple VMs or servers

• Internal service discovery and routing in a cluster

✅ Pros:

• Built-in encryption

• Works across hosts (multi-node)

• Integrated with Swarm DNS

❌ Cons:

• Slight overhead due to VXLAN encapsulation

• Only works in Swarm mode

4. Macvlan Network

• Assigns a MAC address and IP address from the host’s physical network to the container.

• The container looks like a physical machine on the LAN.

• Docker bridges the container to the host’s NIC using macvlan driver.

• Requires configuring a parent interface (e.g., eth0).

Use Case:

• When containers must talk to devices on the same LAN (like a router or printer)

• For apps that require unique MAC/IP (e.g., legacy systems)

✅ Pros:

• Direct access to LAN

• Each container can be addressed as a real device

• No NAT, no port mapping needed

❌ Cons:

• Cannot easily talk to the host (without static routes)

• More complex to set up

• Not supported on all cloud VMs or Wi-Fi interfaces

5. None Network

• The container gets no network interface other than loopback (localhost).

• Used with --network none, Docker creates an isolated container with no external connectivity.

Use Case:

• Fully sandboxed containers

• Containers doing data processing without needing external access

✅ Pros:

• Maximum security

• No risk of unwanted communication

❌ Cons:

• No external communication at all

• Manual configuration required for any network access

6. Custom Bridge Network (User-defined)

• Like the default bridge, but created explicitly by the user. Containers attached to this network can ping each other by name.

• Offers container name resolution, improved DNS, and isolation.

• You create it via docker network create mynet

Use Case:

• Application stacks (e.g., WordPress + MySQL)

• Isolated container groups with service discovery

✅ Pros:

• Built-in DNS (e.g., ping db)

• Controlled isolation

• Easy to manage multi-container apps

❌ Cons:

• Still limited to single host