O.Liebel: "Skalierbare Container-Infrastrukturen". Rheinwerk Computing 2017

Jun 18, 2018
BuchbesprechungSoftware-ContainerDocker

Besprechung von: Oliver Liebel: Skalierbare Container-Infrastrukturen – Das Handbuch für Administratoren. Rheinwerk Computing 2017. ISBN 978-3-8362-4366-7. 1071 Seiten, gebunden. 69,90 EUR

In den letzten Jahren hat die Technik, Software bzw. Anwendungen auf Servern in Containern laufen zu lassen, erhebliche Furore gemacht. Viele sehen darin sogar eine neue Revolution, welche mittelfristig Großteile der professionellen IT-Landschaft verändern wird, und die nicht mehr aufzuhalten ist. Der Einschlag dieser Technik wird oft verglichen mit dem Aufkommen der Maschinen-Virtualisierung einige Jahre vorher, die zu Dingen wie dem Cloud Computing geführt hat. Den Software-Containern zum Durchbruch verholfen hat dabei zweifelsohne das in 2013 von dotCloud als Open Source-Projekt veröffentlichte Docker¹. Der Verdienst der Docker-Entwickler liegt darin, eine gut einzusetzende und universelle Plattform für die Anwendungsauslieferung entwickelt zu haben, welche die dafür verwendeten Mechanismen handhabbar macht, eine Engine für den Container-Betrieb zur Verfügung stellt, und ein Format für Container-Images definiert zu haben. Es ist aber tatsächlich so, dass für Docker das sprichwörtliche Rad gar nicht mal neu erfunden werden musste, sondern die Grundlagen für Software-Container noch weiter zurück liegen, und Docker auf eine Reihe von bereits seit längerem verfügbaren Techniken aufsetzen konnte.

Wie auch in dem Artikel von Martin Loschwitz zu dem Thema² gut zusammengestellt ist liegen die Ursprünge von Software-Containern zunächst bei den LPARs von IBM Mainframes, bei BSD-Jails und Solaris Zones, und gehen im Linux-Bereich auf OpenVZ und Linux-V-Server zurück. Ein direkter Vorläufer von Docker, auf den die Engine in seine Anfängen auch noch selbst aufgesetzt hat, sind die Linux Container (LXC)³, welche sich von Docker als dem Platzhirschen nicht haben verdrängen lassen und weiterentwickelt werden, und auf welche zum Beispiel das von Canonical als Konkurrenz zu Docker aufgestellte LXD aufbaut⁴. Die aktuellen Container-Lösungen haben dabei gemein, dass sie maßgeblich auf zwei schon seit längerem im Linux-Kernel verfügbaren Funktionen aufbauen, nämlich auf Namespaces und Kontrollgruppen (Cgroups). Cgroups sind eine Kernelschnittstelle, über welche sich der Zugriff auf Hardwareressourcen von Prozessen kontrollieren und limitieren lässt⁵, während Linux-Namespaces es ermöglichen, Prozesse vom Kernsystem in Bezug auf verschiedene Parameter wie Netzwerkressourcen und Dateisystem-Zugriffe zu isolieren. Ein mittels Namespaces realisierter Container ist damit vom Host und anderen Namespaces bzw. Containern auf tiefgreifender Ebene separiert, und er kennt zum Beispiel nur sein eigenes Dateisystem und seine eigenen Prozesse, und die ihm zugewiesenen Netzwerkschnittstellen.

