Implementieren von Canary-Releases mit Apache APISIX

Kurz gesagt besteht die Idee hinter Canary-Releases darin, nur einem Bruchteil der Benutzer eine neue Softwareversion bereitzustellen, die Ergebnisse zu analysieren und zu entscheiden, ob fortgefahren werden soll oder nicht. Wenn die Ergebnisse nicht den Erwartungen entsprechen, führen Sie einen Rollback durch. Wenn dies der Fall ist, erhöhen Sie die Anzahl der bereitgestellten Benutzer, bis alle Benutzer von der neuen Version profitieren.

In diesem Beitrag möchte ich diese Einführung kurz erläutern, verschiedene Möglichkeiten zur Definition des Bruchs erläutern und zeigen, wie man ihn mit Apache APISIX ausführt.

Einführung in kanarische Veröffentlichungen

Der Begriff „Kanarienvogel“ stammt ursprünglich aus dem Kohlebergbau. Beim Bergbau kommt es nicht selten zur Freisetzung giftiger Gase: In einem kleinen geschlossenen Raum kann das den schnellen Tod bedeuten. Schlimmer noch: Das Gas könnte geruchlos sein, so dass die Bergleute es einatmeten, bis es zu spät zum Verlassen war. Kohlenmonoxid kommt in Kohlebergwerken häufig vor und ist für den Menschen nicht wahrnehmbar.

Aus diesem Grund brachten Bergleute Kanarienvögel mit in den Untergrund. Wenn der Kanarienvogel plötzlich tot umfiel, war die Wahrscheinlichkeit groß, dass eine solche Gasblase durchbrochen worden war, und es war höchste Zeit, den Ort zu verlassen.

Vor Jahren haben wir diesen Ansatz bei der Veröffentlichung einer neuen Softwareversion umgesetzt. Die Analogie lautet wie folgt: Miner sind das Operations-Team, das die Version bereitstellt, der Canary besteht aus allen Tools, um die Auswirkungen der Freisetzung zu messen, und das Gas ist ein (kritischer) Fehler.

Der wichtigste Teil besteht darin, dass Sie die Auswirkungen der Veröffentlichung messen müssen , einschließlich Fehlerraten, HTTP-Statuscodes usw., und diese mit denen der vorherigen Version vergleichen müssen. Es liegt außerhalb des Rahmens dieses Beitrags, ist aber wiederum von entscheidender Bedeutung, wenn Sie von Canary-Releases profitieren möchten. Der zweitwichtigste Teil ist die Möglichkeit eines schnellen Rollbacks, wenn die neue Version fehlerhaft ist.

Canary-Releases vs. Feature-Flags

Beachten Sie, dass Canary-Releases nicht die einzige Möglichkeit sind, das Risiko der Veröffentlichung von neuem Code zu verwalten. Feature-Flags sind beispielsweise eine weitere beliebte Methode:

• Der Canary-Ansatz liefert den kompletten Funktionsumfang in der neuen Komponentenversion
• Feature-Flags stellen die Komponente ebenfalls bereit, aber spezielle Konfigurationsparameter ermöglichen die individuelle Aktivierung und Deaktivierung jeder Funktion

Feature Flags stellen einen agileren Ansatz (im wahrsten Sinne des Wortes) für Rollbacks dar. Wenn eine von zehn Funktionen fehlerhaft ist, müssen Sie die Bereitstellung der neuen Version nicht aufheben; Sie deaktivieren lediglich die Buggy-Funktion. Diese Superkraft geht jedoch mit einer zusätzlichen Komplexität der Codebasis einher, unabhängig davon, ob Sie auf Produkte von Drittanbietern zurückgreifen oder sie selbst implementieren.

Andererseits erfordert Canary eine ausgereifte Bereitstellungspipeline, um die Bereitstellung und Bereitstellung nach Belieben rückgängig machen zu können.

Ansätze für kanarische Freilassungen

Die Idee hinter Canary-Releases besteht darin, nur einem Bruchteil der Benutzer den Zugriff auf die neue Version zu ermöglichen. Die meisten Canary-Definitionen definieren „Bruch“ nur als Prozentsatz der Benutzer. Es steckt jedoch noch mehr dahinter.

Der erste Schritt könnte darin bestehen, nur geprüften Benutzern die Möglichkeit zu geben, zu überprüfen, ob die Bereitstellung in der Produktionsumgebung wie erwartet funktioniert. In diesem Fall können Sie nur eine bestimmte Gruppe interner Benutzer, z. B. Tester, auf die neue Version weiterleiten. Wenn Sie die Personen im Voraus kennen und das System Benutzer authentifiziert, können Sie es nach Identität konfigurieren; Wenn nicht, müssen Sie auf eine generische Methode zurückgreifen, z. B. HTTP-Header – X-Canary: Let-Me-Go-To-v2 .

Denken Sie daran, dass wir die alten und neuen Systeme überwachen müssen, um Diskrepanzen festzustellen. Wenn nichts angezeigt wird, ist es ein guter Zeitpunkt, den Kreis der Benutzer zu vergrößern, die auf die neue Version weitergeleitet werden. Ich gehe davon aus, dass Sie Ihr eigenes Hundefutter essen, d . h. Teammitglieder verwenden die Software, die sie entwickeln. Wenn Sie beispielsweise keine E-Commerce-Seite für Luxusautos haben, können Sie diesen Abschnitt gerne überspringen.

