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.
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 asmy-bridge-network
Verify container network using the following command:
docker inspect cont-1 | grep -e network -e IP
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 indocker 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.