InhaltsverzeichnisDocker-eigene Tools praktische Hilfsmittel, und das Beherrschen der Grundlagen wird Ihnen helfen, erfolgreicher zu sein. In diesem Buch sollten Sie Kapitel 4 ganz

7

Inhaltsverzeichnis

Vorwort. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Über die Autoren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19Wer sollte dieses Buch lesen? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19Warum überhaupt dieses Buch lesen?. . . . . . . . . . . . . . . . . . . . . . . . . 19Aufbau des Buchs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20Konventionen dieses Buchs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21Danksagungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

1 Einführung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251.1 Die Entstehung von Docker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251.2 Das Docker-Versprechen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

1.2.1 Vorteile des Docker-Workflows . . . . . . . . . . . . . . . . . . . . . . . . 281.3 Was Docker nicht ist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301.4 Wichtige Begrifflichkeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321.5 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

2 Docker im Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332.1 Workflows vereinfachen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332.2 Umfassender Support und breite Akzeptanz . . . . . . . . . . . . . . . . . . . 362.3 Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

2.3.1 Das Client-Server-Modell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392.3.2 Netzwerk-Ports und Unix-Sockets . . . . . . . . . . . . . . . . . . . . . 402.3.3 Stabiles Tooling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402.3.4 Dockers Kommandozeilentool . . . . . . . . . . . . . . . . . . . . . . . . 412.3.5 Docker-Engine-API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422.3.6 Container-Netzwerk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

2.4 Docker ausreizen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442.4.1 Container sind keine virtuellen Maschinen . . . . . . . . . . . . . . 452.4.2 Beschränkte Isolierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462.4.3 Container sind leichtgewichtig . . . . . . . . . . . . . . . . . . . . . . . . 472.4.4 Unveränderliche Infrastruktur . . . . . . . . . . . . . . . . . . . . . . . . 472.4.5 Zustandslose Anwendungen . . . . . . . . . . . . . . . . . . . . . . . . . . 48

© des Titels »Docker« (ISBN 9783958459380) 2020 by mitp Verlags GmbH & Co. KG, Frechen. Nähere Informationen unter: http://www.mitp.de/938

Inhaltsverzeichnis

8

2.4.6 Zustände externalisieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 492.5 Der Docker-Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

2.5.1 Versionsverwaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 512.5.2 Anwendungen erstellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 522.5.3 Testen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

2.5.4 Paketierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 542.5.5 Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 552.5.6 Das Docker-Ökosystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

2.6 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

3 Docker installieren. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593.1 Der Docker-Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

3.1.1 Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 603.1.2 macOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 623.1.3 Microsoft Windows 10 Professional . . . . . . . . . . . . . . . . . . . . 63

3.2 Der Docker-Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 643.2.1 Linux mit systemd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 643.2.2 Server, die nicht auf Linux-VMs basieren . . . . . . . . . . . . . . . . 64

3.3 Installation testen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 753.3.1 Ubuntu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 763.3.2 Fedora . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 763.3.3 Alpine Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

3.4 Docker-Server erkunden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 763.5 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

4 Docker-Images verwenden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 794.1 Der Aufbau eines Dockerfiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 794.2 Erstellen eines Images. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 844.3 Fehlerbehebung bei fehlgeschlagenen Builds . . . . . . . . . . . . . . . . . . . 894.4 Ausführen eines Images . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

4.4.1 Umgebungsvariablen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 934.5 Benutzerdefinierte Base-Images . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 944.6 Images speichern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

4.6.1 Öffentliche Registries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 954.6.2 Private Registries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 974.6.3 Authentifizierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 974.6.4 Eine private Registry betreiben . . . . . . . . . . . . . . . . . . . . . . . . 1024.6.5 Fortgeschrittene Build-Techniken . . . . . . . . . . . . . . . . . . . . . . 107

4.7 So geht es weiter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123


Inhaltsverzeichnis

9

5 Docker-Container verwenden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1255.1 Was sind Container? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

5.1.1 Die Entstehungsgeschichte der Container . . . . . . . . . . . . . . . 1265.2 Container erstellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

5.2.1 Grundlegende Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . 1285.2.2 Speichervolumes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1335.2.3 Ressourcen-Quotas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

5.3 Container starten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1475.4 Container automatisch neu starten . . . . . . . . . . . . . . . . . . . . . . . . . . . 1485.5 Container stoppen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1495.6 Container sofort beenden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1515.7 Ausführung eines Containers pausieren und fortsetzen . . . . . . . . . . 1525.8 Container und Images aufräumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1535.9 Windows-Container. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1565.10 So geht es weiter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158

6 Docker erkunden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1596.1 Ausgabe der Docker-Version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1596.2 Informationen über den Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1616.3 Image-Updates herunterladen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1636.4 Container inspizieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1646.5 Die Shell erkunden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1666.6 Ausgabe von Rückgabewerten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1676.7 In einen laufenden Container gelangen . . . . . . . . . . . . . . . . . . . . . . . 169

6.7.1 docker exec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1696.7.2 nsenter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1706.7.3 docker volume. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

6.8 Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1766.8.1 docker logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1766.8.2 Fortgeschrittenes Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1786.8.3 Non-Plug-in-Community-Optionen . . . . . . . . . . . . . . . . . . . . 180

6.9 Docker überwachen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1826.9.1 Containerstatistiken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1826.9.2 Stats-API-Endpunkt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1836.9.3 Container-Health-Checks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1876.9.4 Docker-Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1916.9.5 cAdvisor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192

6.10 Monitoring mit Prometheus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1976.11 Weitere Erkundung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2006.12 So geht es weiter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201


Inhaltsverzeichnis

10

7 Container debuggen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2037.1 Prozesse anzeigen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2037.2 Prozesse inspizieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2097.3 Prozessverwaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2107.4 Das Netzwerk inspizieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2137.5 Image-History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2167.6 Inspizieren eines Containers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2177.7 Dateisystem inspizieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2197.8 So geht es weiter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220

8 Docker Compose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2218.1 Docker Compose konfigurieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2228.2 Services starten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2318.3 RocketChat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2338.4 Weitere Features von Docker Compose . . . . . . . . . . . . . . . . . . . . . . . . 2408.5 So geht es weiter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243

9 Der Weg zu Containern in Produktivumgebungen . . . . . . . . . . . . . . 2459.1 Einstieg in die Produktion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2459.2 Dockers Rolle in Produktivumgebungen . . . . . . . . . . . . . . . . . . . . . . . 246

9.2.1 Beschränkung der Ressourcen . . . . . . . . . . . . . . . . . . . . . . . . 2499.2.2 Netzwerke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2499.2.3 Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2499.2.4 Paketierung und Auslieferung. . . . . . . . . . . . . . . . . . . . . . . . . 2509.2.5 Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2509.2.6 Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2519.2.7 Scheduling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2519.2.8 Service Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2549.2.9 Fazit zur Produktion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256

9.3 Docker und die DevOps-Pipeline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2579.3.1 Kurzübersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2579.3.2 Externe Abhängigkeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261

9.4 So geht es weiter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261

10 Skalierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26310.1 Centurion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26410.2 Docker Swarm Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27110.3 Amazon ECS und Fargate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283

10.3.1 Einrichten von AWS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28310.3.2 Einrichtung von IAM-Rollen . . . . . . . . . . . . . . . . . . . . . . . . . . 284


Inhaltsverzeichnis

11

10.3.3 Einrichtung der AWS-CLI-Tools . . . . . . . . . . . . . . . . . . . . . . . 28510.3.4 Container-Instanzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28610.3.5 Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28710.3.6 Testen des Tasks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29610.3.7 Task stoppen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296