Untergeordnete Laufzeitumgebungen mit abgeteilten Systemressourcen zu bekommen, etwa um einen Server aufzuteilen und somit an eine Vielzahl von Kunden vermieten zu können, das wird zwar auch mittels Virtualisierung realisiert, es gibt zu Containern aber einen ganz entscheidenden Unterschied. Virtualisierte Systeme setzen auf einer tieferen Systemebene als Container an, sie werden als eigene Maschine mit eigenem Bios zur Verfügung gestellt, auf welcher um eine Applikation zum laufen zu bekommen zunächst immer erst ein eigenes Betriebssystem aufgesetzt und gebootet werden muss. Der Ressourcenverbrauch ist dabei im Gegensatz zu Containern wesentlich höher, und alleine um den für die Virtualisierung benötigten Hypervisor auf dem Host aufzustellen benötigt es mehr Kapazität, als es eine damit zur Verfügung gestellte Anwendung an sich benötigt. Container hingegen können einfach dadurch, dass ein laufender Kernel in Sekundenbruchteilen einen Namespace dafür eröffnet und Ressourcen zugewiesen werden, unmittelbar eingesetzt werden, und teilen sich dieselbe durch diesen Kernel unmittelbar zur Verfügung gestellten Hardware. Sie sind sind dadurch wesentlich leichtgewichtiger und schneller einsetzbar als virtuelle Maschinen, und eine signifikant höhere Packungsdichte auf physikalischen Maschinen kann mit Containern erreicht werden.

Anwendungscontainer kann man im Gegensatz zur Maschinenvirtualiserung also als reine User Space-Virtualisierung bzw. -Isolierung bezeichnen, die mit durchgeschliffenem Kernel betrieben werden. Container werden dabei aus Images gestartet, die lediglich ein nur für eine bestimmte Anwendung zugeschnittenes bzw. reduziertes Basissystem enthalten, für welches kein laufendes Initsystem bzw. ein Prozessmanager notwendig ist, aber eine vollständige Laufzeitumgebung inklusive aller benötigten Abhängigkeiten und Bibliotheken. Das macht es zum Beispiel möglich, parallel Anwendungen zu betreiben, die widersprüchliche Anforderungen an den Host stellen, und Container lassen sich auch ohne Probleme zwischen heterogenen Hosts portieren (Slogan: “run everywhere”). Ein weiterer Vorteil der Auslieferung in Containern gegenüber auf Servern unmittelbar installierter Anwendungen ist die Möglichkeit, das Images bereits auf Entwicklungsebene zusammengepackt, und von der Anwendungsbereitstellung einfach nur noch durchgeschoben und direkt zum laufen gebracht werden können, ohne vorher aufwendig die Produktionsumgebung für ein Update anpassen bzw. ganz neu aufsetzen zu müssen – grundsätzlich kann damit sogar auch komplett automatisiert ausgerollt werden. Mühselige, lang dauernde und kostspielige Bereitstellungsprozesse, in denen etwa unter Vorherrschaft der berüchtigten “Silo-Mentalität” Releases von den Entwicklern zu den Administratoren einfach über die hohe Mauer geworfen werden, lassen sich mit Container-Technik signifikant optimieren. Mit diesen Vorteilen im Gepäck ist es nachvollziehbar, dass Software-Container längst zum Grundstein einer zukunftsweisenden IT ausgerufen worden sind, und in modernen Verfahren der Softwarebereitstellung wie Continuous Delivery und DevOps, bei dem die Trennung zwischen Entwicklung und IT-Betrieb (Operations) aufgehoben oder zumindest eingeebnet wird⁶, eine maßgebliche Rolle spielen.

In der Zwischenzeit ist der “Mega-Hype” um das Thema “Software-Container” wieder ein bisschen abgeklungen, und in vielen Unternehmen stellt sich eine realistische Abwägung der Vorteile gegenüber den Schwierigkeiten ein, welche die Umstellung von bereits etablierten Geschäftsprozessen auf Container-Technik mit sich bringt⁷. Software-Container sind eine eigene Welt für sich, und dem Autor des hier besprochenen Werkes sind diese Probleme bewusst: “Kern- und Drehpunkt der Ernüchterung lag bzw. liegt in dem z.T. sehr hohen Aufwand, der immer noch an den Tag gelegt werden muss, damit eine auch nur etwas komplexere Applikation im Container so läuft, wie sie es mit einem vernünftigen Init-System von Haus aus in einer VM [virtuellen Maschine] oder auf einem realen Host bereits tun würde” (89). Beim Neuaufbau von Abteilungen etwa bei Firmen-Neugründungen gibt es aber wahrscheinlich gar keine Wahl mehr auf Container als Grundlage der Softwarebereitstellung zu setzen oder nicht, so groß ist der Entwicklungsvorsprung gegenüber den herkömmlichen Techniken und Verfahren.

