Komplexe verteilte Umgebungen mit Bordmitteln managen - Teil 3
Scripted Crush'n Build
Einreißen und aufbauen
Vorsicht mit dem Vorschlaghammer, Abgrenzung beachten

Crush’n Build bedeutet, dass die ganze Umgebung abgerissen und neu aufgebaut wird. Quasi wie als wenn wir einen Container zerstören und neu instanziieren.

Mittels Powershell oder Bash kann man einfache aber auch komplexere Crush’n Build Skripte erstellen.
Auch ANT oder Maven bieten sich an. Ansible ist die rund-um-sorglos Lösung unter dem Red Hut, und kommt mit einer Unzahl an Konnektoren und Modulen die anderen Cloud Technologien integrieren. Tendenz steigend.

Wir gehen hier auf nötige Abgrenzungen ein und zeigen ein Beispiel.

Kontext der Setup Artefakte definieren
Was ist alles vom Update betroffen

Bei dem radikalen Vorgehen ist es unabdingbar, sich im Vorfeld Gedanken darüber zu machen, welche Daten herstellbar sind und welche nicht. Meistens sind das Arbeitsdaten, diese können in der Datenbank aber auch im Filesystem liegen.

Auch der Systemkontext muss klar sein. Also, was gehört alles zu meinem System, was kann ich zerstören und selber wieder herstellen. Möglichweise ist man im Gesamtsystem (OS, Server) nicht alleine.

Der Systemkontext muss also klar sein.

Man gelangt auf diese Weise zu der Erkenntnis, dass die Middlewarekomponenten eigentlich nur notwendiges Beiwerk sind, die ich ohne viel Aufwand wieder herstellen kann. Dabei ist es unerheblich, ob hierbei ein Applikations oder Webserver involviert ist, oder Third Party Software … gar ein ganzes Betriebssystem. Letzteres würde für unseren Rahmen zu weit gehen, es verdeutlicht aber die Idee der Automatisierung.

Cloud - IaaS, PaaS, SaaS
Exkurs

Die Idee der Cloud verkörpert im wesentlichen diesen Ansatz: Rechenpower on-demand, meine Software muss einfach nur laufen. Diese steckt dann lediglich in Containern (Docker), die dann in die Cloud geschoben werden. Den Container kann man beliebig oft clonen und wieder herstellen. Stichwort „Self-Healing-Systems“

Wurde eine sinnvolle Abstraktion erreicht, kann alles das, was bei einem Systemupdate angefasst werden muss, in einem Skript abgelegt werden.

Im Prinzip ist es nun egal, ob man sich auf bare Metall oder in der Cloud bewegt. Die Vorteile der Cloud nützen nichts, da auch diese nicht auf magische Weise weiß, welche Anpassungen nötig sind. Zudem wollen auch die Cloud Software Stack gesteuert werden – Open Stack und Cloud Foundry sind in der Bedienung nicht trivial und müssen auch mit Befehlen bestückt werden. Ebenso Kubernetes und Docker.

Skript erstellen
definieren von Modulen

Es bietete sich auf jeden Fall an, Module zu bilden. Das hat gegenüber einem einzigen Universalskript ein paar Vorteile:

  • Es ist übersichtlicher
  • Änderungen lassen sich gezielt einbringen
  • Einzelne Module lassen sich auch mal so ausführen, ohne daß man seinen Skript Monolithen parametrisieren muss.
Komplexe verteilte Umgebungen mit Bordmitteln managen – Teil 2
Apr 16, 2017
Cloud Tool Chain
Apr 25, 2017