© pat138241, 123RF

Docker hat die Art und Weise, wie Admins ihre Software ausrollen, in vielen Firmen radikal verändert. Die Notwendigkeit, regelmäßig Updates einzuspielen, ist allerdings geblieben. Wie funktioniert das am effektivsten mit Containern?

Seit einigen Monaten nimmt der aufgeregte Hype um Docker gefühlt ab. Das liegt jedoch nicht daran, dass weniger das Produkt nutzen – ganz im Gegenteil: Die Ruhe resultiert aus dem Umstand, dass Docker im IT-Mainstream angekommen ist. Produktive Setups setzen wie selbstverständlich auf die Software, die Containern unter Linux neues Leben eingehaucht hat und zum Beispiel auch Kubernetes beflügelte.

Aus Sicht eines Admin spricht einiges für Docker: Docker-Container lassen sich mit reduzierten Berechtigungen betreiben und sorgen so für eine Barriere zwischen einem Dienst und dem darunterliegenden Betriebssystem. Sie sind einfach zu handhaben und lassen sich mühelos ersetzen. Sie ersparen auch Arbeit, wenn es um die Wartung des Systems geht, auf dem sie laufen: Möchte der Admin eine neue Software ausrollen, lädt er sich den entsprechenden Container herunter und startet ihn – fertig. Auf dem Basissystem muss er lediglich dafür sorgen, dass Docker grundsätzlich funktioniert.

Auch für die Anbieter von Software ist dieser Faktor wichtig: Sie stellen ihren Kunden fertige Container bereit, die sofort lauffähig sind. Installations- und Konfigurationsorgien mit RPM, Dpkg, Ansible und anderen Hilfswerkzeugen entfallen. Summa summarum bieten Container also einen merklichen Mehrwert aus der Sicht des Sysadmin.

Nicht alles ist besser

Doch wo Licht ist, ist auch Schatten, und Docker ist von dieser Regel keine Ausnahme. Denn nicht alles wird mit Docker viel besser: Neue Softwareversionen erscheinen und oft haben Administratoren ein handfestes Interesse daran, diese Versionen auch zu verwenden. Ein einleuchtendes Argument sind Sicherheitsupdates: Eine kritische Lücke etwa in Apache oder Nginx möchte der Admin reparieren, ganz gleich, ob der Dienst auf dem nackten Blech oder innerhalb eines Docker-Containers läuft.

Neue Features sind ebenfalls ein wichtiges Kriterium. Wenn die genutzte Software endlich das eine Feature hat, auf das man bereits seit Monaten oder Jahren wartet, wird man es möglichst schnell verwenden wollen. Spätestens dann stellt sich die Frage, wie ein Update möglich ist, wenn das fragliche Programm Teil eines Docker-Containers ist.

Docker-basierte Setups bieten immerhin überhaupt die Möglichkeit, schnell auf die Veröffentlichung neuer Programme zu reagieren. Wer die Arbeit mit LTS-Distributionen gewohnt ist, weiß, dass er im Wesentlichen ein Softwaremuseum betreibt und die Innovationskraft seines Setups auf dem Altar vermeintlicher Stabilität geopfert hat. Er ist gewohnt, dass neue Major-Releases von wichtigen Programmen erst beim nächsten Update auf eine neue Distributionsversion kommen – dann bereits gut abgehangen.

Wer stattdessen auf Docker setzt, kann das Basis-System noch immer auf der Grundlage einer LTS-Distribution betreiben, hat weiter oben im Applikationsstack jedoch deutlich mehr Freiheiten – und tauscht einfach einzelne Bestandteile seiner Umgebung aus.

Egal welche Gründe dafür sprechen, Programme zu aktualisieren, die in Docker-Containern laufen – wie für normale Systeme auch braucht der Admin für ihr Update eine funktionierende Strategie. Weil sich der Betrieb von Software in Docker fundamental vom Betrieb ohne die Containerschicht unterscheidet, unterscheidet sich auch die Art des Umgangs mit Updates, je nachdem, ob man mit oder ohne Container arbeitet.