Seit seiner Veröffentlichung ist rund um das Thema Software-Container und den Platzhirschen Docker ein mittlerweile kaum noch überschaubares Ökosystem von Software und Services entstanden, das sich in rasender Geschwindigkeit laufend weiterentwickelt. Das ganze Thema ist so komplex geworden auch vor allem weil Container in lokalen Installationen und bei Single Nodes-Setups – auch wenn sich zum Beispiel einfache Webserver damit wesentlich komfortablen deployen lassen – ihr volles Potential erst im größerem Maßstab. So lassen sich mehrere Software-Container als Komponenten einer Anwendung in einem Cluster verteilen und zu einem Dienst bündeln (Stichwort: Orchestrierung), der in Verbindung mit einem Load Balancer redundant mit mehreren parallel laufen Instanzen ausgelegt werden kann, so dass sich Vorgaben der Skalierbarkeit und Ausfallsicherheit mit dieser Technik auf Enterprise-Niveau umsetzen lassen.

Sklalierbare Container-Infrastrukturen

Für das Clustering und die Orchestrierung von Containern gibt es mittlerweile eine ganze Reihe von Lösungen⁸, und so ist alles-in-allem ein umfangreiches Wissensfeld enstanden, welches – wie dem Titel zu entnehmen ist – das Hauptthema des vorliegenden Buches von Oliver Liebel ist. Der Autor ist Experte für Linux im Enterprise-Umfeld und offizieller Partner von Red Hat, SUSE und Docker Inc., und unter anderem als Berater, Systemarchitekt und Projekleiter, also auf Praxisebene tätig. Er kann auf eine 25-jährige Berufserfahrung zurückblicken und schreibt, wie ich feststellen konnte, aus einem tiefen auch gerade praktischen Wissen heraus, so gibt es viele Lösungen für Probleme in bestimmten Fällen wie zum Beispiel Docker-Container auf SUSE Enterprise Linux und dem dort per Default eingesetzten BTRFS-Dateisystem. Im selben Verlag (bis 2015 Galileo Press) ist von ihm bereits ein ähnlich umfangreiches Handbuch über Linux-Hochverfügbarkeit erschienen⁹.

I. Brave new world?

Im ersten, gegenüber den anderen vier sehr umfangreichen, eher übersichtlichen Einführungskapitel von 63 Seiten führt der Autor zunächst in die Container-Technik im Gesamtzusammenhang mit modernen Verfahren der Softwareentwicklung und -Bereitstellung ein. Der Titel ist der berühmten Anti-Utopie von Aldous Huxley entlehnt und weist so schon direkt darauf hin, dass der Autor – wie bereits erwähnt – gegenüber der weit verbreiteten, unangemessen überschwänglichen und übertriebenen Erwartungshaltung bezüglich Software-Containern gegenüber demonstrativ einen eher kritischen bzw. einen überlegten Standpunkt einnimmt. Es wird aber natürlich nicht davon abgeraten, diese Technik tatsächlich einzusetzen, sondern diese Haltung ist vor dem Hintergrund des bereits erwähnten “Mega-Hype” zu sehen, die Container-Technik mit dem Aufkommen von Docker ausgelöst hat, denn die Schwierigkeiten der Umstellung von bereits etablierten Arbeitsabläufen in Unternehmen und die darauf folgende tiefe Enttäuschung dürfte der Autor mit seinem Hintergrund als Berater im Enterprise-Umfeld vielerorts mitbekommen haben. Das ist meiner Meinung nach eine sehr gute Position, aus der Liebel in die Thematik einführt, und das schafft Platz für eine realistische Beschäftigung mit diesem hochkomplexen Thema, in der vernünftig erörtert werden kann, was die Möglichkeiten sind und was die Schwierigkeiten, was Software-Container leisten können, und was nicht – bereits laufende Geschäftsprozesse wie mit Zauberhand entschlacken sicherlich nicht. Der Autor schreibt darüber: “Container können viel, in bestimmten Umgebungen. Und vieles auch noch nicht. Container können Vorteile in bestimmten Szenarien gegenüber herkömmlichen IT-Landschaften bringen. In anderen führen sie nur zu einem erhöhten Aufwand an Zeit, Geld und Nerven” (45). Wie man an seinem Buch von 2013 über Linux-Hochverfügbarkeit sehen kann hat Liebel seine Wurzeln im “Old School”-Serverbetrieb und bewertet so die “neue Welt” der Container vor einem angemessenen Hintergrund, welcher die Dinge von der physikalischen Maschine und den unverändert bestehenden IT-Grundlagen aus gesehen kompetent einordnen kann.

