Canary-Releases mit Actions

Stellen Sie sich vor, Sie führen eine neue Funktion oder Aktualisierung ein. Was wäre, wenn sie einen Fehler enthält, der alle Ihre Benutzer betrifft? Beunruhigend, oder?

Canary-Releases helfen, dieses Risiko zu verringern, indem Änderungen zunächst schrittweise für eine kleine Benutzergruppe ausgerollt werden. Es ist so, als würde man einen „Kanarienvogel im Bergwerk“ vorausschicken, um die Luft zu prüfen, bevor alle anderen eintreten.

Canary-Releases bieten mehrere wichtige Vorteile:

• Geringeres Risiko: Begrenzen Sie die Auswirkungen von Problemen auf eine kleine Benutzergruppe.
• Feedback aus der Praxis: Erhalten Sie Produktionsdaten zu Leistung und Stabilität.
• Schnelles Rollback: Wenn Probleme auftreten, können Sie entweder nur die kleine Canary-Gruppe oder den gesamten Dienst schnell zurücksetzen.
• Kontrollierte Einführung: Erhöhen Sie die Reichweite für Benutzer schrittweise, sobald das Vertrauen wächst.

Vielleicht erinnern Sie sich an Blue/Green-Bereitstellungen, bei denen der Datenverkehr sofort zwischen zwei identischen Umgebungen umgeschaltet wird.

Canary-Releases funktionieren anders. Statt einer sofortigen Umschaltung beinhalten sie eine schrittweise Verlagerung des Datenverkehrs. Eine neue Version läuft neben der alten, und zunächst sieht nur ein kleiner Prozentsatz der Benutzer die neue Version. So ist eine detaillierte Überwachung vor dem vollständigen Rollout möglich.

Hier sehen Sie den grundlegenden Ablauf eines Canary-Releases:

1. Neue Version bereitstellen: Eine neue Version Ihrer Anwendung wird neben der vorhandenen stabilen Version auf einer kleinen Gruppe von Servern oder Instanzen bereitgestellt.
2. Geringen Datenverkehr weiterleiten: Ein Load Balancer oder ein Service Mesh wird so konfiguriert, dass ein kleiner Prozentsatz (z. B. 5–10 %) des Benutzerverkehrs an die neue Version gesendet wird.
3. Überwachen: Leistung, Fehlerraten und Benutzerfeedback werden für die Canary-Gruppe genau überwacht.
4. Hochstufen oder zurücksetzen: Wenn alles gut aussieht, wird der Datenverkehr schrittweise erhöht oder die neue Version auf 100 % hochgestuft. Treten Probleme auf, wird das Canary-Rollout zurückgesetzt und der Datenverkehr wieder an die stabile Version geleitet.

GitHub Actions kann den gesamten Prozess eines Canary-Releases orchestrieren. Der Datenverkehr wird dabei nicht direkt verwaltet (das ist Aufgabe Ihrer Infrastruktur), aber die einzelnen Schritte werden ausgelöst:

• Erstellen und Testen Ihrer Anwendung.
• Bereitstellen der neuen Version in einer Canary-Umgebung.
• Einleiten der Datenverkehrsverschiebung über API-Aufrufe an Ihren Load-Balancer oder Service Mesh.
• Warten auf Überwachungsergebnisse oder manuelle Genehmigungen.
• Hochstufen des Canarys oder Auslösen eines Rollbacks.

Ein typischer GitHub-Actions-Workflow für ein Canary-Release könnte folgendermaßen aussehen:

name: Canary Deployment

on: push

jobs:
  build:
    # ... build and test steps ...

  deploy-canary:
    needs: build
    steps:
      - name: Deploy to Canary Group
        # ... call script/tool to deploy and shift 10% traffic ...

  monitor-canary:
    needs: deploy-canary
    # ... wait for monitoring/approval ...

  promote-or-rollback:
    needs: monitor-canary
    # ... conditionally promote to 100% or rollback ...

Jeder Schritt würde mit Ihren Deployment-Tools interagieren.

Während GitHub Actions die Abläufe orchestriert, finden die eigentliche Entscheidungsfindung und die Deployment-Befehle häufig in Skripten statt. Hier sehen Sie ein Python-Beispiel, das die Logik eines Canary-Rollouts simuliert. Stellen Sie sich vor, dass eine Action dieses Skript ausführt:

Eine effektive Überwachung ist entscheidend. Ihr GitHub-Actions-Workflow kann auf verschiedene Weise in Überwachungssysteme integriert werden:

• API-Aufrufe: Fragen Sie Überwachungstools (z. B. Datadog oder Prometheus) nach wichtigen Metriken ab.
• Health-Checks: Rufen Sie regelmäßig die Health-Endpunkte der Anwendung ab.
• Manuelle Freigaben: Halten Sie den Workflow für eine Prüfung und Genehmigung durch eine Person an.
• Zeitbasierte Wartezeiten: Warten Sie einen festgelegten Zeitraum, damit sich die Metriken stabilisieren können.

Der Workflow verwendet diese Signale anschließend, um zu entscheiden, ob der Canary hochgestuft oder ein Rollback durchgeführt werden soll.

Nach der Überwachungsphase verwendet GitHub Actions eine bedingte Logik, um den nächsten Schritt zu bestimmen. In Ihren Job- oder Schrittdefinitionen können Sie if-Anweisungen verwenden.

  promote-or-rollback:
    needs: monitor-canary
    if: success() && needs.monitor-canary.outputs.canary_ok == 'true'
    steps:
      - name: Promote Full Rollout
        # ... command to shift 100% traffic to new version ...

  rollback:
    needs: monitor-canary
    if: failure() || needs.monitor-canary.outputs.canary_ok == 'false'
    steps:
      - name: Rollback to Stable
        # ... command to shift 100% traffic to old version ...

So wird automatisch auf die Leistung des Canarys reagiert.

Sie haben die Vorteile und die Funktionsweise von Canary-Releases kennengelernt. Testen wir nun Ihr Verständnis.

In dieser Lektion haben Sie Canary-Releases kennengelernt – eine leistungsfähige Deployment-Strategie, bei der neue Softwareversionen schrittweise für eine Teilmenge der Benutzer bereitgestellt werden.

• Canary-Releases minimieren Risiken und liefern Feedback aus dem tatsächlichen Betrieb.
• GitHub Actions orchestriert das Erstellen, das Deployment auf den Canary, die Überwachung sowie die bedingte Hochstufung bzw. das Rollback.
• Eine effektive Überwachung und bedingte Logik sind entscheidend für erfolgreiche Canary-Pipelines.

Mit Canarys können Sie Deployments mit größerem Vertrauen und mehr Kontrolle durchführen!