Auch mit Containern stehen mehrere Optionen bereit, die dieser Artikel vorstellt. Doch zunächst geht es noch einmal um die Struktur von Docker-Containern, denn deren Verständnis ist die entscheidende Voraussetzung, um beim Updaten die richtigen Entscheidungen zu treffen.

So sind Docker-Container aufgebaut

Den meisten Admins dürfte klar sein, dass Docker-Container – anders als virtuelle Maschinen auf KVM-Basis – keine virtuelle Festplatte haben und dass sie auch nicht so funktionieren wie komplette Systeme. Der Grund: Die Docker-Welt basiert auf Kernelfunktionen, etwa C-Groups oder Namespaces.

Was innerhalb eines Docker-Containers also wie ein eigenständiges Dateisystem aussieht, ist in Wirklichkeit nur ein Ordner, der im Dateisystem des Docker-Host beheimatet ist. Ähnlich wie »chroot« sorgt Docker durch die Nutzung der besagten Kernelfunktionen dafür, dass ein in einem Container laufendes Programm auch nur Zugriff auf die Dateien innerhalb dieses Containers hat.

Docker-Container bestehen allerdings aus mehreren Schichten oder Layern, zwei Arten sind zu unterscheiden: Der Image-Layer und der eigentliche Container-Layer. Wer sich ein fertiges Docker-Image aus dem Netz herunterlädt, versorgt sich mit dem Image-Layer. Der enthält alle Teile, die zum Docker-Abbild gehören, und wird ausschließlich im Read-only-Modus genutzt. Startet der Admin mit jenem Abbild dann einen Container, kommt ein Read-Write-Layer hinzu, nämlich der Container-Layer.

Wer sich mittels »docker exec« eine Shell in einem laufenden Container öffnet und dort per »touch« eine Datei anlegt, bekommt keinen Permission-Denied-Fehler, gerade weil jener Container-Layer schreibenden Zugriff erlaubt. Die Sache hat aber einen Haken: Beendet man den veränderten Docker-Container, sind auch die darin gemachten Änderungen unwiderruflich verloren. Startet der Container aus demselben Basis-Abbild später neu, präsentiert er sich genauso wie nach dem ersten Herunterladen.

Aus Sicht der Container-Evangelisten leuchtet dieses Prinzip ein: Sinn und Zweck eines Containers ist es ja gerade, schnell durch einen anderen ersetzbar zu sein. Ist an einem Container also etwas zu verändern, so liegt es nahe, den Container einfach zu ersetzen.

Viel zu leicht vergessen die Container-Fürsprecher allerdings, dass nicht jede Applikation auf diesem Planeten dem Microservice-Mantra folgt. Nginx oder Maria DB sind nicht in viele Dienste unterteilt, die beliebig in die Breite skalieren und nativ Cloud-fähig sind. Der Ansatz, einen laufenden Container auszutauschen, funktioniert zwar auch hier, bedingt aber mehr Vorbereitung und geht mit einer Downtime einher.

Der Schnellschuss

Die Reihe der Update-Variante bei Docker-Containern beginnt mit der simplen Option 1, dem Einspielen eines Updates direkt im laufenden Container. Wer einen Container nutzt, der auf Ubuntu oder Cent OS oder einer anderen gängigen Linux-Distribution basiert, verfügt darin meist über die üblichen Werkzeuge, die er auch von echten Systemen kennt. Dazu gehören »rpm« oder »dpkg«, weil die großen Distributoren gerade diese Werkzeuge nutzen, um ihre Container-Abbilder zu generieren.

Daher fällt das Einspielen von Updates leicht: Per »docker exec« startet der Admin eine Bash im laufenden Container und führt anschließend im Beispiel »apt-get update && apt-get upgrade« aus, um Updates in seinen Container zu holen. Flugs sieht er sich allerdings mit dem Problem konfrontiert, auf das der Artikel oben bereits hingewiesen hat: Die Änderungen sind nicht dauerhaft. Außerdem blähen sie die Abbild-Datei des laufenden Containers im Hostsystem ganz gehörig auf.

