Rolling Deployment
Ein Rolling Deployment (rollierende Bereitstellung) ist eine Software-Release-Strategie, die die Bereitstellung über mehrere Phasen zeitlich staffelt, und in der Regel einen oder mehrere Server umfasst, die eine oder mehrere Funktionen innerhalb eines Server-Clusters ausführen. Anstatt alle Server oder Ebenen gleichzeitig zu aktualisieren, installiert das Unternehmen das aktualisierte Softwarepaket auf jeweils einem Server oder einer Teilmenge von Servern. Ein Rolling Deployment wird eingesetzt, um Ausfallzeiten von Anwendungen und unvorhergesehene Folgen oder Fehler bei Software-Updates zu reduzieren.
Bei einem herkömmlichen Software-Update wird ein Anwendungsserver für die Dauer des Updates und zugehöriger Tests aus der Produktivumgebung genommen und später wieder dorthin zurückgeführt. Das kann zu substanziellen Downtime-Zeiten für die betroffene Anwendung führen, die sich noch schwerer auswirken, wenn ein spät erkanntes Problem letztlich doch wieder zu einem Rollback auf die vorherige Version führt.
Bei einem Rolling Upgrade ist zu einem bestimmten Zeitpunkt nur ein Teil der Serverkapazität einer Anwendung offline. Nehmen wir als Beispiel eine dreistufige Anwendung, die Frontend, Backend und Datenbank umfasst und mit drei Knoten in jeder Schicht bereitgestellt wird.
Jeder der drei Knoten des Frontend-Applikationsservers empfängt den Datenverkehr über einen Load Balancer. Bei einem herkömmlichen Upgrade blockiert der Load Balancer den gesamten Anwendungsverkehr, damit die Server offline gehen und sich aktualisieren können. Bei einem Rolling Deployment kann das Unternehmen einen der Knoten in jeder Schicht offline nehmen, wobei der Load Balancer so konfiguriert ist, das er den Datenverkehr auf die verbleibenden Server umleitet, auf denen noch die geprüfte, aktuelle Softwareversion läuft. Die ungenutzten Server erhalten Updates und Tests, die restlichen Server verarbeiten den Traffic.
Die Anzahl gleichzeitiger Deployment-Ziele eines Rolling Deployments bezeichnet man als Windows Size. Eine Window Size mit dem Wert eins führt ein Deployment zur gleichen Zeit auf genau ein Ziel durch. Größere Cluster können mit größeren Window Sizes arbeiten.
Ein Rolling Deployment kann zum Beispiel eine Testphase umfassen, während derer der Load Balancer nur eingeschränkten oder spezifisch für Tests vorgesehenen Traffic weiterleitet, während die neue Software konfiguriert und getestet wird. Davon bleibt die Benutzererfahrung für alle Anwender unverändert, da diese noch auf die verbleibenden Server mit der bisherigen, noch nicht aktualisierten Softwareversion zugreifen.
Nach einem erfolgreichen Test der Software wird der aktualisierte Server wieder in die Produktivumgebung eingeführt und ein anderer Serverknoten offline genommen, um den Vorgang zu wiederholen. Das wird so lange wiederholt, bis irgendwann alle Serverknoten im Cluster aktualisiert sind und die gewünschte Softwareversion installiert ist. Die Gesamtanwendung ist während des Vorgangs des Rolling Deployments durchgängig erreichbar.
Einer der wichtigsten Aspekte bei Rolling Deployments ist die Sicherstellung der Rückwärtskompatibilität über den gesamten Stack hinweg: Einige Knoten führen im Zweifelsfall neuere Versionen aus, während andere Knoten während des Rolling Updates noch die vorherige Version einsetzen. Daher ist es wichtig sicherzustellen, dass die älteren Versionen der Web- oder Anwendungskomponenten mit dem neuen Datenbankschema kompatibel ist.
Die Persistenz der Sitzungen kann bei Rolling Deployments zum Problem werden, wenn der Datenverkehr eines Anwenders zu einem Server geleitet wird, der eine andere Version der Software ausführt. Dies kann zu unerwünschten Ergebnissen führen.
Load Balancer sollten daher die Funktion der Benutzerpersistenz unterstützen, so dass der Traffic für einen bestimmten Nutzer immer an denselben Server weitergeleitet wird. Darüber hinaus sollte nach Möglichkeit die Sitzungsfreigabe aufgerufen werden, damit die Benutzersitzung auf einem anderen Server fortgesetzt werden kann, wenn der Server, der derzeit die Benutzerpersistenz bereitstellt, für seine Aktualisierung offline genommen wird.
Rolling Deployments erfordern nicht so viel zugrunde liegende IT-Ressourcenkapazität wie ein Blue/Green Deployment, bei dem das Update auf einer gesamten Produktionsumgebung stattfindet, während eine identische Produktionsumgebung die vorherige Softwareversion für einen Benutzer ausführt.
Rolling Deployments unterscheiden sich von schrittweisen Rollouts (Phased Rollouts). Eine schrittweise Bereitstellung erfolgt über einen längeren Zeitraum und ein Benutzer ist sich bewusst, dass er sich auf verschiedenen Softwareversionen befindet, um Feedback zu erhalten oder die Leistung zu testen, bevor er eine Änderung vollständig ausführt.