10.4 Kubernetes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29810.4.1 Was ist Minikube? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29810.4.2 Minikube installieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29910.4.3 Kubernetes zum Laufen bringen . . . . . . . . . . . . . . . . . . . . . . 30210.4.4 Kubernetes-Dashboard. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30510.4.5 Kubernetes-Container und Pods . . . . . . . . . . . . . . . . . . . . . . 30610.4.6 Das erste Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30710.4.7 Deployment eines realistischen Stacks . . . . . . . . . . . . . . . . . . 31010.4.8 Service-Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31110.4.9 Definition des PersistentVolumeClaim . . . . . . . . . . . . . . . . . 31210.4.10 Deployment-Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31310.4.11 Die Anwendung deployen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31510.4.12 Hochskalierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31710.4.13 kubectl-API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319


11 Weiterführende Themen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32311.1 Container im Detail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323

11.1.1 Control Groups (cgroups) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32411.1.2 Kernel- und Benutzer-Namespaces. . . . . . . . . . . . . . . . . . . . . 328

11.2 Sicherheitsaspekte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33311.2.1 SELinux und AppArmor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34711.2.2 Wie sicher ist der Docker-Daemon? . . . . . . . . . . . . . . . . . . . . 348

11.3 Erweiterte Konfiguration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35011.3.1 Netzwerke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350

11.4 Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35711.5 Die Struktur von Docker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36211.6 Runtimes austauschen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366

11.6.1 Clear-Container/Kata-Container . . . . . . . . . . . . . . . . . . . . . . 36611.6.2 gVisor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370


12 Container in der Produktivumgebung . . . . . . . . . . . . . . . . . . . . . . . . . 37512.1 »The Twelve-Factor App«-Manifest . . . . . . . . . . . . . . . . . . . . . . . . . . . 376


Inhaltsverzeichnis

12

12.1.1 Codebasis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37612.1.2 Abhängigkeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37712.1.3 Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37812.1.4 Unterstützende Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38012.1.5 Build, Release und Ausführung . . . . . . . . . . . . . . . . . . . . . . . 381

12.1.6 Prozesse. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38112.1.7 Portanbindung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38212.1.8 Nebenläufigkeit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38212.1.9 Austauschbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38312.1.10 Gleichstellung von Entwicklungs- und

Produktivumgebung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38412.1.11 Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38412.1.12 Administrationsprozesse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38512.1.13 »Twelve-Factor«-Zusammenfassung . . . . . . . . . . . . . . . . . . . 385

12.2 The Reactive Manifesto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38612.2.1 Reaktionsschnell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38612.2.2 Belastbar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38612.2.3 Flexibel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38612.2.4 Nachrichtengesteuert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387


13 Schlusswort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38913.1 Herausforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38913.2 Der Docker-Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39013.3 Minimierung der Deployment-Artefakte . . . . . . . . . . . . . . . . . . . . . . . 39113.4 Speicherung und Abruf optimieren . . . . . . . . . . . . . . . . . . . . . . . . . . . 39113.5 Der Lohn der Mühe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39213.6 Zu guter Letzt. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393

Stichwortverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395


13

Vorwort

Die weitverbreitete technische Evolution, die sich um uns herum vollzieht, kon-zentriert sich auf ein scheinbar einfaches Tool: den Container. Etwas vom Designher so Kleines und Leichtgewichtiges hat einen gewaltigen Einfluss auf die Soft-wareentwicklung in allen Branchen. Und das innerhalb kürzester Zeit.

Containerisierung ist allerdings nicht neu und war es auch 2013 nicht, als Dockerzum ersten Mal vorgestellt wurde. Allerdings war die Containerisierung vorDocker bei den meisten Softwareentwicklern kaum auf dem Radar. Selbst die Low-Level-Konzepte hinter Containern wurden überwiegend nur von denen verstan-den, die ein tiefes Verständnis vom Linux-Kernel hatten oder bei einigen der Tech-Giganten wie Sun oder Google arbeiteten. Windows-Entwickler oder Systemadmi-nistratoren wurden generell außen vor gelassen. Heutzutage ist es schwer, einGespräch über eine Software zu führen, ohne Docker zu erwähnen. Aber wie sindwir 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 Tech-nologie. Es wird hauptsächlich verwendet, weil es den Entwicklungsprozessbeschleunigt, die Ausgaben für Infrastruktur und Overhead verringert, dasOnboarding neuer Entwickler erleichtert und sogar die Barriere zwischen den Ent-wicklungs- und Administratorenteams reduziert. Windows-Nutzer können dankder Arbeit von Microsoft, Docker und weiteren zahlreichen Open-Source-Soft-ware-(OSS-)Anbietern nun ebenfalls von den Vorteilen von Docker profitieren.

Trotz all seiner Vorteile ist Docker jedoch nicht immer ein einfaches Tool. Manmuss es richtig verstanden haben, um Cloud-Native-Anwendungen bauen undadministrieren zu können. Cloud-Native-Anwendungen sind hochverfügbare, ska-lierbare Anwendungen, die auf Managed-Cloud-Infrastrukturen laufen. Um dieseResilienz und Skalierbarkeit zu erreichen, muss man auf Container-Orchestrie-rungstechnologien wie Kubernetes setzen. Zusätzlich dazu sind Cloud-Native-Anwendungen in der Regel serviceorientiert oder folgen dem Microservice-Archi-tektur-Ansatz.

Ich werde oft gefragt, ob Docker virtuelle Maschinen (VMs) ersetzt, ob Microser-vice-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 ste-


Vorwort

14

hen nicht in Konkurrenz zueinander, sondern sollten gemeinsam genutzt werden,um den maximalen Nutzen herauszuziehen. Serverless Computing ist dann amsinnvollsten, wenn es mit Containern genutzt wird. Ich würde sogar behaupten,dass Serverless Computing überhaupt nicht so populär wäre, wenn es keine kurz-lebigen und leichtgewichtigen Container gäbe. Microservices sind auch keine Vor-aussetzung 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 denBereich der Administration auszudehnen und für das, was sie entwickelt haben,die Verantwortung zu übernehmen. Das kann die Zusammenarbeit über Abtei-lungsgrenzen hinweg fördern, da Details wie Abhängigkeiten auch in den Verant-wortungsbereich des Entwicklungsteams fallen statt ausschließlich in den derAdministratoren. Darüber hinaus sind Teams so in der Lage, bessere Artefakte zugenerieren, die als Eckpunkte für die Dokumentation genutzt werden können: EinDockerfile und eine docker-compose.yml können zusammen die Rolle eines Leitfa-dens für die Inbetriebnahme des Projekts übernehmen. Neue Entwickler im Teamoder Entwickler in Open-Source-Projekten können in wenigen Schritten produktivarbeiten, wenn diese Dateien existieren. In der Vergangenheit war es oft einemehrtägige Aufgabe, eine Entwicklungsumgebung aufzusetzen. Heutzutage kön-nen wir das mit einem einfachen, reproduzierbaren Workflow ersetzen: Dockerinstallieren, das Repository klonen und docker-compose up laufen lassen.

