In the modern world, the container is a fascinating technology, as it has revolutionized software development and delivery. Everyone is using containers because of its dynamic, scalable, and isolated nature.
People do use some orchestration software such as Kubernetes, Openshift, Docker Swarm, and AWS ECS, etc to run their production workloads on containers.
But the question is how these containers communicate with each other in various situations?
Well, that comes through Docker networking. So in this blog, we will be discussing the docker networking goals, architecture, and types.
Essentially, docker networking is used to create communication between the docker containers and the outside world via host machine or you might say that this is a communication passage through which all the isolated containers communicate with each other in different situations to perform the required acts.
In other words, if we run different workloads on the docker, there should be a communication mechanism through which applications/workloads will interact with each other. For eg, if we have 3-tier application i.e. frontend, backend and database and all of these run on a single host machine, then we will need a simple docker network but what if workloads are running on different machines, in that case, we would need a different type of docker network.
So docker provides different types of docker networks and we can leverage them as per our needs.
Goals of Docker Networking
There are lots of benefits/goals of docker networking but we will highlight some key points only.
Flexibility:- It gives you the flexibility to run any number of container workloads/applications on any sort of infrastructure, such as multi-cloud, hybrid cloud, or single cloud.
Cross-Platform:- Containers can interact through multi-platforms without having depending on the server’s size or operating system.
Scalability:- Docker networking lets you grow and scale your applications without affecting application efficiency.
Types of Networking
Docker offers multiple networking types that can be exploited/leveraged according to our requirements or scenarios. But we will be talking about the Bridge, Host and, Overlay networks.
Bridge:- The bridge network is a private internal default network, built on the host by the docker. Each container has an internal IP address and can reach other container using this internal IP. Bridge networks are typically used when the applications run in containers needs to communicate on standalone setup.
A Bridge network is like a software device that interacts with the host machine’s kernel to create a software bridge network that allows containers to communicate with each other. It creates a virtual network between host and containers which perform all the network address translations(NAT).
Host:- This driver removes the network isolation between the docker host and the docker containers for direct use of host networking. But with this, you will not be able to run multiple containers on the same host, on the same port as all containers in the host network will have common ports of the host system.
Containers that are running with the host network share’s host networking namespace. The network performance would be better in this networking because it doesn’t require NAT.
Overlay:- The overlay driver is designed to enable communication between docker containers in different networks that are hidden from each other. Those networks may be public or private. If there are two hosts and each one runs a docker, the Overlay network will help to create a subnet at the top of these two hosts and each container connected to this Overlay network will be able to communicate with other containers.
For creating an overlay network, we need a key/value store where all host system’s containers information will be stored for communication, for example:- zookeeper, etcd, or consul.
Also, overlay network sits over the top of host networks, some firewall level configuration will also be required. If you want to setup a secure overlay network, you can enable the IPSec encryption. We will see this in-depth in our next blog on overlay networking.
But mostly these tools are to manage overlay networks with Kubernetes or some other orchestrator, so we’ll build an overlay network in our next blog without any orchestration tool to make the idea of docker networking clearer.
Now I am assuming you guys have a basic understanding about docker networking.
Thanks for reading, I’d really appreciate any and all feedback, please leave your comment below if you guys have any feedback.
Cheers till next time!!