Container

Motivation

Container provide a light-weighted virtualization where the kernel of your system is used but the processes that have a different view onto the system. Instead of a Virtual Machine (VM) we only have a Virtual Environment (VE) Here you will learn the basic terminology of the container world and some examples.

Why Container?

In the beginning was the chroot command that allows a process to see only a part of the file-system but it was never meant as a secure confinement. FreeBSD developed something out of this with the name "jail" where you could really limit a process. Jails where limited to be only able to interact with processes inside its jail and also restricted with certain operations.

When Linux become popular hosting-providers wanted to offer cheap "root-servers" to customers without the overhead of full virtualization. This lead to the creation of "linux-VServers" but this was not part of the mainline kernel.

Today, Linux has a generalized framework for limiting what processes can see with the "cgroups" which is used for container-type virtualization.

Container and Dependency Hell

What was driving this was not so much a need for security or the desire to offer cheap root-servers but the ever more increasing dependency hell in languages as ruby, python, etc.. With the fast pace of development in this newer languages developers need to keep track about which version of the programming language and which modules they use. What worked in python2.4 did not work in python2.6, and then there are dependencies on many modules which are also available in newer and older versions and which are not always compatible. While languages like python and ruby already have some ways to deal with that in a way that they install a different set of modules for each project in a sub-directory, it can also be that case that some of the modules might have dependencies with special versions of system libraries. So the solutions, to put all of that into a container where one can make sure that there are no more outside dependencies makes sense.

This certainly has some advantages but also comes with some problems of its own: Now for security updates of modules you do not only have to take care of your system libraries but also a ton of code that is hidden away in containers and then there is a tendency to more or less ignore backwards compatibility of code as people can revert to containers. To manage the increased complexity then additional tools become necessary.

Overview of Container Technologies

On of the first projects that made use of the cgroups containers was the LXC (LinuX Containers) Project. LXCs are often kind of virtual machines which a more or less complete OS install but only sharing the kernel. They are usually meant as permanent machines that are started at boot and maintained with lxc- tools. LXC Container can also be maintained via the libvirt virsh tools. (Yet one should decide for one of the 2 as they are not fully interchangeable). The cgroups allows Virtual Environments (VE) to share some of the "namespace" (e.g. network).

Docker is the most known Container technology today. It started as extension of LXC but now is independent of it. It still makes use of the cgroups of course. The focus of docker is not to run a small OS in the VE (virtual environment) but just one application. What docker offers above that are tools to download container images from a git like repository and to build on existing containers.

Podman after the success of docker RedHat announced the podman project which aims to be a drop-in replacement for docker. It will be part of RedHat8. As of now (2020) it is not well integrated into debian or other distributions yet. Podman offers a few security enhancements over docker, e.g. the option to run containers without root and better integration into the systemd environment.