Ähnlich wie das Cloud-Native-Ökosystem ein Hilfsmittel ist, sind auch vieleDocker-eigene Tools praktische Hilfsmittel, und das Beherrschen der Grundlagenwird Ihnen helfen, erfolgreicher zu sein. In diesem Buch sollten Sie Kapitel 4 ganzbesondere Aufmerksamkeit widmen. Dieses Kapitel beschäftigt sich mit den Con-tainer-Images inklusive der wichtigsten Datei im Projekt: dem Dockerfile. DieseDatei ist, neben den anderen Images, die Sie möglicherweise direkt von einerImage-Registry herunterladen, die Basis für Ihre Anwendung. Jeder weitere Layer,wie Container-Orchestrierung, basiert darauf, dass Sie Ihre Anwendung mittelseines Dockerfiles in einem Image paketiert haben. Sie lernen, dass jeder Anwen-dungscode, unabhängig von Alter, Framework, Sprache oder Architektur, in einContainer-Image paketiert werden kann.

In diesem Buch teilen Sean und Karl ihr umfangreiches kollektives Wissen, umIhnen das breite theoretische und taktische Verständnis von Docker und demdazugehörigen Ökosystem zu vermitteln mit dem Ziel, Ihnen zu einem erfolgrei-chen Start in die Containerisierung zu verhelfen. Während Docker die Entwick-lungsprozesse vereinfachen und optimieren kann, ist es aber auch ein mächtigesTool mit zahlreichen Komplexitätsschichten. Sean und Karl haben dieses Buchsorgfältig zusammengestellt, um sich auf das Wesentliche zu konzentrieren undIhnen dabei zu helfen, schnell produktiv zu werden und trotzdem die wichtigenGrundlagen zu verstehen.


Vorwort

15

Saugen Sie das Wissen und die Erfahrung, die auf diesen Seiten geteilt werden,auf und behalten Sie dieses Buch als Nachschlagewerk. Sie werden es nichtbereuen.

-- Laura Frank Tacho

Docker Captain und Director of Engineering, CloudBees

Twitter: @rhein_wein


17

Über die Autoren

Sean P. Kane ist zur Zeit Lead Site Reliability Engineer bei New Relic. Er war langeals IT-Techniker tätig und hat in sehr breit gefächerten Industriebranchen (Bio-technologie, Verteidigungswesen, Hightechunternehmen) viele verschiedene Pos-ten bekleidet. Zusätzlich zu seinen Tätigkeiten als Autor, Tutor und Speaker übermoderne Systemadministration in produktiven Umgebungen ist er begeisteterUrlauber, Wanderer und Camper. Er lebt mit seiner Frau, seinen Kindern undHunden im pazifischen Nordwesten der USA.

Karl Matthias ist Director of Cloud and Platform Services bei InVision. Zuvor warer Principal Systems Engineer bei Nitro Software und war in den letzten 20 Jahrenals Entwickler, Systemadministrator und Netzwerktechniker für Start-ups und ver-schiedene Fortune-500-Unternehmen tätig. Nach einigen Jahren in Start-ups inDeutschland und Großbrittannien, mit einem kurzem Aufenthalt in seiner Hei-mat in Portland, Oregon, wohnt er mit seiner Familie in Dublin in Irland. Wenn ersich nicht gerade mit digitalen Dingen beschäftigt, verbringt er seine Zeit mit sei-nen zwei Töchtern, mit dem Fotografieren mit Vintage Kameras oder fährt einesseiner Fahrräder.


19

Einleitung

Dieses Buch richtet sich sowohl an System Engineers als auch an Entwickler. Esweist Ihnen den Weg zu einer funktionierenden Docker-Umgebung und einer ver-nünftigen Produktivumgebung. Auf dem Weg werden wir erfahren, wie manDocker-Anwendungen baut, testet, deployt und debuggt – und das sowohl in derEntwicklung als auch in der Produktion. Wir behandeln zudem ein paar wichtigeOrchestrierungstools aus dem Docker-Ökosystem. Hilfestellungen zu Securityund Best Practices für Ihre Containerumgebung runden das Kapitel ab.

Wer sollte dieses Buch lesen?

Das Buch richtet sich an Leser, die nach Lösungen für die verschiedenen mit demkomplexen Workflow bei Entwicklung und Deployment von Anwendungen ein-hergehenden Problemen suchen. Wenn Sie an Docker, Linux-Containern, DevOpsund umfangreichen skalierbaren Softwareinfrastrukturen interessiert sind, ist die-ses Buch genau das Richtige für Sie.

Warum überhaupt dieses Buch lesen?

Heutzutage sind jede Menge Foren, Projektbeschreibungen und Artikel zumThema Docker im Internet verfügbar. Warum also sollten Sie Ihre kostbare Zeitmit dem Lesen dieses Buchs verbringen?

Nun, auch wenn tatsächlich schon viele Informationen bereitstehen, ist Dockerdoch eine neue Technologie, die sich rasant weiterentwickelt. Während wir dieerste Auflage dieses Buchs geschrieben haben, hat Docker, Inc. allein fünf neueVersionen veröffentlicht und sein hauseigenes Ökosystem um eine Reihe bedeu-tender Tools erweitert. In den drei Jahren zwischen der ersten und zweiten Auf-lage dieses Buchs hat sich die Docker-Landschaft stark verändert. Docker wurdeviel stabiler, und mittlerweile gibt es eine Auswahl an guten Tools für nahezujeden Aspekt aus dem DevOps-Workflow. Zu verstehen, was mit Docker alles mög-lich ist und wie es zu Ihrem Workflow passt und darin eingebunden werden kann,ist keine triviale Aufgabe. So haben wir an Aufbau und Betrieb von produktivenDocker-Umgebungen für mehrere Unternehmen über vier Jahre gearbeitet.


Einleitung

20

Wir haben Docker nur wenige Monate nach seinem Release in einer Produktivum-gebung implementiert und möchten in den nachfolgenden Kapiteln einigeErkenntnisse mit Ihnen teilen, die wir in den Jahren 2014 und 2015 im Rahmender Weiterentwicklung unserer Plattform gewonnen haben. Ziel soll es hierbeisein, Sie von unseren Erfahrungen profitieren zu lassen, sodass Sie den Stolperstei-nen, denen wir begegnet sind, soweit möglich aus dem Weg gehen können. Natür-lich ist auch die Onlinedokumentation des Docker-Projekts zwar durchausnützlich, wir möchten Ihnen hier jedoch ein etwas umfassenderes Gesamtbild ver-mitteln und Ihnen einige der Verfahrensweisen vorstellen, die sich bestens bewährthaben.

Nach der Lektüre dieses Buchs sollten Sie über hinreichende Kenntnisse verfügen,um zu verstehen, was Docker eigentlich leistet, warum es von Bedeutung ist, wieSie es zum Laufen bekommen, wie Sie Ihre Anwendungen bereitstellen könnenund was erforderlich ist, um es in einer Produktivumgebung einzusetzen. LassenSie sich von diesem Buch auf eine kurze, aufschlussreiche Reise in das Univer-sum einer interessanten Technologie mitnehmen, die einige sehr praktischeAnwendungen bietet.

Aufbau des Buchs

Hier ein Überblick über den Inhalt des Buchs:

� Kapitel 1 und Kapitel 2 bieten Ihnen eine Einführung in Docker und erläutern,was genau Docker eigentlich ist und wie Sie es verwenden können.

� Kapitel 3 führt Sie schrittweise durch die Installation von Docker.

� Die Kapitel 4 bis Kapitel 6 sind dem Docker-Client, Images und Containerngewidmet und untersuchen deren Aufgaben und Funktionsweisen.

� Kapitel 7 zeigt auf, wie Sie Images und Container debuggen können.

� Kapitel 8 führt in Docker Compose ein. Sie erfahren, wie signifikante Vereinfa-chungen in der Softwareentwicklung von komplexen containerbasierten Ser-vices mit Docker Compose möglich sind.