1. Die neue alte Welt der Virtualisierung

Das erste Kapitel setzt als Einleitung mit einigen nachdenklichen Zeilen gegenüber einer “sich selbst permament und immer schneller neu gebärdende[n] IT-Struktur” (39) ein, die Hauptsache sind hier aber die ab 1.2 aufgeführten allgemeinen Hinweise zu dem Buch, die vielleicht eher in ein Vorwort gehört hätten. Hier findet sich unter anderem der Hinweis, dass das Werk ein “praxisnahes Handbuch für Admins, DevOp-Teams und Entscheider” sein soll, hingegen aber kein “reines Handbuch/Nachschlagewerk für Entwickler, das insbesondere Dev-spezifische Ansprüche berücksichtigt” (41). Der Autor beschreibt die Dinge also von der “Operations”-Seite aus, und so findet sich in Buch kein Kapitel etwa darüber, welche Besonderheiten bei Container-Images für verschiedene Programmiersprachen zu beachten sind und ähnliche Fragen, die sich Entwicklern stellen, die ihre Software als Container vertreiben möchten. Developer als Bestandteil von DevOps-Teams, die auch das große Ganze im Auge haben, sind aber ausdrücklich als Zielgruppe eingeschlossen.

Ein weiterer Disclaimer betrifft den gesamten Bereich des Public Cloud Computing mit seinen speziellen Angeboten für Container (Stichwort: Container-as-a-Service, CaaS), aber auch den reinen Mietserver-Betrieb (Infrastructure-as-a-Service, IaaS) als Grundlage für Container Cluster-Setups, nämlich nur der “Einsatz/das Verständnis von Self-Hosted Container Clustern” (SW: On-premises) ist Gegenstand dieses Buches (42). Fragen des Cloud Computing als eigene Themen mit einzubeziehen hätte mit Sicherheit den bereits auch ohne das sehr umfangreichen Rahmen des Buches gesprengt, und wenn Dinge wie die vom Autor an dieser Stellen erwähnte Spezialfrage der Absicherung von unternehmenskritischen Applikationen und Daten in der Public Cloud noch hinzugenommen hätte, um so mehr.

Ausgeschlossen – zumindest von den Praxisbeispielen – bleibt auch der weit gewordene Bereich der speziellen Container-OS wie CoreOS/Container Linux¹⁰, Red Hat Atomic¹¹, RancherOS, oder SUSE Kubic, sondern Liebel bezieht sich in seinen Beispielen ausschließlich auf “Mainstream”-Betriebssysteme: Red Hat Enterprise Linux 7.x (vertreten durch CentOS 7.3), SUSE Linux Enterprise Server (12 SP2, und Leap 42.2), und Ubuntu (16.04 LTS), welches von vielen Privatanwendern, aber auch in professioneller IT eingesetzt wird. Dass trotz dieser beiden großen, notgedrungen außen vor bleibenden Themen so ein dicker Wälzer von über tausend Seiten zusammengekommen ist verdeutlicht, wie weit der gesamte Themenbereich in dieser relativ kurzen Zeit von einigen Jahren bereits gediehen ist.

2. Container

Im zweiten Kapitel “Container” versucht der Autor ganz konkret dem Leserkreis – und das Buch richtet sich wie gesagt auch an Entscheider – eine realistische Einschätzung der Möglichkeiten der Container-Technik zu vermitteln, indem der Frage nachgegangen wird “Welche Einsatzszenarien profitieren aber nun von dem Einsatz von Containern, machen ihn deutlich ökonomischer bzw. sind zwingend darauf angewiesen oder werden erst durch ihn möglich?” (46).

