Inkrementelle Bereitstellungen vs. vollständige Neubereitstellungen

Vor vier Wochen schrieb mein Kollege Robert van Loghem darüber, was der volle Umfang einer Bereitstellung in einer Java-Unternehmensumgebung ist. Das Szenario, das Robert vorstellte, umfasste die Konfiguration von Datenbanken, Webservern, Firewalls und Java EE-Ressourcen. Sie alle sind genauso wichtig, um Ihre Anwendung zum Laufen zu bringen, wie die Bereitstellung einer EAR-Datei.

Aber obwohl Roberts Verfahren komplizierter war als die einfache Installation einer EAR-Datei, wurde ein noch häufigeres Szenario nicht behandelt: das Upgrade einer Anwendung auf eine neue Version. Die Erstinstallation einer Anwendung ist zwar wichtig, aber ich denke, dass Upgrades aus einer Reihe von Gründen noch interessanter sind:

• Der offensichtlichste Grund ist, dass Upgrades einfach häufiger vorkommen als Erstinstallationen.
• Upgrades (in der Produktion) finden statt, wenn die Benutzer die Anwendung bereits nutzen. Die Anwendung sollte also während der Bereitstellung zugänglich bleiben.
• Wenn das Upgrade fehlschlägt, sollte die alte Version der Anwendung noch vorhanden sein.
• Und schließlich, aber das ist ein eher auf die Menschen bezogener Aspekt, können Upgrades schwierig sein, weil sich der Fokus auf die Anwendung im Laufe der Zeit verschoben haben kann. Wenn die Anwendung zum ersten Mal bereitgestellt wird, sind alle sehr aufmerksam: die Entwickler, die Middleware-Administratoren, die Architekten, die Projektmanager, die Endbenutzer usw. Wenn also ein Problem auftaucht, wird es in der Regel recht schnell behoben. Aber wenn die Version 2.1.54 auftaucht und ein Administrator gebeten wird, sie an einem Freitagnachmittag zu installieren, dann können die Dinge furchtbar schief gehen und das Wochenende des armen Administrators ruinieren. Wenn Sie auf die Komplexität von Anwendungsupgrades achten, können Sie dies abmildern.

Da das Upgrade-Szenario das wichtigste Einsatzszenario ist, wird es häufig angesprochen, wenn wir mit Kunden über Deployit, unser Produkt zur Einsatzautomatisierung, sprechen.

Kehren wir zum Szenario von Robert zurück. Die Anwendung, die in diesem Szenario bereitgestellt wurde, bestand aus einer EAR-Datei, einigen statischen Inhalten (HTML-Dateien, Bilder usw.) und einer Reihe von SQL-DDL-Skripten. Wie also sollten wir diese Anwendung auf die nächste Version, sagen wir v1.1, aktualisieren? Der Einfachheit halber nehmen wir an, dass sich das Datenbankschema zwischen v1.0 und v1.1 nicht geändert hat. Entweder wir machen die gesamte Bereitstellung von v1.0 rückgängig und führen eine saubere Bereitstellung von v1.0 durch, was wir gerne als vollständiges Redeployment bezeichnen, oder wir führen das Upgrade mit minimalem Aufwand durch, also eine inkrementelle Bereitstellung.

Szenario der schrittweisen Einführung

Eine schrittweise Bereitstellung würde folgendermaßen aussehen:

1. Entfernen Sie statische Inhalte für v1.0 vom Webserver.
2. Stoppen Sie v1.0 der EAR-Datei.
3. Heben Sie die Bereitstellung von v1.0 der EAR-Datei auf.
4. Stellen Sie v1.1 der EAR-Datei bereit.
5. Starten Sie v1.1 der EAR-Datei.
6. Kopieren Sie statische Inhalte für v1.1 auf den Webserver.

Szenario der vollständigen Umschichtung

Und eine vollständige Umschichtung würde folgendermaßen aussehen:

1. Stoppen Sie den Webserver.
2. Entfernen Sie statische Inhalte für v1.0 vom Webserver.
3. Entfernen Sie die Webserver-Konfiguration für v1.0.
4. Stoppen Sie den Anwendungsserver.
5. Heben Sie die Bereitstellung von v1.0 der EAR-Datei auf.
6. Zerstören Sie die für v1.0 erforderliche Konfiguration des Anwendungsservers: Datenquelle, Warteschlangen, Serverdefinitionen usw.
7. Erstellen Sie die für v1.1 erforderliche Konfiguration des Anwendungsservers: Datenquelle, Warteschlangen, Serverdefinitionen usw.
8. Stellen Sie v1.1 der EAR-Datei bereit.
9. Starten Sie den Anwendungsserver.
10. Erstellen Sie die Webserver-Konfiguration für v1.1.
11. Kopieren Sie statische Inhalte für v1.1 auf den Webserver.
12. Starten Sie den Webserver.

Wenn Sie diese beiden Szenarien vergleichen, werden Sie eine Reihe von Unterschieden feststellen:

• Der Webserver wird zu Beginn des Szenarios gestoppt und erst im allerletzten Schritt gestartet (Schritt 1 bzw. 12).
• Die Webserver-Konfiguration wird entfernt und neu erstellt (Schritt 3 bzw. 10).
• Anstatt nur die EAR-Datei zu stoppen und dann zu starten, wird der gesamte Anwendungsserver gestoppt und dann gestartet (Schritt 4 bzw. 9).
• Die Konfiguration des Anwendungsservers wird entfernt und neu erstellt (Schritt 6 bzw. 7).

