Log In
Or create an account ->
Imperial Library
Home
About
News
Upload
Forum
Help
Login/SignUp
Index
Cover
Titel
Impressum
Inhalt
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
Die ShopSpinner-Beispiele
In diesem Buch verwendete Konventionen
Danksagung
Teil I Grundlagen
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
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
Prinzip: Variationen minimieren
Konfigurationsdrift
Prinzip: Stellen Sie sicher, dass Sie jeden Prozess wiederholen können
Zusammenfassung
3 Infrastruktur-Plattformen
Die Elemente eines Infrastruktur-Systems
Dynamische Infrastruktur-Plattform
Infrastruktur-Ressourcen
Computing-Ressourcen
Storage-Ressourcen
Networking-Ressourcen
Zusammenfassung
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
Infrastruktur-Scripting
Deklarative Infrastruktur-Sprachen
Programmierbare, imperative Infrastruktur-Sprachen
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
Zusammenfassung
Teil II Arbeiten mit Infrastruktur-Stacks
5 Infrastruktur-Stacks als Code bauen
Was ist ein Infrastruktur-Stack?
Stack-Code
Stack-Instanzen
Server in einem Stack konfigurieren
Low-Level-Infrastruktur-Sprachen
High-Level-Infrastruktur-Sprachen
Patterns und Antipatterns für das Strukturieren von Stacks
Antipattern: Monolithic Stack
Pattern: Application Group Stack
Pattern: Service Stack
Pattern: Micro Stack
Zusammenfassung
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
Antipattern: Copy-Paste Environments
Pattern: Reusable Stack
Umgebungen mit mehreren Stacks erstellen
Zusammenfassung
7 Stack-Instanzen konfigurieren
Eindeutige Kennungen durch Stack-Parameter erstellen
Beispiel-Stack-Parameter
Patterns zum Konfigurieren von Stacks
Antipattern: Manual Stack Parameters
Pattern: Stack Environment Variables
Pattern: Scripted Parameters
Pattern: Stack Configuration Files
Pattern: Wrapper-Stack
Pattern: Pipeline Stack Parameters
Pattern: Stack Parameter Registry
Konfigurations-Registry
Eine Konfigurations-Registry implementieren
Eine oder mehrere Konfigurations-Registries
Secrets als Parameter nutzen
Secrets verschlüsseln
Secretlose Autorisierung
Secrets zur Laufzeit injizieren
Wegwerf-Secrets
Zusammenfassung
8 Zentrale Praktik: Kontinuierlich testen und ausliefern
Warum Infrastruktur-Code kontinuierlich testen?
Was kontinuierliches Testen bedeutet
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
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
9 Infrastruktur-Stacks testen
Beispiel-Infrastruktur
Der Beispiel-Stack
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
Pattern: Ephemeral Test Stack
Antipattern: Dual Persistent and Ephemeral Stack Stages
Pattern: Periodic Stack Rebuild
Pattern: Continuous Stack Reset
Test-Orchestrierung
Unterstützen Sie lokales Testen
Vermeiden Sie eine enge Kopplung mit Pipeline-Tools
Tools zur Test-Orchestrierung
Zusammenfassung
Teil III Mit Servern und anderen Anwendungs-Laufzeitplattformen arbeiten
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
FaaS-Serverless-Anwendungen deployen
Anwendungsdaten
Datenschemata und -strukturen
Cloud-native Storage-Infrastruktur für Anwendungen
Anwendungs-Connectivity
Service Discovery
Zusammenfassung
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
Die Plattform für das automatische Erstellen von Servern konfigurieren
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
Zusammenfassung
12 Änderungen an Servern managen
Patterns zum Changemanagement: Wann Änderungen angewendet werden
Antipattern: Apply on Change
Pattern: Continuous Configuration Synchronization
Pattern: Immutable Server
Wie Sie Serverkonfigurationscode anwenden
Pattern: Push Server Configuration
Pattern: Pull Server Configuration
Andere Ereignisse im Lebenszyklus eines Servers
Eine Server-Instanz stoppen und erneut starten
Eine Server-Instanz ersetzen
Einen ausgefallenen Server wiederherstellen
Zusammenfassung
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
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
14 Cluster als Code bauen
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
Monolithischer Stack für eine Packaged-Cluster-Lösung
Pipeline für einen monolithischen Anwendungs-Cluster-Stack
Beispiel für mehrere Stacks in einem Cluster
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
Teil IV Infrastruktur designen
15 Zentrale Praktik: Kleine, einfache Elemente
Für Modularität designen
Eigenschaften gut designter Komponenten
Regeln für das Designen von Komponenten
Design-Entscheidungen durch Testen
Infrastruktur modularisieren
Stack-Komponenten versus Stacks als Komponenten
Einen Server in einem Stack verwenden
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
Grenzen auf Sicherheits- und Governance-Aspekte abstimmen
Zusammenfassung
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
Antipattern: Obfuscation Module
Antipattern: Unshared Module
Pattern: Bundle Module
Antipattern: Spaghetti Module
Pattern: Infrastructure Domain Entity
Eine Abstraktionsschicht bauen
Zusammenfassung
17 Stacks als Komponenten einsetzen
Abhängigkeiten zwischen Stacks erkennen
Pattern: Resource Matching
Pattern: Stack Data Lookup
Pattern: Integration Registry Lookup
Dependency Injection
Zusammenfassung
Teil V Infrastruktur bereitstellen
18 Infrastruktur-Code organisieren
Projekte und Repositories organisieren
Ein Repository oder viele?
Ein Repository für alles
Ein eigenes Repository für jedes Projekt (Microrepo)
Mehrere Repositories mit mehreren Projekten
Unterschiedliche Arten von Code organisieren
Projektsupport-Dateien
Projektübergreifende Tests
Dedizierte Projekte für Integrationstests
Code anhand des Domänenkonzepts organisieren
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
19 Infrastruktur-Code ausliefern
Auslieferungsprozess von Infrastruktur-Code
Ein Infrastruktur-Projekt bauen
Infrastruktur-Code als Artefakt verpacken
Infrastruktur-Code mit einem Repository ausliefern
Projekte integrieren
Pattern: Build-Time Project Integration
Pattern: Delivery-Time Project Integration
Pattern: Apply-Time Project Integration
Infrastruktur-Tools durch Skripte verpacken
Konfigurationswerte zusammenführen
Wrapper-Skripte vereinfachen
Zusammenfassung
20 Team-Workflows
Die Menschen
Wer schreibt Infrastruktur-Code?
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
Governance in einem Pipeline-basierten Workflow
Zuständigkeiten neu ordnen
Shift Left
Ein Beispielprozess für Infrastructure as Code mit Governance
Zusammenfassung
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
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
Index
Über den Autor
Kolophon
← Prev
Back
Next →
← Prev
Back
Next →