Komplexe verteilte Umgebungen mit Bordmitteln managen - Teil 2

Statische Server im Crush and Build Betrieb

Lösungsansatz ``Static Server``

Build and Crush

Die Idee liegt darin, dass die Server nach dem Setup unveränderbar (immutable), also statisch sind. Jegliche Änderungen benötigen eine neue Installation. Das Konzept ist nicht neu, wird es doch im Kontext von Virtualisierungslösungen schon länger gelebt.

Viele Server lassen sich auf diese Weise also leicht aufsetzen und managen. Eine verteiltes System kann sich dann sogar selber „heilen“ (Self-Healing-Systems). Wenn etwa Unregelmäßigkeiten im Monitoring auftreten, wird ein Server automatisch vom Netz genommen und an anderer Stelle wieder hochgezogen.

Toolchain

Hippe Tools vs. old school Shell Scripting

Tools wie Ansible, Puppet oder Foreman bieten hier wirklich tolle Unterstützung. Aber auch Bordmittel wie Shellskripte sind ein adäquates Mittel, um das Ziel zu erreichen. Letztlich hängt es von den jeweiligen Voraussetzungen ab. Man kann auch verschiedenste Lösungen kombinieren, und so die beste Variante für die Problemstellung definieren.

Cloud Tools und Lösungen

eine Übersicht

Hier findest Du eine (unvollständige) Übersicht und Darstellung der verfügbaren Tools und Lösungen. Ich habe sie so gut wie möglich in knappen Worten vorgestellt.

Check it out - Tool Überblick

Oben genannte Tools benötigen meistens erstmal eine gewisse Einarbeitung. Außerdem sind hier weitreichende Berechtigungen auf den Zielumgebungen nötig. Das kann ein Problem sein, wenn die Zielmaschinen für die Wartung nur durch eigene Tunnel erreichbar, also in der Kommunikation untereinander eingeschränkt, sind. Dies ist heute ein übliches Szenario in gehosteten Umgebungen. Darüber hinaus können eine Reihe anderer Einflussfaktoren gegen eine Out-Of-the Box Lösung sprechen. Etwa Lizenskosten, potenzielles Vendor-Lock-In oder fehlendes Know-How.

Da es auch ohne geht, werden vorhandene Tools hier mal bewusst ausgeblendet. Stattdessen wird auf die Möglichkeiten der Powershell und Bash Bezug genommen. Beide Kommandozeilen Welten bieten genug Möglichkeiten, um eine Automatisierung zu erreichen.

Alter Wein in neuen Schläuchen

Alles alter Tobak - Cloud = Rechenzentren, war alles schonmal da

Was ist das eigentlich genau, diese Cloud?! Ein abstraktes Wunderding welches alle Probleme löst, und Kosten magisch minimiert?!
Ja, so scheint es fast. Bei genauem Hinsehen jeodch: Es muss irgendwo immer noch Blech geben – also Hardware, wo meine Anwendungen laufen. Man trifft auf viel altbekanntes. Hier gibt es einen kleinen Ausflug in die Anatomie der Wolken.

Clouds Anatomy - hier lesen

Automatisierung

Das selbst-fahrende-System

Im klassischen Sinne hat man Änderungen am bestehenden System vorgenommen. Es wurde also eine neue Schicht auf „das Alte“ getan (Stack Style). Mit dem Ziel, alle „Anschlüsse und Verbindungen“ korrekt installiert zu haben. Ein komplettes manuelles Setup „from-the-scratch“ ist in der Regel auch ungleich aufwändiger.

Man kann in dem Bild schon gut erkennen, worauf die Idee hinausläuft. Die potenziellen Fehlerquellen werden um ein vielfaches minimiert.

Die Automatisierung des Setups von Umgebungen eröffnet nun ganz neue Möglichkeiten. Es ist nun ein leichtes, die komplette Umgebung mit jeder Änderung neu aufzusetzen. Man wirft also alles was existiert weg, und führt bei jedem Rollout eine komplette Installation durch.

Ein charmanter Nebeneffekt ist die maximale Reduktion potenzieller Fehlerquellen. Diese liegen nun primär in dem Skript, welches alle Steuerkommandos enthält.

Im Fehlerfall wird das Skript korrigiert, und erneut laufen gelassen.

Es gibt natürlich auch Fehlerquellen, die out-of-scope sind. Wenn sich bspw. Eine IP Adresse ändert und somit ein Zielsystem nicht mehr erreichbar ist.