� Kapitel 9 behandelt Themen, die wichtig sind, um einen reibungslosen Über-gang in die Produktivumgebung zu gewährleisten.

� Kapitel 10 demonstriert das Deployment von Containern in Public und PrivateClouds in größerem Maßstab.

� In Kapitel 11 geht es um fortgeschrittene Themen, die einige Erfahrung mitDocker voraussetzen und von Bedeutung sind, wenn Sie anfangen, Docker inIhrer Produktivumgebung einzusetzen.

� Kapitel 12 untersucht einige der grundlegenden Konzepte, die sich beimDesign der nächsten Generation internetweit verfügbarer Produktivsoftwareherausgebildet haben.


Konventionen dieses Buchs

21

� Und das Kapitel 13 schnürt die maßgeblichen Inhalte dieses Buchs schließlichzu einem ansehnlichen, mit einer hübschen Schleife dekorierten Paket zusam-men: Es enthält eine Zusammenfassung der verfügbaren Tools, die Ihnendabei helfen sollen, das Deployment und die Skalierung von Softwaredienstenzu verbessern.

Natürlich sind wir uns darüber im Klaren, dass kaum jemand technische Fachbü-cher von vorne bis hinten durchliest und Einleitungen nur allzu leicht übersprun-gen werden. Wenn Sie es allerdings schon mal bis hierher geschafft haben, findenSie nachstehend noch einige Hinweise dazu, wie Sie bei der Lektüre des Buchsvorgehen sollten:

� Wenn Linux-Container Neuland für Sie sind, sollten Sie das Buch von Anfangan lesen. Die ersten beiden Kapitel erörtern die Grundlagen von Docker undLinux-Containern und beschreiben, was sie leisten, wie sie funktionieren undwarum Sie all dem Beachtung schenken sollten.

� Falls Sie sofort loslegen und Docker auf Ihrem Rechner installieren und aus-führen wollen, sollten Sie direkt zu Kapitel 3 und Kapitel 4 springen. Hiererfahren Sie, wie Docker installiert wird, wie Images erstellt oder heruntergela-den werden, wie Sie Container starten können und vieles mehr.

� Sind Sie mit den Grundlagen von Docker vertraut, benötigen aber dennochHilfe, um es in der Entwicklung zu nutzen, sollten Sie die Kapitel 5 bisKapitel 8 lesen. Diese behandeln sehr viele Themen zum täglichen Einsatz vonDocker mit Docker Compose, das Ihnen den Alltag erleichtert.

� Wenn Sie Docker bereits zur Entwicklung verwenden, aber Hilfe benötigen,um eine Produktivumgebung einzurichten, sollten Sie die Lektüre ab Kapitel 9in Betracht ziehen, die sich mit dem Deployment und dem Debugging vonContainern sowie weiteren fortgeschrittenen Themen befassen.

� Sie sind Software- oder Plattformarchitekt? Dann dürfte Sie Kapitel 12 interes-sieren, denn hier werden aktuell gängige Erwägungen zum Design containeri-sierter Anwendungen und horizontal skalierbarer Services betrachtet.

Konventionen dieses Buchs

In diesem Buch gelten folgende typografische Konventionen:

� Neue Begriffe, Dateinamen und Dateinamenserweiterungen sind kursiv ge-druckt.

� URLs und E-Mail-Adressen sind im Hyperlink-Format dargestellt.

� Für Programm-Listings oder im Fließtext vorkommende Variablen- oder Funk-tionsnamen, Datenbanken, Datentypen, Umgebungsvariablen, Anweisungenund Schlüsselwörter wird eine nicht-proportionale Schrift verwendet.


Einleitung

22

� Texte, die vom Benutzer durch eigene Eingaben oder aus dem Kontext ersicht-liche Werte ersetzt werden sollen, sind in KAPITÄLCHEN gedruckt.

� Vorschläge, Tipps, Hinweise und Warnungen sind in gesonderten Kästenangegeben.

Danksagungen

Wir möchten den vielen Menschen danken, die jede Auflage dieses Buchs über-haupt erst möglich gemacht haben:

� Nic Benders, Bjorn Freeman-Benson und Dana Lawson (New Relic), die unsereBemühungen stets unterstützten und uns die nötige Zeit für die erste Auflageverschafften.

� Roland Tritsch und Nitro Software für die Unterstützung von Karl bei derArbeit an der zweiten Auflage.

