Früher bedeutete die Veröffentlichung von Software ein Wartungsfenster und das Drücken der Daumen. Moderne Teams verwenden Strategien, die Releases zur Routine machen, und die Wahl zwischen Blue-Green vs. Canary-Deployment ist eine der ersten, mit der Sie konfrontiert werden. Beide verringern das Risiko, tun dies jedoch auf entgegengesetzte Weise: Der eine bereitet einen vollständigen Ersatz vor, während der andere nach und nach Tests mit echten Benutzern durchführt.

In diesem Leitfaden wird erläutert, wie die einzelnen Funktionen funktionieren und was sie in der Praxis kosten. Wir haben die kleinen Benutzer-Routing- und Rollback-Beispiele in Python 3.13 ausgeführt, und die Ausgabe stammt von diesem Lauf. Die Kubernetes-Beispiele dienen der Veranschaulichung und wurden von uns nicht ausgeführt. Betrachten Sie die Prozentsätze und Schwellenwerte als erste Beispiele für die Anpassung.

Die kurze Antwort

Mit der Blau-Grün-Bereitstellung führen Sie zwei identische Produktionsumgebungen aus. Einer bedient Benutzer, während Sie auf dem anderen die neue Version bereitstellen und testen und dann den gesamten Datenverkehr in einem Schritt umstellen.

Bei der Canary-Bereitstellung läuft die neue Version neben der alten. Sie senden ihm einen kleinen Prozentsatz des echten Traffics, vergleichen die Ergebnisse und erhöhen den Anteil Schritt für Schritt, bis er allen dient. Der Name stammt von den Kanarischen Bergleuten, die einst als Frühwarngerät vor Gefahren dienten.

Blaugrün vs. Kanarienvogel nebeneinander

So funktioniert die Blau-Grün-Bereitstellung

1. Blue ist live und bedient den gesamten Verkehr.
2. Stellen Sie die neue Version auf Green bereit, das keinen Benutzerverkehr empfängt.
3. Testen Sie Grün gründlich in der realen Produktionsumgebung, indem Sie Rauchtests und interne Benutzer verwenden.
4. Schalten Sie den Router, Load Balancer oder DNS so um, dass der Datenverkehr auf Grün gesendet wird.
5. Beobachten Sie genau, Blau läuft noch und ist bereit.
6. Wenn etwas nicht stimmt, wechseln Sie zurück. Wenn alles in Ordnung ist, wird Blau zur nächsten Ruheumgebung.

In Kubernetes können Sie den Wechsel durchführen, indem Sie den Selektor eines Dienstes ändern, sodass der Datenverkehr zu Pods mit unterschiedlichen Bezeichnungen verschoben wird:

apiVersion: v1
kind: Service
metadata:
  name: shop
spec:
  selector:
    app: shop
    version: green   # was: blue
  ports:
    - port: 80
      targetPort: 8000

Stärken: Es ist konzeptionell einfach, Sie können das genaue Produktions-Setup testen, bevor Benutzer es sehen, und das Rollback erfolgt nahezu augenblicklich. Schwächen: Eine doppelte Infrastruktur kann teuer sein, ein Fehler, der Ihren Tests entgeht, erreicht alle auf einmal, und offene Sitzungen und Arbeiten während des Flugs müssen während des Wechsels betreut werden. Wenn Sie DNS für den Switch verwenden, können zwischengespeicherte Datensätze ihn verzögern. Neu in den Konzepten? Sehen Sie sich unser Kubernetes-Tutorial für Anfänger an.

So funktioniert die Canary-Bereitstellung

1. Stellen Sie die neue Version zusammen mit der stabilen Version bereit.
2. Leiten Sie einen kleinen Teil des Datenverkehrs, zum Beispiel 5 %, an den Kanarienvogel weiter.
3. Vergleichen Sie Fehlerraten, Latenz und Geschäftskennzahlen mit der stabilen Version.
4. Wenn es gesund ist, erhöhen Sie es auf 25 %, dann auf 50 % und dann auf 100 %.
5. Wenn sich etwas verschlechtert, leiten Sie den gesamten Datenverkehr an die stabile Version zurück.