Trotzdem kann ein solcher Prozess sinnvoll sein: Erscheint etwa für einen zentralen Dienst eine Zero-Day-Lücke, für die schon Exploits im Umlauf sind, verschafft einem das Update der laufenden Applikation im Container eine kurze Verschnaufpause, in der sich das richtige Update planen lässt. So oder so gilt: Wer innerhalb eines Containers Updates für Distributionspakete einspielt, sollte parallel auch die Basis-Abbilder auf dem eigenen System aktualisieren.

Hinzu kommt, dass in manchen Fällen die Option eines Dienst-Updates im Container technisch nicht zur Verfügung steht: Wer einen Docker-Container so gebaut hat, dass der den eigentlichen Dienst – etwa Maria DB – als »ENTRYPOINT« oder als »CMD« im Dockerfile definiert, hat ein Problem. Denn würde er in einem solchen Container dem jeweiligen Prozess per »kill -9« den Garaus machen, wäre der gesamte Container sofort weg – aus Docker-Sicht war darin das jeweilige Programm nämlich der Init-Prozess, ohne den der Container nicht läuft.

Für alle anderen Szenarien außer schwerwiegenden Sicherheitsfehlern, die sofort ein Update erzwingen, gilt der dringende Rat, von dieser Option die Finger zu lassen. Sie widerspricht den Design-Prinzipien von Containern und führt letztlich auch nicht zu den anzustrebenden nachhaltigen Ergebnissen.

Der Schnellschuss mit Kleber

Eher als abschreckendes Beispiel erwähnt dieser Artikel auch die Option 2, die unmittelbar auf Option 1 beruht: das Update von Containern im laufenden Betrieb samt anschließendem Erstellen eines zusätzlichen Container-Layers. Grundsätzlich bietet Docker diese Option: Verändert der Admin im laufenden Betrieb einen Container und möchte die vorgenommenen Änderungen dauerhaft speichern, legt der Befehl »docker commit« ein neues lokales Container-Image an, das zum Starten eines neuen Containers dient.

Installiert der Admin also wie beschrieben Updates in einem Container und führt danach »docker commit« aus, hat er diese im neuen Abbild permanent gespeichert. Theoretisch umgeht er so auch das Problem, dass sich der Dienst im Container nicht erneut starten lässt, ohne den Container zu beenden – er stoppt den alten Container und startet den neuen. Die Downtime ist also sehr kurz.

Aus administrativer Sicht ist dieses Szenario allerdings ein Alptraum, denn es macht die Verwaltung von Containern beinahe komplett unmöglich. Ein derart aktualisierter einzelner Container unterscheidet sich von den anderen Containern – und verhält sich im schlimmsten Fall auch anders. Der Vorteil einer uniformen Containerflotte, dass sie sich zentral steuern lässt, ist somit also definitiv verloren.

Noch schlimmer kommt es, wenn der Admin den beschriebenen Stunt mehrmals vollzieht: Am Ende steht ein chaotisches Container-Konglomerat, das sich nicht mehr aus sauber definierten Quellen erneut erstellen lässt. Der gesamte Vorgang läuft dem Betriebskonzept von Containern vollständig zuwider, weil er das Prinzip des Immutable Underlay torpediert, also jenes Konzept, in dem sich das bestehende Setup zu jedem Zeitpunkt aus seinen Quellen automatisiert und sauber reproduzieren lässt.

Während Option 1 also im äußersten Notfall noch zur Anwendung kommen kann, ist der Admin gut beraten, Option 2 nicht mal im Traum in Erwägung zu ziehen.

Fertige Container

Wer seine Docker-Container – wie in Option 3 weiter unten beschrieben – nicht gleich komplett selbst bauen möchte, findet möglicherweise in den Docker-Containern der großen Projekte eine nützliche Alternative. Wie Ubuntu, Canonical & Co. ist es auch bei den Anbietern verschiedener Programme mittlerweile Usus, das eigene Werk als fertigen, lauffähigen Docker-Container im Netz zum Download zur Verfügung zu stellen. Perfekt ist das zwar nicht, denn hier muss der Admin den Autoren der jeweiligen Software entsprechendes Vertrauen entgegenbringen. Im Gegenzug spart diese Variante aber verglichen mit dem Do-it-yourself einige Arbeit.