� Laurel Ruma (O'Reilly), die uns vorschlug, ein Buch über Docker zu schreiben,und Mike Loukides, der alles Notwendige arrangierte.

� Besonderer Dank gilt unserem Lektor Brian Anderson, der uns klargemachthat, worauf wir uns einlassen, und uns bei jedem Schritt zur Seite stand.

� Nikki McDonald und Virginia Wilson, die uns durch den Prozess der zweitenAuflage führten.

� Eine neue Leserschaft an eine neue Technologie heranzuführen, benötigtbesonderes Talent. Wir sind sehr dankbar, dass Lars Herrmann und LauraFrank Tacho sich die Zeit genommen haben, jeweils ein Vorwort zu schreiben.

� Den Lesern unseres Buchentwurfs, die gewährleisteten, dass wir beim Schrei-ben nicht vom richtigen Weg abkamen: Ksenia Burlachenko, die eine ersteBewertung und eine vollständige technische Rezension lieferte, sowie AndrewT. Baker, Sébastien Goasguen, Henri Gomez, Chelsey Frank und RachidZarouali.

� Besondere Erwähnung verdienen Alice Goldfuss und Tom Offermann, die unsdetailliertes und durchweg nützliches Feedback gaben.

� Gillian McGarvey und Melanie Yarbrough für das Redigieren des Manuskripts,damit es so aussieht, als hätten wir in der Schule bei der Rechtschreibung undZeichensetzung aufgepasst. 517 fehlende Kommata, und die Zählung läuft wei-ter ...

� Wendy Catalano und Ellen Troutman, die dafür gesorgt hat, dass alle Leser imStichwortverzeichnis sinnvolle Einträge vorfinden.

� Unseren Kollegen bei New Relic, die uns beim Einsatz von Docker begleitetenund viele der Erfahrungen sammelten, von denen wir hier berichten.


Danksagungen

23

� Grains of Wrath Brewery, World Cup Coffee, McMenamins Ringlers Pub, OldTown Pizza, A Beer at a Time!, Taylor‘s Three Rock pub und Weitere, die unsfreundlicherweise ihre Tische und Strom zur Verfügung stellten, auch wennunsere Speisen und Getränke schon längst verzehrt waren.

� Unseren Familien für ihre Unterstützung und dafür, dass sie uns die nötigeRuhe gewährten, wenn wir sie brauchten.

� Und schließlich allen, die uns ermutigten, uns Ratschläge gaben oder uns inanderer Weise irgendwie beim Schreiben dieses Buchs unterstützt haben.


25

Kapitel 1

Einführung

1.1 Die Entstehung von Docker

Es war der 15. März 2013, als Solomon Hykes, der Gründer und Geschäftsführervon dotCloud (jetzt Docker, Inc.), das Projekt Docker erstmals – ohne Vorankündi-gung und großes Brimborium – in einer blitzartigen Fünf-Minuten-Präsentation(http://youtu.be/wW9CAH9nSLs) auf der Python Developers Conference inSanta Clara, Kalifornien, vorstellte. Zu diesem Zeitpunkt hatten lediglich rund 40Leute außerhalb des Unternehmens dotCloud Gelegenheit gehabt, Docker auszu-probieren.

Schon wenige Wochen nach dieser Präsentation brach ein unerwartet großerMedienrummel ü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. ImLaufe der darauffolgenden Monate gewann Docker in der Branche zunehmend anBekanntheit, und man bescheinigte ihm, die bisherige Art und Weise der Soft-wareentwicklung, -verteilung und -nutzung revolutionieren zu können. Innerhalbeines Jahres hatte praktisch jeder Branchenkundige zumindest von Docker Notizgenommen, wenngleich vielen Menschen nicht ganz klar war, was es eigentlichgenau leistet und warum das so spannend ist.

Docker ist ein Tool, das eine einfache Kapselung des Erstellungsprozesses vonArtefakten zur Verteilung beliebiger Anwendungen verspricht. Dabei ist dasDeployment für beliebige Umgebungen skalierbar, und der Workflow sowie dieReaktionsfähigkeit der betreffenden agilen Unternehmen werden optimiert.

1.2 Das Docker-Versprechen

Diejenigen, die noch keine Erfahrung mit Docker haben, verstehen Docker vorder-gründig als Virtualisierungsplattform. Es leistet tatsächlich aber viel mehr. Esumspannt eine Reihe von belebten Branchensegmenten, für die bereits Lösungs-ansätze in Form individueller Technologien wie KVM, Xen, OpenStack, Mesos,Capistrano, Fabric, Ansible, Chef, Puppet, SaltStack usw. existieren. Wie Sie viel-leicht bemerkt haben, ist die Liste der Produkte, mit denen Docker in Konkurrenztritt, schon ziemlich aufschlussreich. Viele Administratoren würden kaumbehaupten, dass Virtualisierungslösungen im Wettbewerb mit Tools für die Konfi-


Kapitel 1Einführung

26

gurationsverwaltung stünden – dennoch wirkt sich Docker auf beide Technologiendisruptiv aus. Dies hängt im Wesentlichen damit zusammen, dass Docker einengroßen Einfluss auf die Arbeitsweise hat. Das wiederum wirkt sich stark auf diezuvor genannten traditionell voneinander isolierten Segmente in der DevOps-Pipeline aus.

Zudem werden den vorgenannten Technologien im Allgemeinen produktivitäts-steigernde Eigenschaften nachgesagt, und genau deshalb wird ihnen auch so vielAufmerksamkeit zuteil. Docker befindet sich sozusagen im Zentrum einiger derleistungsfähigsten Technologien des letzten Jahrzehnts und kann zu signifikantenVerbesserungen fast jedes Schritts der Pipeline führen.

Würden Sie Docker allerdings Punkt für Punkt mit den jeweiligen Platzhirschender verschiedenen Einsatzbereiche vergleichen, stünde es höchstwahrscheinlichbloß wie ein mittelmäßiger Wettbewerber da. In manchen Bereichen kann Dockerseine Stärken besser ausspielen als in anderen, insgesamt betrachtet decken dieFeatures, die es mitbringt, aber ein sehr breites Anwendungsspektrum ab. Durchdie Zusammenführung der Schlichtheit von Softwareverteilungstools wie Capis-trano und Fabric mit der komfortablen Verwaltungshandhabung von Virtualisie-rungssystemen sowie optionalen Möglichkeiten zur problemlosen Implementie-rung der Automatisierung von Workflow und Orchestrierung stellt Docker einensehr leistungsfähigen Satz an Features zur Verfügung.

Viele neue Technologien kommen und gehen, insofern ist eine gewisse Skepsisgegenüber den neuesten Trends durchaus angebracht. Oberflächlich betrachtet,könnte man auch Docker sicherlich einfach als eine weitere neue Technologieabtun, die sich irgendwelcher speziellen Probleme annimmt, mit denen Entwick-ler und Administratoren konfrontiert sind. Und wenn Sie es lediglich als Pseudo-Virtualisierungs- oder Deployment-Technologie sehen, erscheint es womöglichwirklich nicht besonders reizvoll. Allerdings leistet Docker sehr viel mehr als nurdas, was es auf den ersten Blick zu erkennen gibt.

Die Kommunikation und Workflows mehrerer Teams zu koordinieren, ist oftmalsselbst in kleineren Unternehmen und Organisationen schwierig und teuer. Des-sen ungeachtet kommt dem detaillierten Informationsaustausch zwischen denTeams jedoch immer mehr Bedeutung für ein erfolgreiches Arbeiten zu. Die Ent-deckung und Implementierung eines Tools, das diese Kommunikation erleichtertund gleichzeitig dazu beiträgt, stabilere Software zu produzieren, wäre also vonenormem Nutzen – und genau deswegen ist Docker einen zweiten Blick wert.Natürlich ist es kein Wundermittel, und seine zielführende Implementierung willwohlüberlegt sein, trotzdem ist Docker ein guter Ansatz, um in der Praxis auftre-tende organisatorische Probleme zu lösen und einem Unternehmen das zügigereDeployment besserer Software zu ermöglichen. Abgesehen davon kann ein gutgeplanter Docker-Workflow auch zufriedenere Teams und spürbare Kosteneinspa-rungen zur Folge haben.


1.2Das Docker-Versprechen

27

Wo also treten die größten Schwierigkeiten auf? Software in dem Tempo auszulie-fern, das heutzutage gefordert wird, ist nicht leicht – und wenn ein Unternehmenwächst und aus zwei oder drei Entwicklern mehrere Entwicklerteams werden,wird es auch zunehmend schwieriger, die Kommunikation hinsichtlich des Deploy-ments neuer Softwareversionen zu koordinieren. Die Entwickler müssen mög-lichst weitreichende Kenntnisse von der Umgebung besitzen, in der ihre Softwarelaufen soll, und die Administratoren müssen ihrerseits immer umfassender mitder internen Funktionsweise der ausgelieferten Software vertraut sein. Im Allge-meinen ist es durchaus vernünftig, diese Kenntnisse kontinuierlich weiter zu ver-tiefen, weil das letztlich zu einem besseren Verständnis der Softwareumgebunginsgesamt führt und somit das Design stabilerer Software ermöglicht. Allerdingsist dieses Wissen nur sehr schwer skalierbar, wenn das Wachstum eines Unter-nehmens zunimmt.

Die spezifischen Details einer Softwareumgebung bedingen oft eine Menge Kom-munikation, die für die beteiligten Teams nicht immer unmittelbar von Nutzenist. Wenn beispielsweise ein Entwicklerteam darauf warten muss, dass ein Admi-nistratorenteam irgendeine Library in der Version 1.2.1 deployt, kommt eszunächst nicht weiter – und für das betroffene Unternehmen bedeutet das verlo-rene Arbeitszeit. Könnten die Entwickler die Version der verwendeten Library hin-gegen einfach selbst aktualisieren und dann ihren Code schreiben, testen undausliefern, würde sich die Zeit bis zum Deployment deutlich verkürzen, und esbestünden darüber hinaus geringere Risiken beim Deployment der Änderung.Und wenn umgekehrt die Administratorenteams die Software auf dem Host aktu-alisieren könnten, ohne sich mit mehreren Entwicklerteams abstimmen zu müs-sen, ginge es ebenfalls schneller voran. Docker unterstützt die Möglichkeit, dieSoftware so zu isolieren, dass weniger Kommunikation zwischen den beteiligtenTeams erforderlich ist.

Docker reduziert aber nicht nur die notwendige Kommunikation, sondern wirktsich auch hinsichtlich der Softwarearchitektur recht bestimmend aus und begüns-tigt Anwendungen, die besonders stabil ausgelegt sind. Seine architektonischePhilosophie stellt atomare Container oder Wegwerf-Container in den Mittelpunkt.Beim Deployment wird die gesamte laufende Umgebung der alten Anwendungzusammen mit der Anwendung selbst weggeworfen. Nichts in der Umgebung deralten Anwendung überlebt länger als die Anwendung selbst – eine einfache Ideemit großem Effekt. Auf diese Weise wird es äußerst unwahrscheinlich, dass eineAnwendung versehentlich auf irgendwelche Überbleibsel einer vorhergehendenVersion zugreift. Und auch beim Debuggen vorgenommene kurzlebige Änderun-gen können so keinen Eingang in künftige Versionen finden, indem sie vom loka-len Dateisystem eingelesen werden. Außerdem sind Anwendungen dadurchhochgradig portabel und lassen sich leicht auf einen anderen Server verschieben,denn alle Zustände müssen unveränderlicher Bestandteil des Deployment-Arte-



28

fakts sein oder an einen externen Speicherort wie eine Datenbank, einen Cacheoder einen Dateiserver übergeben werden.

Die Anwendungen sind somit nicht nur besser skalierbar, sondern auch zuverläs-siger – und die Instanzen eines Anwendungscontainers können kommen undgehen, ohne dass sich dies großartig auf die Verfügbarkeit des Frontends auswir-ken würde. Hierbei handelt es sich um erprobte architektonische Entscheidungen,die sich bei Anwendungen bewährt haben, in denen Docker nicht zum Einsatzkommt. Docker hat diese Designentscheidungen übernommen und gewährleistetsomit, dass sich Anwendungen, in denen das Projekt genutzt wird, im Bedarfsfallebenfalls dementsprechend verhalten – was nur vernünftig ist.

1.2.1 Vorteile des Docker-Workflows

Es ist nicht einfach, all die Möglichkeiten, die Docker mitbringt, in sinnvollzusammenhängende Kategorien einzuordnen. Eine gut vollzogene Implementie-rung verschafft dem Unternehmen als Ganzes sowie den Teams, den Entwicklernund den Administratoren im Besonderen zahlreiche Vorteile. Sie vereinfachtarchitektonische Designentscheidungen, weil alle Anwendungen aus der Perspek-tive des Hostsystems von außen betrachtet im Wesentlichen gleich aussehen.Außerdem fällt es leichter, Toolings zu erstellen, die von mehreren Anwendungengemeinsam 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 Erstel-lung von Softwarepaketen mit ein. In vielen Unternehmen mussten für die Erstellung von Softwarepaketen fürdie jeweils zu unterstützenden Plattformen eigens Stellen für Release undBuild Engineers geschaffen werden, die über die erforderlichen Kenntnisse imUmgang mit den entsprechenden Toolings verfügen. Der Einsatz von Tools wierpm, mock, dpkg oder pbuilder kann ziemlich kompliziert sein und mussjeweils individuell erlernt werden. Docker schnürt alle von Ihnen benötigtenBestandteile zu einem Paket zusammen, das aus nur einer einzigen Dateibesteht.

� Anwendungssoftware und erforderliche Betriebssystemdateien werden in einemstandardisierten Image-Format gebündelt.Früher musste ein Paket nicht nur die eigentliche Anwendung enthalten, son-dern 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 überein-stimmten. Für nativ kompilierten Code bedeutete dies, dass das Build-Systemexakt die gleichen Versionen der Shared Libraries haben musste wie die Pro-duktivumgebung. Dies erschwerte die Paketierung und bereitete vielen Unter-


1.2Das Docker-Versprechen

29

nehmen Probleme, verlässlich funktionierende Pakete zu liefern. Oftmals ver-suchen Entwickler, die die (auf Red Hat basierende) Linux-Distribution Scienti-fic Linux verwenden, in der Hoffnung, dass beide Distributionen einanderähnlich genug sind, ein unter Red Hat getestetes Paket zum Laufen zu bekom-men. Mit Docker wird die Anwendung allerdings bereits inklusive aller für dieAusführung erforderlichen Dateien zur Verfügung gestellt. Dank der mehr-schichtigen Images (Overlays), die an dieser Stelle zum Einsatz kommen, han-delt es sich hierbei um einen effizienten Vorgang, der gewährleistet, dass IhreAnwendung in der erwarteten Umgebung läuft.

� Pakete werden mit exakt gleichen Artefakten zum Testen und Ausliefern für alleSysteme in allen Umgebungen benutzt.Wenn Entwickler über eine Versionsverwaltung Änderungen einchecken, kannein neues Docker-Image erstellt werden, das den vollständigen Überprüfungs-vorgang durchläuft und an die Produktivumgebung ausgeliefert wird, ohnedass dabei eine Neukompilierung oder die Erstellung eines neuen Pakets erfor-derlich wäre, es sei denn, dies ist speziell gewünscht.

� Abstraktion von Softwareanwendungen von der Hardware, ohne Ressourcen zuopfern.Wenn ein Abstraktionslayer zwischen der physischen Hardware und der darauflaufenden Softwareanwendung erforderlich ist, werden typischerweise her-kömmliche Virtualisierungslösungen wie VMware eingesetzt – zum Preiseines höheren Ressourcenbedarfs: Der Hypervisor, der die VMs verwaltet,sowie alle laufenden VM-Kernel nutzen einen bestimmten Prozentsatz derHardwareressourcen des Systems, die den Anwendungen dann nicht mehr zurVerfügung stehen. Ein Container hingegen ist einfach nur ein weiterer, direktmit dem Linux-Kernel kommunizierender Prozess, der daher mehr Ressour-cen in Anspruch nehmen kann, bis er an die systemseitig vorgegebene oderihm zugewiesene Kontingentsgrenze stößt.

Zum Zeitpunkt des ursprünglichen Docker-Releases existierten Linux-Containerbereits seit einigen Jahren, und auch viele der anderen Technologien, auf denenDocker beruht, sind nicht völlig neu. Allerdings bildet die einzigartige Mischungder nachhaltigen Designentscheidungen hinsichtlich Architektur und Workflowhier ein großes Ganzes, das erheblich leistungsfähiger ist als die Summe seinerTeile. Docker gewährt dem durchschnittlichen Software-Engineer Zugang zu denseit 2008 verfügbaren Linux-Containern. Es gestattet die relativ einfache Integra-tion von Linux-Containern in den bereits vorhandenen Workflow bzw. die Prozess-abläufe eines Unternehmens. Tatsächlich waren offenbar derart viele Menschenvon den oben beschriebenen Schwierigkeiten betroffen, dass das Interesse anDocker schneller zunahm, als man vernünftigerweise hätte erwarten dürfen.

Seit seinem Start vor nur wenigen Jahren hat Docker bereits einige Iterationengesehen, verfügt nun über eine Fülle an Funktionen und läuft weltweit in einer



30

großen Anzahl von Produktivumgebungen. Es entwickelte sich sehr schnell zueinem der Grundsteine jedes modernen verteilten Systems. Eine Vielzahl vonUnternehmen ziehen Docker als Lösung für ernst zu nehmende Probleme inBetracht, mit denen sie sich im Rahmen des Deployments ihrer Anwendungenkonfrontiert sehen.

1.3 Was Docker nicht ist

Docker ist für eine breite Palette von Problemstellungen geeignet, für derenLösung in der Vergangenheit üblicherweise Tools anderer Kategorien herangezo-gen wurden. Diese Vielseitigkeit bedingt es oftmals aber auch, dass die Funktiona-lität in bestimmten Bereichen nicht allzu tief greifend ausgeprägt ist. So werdenmanche Unternehmen feststellen, dass sie komplett auf ihre Tools für die Konfi-gurationsverwaltung verzichten können, wenn sie Docker einsetzen. Es kann zwardurchaus einige der Aufgaben herkömmlicher Tools übernehmen – seine wahreStärke zeigt sich jedoch darin, dass es in der Regel mit ihnen kompatibel ist odersich durch sie ergänzen lässt. Im Folgenden stellen wir einige der Toolkategorienvor, die Docker zwar nicht unmittelbar ersetzt, die sich aber in Kombination ver-wenden lassen. Auf diese Weise können oft hervorragende Ergebnisse erzielt wer-den.

� 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 einemHypervisor betrieben wird, der innerhalb des Host-Systems ausgeführt wird.Der größte Vorteil gegenüber der Hardwarevirtualisierung besteht darin, dasses problemlos möglich ist, mehrere virtuelle Maschinen mit völlig anderenBetriebssystemen auf einem einzelnen Host auszuführen. Bei einem Cont-ainer teilen sich der Host und der Container denselben Kernel – das bedeutet,dass der Container weniger Ressourcen belegt als eine VM, aber auf demselbenBetriebssystem (z.B. Linux) beruhen muss wie der Host.

� Cloud-Plattform (OpenStack, CloudStack usw.) Ebenso wie bei Enterprise-Virtualisierungsplattformen haben – oberflächlichgesehen – Container-Workflows und Cloud-Plattformen viele Gemeinsamkei-ten. Beide werden typischerweise für die horizontale Skalierung eingesetzt, umwechselndem Leistungsbedarf Rechnung zu tragen. Docker ist allerdings keineCloud-Plattform, sondern handhabt das Deployment, die Ausführung und dieVerwaltung von Containern auf bereits vorhandenen Docker-Hosts. Es ist nichtmöglich, neue Hosts (Instanzen), neue Objektspeicher, neuen Speicherplatzoder eine der anderen typischerweise auf einer Cloud-Plattform verfügbarenRessourcen zu erstellen. Wenn Sie Docker-Tooling ausweiten, werden Siemehr und mehr von den Vorteilen profitieren, die traditionell mit der Cloudassoziiert werden.


1.3Was Docker nicht ist

31

� Konfigurationsverwaltung (Puppet, Chef usw.) Docker kann zwar die Möglichkeiten zur Administration von Anwendungenund deren Abhängigkeiten erheblich verbessern, ist aber kein direkter Ersatzfür eine herkömmliche Konfigurationsverwaltung. Dockerfiles legen fest, wieein fertiger Container zur Build-Zeit aussehen soll, haben aber keinen Einflussauf den aktuellen Zustand und können auch nicht verwendet werden, um dasDocker-Host-System zu verwalten. Nichtsdestotrotz kann die Nutzung vonDocker dazu führen, dass die Komplexität von Konfigurationsverwaltungscodedeutlich reduziert wird. Allein dadurch, dass mehr und mehr Server einfach zuDocker-Hosts werden, wird der Code der Konfigurationsverwaltung viel klei-ner, und Docker kann anschließend dafür verwendet werden, die komplexenAnforderungen einer Anwendung innerhalb von Docker-Images auszurollen.

� Deployment-Framework (Capistrano, Fabric usw.) Docker erleichtert viele Aspekte des Deployments, indem es eigenständigeContainer-Images erstellt, die alle Abhängigkeiten einer Anwendung kapselnund ohne weitere Anpassungen für alle Umgebungen geeignet sind. Es kannjedoch nicht verwendet werden, um die komplexen Deployments selbst zuautomatisieren. Für die Aneinanderreihung umfangreicherer automatisierterWorkflows werden im Allgemeinen zusätzliche Tools benötigt. Diese Methodeverlangt, dass alle deployten Container auf allen Hosts konsistent ausgerolltwerden. Ein einziger Deployment-Workflow würde für die meisten – wennnicht sogar alle – Docker-basierten Anwendungen ausreichen.

� Workload-Manager (Mesos, Kubernetes, Swarm usw.)Ein Orchestrierungslayer (inklusive des eingebauten Swarm-Modus) mussgenutzt werden, wenn man die Workload auf einen Pool von Docker-Hostsintelligent verteilen möchte. Er trackt den aktuellen Status aller Hosts und dergenutzten Ressourcen und unterhält ein Inventar von allen laufenden Con-tainern.

� Entwicklungsumgebung (Vagrant usw.) Vagrant ist ein Developer-Tool zur Verwaltung virtueller Maschinen, das häufigzur Simulation einer Serverumgebung genutzt wird, die der echten Produktiv-umgebung, in der eine Anwendung laufen soll, sehr ähnlich ist. Unter ande-rem vereinfacht Vagrant die Ausführung von Linux-Software auf Rechnern mitWindows oder macOS. Docker Machine ist für viele Standard-Docker-Work-flows ausreichend. Es bringt allerdings nicht die breite Palette an Funktionenmit, 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 esallerdings nicht notwendig, eine breite Palette von Produktivumgebungen inder Entwicklungsumgebung zu simulieren, wenn Sie Docker einsetzen. Dieshängt damit zusammen, dass die meisten Produktivumgebungen einfacheDocker-Server sein werden, die auch leicht lokal gebaut werden können.



32

1.4 Wichtige Begrifflichkeiten

Hier werden einige Begrifflichkeiten kurz genannt und erläutert, die im weiterenVerlauf 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-Prozesszu starten, der über einen Client Container baut und startet.

� Docker-Image Docker-Images bestehen aus einem oder mehreren Dateisystemlayern, ange-reichert mit einigen wichtigen Metadaten, die alle Dateien repräsentieren, dieeine dockerisierte Anwendung benötigt. Ein einzelnes Docker-Image kann aufzahlreiche Hosts kopiert werden. Ein Image hat üblicherweise sowohl einenNamen als auch ein Tag. Das Tag wird generell zur Identifizierung einer spezi-fizierten Version eines Images nutzt.

� Docker-Container Ein Docker-Container ist ein Linux-Container, der von einem Docker-Imageinstanziiert 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 Containernerlaubt sowie Image-basierte (atomic) Betriebssystem-Upgrades ermöglicht.

1.5 Zusammenfassung

Sofern Sie nicht den entsprechenden beruflichen Hintergrund besitzen, ist esnicht ganz einfach, Docker zu verstehen. Im folgenden Kapitel geben wir Ihneneinen umfangreichen Überblick darüber, was Docker eigentlich leistet, wie es ein-gesetzt werden sollte und welche Vorteile Sie erzielen können, wenn Sie all das beider Implementierung berücksichtigen.


395

Stichwortverzeichnis

12-Factor App 376.dockercfg 99.dockerignore 85/sys-Dateisystem 326$WHO 93

AAbhängigkeit 257, 377Abhängigkeiten

extern 261ADD 82Administrationsprozess 385Amazon Elastic Container Service 263Ansible 58Anwendung testen 257apt (Advanced Package Tool) 60Arbeitsspeicher

beschränken 141virtueller 142

Artefakt 25Asynchrone Nachrichten 387Atomic Host 32, 56AUFS (Advanced Multi-layered Unification

Filesystem) 359Aurora 56Ausgabeumlenkung 385Authentifizierung 97, 349Autorisierung 349AWS-CLI (AWS Command Line Interface)

285Azure Container Service 263

BBase-Image 94, 217, 377Benutzer-ID 204, 330Benutzer-Namespaces 330Beschränkung der Ressourcen 325blkio.weight 144Blue-Green-Deployment 252Brewer, Eric 37Btrfs (B-tree Filesystem) 359, 360

CCache 89cAdvisor 192, 193cap-add 341Centurion 56, 264, 267cgroup-parent 328cgroups 136cgroups-Einstellung 326cgroups-Freezer 152Chocolatey 60, 63chroot 127Clear-Container 38Cloud-Plattform 30CMD 83Codebasis 376Codeshop 53Container

atomarer 27Austauschbarkeit 383automatisch neu starten 148debuggen 203erstellen 128inspizieren 164Instanz 286pausieren und fortsetzen 152privilegierte 338Sicherheit 335sofort beenden 151starten 147stoppen 149

containerd 39, 363Control Groups 324Convoy 58CoreOS 57CPU

Nutzung beschränken 137CPU-Anteile 137CPU-Performance

beschränken 137cpu-quota 141CPU-Quotas-Kontingente 141cpuset 140CPU-Zuweisung 140



396

cron 45, 155curl 183

DDateisystem-Metadaten 348DC/OS 56Debian 60Deployment

Schritte 381Deployment-Framework 31Designentscheidungen 29Device Mapper 360, 361DevOps 257, 390dmesg 176Docker Community Edition 61Docker Compose 221, 261Docker Enterprise Edition 61Docker Hub 81Docker Machine 31, 64, 65Docker Swarm 40docker0-Schnittstelle 351, 352docker-Befehl

build 85cp 200create 128, 136, 147diff 219events 182, 192exec 109, 169export 109, 200history 216image inspect 112import 201info 137inspect 129, 165, 217inspect network 355kill 151login 98, 101logout 99logs 176, 177network ls 213node update 280pause 152ps 92, 129pull 101push 101, 260rm 129run 92, 128, 135save 201service ls 277service ps 278service rm 282service rollback 279service scale 278

start 128, 147stats 182, 325stop 94system prun 155tag 100, 260top 203unpause 153version 160volume 174

Docker-Client 32docker-compose down 231, 243docker-compose start 242docker-compose stop 242Docker-Container 32docker-containerd-shim 363dockerd 363Docker-Daemon 40, 348docker-enter 173Dockerfile 79Docker-Image 29, 32docker-init 39docker-machine create 66docker-proxy 39, 216, 351, 353Docker-Server 32Docker-Workflow 28, 390dotCloud 25

EElastic Container Service 283Enterprise-Virtualisierungsplattform 30ENTRYPOINT 212Entwicklungsumgebung 31ENV 81essential-Flag 289Eventreignisstreaom 384

FFargate 264

GGemfile 267Git 84GNU-Debugger (gdb) 210Go (Programmiersprache) 41Google Kubernetes Engine 263Graceful Degradation 380, 387Graduelle Leistungsabnahme 380, 387gVisor 38

HHealth-Checks 187Helios 56, 264



397

Heroku 34History (Image) 216Hochverfügbarkeit 381Homebrew 60, 63Hostname 332Host-Netzwerk 357hubot 378Hykes, Solomon 25Hyper 38Hyper-V 63Hypervisor 125

IIAM (Identity and Access Management) 284Idempotenz 48Image

alle löschen 155Ausführung 92Erstellung 84hochladen 100speichern 95

Immunix 347iops 325ip addr 351IPC-Namespaces 330

Jjail 127Jenkins 53, 261JSON-Objekt 177

KKata-Container 38kill-Befehl 210Kind-Prozess 325Konfiguration 378Konfigurationsverwaltung 31kubectl 300Kubernetes 56, 298

Llatest 52libc 95Linux-Container 29Load Balancer 254Logging 176Logs 384Logspout 182löschen 154lsof 209

MMAC (Mandatory Access Control) 347MAC-Adresse (Media-Access-Control-

Adresse) 132macOS 31, 59, 60, 62, 64, 84, 265, 285macvlan 356Marathon 56memory-swap 142Mesos 56, 252Minikube 298mount 354Mount-Namespaces 329musl 95

NNagios 193Namespace 328NAT (Network Address Translation) 351Nebenläufigkeit 383netstat 215, 354network 354Netzwerk

privates 350Netzwerk-Namespaces 330, 354Netzwerk-Port 40nice-Befehl 139nice-Wert 325Nomad 56nsenter 170

OOOM-Killer 143Open Container Initiative 38openssl 104Orchestrierung 271Overlay 358overlay 356

PPacker 48PaketerstellungPaketierung 28PersistentVolume 310PersistentVolumeClaim 310PID 1 211PID-Namespaces 330Pod 306Portabilität 27Portanbindung 382Programm

statisch gelinktes 378Programmierschnittstelle 42Project Atomic 57



398

Prometheus 58, 197Prozesse anzeigen 203Prozessverwaltung 210pstree 208Public Cloud 263

QQuay.io 96

Rrailcar 38Rancher 56Reactive-Manifest 386Red Hat 60Red Hat OpenShift 263Redis 147Registry 39

Anmeldung 98Authentifizierung 97öffentliche 95

Reproduzierbarkeit 384Ressource

Verlust 380Ressourcennutzung 325Ressourcen-Quotaskontingente 136RFC1918 43RocketChat 222Rolling Deployment 269root-Benutzer 335rpm 28rpm (Red Hat Package Manager) 60Ruby 265RUN 82runc 38, 39, 363Runlevel 64

SScheduler 252Scientific Linux 29Secure Resource Partitions 127Security Group 284SELinux 347Server-Informationen 161Sicherheitsmaßnahmen 347SIGKILL-Signal 151SIGTERM-Signal 150, 383SIGUSR1-Signal 210Singularity 56Skalierung 263

horizontale 381, 383Solaris-Zonen 127Statistik 325

STDOUT 384Storage 357Storage-Backend 361strace 209stress-Befehl 138Swarm 31, 56Swarm Mode 40swarm-Befehl

init 272join 273

syslog 178systemctl 64, 326systemd 64systemd-Timer 155

TTask

stoppen 296Taskdefinition 287Taskstatus 296tcpdump 216Tectonic 56The Twelve-Factor App 376tlsverify 349tmpfs-Dateisystem 135top-Befehl 138Travis-CI 53Trennung von Verantwortlichkeiten 387

UUID 0 335ulimit 146Umgebungsvariable 93, 378

DOCKER_HOST 92WHO 93

Unix-Signal 210, 383Unterstützende ServicesDienste 380USER 81USR1-Signal 151util-linux-Paket 171UTS-Namespaces 329

VVagrant 69Verschlüsselung 349Versionsnummer 160VFS (Virtual File System) 360Virtual Private Cloud 284VirtualBox 65Virtuelle Schnittstelle 352



399

WWeave 357Weave Net 58Wegwerf-cContainer 27Wiggins, Adam 376Windows 31, 59, 60, 64, 285Windows-Container 37WORKDIR 83Workload-Manager 31

Xxhyve 63

Yyum (Yellowdog Updater, Modified) 60

ZZertifikat 349Zertifizierungsstelle 349ZFS 360Zustandsdaten 382Zustandslosigkeit 44


Documents

InhaltsverzeichnisDocker-eigene Tools praktische Hilfsmittel, und das Beherrschen der Grundlagen wird Ihnen helfen, erfolgreicher zu sein. In diesem Buch sollten Sie Kapitel 4 ganz