Demystifying Docker Containers Internal and Breaking Myths
By: Rahul Sharma
Tags: Docker, Kubernetes, AWS, Linux, Containers

Demystifying Docker Containers Internal and Breaking Myths

In this post, we will see how the Docker and container internal works, and we will discuss a kind of a container’s image that we may have in our mind but actually, it’s something different.

Okay! If we Google the term “Docker containers” the images that we get in search is similar to this:

I know you will not find the exact same image but a similar type of image with some containers and white stripes on them or blue containers and so on. This is good for representation purposes and that’s how people use it to show everyone and many of us are satisfied with this understanding, that yeah! there is some container running on top of the operating system and they have a separate process and operating system altogether, at least as a starter you will think this. But what if I say, this is not the correct representation of containers running on your operating system? This representation changes our mindset to some totally different understanding.

Containers are nothing but just a process like some of your other processes that are running on top of your operating system! But the difference is that these processes are special processes that are created by some typical Linux technology.

For example, your top or list (ls) or listing process command (ps) are processes that are regular Linux process but when we say containerized processes they are basically created by LXC, LXD, LibContainers, LibVirt, and these library uses three Linux technology such has Cgroups, Namespaces, and SELinux, other than this the process created uses all the similar scheduling, drivers, etc.. similar to a normal process the only difference is these are created by using a library which makes these container processes to start.

So before docker existed the Linux containers were already there, now you may ask what Docker did new for us? Well, it has two parts a local daemon and an API server that sits in your system(or API in a remote system). The local daemon has a simple CLI/REST interface and it talks to the API server and the API server talks to the various libraries that we discussed above. Docker has support for images which made things easy for us, now we have OCI format which is a common format agreement between industry so as multiple organizations can use and contribute using the same image standard, some of the examples is Amazon ECR and DockerHub, etc. these are used to store the images which we built and deploy.

So if we try to understand more internals, Docker on receiving a request from daemon will make a call to Containerd and Containerd creates instances of runc using the LibContainer library, also this library will talk to Linux Kernal to make separate namespaces and creates a secret in SELinux for these containerized processes.If you are thinking about the container image which contains alpine, ubuntu, etc. Well, that filesystem is mounted for you when these special processes are started! The explanation is done at a high level to understand the concept behind the containers. That’s all, I hope this post may help you to gain internal insight into what a container actually is!