In the virtualization paradigm, the hypervisor emulates computing resources and provides a virtualized environment called a VM to install the operating system and applications on top of it. Whereas, in the case of the container paradigm, a single system (bare metal or virtual machine) is effectively partitioned to run multiple services simultaneously without interfering with each other. These services must be isolated from each other in order to prevent them from stepping on each other's resources or dependency conflict (also known as dependency hell). The Docker container technology essentially achieves process-level isolation by leveraging the Linux kernel constructs, such as namespaces and cgroups, particularly, the namespaces. The Linux kernel provides the following five powerful namespace leavers to isolate the global system resources from each other. These are the Interprocess Communication (IPC) namespaces used to isolate the interprocess communication resources:
• The network namespace is used to isolate networking resources, such as the network devices, network stack, port number, and so on
• The mount namespace isolates the filesystem mount points
• The PID namespace isolates the process identification number
• The user namespace is used to isolate the user ID and group ID
• The UTS namespace is used to isolate the hostname and the NIS domain name
These namespaces add an additional level of complexity when we have to debug the services running inside the containers, which we will learn more in detail in the next chapter.
In this section, we will discuss how the Docker engine provides process isolation by leveraging the Linux namespaces through a series of practical examples, and one of them is listed here:
1. Start by launching an ubuntu container in an interactive mode using the docker run subcommand, as shown here:
$ sudo docker run -it --rm ubuntu /bin/bash root@93f5d72c2f21:/#
2. Proceed to find the process ID of the preceding container 93f5d72c2f21, using the docker inspect subcommand in a different terminal:
$ sudo docker inspect \
--format "{{ .State.Pid }}" 93f5d72c2f21 2543
Apparently, from the preceding output, the process ID of the container 93f5d72c2f21 is 2543.
3. Having got the process ID of the container, let's continue to see how the process associated with the container looks in the Docker host, using the ps command:
$ ps -fp 2543
UID PID PPID C STIME TTY TIME CMD root 2543 6810 0 13:46 pts/7 00:00:00 /bin/bash
Amazing, isn't it? We launched a container with /bin/bash as its command, and we have the /bin/bash process in the Docker host as well.
4. Let's go one step further and display the /proc/2543/environ file in the Docker host using the cat command:
$ sudo cat -v /proc/2543/environ
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/
bin^@HOSTNAME=93f5d72c2f21^@TERM=xterm^@HOME=/root^@$
In the preceding output, HOSTNAME=93f5d72c2f21 stands out from the other environment variables because 93f5d72c2f21 is the container ID, as well as the hostname of the container, which we launched previously.
5. Now, let's get back to the terminal, where we are running our interactive container 93f5d72c2f21, and list all the processes running inside this container using the ps command:
root@93f5d72c2f21:/# ps -ef
UID PID PPID C STIME TTY TIME CMD root 1 0 0 18:46 ? 00:00:00 /bin/bash root 15 1 0 19:30 ? 00:00:00 ps -ef
Surprising, isn't it? Inside the container, the process ID of the bin/bash process is 1, whereas outside the container, in the Docker host, the process ID is 2543. Besides, the Parent Process ID (PPID) is 0 (zero).
In the Linux world, every system has just one root process with the PID 1 and PPID 0, which is the root of the complete process tree of that system. The Docker framework cleverly leverages the Linux PID namespace to spin a completely new process tree; thus, the processes running inside a container have no access to the parent process of the Docker host. However, the Docker host has a complete view of the child PID namespace spun by the Docker engine.
The network namespace ensures that all containers have independent network interfaces on the host machine. Also, each container has its own loopback interface.
Each container talks to the outside world using its own network interface. You will be surprised to know that the namespace not only has its own routing table, but also has its own iptables, chains, and rules. The author of this chapter is running three containers on his host machine. Here, it is natural to expect three network interfaces for each container. Let's run the docker ps command:
$ sudo docker ps
41668be6e513 docker-apache2:latest "/bin/sh -c 'apachec 069e73d4f63c nginx:latest "nginx -g '
871da6a6cf43 ubuntu:14.04 "/bin/bash"
So here, three are three interfaces, one for each container. Let's get their details by running the following command:
$ ifconfig
veth2d99bd3 Link encap:Ethernet HWaddr 42:b2:cc:a5:d8:f3 inet6 addr: fe80::40b2:ccff:fea5:d8f3/64 Scope:Link UP BROADCAST RUNNING MTU:9001 Metric:1
veth422c684 Link encap:Ethernet HWaddr 02:84:ab:68:42:bf inet6 addr: fe80::84:abff:fe68:42bf/64 Scope:Link UP BROADCAST RUNNING MTU:9001 Metric:1
vethc359aec Link encap:Ethernet HWaddr 06:be:35:47:0a:c4 inet6 addr: fe80::4be:35ff:fe47:ac4/64 Scope:Link UP BROADCAST RUNNING MTU:9001 Metric:1
The mount namespace ensures that the mounted filesystem is accessible only to the processes within the same namespace. The container A cannot see the mount points of the container B. If you want to check your mount points, you need to first log in to your container using the exec command (described in the next section), and then go to /proc/mounts:
root@871da6a6cf43:/# cat /proc/mounts
rootfs / rootfs rw 0 0/dev/mapper/docker-202:1-149807
871da6a6cf4320f625d5c96cc24f657b7b231fe89774e09fc771b3684bf405fb / ext4 rw,relatime,discard,stripe=16,data=ordered 0 0 proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
Let's run a container with a mount point that runs as the Storage Area Network (SAN) or Network Attached Storage (NAS) device and access it by logging into the container. This is given to you as an exercise. I have implemented this in one of my projects at work.
There are other namespaces that these containers/processes can be isolated into, namely, user, IPC, and UTS. The user namespace allows you to have root privileges within the namespace without giving that particular access to processes outside the namespace. Isolating a process with the IPC namespace gives it its own interprocess communication resources, for example, System V IPC and POSIX messages. The UTS namespace isolates the hostname of the system.
Docker has implemented this namespace using the clone system call. On the host machine, you can inspect the namespace created by Docker for the container (with pid3728):
$ sudo ls /proc/3728/ns/
ipc mnt net pid user uts
In most industrial deployments of Docker, people are extensively using patched Linux kernels to provide specific needs. Also, a few companies have patched their kernels to attach arbitrary processes to the existing namespaces because they feel that this is the most convenient and reliable way to deploy, control, and orchestrate containers.