Indem wir die Konfiguration des Webservers und des Anwendungsservers in diesem Einsatzszenario entfernen und dann neu erstellen, wissen wir genau, wie die Ergebnisse aussehen werden. Alle Änderungen an der Konfiguration, die nicht im Einsatzszenario dokumentiert sind, werden entfernt und nicht wiederhergestellt. Um dies zu ermöglichen, müssen wir den Webserver und den Anwendungsserver anhalten und sie gegen Ende des Szenarios wieder starten. Dies könnte sich negativ auf die Verfügbarkeit Ihrer Anwendung auswirken, aber Sie wissen ja, dass Sie sowieso einen Cluster einrichten müssen, um Ihre Anwendung hochverfügbar zu machen, nicht wahr? ;-)

Interessant an dem Szenario der vollständigen Neuverteilung ist auch, dass die Schritte 7 bis 12 genau wie das ursprüngliche Verteilungsszenario für diese Anwendung aussehen. Das Einzige, was fehlt, sind die Schritte, die zum Erstellen des Datenbankschemas erforderlich sind. Da die Datenbank ihren Zustand beibehält, ist es nicht möglich, das Schema zu löschen und neu zu erstellen. Und wenn wir uns das vollständige Redeployment-Szenario genauer ansehen, stellen wir fest, dass die Schritte 1 bis 6 erforderlich sind, um die Anwendung endgültig zurückzusetzen. Lassen Sie uns die Vor- und Nachteile der beiden Szenarien zusammenfassen:

Vor- und Nachteile der schrittweisen Bereitstellung

• Pro: Inkrementelle Bereitstellungen werden sehr schnell ausgeführt, da sie den geringsten Arbeitsaufwand verursachen.
• Nachteil: Bei der inkrementellen Bereitstellung bleiben alle manuell vorgenommenen Änderungen intakt. Das ist schlecht, denn es bedeutet, dass magische, wahrscheinlich nicht dokumentierte, Konfigurationsänderungen notwendig sind, damit die Anwendung funktioniert. Wenn Sie auf eine neue Hardware migrieren müssten, würden Sie diese Option wieder vergessen. Und wenn die Änderung an einem der bereitstellbaren Artefakte vorgenommen wurde, nun... muss ich das wirklich erklären? ;-)
• Pro: Inkrementelle Implementierungen berühren keine Systeme, die bereits in Ordnung sind. Wenn Sie jedoch Angst haben, Ihre Systeme anzurühren, weil Sie befürchten, dass sie sonst kaputt gehen könnten, haben Sie noch viel zu tun. Sie müssen in der Lage sein, Ihrer Middleware-Umgebung so weit zu vertrauen, dass Sie jede Änderung vornehmen und jeden Server neu starten können, ohne Angst haben zu müssen, dass er nicht wieder hochfährt.
• Nachteil: Inkrementelle Verteilungen sind schwer rückgängig zu machen. Sie müssen für jede inkrementelle Bereitstellung ein separates Rückgängigmachungsszenario definieren, da Sie die vorherige Bereitstellung nicht einfach wiederherstellen können, da diese ebenfalls inkrementell ist. Die einzige Möglichkeit, zu v1.3 zurückzukehren, ist die saubere Bereitstellung von v1.0 und die anschließende Anwendung der inkrementellen Bereitstellungen für v1.1, v1.2 und v1.3.

Vor- und Nachteile von vollständigen Umschichtungen

• Pro: Vollständige Neuinstallationen löschen alle manuellen Änderungen, so dass nur die dokumentierten Konfigurationen bestehen bleiben.
• Pro: Vollständige Neuimplementierungen sind wiederholbar und vorhersehbar. Da das Verfahren immer dasselbe ist, unabhängig davon, welcher Teil der verteilbaren Artefakte sich geändert hat, und unabhängig vom aktuellen Zustand der Zielumgebung, wird es immer zu denselben Ergebnissen führen.
• Pro: Vollständiges Redeployment ermöglicht eine sehr einfache Rückgängig-Strategie. Wenn die Bereitstellung einer neuen Version Ihrer Anwendung fehlschlägt oder die neue Version einfach nicht funktioniert, stellen Sie die Bereitstellung der vorherigen Version einfach wieder her.
• Nachteil: Vollständige Neuinstallationen funktionieren nicht bei Systemen, die einen Status haben, wie z.B. eine Datenbank. Diese Systeme müssen intakt bleiben.
• Nachteil: Es ist schwieriger, die Anwendung bei einer vollständigen Neuverteilung verfügbar zu halten als bei einer inkrementellen Verteilung. Andererseits müssen Sie, wie bereits erwähnt, für eine wirklich hochverfügbare Anwendung ohnehin Cluster einrichten.
• Nachteil: Vollständige Neuverteilungen können langsam ausgeführt werden, wenn die Ziel-Middleware nicht sehr schnell ist, da eine große Anzahl von Middleware-Konfigurationsaktionen durchgeführt werden muss.

Fazit

Auch wenn es manchmal schwierig sein kann, eine vollständige Neuverteilung zum Laufen zu bringen, ist die Tatsache, dass sie wiederholbar und vorhersehbar ist, ein so großer Vorteil, dass er meiner Meinung nach die Nachteile bei weitem überwiegt. Inkrementelle Bereitstellungen mögen wie ein schlanker und gemeiner Ansatz für die Bereitstellung von Upgrades erscheinen, aber in Wirklichkeit opfern Sie das, was für ein Bereitstellungsszenario wesentlich ist: dass es sich um einen wiederholbaren, vorhersehbaren und unumkehrbaren Prozess handelt. Nur wenn der Status beibehalten wird (wir sprechen hier von Datenbanken), sind inkrementelle Implementierungen wirklich notwendig. In allen anderen Fällen empfehle ich, für Upgrades ein vollständiges Redeployment-Szenario zu implementieren.