For some time now, a large part of the IT landscape has been talking only about “containers”, “microservices” and “Kubernetes.”<\/p>\n
But what exactly are containers and what technical basis are they based on?<\/p>\n
Simply put, a container is an isolated runtime environment for processes. There are various areas that can be separated – the most important being processes (pid), network (net), volumes \/ hard disks (mnt) and user \/ group IDs (user). <\/p>\n
The technology behind this is called “namespaces” and was first implemented in the Linux Kernel since version 2.4.19 (2002) and later expanded, but only since version 3.8 (2013) in userspace, i.e. meaningfully usable for users. In addition, the cgroups technology plays a major role here. This makes it possible to provide the separate areas with resources such as CPU and RAM, or to define them. <\/p>\n
A well-known and early implementation of these features is lxc (linux containers), which is still being developed today and implements these features close to the system.<\/p>\n
A namespace is a way to divide resources and objects into logical groups. You could also describe it as a system context in which a process is started. It is not a problem to create your own namespaces within a namespace for newly started processes. <\/p>\n
An example from daily practice:<\/p>\n
When a Linux host starts, an instance is created for each namespace type. The init process with PID 1 (usually systemd today) is then assigned to the instances accordingly. This is transparent and only of limited relevance for most users. This is because all system resources are available to these namespaces and new resources are initially assigned to them. <\/p>\n
To view a list of the namespaces currently running on the system, there is the tool In the following example, we see the initially created namespaces and the assignment of the init process.<\/p>\n A process can only ever be assigned to one namespace per type. For example, the process with PID 1 from the example above cannot be assigned an additional pid namespace. <\/p>\n The different types have no interactions or dependencies with each other. For example, you can assign a new process (e.g. a shell) only its own net-namespace. <\/p>\n To create a new namespace as a user, there is the tool The following is an example of how a container-like environment (in which all possible areas are separated from the host system) can be created manually.<\/p>\n To do this, we start a bash shell with the parameters shown as a normal user without root permissions.<\/p>\n As you can see, the process is now in an encapsulated area with its own IDs and network area. However, the entire hard disk configuration was also transferred to the new area, including the To correct this, a To leave the environment, simply type Control Groups (cgroups for short) are not a direct namespace, but allow processes to be grouped in a type of namespace and the available resources such as CPU and \/ or RAM to be limited or prioritized.<\/p>\n There is now an updated version of cgroups (cgroupsV2) in the kernel. However, this is probably only used productively by Fedora >= 31, as there are some incompatibilities with Docker here, but not with Podman. <\/p>\n However, the setup is somewhat more complex and will therefore not be explained here, but will be the subject of a separate article.<\/p>\n Further information can be found for those interested here<\/a> (cgroupsv1) and here<\/a> (cgroupsv2)<\/p>\n Each container contains all the components necessary for the operation of the binaries, such as libraries and binaries. However, the file system is not a separate hard disk or similar, but merely an archive that contains a directory tree.<\/p>\n This archive is then unpacked into a folder at the latest when a container is started and used as a new file system on this folder by means of an mnt namespace and Here is an example with the separated environment from the previous section.<\/p>\n First, we export the file system of the Postgres container as a tar archive and then unpack it into a subfolder.<\/p>\n Now we create a shell with its own namespaces again and execute the Finally, the This is of course only a quick overview of the technical framework of container technology, which is based on known features of the Linux kernel. At the latest when using container orchestration tools such as Kubernetes or okd, several layers of complexity are also added.<\/p>\nlsns<\/code>.<\/p>\n[root@buildah ~]# lsns -p1\n NS TYPE NPROCS PID USER COMMAND\n4026531835 cgroup 96 1 root \/usr\/lib\/systemd\/systemd --switched-root --system --deserialize 18\n4026531836 pid 96 1 root \/usr\/lib\/systemd\/systemd --switched-root --system --deserialize 18\n4026531837 user 95 1 root \/usr\/lib\/systemd\/systemd --switched-root --system --deserialize 18\n4026531838 uts 96 1 root \/usr\/lib\/systemd\/systemd --switched-root --system --deserialize 18\n4026531839 ipc 96 1 root \/usr\/lib\/systemd\/systemd --switched-root --system --deserialize 18\n4026531840 mnt 90 1 root \/usr\/lib\/systemd\/systemd --switched-root --system --deserialize 18\n4026531992 net 96 1 root \/usr\/lib\/systemd\/systemd --switched-root --system --deserialize 18\n<\/code><\/pre>\nunshare<\/code>. Using parameters, it is possible to specify which namespace types should be created for the process. <\/p>\n[podmanager@buildah ~]$ unshare --mount --uts --ipc --net --pid --fork --user --map-root-user \/bin\/bash\n\n[root@buildah ~]# id\nuid=0(root) gid=0(root) Gruppen=0(root) Kontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023\n\n[root@buildah ~]# ip a\n1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN group default qlen 1000\n link\/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00\n\n[root@buildah ~]# lsns\n NS TYPE NPROCS PID USER COMMAND\n4026531835 cgroup 3 952 root unshare --mount --uts --ipc --net --pid --fork --user --map-root-user \/bin\/bash\n4026531836 pid 1 952 root unshare --mount --uts --ipc --net --pid --fork --user --map-root-user \/bin\/bash\n4026532192 user 3 952 root unshare --mount --uts --ipc --net --pid --fork --user --map-root-user \/bin\/bash\n4026532193 mnt 3 952 root unshare --mount --uts --ipc --net --pid --fork --user --map-root-user \/bin\/bash\n4026532194 uts 3 952 root unshare --mount --uts --ipc --net --pid --fork --user --map-root-user \/bin\/bash\n4026532196 ipc 3 952 root unshare --mount --uts --ipc --net --pid --fork --user --map-root-user \/bin\/bash\n4026532198 pid 2 953 root \/bin\/bash\n4026532200 net 3 952 root unshare --mount --uts --ipc --net --pid --fork --user --map-root-user \/bin\/bash\n<\/code><\/pre>\n\/proc<\/code> folder, in which the processes of the host system are listed. <\/p>\n[root@buildah ~]# ps -ef f | head\nUID PID PPID C STIME TTY STAT TIME CMD\nnobody 2 0 0 14:22 ? S 0:00 [kthreadd]\nnobody 3 2 0 14:22 ? I< 0:00 \\_ [rcu_gp]\nnobody 4 2 0 14:22 ? I< 0:00 \\_ [rcu_par_gp]\nnobody 6 2 0 14:22 ? I< 0:00 \\_ [kworker\/0:0H-kblockd]\nnobody 8 2 0 14:22 ? I< 0:00 \\_ [mm_percpu_wq]\nnobody 9 2 0 14:22 ? S 0:00 \\_ [ksoftirqd\/0]\nnobody 10 2 0 14:22 ? I 0:00 \\_ [rcu_sched]\nnobody 11 2 0 14:22 ? S 0:00 \\_ [migration\/0]\nnobody 12 2 0 14:22 ? S 0:00 \\_ [watchdog\/0]\n<\/code><\/pre>\nmount -t proc proc \/proc<\/code> is required. This overlays the \/proc<\/code> of the host system, meaning that only the processes of the new environment are visible. <\/p>\n[root@buildah ~]# mount -t proc proc \/proc\n[root@buildah ~]# ps -ef f \nUID PID PPID C STIME TTY STAT TIME CMD\nroot 1 0 0 15:05 pts\/1 S 0:00 \/bin\/bash\nroot 27 1 0 15:11 pts\/1 R+ 0:00 ps -ef f\n<\/code><\/pre>\nexit<\/code>, or the key combination STRG+D<\/code>.<\/p>\n[root@buildah ~]# exit\nexit\n[podmanager@buildah ~]$\n<\/code><\/pre>\ncgroups<\/h3>\n
The file system of a container<\/h2>\n
\nThe only dependency on the host system is generally that the applications must be able to run on the kernel of the host system.<\/p>\nchroot<\/code>. The chroot<\/code> changes the entry point for the file system to which the user has access. For example, \/var\/lib\/docker\/container1\/dateisystem<\/code> on the host becomes the new \/<\/code> within the container. <\/p>\n[podmanager@buildah ~]$ podman export 3b62694339c6 -o postgres_container.tar\n[podmanager@buildah ~]$ ls -l postgres_container.tar \n-rw-r--r--. 1 podmanager podmanager 313597440 31. M\u00e4r 15:31 postgres_container.tar\n[podmanager@buildah ~]$ mkdir postgres_root\n[podmanager@buildah ~]$ tar -xf postgres_container.tar -C postgres_root\/\n[podmanager@buildah ~]$ ls -l postgres_root\/\ninsgesamt 12\ndrwxr-xr-x. 2 podmanager podmanager 4096 3. M\u00e4r 01:27 bin\ndrwxr-xr-x. 2 podmanager podmanager 6 1. Feb 18:09 boot\ndrwxr-xr-x. 2 podmanager podmanager 6 24. Feb 01:00 dev\ndrwxr-xr-x. 2 podmanager podmanager 6 3. M\u00e4r 01:27 docker-entrypoint-initdb.d\nlrwxrwxrwx. 1 podmanager podmanager 34 4. M\u00e4r 18:35 docker-entrypoint.sh -> usr\/local\/bin\/docker-entrypoint.sh\ndrwxr-xr-x. 37 podmanager podmanager 4096 31. M\u00e4r 14:24 etc\ndrwxr-xr-x. 2 podmanager podmanager 6 1. Feb 18:09 home\ndrwxr-xr-x. 8 podmanager podmanager 96 26. Feb 01:54 lib\ndrwxr-xr-x. 2 podmanager podmanager 34 24. Feb 01:00 lib64\ndrwxr-xr-x. 2 podmanager podmanager 6 24. Feb 01:00 media\ndrwxr-xr-x. 2 podmanager podmanager 6 24. Feb 01:00 mnt\ndrwxr-xr-x. 2 podmanager podmanager 6 24. Feb 01:00 opt\ndrwxr-xr-x. 2 podmanager podmanager 6 1. Feb 18:09 proc\ndrwx------. 2 podmanager podmanager 76 31. M\u00e4r 14:44 root\ndrwxr-xr-x. 5 podmanager podmanager 84 31. M\u00e4r 14:24 run\ndrwxr-xr-x. 2 podmanager podmanager 4096 3. M\u00e4r 01:27 sbin\ndrwxr-xr-x. 2 podmanager podmanager 6 24. Feb 01:00 srv\ndrwxr-xr-x. 2 podmanager podmanager 6 1. Feb 18:09 sys\ndrwxrwxr-x. 2 podmanager podmanager 6 3. M\u00e4r 01:27 tmp\ndrwxr-xr-x. 10 podmanager podmanager 105 24. Feb 01:00 usr\ndrwxr-xr-x. 11 podmanager podmanager 139 24. Feb 01:00 var\n<\/code><\/pre>\nchroot<\/code>.<\/p>\n[podmanager@buildah ~]$ unshare --mount --uts --ipc --net --pid --fork --user --map-root-user \/bin\/bash\n\n[root@buildah ~]# cat \/etc\/redhat-release \nCentOS Linux release 8.1.1911 (Core)\n\n[root@buildah ~]# chroot postgres_root\n\nroot@buildah:\/var\/lib\/postgresql\/data# \/bin\/cat \/etc\/issue\nDebian GNU\/Linux 10 \\n \\l\n<\/code><\/pre>\n\/proc<\/code> file system must be corrected, as mentioned.
\nOnce this is done, we have the same working environment that we would have in a container.<\/p>\nroot@buildah:\/var\/lib\/postgresql\/data# \/bin\/mount -t proc proc \/proc\n\nroot@buildah:\/var\/lib\/postgresql\/data# \/bin\/ps -ef f \nUID PID PPID C STIME TTY STAT TIME CMD\nroot 1 0 0 13:34 ? S 0:00 \/bin\/bash\nroot 27 1 0 13:35 ? S 0:00 \/bin\/bash -i\nroot 54 27 0 13:43 ? R+ 0:00 \\_ \/bin\/ps -ef f\n<\/code><\/pre>\nConclusion<\/h2>\n
\nDocker and also Podman<\/a> use these features, but offer many more functions and, above all, convenience functions for handling them.<\/p>\n