Technische Dinge für Nicht-Technische Leute (Teil 3)

Was ist überhaupt ein Deployment?

Ein Deployment ist nichts anderes als ein automatisierter Prozess zur Installation und Konfiguration von Software auf Servern oder PCs. Möglicherweise könnt ihr euch noch an die Zeiten erinnern, als große Monolithen in Downtimes von mehr als zehn Stunden in Betrieb genommen wurden. Der gesamte Prozess war wirklich teuer und fehleranfällig. Bei heutigen Online-Dienstleistern wie Uber, AirBnB oder auch bei Streaming-Diensten wie Netflix sind solche Downtimes einfach undenkbar. Auch für Anwendungen im B2B-Bereich gehören Downtimes zum alten Eisen. Das Online Deployment ist kein Hexenwerk, aber es hat einige technische Abhängigkeiten, die ihr für eine erfolgreiche Anwendung unbedingt beachten solltet.

Wenn ihr eine neue Anwendung deployen oder eine neue Version einer bereits bestehenden Anwendung in Betrieb nehmen möchtet, müsst ihr die neue Anwendung auf den Server bringen und eventuell die Einstellungen des Betriebssystems oder der virtuellen Maschine anpassen.

Knoten und Cluster

Ein einzelner Server ist allerdings nicht genug. Ihr braucht mehrere sogenannter Knoten in einem Cluster. Diese Knoten dienen als eine Art Rückversicherung, denn wenn ein Knoten eines Clusters ausfällt, kann ein anderer Knoten die Aufgaben ausführen. Die Übernahme wird über eine Cluster-Software und die Last auf den Knoten über einen Loadbalancer – er gleicht die Last entsprechend aus – gesteuert. Wie ihr euch denken könnt, ist euer Server nicht allein, denn zu einer Anwendung gehört auch eine Datenbank. Und auch diese muss an die neue Version angepasst werden.

Früher gab es eine bestimmte Abfolge von Aufgaben während einer Downtime:

• Schließen des Loadbalancer
• Setzen eines Rollback-Punkts für die Datenbank
• Stoppen der Anwendungsserver
• Anpassung der Datenbankversion
• Neustart der Datenbank
• Anpassung der Anwendung
• Anpassung der Serversettings
• Neustart des Anwendungsservers
• Testen der neuen Anwendung
• Öffnung des Loadbalancer

Wie ihr seht, gab es während der Inbetriebnahme eines Monolithen viel zu tun. Ihr könnt euch nun hoffentlich vorstellen, wieso eine Downtime früher extrem viel Zeit in Anspruch genommen hat.

Wie kann Online Deployment die Welt besser machen?

In einem Online-Deployment-Szenario könnt ihr die Funktionalität eines Loadbalancer nutzen, um einzelne Server vom Außenzugriff - beispielsweise einzelne Knoten, die nicht für den Nutzer erreichbar sind - auszuschließen.

So würde der Prozess für einen einzelnen Knoten aussehen:

• Setzen eines Rollback-Punkts für die Datenbank
• Anpassung der Datenbank
• Entfernen eines Knoten aus dem Loadbalancing
• Anpassung der Anwendung
• Anpassung der Serversettings
• Testen der Applikation
• Erneutes Einbinden des Knoten in das Loadbalancing

Ein solches Vorgehen wird Canary-Deployment genannt, das in der folgenden Abbildung illustriert wird.

Wie ihr seht, wird der blaue Knoten aus dem Loadbalancing verwendet, entsprechend angepasst, um anschließend wieder zurück ins Loadbalancing eingebunden zu werden. Die mittelgrünen Knoten befinden sich innerhalb des Loadbalancing, während die dunkelgrünen Knoten die früheren Versionen kennzeichnen.

Die hellgrün gekennzeichneten Knoten symbolisieren in der Beispielgrafik die neuen Versionen. Beide Versionen – dunkelgrün und hellgrün - sind durch den Nutzer parallel aufrufbar und arbeiten auf der gleichen Datenbank. Das bedeutet, dass die Datenbank als erstes angepasst werden muss, was aber in der Regel problemlos möglich ist. Natürlich könnt ihr bei diesem Vorgehen auch zwei Datenbanken bedienen. Angesichts von Lizenz- und Speicherkosten ist ein solches Vorgehen aber kostenaufwändiger.

Diese Methode hat allerdings auch einige Nachteile:

• Es muss immer ein Knoten aus dem Loadbalancing genommen werden und somit ist dieser nicht mehr für den Nutzer verfügbar. Dieser Nachteil kann jedoch durch einen zusätzlichen Knoten, der nicht immer im Loadbalancing ist, umgangen werden.
• Tests werden immer nur auf einem Knoten durchgeführt. Probleme bei der Synchronisation der einzelnen Knoten werden dementsprechend nicht erkannt.
• Tauchen schwerwiegende Fehler in der neuen Version auf, ist ein Rollback schwierig. Hier müsstet ihr die komplette Prozedur für jeden Knoten wiederholen.

