Das AMI Ihrer Instanzen zu wechseln heißt, das Fundament Ihres Dienstes zu tauschen, während er weiterläuft. Schlecht gemacht bedeutet das Ausfälle; gut gemacht ist es für Nutzer nahezu unsichtbar. Die gute Nachricht: Es gibt erprobte Muster, die diese Migration sicher und umkehrbar machen.
Die gemeinsame Basis: keine laufenden Instanzen bearbeiten, sondern neue Instanzen mit dem neuen AMI starten und den Verkehr kontrolliert umlenken.
Vor der Migration: Boden bereiten
- Testen Sie das neue AMI in einer Staging-Umgebung, die der Produktion gleicht.
- Verlässliche Health Checks: Prüfungen definieren, die bestätigen, dass eine neue Instanz wirklich gesund ist.
- Rollback-Plan: Vorgängerversion und Rückkehrprozedur bereithalten.
- Beobachtbarkeit: Metriken und Alarme, um Regressionen sofort zu erkennen.
Migrationsstrategien ohne Ausfallzeit
| Strategie | Funktionsweise | Ideal für |
|---|---|---|
| Rolling Update | Ersetzt Instanzen schubweise, nach und nach | Dienste in einer Auto Scaling Group |
| Blue/Green | Neue Umgebung aufbauen, Verkehr auf einmal umschalten | Migrationen mit sofortigem Rollback |
| Canary | Kleinen Prozentsatz des Verkehrs auf die neue Version schicken | Validierung in Produktion bei geringem Risiko |
Drei Muster, um das AMI ohne Serviceunterbrechung zu wechseln.
Rolling Update
Sie aktualisieren das Launch Template mit dem neuen AMI, und die Auto Scaling Group ersetzt die Instanzen in Wellen: Sie startet neue, wartet auf den Health Check und nimmt die alten heraus. Einfach und ohne zusätzliche Infrastruktur, wobei eine Zeit lang beide Versionen koexistieren.
Blue/Green
Sie bauen eine parallele Umgebung (green) mit dem neuen AMI auf, während die aktuelle (blue) weiter bedient. Ist green validiert, leiten Sie den Verkehr im Load Balancer oder im DNS um. Geht etwas schief, sind Sie in Sekunden zurück auf blue. Das Muster mit dem schnellsten Rollback – zum Preis vorübergehend doppelter Ressourcen.
Canary
Sie schicken einen kleinen Anteil des Verkehrs auf Instanzen mit dem neuen AMI und beobachten. Halten die Metriken, erhöhen Sie den Anteil schrittweise bis 100 %. Das minimiert den Wirkungsradius eines unerwarteten Problems.
Nach der Migration
- Beobachten Sie Metriken und Logs eine angemessene Zeit, bevor Sie die Migration als gelungen abhaken.
- Markieren Sie das alte AMI als veraltet, damit es nicht versehentlich neu gestartet wird.
- Dokumentieren Sie die ausgerollte Version und den Grund für den Wechsel.
- Löschen Sie das Vorgänger-Image nicht sofort: Bewahren Sie es für den Rollback-Fall auf.
Häufig gestellte Fragen
Welche Strategie ist am besten für null Ausfallzeit?
Blue/Green bietet das schnellste Rollback; Rolling Update ist einfacher und günstiger; Canary minimiert das Risiko durch Validierung in Produktion. Die Wahl hängt von Risikotoleranz und Infrastrukturbudget ab.
Muss ich die Infrastruktur zum Migrieren verdoppeln?
Nur bei Blue/Green, und nur vorübergehend. Mit Rolling Update oder Canary nutzen Sie dieselbe Gruppe und ersetzen Instanzen nach und nach, ohne die ganze Umgebung zu verdoppeln.
Wie stelle ich sicher, dass ich zurück kann?
Bewahren Sie das vorherige AMI und sein Launch Template auf, definieren Sie verlässliche Health Checks und testen Sie die Rollback-Prozedur, bevor die Migration beginnt.
Bei imaxe.cloud versionieren wir unsere Images, damit der Wechsel zwischen Versionen vorhersehbar und umkehrbar ist.
