Microsurvival Part 2: Divide and containerize
Appy, a young application trying to grow, gets further lessons in isolation, namespaces, and control groups that can help him and his parents as he…
Note: If you didn’t already read part one, go there first for the beginning of young Appy’s story.
You know Appy, I was always fascinated by the term “Divide and Conquer” (or divide et impera if you like fancy talk). It is such a great idea that it is used in politics and in computer science. You don’t see these two fields mentioned in the same sentence too often, do you? Well, the concept of breaking up big headaches into smaller headaches can apply to a lot of things, whether it be armies, factions, algorithms, or Hawaiian pizza.
Last time we talked, I mentioned how you were monolithic while growing up, and you then were divided into processes that were put in containers and became easier to manage. Anyway, do you remember where we stopped? How container isolation is possible?
Mechanisms to make isolation happen
I see… Well, container isolation is easy, but you need to pay attention though. Container isolation of processes is possible due to two mechanisms: Linux namespaces and Linux control groups (cgroups). I want to start with Linux namespaces but before that, I want to be sure about something. You do have knowledge about Linux systems, right? Wow, that is a lot of coughing… I guess that’s a “no” then. I will just mention the relevant information.
Typically, a Linux system has one single namespace, and all the resources belong to that namespace, including file systems, network interfaces, process IDs, and user IDs. Now if we run one of your processes, we run it inside one of these namespaces. The process is only able to see the resources inside the same namespace. Easy, right?
Now it can get a bit complex, because we have different kinds of namespaces like:
- Mount (mnt)
- Process ID (pid)
- Network (net)
- Inter-process communication (ipc)
- User ID (user)
Each of these namespaces isolate a specific group of resources, so a process belongs to one namespace of each kind. Your parents will probably tell you more about what kind of resources they would isolate and how, but I’ll give you a small example, if we give each of your processes a different UTS namespace, it will be as if these different processes are running on different machines because they see different local host names!
How cool is that? Yeah, I know you want to learn more about them, but for now, I think this is enough to give you an idea of how they would isolate processes running in containers.
Okay, Appy, now to complete the container isolation, we need to limit the amount of system resources that each container can consume. This is where cgroups, a Linux kernel feature, comes in play. It limits the processes’ resource usage, whether CPU, memory, or network bandwidth. A process can’t use more than the configured amount so it cannot hog other processes’ resources.
How about it? I told you that it’s going to be easy to understand container technologies. They have been around for some time now.
Containers are not new, but they became more famous when Docker was introduced. Docker simplified the whole process of packaging the application with all its libraries, dependencies, and a whole OS file system that the application runs on. All that in a small, package that can be moved to any machine running Docker to provision the application.
Well, not any machine. There are some limitations. For example, if we containerize one of your applications built for x86 architecture, we can’t expect a machine with an ARM architecture to run that application just because it also runs Docker. We might need a virtual machine to solve that problem.
Hmm… We still have some time before I head out to work, but I will keep it short and tell you about the main concepts of Docker for now. We have images, registries, and containers. Images are where we can package one of your applications with its environment, and other metadata. We build the image and run it on the same computer or we can push — upload — it to a Registry. Registries are like repositories that allow us to store our Docker images and easily share them with other people or computers. We can also pull — download — the image from the registry on another computer. Docker containers are just normal containers but based on a Docker image, and it will run on the host running Docker. Of course, it will be isolated from the other containers — or processes — and the host machine.
Here’s a picture I made that shows the Docker image, the registry, and the container:
Until next time
Okay, I really need to leave now, but let me know what your parents think of this. I will talk to you about Kubernetes and an example that your parents can try out on the IBM Cloud Kubernetes Service sometime later. Until then, stay stable!
A previous version of this post was published on Medium.