Learning Docker Networking

4.6 (5 reviews total)
By Rajdeep Dua , Vaibhav Kohli , Santosh Kumar Konduri
    Advance your knowledge in tech with a Packt subscription

  • Instant online access to over 7,500+ books and videos
  • Constantly updated with 100+ new titles each month
  • Breadth and depth in over 1,000+ technologies

About this book

Docker is a Linux container implementation that enables the creation of light weight portable development and production environments. These environments can be updated incrementally. Docker achieves this by leveraging containment principles like cgroups and Linux namespaces along with Overlay filesystem based portable images. Docker provides the networking primitives that allow administrators to specify how different containers network with each application and connect each of its components, then distribute them across a large number of servers and ensure coordination between them irrespective of the host or VM they are running in.

This book will show you how to create, deploy, and manage a virtual network for connecting containers spanning single or multiple hosts.

Publication date:
February 2016
Publisher
Packt
Pages
176
ISBN
9781785280955

 

Chapter 1. Docker Networking Primer

Docker is a lightweight container technology that has gathered enormous interest in recent years. It neatly bundles various Linux kernel features and services, such as namespaces, cgroups, SELinux, and AppArmor profiles, over union filesystems such as AUFS and BTRFS in order to make modular images. These images provide a highly configurable virtualized environment for applications and follow a write once, run anywhere workflow. An application can be composed of a single process running in a Dcker container or it could be made up of multiple processes running in their own containers and being replicated as the load increases. Therefore, there is a need for powerful networking elements that can support various complex use cases.

In this chapter, you will learn about the essential components of Docker networking and how to build and run simple container examples.

This chapter covers the following topics:

  • Networking and Docker

  • The docker0 bridge networking

  • Docker OVS networking

  • Unix domain networks

  • Linking Docker containers

  • What's new in Docker networking

Docker is getting a lot of traction in the industry because of its performance-savvy and universal replicability architecture, while providing the following four cornerstones of modern application development:

  • Autonomy

  • Decentralization

  • Parallelism

  • Isolation

Furthermore, wide-scale adoption of Thoughtworks's microservices architecture, or LOSA (Lots of Small Applications), is further bringing potential to Docker technology. As a result, big companies such as Google, VMware, and Microsoft have already ported Docker to their infrastructure, and the momentum is continued by the launch of myriad Docker start-ups, namely Tutum, Flocker, Giantswarm, and so on.

Since Docker containers replicate their behavior anywhere, be it your development machine, a bare metal server, virtual machine, or data center, application designers can focus their attention on development, while operational semantics are left with DevOps. This makes team workflow modular, efficient, and productive. Docker is not to be confused with a virtual machine (VM), even though they are both virtualization technologies. While Docker shares an OS with providing a sufficient level of isolation and security to applications running in containers, it later completely abstracts away the OS and gives strong isolation and security guarantees. However, Docker's resource footprint is minuscule in comparison to a VM and hence preferred for economy and performance. However, it still cannot completely replace VMs and is therefore complementary to VM technology. The following diagram shows the architecture of VMs and Docker:

 

Networking and Docker


Each Docker container has its own network stack, and this is due to the Linux kernel NET namespace, where a new NET namespace for each container is instantiated and cannot be seen from outside the container or from other containers.

Docker networking is powered by the following network components and services.

Linux bridges

These are L2/MAC learning switches built into the kernel and are to be used for forwarding.

Open vSwitch

This is an advanced bridge that is programmable and supports tunneling.

NAT

Network address translators are immediate entities that translate IP addresses and ports (SNAT, DNAT, and so on).

IPtables

This is a policy engine in the kernel used for managing packet forwarding, firewall, and NAT features.

AppArmor/SELinux

Firewall policies for each application can be defined with these.

Various networking components can be used to work with Docker, providing new ways to access and use Docker-based services. As a result, we see a lot of libraries that follow a different approach to networking. Some of the prominent ones are Docker Compose, Weave, Kubernetes, Pipework, libnetwork, and so on. The following figure depicts the root ideas of Docker networking:

 

The docker0 bridge


The docker0 bridge is the heart of default networking. When the Docker service is started, a Linux bridge is created on the host machine. The interfaces on the containers talk to the bridge, and the bridge proxies to the external world. Multiple containers on the same host can talk to each other through the Linux bridge.

docker0 can be configured via the --net flag and has, in general, four modes:

  • --net default

  • --net=none

  • --net=container:$container2

  • --net=host

The --net default mode

In this mode, the default bridge is used as the bridge for containers to connect to each other.

The --net=none mode

With this mode, the container created is truly isolated and cannot connect to the network.

The --net=container:$container2 mode

