Konfigurations-Management auf den Open Source Automation Days 2022 Wenn User in komplexen Cloud-Umgebungen den Bug selbst fixen

Anbieter zum Thema

Vogel IT-Medien GmbH

FNT GmbH

Schwarz IT KG

ATIX AG

Intelligent automatisiertes Konfigurations-Management reduziert nicht nur die Kosten für die Unternehmen, sondern bringt Admins und Usern auch mehr Kreativitätsfreiräume jenseits stupider repetitiver Tätigkeiten. Ein Vortrag auf den „Open Source Automation Days“ (OSAD) 2022 zeigte, wie Config-Management dabei mit Workflows-Anforderungen und Orchestrierung zusammenspielen kann.

„Hände weg bei der Konfiguration großer Server-Landschaften in der Cloud“, so könnte man Vortrag von Martin Alfke, CEO von Betadots, des Berliner Schulungsanbieters für Open-Source-System-Management-Software, auf den „Open Source Automation Days“ (OSAD) 2002 der Firma Atix etwas flapsig beschreiben. Dass das händische Aufschalten auf Hunderte Server, um dann Hunderte Male die gleiche Befehlsfolge zu tippen, nervtötend und superteuer ist, leuchtet eigentlich unmittelbar ein.

Bemerkenswerte Keynote zur Digitalen Souveränität

Atix AG: Open Source Automation Days 2022

Dennoch ist es nicht selten noch (un)gern(?) geübte Praxis. Spätestens bei dynamischen Cloud-Umgebungen, bei denen in Null-Komma-Nix 50 Server, die man gerade händisch konfiguriert hat, schon wieder abgekoppelt sind, wird jedem klar, dass Automatismen beim Konfigurieren alternativlos los, alles andere ist die pure „Admin- und auch User-Hölle“.

Config-Automatisierung in Richtung Anwendung

Als Grund schlechter und Geld verschleudernder Praxis sieht Alfke nicht so sehr eine Inkompetenz der Admins, sondern bestimmte unregelmäßig wiederkehrende Aktivitäten wie ungeplante Änderungen oder nachträglich eingeschobene Änderungen, die nicht oder zumindest nicht ohne großen Aufwand in so genannte Desired State Configuration (DSC-)Konstrukte integriert werden könnten, da diese ja per definitionem einen finalen Zustand der Konfiguration beschrieben. DSC verbiete eben widersprüchliche Einstellungen wie etwa „Service stop“ und danach gleich „Service Start“.

Mit DSC allein gebe es keine (zumindest unmittelbar zur Verfügung stehende Möglichkeit), punktuell erwünschte Abläufe darzustellen beziehungsweise zu automatisieren, etwa wenn die Marketingabteilung „eben mal wissen wolle, wie viele Zahlkunden sich aus einer gerade abgeschlossenen Kampagne ergeben hätten“. Rein technisch läuft eine solche Anforderung darauf hinaus, dass eine Applikation in der richtigen Reihenfolge ausgerollt wird (Datenbank, Middleware, Front-End). De facto verlangen also die User, dass die Möglichkeiten der Automatisierung des Konfigurationsmanagements auch für Anwendungen fruchtbar gemacht werden.

Automatisierte Anweisungen statt individuelles Skripten

Alfke beschäftigte sich in seinem Vortrag im Detail mit Möglichkeiten, wie man die eben beispielhaft genannte (absolut wichtige und richtige) Anforderung so umsetzen kann, dass nicht mit ad hoc geschriebenen Skripten, die womöglich jeder Admin ein bisschen anders gestaltet, hantiert wird, sondern mit möglichst viel (generalisierbarer) Automatik.

Mit der Konfigurationssprache „Ansible“ könne diese Anforderung, so der Referent, in das so genannte Playbook aufgenommen werden, mit dem Konfigurations-Tool „Puppet“ müsse man etwas mehr Codezeilen investieren, weil zusätzlich zu dem Skript, in „Bash“ und „Python“ beispielsweise, noch eine JSON-Datei angelegt werden müsse, in der die Parameter und Datentypen hinterlegt seien. Schließlich dürfe der Automat keine fehlerhaften Eingangsdaten (etwa einen String-Wert statt eines Booleschen Werts) erhalten und auch nichts Fehlerhaftes selbst produzieren.

Automatisch konfigurieren im „Orchestrierer“

Wenn es um ganze Serverlandschaften geht (und das ist in der Cloud wohl fast immer der Fall), muss das automatisierte Konfigurations-Management auch mit der Orchestrierung zusammenspielen. Auch hierbei kann einerseits mit Ansible gearbeitet werden, andererseits mit Puppet in seiner Ausprägung „Puppet Plans“.

Ein solcher „Plan“ beschreibt, welche Puppet Tasks auf welchem System in welcher Reihenfolge ausgeführt werden. Diese Information kann man ohne hart-codierte oder manuelle Listen sehr elegant mit „plans“ aus der Puppet-Datenbank extrahieren.

Weitere Details der Referenten sollen hier entfallen. Quintessenz des Vortrags war jedenfalls, dass mit Tools wie Ansible oder Puppet (oder auch Chef) hinreichend automatisiert Ablaufvorgänge programmiert werden können, ohne dass direkt mit dem SSH-Protokoll gearbeitet werden muss.

Konfigurations-Management de luxe

Die zuletzt beschriebenen Maßnahmen machen eine weitgehende Automatisierung auch bei den komplexen Konstellationen im Bereich der Workflows (Ablaufsteuerung) oder der Server- und Service-Welten (Orchestrierung) möglich. Eine noch weiter gehende Automatisierung – so Martin Alfke in seinen Schlussbemerkungen – ist durch ein Message-Queue-basiertes System möglich, auf dessen Basis über ein Webinterface und ein rollenbasiertes Zugangssystem (RBAC) eine komplette zentrale Steuerung und ein komplettes Logging möglich werden.

In diesem Kontext kann sich Alfke ein Szenario vorstellen, wo auch ein weitgehender System-Management-Laie eine Website, die „ihm oder ihr komisch vorkommen“ und wegen der sie heute noch ein Ticket an die Systemadministration öffnen würden, selbsttätig auf einen roten Knopf im Menü klicken und die Website selbst wieder in Ordnung bringen. Nota bene, ohne zu wissen, welche technischen Vorgänge nach dem Knopfdruck ablaufen.

Der Anwender habe jedenfalls das Gefühl, dass er oder sie den „Bug selbst gefixt hätten“. Mit anderen Worten: Automation de luxe im Konfigurations-Management in der Cloud.

(ID:48708196)