Wichtig: Es haben sich gewisse Qualitätsstandards herauskristallisiert, die bei den meisten Projekten entsprechende Beachtung finden. Als Beispiel sei der Docker-Container genannt, den das Prometheus-Projekt anbietet. Er enthält tatsächlich nur den Prometheus-Dienst und lässt sich über Parameter, die er beim Start übergeben bekommt, auch steuern.

Die Quellen, insbesondere das Dockerfile, das dem jeweiligen Container zugrunde liegt, stehen im Github-Verzeichnis von Prometheus zum Download bereit. Im Zweifel hat der Admin also die Möglichkeit, sich dieses Dockerfile herunterzuladen, es zu untersuchen und bei Bedarf auch an die eigenen Voraussetzungen anzupassen (Abbildung 1).

Abbildung 1: Das Prometheus-Projekt stellt dokumentierte Container für seine Software bereit.

Unbedingt die Finger lassen sollten Admins hingegen von Container-Abbildern im Docker-Hub, deren Ursprung nicht zu klären ist. Das sind die berüchtigten Blackboxes, die funktionieren oder auch nicht und bei denen es praktisch unmöglich ist, Fehlersuche zu betreiben. Wer auf fertige Abbilder setzt, sollte sich jedenfalls von der Qualität der Arbeit der Entwickler überzeugen und erst dann zur Tat schreiten.

Dieser Ansatz hat einen weiteren Nachteil: Nicht immer aktualisieren die verschiedenen Software-Anbieter ihre Docker-Abbilder in der Geschwindigkeit, die möglicherweise angezeigt ist. Während Distributoren entsprechende Updates schnell ausrollen, kann es bei den jeweiligen Applikationen selbst durchaus einige Tage dauern, bis ein aktualisiertes Docker-Abbild zur Verfügung steht.

Container selber bauen

Wer mit seinen Containern langfristig glücklich werden möchte, sollte sich frühzeitig Gedanken über sein Betriebskonzept machen – dann fällt als Nebenprodukt Option 3 an, die sich für Anwendungs- und Sicherheitsupdates vorzüglich eignet: das Selberbauen von Containern.

Dieser Ansatz war im Linux-Magazin bereits mehrere Male Thema. Zur Erinnerung: Es ist nicht sonderlich kompliziert, einen Docker-Container zu erstellen. Der Befehl »docker build« in Kombination mit einem »Dockerfile« sind die einzigen Voraussetzungen. Die Syntax von Dockerfile ist unkompliziert: Im Wesentlichen enthält es elementare Anweisungen, die Docker verraten, wie der fertige Container aussehen soll. Die Docker-Anleitung dazu ist nützlich und erklärt die wichtigsten Details [1].

Wichtig: Während Docker das Dockerfile abarbeitet, führt es die darin beschriebenen Anweisungen aus und erstellt diverse Image-Layer, die später allesamt im Read-only-Modus zur Verfügung stehen. Eine Veränderung des Abbilds ist später also bloß noch möglich, indem der Admin entweder ein neues Image baut oder die sehr hässliche Option 2 zieht. Beim Vorbereiten ihrer Dockerfiles sollten Admins insofern ein gerüttelt Maß an Sorgfalt an den Tag legen (Abbildung 2).

Abbildung 2: Ein Dockerfile ist keine Magie – es beschreibt, was der Befehl »docker build« tut, um ein Basis-Image zu erstellen.

Schützenhilfe bekommt der Admin von den großen Distributoren: Die bieten ihre Systeme meist als Basis-Image an. Wer also einen eigenen Container auf Grundlage von Ubuntu bauen möchte, muss nicht per »debotstrap« zunächst ein Ubuntu-Basis-System installieren und es zu einem Container verwursten. Es ist völlig ausreichend, im Dockerfile auf das Ubuntu-Base-Image zu verweisen, den Rest erledigt Docker ganz alleine.

Anders als viele Images, die Docker-Nutzer über den Docker-Hub zur Verfügung stellen, entsteht hier auch kein erhöhtes Sicherheitsrisiko: Wer einer regulären Ubuntu-Installation traut, hat keinen Grund, dem von Ubuntu gepackten Fertig-Container zu misstrauen – es handelt sich um dieselben Pakete.

