Zero Downtime Deployments mit Blue/Green - machbar ohne Cloud?

Happy1987

Mitglied
Beiträge
14
Lösungen
1
Likes
40
Punkte
13
Fachgebiete
PHP, Laravel, Shopify
Hallo zusammen,

ich überlege gerade, ob wir Zero Downtime Deployments mit einer Blue/Green-Strategie auf unserer selbstverwalteten Infrastruktur hinbekommen. Wir sind ein kleiner Mittelständler und hosten unsere Server selbst, also nix mit AWS oder Azure.

Ich habe mir schon einiges dazu angelesen, aber meistens wird von großen Cloud-Anbietern ausgegangen. Meine Frage: Hat jemand von euch sowas schon mal ohne die großen Cloud-Dienste umgesetzt?

Mir geht es vor allem darum, wie ihr den Traffic-Wechsel zwischen den beiden Umgebungen handhabt. Gibt es da clevere Tricks, ohne gleich auf teure Load Balancer zu setzen? Und wie sieht's mit der Datenbank aus - habt ihr da erfahrungsgemäß Probleme beim Umschalten oder läuft das bei euch reibungslos?

Freue mich auf eure pragmatischen Tipps. :)

Viele Grüße,
Happy1987
 
Beste Antwort
Hallo,

selber umgesetzt habe ich so ein Setup bisher nicht, muss ich zugeben. Aber in der Theorie sollte das auch ohne Cloud-Anbieter gut machbar sein.

Was du brauchst, sind zwei getrennte Deployments auf dem Server. Der Webserver zeigt dabei natürlich immer nur auf eines von beiden. Der Wechsel erfolgt dann einfach durch Anpassung der Config und Reload (kann auch automatisiert erfolgen). Alternativ (und so würde ich es wohl auch machen): auf dem Server selbst ein Symlink, der auf eine der Versionen zeigt. Das lässt sich schnell ändern, auch im Falle eines Rollbacks. Die Server-Config selbst muss dafür gar nicht angefasst werden.

Was die Datenbank betrifft: Ich würde keine zweite Instanz verwenden, sondern beide Versionen auf...
Hallo,

selber umgesetzt habe ich so ein Setup bisher nicht, muss ich zugeben. Aber in der Theorie sollte das auch ohne Cloud-Anbieter gut machbar sein.

Was du brauchst, sind zwei getrennte Deployments auf dem Server. Der Webserver zeigt dabei natürlich immer nur auf eines von beiden. Der Wechsel erfolgt dann einfach durch Anpassung der Config und Reload (kann auch automatisiert erfolgen). Alternativ (und so würde ich es wohl auch machen): auf dem Server selbst ein Symlink, der auf eine der Versionen zeigt. Das lässt sich schnell ändern, auch im Falle eines Rollbacks. Die Server-Config selbst muss dafür gar nicht angefasst werden.

Was die Datenbank betrifft: Ich würde keine zweite Instanz verwenden, sondern beide Versionen auf dieselbe DB zugreifen lassen. Das vereinfacht die Infrastruktur deutlich und vermeidet Synchronisationsprobleme. Wichtig ist dabei nur, dass alle Änderungen abwärtskompatibel sind - also z. B. neue Spalten hinzufügen, aber nichts entfernen oder umbenennen, solange die alte Version noch aktiv ist. So bleibt die Datenbank durchgängig nutzbar, und ein Rollback ist jederzeit möglich.

Wenn du Containerisierung nutzt kannst du auch beide Varianten einfach als eigenständige Container laufen lassen. Dann musst du hier nur den Container switchen, das geht deutlich einfacher und ist noch etwas robuster.
 
Zero Downtime Deployments mit einer Blue/Green-Strategie auf eigener Infrastruktur sind durchaus machbar, auch ohne auf die großen Cloud-Anbieter zurückzugreifen. Der Schlüssel liegt in der sorgfältigen Planung und Implementierung der notwendigen Netzwerk- und Serverkonfigurationen.

Für den Traffic-Wechsel zwischen den beiden Umgebungen gibt es verschiedene Ansätze. Ein gängiger Weg ist die Nutzung von DNS-Switching, wobei die TTL (Time to Live) der DNS-Einträge sehr niedrig gesetzt wird, um einen schnellen Wechsel zu ermöglichen. Allerdings kann dies bei einigen DNS-Resolvern zu Verzögerungen führen, da nicht alle die TTL-Einstellungen respektieren.

Ein anderer Ansatz ist die Verwendung eines Reverse Proxy Servers, wie Nginx oder HAProxy, der den Traffic an die entsprechende Umgebung weiterleitet. Diese Tools sind flexibel und können auf eigener Hardware oder virtuellen Maschinen betrieben werden, was die Notwendigkeit teurer Load Balancer umgeht. Man kann damit auch Rollbacks direkt steuern, falls in der neuen Umgebung Probleme auftreten.

Das Umschalten der Datenbank ist oft die größere Herausforderung. Eine Möglichkeit ist, beide Umgebungen auf dieselbe Datenbank zugreifen zu lassen, was jedoch bei Datenbankänderungen oder -migrationen problematisch werden kann. Hier hilft es oft, Änderungen über Feature Toggles zu steuern oder Datenbankmigrationen in mehreren Schritten durchzuführen, um die Kompatibilität zwischen den Versionen zu gewährleisten.

Ein praktischer Tipp: Testläufe und Staging-Umgebungen sind unerlässlich, um mögliche Probleme frühzeitig zu erkennen. Im Produktionsumfeld kann man dann mit schrittweisen Umschaltungen (z.B. nur einen Teil des Traffics zuerst umleiten) das Risiko weiter minimieren.

Insgesamt ist es eine Herausforderung, aber mit sorgfältiger Planung und den richtigen Tools durchaus zu meistern.

Viel Erfolg
 
Oh, das Thema hatten wir mal in einem früheren Projekt. Klingt erstmal ganz einfach, ist es aber nicht wirklich, wenn mans sauber machen will.

Wir haben das damals mit Nginx gemacht – ziemlich basic: Zwei Umgebungen, und wir haben manuell umgeschaltet, sobald alle Checks durch waren. War nicht hyperautomatisiert, aber hat funktioniert. Was aus UX-Sicht superwichtig war: keine Hänger oder leeren Seiten beim Umschalten. Da hilft es echt, irgendwas Kurzes einzublenden à la "Seite wird aktualisiert“ – nicht schön, aber besser als plötzlich weiß.
 
Zurück
Oben