Docker Networking - An Overview

Docker has been in the limelight since the days of its very beginning and dockerizing almost ‘everything’ has been the talk of the day. Being at the hype, it’s getting more and more attention from both, developers or enterprises. As the IT world has taken the virtualization turn, the networking paradigm has also shifted from configuring physical routers, switches, LAN/WAN to networking components found in virtualized platforms, i.e., VMs, cloud, and others.

We’re going to start small, talk a little bit about the basics of docker networking, and then step up to get containers to talk to each other using more recent and advanced options that docker networking provides. Please note that this article is not meant for absolute beginners with docker rather it assumes you have the basic knowledge of about docker and containers. I’m not going to talk about what docker or containers are; rather, my focus would be to make the docker learning curve smooth by giving you an overview of networking. So, don’t mind me taking some sharp turns if I may.

Some Background

Containers bring a whole new ideology to how networking works across all your hosts as it will include everything needed to run the application - code, runtime, system tools, system libraries, settings, and everything.

This should make the idea clear that the container isolates the application form the rest of the system to ensure that the environment is constant. That’s what the whole docker (Not to forget here that docker is the most popular containerizing tool) craze is all about, right? To separate the application from your infrastructure to ensure quick development, shipping, and running the application is so far so good but there can be 100s or even 1000s of containers per host. Moreover, our microservice can be distributed across multiple hosts.

To be brutally honest, docker networking wasn’t something to brag about in the early days. It was complex and wasn’t easy to scale either. Not until after 2015; when docker laid its hands-on socket plane; that the docker networking started to shine. Since then, many interesting contributions have been made by the developer community including Pipework, Weave, Clocker, and Kubernetes. Docker Inc. also played the card by establishing the project to standardize networking known as libnetwork which implements the container network model (CNM). Our focus will be the same Container network model for this article.

Container Network Model

A container network model can be thought of as the backbone of the docker networking. It aims at keeping the networking as a library separated from container runtime rather than implementing it as a plugin using drivers (bridge, overlay, weave etc.).

That's the whole philosophy behind CNM model. You can think of it serving the purpose of abstraction layer to diversify the complexity of common networking as well as supporting multiple network drivers. The model has three main components -

• Sandbox - contains the configuration of a container's network stack.
• Endpoint - joins a Sandbox to a Network
• Network - a group of Endpoints that are able to communicate with each other directly

Here’s a pictorial representation of the model.

The project is hosted on GitHub. If you’re interested in knowing more about the CNM model, I would encourage you to go ahead and give it a thorough read.

I heard about CNI as well...?

Well yes! Container Network Interface (CNI) is another standard for container networking which was started by coreOS and is used by cloudfoundry, kubernetes etc. which is beyond the scope of this article. That’s why I didn’t touch that ground. I might talk about that in the upcoming article but my apologies for now. Feel free to search and learn on your own.

libnetwork

The libnetwork implements the same CNM model we just talked about. Docker was introduced under the philosophy of providing great user experience and seamless application portability across the infrastructure. Networking follows the same philosophy. Portability and Extensibility were two main factors behind the libnetwork project. The long-term goal of this project, as mentioned officially, was to follow the Docker and Linux philosophy of delivering small, highly modular, and composable tools that work well independently with the aim to satisfy that composable need for networking in containers. libnetwork is not just a driver interface but has much more to it. Some of its main features are,

• built-in IP address management
• multi-host networking
• service discovery and load balancing
• plugins to extend the ecosystems

Things should make sense by now. Saying that I feel like enough talking and it is time to get our hands on it.

Some fun with networking modes

I’m assuming that you already have Docker installed on your machine. If not, please follow the documentation here to get docker. I’m working on Linux (Ubuntu 18.04 LTS) so everything that I’m going to show you now would work fine on the same and more interestingly, since it's docker we are talking about, things shouldn’t be so different for Mac, Windows, or any other platform that you might be working on. You can make sure of the installation by simply checking the version. Open your terminal window and execute the following command.

And you should get the output as follow,

Now, we are good to rock and roll. You can check the available commands for networks by using the following command.

$ docker network

The above command results in the following output.

Let’s see what else is there for us.

Default Networking Modes

By default, there are some networking modes active. They can also be called as single host docket networking modes. To view docker networks, run,

The above command outputs three options as follow.

Pretty self-explanatory it is. Bridge, Host and None networks are by default created for us which are using bridge, host and null drivers. One thing to note here is that it shows the scope as local meaning that these networks would only work for this host. But what is so different about these networks? Let’s see.

Bridge Networking mode

The Docker daemon creates “docker0” virtual ethernet bridge that forwards packets between all interfaces attached to it. Let's inspect this network a little bit more by using the inspect command and specifying the name or ID of the network.

And it would output all the specifications and configurations of the network.