Um den Anteil der Benutzer zu vergrößern und gleichzeitig die Risiken zu begrenzen, können wir die neue Version jetzt uneingeschränkt internen Benutzern zur Verfügung stellen. Zu diesem Zweck können wir das System so konfigurieren, dass es basierend auf der Client-IP an die neue Version weiterleitet. Zu einer Zeit, als die Leute vor Ort arbeiteten, war das einfach, da ihre IPs in einem bestimmten Bereich lagen. Remote ändert sich nicht viel, da Benutzer wahrscheinlich über ein VPN auf das Netzwerk des Unternehmens zugreifen.

Beobachten und vergleichen Sie auch an dieser Stelle.

Die ganzen neun Yards

Zu diesem Zeitpunkt sollte für einige oder alle internen Benutzer alles wie erwartet funktionieren. Doch so wie kein Plan den Kontakt mit dem Feind übersteht, kann auch keine Anwendung die ganze Vielfalt einer Produktionsarbeitslast nachbilden. Kurz gesagt, wir müssen regulären Benutzern den Zugriff auf die neue Version ermöglichen, aber auf kontrollierte Weise, so wie wir bisher die Anzahl der Benutzer schrittweise erhöht haben: Beginnen Sie mit einem kleinen Bruchteil, überwachen Sie ihn und wenn alles in Ordnung ist, erhöhen Sie den Bruchteil .

Hier erfahren Sie, wie es mit Apache APISIX geht. Apache APISIX bietet eine Plugin-basierte Architektur und stellt ein Plugin bereit, das unseren Anforderungen entspricht, nämlich das traffic-split Plugin.

Das traffic-split Plugin kann verwendet werden, um Teile des Datenverkehrs dynamisch an verschiedene Upstream-Dienste weiterzuleiten.

Dies erfolgt durch die Konfiguration von match , bei denen es sich um benutzerdefinierte Regeln zur Aufteilung des Datenverkehrs handelt, und weighted_upstreams , bei dem es sich um eine Reihe von Upstreams handelt, an die der Datenverkehr weitergeleitet werden soll.

- Verkehrsaufteilung

Beginnen wir mit einigen grundlegenden Upstreams, einem für jede Version:

 upstreams: - id: v1 nodes: "v1:8080": 1 - id: v2 nodes: "v2:8080": 1

Wir können das traffic-split Plugin verwenden, um den größten Teil des Datenverkehrs an v1 und einen Bruchteil an v2 weiterzuleiten:

 routes: - id: 1 uri: "*" #1 upstream_id: v1 plugins: traffic-split: rules: - weighted_upstreams: #2 - upstream_id: v2 #3 weight: 1 #3 - weight: 99 #3

1. Definieren Sie eine Catch-All-Route
2. Konfigurieren Sie, wie der Datenverkehr aufgeteilt wird. hier, Gewichte
3. Leiten Sie 99 % des Datenverkehrs an v1 und 1 % an v1 weiter. Beachten Sie, dass die Gewichte relativ zueinander sind. Um 50/50 zu erreichen, können Sie die Gewichtungen 1 und 1, 3 und 3, 50 und 50 usw. festlegen.

Auch hier überwachen wir alles und stellen sicher, dass die Ergebnisse den Erwartungen entsprechen. Dann können wir den Anteil des an v2 weitergeleiteten Datenverkehrs erhöhen, z. B .:

 routes: - id: 1 uri: "*" upstream_id: v1 plugins: traffic-split: rules: - weighted_upstreams: - upstream_id: v2 weight: 5 #1 - weight: 95 #1

1. Erhöhen Sie den Traffic zu v2 auf 5 %

Beachten Sie, dass Apache APISIX jede Sekunde Änderungen an der obigen Datei neu lädt. Daher teilen Sie den Datenverkehr nahezu in Echtzeit auf. Alternativ können Sie die Admin-API verwenden, um dasselbe zu erreichen.

Kontrolliertere Freisetzungen

Oben bin ich von internen Benutzern zu einem Bruchteil externer Benutzer übergegangen. Möglicherweise stellt die Freigabe für jeden internen Benutzer in Ihrem Unternehmen ein zu großes Risiko dar und Sie benötigen noch mehr Kontrolle. Beachten Sie, dass Sie in diesem Fall das traffic-split Plugin weiter konfigurieren können.

 routes: - id: 1 uri: /* upstream_id: v1 plugins: traffic-split: rules: - match: - vars: [["http_X-Canary","~=","Let-Me-Go-To-v2"]] #1 - weighted_upstreams: - upstream_id: v2 weight: 5 - weight: 95

1. Teilen Sie den Datenverkehr nur auf, wenn der X-Canary HTTP-Header den konfigurierten Wert hat.

Der folgende Befehl leitet immer an v1 weiter:

 curl http://localhost:9080

Der folgende Befehl leitet auch immer zu v1 weiter:

 curl -H 'X-Canary: Let-Me-Go-To-v1' http://localhost:9080

Der folgende Befehl teilt den Datenverkehr entsprechend den konfigurierten Gewichtungen auf, d . h. 95/5:

 curl -H 'X-Canary: Let-Me-Go-To-v2' http://localhost:9080

Abschluss

In diesem Beitrag werden Canary-Releases erläutert und wie Sie diese über Apache APISIX konfigurieren können. Sie können mit mehreren Routen mit unterschiedlichen Prioritäten beginnen und mit dem traffic-split Plugin fortfahren. Letzteres kann sogar weiter konfiguriert werden, um komplexere Anwendungsfälle zu ermöglichen.

Den vollständigen Quellcode für diesen Beitrag finden Sie auf GitHub .

Um weiter zu gehen:

• Implementierung einer Canary-Release-Lösung basierend auf Apache APISIX
• Canary-Release in Kubernetes mit Apache APISIX Ingress
• Reibungslose Canary-Veröffentlichung mit APISIX Ingress Controller mit Flagger