{"id":91905,"date":"2020-08-20T07:42:23","date_gmt":"2020-08-20T05:42:23","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/chto-takoe-docker-kratkij-ekskurs-v-istoriyu-i-osnovnye-abstrakczii"},"modified":"2020-08-20T07:42:23","modified_gmt":"2020-08-20T05:42:23","slug":"chto-takoe-docker-kratkij-ekskurs-v-istoriyu-i-osnovnye-abstrakczii","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/chto-takoe-docker-kratkij-ekskurs-v-istoriyu-i-osnovnye-abstrakczii","title":{"rendered":"What is Docker: a brief overview of the history and key abstractions","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

On August 10, Slyurm launched a video course on Docker<\/a><\/noindex>, where we cover it thoroughly \u2014 from basic abstractions to network parameters. <\/p>\n

<\/p>\n

In this article, we will discuss the history of Docker and its primary abstractions: Image, CLI, Dockerfile. The lecture is aimed at beginners, so it is unlikely to be interesting for experienced users. There will be no blood, appendices, or deep dives. Just the basics.<\/p>\n

<\/p>\n

\"What<\/p>\n

<\/a><\/noindex><\/p>\n

What is Docker<\/h2>\n

<\/p>\n

Let\u2019s look at Docker\u2019s definition from Wikipedia.<\/p>\n

<\/p>\n

Docker is software for automating the deployment and management of applications in environments that support containerization.<\/p><\/blockquote>\n

This definition doesn\u2019t clarify much. Particularly, it\u2019s unclear what \u2018in environments that support containerization\u2019 means. To understand it, we need to go back in time. Let\u2019s start from what I term the 'Monolithic Era.'<\/p>\n

<\/p>\n

Monolithic Era<\/h2>\n

<\/p>\n

The Monolithic Era was the early 2000s when all applications were monolithic, with a plethora of dependencies. Development took a long time. At that time, there weren't many servers; we all knew them by name and monitored them closely. There's a funny analogy:<\/p>\n

\n

\r\n \"Play\r\n
<\/div>\r\n <\/div><\/center><\/p>\n

Pets \u2014 these are household animals. In the monolithic era, we treated our servers like pets, nurturing and cherishing them, dusting off any debris. To manage resources better, we used virtualization: taking one server and splitting it into several virtual machines to ensure environment isolation.<\/p>\n

<\/p>\n

Hypervisor-based Virtualization Systems<\/h2>\n

<\/p>\n

Everyone has surely heard of virtualization systems: VMware, VirtualBox, Hyper-V, Qemu KVM, etc. They provide application isolation and resource management, but they also have downsides. To enable virtualization, a hypervisor is required. And a hypervisor brings resource overhead. Moreover, the virtual machine itself is usually quite bulky \u2014 a heavy image containing the operating system, Nginx, Apache, and possibly MySQL. The image is large and cumbersome to operate with. Consequently, working with virtual machines can be slow. To address this issue, virtualization systems at the kernel level were created.<\/p>\n

<\/p>\n

Kernel-Level Virtualization Systems<\/h2>\n

<\/p>\n

Kernel-level virtualization is supported by systems such as OpenVZ, Systemd-nspawn, LXC. A prominent example of such virtualization is LXC (Linux Containers). <\/p>\n

<\/p>\n

LXC is an operating system-level virtualization system for running multiple isolated instances of the Linux operating system on a single node. LXC does not use virtual machines but creates a virtual environment with its own process space and network stack.<\/p>\n

<\/p>\n

Essentially, LXC creates containers. What is the difference between virtual machines and containers?<\/p>\n

<\/p>\n

\"What<\/p>\n

<\/p>\n

A container is not suitable for isolating processes: kernel-level virtualization systems have vulnerabilities that allow escaping from the container to the host. Therefore, if you need to isolate something, it is better to use a virtual machine.<\/p>\n

<\/p>\n

The differences between virtualization and containerization can be seen in the diagram.
\nThere are hardware hypervisors, hypervisors on top of the OS, and containers. <\/p>\n

<\/p>\n

\"What<\/p>\n

<\/p>\n

Hardware hypervisors are great if you really want to isolate something. Because they offer the ability to isolate at the level of memory pages and processors.<\/p>\n

<\/p>\n

There are hypervisors as programs, and there are containers, which we will discuss next. In containerization systems, there is no hypervisor, but there is a Container Engine that creates and manages containers. This is a lighter-weight solution, so due to its operation with the kernel, the overhead is lower or nonexistent.<\/p>\n

<\/p>\n

\n

What is used for kernel-level containerization<\/h2>\n

The main technologies that allow creating a container isolated from other processes are Namespaces and Control Groups.<\/p>\n

Namespaces: PID, Networking, Mount, and User. There are others, but for simplicity, we will focus on these.<\/p>\n

The PID Namespace restricts processes. When we create a PID Namespace and place a process in it, it becomes PID 1. Normally, in systems, PID 1 is either systemd or init. Accordingly, when we place a process into a new namespace, it too receives PID 1.<\/p>\n

The Networking Namespace allows limiting\/isolate the network and to place its own interfaces within. Mount is a restriction on the file system. User is a restriction on users.<\/p>\n

Control Groups: Memory, CPU, IOPS, Network \u2014 there are about 12 settings in total. They are also called Cgroups.<\/p>\n

Control Groups manage resources for the container. Through Control Groups, we can specify that a container should not consume more than a certain amount of resources.<\/p>\n

For containerization to work effectively, additional technologies are used: Capabilities, Copy-on-write, and others.<\/p>\n

Capabilities refer to defining what a process is allowed to do and what it is not. At the kernel level, these are simply bitmaps with numerous parameters. For example, the root user has full privileges and can do anything. A time server can change the system time: it has capabilities for the Time Capsule, and that's it. Privileges allow for flexible configurations to set restrictions on processes, thereby enhancing security.<\/p>\n

The Copy-on-write system enables us to work with Docker images more efficiently.<\/p>\n

At present, Docker has compatibility issues with Cgroups v2; therefore, this article focuses on Cgroups v1.<\/em><\/p><\/blockquote>\n

But let's return to the history. <\/p>\n

<\/p>\n

When virtualization systems at the kernel level emerged, they began to be actively adopted. The overhead for the hypervisor disappeared, but some problems remained:<\/p>\n

<\/p>\n