Читать книгу Handbuch Infrastructure as Code - Kief Morris - Страница 5
Inhalt
ОглавлениеWarum ich dieses Buch geschrieben habe
Was in dieser Auflage neu und anders ist
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
In diesem Buch verwendete Konventionen
1Was ist Infrastructure as Code?
Aus der Eisenzeit in das Cloud-Zeitalter
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«
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
2Prinzipien der Infrastruktur im Cloud-Zeitalter
Prinzip: Gehen Sie davon aus, dass Systeme unzuverlässig sind
Prinzip: Alles reproduzierbar machen
Prinzip: Erstellen Sie wegwerfbare Elemente
Prinzip: Variationen minimieren
Prinzip: Stellen Sie sicher, dass Sie jeden Prozess wiederholen können
Die Elemente eines Infrastruktur-Systems
Dynamische Infrastruktur-Plattform
4Zentrale 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
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
Teil IIArbeiten mit Infrastruktur-Stacks
5Infrastruktur-Stacks als Code bauen
Was ist ein Infrastruktur-Stack?
Server in einem Stack konfigurieren
Low-Level-Infrastruktur-Sprachen
High-Level-Infrastruktur-Sprachen
Patterns und Antipatterns für das Strukturieren von Stacks
Pattern: Application Group Stack
Umgebungen, Konsistenz und Konfiguration
Patterns zum Bauen von Umgebungen
Antipattern: Multiple-Enviroment Stack
Antipattern: Copy-Paste Environments
Umgebungen mit mehreren Stacks erstellen
7Stack-Instanzen konfigurieren
Eindeutige Kennungen durch Stack-Parameter erstellen
Patterns zum Konfigurieren von Stacks
Antipattern: Manual Stack Parameters
Pattern: Stack Environment Variables
Pattern: Stack Configuration Files
Pattern: Pipeline Stack Parameters
Pattern: Stack Parameter Registry
Eine Konfigurations-Registry implementieren
Eine oder mehrere Konfigurations-Registries
Secrets zur Laufzeit injizieren
8Zentrale 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
Infrastruktur-Delivery-Pipelines
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
Pipeline für den Beispiel-Stack
Offline-Test-Stages für Stacks
Statische Offline-Code-Analyse
Statische Code-Analyse per API
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
Antipattern: Dual Persistent and Ephemeral Stack Stages
Pattern: Periodic Stack Rebuild
Pattern: Continuous Stack Reset
Unterstützen Sie lokales Testen
Vermeiden Sie eine enge Kopplung mit Pipeline-Tools
Teil IIIMit Servern und anderen Anwendungs-Laufzeitplattformen arbeiten
10Anwendungs-Laufzeitumgebungen
Cloud-native und anwendungsgesteuerte Infrastruktur
Ziele für eine Anwendungs-Laufzeitumgebung
Deploybare Teile einer Anwendung
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
Cloud-native Storage-Infrastruktur für Anwendungen
Code-Module für die Serverkonfiguration
Code-Module für die Serverkonfiguration designen
Server-Code versionieren und weitergeben
Was Sie bei 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
Einen Server-Snapshot verwenden
Ein sauberes Server-Image erstellen
Eine neue Server-Instanz konfigurieren
Backen und Ausbacken kombinieren
Serverkonfiguration beim Erstellen eines Servers anwenden
12Änderungen an Servern managen
Patterns zum Changemanagement: Wann Änderungen angewendet werden
Pattern: Continuous Configuration Synchronization
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
Einen ausgefallenen Server wiederherstellen
Wie Sie ein Server-Image bauen
Tools zum Bauen von Server-Images
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 frisches Image aufwärmen oder backen
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
Lösungen für Anwendungs-Cluster
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
Getrennte Cluster für Auslieferungs-Stages
Infrastruktur für FaaS Serverless
15Zentrale Praktik: Kleine, einfache Elemente
Eigenschaften gut designter Komponenten
Regeln für das Designen von Komponenten
Design-Entscheidungen durch Testen
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
16Stacks 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
Antipattern: Obfuscation Module
Pattern: Infrastructure Domain Entity
Eine Abstraktionsschicht bauen
17Stacks als Komponenten einsetzen
Abhängigkeiten zwischen Stacks erkennen
Pattern: Integration Registry Lookup
Teil VInfrastruktur bereitstellen
18Infrastruktur-Code organisieren
Projekte und Repositories organisieren
Ein eigenes Repository für jedes Projekt (Microrepo)
Mehrere Repositories mit mehreren Projekten
Unterschiedliche Arten von Code organisieren
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
19Infrastruktur-Code ausliefern
Auslieferungsprozess von Infrastruktur-Code
Ein Infrastruktur-Projekt bauen
Infrastruktur-Code als Artefakt verpacken
Infrastruktur-Code mit einem Repository ausliefern
Pattern: Build-Time Project Integration
Pattern: Delivery-Time Project Integration
Pattern: Apply-Time Project Integration
Infrastruktur-Tools durch Skripte verpacken
Konfigurationswerte zusammenführen
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
Governance in einem Pipeline-basierten Workflow
Ein Beispielprozess für Infrastructure as Code mit Governance
Reduzieren Sie den Umfang von Änderungen
Unvollständige Änderungen in die Produktivumgebung übernehmen
Abwärtskompatible Transformationen
Kontinuität durch das Verhindern von Fehlern
Kontinuität durch schnelles Wiederherstellen
Kontinuierliches Disaster Recovery
Datenkontinuität in einem sich ändernden System