Es gibt zudem einen guten Grund, auf die Basis-Abbilder der Distributoren zu setzen: Sie sind nämlich im Hinblick auf den Plattenplatz, den sie benötigen, optimiert, es sind also tatsächlich nur die nötigen Pakete enthalten. Wer stattdessen mit »debootstrap« zu Werke geht, bekommt viele Komponenten automatisch, die sich im Kontext eines Containers gar nicht sinnvoll nutzen lassen. Der Unterschied zwischen einem Basis-Abbild Marke Eigenbau und dem offiziellen Ubuntu-Image für Docker beträgt schnell mehrere Hundert Megabyte.

Automation ist Pflicht

Ein Dockerfile allein macht jedoch noch keinen funktionierenden Workflow aus, um sinnvoll mit Containern zu hantieren. Man stelle sich etwa vor, bei Dutzenden von Containern in einem verteilten Setup gelangt eine Sicherheitslücke an die Öffentlichkeit, etwa das SSL-Desaster, das Debian vor ein paar Jahren ausgelöst hat. Weil das Problem in der Open-SSL-Bibliothek selbst zu finden war, galt es, SSL flächendeckend zu aktualisieren. Wovon im Zweifelsfalle auch Container nicht ausgenommen wären – es stünde also einiges an Arbeit an.

Im schlimmsten Fall steht der Admin vor der Herausforderung, dass er innerhalb des Setups verschiedene Container nutzt, die selbst gebaut und auf die absolut nötigen Teile reduziert sind. Alle Container basieren zwar auf Ubuntu, doch ein Container hat Nginx, ein anderer hat Maria DB und in einem dritten läuft die eigentliche Custom Application.

Stellt sich nun heraus, dass eine wichtige Komponente in all diesen Containern auszutauschen ist, kommt der Admin eventuell trotz selbst gebauter Container auf Basis von Dockerfiles gehörig ins Schwitzen: Selbst wenn sich aus den bestehenden Dockerfiles ad hoc neue Container mit aktualisierten Paketen bilden lassen, dauert der Prozess doch lange, wenn er ihn manuell ausführt.

Sinnvoller ist es, sich einen automatischen Workflow zu basteln, der auf Knopfdruck Docker-Abbilder neu generiert. Das macht sich sowohl beim Handling von Applikations-Updates als auch bei Sicherheitsaktualisierungen bezahlt. Im Linux-Magazin kam dieser Ansatz schon zur Sprache. Dabei stand Gitlab in der Community-Edition im Mittelpunkt [2]. Denn Gitlab hat eine eigene Docker-Registry an Bord und mit seiner CI-/CD-Funktionen, lässt sich der Bau von Containern voll automatisieren. Am Ende stellt Gitlab die neuen Images per Registry zur Verfügung, sodass es genügt, sie auf dem Zielsystem herunterzuladen und den alten Container durch den neuen zu ersetzen – fertig (Abbildungen 3 und 4).

Abbildung 3: Gitlab hat eine eigene Registry für Docker-Abbilder, in denen die fertigen Images landen.

Abbildung 4: Ist Gitlab mit den richtigen CI- und CD-Befehlen konfiguriert, erstellt es neue Abbilder nach einem Push komplett automatisch.

Orchestrierung ist noch besser

Wer beträchtliche Teile seines Workflow über Container abwickelt, kommt um einen Flottenmanager wie Docker Swarm oder Kubernetes kaum herum. Es würde den Rahmen des Artikels sprengen, im Detail auf die Frage einzugehen, wie etwa die verschiedenen Kubernetes-Funktionen das Aktualisieren von Applikationen in Containern erleichtern; namentlich erwähnt seien etwa die eingebauten Redundanzfunktionen, die sowohl Kubernetes als auch Swarm mitbringen. Fakt ist aber, dass der Betrieb großer Container-Flotten ohne entsprechende Hilfe bald keinen Spaß mehr macht. Das Thema sollte der Admin also im Hinterkopf haben.

