Das Buchungsportal der Nordlicht Reisen GmbH besteht aus einer Web-App, einer Schnittstelle (API) und einem Dienst für Zahlungen. Bei jeder Auslieferung ist die Frage nicht mehr „wie kommt die neue Version in die Produktion“, sondern: Wer sieht sie zuerst, wie schnell wächst der Kreis, und wie kommen wir zurück? Das ist die Fähigkeit dieser Lektion: Bereitstellungsstrategien (Blue-Green, Canary, Ring, schrittweises Ausrollen, Feature Flags, A/B-Tests) und Bereitstellungen in der Reihenfolge ihrer Abhängigkeiten.
Vorwissen: Revisionen von Azure Container Apps, den Verkehr auf 10 Prozent zu stellen und zurückzurollen, lehrt K3, Lektion 3.7.6; Stufen, dependsOn und needs kennen Sie aus Lektion 4.3, Prüfungen und Genehmigungen aus Lektion 4.7. Hier geht es um den Entwurf: welche Strategie für welchen Dienst und wie sie in der Pipeline aussieht. Feature Flags im Einzelnen folgen in Lektion 4.10, Verfahren gegen Ausfallzeit und der Hotfix-Pfad in Lektion 4.9.
Nicht gegen Azure, GitHub oder Azure DevOps ausgeführt; aus der Referenz von Microsoft und GitHub: Alle Befehle, YAML-Dateien und Menüpfade dieser Lektion stammen aus der Dokumentation oder sind aus ihr abgeleitet; sie sind in diesem Kurs nicht ausgeführt worden.
Ein gemeinsamer Rahmen: Wer sieht was, wann
Microsoft beschreibt in den Leitfäden zu sicheren Bereitstellungen eine Grundidee: Schrittweises Ausrollen (progressive exposure). Eine Version wird zuerst einer kleinen Gruppe mit hoher Risikotoleranz gezeigt; bewährt sie sich, wächst der Kreis, bis alle sie benutzen. Das begrenzt den Wirkungsradius (blast radius) eines Fehlers. Die Strategien dieser Lektion sind Wege dahin, jeder mit einem eigenen Rückweg.
| Strategie | Prinzip | Rückweg | Was sie kostet |
|---|---|---|---|
| Blue-Green | zwei gleiche Umgebungen; die neue (green) wird getestet und bekommt dann den Verkehr | Verkehr zurück auf blue | zwei Umgebungen gleichzeitig |
| Canary | die neue Version bekommt zuerst einen kleinen Teil der Server oder des Verkehrs | Anteil auf 0, Rest bleibt | die Steuerung des Anteils |
| Ring | feste Gruppen (Ringe) von Nutzern oder Umgebungen, einer nach dem anderen | Auslieferung stoppt am Ring, der Fehler zeigt | mehrere Stufen, Wartezeit |
| Schrittweise (progressive exposure) | der Oberbegriff: Stufen, Feature Flags, freiwillige Teilnahme | je nach Mittel | Beobachtung zwischen den Stufen |
| A/B-Test | zwei Fassungen nebeneinander, um zu messen, welche ein Ziel besser erreicht | eine Fassung abschalten | Messung, Auswertung |
Blue-Green
In einer Blue-Green-Bereitstellung setzen Sie zwei gleiche Umgebungen auf. Die eine (blue) läuft mit der aktuellen Version und bekommt den Verkehr der Nutzer; in der anderen (green) läuft die neue Version, zunächst ohne Verkehr. Nach den Tests lenken Sie den Verkehr auf green. Gibt es Probleme, lenken Sie ihn zurück; blue läuft ja noch. Microsoft fasst die Schritte in Container Apps zusammen: Test und Prüfung (funktional, Leistung, Verträglichkeit), Umschalten des Verkehrs, Rückweg und Rollenwechsel (beim nächsten Mal ist green die stabile Umgebung). Der Leitfaden zu sicheren Bereitstellungen beschreibt eine Abart, bei der der Verkehr nach und nach in größeren Wellen auf green wandert; die beiden Pools müssen jeweils die volle Last tragen können und sollen logisch getrennt sein.
Canary
Bei Canary erhält zuerst eine kleine Gruppe (intern oder extern) die neue Version; läuft sie dort ohne Probleme, wird sie schrittweise auf größere Gruppen ausgedehnt. Microsoft nennt Feature Flags als übliches Mittel, die neue Version für die Zielgruppe zu aktivieren. Der erste Ring einer Ring-Bereitstellung kann ein Canary sein.
Ring-Bereitstellung und Stufen
Microsoft beschreibt die Ringe als Stufen (tiers) mit einem Zweck: Stufe 0 findet die meisten Fehler, die Nutzer beträfen (intern, hohe Fehlertoleranz), Stufe 1 deckt Bereiche ab, die das Team nicht ausführlich testet (Kunden mit breiter Nutzung, ein kleines Rechenzentrum), Stufe 2 findet Fehler der Größenordnung (öffentliche Konten, ein mittleres bis großes Rechenzentrum), Stufe 3 Fehler bei großen internen Konten und einer europäischen Region, Stufe 4 sind alle übrigen Einheiten. Zwischen den Ringen liegt die Wartezeit (bake time): Manche Fehler zeigen sich erst nach Stunden. Microsoft nennt einen Tag als in der Regel ausreichend, mit einer Spitzenzeit darin, und rät in der Well-Architected-Empfehlung, die Wartezeiten in Stunden und Tagen zu messen und von Ring zu Ring zu verlängern. Fehlerhafte Auslieferungen sollen an dem Ring anhalten, in dem sie auffallen; man rollt dann zurück, nach vorn (mit einem Hotfix) oder stellt neue Infrastruktur nach dem letzten guten Stand bereit.
A/B-Test
Ein A/B-Test vergleicht zwei Fassungen eines Dienstes oder einer Oberfläche gegen ein Ziel. Microsoft nennt ihn leicht zu verwenden, weil die Änderungen meist klein sind und am kundennahen Rand liegen. Er ist keine Sicherheitsmaßnahme, sondern ein Messverfahren: Es kommt darauf an, wie der Verkehr verteilt wird und was gemessen wird. Container Apps nennt die Verkehrsaufteilung ausdrücklich für Blue-Green und für A/B-Tests; Azure App Configuration hat dafür den Typ Experiment (Lektion 4.10).
Der Rahmen von Microsoft in einer Zeile
Zwei Grundsätze gelten für alle: Es gibt keine risikoarme Bereitstellung in der Produktion, also gilt jede nach demselben Muster und automatisiert; und kleine, häufige Bereitstellungen sind besser als seltene große, weil Fehler leichter zu finden sind.