Docker Networking- Part 1

Note: If you have missed my previous articles on Docker, you can find them here.
Application deployment models evolution.
Getting started with Docker.
Docker file and images.
Publishing images to Docker Hub and re-using them
Docker- Find out what's going on

Containers allow you to break your application into small functional areas called microservices. Microservice implement a set of functionalities like "shopping cart", "Payment Gateways" and exports "services" to other parts of the application with APIs (typically JSON).

For an e-commerce platform, the web tier in the above diagram could further be broken down "User-Registration-UI", "Shopping-cart-UI", "payment-gateway-UI" etc. These will be docker containers and will talk to each other ONLY through APIs.

Note: The key to understanding of microservices is "talk to each other only through API's". This also means,code changes could be implemented in a container and tested "on-the-fly". If exported API's work, the whole application would continue to function. This has led to new development/deployment models like "Continuous integration (CI) and continuous delivery (CD)" (CI/CD). Many major players like amazon, FB etc are already using this model.

Dockerized microservices "talk" to each other through a network. From a networking standpoint, a container should:

1. Communicate with other containers on the same host- Docker Bridge. This is the docker0 interface.

2. Communicate with the outside world - Leverage the host's network to communicate with the outside world with docker Host Networking.

3. Containers on other hosts- Overlay (VxLAN) driver is used for this. This is used by Docker Swarm and Kubernetes control plane.

4. Finally, there is a MacVLan mode in docker for legacy applications. You need to designate a physical interface on the Docker host for MacVLAN mode.

Before I dive into Docker networking, let's talk about an important component that makes Docker networking possible. This is IP-netns or IP networking namespace which is a component of the Linux kernel.

Note: Netns is very similar to an IP VRF used in many routers/switches. Many Network Operating Systems utilize ip-netns for their VRF implementation one way or other.

A networking device can be a part of any one IP namespace. In the Docker world this means, the container network interface belongs to its own namespace, and host NICs operate in a different namespace. But how do containers in the namespace "talk" to the outside world?

This question brings us to the next important component of Linux that allows devices in namespaces to communicate with each other - this is Virtual Ethernet Device. Quoting from Linux manual page for vETH

" The veth devices are virtual Ethernet devices. They can act as tunnels between network namespaces to create a bridge to a physical network device in another namespace, but can also be used as standalone network devices."

In simple terms- this is a virtual "cable" that connects containers in"Namespace1" to physical NIC which is in a different namespace.

Docker internally uses this capability to implement a "Bridge" interface called "Docker0". Docker0 allows the web, application, and DB server to talk to each other. The web, application, and DB server belong to the same namespace/subnet and are connected to the Docker0 interface by default.

Note: You can create your own bridge interfaces and associate them  with containers.

To summarize, when you type the command

docker run -detach --name webfromrepo -p 80:80 wizardonwire/mycoolwebsite:latest

Following a sequence of steps happen internally

1. A New Network namespace is created.

2. A New Virtual Ethernet device is created. One end of this device is connected to eth0 (Docker bridge) and the other end is connected to the host physical NIC.

3. The loopback interface is created inside the container.

This allows, the "webfromrepo" container to talk to the app and DB server in the same namespace (assuming app and DB containers are created with default options). But it still cannot talk to the internet and the host's physical network.

To allow containers to communicate with the external network a "Network Address Translation" rule is created with the Docker0 bridge interface on one side and hosts physical interface IP on another. NAT allows 2 modes of operation:

• Client Mode: Containers can access the internet, but the outside world cannot access containers. This is the default mode when you do not specify the "-p" option.

• Server Mode: Outside world can access services inside the container. When executing"docker run -detach --name webfromrepo -p 80:80", the webfromrepo container is run in server mode and can be accessed from the outside network with the host IP address.

Finally, IPTABLES are used to enable NAT. "Post-routing" IPtable rule is used for "container" to "outside network" communication. Whereas, "Pre-routing" iptable rule is used for server mode communication (outside network to the container).

That's all for today folks, more coming up soon!!

P.S: Found this excellent, multipart article on microservices : https://www.nginx.com/blog/introduction-to-microservices/