Das Canary-Deployment ist aber nicht die einzige Methode, die ihr nutzen könnt, denn mit dem Grün-Blau-Ansatz gibt es auch noch ein weiteres Model.

Wie ihr in der oberen Abbildung erkennen können, braucht der Grün-Blau-Ansatz eine doppelte Infrastruktur. Zu erkennen ist eine grüne und eine blaue Linie mit jeweils drei Knoten. Die grüne Linie ist durch den Nutzer erreichbar, die blaue Linie hingegen nicht. Der Anpassungsmechanismus spielt die neue Version auf der blauen Linie ein und anschließend sind sowohl die grüne als auch die blaue Linie für den Nutzer erreichbar. Auf dem Loadbalancer ist eine Regel definiert, wonach Nutzer, die sich neu anmelden nur auf der neuen Version landen. Auf diese Weise nutzen alle User Schritt für Schritt die neue Version. Wird die alte Version nicht mehr genutzt, stellt der Loadbalancer diese automatisch offline.

Die Blau-Grün-Methode verursacht höhere Kosten als die Canary-Methode, ist aber zuverlässiger. Die Nutzer bekommen immer die gleiche Anzahl an Knoten. Wenn beide Versionen aktiv sind, können die Benutzer sogar mehr Knoten als normalerweise erreichen. Aber vor allem ist ein Rollback wirklich einfach – ihr müsst nur am Loadbalancer von der grünen wieder auf die blaue Linie zurückschalten.

Container

Stellt euch vor, ihr müsst nicht nur eine Anwendung in Betrieb nehmen, sondern eine ganze Infrastruktur mit Loadbalancern und anderen spezialisierten Servern. Wenn diese Infrastruktur als Code vorliegt, wird die ganze Sache noch interessanter. Ihr stimmt mir sicher zu, dass niemand in einer technischen Umgebung manuelle Anpassungen – etwa das Eingeben einer URL – durchführen möchte. Dementsprechend sollten alle Prozesse und Zwischenschritte automatisiert ablaufen. Das ist in einer klassischen Umgebung allerdings nahezu unmöglich. Hier benötigt ihr Container.

Ein Container ist ein Paket von Softwaremodulen, das nicht nur die Anwendung, sondern auch das Betriebssystem enthält. Auf diesem Weg müsst ihr die Settings des Betriebssystems nicht mehr anpassen, sondern nur noch das gesamte Paket ausliefern. Diese Pakete können von einer Umgebung in eine andere gebracht werden, ohne dass irgendwelche Änderungen an ihnen durchgeführt werden müssen. Von „außen“ sieht jeder Container gleich aus, obwohl die Inhalte natürlich sehr unterschiedlich sind. Daher auch der Name „Container“. Eine typische Software, die ihr hier nutzen könnt, ist Docker.

Container Management

Wie beschrieben, werden Anwendungen für unterschiedliche Aufgaben, etwa Anwendungsknoten oder spezifische Skripte auf dem Loadbalancer, benötigt. Um ein solches Deployment zu automatisieren und gleichzeitig eine automatische Skalierung zu erhalten, braucht ihr eine Container Management Software. Ist eine neue Software im Versions-Kontroll-System verfügbar, ist die Management Software in der Lage, einen neuen Knoten anzulegen und die neue Software komplett automatisch zu deployen. Die Management Software kann auch entsprechend programmiert werden (skriptet). Ihr könnt so bestimmen, wie ein Deployment durchgeführt werden soll – egal ob nach der Canary-Methode oder dem Blau-Grün-Ansatz.

Zudem könnt ihr innerhalb eurer Management Software bestimmte Kriterien definieren - etwa wann neue Knoten zu einem Cluster hinzugefügt werden oder Knoten herausgenommen werden sollen. Auf diesem Weg kann auf steigende oder fallende Lasten - zum Beispiel durch eine erhöhte Anzahl von Nutzern – reagiert werden. Die Programmierung wird durch das Management Interface gesteuert. Die Nutzer haben hingegen über einen Proxy Zugriff auf das Cluster, so dass das Ganze wie ein „normaler“ Server aussieht.

Vorteilhaft ist der Einsatz einer Management Software nicht nur wegen des hohen Automatisierungsgrades, sondern auch dann, wenn die Anwendung in der Cloud installiert werden soll.

Fazit

Wie ihr gesehen habt, bietet das Online Deployment nicht nur den Vorteil der Automatisierung, sondern ist heutzutage ein absolutes Muss. Um ein funktionierendes Online Deployment zu haben, müsst ihr keine Container oder Container Management Software benutzen. Wie ich euch aber gezeigt habe, hilft ein solcher Einsatz dabei, einen verlässlichen Prozess zu installieren, um neue Software zum Kunden zu bringen.

Weitere Blog-Beiträge aus dieser Rubrik:

• Technische Dinge für nichttechnische Leute 1
• Technische Dinge für nichttechnische Leute 2
• Technische Dinge für nichttechnische Leute 4