Dafür wird als erstes der Begriff “Microservices” (2.2) besprochen, von dem Liebel schreibt, es handelt dabei um “Eine, wenn nicht gar die wichtigste, Container-Designphilosophie” (46). Die Technik, eine monolithische Applikation in kleine Bestandteile zu zerlegen und diese als separate Dienste jeweils in einem eigenen Container zu betreiben und diese zu vernetzen, hat einige Reihe von Vorteilen, so kommt es zum Beispiel hohen Anforderungen von Skalierbarkeit und Verfügbarkeit entgegen. Allerdings gibt es dabei einige Fallstricke, auf die Liebel eingeht.

Die nächsten Begriffe, die der Autor im Hinblick auf Software-Container und die darin enthaltenen Microservices untersucht und ins Spiel bringt sind “Continuous Delivery” und “Continuous Integration” (CI/CD), sowie “DevOps” (2.3). Es findet hier allerdings nicht das übliche Abklappern der üblichen Schlagworte aus dem Bereich “zukunftsweisende IT” statt, sondern Liebel stellt dar, wie diese Verfahrensweisen in Verbindung mit Containern und Microservices dazu benutzt werden können, um herkömmliche, schwerfällige Releases von monolithischer Software mit ihren üblichen Problemen sukzessive umzustellen. Dafür stellt Liebel ein gesamtes auf Continous Delivery und Containern basierendes Modell für die Softwareauslieferung dar (2.4). Es folgt eine Diskussion des in diesem Zusammenhang wichtigen Begriffs “DevOps” (2.5).

II. Single Node Container-Systeme

Der zweite Teil des Buches behandelt das Thema “Single Node Container-Systeme”, und es nimmt mit 415 Seiten ein maßgebliches Stück des besprochenen Werkes ein, und ist damit ähnlich ausführlich wie der dritte und umfangreichste Teil über “Container-Cluster und Orchestrierung”. Das Buch handelt – wie der Titel besagt – gerade von Multi Node-Systemen, und es heißt geradezu “Keine Container-Technologie ergibt heutzutage ohne einen entsprechenden Orchestrierungs-Layer darüber wirklich Sinn” (42), aber Liebel setzt zunächst bei Single Nodes an, um den Leser auf grundlegender Ebene beginnend umfassend in die Container-Technik einzuführen: “Aus diesem Grund ist der Teil über Single Node Container-Systeme/Container Engines ebenfalls umfangreich ausgelegt, um alle Konzepte, Verfahren und Technologien hinreichend zu erläutern” (42). Es gibt in diesem Teil zunächst eine allgemeine Einführung in das Thema, im Zuge derer auch alternative Lösungen kurz abgehandelt werden. Die Hauptrolle spielt in diesem Teil allerdings gerade Docker als Container-Engine mit dem mit weitem Abstand höchsten Marktanteil (und daran hat sich in der Zwischenzeit auch nichts geändert). Den ganzen für Docker eingeräumten Platz nutzt Liebel aber auch, um genauso kritisch auch auf die Nachteile und die Probleme von diesem weit verbreiteten Softwareprodukt einzugehen.

3. Container-Plattformen, Basics und Konzepte

Im dritten Kapitel “Container-Plattformen, Basics und Konzepte” wird für das Verständnis der Container-Technik zunächst ein Schichtenmodell präsentiert (3.1), in dem Container-Engines auf Betriebssystemen aufsetzen, welchen wiederum auf von Hypervisoren oder Cloud Computing bereitgestellter virtueller Infrastruktur basieren, die wiederum auf physikalischer Infrastruktur stehen.

