Die Nordlicht Reisen GmbH baut für das Buchungsportal drei Umgebungen: Entwicklung, Test und Produktion. Bisher hat jemand die Ressourcen im Portal angelegt und die Unterschiede zwischen den Umgebungen im Kopf behalten. Nach dem dritten Fehler, der nur in der Produktion auftrat, soll die Infrastruktur selbst Quellcode werden: im Repository, mit Review, mit Tests und mit einer Pipeline, die sie ausrollt. Das sind die Fähigkeiten dieser Lektion: Konfigurationsmanagement empfehlen und umsetzen und eine IaC-Strategie entwerfen (Quellcodeverwaltung, Test und Bereitstellung automatisieren).
Vorwissen: Die Sprache Bicep, Module, Parameterdateien und Umgebungen mit azd kennen Sie aus K3, Modul 3.2 (Lektionen 3.2.2, 3.2.3 und 3.2.6). What-if, sein Rauschen, der vollständige Modus und die Bereitstellungsstapel stehen in K3, Lektion 3.2.4; die Lektion wiederholt das nicht. Freigaben vor dem Deploy zeigt K3, Lektion 3.7.6, Pull-Request-Regeln Lektion 2.2. Diese Lektion fragt: Welches Werkzeug für welche Aufgabe, und wie sieht die Pipeline aus, die Infrastruktur sicher ausrollt?
Nicht gegen Azure oder GitHub ausgeführt; aus der Referenz von Microsoft: Alle Befehle, YAML- und Bicep-Dateien dieser Lektion stammen aus Microsofts Dokumentation (teils angepasst) und sind in diesem Kurs nicht ausgeführt worden. Namen in spitzen Klammern sind Platzhalter.
Konfigurationsmanagement empfehlen
Zwei Dinge heißen im Alltag „Konfiguration“. Infrastruktur ist, welche Ressourcen es gibt: Netz, Datenbank, App. Konfiguration im engeren Sinn ist, wie eine Maschine oder ein Dienst von innen eingestellt ist: Betriebssystemeinstellungen, installierte Software, Anwendungseinstellungen. Microsofts Anleitung zu Werkzeugen für virtuelle Maschinen ordnet die Werkzeuge deshalb nach Aufgabe:
- Die Konfiguration von VMs automatisieren: Ansible, Chef, Puppet, Bicep und ARM-Vorlagen; speziell für VM-Anpassung cloud-init (Linux), PowerShell Desired State Configuration (DSC) und die Custom Script Extension.
- Die Verwaltung der Infrastruktur automatisieren: Packer (eigene VM-Images bauen), Terraform (die Infrastruktur aufbauen), Azure Automation (Aktionen über Azure und lokale Infrastruktur).
- Anwendungsbereitstellung und -auslieferung: Azure DevOps Services, Jenkins (Lektion 4.11).
Die Werkzeuge im Vergleich
| Werkzeug | Was Microsoft darüber sagt | Typische Aufgabe |
|---|---|---|
| Bicep | domänenspezifische Sprache mit deklarativer Syntax für Azure-Ressourcen; knappe Syntax, Typsicherheit, Wiederverwendung von Code | Azure-Ressourcen anlegen und ändern |
| Terraform | quelloffenes Werkzeug von HashiCorp; beschreibt die Topologie der Cloud-Ressourcen in der Konfigurationssprache HCL; Vorlagen anderer Plattformen lassen sich mit Azure nutzen, ohne sie in eine ARM-Vorlage zu übersetzen | Infrastruktur über mehrere Plattformen mit einem Format |
| Ansible | Automatisierungsmaschine für Konfiguration, VM-Anlage und Anwendungsbereitstellung; ohne Agent, meist mit SSH-Schlüsseln; Aufgaben stehen in Playbooks | Konfiguration von Maschinen von außen |
| Chef | Automatisierungsplattform; Chef-Clients auf den Zielmaschinen, ein oder mehrere zentrale Chef-Server speichern die Konfigurationen; Chef InSpec prüft Einhaltung | Konfiguration mit Agent und zentralem Server |
| Puppet | Plattform für Auslieferung und Bereitstellung; Agents auf den Zielmaschinen, der Puppet Master führt Manifeste aus, die den gewünschten Zustand beschreiben | wie Chef, mit Manifesten |
| PowerShell DSC, Machine Configuration | gewünschten Zustand im Betriebssystem herstellen und prüfen | Lektion 4.13 |
| Azure App Configuration | Konfigurationsdienst für PaaS-Anwendungen, der selbst mit IaC bereitgestellt werden kann | Anwendungseinstellungen, Feature Flags (Lektion 4.10) |
Microsofts Leitfaden zum Entwerfen guter Betriebsabläufe (Well-Architected Framework) sagt dazu, was als Entscheidung taugt: Nehmen Sie das richtige Werkzeug für die Aufgabe. Bicep zur Bereitstellung sei nicht für jede Verwaltungsaufgabe das beste Werkzeug. Für den gewünschten Zustand von VMs nennt der Leitfaden als Beispiel Ansible, für Kubernetes-Cluster Flux, für PaaS-Dienste die Konfigurationsdienste der Plattform (etwa Azure App Configuration), die man wiederum mit IaC bereitstellt. SaaS-Dienste sind oft eingeschränkter, weil die Plattform sie enger steuert. Standardisieren Sie auf Werkzeuge, die alle Aufgaben in Ihrem Rahmen abdecken und in Ihre Entwicklungs- und Verwaltungspraxis passen.
Deklarativ, imperativ, idempotent
Drei Wörter kommen in jeder Frage zu IaC vor. Imperativ beschreibt Schritte („installiere dies, ändere das“), deklarativ den Endzustand („so soll es aussehen“). Microsofts Einführung zu IaC empfiehlt deklarative Definitionsdateien, wenn möglich: Eine Datei beschreibt, welche Komponenten und Einstellungen eine Umgebung braucht, nicht unbedingt, wie man dorthin kommt. Das lässt dem Anbieter Raum für optimierte Verfahren und verringert die technische Schuld imperativer Bereitstellungsskripte. Eine einheitliche Syntax für deklarative IaC gibt es nicht; sie richtet sich nach der Zielplattform (Formate wie YAML, JSON, XML).
Idempotenz ist die Fähigkeit einer Operation, immer dasselbe Ergebnis zu liefern. Microsoft: Ein Bereitstellungsbefehl setzt die Zielumgebung immer in dieselbe Konfiguration, egal wie sie vorher aussah. Erreicht wird das, indem man das vorhandene Ziel automatisch konfiguriert oder es verwirft und frisch neu anlegt. Das ist der Grund, warum IaC das Problem der Umgebungsdrift löst: Ohne IaC wird jede Umgebung zur „Schneeflocke“, einer Konfiguration, die sich nicht automatisch reproduzieren lässt. Mit IaC ändert das Team die Quelle, nicht das Ziel.