With this flag, the container created shares its network namespace with the container called $container2.

The --net=host mode

With this mode, the container created shares its network namespace with the host.

Port mapping in Docker container

In this section, we look at how container ports are mapped to host ports. This mapping can either be done implicitly by Docker Engine or can be specified.

If we create two containers called Container1 and Container2, both of them are assigned an IP address from a private IP address space and also connected to the docker0 bridge, as shown in the following figure:

Both the preceding containers will be able to ping each other as well as reach the external world.

For external access, their port will be mapped to a host port.

As mentioned in the previous section, containers use network namespaces. When the first container is created, a new network namespace is created for the container. A vEthernet link is created between the container and the Linux bridge. Traffic sent from eth0 of the container reaches the bridge through the vEthernet interface and gets switched thereafter. The following code can be used to show a list of Linux bridges:

# show linux bridges
$ sudo brctl show

The output will be similar to the one shown as follows, with a bridge name and the veth interfaces on the containers it is mapped to:

bridge name      bridge id        STP enabled    interfaces
docker0      8000.56847afe9799        no         veth44cb727
                                                 veth98c3700

How does the container connect to the external world? The iptables nat table on the host is used to masquerade all external connections, as shown here:

$ sudo iptables -t nat -L –n
...
Chain POSTROUTING (policy ACCEPT) target prot opt
source destination MASQUERADE all -- 172.17.0.0/16
!172.17.0.0/16
...

How to reach containers from the outside world? The port mapping is again done using the iptables nat option on the host machine.

 

Docker OVS


Open vSwitch is a powerful network abstraction. The following figure shows how OVS interacts with the VMs, Hypervisor, and the Physical Switch. Every VM has a vNIC associated with it. Every vNIC is connected through a VIF (also called a virtual interface) with the Virtual Switch:

OVS uses tunnelling mechanisms such as GRE, VXLAN, or STT to create virtual overlays instead of using physical networking topologies and Ethernet components. The following figure shows how OVS can be configured for the containers to communicate between multiple hosts using GRE tunnels:

 

Unix domain socket


Within a single host, UNIX IPC mechanisms, especially UNIX domain sockets or pipes, can also be used to communicate between containers:

$  docker run  --name c1 –v /var/run/foo:/var/run/foo –d –I –t base /bin/bash  
$  docker run  --name c2 –v /var/run/foo:/var/run/foo –d –I –t base /bin/bash

Apps on c1 and c2 can communicate over the following Unix socket address:

struct  sockaddr_un address;
address.sun_family = AF_UNIX;
snprintf(address.sun_path, UNIX_PATH_MAX, "/var/run/foo/bar" );

C1: Server.c

C2: Client.c

bind(socket_fd, (struct sockaddr *) &address, sizeof(struct sockaddr_un));
listen(socket_fd, 5);
while((connection_fd = accept(socket_fd, (struct sockaddr *) &address, &address_length)) > -1)
nbytes = read(connection_fd, buffer, 256);

connect(socket_fd, (struct sockaddr *) &address, sizeof(struct sockaddr_un));
write(socket_fd, buffer, nbytes);
 

Linking Docker containers


In this section, we introduce the concept of linking two containers. Docker creates a tunnel between the containers, which doesn't need to expose any ports externally on the container. It uses environment variables as one of the mechanisms for passing information from the parent container to the child container.

In addition to the environment variable env, Docker also adds a host entry for the source container to the /etc/hosts file. The following is an example of the host file:

$ docker run -t -i --name c2 --rm --link c1:c1alias training/webapp /bin/bash
[email protected]<container_id>:/opt/webapp# cat /etc/hosts
172.17.0.1  aed84ee21bde
...
172.17.0.2  c1alaias 6e5cdeb2d300 c1

There are two entries:

  • The first is an entry for the container c2 that uses the Docker container ID as a host name

  • The second entry, 172.17.0.2 c1alaias 6e5cdeb2d300 c1, uses the link alias to reference the IP address of the c1 container

The following figure shows two containers Container 1 and Container 2 connected using veth pairs to the docker0 bridge with --icc=true. This means these two containers can access each other through the bridge:

Links

Links provide service discovery for Docker. They allow containers to discover and securely communicate with each other by using the flag -link name:alias. Inter-container communication can be disabled with the daemon flag -icc=false. With this flag set to false, Container 1 cannot access Container 2 unless explicitly allowed via a link. This is a huge advantage for securing your containers. When two containers are linked together, Docker creates a parent-child relationship between them, as shown in the following figure:

From the outside, it looks like this:

# start the database
$  sudo docker run -dp 3306:3306 --name todomvcdb \
-v /data/mysql:/var/lib/mysql cpswan/todomvc.mysql 

