Mit einem einzigen Umschalten auf Kubernetes

ClickFortify begann auf einer einzelnen VM mit docker-compose. Heute läuft es auf Kubernetes in GCP und wird über ArgoCD deployt. In diesem Beitrag geht es um den Umzug dazwischen und darum, warum ich ihn am Ende als ein einziges Umschalten statt als schrittweise Migration umgesetzt habe.

Das Produkt kann nicht pausieren

ClickFortify erfasst Werbeklicks im Live-Traffic, bewertet sie und schreibt Ausschlüsse zurück in Google Ads und Meta. Klicks treffen rund um die Uhr ein. Ein Migrationsplan, der ein Wartungsfenster braucht oder den Tracker halb auf dem einen und halb auf dem anderen Stack lässt, kostet echte Werbetreibende echtes Budget.

Die Frage war also nicht „Wie ziehen wir alles um?“, sondern „Wie machen wir den Wechsel zu einem einzigen, kleinen, umkehrbaren Schritt?“.

Zuerst den Deploy-Pfad richtig aufsetzen

Bevor irgendein Traffic umzog, brauchte der Cluster einen Deploy-Pfad, dem ich vertraute. Das GitOps-Setup nutzt drei Repositories: die Anwendung, die Manifeste, die ArgoCD deployt, und die Plattform-Infrastruktur. Der ursprüngliche Plan sah vor, die Manifeste im Monorepo der Anwendung zu belassen. Ich habe sie ausgelagert, weil ArgoCD das Repository bei jedem Refresh neu klont und das Monorepo groß ist, weil die Plattform einen eigenen Lebenszyklus und eigene Reviewer hat und weil die CI der Anwendung dann überhaupt keinen Zugriff auf das Plattform-Repository hat.

Das ist für einen Cutover wichtig. Wird die neue Seite genau so deployt, wie sie auch künftig deployt wird, prüft man am ersten Tag mit ihr zugleich den Release-Prozess.

Ein paralleler Satz von Stage-Hostnamen

Der Plan, auf den ich mich festlegte, hatte drei Schritte:

1. Den vollständigen neuen Stack auf dem Cluster hinter einem parallelen Satz von Stage-Hostnamen deployen, etwa stage.example.com.
2. Ihn dort verifizieren.
3. Die Produktions-Hostnamen mit einem einzigen Umschalten auf den Cluster zeigen lassen.

An der Produktion änderte sich nichts, während die neue Seite getestet wurde. Die alte VM bediente weiterhin jede echte Anfrage, und die Stage-Hostnamen gaben mir einen Ort, an dem ich den neuen Stack Ende zu Ende durchspielen konnte.

Keine Datenmigration, und der Haken daran

Beide Seiten nutzten dieselben Datenbanken. Genau das machte ein einziges Umschalten möglich: Es gab keine Kopie, keine Synchronisierung, die konsistent bleiben musste, und keinen Moment, in dem sich die beiden Stacks bei den Daten uneinig waren. Als das DNS umgestellt wurde, las und schrieb der neue Stack bereits dieselben Zeilen wie der alte.

Der Haken: Die Stage-Seite war nie wirklich eine Sandbox. Alles, was sie schrieb, landete in Produktionsdaten. Für Tests gab es einen eigens dafür reservierten Bereich, und kein Skript eines echten Kunden wurde je auf den Stage-Tracker gerichtet.

Warum der Worker auf null blieb

Der Worker ist der Service, der geplante Jobs ausführt. Auf einer gemeinsamen Datenbank bedeuten zwei Worker, dass jeder geplante Job doppelt läuft: E-Mails gehen zweimal raus, Bereinigungen löschen zweimal. Deshalb blieb der Worker auf der neuen Seite während der gesamten Stage-Phase auf null Replikas.

# Illustrative: keep the new side's worker off until the flip
kubectl scale deployment worker --replicas=0

Das Umschalten und die Prüfung, ob es hält

Das Umschalten selbst war eine DNS-Änderung: Die Produktions-Hostnamen wurden auf den Cluster gerichtet. Vorher prüfte ich, ob die Image-Digests auf dem Cluster mit dem übereinstimmten, was ich ausliefern wollte.

Danach war die wichtigste Prüfung die des Trackers. Er sitzt hinter einem CDN und einem Reverse Proxy, und die echte IP des Besuchers dahinter zu ermitteln, ist genau die Art von Sache, die bricht, wenn sich die Topologie ändert. Der Live-Traffic des Trackers zeigte nach dem Umschalten echte Besucher-IPs und keine CDN-Edge-Adressen. Als das hielt, wurden die Stage-Hostnamen entfernt.

Direkt nach dem Umschalten war ein Rollback derselbe Schritt in umgekehrter Richtung: die Hostnamen zurück auf die alte VM zeigen lassen, die ich gestoppt und nicht gelöscht hatte.

Was ich jemandem raten würde, der denselben Umzug plant

1. Wenn beide Seiten die Datenbanken teilen können, tun Sie es. Das erspart die Datenmigration und macht den Cutover zu einer einzigen DNS-Änderung.
2. Listen Sie jeden geplanten Job auf und stellen Sie sicher, dass er während der Stage-Phase an genau einem Ort läuft, selbst wenn sich ein Service dadurch nicht vorab erproben lässt.
3. Leeren oder exportieren Sie Jobs in Queues und verzögerte Jobs vor dem Umschalten. Sie liegen außerhalb der Datenbank.
4. Legen Sie die Verifikationsprüfung vor dem Umschalten fest, und beziehen Sie sie auf echten Traffic, nicht auf Health-Endpunkte.