Komplexe verteilte Umgebungen mit Bordmitteln managen - Teil 1

Rollout und Systemupdate

Automatisierung in der Praxis

Abstracts

Dieser Beitrag beschäftigt sich mit der Herausforderung der Softwareinstallation in verteilten System Umgebungen sowie Automatisierung mit Bordmitteln.
Da ich hauptsächlich in der Java Welt unterwegs bin, werden in diesem Artikel Bezeichnungen aus dieser Welt verwendet. Die Ansätze lassen sich aber auch leicht auf andere Plattformen wie .NET oder NodeJS usw. portieren.
Es werden moderne Tools wie Ansible und weitere Cloud Techniken angeschnitten, liegen aber bewusst nicht im Fokus dieser Abhandlung.

Container OHNE Docker

Bordmittel

In Zeiten von Docker, Kubernetes und Cloud oder Big Data gibt es eine Vielzahl von Tools, die verschiedenste Herausforderungen adressieren und eine sicherlich gute Lösung bieten. In der Bugwelle jedes Hypes schwimmt jedoch der Anspruch mit, DIE Lösung für eine Vielzahl von Problemen zu sein.
Man sollte sich jedoch immer die Frage stellen, ob man das gehypte Tool denn wirklich braucht. Vielleicht sieht die Lösung der eigenen Probleme ganz anders aus, die Ursache ganz anders begründet.

Conainer OHNE Docker – große Worte könnte man meinen. Zugegeben, es ist sehr gewagt. Aber da Docker im Grunde per Definition eigentlich „nur“ klare Grenzen für das was es enthält schafft, ein Haufen Scripte den Inhalt verwalten und managen, trifft es das ziemlich genau. Im wesentlich geht es um Vereinfachung durch Abstraktion.
Dieses Ziel läßt sich eben auch mit Bordmitteln erreichen, wie wir sehen werden.

Martin Fowler hat es im Zusammenhang mit Microservices einst auf den Punkt gebracht: „If you can’t build a well-structured monolith, what makes you think you can build a well-structured set of microservices?“

Übersetzt heißt dies, daß Microservices nicht der Heilsbringen sind, nur weil man die Architektur danach plant. Übertragen auf den Kontext dieses Artikels kann man sagen, dass die tollsten Tools nicht den gewünschten Erfolg bringen, wenn die Ursache von Problemen nicht geklärt oder die Ziele nicht klar definiert sind.

Aus welchem Grund sollten demnach Container wie Docker, scriptete Ansible Türme oder andere Cloudtechnologien Besserung bringen, nur weil man sie einsetzt.

Wenn System und Software Architektur nicht klar ist, Systemkontexte nicht defniert sind, Runtime Stacks schwammig oder Prozesse verworren sind, dann werden weitere Tools die Komplexität in allen Ebenen einfach nur erhöhen. Die Zielerreichung ist fragwürdig.

Darüber hinaus gibt es zahlreiche Bestandsanwendungen, die sich schlichtweg nicht so einfach mit modernen Tools kombinieren lassen. Der Aufwand und Nutzen ist hier ebenfalls ein wichtiger Aspekt.

Unter diesem Licht ist dieser Artikel entstanden, es soll gezielt die Problematik der Softwareverteilung (primär im JEE Umfeld) betrachtet werden, und in wie weit die Komplexität mit Bordmitteln eingefangen werden kann.

Hoch verteilt, viele Fehlerquellen

Früher war alles besser - wirklich?

Ein übliches Szenario: Ein verteiltes System besteht aus Web und Applicationservern, sowie Datenbanken und weiteren Middlewarekomponenten. Updates der Applikation oder aber auch an Runtime Systemkomponenten haben meist eine ganze Reihe von Implikationen zur Folge:

Anpassen von Config Files
Updaten des WAR oder EAR
Aktualisieren der DB Tabellen, SQL muss ausgeführt werden
Systemumgebung benötigt eine aktualisierte Komponente
Anpassungen im Dateisystem sind nötig

Klassischerweise wird man die Änderungen an allen Servern nach und nach durchführen. Im Besten Fall auf Basis eines Update Guides oder ähnlicher Unterlagen, die bei der Umsetzung unterstützen.

Dies ist nicht nur sehr zeitaufwändig und mühselig in der Umsetzung, sondern auch sehr fehleranfällig:

Der Installation Guide ist unvollständig
Bei der Umsetzung wird ein Schritt vergessen.
Das Konzept insgesamt war fehlerhaft.

Alle drei Möglichkeiten sind ganz reale Rest Risiken und treten in der wahren Welt sehr häufig auf. Steht das System, folgt eine komplexe Analyse – die Suche nach dem Fehler gleicht eher der berühmten Suche nach der Nadel im Heuhaufen. Oft ist ein Rollback und neues Setup dann die bessere Wahl.

Ein Königreich für Automatisierung

Nicht alles war schlecht, trotzdem ist heute vieles besser

Spätestens jetzt wäre es praktisch, wenn man einfach nur mit wenigen Klicks das Setup durchführen könnte. Und warum auch nicht. Die meisten Schritte sind auf jedem Server die gleichen, man kann also vieles schon mal automatisieren. Individuelle Einstellungen können mit zielsystem-spezifischen Konfigfiles abgedeckt werden.