Containers: How They Work Under the Hood and Why They’re Taking Over the Data Science World | by Dimitris Poulopoulos | Jan, 2023
A Beginner’s Guide to Understanding the Magic of Docker
Docker has taken the world by storm, and for a good reason. Lightweight, portable containers make it easy to package and deploy applications, ensuring they run consistently and reliably on any platform.
But what exactly are Docker containers, and how do they work under the hood? A Google search will give you hundreds of articles about how containers compare to Virtual Machines (VMs), but this does not answer the question. What does Docker do? Is it something they invented? Can we create containers without Docker or Podman, or any other platform you may use?
This series of articles will break down the concept of containers and explain how Docker uses them to revolutionize how we build and deploy software. We’ll see what Linux namespaces are, how you can use cgroups to limit the resources a container can dip into, and why overlay file systems play a critical role in creating container-like environments.
Are you ready to understand the magic of Docker containers? By the end of this series, you will be able to create your own container-like environments without Docker.
Learning Rate is a newsletter for those who are curious about the world of MLOps. MLOps is thebroader field that strives to bring ML models to production in an efficient and rerpoducible way. Containers play a crucial role in the pipeline. If you want to learn more about topics like this subscribe here. You’ll hear from me on the first Saturday of every month with updates and thoughts on the latest MLOps news and articles!
Let’s move away from Docker a bit and start discussing the key components that make up Linux Containers. Linux containers are a powerful technology that allows you to run multiple sandboxed processes on a single host.
These processes share the host’s kernel but have their own user space, meaning that they have their own set of libraries, dependencies, and runtime environments. There are three key components that make up a Linux container: namespaces, control groups (cgroups), and overlay file systems.
Namespaces is a kernel feature that allows you to create isolated environments within a single Linux system. Each namespace has its own view of the system, meaning that processes within a namespace are unaware of the processes running in other namespaces.
Control groups (cgroups) are kernel features that allow you to manage and allocate resources, such as CPU, memory, and I/O bandwidth, to groups of processes.
Overlay file systems allow you to stack one file system on top of another, creating a single logical file system. We’ll see why this is important in later articles.
This is a high-level view of what each component that makes up a container does. In this article, we will talk more about namespaces. In later articles, we will discuss how cgroups and the overlay file systems complete the picture.
Namespaces are kernel features that allow you to create isolated environments within a single Linux system. Each namespace has its own view of the system, meaning that processes within a namespace are unaware of the processes running in other namespaces. Namespaces are used to create the isolated environments in which containers run.
Let’s try a simple analogy: a namespace in Linux is like a room in a house. Each room has its own things inside of it, and you can only see and use the things in the room you are in. But there might be other rooms in the house with different things inside of them, and you can’t see or use those things unless you go into those rooms.
In Linux, each process (which is like a program that is running on the computer) can be in a different namespace. So if you have two processes in different namespaces, they can each have their own separate things (like their own list of files or their own network connections), and they won’t be able to see or use each other’s things. This is useful for keeping different processes separate from each other and for making sure that one process can’t interfere with another process.
Types of namespaces
There are several different types of namespaces in Linux, including the following:
PIDnamespace: Isolates the process ID space so that processes in differentPIDnamespaces can have the samePIDwithout conflicting with each other.netnamespace: Isolates the network stack, including network interfaces, IP addresses, and routing tables.mountnamespace: Isolates the mount points so that processes in different mount namespaces can have their own private file systems that are separate from each other and from the host file system.IPCnamespace: Isolates interprocess communication resources, such as System VIPCobjects and POSIX message queues.utsnamespace: Isolates the hostname.
Next, let’s create our own PID namespace.
Create your own namespace
So, let’s create a new PID namespace and run the bash command in it. First, let’s explore the current state of our system using the pstree command. I work in a VM running Ubuntu in VirtualBox, so the command returns the following output:
pstree — Image by AuthorHere we see the way processes in Linux are structured. Every process has a parent except the first process. Typically the init process (usually systemd) will be PID 1 and has no parent. To learn more about systemd read the following story:
If we create a new PID namespace, we expect to have a new tree structure with the processes that belong to this namespace. Moreover, the command we will run first in this namespace will take the PID 1, which will be mapped to a higher PID number in the host. Let’s see that in action:
unshare -ipf
The unshare command is the one you want to use to create new namespaces. In this context and with these flags, it will create a new PID namespace (the p flag) and a new IPC namespace (the i flag).
Now, if you try to get the processes running in this namespace, you should be able to see bash as PID 1, right? Let’s check this:
ps -ef
This is the result I get in my system:
So, what is going on? Why do I still see the init process as PID 1? The Linux kernel uses the /proc file system to get data about the running processes. Thus, we’re missing a component here. We need to also create a new mount namespace and mount a new /proc file system because now we’re getting this information from the default mount namespace.
To resolve this error, we will use the --mount-proc flag, which creates a new mount namespace and mounts a new /proc file system. Type exit to get out of the PID namespace you created and run the following command:
unshare -ipf --mount-proc
Now, if you run ps -ef again you’ll get what you were looking for:
Congratulations, you created a new PID namespace. This is the first step to understanding how containers work under the hood. Of course, it helps if you try to run something more meaningful than bash, but keep in mind that you have created an isolated view of your system. To exit this view, just type exit in your terminal.
Docker containers are a revolutionary technology that has taken the world by storm. These lightweight, portable containers make it easy to package and deploy applications, ensuring that they run consistently and reliably on any platform. But what exactly are Docker containers, and how do they work under the hood?
In this article, we discussed about the key components that make up a Linux container and looked at namespaces in detail. Next, we’ll take a deep dive into cgroups. Our goal is to create a container-like environment without using Docker!
My name is Dimitris Poulopoulos, and I’m a machine learning engineer working for Arrikto. I have designed and implemented AI and software solutions for major clients such as the European Commission, Eurostat, IMF, the European Central Bank, OECD, and IKEA.
If you are interested in reading more posts about Machine Learning, Deep Learning, Data Science, and DataOps, follow me on Medium, LinkedIn, or @james2pl on Twitter.
Opinions expressed are solely my own and do not express the views or opinions of my employer.
A Beginner’s Guide to Understanding the Magic of Docker
Docker has taken the world by storm, and for a good reason. Lightweight, portable containers make it easy to package and deploy applications, ensuring they run consistently and reliably on any platform.
But what exactly are Docker containers, and how do they work under the hood? A Google search will give you hundreds of articles about how containers compare to Virtual Machines (VMs), but this does not answer the question. What does Docker do? Is it something they invented? Can we create containers without Docker or Podman, or any other platform you may use?
This series of articles will break down the concept of containers and explain how Docker uses them to revolutionize how we build and deploy software. We’ll see what Linux namespaces are, how you can use cgroups to limit the resources a container can dip into, and why overlay file systems play a critical role in creating container-like environments.
Are you ready to understand the magic of Docker containers? By the end of this series, you will be able to create your own container-like environments without Docker.
Learning Rate is a newsletter for those who are curious about the world of MLOps. MLOps is thebroader field that strives to bring ML models to production in an efficient and rerpoducible way. Containers play a crucial role in the pipeline. If you want to learn more about topics like this subscribe here. You’ll hear from me on the first Saturday of every month with updates and thoughts on the latest MLOps news and articles!
Let’s move away from Docker a bit and start discussing the key components that make up Linux Containers. Linux containers are a powerful technology that allows you to run multiple sandboxed processes on a single host.
These processes share the host’s kernel but have their own user space, meaning that they have their own set of libraries, dependencies, and runtime environments. There are three key components that make up a Linux container: namespaces, control groups (cgroups), and overlay file systems.
Namespaces is a kernel feature that allows you to create isolated environments within a single Linux system. Each namespace has its own view of the system, meaning that processes within a namespace are unaware of the processes running in other namespaces.
Control groups (cgroups) are kernel features that allow you to manage and allocate resources, such as CPU, memory, and I/O bandwidth, to groups of processes.
Overlay file systems allow you to stack one file system on top of another, creating a single logical file system. We’ll see why this is important in later articles.
This is a high-level view of what each component that makes up a container does. In this article, we will talk more about namespaces. In later articles, we will discuss how cgroups and the overlay file systems complete the picture.
Namespaces are kernel features that allow you to create isolated environments within a single Linux system. Each namespace has its own view of the system, meaning that processes within a namespace are unaware of the processes running in other namespaces. Namespaces are used to create the isolated environments in which containers run.
Let’s try a simple analogy: a namespace in Linux is like a room in a house. Each room has its own things inside of it, and you can only see and use the things in the room you are in. But there might be other rooms in the house with different things inside of them, and you can’t see or use those things unless you go into those rooms.
In Linux, each process (which is like a program that is running on the computer) can be in a different namespace. So if you have two processes in different namespaces, they can each have their own separate things (like their own list of files or their own network connections), and they won’t be able to see or use each other’s things. This is useful for keeping different processes separate from each other and for making sure that one process can’t interfere with another process.
Types of namespaces
There are several different types of namespaces in Linux, including the following:
PIDnamespace: Isolates the process ID space so that processes in differentPIDnamespaces can have the samePIDwithout conflicting with each other.netnamespace: Isolates the network stack, including network interfaces, IP addresses, and routing tables.mountnamespace: Isolates the mount points so that processes in different mount namespaces can have their own private file systems that are separate from each other and from the host file system.IPCnamespace: Isolates interprocess communication resources, such as System VIPCobjects and POSIX message queues.utsnamespace: Isolates the hostname.
Next, let’s create our own PID namespace.
Create your own namespace
So, let’s create a new PID namespace and run the bash command in it. First, let’s explore the current state of our system using the pstree command. I work in a VM running Ubuntu in VirtualBox, so the command returns the following output:
pstree — Image by AuthorHere we see the way processes in Linux are structured. Every process has a parent except the first process. Typically the init process (usually systemd) will be PID 1 and has no parent. To learn more about systemd read the following story:
If we create a new PID namespace, we expect to have a new tree structure with the processes that belong to this namespace. Moreover, the command we will run first in this namespace will take the PID 1, which will be mapped to a higher PID number in the host. Let’s see that in action:
unshare -ipf
The unshare command is the one you want to use to create new namespaces. In this context and with these flags, it will create a new PID namespace (the p flag) and a new IPC namespace (the i flag).
Now, if you try to get the processes running in this namespace, you should be able to see bash as PID 1, right? Let’s check this:
ps -ef
This is the result I get in my system:
So, what is going on? Why do I still see the init process as PID 1? The Linux kernel uses the /proc file system to get data about the running processes. Thus, we’re missing a component here. We need to also create a new mount namespace and mount a new /proc file system because now we’re getting this information from the default mount namespace.
To resolve this error, we will use the --mount-proc flag, which creates a new mount namespace and mounts a new /proc file system. Type exit to get out of the PID namespace you created and run the following command:
unshare -ipf --mount-proc
Now, if you run ps -ef again you’ll get what you were looking for:
Congratulations, you created a new PID namespace. This is the first step to understanding how containers work under the hood. Of course, it helps if you try to run something more meaningful than bash, but keep in mind that you have created an isolated view of your system. To exit this view, just type exit in your terminal.
Docker containers are a revolutionary technology that has taken the world by storm. These lightweight, portable containers make it easy to package and deploy applications, ensuring that they run consistently and reliably on any platform. But what exactly are Docker containers, and how do they work under the hood?
In this article, we discussed about the key components that make up a Linux container and looked at namespaces in detail. Next, we’ll take a deep dive into cgroups. Our goal is to create a container-like environment without using Docker!
My name is Dimitris Poulopoulos, and I’m a machine learning engineer working for Arrikto. I have designed and implemented AI and software solutions for major clients such as the European Commission, Eurostat, IMF, the European Central Bank, OECD, and IKEA.
If you are interested in reading more posts about Machine Learning, Deep Learning, Data Science, and DataOps, follow me on Medium, LinkedIn, or @james2pl on Twitter.
Opinions expressed are solely my own and do not express the views or opinions of my employer.
Denial of responsibility! Techno Blender is an automatic aggregator of the all world’s media. In each content, the hyperlink to the primary source is specified. All trademarks belong to their rightful owners, all materials to their authors. If you are the owner of the content and do not want us to publish your materials, please contact us by email – [email protected]. The content will be deleted within 24 hours.