Оглавление
Kief Morris. Handbuch Infrastructure as Code
Handbuch Infrastructure as Code
Inhalt
Über dieses Buch
Vorwort
Warum ich dieses Buch geschrieben habe
Was in dieser Auflage neu und anders ist
Was kommt als Nächstes?
Was dieses Buch ist und was es nicht ist
Etwas Geschichte zu Infrastructure as Code
Für wen dieses Buch gedacht ist
Prinzipien, Praktiken und Patterns
Warum ich den Begriff »Best Practice« nicht verwende
Die ShopSpinner-Beispiele
In diesem Buch verwendete Konventionen
Danksagung
KAPITEL 1. Was ist Infrastructure as Code?
Aus der Eisenzeit in das Cloud-Zeitalter
Infrastructure as Code
Vorteile von Infrastructure as Code
Infrastructure as Code nutzen, um für Änderungen zu optimieren
Einwand »Wir haben gar nicht so häufig Änderungen, sodass sich Automation nicht lohnt«
Einwand »Wir sollten erst bauen und danach automatisieren«
Einwand »Wir müssen zwischen Geschwindigkeit und Qualität entscheiden«
Die Four Key Metrics
Drei zentrale Praktiken für Infrastructure as Code
Zentrale Praktik: Definieren Sie alles als Code
Zentrale Praktik: Kontinuierliches Testen und die gesamte aktuelle Arbeit ausliefern
Zentrale Praktik: Kleine einfache Elemente bauen, die Sie unabhängig voneinander ändern können
Zusammenfassung
KAPITEL 2. Prinzipien der Infrastruktur im Cloud-Zeitalter
Prinzip: Gehen Sie davon aus, dass Systeme unzuverlässig sind
Prinzip: Alles reproduzierbar machen
Fallstrick: Snowflake-Systeme
Prinzip: Erstellen Sie wegwerfbare Elemente
Der Fall des verschwundenen Dateiservers
Prinzip: Variationen minimieren
Konfigurationsdrift
Die Angstspirale der Automation
Prinzip: Stellen Sie sicher, dass Sie jeden Prozess wiederholen können
Zusammenfassung
KAPITEL 3. Infrastruktur-Plattformen
Die Elemente eines Infrastruktur-Systems
Dynamische Infrastruktur-Plattform
Multicloud
Infrastruktur-Ressourcen
Computing-Ressourcen
Storage-Ressourcen
Networking-Ressourcen
Zero-Trust-Sicherheitsmodell mit SDN
Zusammenfassung
KAPITEL 4. Zentrale Praktik: Definieren Sie alles als Code
Warum Sie Ihre Infrastruktur als Code definieren sollten
Was Sie als Code definieren können
Wählen Sie Werkzeuge mit externalisierter Konfiguration aus
Managen Sie Ihren Code in einer Versionsverwaltung
Programmiersprachen für Infrastruktur
Deklarativen und imperativen Code mischen
Infrastruktur-Scripting
Listing 4-1: Beispiel für prozeduralen Code, der einen Server erstellt
Deklarative Infrastruktur-Sprachen
Listing 4-2: Beispiel für deklarativen Code
Idempotenz
Programmierbare, imperative Infrastruktur-Sprachen
Listing 4-3: Beispiel für Infrastruktur-Code in einer imperativen Sprache
Deklarative und imperative Sprachen für Infrastruktur
Domänenspezifische Infrastruktur-Sprachen
Allgemein nutzbare Sprachen und DSLs für die Infrastruktur
Implementierungs-Prinzipien beim Definieren von Infrastructure as Code
Halten Sie deklarativen und imperativen Code voneinander getrennt
Behandeln Sie Infrastruktur-Code wie echten Code
Code als Dokumentation
Zusammenfassung
KAPITEL 5. Infrastruktur-Stacks als Code bauen
Was ist ein Infrastruktur-Stack?
Stack-Code
Listing 5-1: Projekt-Ordnerstruktur eines Stack-Projekts für ein fiktives Tool
Stack-Instanzen
Server in einem Stack konfigurieren
Listing 5-2: Beispiel für eine Stack-Definition, die ein Tool zur Serverkonfiguration aufruft
Low-Level-Infrastruktur-Sprachen
Listing 5-3: Beispiel für Low-Level-Code für einen Infrastruktur Stack
High-Level-Infrastruktur-Sprachen
Listing 5-4: Beispiel für High-Level-Infrastruktur-Stack-Code
Patterns und Antipatterns für das Strukturieren von Stacks
Antipattern: Monolithic Stack
Motivation
Anwendbarkeit
Konsequenzen
Implementierung
Zugehörige Patterns
Ist mein Stack ein Monolith?
Pattern: Application Group Stack
Motivation
Anwendbarkeit
Konsequenzen
Implementierung
Zugehörige Patterns
Pattern: Service Stack
Motivation
Anwendbarkeit
Konsequenzen
Implementierung
Zugehörige Patterns
Pattern: Micro Stack
Motivation
Konsequenzen
Implementierung
Zugehörige Patterns
Zusammenfassung
KAPITEL 6. Umgebungen mit Stacks bauen
Worum es bei Umgebungen geht
Auslieferungsumgebungen
Mehrere Produktivumgebungen
Umgebungen, Konsistenz und Konfiguration
Patterns zum Bauen von Umgebungen
Antipattern: Multiple-Enviroment Stack
Motivation
Konsequenzen
Zugehörige Patterns
Antipattern: Copy-Paste Environments
Motivation
Anwendbarkeit
Konsequenzen
Implementierung
Zugehörige Patterns
Pattern: Reusable Stack
Motivation
Anwendbarkeit
Konsequenzen
Implementierung
Zugehörige Patterns
Umgebungen mit mehreren Stacks erstellen
Zusammenfassung
KAPITEL 7. Stack-Instanzen konfigurieren
Designprinzip: Sorgen Sie für einfache Parameter
Eindeutige Kennungen durch Stack-Parameter erstellen
Beispiel-Stack-Parameter
Listing 7-1: Beispiel-Projektstruktur für einen Template-Stack, der ein Container-Cluster definiert
Patterns zum Konfigurieren von Stacks
Antipattern: Manual Stack Parameters
Listing 7-2: Beispiel für das manuelle Eingeben von Befehlszeilenparametern
Motivation
Konsequenzen
Implementierung
Zugehörige Patterns
Pattern: Stack Environment Variables
Listing 7-3: Umgebungsvariablen setzen
Listing 7-4: Der Stack-Code nutzt Umgebungsvariablen
Motivation
Anwendbarkeit
Konsequenzen
Implementierung
Zugehörige Patterns
Pattern: Scripted Parameters
Motivation
Anwendbarkeit
Konsequenzen
Implementierung
Listing 7-5: Beispiel für ein Skript, das die Parameter für mehrere Umgebungen enthält
Listing 7-6: Beispiel-Projektstruktur mit einem Skript für jede Umgebung
Listing 7-7: In einem Skript einen Schlüssel aus einem Secrets Manager holen
Zugehörige Patterns
Pattern: Stack Configuration Files
Listing 7-8: Beispielprojekt mit einer Parameterdatei für jede Umgebung
Motivation
Anwendbarkeit
Konsequenzen
Implementierung
Listing 7-9: Secrets aus einer lokalen Datei lesen
Zugehörige Patterns
Pattern: Wrapper-Stack
Motivation
Konsequenzen
Implementierung
Zugehörige Patterns
Pattern: Pipeline Stack Parameters
Motivation
Anwendbarkeit
Konsequenzen
Implementierung
Listing 7-10: Beispiel für eine Pipeline-Stage-Konfiguration
Listing 7-11: Beispiel für eine Pipeline-Stage-Konfiguration mit Umgebungsvariablen
Listing 7-12: Beispiel für Pipeline-Stage mit Secrets
Zugehörige Patterns
Pattern: Stack Parameter Registry
Motivation
Anwendbarkeit
Konsequenzen
Implementierung
Listing 7-13: Beispiel für Einträge in der Konfigurations-Registry
Zugehörige Patterns
Konfigurations-Registry
Eine Konfigurations-Registry implementieren
Registries von Infrastruktur-Automatisierungs-Tools
Allgemein einsetzbare Produkte für eine Konfigurations-Registry
Plattform-Registry-Services
Selbst gebaute Konfigurations-Registries
Eine oder mehrere Konfigurations-Registries
Secrets als Parameter nutzen
Secrets verschlüsseln
Secretlose Autorisierung
Secrets zur Laufzeit injizieren
Wegwerf-Secrets
Zusammenfassung
KAPITEL 8. Zentrale Praktik: Kontinuierlich testen und ausliefern
Warum Infrastruktur-Code kontinuierlich testen?
Was kontinuierliches Testen bedeutet
Sofortiges Testen und abschließendes Testen
Was sollten wir bei der Infrastruktur testen?
Herausforderungen beim Testen von Infrastruktur-Code
Herausforderung: Tests für deklarativen Code haben häufig nur einen geringen Wert
Variablen deklarativen Code testen
Kombinationen deklarativen Codes testen
Herausforderung: Das Testen von Infrastruktur-Code ist langsam
Herausforderung: Abhängigkeiten verkomplizieren die Test-Infrastruktur
Progressives Testen
Testpyramide
Schweizer-Käse-Testmodell
Infrastruktur-Delivery-Pipelines
Pipeline-Stages
Scope von Komponenten, die in einer Stage getestet werden
Scope von Abhängigkeiten für eine Stage
Plattformelemente, die für eine Stage erforderlich sind
Software und Services für die Delivery-Pipeline
Testen in der Produktivumgebung
Was Sie außerhalb der Produktivumgebung nicht nachbauen können
Die Risiken beim Testen in der Produktivumgebung managen
Zusammenfassung
KAPITEL 9. Infrastruktur-Stacks testen
Beispiel-Infrastruktur
Der Beispiel-Stack
Listing 9-1: Stack-Projekt für die Kundenanwendung von ShopSpinner
Listing 9-2: Teil des Inhalts von appserver_vm.infra
Pipeline für den Beispiel-Stack
Offline-Test-Stages für Stacks
Syntax-Checks
Statische Offline-Code-Analyse
Statische Code-Analyse per API
Testen mit einer Mock-API
Online-Test-Stages für Stacks
Preview: Prüfen, welche Änderungen vorgenommen werden
Verifikation: Aussagen über Infrastruktur-Ressourcen treffen
Ergebnisse: Prüfen, dass die Infrastruktur korrekt arbeitet
Test-Fixtures für den Umgang mit Abhängigkeiten verwenden
Test-Doubles für Upstream-Abhängigkeiten
Test-Fixtures für Downstream-Abhängigkeiten
Komponenten refaktorieren, um sie isolieren zu können
Lebenszyklus-Patterns für Testinstanzen von Stacks
Pattern: Persistent Test Stack
Motivation
Anwendbarkeit
Konsequenzen
Implementierung
Zugehörige Patterns
Pattern: Ephemeral Test Stack
Motivation
Anwendbarkeit
Konsequenzen
Implementierung
Zugehörige Patterns
Antipattern: Dual Persistent and Ephemeral Stack Stages
Motivation
Anwendbarkeit
Konsequenzen
Implementierung
Zugehörige Patterns
Pattern: Periodic Stack Rebuild
Motivation
Anwendbarkeit
Konsequenzen
Implementierung
Zugehörige Patterns
Pattern: Continuous Stack Reset
Motivation
Anwendbarkeit
Konsequenzen
Implementierung
Zugehörige Patterns
Test-Orchestrierung
Unterstützen Sie lokales Testen
Vermeiden Sie eine enge Kopplung mit Pipeline-Tools
Tools zur Test-Orchestrierung
Zusammenfassung
KAPITEL 10. Anwendungs-Laufzeitumgebungen
Cloud-native und anwendungsgesteuerte Infrastruktur
Ziele für eine Anwendungs-Laufzeitumgebung
Deploybare Teile einer Anwendung
Deployment-Pakete
Anwendungen auf Server deployen
Anwendungen als Container verpacken
Anwendungen auf Server-Cluster deployen
Anwendungen auf Anwendungs-Cluster deployen
Pakete zum Deployen von Anwendungen auf Cluster
Listing 10-1: Beispiel für ein Deployment-Manifest eines Anwendungs-Clusters
FaaS-Serverless-Anwendungen deployen
Anwendungsdaten
Datenschemata und -strukturen
Cloud-native Storage-Infrastruktur für Anwendungen
Listing 10-2: Beispiel für ein Anwendungs-Deployment-Manifest mit Daten-Storage
Anwendungs-Connectivity
Service Discovery
Zusammenfassung
KAPITEL 11. Server als Code bauen
Was gibt es auf einem Server
Woher Dinge kommen
Server-Konfigurationscode
Code-Module für die Serverkonfiguration
Code-Module für die Serverkonfiguration designen
Server-Code versionieren und weitergeben
Serverrollen
Server-Code testen
Server-Code progressiv testen
Was Sie bei Server-Code testen
Wie Sie Server-Code testen
Eine neue Server-Instanz erstellen
Eine neue Server-Instanz per Hand erstellen
Einen Server mit einem Skript erstellen
Einen Server mit einem Stack-Management-Tool erstellen
Listing 11-1: Stack-Code, der einen Server definiert
Die Plattform für das automatische Erstellen von Servern konfigurieren
Listing 11-2: Stack-Code zum automatischen Skalieren
Einen Server mit einem Network-Provisioning-Tool erstellen
Server vorbereiten
Hot-Cloning eines Servers
Einen Server-Snapshot verwenden
Ein sauberes Server-Image erstellen
Eine neue Server-Instanz konfigurieren
Eine Server-Instanz ausbacken
Server-Images backen
Backen und Ausbacken kombinieren
Serverkonfiguration beim Erstellen eines Servers anwenden
Listing 11-3: Stack-Code führt mein fiktives Server-Konfigurationstool aus
Zusammenfassung
KAPITEL 12. Änderungen an Servern managen
Patterns zum Changemanagement: Wann Änderungen angewendet werden
Antipattern: Apply on Change
Motivation
Anwendbarkeit
Konsequenzen
Implementierung
Zugehörige Patterns
Pattern: Continuous Configuration Synchronization
Motivation
Anwendbarkeit
Konsequenzen
Implementierung
Zugehörige Patterns
Pattern: Immutable Server
Motivation
Anwendbarkeit
Konsequenzen
Implementierung
Zugehörige Patterns
Wie Sie Serverkonfigurationscode anwenden
Pattern: Push Server Configuration
Motivation
Anwendbarkeit
Konsequenzen
Implementierung
Zugehörige Patterns
Pattern: Pull Server Configuration
Motivation
Anwendbarkeit
Implementierung
Listing 12-1: Beispiel-Stack-Code, der ein Setup-Skript startet
Zugehörige Patterns
Dezentralisierte Konfiguration
Andere Ereignisse im Lebenszyklus eines Servers
Eine Server-Instanz stoppen und erneut starten
Eine Server-Instanz ersetzen
Einen ausgefallenen Server wiederherstellen
Zusammenfassung
KAPITEL 13. Server-Images als Code
Ein Server-Image bauen
Warum ein Server-Image bauen?
Wie Sie ein Server-Image bauen
Tools zum Bauen von Server-Images
Online Image Building
Listing 13-1: Beispielcode für den Image Builder zum Booten eines Original-Image
Infrastruktur für die Builder-Instanz
Listing 13-2: Dynamisch zugewiesene Infrastruktur-Ressourcen
Die Builder-Instanz konfigurieren
Listing 13-3: Die Server-Instanz mit dem Servermaker-Tool konfigurieren
Ein Server-Image mit einfachen Skripten bauen
Listing 13-4: Beispiel-Image-Builder, der Shell-Skripte nutzt
Offline Image Building
Ursprungsinhalte für ein Server-Image
Aus einem Stock-Server-Image bauen
Ein Server-Image von Grund auf bauen
Herkunft eines Server-Image und seiner Inhalte
Ein Server-Image ändern
Ein frisches Image aufwärmen oder backen
Ein Server-Image versionieren
Server-Instanzen aktualisieren, wenn sich ein Image ändert
Ein Server-Image in mehreren Teams verwenden
Umgang mit größeren Änderungen an einem Image
Eine Pipeline zum Testen und Ausliefern eines Server-Image verwenden
Build-Stage für ein Server-Image
Test-Stage für ein Server-Image
Delivery-Stages für ein Server-Image
Mehrere Server-Images verwenden
Server-Images für unterschiedliche Infrastruktur-Plattformen
Server-Images für unterschiedliche Betriebssysteme
Server-Images für unterschiedliche Hardware-Architekturen
Server-Images für unterschiedliche Rollen
Server-Images in Schichten erstellen
Code für mehrere Server-Images verwenden
Zusammenfassung
KAPITEL 14. Cluster als Code bauen
Container als Code
Lösungen für Anwendungs-Cluster
Cluster as a Service
Packaged Cluster Distribution
Stack-Topologien für Anwendungs-Cluster
Monolithischer Stack, der Cluster as a Service nutzt
Listing 14-1: Stack-Code, der alles für ein Cluster definiert
Monolithischer Stack für eine Packaged-Cluster-Lösung
Listing 14-2: Code zum Bauen eines Cluster-Management-Servers
Pipeline für einen monolithischen Anwendungs-Cluster-Stack
Beispiel für mehrere Stacks in einem Cluster
Listing 14-3: Stack-Code, der den Server-Pool mit Host-Knoten definiert
Strategien zur gemeinsamen Verwendung von Anwendungs-Clustern
Ein großes Cluster für alles
Getrennte Cluster für Auslieferungs-Stages
Cluster für die Governance
Cluster für Teams
Service Mesh
Infrastruktur für FaaS Serverless
Zusammenfassung
KAPITEL 15. Zentrale Praktik: Kleine, einfache Elemente
Für Modularität designen
Eigenschaften gut designter Komponenten
Regeln für das Designen von Komponenten
Wiederholungen vermeiden
Regel des Zusammenbaus
Single-Responsibility-Prinzip
Komponenten entlang von Domänenkonzepten entwerfen, nicht entlang technischer Konzepte
Das Gesetz von Demeter
Keine zirkulären Abhängigkeiten
Design-Entscheidungen durch Testen
Infrastruktur modularisieren
Stack-Komponenten versus Stacks als Komponenten
Einen Server in einem Stack verwenden
Shared-Nothing-Infrastruktur
Grenzen zwischen Komponenten ziehen
Grenzen mit natürlichen Änderungsmustern abstimmen
Grenzen mit Komponenten-Lebenszyklen abstimmen
Grenzen mit Organisationsstrukturen abstimmen
Grenzen schaffen, die Resilienz fördern
Grenzen schaffen, die Skalierbarkeit ermöglichen
Vertikales Gruppieren dem horizontalen Gruppieren vorziehen
Grenzen auf Sicherheits- und Governance-Aspekte abstimmen
Zusammenfassung
KAPITEL 16. Stacks aus Komponenten bauen
Infrastruktur-Sprachen für Stack-Komponenten
Deklarativen Code mit Modulen wiederverwenden
Stack-Elemente dynamisch mit Bibliotheken erstellen
Patterns für Stack-Komponenten
Pattern: Facade Module
Listing 16-1: Beispielcode für den Einsatz eines Facade-Moduls
Listing 16-2: Code für das Beispiel-Facade-Modul
Motivation
Anwendbarkeit
Konsequenzen
Implementierung
Zugehörige Patterns
Antipattern: Obfuscation Module
Listing 16-3: Beispielcode für den Einsatz eines Obfuscation-Moduls
Listing 16-4: Code für das Beispiel-Obfuscation-Modul
Motivation
Anwendbarkeit
Konsequenzen
Implementierung
Zugehörige Patterns
Antipattern: Unshared Module
Motivation
Anwendbarkeit
Konsequenzen
Implementierung
Zugehörige Patterns
Pattern: Bundle Module
Listing 16-5: Modul-Code für einen Anwendungsserver
Motivation
Anwendbarkeit
Konsequenzen
Implementierung
Zugehörige Patterns
Antipattern: Spaghetti Module
Listing 16-6: Beispiel für ein Spaghetti-Modul
Motivation
Konsequenzen
Implementierung
Listing 16-7: Beispiel für den Einsatz mehrerer Module statt eines einzelnen Spaghetti-Moduls
Zugehörige Patterns
Pattern: Infrastructure Domain Entity
Motivation
Anwendbarkeit
Implementierung
Zugehörige Patterns
Eine Abstraktionsschicht bauen
Zusammenfassung
KAPITEL 17. Stacks als Komponenten einsetzen
Abhängigkeiten zwischen Stacks erkennen
Pattern: Resource Matching
Motivation
Anwendbarkeit
Konsequenzen
Implementierung
Zugehörige Patterns
Pattern: Stack Data Lookup
Motivation
Anwendbarkeit
Konsequenzen
Implementierung
Listing 17-1: Eine Ressourcen-ID mit einem Stack-Tool über die Datenstruktur der Stack-Instanz finden
Zugehörige Patterns
Pattern: Integration Registry Lookup
Motivation
Anwendbarkeit
Konsequenzen
Implementierung
Zugehörige Patterns
Dependency Injection
Probleme beim Vermischen von Abhängigkeits- und Definitionscode
Abhängigkeiten vom Finde-Mechanismus entkoppeln
Zusammenfassung
KAPITEL 18. Infrastruktur-Code organisieren
Projekte und Repositories organisieren
Ein Repository oder viele?
Ein Repository für alles
Monorepo – ein Repository, ein Build
Ein Repository, mehrere Builds
Ein eigenes Repository für jedes Projekt (Microrepo)
Mehrere Repositories mit mehreren Projekten
Unterschiedliche Arten von Code organisieren
Projektsupport-Dateien
Listing 18-1: Beispiel-Ordnerlayout für ein Projekt
Projektübergreifende Tests
Integrationstests in einem Projekt halten
Dedizierte Projekte für Integrationstests
Code anhand des Domänenkonzepts organisieren
Listing 18-2: Quelldateien nach Technologie organisiert
Dateien mit Konfigurationswerten organisieren
Infrastruktur- und Anwendungscode managen
Infrastruktur und Anwendungen ausliefern
Anwendungen mit Infrastruktur testen
Infrastruktur vor der Integration testen
Infrastruktur-Code zum Deployen von Anwendungen nutzen
Zusammenfassung
KAPITEL 19. Infrastruktur-Code ausliefern
Auslieferungsprozess von Infrastruktur-Code
Ein Infrastruktur-Projekt bauen
Infrastruktur-Code als Artefakt verpacken
Infrastruktur-Code mit einem Repository ausliefern
Spezialisiertes Artefakt-Repository
Tool-spezifisches Repository
Repository in universell nutzbarem Datei-Storage
Code aus einem Quellcode-Repository ausliefern
Projekte integrieren
Pattern: Build-Time Project Integration
Motivation
Anwendbarkeit
Konsequenzen
Implementierung
Zugehörige Patterns
Pattern: Delivery-Time Project Integration
Motivation
Anwendbarkeit
Konsequenzen
Implementierung
Zugehörige Patterns
Pattern: Apply-Time Project Integration
Motivation
Anwendbarkeit
Konsequenzen
Implementierung
Zugehörige Patterns
Infrastruktur-Tools durch Skripte verpacken
Konfigurationswerte zusammenführen
Wrapper-Skripte vereinfachen
Zusammenfassung
KAPITEL 20. Team-Workflows
Die Menschen
Wer schreibt Infrastruktur-Code?
Mit Value Stream Mapping die Workflows verbessern
Code auf Infrastruktur anwenden
Code von Ihrem lokalen Rechner aus anwenden
Code von einem zentralisierten Service anwenden lassen
Private Infrastruktur-Instanzen
Quellcode-Branches in Workflows
Konfigurationsdrift verhindern
Automatisierungs-Verzögerung minimieren
Ad-hoc-Anwendung vermeiden
Code kontinuierlich anwenden
Immutable Infrastruktur
GitOps
Governance in einem Pipeline-basierten Workflow
Zuständigkeiten neu ordnen
Shift Left
Ein Beispielprozess für Infrastructure as Code mit Governance
Zusammenfassung
KAPITEL 21. Infrastruktur sicher ändern
Reduzieren Sie den Umfang von Änderungen
Kleine Änderungen
Refaktorieren – ein Beispiel
Unvollständige Änderungen in die Produktivumgebung übernehmen
Parallele Instanzen
Abwärtskompatible Transformationen
Feature Toggles
Live-Infrastruktur ändern
Infrastruktur-Chirurgie
Expand and Contract
Zero-Downtime-Änderungen
Blue-Green-Änderungen
Kontinuität
Kontinuität durch das Verhindern von Fehlern
Kontinuität durch schnelles Wiederherstellen
Kontinuierliches Disaster Recovery
Chaos Engineering
Für Ausfälle planen
Datenkontinuität in einem sich ändernden System
Sperren
Aufteilen
Replizieren
Neu laden
Ansätze zur Datenkontinuität mischen
Zusammenfassung
Fußnoten. Vorwort
Kapitel 1: Was ist Infrastructure as Code?
Kapitel 2: Prinzipien der Infrastruktur im Cloud-Zeitalter
Kapitel 3: Infrastruktur-Plattformen
Kapitel 4: Zentrale Praktik: Definieren Sie alles als Code
Kapitel 5: Infrastruktur-Stacks als Code bauen
Kapitel 6: Umgebungen mit Stacks bauen
Kapitel 7: Stack-Instanzen konfigurieren
Kapitel 8: Zentrale Praktik: Kontinuierlich testen und ausliefern
Kapitel 9: Infrastruktur-Stacks testen
Kapitel 10: Anwendungs-Laufzeitumgebungen
Kapitel 11: Server als Code bauen
Kapitel 12: Änderungen an Servern managen
Kapitel 13: Server-Images als Code
Kapitel 14: Cluster als Code bauen
Kapitel 15: Zentrale Praktik: Kleine, einfache Elemente
Kapitel 16: Stacks aus Komponenten bauen
Kapitel 17: Stacks als Komponenten einsetzen
Kapitel 18: Infrastruktur-Code organisieren
Kapitel 19: Infrastruktur-Code ausliefern
Kapitel 20: Team-Workflows
Kapitel 21: Infrastruktur sicher ändern
Index
A
B
C
D
E
F
G
H
I
J
K
L
M
N
O
P
Q
R
S
T
U
V
W
X
Y
Z
Über den Autor
Kolophon