Viele Teams beginnen zunächst mit internen Mitarbeitern, dann mit einer Region mit geringem Risiko und erst dann mit der breiten Öffentlichkeit.

Stärken: Eine schlechte Version betrifft nur eine kleine Gruppe, und aus dem echten Datenverkehr lernt man, dass keine Testumgebung eine vollständige Reproduktion durchführen kann. Schwächen: Sie benötigen ein prozentuales Routing und Kennzahlen pro Version, Rollouts dauern länger und zwei Versionen laufen eine Zeit lang zusammen. Ein kleiner Kanarienvogel kann auch zu leise sein, um ein sinnvolles Signal zu geben, insbesondere in verkehrsarmen Zeiten.

Stabile Benutzerweiterleitung

Die zufällige Auswahl einer Version bei jeder Anfrage führt für Benutzer zu einer verwirrenden Erfahrung, da sie möglicherweise zwischen der alten und der neuen Version hin- und herwechseln. Eine gängige Lösung besteht darin, eine stabile Benutzer-ID in einen Bucket zu hashen, sodass jeder Benutzer immer die gleiche Antwort erhält:

import hashlib

def bucket(user_id):
    digest = hashlib.sha256(user_id.encode()).hexdigest()
    return int(digest, 16) % 100

def version_for(user_id, canary_percent):
    return "v2" if bucket(user_id) < canary_percent else "v1"

users = [f"user-{i}" for i in range(10000)]
for percent in (5, 25, 50, 100):
    share = sum(version_for(u, percent) == "v2" for u in users) / len(users)
    print(percent, round(share * 100, 1))

# 5 5.0
# 25 24.5
# 50 49.9
# 100 100.0

Der tatsächliche Anteil folgte knapp dem Zielwert. Diese Methode hat zwei weitere nützliche Eigenschaften und unser Test bestätigte beide. Derselbe Benutzer erhielt immer die gleiche Version. Und jeder in der 5 %-Gruppe war immer noch bei 25 % enthalten, sodass niemand, der bereits die neue Version hatte, mit zunehmender Einführung zurückversetzt wurde.

In realen Systemen übernimmt normalerweise ein Service Mesh, Load Balancer oder ein Tool wie Argo Rollouts oder Flagger dieses Routing, sodass Sie es nicht selbst schreiben müssen. Es ist immer noch hilfreich zu verstehen, was sie tun.

Automatisierung der Entscheidung

Ein Kanarienvogel funktioniert nur, wenn tatsächlich jemand die Versionen vergleicht. Automatisierte Kontrollen sind zuverlässiger als die Beobachtung von Diagrammen durch eine Person. Hier ist die Kernidee, die Fehlerrate des Canary mit der der stabilen Version zu vergleichen:

def should_rollback(canary_errors, canary_total, base_errors, base_total,
                    tolerance=1.5, min_requests=500):
    if canary_total < min_requests:
        return False   # not enough data to decide
    return (canary_errors / canary_total) > (base_errors / base_total) * tolerance

should_rollback(3, 100, 10, 5000)        # False: too few requests
should_rollback(30, 1000, 100, 10000)    # True:  3% against 1%
should_rollback(12, 1000, 100, 10000)    # False: 1.2% is within tolerance

Beachten Sie den ersten Fall. Die Fehlerquote erscheint zwar hoch, reicht aber mit nur 100 Anfragen noch nicht aus. Echte Tools wenden sorgfältigere Statistiken an und betrachten mehrere Signale zusammen:

Das Datenbankproblem

Anwendungscode kann in Sekundenschnelle ausgetauscht werden, Daten jedoch nicht. Beide Strategien teilen sich in der Regel eine Datenbank, daher müssen sowohl die alte als auch die neue Version während eines Rollouts und nach einem Rollback mit demselben Schema arbeiten.

Die Standardantwort ist das Muster Expandieren und Kontrahieren. Angenommen, Sie möchten name in full_name umbenennen:

