Containers everywhere

Von Admins und Devops

Früher™ hat man als Admin seine Server bis ins letzte Details konfiguriert und gepflegt. Zum Dank liefen sie dann auch über Monate oder gar Jahre, ohne dass sie langsamer wurden, Speicher vollliefen, Dienste neu gestartet werden mussten, etc.
Auch wenn die Hardware immer langsamer altert - Moore's Law ist tot - die Softwareumgebungen werden immer schnelllebiger.

Es ist die Veränderung, die fortwährende, unausweichliche Veränderung, die den dominanten Faktor in der heutigen Gesellschaft darstellt. Keine vernünftige Entscheidung kann noch getroffen werden, ohne dabei nicht nur die Welt, wie sie ist, sondern auch die Welt, wie sie sein wird, in Betracht zu ziehen.
- Isaac Asimov 1981

Wer versucht, auf LTS-Systemen aktuelle Versionen von Perl, PHP, Ruby, node.js, Python und Co zu verwenden, landet schnell in einer Abhängigkeitshölle von Fremdquellen, die einem spätestens beim nächsten Releaseupgrade in den Arsch tritt.
Wenn "neu aufsetzen" eh der neue Standard ist, dann kann man diese verschiedenen Umgebungen doch eh getrennt voneinander virtualisieren. Aber wozu jeweils ein eigenes Debian-System installieren und ein halbes Gigabyte an Betriebssystem-Bibliotheken mit Updates pflegen?
Bei Docker laufen alle Container auf dem Kernel des Basissystems. Für die Gast-Images gibt es abgespeckte Distributionen wie Alpine. Diese ermöglichen Container, die nur 7-8 MB groß sind! Auch zur Laufzeit hat man somit nur minimalen Overhead.
Gibt es ein Update für das Basis-Image (welches z.B. MariaDB, aspnet-core, ö-Ä. enthält), dann genügt ein docker pull oder ein Container mit Watchtower und nach wenigen Sekunden läuft die neue Version. Da diese Vorgänge häufig in continuous integration Systemen, wie z.B. Jenkins automatisiert werden, verschwimmt die Grenze zwischen Entwicklern und klassischen Administratoren immer mehr.

Buzzword Bingo vs. Lernkurve

Docker, Moby, OpenStack, Photon, OpenFaas, EC2, Kubernetes - na was denn nun?
Ich wollte doch nur ein paar Dienste wie Nginx virtualisieren und kein ganzes Rechenzentrum betreiben! Zugegeben - man fühlt sich beim ersten Kontakt wie in einem Raum, bei dem zu jeder Richtung Türen offenstehen, hinter denen sich weitere, riesige Räume verbergen. Also raus aus der Hobbit-Höhle; hinein in das Abenteuer!
Tatsächlich bietet die Dokumentation auf der Docker Homepage einen guten Einstieg. Die vielen neuen Befehle mit endlos scheinenden Parameterlisten erinnern an die Zeit, in der man sein Slackware- oder Gentoo-System von Grund auf per Hand zusammen gefrickelt hat.
Klar kann man auch die hübschen (meist hoffnungslos veralteten) Oberflächen von NAS-Anbietern wie Synology und Co benutzen, aber der Lerneffekt bleibt dabei etwas auf der Strecke.

In der Praxis

Bereits nach wenigen Stunden hat man die ersten Dienste als Docker-Container laufen, die Daten dauerhaft persistiert und vielleicht schon die eine oder andere Stolperfalle mitgenommen. Was dann?
Am schnellsten lernt man, wenn man etwas Sinnvolles mit seinem Wissen anstellt.
Viele haben sicherlich kleine Webserver für Blogs, Heimautomatisierung o.Ä. am Laufen. Dazu noch diverse Medienserver wie Samba, Plex, Libresonic und Co für Filme und Musikstreaming. Zuletzt hoffentlich noch den einen oder anderen (Cloud-)Backupdienst.

Alle diese Aufgaben lassen sich hervorragend modular auf einem Homeserver betreiben. Dafür findet ihr eine wunderbare Anleitung mit einigen interessanten Docker-Kniffen bei Linuxserver.io.

Aber selbst wenn man diese Dienste nicht benötigt, erweist sich Docker im Alltag häufig als sehr praktisch. Als Testumgebung für Anwendungsentwickler oder um Produktivsysteme sauber zu halten. Hand aufs Herz: wer hat nicht bereits das build-essential Paket installiert, weil man für VMWare-Tools oder ähnliche Kernelmodule den Drittanbieter-Code kompilieren musste? Stattdessen startet man jetzt einfach ein Image mit der nötigen Entwicklungsumgebung, lässt dieses die Artefakte erstellen und löscht hinterher das Container-Volume wieder (selbst das geht mit dem entsprechenden Parameter völlig automatisch). Genial.

The next Level

Zu Beginn reicht ein einfaches docker run hello world. Dann schaut man sich mounts und volumes an. Das krude L4 docker networking. Spätestens bei swarms wird ein Blick über den Tellerrand fällig. Jüngst wurde die Integration von Docker und Kubernetes angekündigt. Je weiter man seine Anwendungen in Pods kapselt und von Kubernetes verteilen, ausführen und vernetzen lässt, desto weniger kommt das eigentliche Docker zum Zuge. Letzlich ist es nur noch für den Filesystem Namespace zuständig. Hat man sich mit den Begrifflichkeiten vertraut gemacht, ist auch Kubernetes relativ einfach zu beherrschen.
Wer Lust zum Experimentieren hat, kann sich tiefer in das Thema serverless computing eingraben und mit OpenFaaS sein eigenes Amazon Lambda hosten.

Ein schönes Fun-Projekt hat Scott Hanselman von Microsoft verwirklicht: ein Cluster aus 6 Raspberry Pi Rechnern.

Hier meine Variante mit lediglich drei Nodes - viel Spaß beim Nachbauen!