Docker's Internal Architecture: How it actually works?

Driven by my curious nature, I became interested in understanding the inner workings of Docker. After conducting some research, I discovered that Docker leverages the underlying Linux kernel to virtualize only the application or user space, rather than the entire operating system. However, I remained puzzled about how Docker functions on Windows, given the absence of a Linux kernel.

Interestingly, I have found that “Docker on Windows” actually utilizes the “Linux kernel on windows” to work. This seems confusing right? Let’s dig in to explore more.?

Note: it is recommended to open the architecture diagram I have created, alongside, to better understand this article.

There is a Linux Kernel inside Windows:

Did you know that? Windows 10 and above basically contains a very lightweight Linux Kernel known as WSL (Windows subsystem for Linux) which is the underlying technology that enables Docker to run Linux containers on windows. Latest version of WSL is WSL 2 which is actually a real Linux kernel running inside a lightweight virtual machine. When we install Docker Desktop on windows, we are actually installing 3 components on our windows system.?

• Docker Engine
• ContainerD - container runtime
• RunC - Low level container runtime?

Why containers?

Most of the people already know why we are using Docker or containerization technology but let’s refresh our concepts. Previously, there were two ways a developer can share code with other developers or the deployment team.?

1. They can share just the application’s code
2. They can share a complete Virtual machine??

First approach is convenient since the size of the application is much less than the VM but it creates the challenges of incompatible deployment environments, missing dependencies on deployment/production environments etc.?

Second approach was beneficial in the sense that the environment created by the developer in which the application can run, is also shared. But normally the size of VM is quite large normally in GB’s and sharing such a huge file is a headache.??

A VM basically consists of two things:?

• a virtual hard disk containing the OS (Kernel) and the user space programs (app developed by developer and supported dependencies)
• A metadata file containing information about the resources required for this VM (RAM, CPU etc.)

When a docker image is created, it eliminates the need for metadata file and underlying Kernel, so a docker image only consists of user space i-e the app packaged with its dependencies.?

When we run a docker image, it runs just like any other process - but this process runs isolated from all the other processes of the system. This isolated process is called a container.

Next time, whenever you come across the word container, just remember that it's just another process but running in an isolated environment.

But how exactly does docker achieve this isolation? Let’s read.

The Execution Process:

I am explaining things here in the context of docker on windows, but just remember that in Linux there is no WSL underneath since we have a linux kernel already.

When we run a process inside Linux, it makes use of system calls to perform tasks. Think of system calls as requests made by the process to the Linux kernel. A process needs access to resources, it makes a system call. A process needs to read a file or do an I/O operation, it makes a system call.?

An example is shown in the drawing below, where in order to read a file, the process actually makes the open() system call to the kernel.

You can view system calls a process is making by using strace command. For example, you can view which system calls are made by ls command by simply doing:

strace ls        

When we run a docker command to run a container (a process or an app), the command is first interpreted by Docker engine, which receives the command and hands it over for further execution to the containerD runtime. ContainerD is a high level container management tool responsible for managing the container lifecycle such as creating, starting, stopping and deleting containers. But containerD can’t do it alone, it utilizes the low-level runC container runtime to achieve this.?

runC basically receives the command and creates the corresponding system call to the underlying linux kernel.

According to the diagram below, when a command to create a container is issued it first makes the clone() system call to the kernel. This system call is responsible for creating a linux namespace - consider linux namespace as an exact copy of the original linux kernel but separated from the original kernel.

So everything inside that container is actually running inside that namespace and not in the original kernel space.?

All follow up system calls made by the process are actually made to this namespace.?

Full architecture diagram is available at

https://miro.com/app/board/uXjVN-YcBlo=/?share_link_id=263943070854?

Conclusion:

Keep in mind that a container means process so it will run as long as the process is running. If the process dies or stops for whatever reason, the container will be no longer available. There is no concept of running a container with just the OS only. Take the example of an ubuntu container. If you just try to run the base OS without any command:

docker run ubuntu        

It will die immediately since there is no app or process running. But if we do it like:

docker run -it ubuntu bash        

It will run the “bash” process in interactive terminal mode and thus our container will stay alive.

References:

• Docker Documentation
• Architecting Containers
• Containers: The Story of isolation