Für meine Frau und meine Kinder, die alles lohnenswert machen.
Für meine Eltern, die mir den Weg wiesen, Logik und Leidenschaft miteinander zu vereinbaren.
Und für meine Schwester, die mir beibringt, die Welt durch die Wahrnehmung anderer zu erforschen.
– Sean P. Kane
Für meine Mutter, die mich zum Lesen brachte, und für meinen Vater, der mir vorlas.
Und für meine Frau und meine Töchter, die für mich Felsen in der Brandung sind.
– Karl Matthias
Die weitverbreitete technische Evolution, die sich um uns herum vollzieht, konzentriert sich auf ein scheinbar einfaches Tool: den Container. Etwas vom Design her so Kleines und Leichtgewichtiges hat einen gewaltigen Einfluss auf die Softwareentwicklung in allen Branchen. Und das innerhalb kürzester Zeit.
Containerisierung ist allerdings nicht neu und war es auch 2013 nicht, als Docker zum ersten Mal vorgestellt wurde. Allerdings war die Containerisierung vor Docker bei den meisten Softwareentwicklern kaum auf dem Radar. Selbst die Low-Level-Konzepte hinter Containern wurden überwiegend nur von denen verstanden, die ein tiefes Verständnis vom Linux-Kernel hatten oder bei einigen der Tech-Giganten wie Sun oder Google arbeiteten. Windows-Entwickler oder Systemadministratoren wurden generell außen vor gelassen. Heutzutage ist es schwer, ein Gespräch über eine Software zu führen, ohne Docker zu erwähnen. Aber wie sind wir zu diesem Punkt gekommen, und wo geht die Reise noch hin?
Wir nutzen Docker nicht mehr, weil es neu ist, oder nur wegen der reinen Technologie. Es wird hauptsächlich verwendet, weil es den Entwicklungsprozess beschleunigt, die Ausgaben für Infrastruktur und Overhead verringert, das Onboarding neuer Entwickler erleichtert und sogar die Barriere zwischen den Entwicklungs- und Administratorenteams reduziert. Windows-Nutzer können dank der Arbeit von Microsoft, Docker und weiteren zahlreichen Open-Source-Software-(OSS-)Anbietern nun ebenfalls von den Vorteilen von Docker profitieren.
Trotz all seiner Vorteile ist Docker jedoch nicht immer ein einfaches Tool. Man muss es richtig verstanden haben, um Cloud-Native-Anwendungen bauen und administrieren zu können. Cloud-Native-Anwendungen sind hochverfügbare, skalierbare Anwendungen, die auf Managed-Cloud-Infrastrukturen laufen. Um diese Resilienz und Skalierbarkeit zu erreichen, muss man auf Container-Orchestrierungstechnologien wie Kubernetes setzen. Zusätzlich dazu sind Cloud-Native-Anwendungen in der Regel serviceorientiert oder folgen dem Microservice-Architektur-Ansatz.
Ich werde oft gefragt, ob Docker virtuelle Maschinen (VMs) ersetzt, ob Microservice-Architekturen eine Voraussetzung sind oder ob Unternehmen lieber alles über Docker vergessen und stattdessen auf Serverless Computing setzen sollten, was immer populärer wird. Die Antwort lautet immer: Nein! Tools im Cloud-Native-Ökosystem sind ein Zusatzmittel und nicht exklusiv. Docker und VMs stehen nicht in Konkurrenz zueinander, sondern sollten gemeinsam genutzt werden, um den maximalen Nutzen herauszuziehen. Serverless Computing ist dann am sinnvollsten, wenn es mit Containern genutzt wird. Ich würde sogar behaupten, dass Serverless Computing überhaupt nicht so populär wäre, wenn es keine kurzlebigen und leichtgewichtigen Container gäbe. Microservices sind auch keine Voraussetzung für Container. Allerdings ziehen Sie mehr Vorteile aus Containern, wenn Ihre Architektur kleinere Services erlaubt.
Der Einsatz von Docker erlaubt den Entwicklern, ihre Zuständigkeiten in den Bereich der Administration auszudehnen und für das, was sie entwickelt haben, die Verantwortung zu übernehmen. Das kann die Zusammenarbeit über Abteilungsgrenzen hinweg fördern, da Details wie Abhängigkeiten auch in den Verantwortungsbereich des Entwicklungsteams fallen statt ausschließlich in den der Administratoren. Darüber hinaus sind Teams so in der Lage, bessere Artefakte zu generieren, die als Eckpunkte für die Dokumentation genutzt werden können: Ein Dockerfile und eine docker-compose.yml können zusammen die Rolle eines Leitfadens für die Inbetriebnahme des Projekts übernehmen. Neue Entwickler im Team oder Entwickler in Open-Source-Projekten können in wenigen Schritten produktiv arbeiten, wenn diese Dateien existieren. In der Vergangenheit war es oft eine mehrtägige Aufgabe, eine Entwicklungsumgebung aufzusetzen. Heutzutage können wir das mit einem einfachen, reproduzierbaren Workflow ersetzen: Docker installieren, das Repository klonen und docker-compose up laufen lassen.
Ähnlich wie das Cloud-Native-Ökosystem ein Hilfsmittel ist, sind auch viele Docker-eigene Tools praktische Hilfsmittel, und das Beherrschen der Grundlagen wird Ihnen helfen, erfolgreicher zu sein. In diesem Buch sollten Sie Kapitel 4 ganz besondere Aufmerksamkeit widmen. Dieses Kapitel beschäftigt sich mit den Container-Images inklusive der wichtigsten Datei im Projekt: dem Dockerfile. Diese Datei ist, neben den anderen Images, die Sie möglicherweise direkt von einer Image-Registry herunterladen, die Basis für Ihre Anwendung. Jeder weitere Layer, wie Container-Orchestrierung, basiert darauf, dass Sie Ihre Anwendung mittels eines Dockerfiles in einem Image paketiert haben. Sie lernen, dass jeder Anwendungscode, unabhängig von Alter, Framework, Sprache oder Architektur, in ein Container-Image paketiert werden kann.
In diesem Buch teilen Sean und Karl ihr umfangreiches kollektives Wissen, um Ihnen das breite theoretische und taktische Verständnis von Docker und dem dazugehörigen Ökosystem zu vermitteln mit dem Ziel, Ihnen zu einem erfolgreichen Start in die Containerisierung zu verhelfen. Während Docker die Entwicklungsprozesse vereinfachen und optimieren kann, ist es aber auch ein mächtiges Tool mit zahlreichen Komplexitätsschichten. Sean und Karl haben dieses Buch sorgfältig zusammengestellt, um sich auf das Wesentliche zu konzentrieren und Ihnen dabei zu helfen, schnell produktiv zu werden und trotzdem die wichtigen Grundlagen zu verstehen.
Saugen Sie das Wissen und die Erfahrung, die auf diesen Seiten geteilt werden, auf und behalten Sie dieses Buch als Nachschlagewerk. Sie werden es nicht bereuen.
-- Laura Frank Tacho
Docker Captain und Director of Engineering, CloudBees
Twitter: @rhein_wein
Es war der 15. März 2013, als Solomon Hykes, der Gründer und Geschäftsführer von dotCloud (jetzt Docker, Inc.), das Projekt Docker erstmals – ohne Vorankündigung und großes Brimborium – in einer blitzartigen Fünf-Minuten-Präsentation (http://youtu.be/wW9CAH9nSLs) auf der Python Developers Conference in Santa Clara, Kalifornien, vorstellte. Zu diesem Zeitpunkt hatten lediglich rund 40 Leute außerhalb des Unternehmens dotCloud Gelegenheit gehabt, Docker auszuprobieren.
Schon wenige Wochen nach dieser Präsentation brach ein unerwartet großer Medienrummel über das Projekt herein. Es wurde umgehend auf GitHub (https://github.com/moby/moby) als Open Source zur Verfügung gestellt, damit jedermann es herunterladen und eigene Beiträge dazu leisten konnte. Im Laufe der darauffolgenden Monate gewann Docker in der Branche zunehmend an Bekanntheit, und man bescheinigte ihm, die bisherige Art und Weise der Softwareentwicklung, -verteilung und -nutzung revolutionieren zu können. Innerhalb eines Jahres hatte praktisch jeder Branchenkundige zumindest von Docker Notiz genommen, wenngleich vielen Menschen nicht ganz klar war, was es eigentlich genau leistet und warum das so spannend ist.
Docker ist ein Tool, das eine einfache Kapselung des Erstellungsprozesses von Artefakten zur Verteilung beliebiger Anwendungen verspricht. Dabei ist das Deployment für beliebige Umgebungen skalierbar, und der Workflow sowie die Reaktionsfähigkeit der betreffenden agilen Unternehmen werden optimiert.
Diejenigen, die noch keine Erfahrung mit Docker haben, verstehen Docker vordergründig als Virtualisierungsplattform. Es leistet tatsächlich aber viel mehr. Es umspannt eine Reihe von belebten Branchensegmenten, für die bereits Lösungsansätze in Form individueller Technologien wie KVM, Xen, OpenStack, Mesos, Capistrano, Fabric, Ansible, Chef, Puppet, SaltStack usw. existieren. Wie Sie vielleicht bemerkt haben, ist die Liste der Produkte, mit denen Docker in Konkurrenz tritt, schon ziemlich aufschlussreich. Viele Administratoren würden kaum behaupten, dass Virtualisierungslösungen im Wettbewerb mit Tools für die Konfigurationsverwaltung stünden – dennoch wirkt sich Docker auf beide Technologien disruptiv aus. Dies hängt im Wesentlichen damit zusammen, dass Docker einen großen Einfluss auf die Arbeitsweise hat. Das wiederum wirkt sich stark auf die zuvor genannten traditionell voneinander isolierten Segmente in der DevOps-Pipeline aus.
Zudem werden den vorgenannten Technologien im Allgemeinen produktivitätssteigernde Eigenschaften nachgesagt, und genau deshalb wird ihnen auch so viel Aufmerksamkeit zuteil. Docker befindet sich sozusagen im Zentrum einiger der leistungsfähigsten Technologien des letzten Jahrzehnts und kann zu signifikanten Verbesserungen fast jedes Schritts der Pipeline führen.
Würden Sie Docker allerdings Punkt für Punkt mit den jeweiligen Platzhirschen der verschiedenen Einsatzbereiche vergleichen, stünde es höchstwahrscheinlich bloß wie ein mittelmäßiger Wettbewerber da. In manchen Bereichen kann Docker seine Stärken besser ausspielen als in anderen, insgesamt betrachtet decken die Features, die es mitbringt, aber ein sehr breites Anwendungsspektrum ab. Durch die Zusammenführung der Schlichtheit von Softwareverteilungstools wie Capistrano und Fabric mit der komfortablen Verwaltungshandhabung von Virtualisierungssystemen sowie optionalen Möglichkeiten zur problemlosen Implementierung der Automatisierung von Workflow und Orchestrierung stellt Docker einen sehr leistungsfähigen Satz an Features zur Verfügung.
Viele neue Technologien kommen und gehen, insofern ist eine gewisse Skepsis gegenüber den neuesten Trends durchaus angebracht. Oberflächlich betrachtet, könnte man auch Docker sicherlich einfach als eine weitere neue Technologie abtun, die sich irgendwelcher speziellen Probleme annimmt, mit denen Entwickler und Administratoren konfrontiert sind. Und wenn Sie es lediglich als Pseudo-Virtualisierungs- oder Deployment-Technologie sehen, erscheint es womöglich wirklich nicht besonders reizvoll. Allerdings leistet Docker sehr viel mehr als nur das, was es auf den ersten Blick zu erkennen gibt.
Die Kommunikation und Workflows mehrerer Teams zu koordinieren, ist oftmals selbst in kleineren Unternehmen und Organisationen schwierig und teuer. Dessen ungeachtet kommt dem detaillierten Informationsaustausch zwischen den Teams jedoch immer mehr Bedeutung für ein erfolgreiches Arbeiten zu. Die Entdeckung und Implementierung eines Tools, das diese Kommunikation erleichtert und gleichzeitig dazu beiträgt, stabilere Software zu produzieren, wäre also von enormem Nutzen – und genau deswegen ist Docker einen zweiten Blick wert. Natürlich ist es kein Wundermittel, und seine zielführende Implementierung will wohlüberlegt sein, trotzdem ist Docker ein guter Ansatz, um in der Praxis auftretende organisatorische Probleme zu lösen und einem Unternehmen das zügigere Deployment besserer Software zu ermöglichen. Abgesehen davon kann ein gut geplanter Docker-Workflow auch zufriedenere Teams und spürbare Kosteneinsparungen zur Folge haben.
Wo also treten die größten Schwierigkeiten auf? Software in dem Tempo auszuliefern, das heutzutage gefordert wird, ist nicht leicht – und wenn ein Unternehmen wächst und aus zwei oder drei Entwicklern mehrere Entwicklerteams werden, wird es auch zunehmend schwieriger, die Kommunikation hinsichtlich des Deployments neuer Softwareversionen zu koordinieren. Die Entwickler müssen möglichst weitreichende Kenntnisse von der Umgebung besitzen, in der ihre Software laufen soll, und die Administratoren müssen ihrerseits immer umfassender mit der internen Funktionsweise der ausgelieferten Software vertraut sein. Im Allgemeinen ist es durchaus vernünftig, diese Kenntnisse kontinuierlich weiter zu vertiefen, weil das letztlich zu einem besseren Verständnis der Softwareumgebung insgesamt führt und somit das Design stabilerer Software ermöglicht. Allerdings ist dieses Wissen nur sehr schwer skalierbar, wenn das Wachstum eines Unternehmens zunimmt.
Die spezifischen Details einer Softwareumgebung bedingen oft eine Menge Kommunikation, die für die beteiligten Teams nicht immer unmittelbar von Nutzen ist. Wenn beispielsweise ein Entwicklerteam darauf warten muss, dass ein Administratorenteam irgendeine Library in der Version 1.2.1 deployt, kommt es zunächst nicht weiter – und für das betroffene Unternehmen bedeutet das verlorene Arbeitszeit. Könnten die Entwickler die Version der verwendeten Library hingegen einfach selbst aktualisieren und dann ihren Code schreiben, testen und ausliefern, würde sich die Zeit bis zum Deployment deutlich verkürzen, und es bestünden darüber hinaus geringere Risiken beim Deployment der Änderung. Und wenn umgekehrt die Administratorenteams die Software auf dem Host aktualisieren könnten, ohne sich mit mehreren Entwicklerteams abstimmen zu müssen, ginge es ebenfalls schneller voran. Docker unterstützt die Möglichkeit, die Software so zu isolieren, dass weniger Kommunikation zwischen den beteiligten Teams erforderlich ist.
Docker reduziert aber nicht nur die notwendige Kommunikation, sondern wirkt sich auch hinsichtlich der Softwarearchitektur recht bestimmend aus und begünstigt Anwendungen, die besonders stabil ausgelegt sind. Seine architektonische Philosophie stellt atomare Container oder Wegwerf-Container in den Mittelpunkt. Beim Deployment wird die gesamte laufende Umgebung der alten Anwendung zusammen mit der Anwendung selbst weggeworfen. Nichts in der Umgebung der alten Anwendung überlebt länger als die Anwendung selbst – eine einfache Idee mit großem Effekt. Auf diese Weise wird es äußerst unwahrscheinlich, dass eine Anwendung versehentlich auf irgendwelche Überbleibsel einer vorhergehenden Version zugreift. Und auch beim Debuggen vorgenommene kurzlebige Änderungen können so keinen Eingang in künftige Versionen finden, indem sie vom lokalen Dateisystem eingelesen werden. Außerdem sind Anwendungen dadurch hochgradig portabel und lassen sich leicht auf einen anderen Server verschieben, denn alle Zustände müssen unveränderlicher Bestandteil des Deployment-Artefakts sein oder an einen externen Speicherort wie eine Datenbank, einen Cache oder einen Dateiserver übergeben werden.
Die Anwendungen sind somit nicht nur besser skalierbar, sondern auch zuverlässiger – und die Instanzen eines Anwendungscontainers können kommen und gehen, ohne dass sich dies großartig auf die Verfügbarkeit des Frontends auswirken würde. Hierbei handelt es sich um erprobte architektonische Entscheidungen, die sich bei Anwendungen bewährt haben, in denen Docker nicht zum Einsatz kommt. Docker hat diese Designentscheidungen übernommen und gewährleistet somit, dass sich Anwendungen, in denen das Projekt genutzt wird, im Bedarfsfall ebenfalls dementsprechend verhalten – was nur vernünftig ist.
Es ist nicht einfach, all die Möglichkeiten, die Docker mitbringt, in sinnvoll zusammenhängende Kategorien einzuordnen. Eine gut vollzogene Implementierung verschafft dem Unternehmen als Ganzes sowie den Teams, den Entwicklern und den Administratoren im Besonderen zahlreiche Vorteile. Sie vereinfacht architektonische Designentscheidungen, weil alle Anwendungen aus der Perspektive des Hostsystems von außen betrachtet im Wesentlichen gleich aussehen. Außerdem fällt es leichter, Toolings zu erstellen, die von mehreren Anwendungen gemeinsam genutzt werden können. Alles auf dieser Welt hat Vor- und Nachteile, im Fall von Docker ist es aber schon erstaunlich, wie sehr die Vorteile überwiegen. Im Folgenden sind einige der Vorteile beschrieben, die Docker Ihnen bietet:
Vorhandene Fertigkeiten der Entwickler fließen vollumfänglich in die Erstellung von Softwarepaketen mit ein.
In vielen Unternehmen mussten für die Erstellung von Softwarepaketen für die jeweils zu unterstützenden Plattformen eigens Stellen für Release und Build Engineers geschaffen werden, die über die erforderlichen Kenntnisse im Umgang mit den entsprechenden Toolings verfügen. Der Einsatz von Tools wie rpm, mock, dpkg oder pbuilder kann ziemlich kompliziert sein und muss jeweils individuell erlernt werden. Docker schnürt alle von Ihnen benötigten Bestandteile zu einem Paket zusammen, das aus nur einer einzigen Datei besteht.
Anwendungssoftware und erforderliche Betriebssystemdateien werden in einem standardisierten Image-Format gebündelt.
Früher musste ein Paket nicht nur die eigentliche Anwendung enthalten, sondern darüber hinaus auch viele weitere Dateien, auf die sie angewiesen war, wie z.B. Libraries oder Daemons. Trotzdem konnte man sich nie sicher sein, dass Ausführungs- und Entwicklungsumgebung zu 100 Prozent übereinstimmten. Für nativ kompilierten Code bedeutete dies, dass das Build-System exakt die gleichen Versionen der Shared Libraries haben musste wie die Produktivumgebung. Dies erschwerte die Paketierung und bereitete vielen Unternehmen Probleme, verlässlich funktionierende Pakete zu liefern. Oftmals versuchen Entwickler, die die (auf Red Hat basierende) Linux-Distribution Scientific Linux verwenden, in der Hoffnung, dass beide Distributionen einander ähnlich genug sind, ein unter Red Hat getestetes Paket zum Laufen zu bekommen. Mit Docker wird die Anwendung allerdings bereits inklusive aller für die Ausführung erforderlichen Dateien zur Verfügung gestellt. Dank der mehrschichtigen Images (Overlays), die an dieser Stelle zum Einsatz kommen, handelt es sich hierbei um einen effizienten Vorgang, der gewährleistet, dass Ihre Anwendung in der erwarteten Umgebung läuft.
Pakete werden mit exakt gleichen Artefakten zum Testen und Ausliefern für alle Systeme in allen Umgebungen benutzt.
Wenn Entwickler über eine Versionsverwaltung Änderungen einchecken, kann ein neues Docker-Image erstellt werden, das den vollständigen Überprüfungsvorgang durchläuft und an die Produktivumgebung ausgeliefert wird, ohne dass dabei eine Neukompilierung oder die Erstellung eines neuen Pakets erforderlich wäre, es sei denn, dies ist speziell gewünscht.
Abstraktion von Softwareanwendungen von der Hardware, ohne Ressourcen zu opfern.
Wenn ein Abstraktionslayer zwischen der physischen Hardware und der darauf laufenden Softwareanwendung erforderlich ist, werden typischerweise herkömmliche Virtualisierungslösungen wie VMware eingesetzt – zum Preis eines höheren Ressourcenbedarfs: Der Hypervisor, der die VMs verwaltet, sowie alle laufenden VM-Kernel nutzen einen bestimmten Prozentsatz der Hardwareressourcen des Systems, die den Anwendungen dann nicht mehr zur Verfügung stehen. Ein Container hingegen ist einfach nur ein weiterer, direkt mit dem Linux-Kernel kommunizierender Prozess, der daher mehr Ressourcen in Anspruch nehmen kann, bis er an die systemseitig vorgegebene oder ihm zugewiesene Kontingentsgrenze stößt.
Zum Zeitpunkt des ursprünglichen Docker-Releases existierten Linux-Container bereits seit einigen Jahren, und auch viele der anderen Technologien, auf denen Docker beruht, sind nicht völlig neu. Allerdings bildet die einzigartige Mischung der nachhaltigen Designentscheidungen hinsichtlich Architektur und Workflow hier ein großes Ganzes, das erheblich leistungsfähiger ist als die Summe seiner Teile. Docker gewährt dem durchschnittlichen Software-Engineer Zugang zu den seit 2008 verfügbaren Linux-Containern. Es gestattet die relativ einfache Integration von Linux-Containern in den bereits vorhandenen Workflow bzw. die Prozessabläufe eines Unternehmens. Tatsächlich waren offenbar derart viele Menschen von den oben beschriebenen Schwierigkeiten betroffen, dass das Interesse an Docker schneller zunahm, als man vernünftigerweise hätte erwarten dürfen.
Seit seinem Start vor nur wenigen Jahren hat Docker bereits einige Iterationen gesehen, verfügt nun über eine Fülle an Funktionen und läuft weltweit in einer großen Anzahl von Produktivumgebungen. Es entwickelte sich sehr schnell zu einem der Grundsteine jedes modernen verteilten Systems. Eine Vielzahl von Unternehmen ziehen Docker als Lösung für ernst zu nehmende Probleme in Betracht, mit denen sie sich im Rahmen des Deployments ihrer Anwendungen konfrontiert sehen.
Docker ist für eine breite Palette von Problemstellungen geeignet, für deren Lösung in der Vergangenheit üblicherweise Tools anderer Kategorien herangezogen wurden. Diese Vielseitigkeit bedingt es oftmals aber auch, dass die Funktionalität in bestimmten Bereichen nicht allzu tief greifend ausgeprägt ist. So werden manche Unternehmen feststellen, dass sie komplett auf ihre Tools für die Konfigurationsverwaltung verzichten können, wenn sie Docker einsetzen. Es kann zwar durchaus einige der Aufgaben herkömmlicher Tools übernehmen – seine wahre Stärke zeigt sich jedoch darin, dass es in der Regel mit ihnen kompatibel ist oder sich durch sie ergänzen lässt. Im Folgenden stellen wir einige der Toolkategorien vor, die Docker zwar nicht unmittelbar ersetzt, die sich aber in Kombination verwenden lassen. Auf diese Weise können oft hervorragende Ergebnisse erzielt werden.
Enterprise-Virtualisierungsplattform (VMware, KVM usw.)
Ein Container ist keine virtuelle Maschine (kurz VM) im herkömmlichen Sinn. Virtuelle Maschinen enthalten ein vollständiges Betriebssystem, das von einem Hypervisor betrieben wird, der innerhalb des Host-Systems ausgeführt wird. Der größte Vorteil gegenüber der Hardwarevirtualisierung besteht darin, dass es problemlos möglich ist, mehrere virtuelle Maschinen mit völlig anderen Betriebssystemen auf einem einzelnen Host auszuführen. Bei einem Container teilen sich der Host und der Container denselben Kernel – das bedeutet, dass der Container weniger Ressourcen belegt als eine VM, aber auf demselben Betriebssystem (z.B. Linux) beruhen muss wie der Host.
Cloud-Plattform (OpenStack, CloudStack usw.)
Ebenso wie bei Enterprise-Virtualisierungsplattformen haben – oberflächlich gesehen – Container-Workflows und Cloud-Plattformen viele Gemeinsamkeiten. Beide werden typischerweise für die horizontale Skalierung eingesetzt, um wechselndem Leistungsbedarf Rechnung zu tragen. Docker ist allerdings keine Cloud-Plattform, sondern handhabt das Deployment, die Ausführung und die Verwaltung von Containern auf bereits vorhandenen Docker-Hosts. Es ist nicht möglich, neue Hosts (Instanzen), neue Objektspeicher, neuen Speicherplatz oder eine der anderen typischerweise auf einer Cloud-Plattform verfügbaren Ressourcen zu erstellen. Wenn Sie Docker-Tooling ausweiten, werden Sie mehr und mehr von den Vorteilen profitieren, die traditionell mit der Cloud assoziiert werden.
Konfigurationsverwaltung (Puppet, Chef usw.)
Docker kann zwar die Möglichkeiten zur Administration von Anwendungen und deren Abhängigkeiten erheblich verbessern, ist aber kein direkter Ersatz für eine herkömmliche Konfigurationsverwaltung. Dockerfiles legen fest, wie ein fertiger Container zur Build-Zeit aussehen soll, haben aber keinen Einfluss auf den aktuellen Zustand und können auch nicht verwendet werden, um das Docker-Host-System zu verwalten. Nichtsdestotrotz kann die Nutzung von Docker dazu führen, dass die Komplexität von Konfigurationsverwaltungscode deutlich reduziert wird. Allein dadurch, dass mehr und mehr Server einfach zu Docker-Hosts werden, wird der Code der Konfigurationsverwaltung viel kleiner, und Docker kann anschließend dafür verwendet werden, die komplexen Anforderungen einer Anwendung innerhalb von Docker-Images auszurollen.
Deployment-Framework (Capistrano, Fabric usw.)
Docker erleichtert viele Aspekte des Deployments, indem es eigenständige Container-Images erstellt, die alle Abhängigkeiten einer Anwendung kapseln und ohne weitere Anpassungen für alle Umgebungen geeignet sind. Es kann jedoch nicht verwendet werden, um die komplexen Deployments selbst zu automatisieren. Für die Aneinanderreihung umfangreicherer automatisierter Workflows werden im Allgemeinen zusätzliche Tools benötigt. Diese Methode verlangt, dass alle deployten Container auf allen Hosts konsistent ausgerollt werden. Ein einziger Deployment-Workflow würde für die meisten – wenn nicht sogar alle – Docker-basierten Anwendungen ausreichen.
Workload-Manager (Mesos, Kubernetes, Swarm usw.)
Ein Orchestrierungslayer (inklusive des eingebauten Swarm-Modus) muss genutzt werden, wenn man die Workload auf einen Pool von Docker-Hosts intelligent verteilen möchte. Er trackt den aktuellen Status aller Hosts und der genutzten Ressourcen und unterhält ein Inventar von allen laufenden Containern.
Entwicklungsumgebung (Vagrant usw.)
Vagrant ist ein Developer-Tool zur Verwaltung virtueller Maschinen, das häufig zur Simulation einer Serverumgebung genutzt wird, die der echten Produktivumgebung, in der eine Anwendung laufen soll, sehr ähnlich ist. Unter anderem vereinfacht Vagrant die Ausführung von Linux-Software auf Rechnern mit Windows oder macOS. Docker Machine ist für viele Standard-Docker-Workflows ausreichend. Es bringt allerdings nicht die breite Palette an Funktionen mit, die in Vagrant zu finden sind, da es sehr stark auf den speziellen Docker-Workflow ausgerichtet ist. Wie auch bei vielen der vorherigen Beispiele ist es allerdings nicht notwendig, eine breite Palette von Produktivumgebungen in der Entwicklungsumgebung zu simulieren, wenn Sie Docker einsetzen. Dies hängt damit zusammen, dass die meisten Produktivumgebungen einfache Docker-Server sein werden, die auch leicht lokal gebaut werden können.
Hier werden einige Begrifflichkeiten kurz genannt und erläutert, die im weiteren Verlauf des Buchs verwendet werden:
Docker-Client
Das ist der docker-Befehl, der im Docker-Workflow am meisten genutzt wird, um mit Docker-Servern zu arbeiten.
Docker-Server
Das ist der dockerd-Befehl, der genutzt wird, um den Docker-Server-Prozess zu starten, der über einen Client Container baut und startet.
Docker-Image
Docker-Images bestehen aus einem oder mehreren Dateisystemlayern, angereichert mit einigen wichtigen Metadaten, die alle Dateien repräsentieren, die eine dockerisierte Anwendung benötigt. Ein einzelnes Docker-Image kann auf zahlreiche Hosts kopiert werden. Ein Image hat üblicherweise sowohl einen Namen als auch ein Tag. Das Tag wird generell zur Identifizierung einer spezifizierten Version eines Images nutzt.
Docker-Container
Ein Docker-Container ist ein Linux-Container, der von einem Docker-Image instanziiert wird. Ein spezifischer Container existiert genau ein einziges Mal. Allerdings kann es mehrere Container von ein und demselben Image geben.
Atomic Host
Ein Atomic Host ist ein kleines Betriebssystemabbild wie Fedora CoreOS (https://getfedora.org/en/coreos/), das das Hosting von Containern erlaubt sowie Image-basierte (atomic) Betriebssystem-Upgrades ermöglicht.
Sofern Sie nicht den entsprechenden beruflichen Hintergrund besitzen, ist es nicht ganz einfach, Docker zu verstehen. Im folgenden Kapitel geben wir Ihnen einen umfangreichen Überblick darüber, was Docker eigentlich leistet, wie es eingesetzt werden sollte und welche Vorteile Sie erzielen können, wenn Sie all das bei der Implementierung berücksichtigen.
Sean P. Kane ist zur Zeit Lead Site Reliability Engineer bei New Relic. Er war lange als IT-Techniker tätig und hat in sehr breit gefächerten Industriebranchen (Biotechnologie, Verteidigungswesen, Hightechunternehmen) viele verschiedene Posten bekleidet. Zusätzlich zu seinen Tätigkeiten als Autor, Tutor und Speaker über moderne Systemadministration in produktiven Umgebungen ist er begeisteter Urlauber, Wanderer und Camper. Er lebt mit seiner Frau, seinen Kindern und Hunden im pazifischen Nordwesten der USA.
Karl Matthias ist Director of Cloud and Platform Services bei InVision. Zuvor war er Principal Systems Engineer bei Nitro Software und war in den letzten 20 Jahren als Entwickler, Systemadministrator und Netzwerktechniker für Start-ups und verschiedene Fortune-500-Unternehmen tätig. Nach einigen Jahren in Start-ups in Deutschland und Großbrittannien, mit einem kurzem Aufenthalt in seiner Heimat in Portland, Oregon, wohnt er mit seiner Familie in Dublin in Irland. Wenn er sich nicht gerade mit digitalen Dingen beschäftigt, verbringt er seine Zeit mit seinen zwei Töchtern, mit dem Fotografieren mit Vintage Kameras oder fährt eines seiner Fahrräder.
Bevor Sie anfangen, Docker zu installieren und zu konfigurieren, soll an dieser Stelle kurz erläutert werden, was es eigentlich genau damit auf sich hat und was es leistet. Im Prinzip handelt es sich um eine sehr effiziente Technologie, die gar nicht mal so kompliziert ist. In diesem Kapitel stellen wir die allgemeine Funktionsweise von Docker vor, erläutern, warum es so leistungsfähig ist, und liefern Ihnen einige Argumente, die für seine Verwendung sprechen. Aufgrund der Tatsache, dass Sie dieses Buch lesen, ist zwar zu vermuten, dass Sie bereits mindestens einen guten Grund gefunden haben, Docker zu benutzen, dennoch kann es ja keinesfalls schaden, Ihre Kenntnisse noch ein wenig zu erweitern, bevor Sie richtig loslegen. Und keine Sorge: Dieses Kapitel wird Sie nicht lange aufhalten. Schon das nächste Kapitel hat die Installation und die Inbetriebnahme von Docker auf Ihrem System zum Inhalt.
Auf den ersten Blick ist es nicht offensichtlich, dass Docker einen großen positiven Einfluss auf das Unternehmen und die Teamprozesse haben kann, wenn es richtig eingeführt wird – schließlich ist Docker doch auch nur eine Software. Es ist daher Zeit, tiefer einzusteigen und zu erfahren, wie Docker sowohl die Kommunikation als auch die Workflows vereinfachen kann. Das beginnt für gewöhnlich mit dem Deployment. Um eine Anwendung in den Produktivbetrieb zu übernehmen, werden traditionell die folgenden Schritte unternommen (siehe Abbildung 2.1):
Die Anwendungsentwickler fordern bestimmte Ressourcen von den Administratoren an.
Die gewünschten Ressourcen werden den Entwicklern zur Verfügung gestellt.
Die Entwickler erstellen Skripte und bereiten das Deployment vor.
Administratoren und Entwickler stimmen das Deployment miteinander ab und nehmen wiederholt Modifikationen und Verbesserungen vor.
Die Entwickler entdecken weitere Abhängigkeiten.
Die Administratoren arbeiten daran, zusätzliche Anforderungen zu erfüllen.
Die Schritte 5 und 6 werden N-mal wiederholt.
Das Deployment der Anwendung ist vollzogen.
Abb. 2.1: Ein typischer Workflow beim Deployment ohne Docker
Unserer Erfahrung nach dauert das Deployment einer nagelneuen Anwendung auf traditionelle Art und Weise bei komplexen Produktivsystemen nicht selten fast eine Woche. Das ist nicht sehr ertragreich, und obwohl einige Hindernisse mithilfe verschiedener DevOps-Praktiken umgangen werden könnten, ist dies oftmals dennoch mit großem Aufwand und einer Menge Kommunikation zwischen den Teams verbunden. Derartige Vorgänge sind in der Regel nicht nur technisch anspruchsvoll, sondern auch kostspielig. Noch schlimmer ist allerdings, dass sie sich nachteilig auf die Bereitschaft der Entwicklerteams auswirken, zukünftig Innovationen umzusetzen. Wenn das Deployment schwierig, zeitraubend und von der Verfügbarkeit der Ressourcen anderer Teams abhängig ist, werden die Entwickler vielmehr versuchen, möglichst alles in die vorhandene Anwendung einzubauen, um dem lästigen und umständlichen neuen Deployment zu entgehen.
Systeme wie Heroku (https://www.heroku.com), die ein Deployment quasi auf Knopfdruck durchführen, haben den Entwicklern gezeigt, wie einfach ihr Leben sein kann, wenn sie selbst für den überwiegenden Teil der Abhängigkeiten ihrer Anwendung verantwortlich sind. Unterhält man sich mit ihnen über dieses Thema, führt das nicht selten zu einer Debatte darüber, wie reibungslos das Deployment bei Heroku und ähnlichen Systemen ablaufen könnte. Und wenn Sie zum Administratorenteam gehören, sind Ihnen vermutlich auch schon einige Klagen darüber zu Ohren gekommen, um wie viel langsamer Ihre internen Systeme im Vergleich zum Deployment mit Heroku sind.
Heroku ist eine vollständige Umgebung und nicht nur eine Container-Engine. Nun erhebt Docker keineswegs den Anspruch, alle Funktionen von Heroku abzudecken, aber es sorgt für eine klare Trennung zwischen den Zuständigkeiten und der Verkapselung von Abhängigkeiten, was die Produktivität in ähnlicher Weise steigert. Außerdem ermöglicht Docker eine noch feiner abgestimmte Steuerung als Heroku, weil der Entwickler hier praktisch für alles selbst verantwortlich ist – bis hin zur Betriebssystemdistribution, auf der die Anwendung laufen soll. Einige der inzwischen verfügbaren Orchestrierungstools wie Kubernetes, Swarm oder Mesos, die auf Docker aufbauen, versuchen, die Einfachheit von Heroku zu kopieren. Aber auch diese Plattformen bündeln noch mehr Funktionen um Docker herum, um eine höhere Leistungsfähigkeit zu erreichen, was wiederum zu einer komplexen Umgebung führt. Eine einfache Plattform, die nur Docker unterstützt, besitzt trotzdem alle Prozesse, ohne eine hohe Komplexität hinzuzufügen.
Als Unternehmen verfolgt Docker einen Ansatz, den man mit »Batterien sind im Lieferumfang enthalten, aber entnehmbar« beschreiben könnte. Soll heißen: Docker wird mit allen Tools ausgeliefert, die typischerweise zur Erledigung anfallender Aufgaben nötig sind, wobei einzelne Komponenten jedoch leicht ausgetauscht werden können, um auch benutzerdefinierte Lösungen zu ermöglichen.
Docker verwendet zur Übergabe von Images ein Repository und gestattet es so, die Zuständigkeit für die Image-Erstellung vom Deployment und dem Betrieb des Containers zu trennen.
In der Praxis ermöglicht dies den Entwicklerteams, ihre Anwendung inklusive aller Abhängigkeiten zu erstellen, sie in Entwicklungs- und Testumgebungen zu überprüfen und dann genau dieses Paket aus Anwendung und Abhängigkeiten für die Produktivumgebung freizugeben. Da solche Pakete von außen betrachtet immer gleich aussehen, kann das Administratorenteam für das Deployment und den Betrieb der Anwendungen Standardtools einsetzen. Der in Abbildung 2.2 beschriebene Workflow sieht dann in etwa so aus:
Die Entwickler erstellen das Docker-Image und liefern es bei der Registry ab.
Die Administratoren stellen sowohl Konfigurationsinformationen für den Container als auch Ressourcen zur Verfügung.
Die Entwickler veranlassen das Deployment.
Abb. 2.2: Workflow beim Deployment mit Docker
Möglich wird das Ganze dadurch, dass Docker es gestattet, alle durch Abhängigkeiten verursachten Probleme schon während der Entwicklungsphase und beim Testen der Anwendung aufzuspüren. Zum Zeitpunkt des ersten Deployments ist diese Arbeit also bereits erledigt. Darüber hinaus sind für gewöhnlich weniger Handover zwischen dem Entwicklerteam und dem Administratorenteam erforderlich. Das stellt eine beträchtliche prozedurale Vereinfachung dar und spart viel Zeit. Und was noch besser ist: Die Tests der Deployment-Umgebung vor dem Release führen letztendlich zu einer stabileren Software.
Docker wird bereits gut unterstützt, immerhin hat die Mehrheit der großen Public Cloud Provider ihren direkten Support zumindest angekündigt. Es läuft auf AWS über mehrere Produkte, wie Elastic Container Service (ECS), Elastic Container Service for Kubernetes (EKS), Fargate und Elastic Beanstalk. Docker lässt sich zudem unter anderem über Google AppEngine, Google Kubernetes Engine, Red Hat OpenShift, IBM Cloud, Microsoft Azure, Rackspace Cloud und Dockers eigene Docker-Cloud nutzen. Auf der DockerCon 2014 kündigte Eric Brewer außerdem an, dass Google Docker als primäres internes Container-Format unterstützen wird. Und dabei handelt es sich nicht nur um gute PR für die beiden Unternehmen – vielmehr profitiert die Docker-Community spürbar davon, dass sehr viel Geld in die Stabilität und den Erfolg der Docker-Plattform investiert wurde.
Damit baut Docker seinen Einfluss weiter aus, denn seine Container sind im Begriff, zum gängigen gemeinsam genutzten Format der großen Cloud Provider zu werden, und bieten Potenzial für »Einmal schreiben, überall ausführen«-Cloud-Anwendungen. Als Docker auf der DockerCon 2014 den Startschuss für das Release der Development Library libswarm gab, führte ein Entwickler von Orchard das gleichzeitige Deployment eines Docker-Containers auf einer heterogenen Zusammenstellung verschiedener Cloud Provider vor. Diese Art von Orchestrierung war früher alles andere als einfach, da jeder Cloud Provider unterschiedliche APIs oder andere Tools für das Managen von Instanzen bereitstellte, die normalerweise das kleinste Element waren, das man mit einer API verwalten konnte. Was 2014 lediglich ein Versprechen von Docker war, ist mittlerweile zum Mainstream geworden, da viele große Firmen weiterhin in die Plattform, den Support und das Tooling investieren. Da die meisten Cloud Provider eine Form von Docker-Orchestrierung ebenso anbieten wie eine Container-Runtime, wird Docker selbst sehr gut für jede mögliche Art von Anwendung in gängigen Produktivumgebungen unterstützt. Wenn Ihr gesamtes Tooling um Docker herum gebaut ist, können Sie Ihre Anwendungen unabhängig von irgendeiner Cloud einfach mit neuer Flexibilität deployen, was vorher nicht möglich war.
So viel also zu den Docker-Containern und -Toolings, aber wie sieht es mit dem Support durch die Betriebssystemhersteller und deren Akzeptanz aus? Der Docker-Client läuft auf den meisten wichtigen Betriebssystemen, und der Server kann unter Linux- und Windows-Servern laufen. Der Großteil des Ökosystems nutzt Linux-Server, aber auch andere Plattformen bekommen langsam, aber sicher Unterstützung. Der eingeschlagene Pfad führt aber höchstwahrscheinlich weiterhin über Linux-Server.
Hinweis
Es ist tatsächlich möglich, Windows-Container nativ (also ohne virtuelle Maschine) auf 64-Bit-Versionen von Windows Server 2016 zu betreiben. Allerdings benötigt Windows Server 2016 weiterhin Hyper-V, um den Windows-Server-Kernel bereitzustellen, der für die Windows-Container genutzt wird. Ein paar mehr Details finden sich im Abschnitt 5.9 (Windows-Container).
Um den gestiegenen Bedarf an Docker-Tooling in Entwicklungsumgebungen zu unterstützen, hat Docker einfach nutzbare Implementierungen für macOS und Windows bereitgestellt. Diese scheinen zwar nativ zu laufen, nutzen im Hintergrund aber einen Linux-Kernel. Docker wurde ursprünglich mit der Linux-Distribution Ubuntu entwickelt, inzwischen werden jedoch größtenteils auch die anderen großen Linux-Distributionen unterstützt, sofern es möglich ist. Red Hat nutzte bislang in all seinen Plattformen Docker als Container-Runtime – dies änderte sich erst ab OpenShift 4.
In den ersten Jahren nach dem Release von Docker äußerte sich eine Reihe von Wettbewerbern kritisch über Dockers proprietäres Image-Format. Container auf Linux hätten kein standardisiertes Format, so Docker, Inc., daher entwickelten sie ein eigenes Format nach ihren Anforderungen.
Service Provider und kommerzielle Anbieter waren zu Beginn zurückhaltend darin, Plattformen zu bauen, die sich auf gewisse Art mit ihren bisherigen Interessen überschneiden. Knapp zwei Jahre nach seinem Release hat sich Docker bereits auf breiter Front den Support zahlreicher Plattformen gesichert – und half bei der Gründung der Open Container Initiative im Juni 2015. Die erste vollständige Spezifikation von dieser Arbeit wurde im Juli 2017 veröffentlicht und basierte zu großen Teilen auf der zweiten Version von Dockers Image-Format. Die OCI arbeitet an einem Zertifizierungsprozess, und somit wird es bald möglich sein, die Implementierungen zertifizieren zu lassen. Inzwischen gibt es mindestens vier Container-Runtimes, die nach eigenen Angaben die Spezifikation unterstützen: runc, ein Teil von Docker, railcar, eine alternative Implementierung von Oracle, Kata-Container (vorher Clear-Container) von Intel, Hyper und die OpenStack Foundation, die einen Mix aus Containern und virtuellen Maschinen unterstützt, sowie die gVisor-Runtime von Google, die komplett im Userspace implementiert ist. Die Liste wird wahrscheinlich wachsen, wenn man zum Beispiel die Pläne von CoreOS für rkt anschaut, das ebenfalls OCI-kompatibel werden möchte.
Das Deployment und die Orchestrierung von vollständigen Systemen mit Containern werden stetig größer. Viele der Tools stehen unter einer Open-Source-Lizenz und sind sowohl in der Private und Public Cloud als auch als Software as a Service bei verschiedenen Anbietern verfügbar. Angesichts der hohen Investitionen, die in Docker fließen, ist es wahrscheinlich, dass es sich weiter in das Gefüge des modernen Internets einfügen wird.