# start the app server
$  sudo docker run -dp 4567:4567 --name todomvcapp \ 
--link todomvcdb:db cpswan/todomvc.sinatra 

On the inside, it looks like this:

$  dburl = ''mysql://root:[email protected]'' + \ ENV[''DB_PORT_3306_TCP_ADDR''] + ''/todomvc''
$  DataMapper.setup(:default, dburl)
 

What's new in Docker networking?


Docker networking is at a very nascent stage, and there are many interesting contributions from the developer community, such as Pipework, Weave, Clocker, and Kubernetes. Each of them reflects a different aspect of Docker networking. We will learn about them in later chapters. Docker, Inc. has also established a new project where networking will be standardized. It is called libnetwork.

libnetwork implements the container network model (CNM), which formalizes the steps required to provide networking for containers while providing an abstraction that can be used to support multiple network drivers. The CNM is built on three main components—sandbox, endpoint, and network.

Sandbox

A sandbox contains the configuration of a container's network stack. This includes management of the container's interfaces, routing table, and DNS settings. An implementation of a sandbox could be a Linux network namespace, a FreeBSD jail, or other similar concept. A sandbox may contain many endpoints from multiple networks.

Endpoint

An endpoint connects a sandbox to a network. An implementation of an endpoint could be a veth pair, an Open vSwitch internal port, or something similar. An endpoint can belong to only one network but may only belong to one sandbox.

Network

A network is a group of endpoints that are able to communicate with each other directly. An implementation of a network could be a Linux bridge, a VLAN, and so on. Networks consist of many endpoints, as shown in the following diagram:

 

The Docker CNM model


The CNM provides the following contract between networks and containers:

  • All containers on the same network can communicate freely with each other

  • Multiple networks are the way to segment traffic between containers and should be supported by all drivers

  • Multiple endpoints per container are the way to join a container to multiple networks

  • An endpoint is added to a network sandbox to provide it with network connectivity

We will discuss the details of how CNM is implemented in Chapter 6, Next Generation Networking Stack for Docker: libnetwork.

 

Summary


In this chapter, we learned about the essential components of Docker networking, which have evolved from coupling simple Docker abstractions and powerful network components such as Linux bridges and Open vSwitch.

We learned how Docker containers can be created with various modes. In the default mode, port mapping helps through the use of iptables NAT rules, allowing traffic arriving at the host to reach containers. Later in the chapter, we covered the basic linking of containers. We also talked about the next generation of Docker networking, which is called libnetwork.

About the Authors

  • Rajdeep Dua

    Rajdeep Dua has over 18 years experience in the cloud and big data space. He has taught Spark and big data at some of the most prestigious tech schools in India: IIIT Hyderabad, ISB, IIIT Delhi, and Pune College of Engineering. He currently leads the developer relations team at Salesforce India. He has also presented BigQuery and Google App Engine at the W3C conference in Hyderabad. He led the developer relations teams at Google, VMware, and Microsoft, and has spoken at hundreds of other conferences on the cloud. Some of the other references to his work can be seen at Your Story and on ACM digital library. His contributions to the open source community relate to Docker, Kubernetes, Android, OpenStack, and Cloud Foundry.

    Browse publications by this author
  • Vaibhav Kohli

    Vaibhav Kohli at present is working in VMware's R&D Department and earlier taught computer engineering for a year at the esteemed University of Mumbai. He works for the office of the CTO, VMware IoT (Internet of Things) project. He has published many research papers in leading journals, IEEE transactions, and has filed patents at VMware on container technology. One of his big data projects has won the top prize at the national-level project showcase event. He has conducted workshops, hackathons, training sessions, and trade shows in many countries and is a reputed & established speaker at conferences on IoT and Docker technology. He is an active open source code contributor, repository manager and has also published many online Docker & Kubernetes tutorials. He has helped many customers and organizations to understand cloud-native apps, DevOps model and migrate to micro-service architecture. He has also recently published a book on Docker Networking.

    Vaibhav manages and leads various meetup groups across India on the latest cutting-edge Docker and Kubernetes technologies.

    Browse publications by this author
  • Santosh Kumar Konduri

    Santosh Kumar Konduri has around 5 years of IT experience. He is an expert OpenStack administrator with 3 years of experience.

    Browse publications by this author

Latest Reviews

(5 reviews total)
I understand Docker networking much better
I've gotten many book, both free and purchase. The information was correct and the teach very sound. Some of the older books has some dated information, but it was well documented what version of libraries was used. The two books on using Docker that I recently reviewed on the free Mapt account and then purchased has helped me understand Docker a whole lot!
Very informative and useful
Book Title
Unlock this book and the full library for FREE
Start free trial