Docker Networks and beyond 🐳

How containers talk to each other in the Docker runtime.

Communication is key — that too in the world of Docker containers.

If you’re familiar with system processes and the internet, you’ll surely be well versed with ports and their magic.

It should then be no surprise that Docker containers help microservices function as a unit through the use of such ports.

But of course, ports can’t really accomplish much on their own, so having an application’s services interact over a network would start to make sense.

In this article, we’ll uncover exactly how this works, specifically:

• Docker Networks
• Bridge Network
• Hands-on with Bridges
• User-defined Network
• Hands-on with User-defined networks
• Other network types

Docker networks

Docker’s networking capabilities are versatile since it offers various network types to cater to different needs. One of the most commonly encountered networks is the bridge network, which happens to be the default network assigned to containers.

Courtesy: https://toolsqa.com

The Bridge Network: Your Container’s Playground

By default, Docker containers are connected to a bridge network. This network type provides an isolated environment for your containers, allowing them to communicate with each other using their container names. Here, the container names can be considered host names, where each container can communicate on some port.

When to use Bridges

Any container created using docker run defaults to a default bridge network. Bridges have a few important features:

• They provide container isolation from external networks
• They provide basic network functionalities
• They are used for single container applications requiring network access

Hands-on with Bridges

Fire up your terminal and type the following:

docker network create my-bridge-network

We have now established a bridge network. Now let's create some containers and assign them to this network.

docker run --itd --network my-bridge-network --name cont-1 hello-world

This docker run command has a new flag:

• --network: Specifies the container’s network. In this example, we specify it as my-bridge-network

Verify container network using the following command:

docker inspect cont-1 | grep -e network -e IP

Output for the command

Here, we can see the NetworkMode is set to our custom my-bridge-network with randomly assigned IP of 172.19.0.2

Why you shouldn’t use Bridges

• Bridge networks are limited to isolated container exposure, so you cannot assign custom IP addresses to containers in the network.

User-defined Networks

Use these for maximum flexibility. User-defined networks have the following features:

• Custom subnets: Define your own cidr blocks for the network
• Custom IP address assignment: Assign your own IP address to containers. This is done using the --ip flag in docker run

Hands-on with User-defined networks

docker network create --subnet=<cidr-block> my-defined-network

• In place of cidr-block , assign the range of IP addresses you wish to allocate to the network.

The docker run command now becomes:

docker run --network my-defined-network --ip <your_ip>  --name <container_name> -d <image_name>

To verify assignment, use the same docker inspect cont-1 | grep -e network -e IP command.

Other network types

There are a total of 3 additional network types that Docker provides, each having their own meaningful use-cases

Host Networks:

• Full Host Integration: Containers using the host network share the network namespace with the host system, effectively using the host’s network stack.
• Performance: Offers the best network performance but lacks isolation.
• Use Cases: Suitable for applications that require maximum network performance and do not need network isolation.

This network type lacks isolation since it shares the network namespace of the host. While this is the more performant network type, it also poses a security concern since any container can access another container. Vulnerabilities are introduced.

Overlay Networks

• Multi-Host Communication: Overlay networks enable communication between containers running on different Docker hosts or Swarm nodes.
• Use Cases: Ideal for container orchestration platforms like Docker Swarm and Kubernetes, where containers need to communicate across multiple hosts.

Overlay networks shine in container orchestration .

Macvlan Networks

• Directly Attached to Physical Network: Macvlan networks allow containers to have their own MAC addresses and appear as physical devices on the network.
• Use Cases: Useful for scenarios where containers need to appear as separate physical devices on the network, such as running network appliances or legacy applications.

You wouldn’t typically use these networks.

None Network

• Placeholder network for an offline container
• Complete isolation: No container can reach a container in the none network. This network loosely couples disconnected offline containers
• Use Cases: Used when no network access whatsoever is required by a container.

None networks loosely couple offline containers, but these offline containers can’t interact with each other either.

And that’s a wrap for networking in Docker containers! Please follow for more things on Docker and DevOps!