Command Palette
Search for a command to run...
Comments
Join the discussionNo comments yet. Be the first to comment.
containers
Part 1 of 1
Search for a command to run...
No comments yet. Be the first to comment.
In this blog post, I will cover the fundamentals of containers and the magic behind them, and open paths to researching the mechanisms behind containers in the future.
To understand what a container is, we need to ask ourselves five main questions:
What is a process?
Why do we need a container?
How to run a container?
What is a container? And what is it actually made of?
How is a container being created under the hood?
In order to truly understand containers, we need to start low, which is to first understand what a process is.
Simply put, a process is an executing instance of a program. It holds the state, memory mapping, and resources required for the CPU to execute the code. (There is much more to talk about what a process is, but that would be enough for our discussion.) For our aiming goal, we will focus only on a specific feature of Linux's process that makes containers happen.
Let's take a look at the Linux source code of the process found here:
We can find a row that reveals the powerful feature that is responsible for containers:
/* Namespaces: */
struct nsproxy *nsproxy;
Introducing Namespaces.
What are namespaces? Let's look at the source code that will reveal a little bit more. include/linux/nsproxy.h#L32
struct nsproxy {
refcount_t count;
struct uts_namespace *uts_ns;
struct ipc_namespace *ipc_ns;
struct mnt_namespace *mnt_ns;
struct pid_namespace *pid_ns_for_children;
struct net *net_ns;
struct time_namespace *time_ns;
struct time_namespace *time_ns_for_children;
struct cgroup_namespace *cgroup_ns;
};
Remember this code, as we will understand it a bit later as we dive in.
Now let's get back to containers and connect the dots, as we explain what we see in the source code above.
Containers allow us to create a virtualized "bubble" of a thin, minimal machine to execute an application. The main purpose is to create an easy-to-ship environment of the application to production without worrying about dependencies and environment differences between development and production. The key is that we can control what will live inside the container bubble, which fits our application needs.
Let's say we want to run a simple nginx server that will run our application.
For the purpose of this tutorial, I use Docker Engine on WSL.
docker run --name my-nginx -p 8080:80 -d ubuntu/nginx
Here is our simple container running on our local machine.
go to: http://127.0.0.1:8080/ and voilà, we have our nginx container running on our local machine.
Start with the end in mind: a container is basically just a process. But an isolated one.
Let's get inside the container and explore a little bit of what it means.
docker exec -it my-nginx /bin/bash
Now we get a Bash shell inside the containers. Run the lsns command, and we get all the namespaces that manage the container:
Looks familiar, right? We remember the struct nsproxy above. Let's break things down to what namespaces are.
time - A relatively new namespace. Usually, containers share the same kernel time.
cgroup - Creates the "bubble" around resource management. By hiding the host's actual tree hierarchy, it tricks the container into thinking it sits at the absolute 'Root' of the system.
user - each container can get its own root user or regular user without conflicting with the local host machine.
net - each container can have a different network interface and IP address.
ipc - Inter-Process Communication, it’s about whether processes can communicate with each other or see each other's data.
mnt - Mount, responsible for the isolation of the file system of each container, the mount point where each container starts its root file system in the host machine.
uts - Responsible for the hostname and domain name.
pid - Just like a regular OS boot, the container gets its own isolated PID tree starting from 1.
We can see in the images above that the container has its own hostname, its own 'root' user, its own new network interface and IP address, and it can't see the files above its '/' root file, which tells us something: Docker takes care of these configurations by default, and maybe we can change and control some of them.
All hints lead to this point. As we mentioned, a container is an isolated process. The isolation is being implemented via namespaces, which control the aspects of how isolated the container will be. Can it share the same IP address and network interface as the host or other containers? Share hostname? Can it see other processes? Share file system? and many other questions that regard the security elements of containers. In this blog post, we used Docker to create a basic container, and we saw that Docker takes care of some defaults in isolation, such as network, hostname, and filesystem.
If a container is just a process, it means we can see it on our local machine. To prove this point, I will switch to my VMWare Ubuntu machine (because WSL on Windows makes things complicated for Docker)
First, we use the Docker 'inspect' command to find the container's "real" Pid in the eyes of the operating system, and then we verify that the same process is shown in the local host machine.
In the context of the code we saw earlier, every process being created in the OS shares the same features, such as file system, network interface, host name, etc., meaning all these (or most) structs point to the same resources, while when creating a container, these namespaces point to different resources.
Let's see it with our own eyes and compare from both sides, the OS side and the container side. Let's open two terminals and analyze what we see.
Run the following command in one of them:
docker exec -it my-nginx /bin/bash
Now let's compare:
The first screenshot is the container perspective of the world:
And here is the OS perspective:
Comparing the two, we can see the differences:
(notice that I changed to a root user in my local machine), Both have root user, different hostname. The network is an interesting part. We can see that inside the container, we have the eth0@if4 interface and IP address 172.17.0.2/16 looks normal, right? But when we see what happens in the OS, we see something new.
Let's explain: what Docker does in order to transfer network data inside and outside containers is by using DNAT.
It creates two new network interfaces: a default gateway named docker0 and another eth0@if4 inside the container.
It creates a 'virtual cable' named veth<id>@if2 responsible for connecting both interfaces and delivering packets between the container and the host bridge.
But to actually translate network addresses and map ports without conflict, Docker uses Linux iptables to create the DNAT.
run: sudo iptables -t nat -L -n on the host and see port mapping in action.
In regard of the file system, we can see that running cat /proc/self/cgroup in both terminals, we will also get different answers. The container shows that there is nothing above, and it lives in the root files, while the OS shows us the hard, messy truth of the file system that it lives inside the Docker file system created in order to create the virtual isolation. We can actually peek inside the container file system from the outside, in the host.
Let's create a file in the container in the root folder touch my-container-file.txt and...
Let's summarize our main takeaway here: A container is just an illusion created by the OS, while all along it's just an isolated process being manipulated via namespaces.
Final Note:
There are other Linux features responsible for creating what we call a 'Container'. Here is a diagram that will give you a hint for future research, as I hope to cover them in the future.
Today, we have scratched the surface of the most fundamental Linux feature, 'namespaces', which allow us to create the magic called 'Containers.'
Here is something to think about: what if you could control all these isolation features? Or even build our own container using the same namespace feature?