1. Erweitern: Fügen Sie die neue Spalte hinzu. Der alte Code bleibt davon unberührt.
2. Migrieren: Geben Sie Code frei, der in beide Spalten schreibt, und füllen Sie alte Zeilen auf.
3. Schalter: Freigabecode, der aus der neuen Spalte liest.
4. Vertrag: Sobald die alte Spalte nicht mehr verwendet wird, entfernen Sie sie in einer späteren Version.

Dies erfordert mehrere Releases, aber jeder Schritt kann sicher zurückgesetzt werden. Das auf einmal ausgeführte Ausführen von RENAME COLUMN würde die Version zerstören, die den anderen Namen erwartet. Seien Sie auch bei Schemaänderungen mit langer Laufzeit vorsichtig, da diese Sperren enthalten können. Weitere Informationen hierzu finden Sie unter SQL-Transaktionen.

Rollen und andere Strategien

Eine Kubernetes-Bereitstellung führt standardmäßig ein fortlaufendes Update durch, was für viele Dienste geeignet ist. Ein rollierendes Update verschiebt sich ebenfalls schrittweise, sein Anteil ist jedoch an die Anzahl der Instanzen gebunden und es werden nicht automatisch Ergebnisse analysiert oder bei schlechten Kennzahlen pausiert.

Was ist mit Feature-Flags?

Durch die Bereitstellung wird Code auf Servern abgelegt und durch die Veröffentlichung wird den Benutzern eine Funktion zur Verfügung gestellt. Feature-Flags halten diese getrennt, indem sie es Ihnen ermöglichen, eine Funktion für ausgewählte Benutzer zu aktivieren, ohne etwas bereitzustellen. Sie funktionieren mit beiden Strategien sehr gut: Bereitstellung mit ausgeschaltetem Flag und dann schrittweise Aktivierung. Sie ersetzen diese Strategien nicht, da ein Flag Sie nicht vor einem Release schützen kann, das beim Start abstürzt. Denken Sie daran, alte Flags zu entfernen, da sie sich als technische Schulden ansammeln.

So wählen Sie aus

Sie können auch kombiniert werden. Einige Teams stellen eine grüne Umgebung bereit und verlagern den Verkehr dann schrittweise dorthin, um eine saubere Umgebung und einen begrenzten Explosionsradius zu erreichen. Was auch immer Sie wählen, automatisieren Sie es über Ihre CI/CD-Pipeline, wie unser GitHub-Aktionsleitfaden erklärt.

Häufige Fehler

• Machen Sie wichtige Schemaänderungen durch. Ein Rollback hilft nicht, wenn der alte Code die Daten nicht lesen kann.
• Es gibt keine Rollback-Kriterien. Entscheiden Sie, was „schlecht“ bedeutet, bevor die Veröffentlichung beginnt, nicht während eines Vorfalls.
• Die Umgebungen treiben lassen. Wenn sich Grün von Blau unterscheidet, ergeben Ihre Tests weniger. Definieren Sie beide mit Infrastruktur als Code.
• Es werden nur technische Kennzahlen gemessen. Eine Veröffentlichung kann fehlerfrei sein und dennoch den Checkout unterbrechen.
• Üben Sie niemals Rollback. Üben Sie es, damit es funktioniert, wenn Sie unter Druck stehen.
• Hintergrundjobs vergessen. Mitarbeiter und geplante Aufgaben benötigen auch während eines Wechsels einen Plan.

Fazit

Blaugrün sorgt für einen sauberen und schnellen Wechsel. Canary bietet Ihnen eine kleine, gemessene Belichtung. Wenn Ihre Überwachung noch einfach ist, beginnen Sie mit fortlaufenden Updates oder Blue-Green und investieren Sie in Metriken pro Version, bevor Sie Canaries ausprobieren. Dann üben Sie ein Rollback für Ihr nächstes Release, einschließlich der Datenbank. Diese einzelne Übung zeigt tendenziell, was wirklich repariert werden muss.

Häufige Fragen

Lerne weiter