Darauf folgt ein Abschnitt über Container-Basics (3.2), in dem der Autor sehr detailliert auf Linux-Namespaces eingeht, wobei auch schon direkt Fragen der Sicherheit eine Rolle spielen. Der nächste Abschnitt (3.3) vergleicht Container mit virtuellen Maschinen, stellt die Vorteile der neueren Technik dar, und untersucht die Frage, ob der Einsatz von VMs als maßgebliche Umgebungen für die Anwendungsbereitstellung dadurch obsolet geworden ist bzw. wird. Hier wechselt der Autor dann von den technischen Details weg in eine Vogelperspektive und entwickelt Kriterien für die Frage, für welchen Bedarf in Unternehmen sich die Container-Technik eignet – dieses Kapitel richtet sich maßgeblich auch wieder mit an Entscheider.

Darauf gibt es eine Übersicht über die vorhandenen Container-Lösungen (3.5), in dem wieder sehr tief gehend und ausführlich auf die Komponenten im Unterbau von Docker eingegangen wird (libcontainer, containerd, runC und shim). Alternative Lösungen wie LXD (3.5.3), rkt (Rocket)⁰ und VMWare Photon werden hier dagegen nur ganz kurz angerissen; der Abschnitt über Photon (3.5.5) endet auch vom Sinn her mit einem Doppelpunkt, was darauf schließen lässt, dass hier gekürzt worden ist bzw. gekürzt werden musste. Es gibt noch einen kleinen Überblick über alternative Container-Formate (3.5.6), aber Leser, die in diesem Kapitel Informationen über Lösungen jenseits von Docker suchen, werden eher enttäuscht sein.

4. Docker

In Kapitel 6 geht es dann ohne Seitenblicke ausschließlich um Docker, und es werden zunächst die (zum Zeitpunkt der Erstellung dieses Buches) aktuellen Docker Versionen mit einem funktionalem Überblick über seine Funktionsweise (4.1) thematisiert, und dann geht es um die Installation dieser Container-Lösung (4.2). Auch wenn das, was hier über die Verfahrensweisen geschrieben wird Docker zu installieren (offizielles Paket der Linux-Distribution, Pakete von Docker Inc., Installation über Shellskript und mit Tarball), immer noch Gültigkeit hat, so sind die besprochenen Versionsnummern mittlerweile allerdings schon überholt. Open Source-Software zeichnet sich durch häufigere Releases aus, Software-Container sind ein höchst dynamischer Softwarebereich, und einige Monate nach der Veröffentlichung (das Buch ist Mitte 2017 erschienen, und natürlich noch einige Wochen vorher geschrieben worden) sind die in diesem Abschnitt des Buches erwähnten Versionen mittlerweile natürlich veraltet (siehe auch die weiter oben die Liste der besprochenen Betriebssystem-Versionen). So heißt zum Beispiel das Kernpaket aus den Repositories des Anbieters heute “docker-ce”, und nicht mehr “docker-engine”, dann es hat sich mittlerweile der CE-Zweig etabliert (mit einer Umstellung in der Versionszählung, derzeit aktuell 18.03 gegenüber 1.12/1.13 in diesem Handbuch), und AUFS als FS-Overlay wird auch nicht mehr standardmäßig eingesetzt. Da aber wie gesagt die Verfahren grundsätzlich dieselben geblieben sind ist die nötige Abstraktionsleistung diesen Abschnitt erfolgreich nachzuarbeiten aber durchaus eher gering, der Leser muss sich dessen nur bewusst sein, und ggf. selber nachrecherchieren und ausprobieren.

Es gibt darauf hin eine Fülle von wertvollen Profi-Informationen zu Storage Backends (4.3), zur Systemd-Integration (4.4), und in 4.5 zu Docker im Betrieb (Laufinformationen bekommen, Konfigurationsmöglichkeiten, Startoptionen des Docker-Dämons usw.). Im Abschnitt 4.6 geht es dann sehr ausführlich um das lokale Management von Container-Images, und es kann gut auch als erste Einführung in das Thema durchgearbeitet werden, wenn der in diesem Thema unerfahrene Leser die vielen Details und Spezialfragen verarbeiten kann bzw. möchte. Liebel wird nicht müde an vielen Stellen im Buch immer wieder darauf hinzuweisen, dass sich Images aus bzw. über öffentlichen Quellen wie dem Docker Hub grundsätzlich nicht für Produktivumgebungen eignen, und in diesem Zusammenhang gibt es hier einen eigenen Abschnitt über eigene Trusted Images (4.7), der aber – wie ein Hinweis sagt – ggf. auch erst einmal übersprungen werden kann. Der Abschnitt 4.8 handelt dann von dem lokalen Betrieb von Docker-Containern, wobei hauptsächlich die Optionen des zugehörigen CLI-Werkzeuges abgehandelt werden. Die mit Docker 1.13 eingeführten gruppierenden Subkommandos werden dabei immer parallel zu der einfacheren Form ohne diese angegeben, die bisher noch weiterhin verfügbar sind.