Persistente Daten und rollende Updates

Der letzte Teil des Artikels ist einem heiklen Thema vorbehalten, mit dem sich nach der Erfahrung des Autors viele Admins im Alltag schwertun – nämlich persistente Daten von Applikationen, die in Docker-Containern laufen. Auch im Kontext von Applikations-Updates spielen sie eine wichtige Rolle, und je nach Ausprägung des Setups erleichtern sie dem Admin das Leben entweder enorm oder erschweren es unnötig.

Technisch sind die Details eigentlich klar: Die einfachste Variante, um an einen Docker-Container persistenten Speicher anzubinden, sind die Docker-Volumes. Arbeitet Docker in der Standardkonfiguration, resultieren diese in neuen Dateien in »/var/lib/docker«. Mit den richtigen Parametern angelegt ist ein Docker-Volume persistent und überlebt auch das Löschen des Containers, zu dem es ursprünglich gehörte.

Mittels verschiedener Storage-Plugins lassen sich auch andere Storage-Arten an Docker anbinden: Beispiele gibt es etwa für Ceph. Wer ein Volume des Typs »rbd-volume« in Docker anlegt, postiert es unmittelbar auf dem angeschlossenen Ceph-Cluster (Abbildung 5). Aber auch mit der Standardvariante in lokalen Files lassen sich Distributions-Updates schon erheblich vereinfachen – das sei im Folgenden anhand von Maria DB als Beispiel erläutert.

Abbildung 5: Docker beherrscht eine Vielzahl von Möglichkeiten, um Volumes auch aus externen Storage-Quellen zu speisen.

Volumes für dynamische Updates nutzen

Wer einen Docker-Container mit Maria DB betreibt, wird diesen im Normalfall ohnehin mit einem Docker-Volume versehen haben, um die Daten zu persistieren. Aus operativer Sicht bringt das bei Updates einen entscheidenden Vorteil: Den neuen Container mit der neuen Version von Maria DB kann der Admin nämlich im Hintergrund vorbereiten, während der alte Container wie gehabt weiterläuft. Konkret bedeutet das: Der Admin lädt ein neues Basis-Image von Maria DB herunter oder baut sich ein entsprechendes eigenes Container-Abbild, das er auf Herz und Nieren testet.

Funktioniert es wie gewünscht, stoppt er zu einem Zeitpunkt X einfach den alten Container, löscht die Verbindung zwischen dem alten Abbild und dem Volume und hängt genau dieses anschließend direkt an den neuen Container mit dem neuen Maria DB an. Wenn dabei sichergestellt ist, dass das Einhängen des Volume in den Container an der richtigen Stelle im Dateisystem passiert, also dort, wo Maria DB im neuen Container die Daten erwartet, ist die Downtime vernachlässigbar.

Das Prozedere mit persistenten Volumes bietet einen weiteren Vorteil: Wer mit echten Daten testen will, ob während des Upgrade Probleme zu erwarten sind, der kann vom bestehenden Docker-Volume einen Klon anlegen und ihn an den neuen Container anschließen. Die Gefahr, dass es während des Updates des Live-Systems zu Problemen kommt, lässt sich so weiter erfolgreich reduzieren.

Fazit

Das Ausrollen von Sicherheits- und Applikations-Updates in Containern ist keine sonderlich schwierige Angelegenheit, wenn der Admin ein klares Konzept hat. Bastellösungen mit Updates in laufenden Containern sollten lediglich als Notnagel dienen und keinesfalls länger als unbedingt nötig zum Einsatz kommen. Der Königsweg besteht darin, sich seine Container samt allen benötigten Teilen selbst zu bauen, wobei Werkzeuge wie etwa Gitlab und Docker selbst praktische Hilfe liefern.

Wer diesen Aufwand scheut, greift zu den fertigen Abbildern verschiedener Programmanbieter – die unterscheiden sich hinsichtlich der Durchführung eines Update nicht sonderlich von ihren Pendants aus eigener Herstellung. Im Gegenzug muss der Admin hier möglicherweise aber länger warten, bis eine aktualisierte Version der benötigten Software als Container bereitsteht.