• untoreh-light
  • untoreh

    I am Francesco Giannelli. The website «unto.re» is the place where I put stuff I should remember...or forget. Located in south italy. Born in the early nineties.

  • I am Francesco Giannelli. The website «unto.re» is the place where I put stuff I should remember...or forget. Located in south italy. Born in the early nineties.
    italy

On Containers

Using containers, what and why

What are containers

[Containers] is a name given to restricted environments, made possible by a collection of subsystems within linux like [cgroups] and [namespaces]. Although the wiki page uses the word virtualization I think the word isolation is more appropriate, since virtualization means that there is a layer of translation in-between, while what cgroups and namespaces do is to separate, and contextualize processes.

Cgroups are used to define allocation policies for resources, usually RAM and CPU, while namespaces control the contexts like mount-points, networking and users. [Apparmor] instead provides a way to restrict capabilities for containers environments as a whole, whereas apparmor without containers is, as written in wikipedia, program-based.

Tools like flatpak and firejail use containers, to constrain the access surface of user applications. [Windows] containers implements equivalent systems, and also offer support for linux containers through [WSL].

But why?

Too much?

When I started building pine, I experimented a bit with shipping my own container images, distributed from github releases. The main script (trees) commands were

Usage: trees APP [FLAGS]...
'APP'               Install apps through ostree deltas checkouts.
    -b, --base      base image (alp,trub...)
    -n, --name      same as APP (etcd,hhvm...)
    -f, --force     clear before install
    -d, --delete    clear checkout and prune ostree repo
ck, check           make sure the apps repo is mounted
co, checkout        builds the trees of links for the specified APP
    -t 	            optional path where to build the tree

It was similar to flatpak, as I was shipping an ostree static delta based on the main pine image, and [checking out] the new app based rootfs, and then launching a container instance on top of it. OpenVZ had lots of issues before v7 for running container (since you know...you were running a nested container on a container-based [VPS], and the kernel was a fork of v2.6 (!))...it was a huge waste of time.

When?

My attempt was to get a minimal container runtime without requiring docker or more beefier software, as docker is probably the most lightweight, and docker swarm, being built-in shares a lot of functionality and provides you the most useful features for orchestration, which makes it the most lean on host system requirements compared to k8s or nomad.

Despite containers being a feature you might want most of the times, orchestration isn't. I think loosely targeted advertising campaigns attract the un-intended target audience for such software, making one believe that it can be useful to them, without emphasizing the premise that you really need to scale a lot(!) to justify the complexity cost of such setups. The number of convenience tooling built around k8s to aid the bootstrapping process of a k8s cluster should be enough evidence...

Conclusions

Orchestrations tools end up crowding the place for solutions to manage multi host machines when users can't tell the difference between pet and cattle servers. On many occasions, software like ansible, pyinfra or even cssh or assh is all one ever needs.