Weitere Abschnitte widmen sich der Verwaltung von Prozessen in Container-Instanzen (4.9) und dem Logging (4.10). Als Beispiel für das Management von Containern dient dabei ein CentOS-Basisimage, ab 4.11 geht es dann spezieller um den Betrieb von Applikationen in einem Container, was anhand eines Apache-Webserver besprochen wird. Der Autor beschreibt dann weiterhin sehr ausführlich, wie eigene Image-Modifikationen eingebucht und getaggt werden (4.12), um ein neues Image damit zu erzeugen. Hier wird auch das Schema für Image-Kennzeichnungen besprochen (4.2.12), und auch eventuelle Probleme mit dem automatisch vergebenen, vom Sinn her leeren “latest”-Tag. Ein eigener Abschnitt geht dann auf die Schichten von Container-Images ein (4.13), und es gibt auch hier viele praktische Tips z.B. in welchem lokalen Verzeichnis auf dem Host die Images und Schichten zu finden sind, und wie der Anwender verfahren kann, wenn das Limit von 127 Layern in einem Projekt erreicht wird. Ein weiterer Abschnitt behandelt die Ressourcen-Limits von Containern (4.14), die unmittelbar über Cgroups-Manipulation, über Optionen für docker run und mittels docker update manipuliert werden können.

Das nächste und die folgenden Abschnitte beschäftigen sich dann mit dem wichtigen Thema, wie Nutzer eigene Docker Container mit Applikationen bzw. dediziert Image-Stände herstellen können, wobei zunächst das Dockerfile im Mittelpunkt steht. Als Beispiel wird dann beschrieben, wie ein CentOS-basierter Container mit Apache-Webserver aufgesetzt wird (4.15.5), als anderes Beispiel ein sshd-Container, der z.B. als Gateway-Host fungieren kann (4.15.6). Liebel gibt dann einige interessante Hinweise, wie das inaktive Systemd (in RHEL bzw. CentOS 7.x mittlerweile verwendet) im Container als Starthilfe eingesetzt werden kann (4.15.7), und eine Fülle von Hinweisen für gute Container-Images (4.16). Da wie gesagt die Docker-Grundlagen im vorliegenden Werk viel Raum einnehmen kann der Autor dann weiterhin sehr ausführlich über Docker-Networking (4.17), auf die Verknüpfung von Containern (4.18) und Docker Compose (4.19), und über das Thema “Storage-Driver” (4.20-22) und Docker-Volumes (4.23-24) schreiben.

5-7. Docker Security, Trusted Registry, Weitere Container-Plattformen

Eigene Kapitel behandeln dann die Frage nach der Sicherheit von Docker-Containern (5.) und – damit im Zusammenhang stehend – wie eigene trusted Docker-Registries aufgesetzt werden (6.). Der zweite Teil über Single Node Container-Systeme wird dann abgeschlossen mit einem eigenen Kapitel, welches noch einmal einige Lösungen jenseits des Hauptthemas “Docker auf Linux” thematisiert (7.). Darunter gehört auch ein Abschnitt über Docker unter Windows (7.2), und zwei etwas längere eigene Abschnitte zu Atomic Host (7.1) und CoreOS/Container Linux mit rkt (7.3) – wie oben geschrieben ohne Praxisbeispiele wie Container darauf eingesetzt werden.

Fortsetzung folgt.