"Ansible Automates" in München Die Zukunft der IT-Automatisierung: maschinelle Reparaturprozesse

Anbieter zum Thema

PresseBox - unn | UNITED NEWS NETWORK GmbH

Fujitsu Technology Solutions GmbH

FNT GmbH

Red Hat GmbH

Red Hat GmbH

Mit Cloud-orientierten IT-Automatisierungs-Tools wie „Ansible“ lassen sich in Zukunft komplexe Reparaturprozesse in der IT auch für Anwender ohne systemorientiertes Spezialwissen handhaben. Die Roadshow „Ansible Automates“ von Red Hat hat die Richtung aufgezeigt.

Als Instrument für den Brückenbau zwischen den traditionellen Silostrukturen in der IT hat Belkacem Moussouni, Head of Business Development EMEA beim Open-Source-Pionier Red Hat, das hauseigene Konfigurationstool Ansible bezeichnet. Moussouni hat auf einer Roadshow für Ansible-Experten und solche, die es werden wollen, in München gesprochen. Weitere Stationen sind Genf, Zürich, Frankfurt am Main und Wien gewesen.

Schon der Name „Ansible Automates“, den man für die technische Werbereise gewählt hat, zeigt, dass die Ansible-Experten in ihrem Produkt weit mehr sehen als ein bloßes System-Management-Tool für das Cloud-Zeitalter. In der Tat: ein modernes System-Management-Werkzeug ist die „Ansible Automation Platform“ sicher auch, aber gleichzeitig noch viel mehr, nämlich ein Allzweck-Werkzeug für die Automatisierung umfangreicher IT-Prozesse. „Wir können alles integrieren, was eine IP-Adresse hat, selbst den Kaffeeautomaten“, mit solchen Statements zeigt man auf der Veranstaltung die verbalen Muskeln.

Nach Kubernetes das meistgefragte Community-Projekt

Obwohl Ansible mit seiner Sprache namens YAML am Anfang nicht als Open-Source-Tool konzipiert war, hat die IBM-Tochterfirma Red Hat das Automatisierungs-Paket seit der Übernahme der Firma Ansible im Jahr 2016 zu einem der nach Kubernetes meistgefragten Community-Projekte im Bereich IT-Automation (DevSecOps, Konfiguration, Systemmanagement, codebasierte Infrastruktur-Darstellung .... ) gemacht.

„Ansible hat mehr als 50.000 Experten („Github-Stars“) in der Community präsent, dazu mehr als 5.900 Ansible-Module sowie mehr als 17 eigene quelloffene Komponenten in Github verzeichnet“, haben die beiden Ansible-Architekten Leonton Doering und Karoly Vegh auf der Münchner Tagung berichtet. Dazu würden jeden Monat zwei Millionen Downloads von Ansible-Code registriert.

Fallbeispiele für IT-Automatisierung

In ihrem Vortrag auf der Münchner „Ansible Automates“ präsentierten Doering und Vegh Beispiele dafür, was derzeit Anwender mit der (mittlerweile) Ansible Automation Platform genannten Software-Umgebung machen: das Spektrum reicht vom Aufbau einer Self-Service-Plattform für das Ausbringen von virtuellen Maschinen bei Schwarz IT (Technik-Mutter unter anderem von Lidl) über den automatischen Abgleich („Validierung“) der Netzwerkeinstellungen mit der vorhandenen Dokumentation beim schweizerischen Telekom-Anbieter Swisscom und der Ausbringung von Windows Updates über die verschiedenen betroffenen Teams hinweg („Cross-Team Collaboration“) bei Siemens bis zum automatischen Zusammenspiel von IT Service Management und Änderungsanfragen bei der Lufthansa.

Doering und Vegh haben darauf hingewisen, dass alle genannten Aufgaben alles andere als trivial sind: So müsse man vor der Ausbringung eines „Windows“ Update bei den einzelnen Teams („Load Balancer-Team, Virtualisierungsteam etc.) erst einmal den Status quo abfragen, bevor man die aktualisierte Betriebssystemsoftware aufspiele und bei der Integration von Change-Anfragen und IT Service-Management gehe es um nichts weniger als darum, Änderungswünsche ohne menschliche Zwischenträger („Cloud Team“) direkt an den jeweiligen Ankerpunkt („Hook“) des ITSM-Systems zu bringen.

Doering und Veh empfehlen, die derzeit von Ansible besonders unterstützten Technologiebereiche, die Red Hat in so genannten Certified Collections präsentiere, mit den eigenen Technologieansätzen und Technologieschwerpunkten zu vergleichen und Lösungen zunächst im Bereich entsprechender Schnittstellen-Bereiche zu entwickeln. Damit sei die beste Effizienz zu erreichen.

Entkopplung von Ausführungs- und Steuerungsebene

Diese Vorgehensweise ist absolut plausibel, im Vorfeld sollten potenzielle Anwender aber die Spezifika der Ansible Automation Platform 2, die es im Übrigen nicht nur direkt von Red Hat, sondern die es auch als Paket in den Cloud-Angeboten von „Microsoft Azure“ und Amazon Web Services gibt, gut studieren. Den Stand der heutigen Technik und die architekturale Planung für die nahe Zukunft hat Götz Rieger, Principal Solutions Architect bei Red Hat, auf der Ansible Automates in München detailliert dargestellt.

Während die lange dominierende Steuerungsumgebung „Tower" von Ansible sehr monolithisch angelegt ist - unter anderem waren die Fähigkeiten von Control und Execution eng miteinander verschränkt - und die Systemarchitektur nur wenig skalierbar, sind Control und Execution in der aktuellen Version entkoppelt, so Rieger. Angesichts der heute vorherrschenden Aufteilung der Rechen- und Speicherkapazitäten in Zentralverarbeitung und Vor-Ort-Verarbeitung (Zentrale und „Edge“) war das Nachführen der Ansible-Architektur in diesem Bereich unausweichlich.

Er nimmt als Beispiel eine Fischfabrik in Grönland, deren Zentrale in Cuxhaven oder Hamburg ist. Die Firewall-Mechanismen (unter anderem die DMZ) befinden sich in einer solchen Konstellation an der „Edge“ in Grönland, also am „execution node“, während die Steuerungskomponente („control plane“) in Cuxhaven oder Hamburg lokalisiert ist. Zwischen Execution Plane und Control Plane gibt es nach Darstellung von Rieger ein „stabiles Messaging“ („automation mesh“).

Privater „automation hub“ als Sicherheits-Kordon

Die Steuerungsebene alias „automation controller“ (der ehemalige Tower) ist unter anderem angereichert durch eine Benutzerverwaltung („nicht jeder Nutzer darf alles“), eine Anwendungsprogrammierschnittstelle (API) für die Systemintegration und durch ein Rechte-Management. Im „Automation Workflow“ lassen sich mehrere Jobs (Netzwerk, Sicherheit, Virtualisierungs-Konfiguration etc.) miteinander verketten. Die Ausführungsphase ist darüber hinaus weitgehend gegen Unterbrechungen und unvorhergesehene Übertragungsverzögerungen immun.

Die „execution“ spielt sich in einem Linux-Container ab. Man benötigt Container-Images, um die Anweisungen im Ansible-Playbook auszuführen. Um die Playbooks in die Execution-Umgebung zu schieben, steht mit dem „Navigator“ ein spezielles Tool dafür zur Verfügung.

Der zentrale „Automation Hub“, in dem der „Automation Controller“ angesiedelt ist und in dem die Playbooks ausgeführt werden, ist ohne weitere Eingrenzungen zu unsicher. Deshalb werden die Anwender in aller Regel einen privaten „Automation Hub“ benutzen, in dem die Module aggregiert sind, die benutzt werden dürfen. Und der „Automation Controller“ darf nur den Content verwenden, der in diesem privaten Hub steht.

IT-Automatisierung ohne Spezialwissen auf Knopfdruck

Was derzeit noch nicht in den „Automation Controller“ integriert ist, aber in naher Zukunft eingebaut werden soll, ist eine „event driven architecture“. Damit sind wir beim großen Thema, das alle cloud-orientierten IT-Automatisierer derzeit besonders umtreibt. Erst kürzlich hat dieses Portal die Aufgaben in einem Artikel über den Ansible-Mitbewerber Puppet dargestellt.

Konfigurations-Management auf den Open Source Automation Days 2022

Wenn User in komplexen Cloud-Umgebungen den Bug selbst fixen

Es geht schlicht darum, menschliche Zwischeninstanzen bei der IT-Automatisierung komplett oder zumindest weitgehend zu eliminieren und die IT-Automatisierer in Richtung selbstheilende Systeme (oder zumindest Systeme, die auch ohne IT-Spezialwissen erfolgreich genutzt werden können) weiterzuentwickeln. Ansible macht da keine Ausnahme.

Grundmuster einer solchen ereignisgetriebenen Architektur ist eine Playbook-Ausführung, die durch ein Ereignis getriggert wird („wenn das und das passiert, dann führe dieses Playbook aus“). Als Vorausschau hat Rieger andeuten können, wie das im Einzelnen funktioniert. Es werde ein Verzeichnis („Source“) geben, in dem festgelegt sei, aus welchen Quellen die Events kommen dürften und es würden Regeln definiert, wie darauf reagiert werde. Dann werde die Aktion ausgelöst und es gebe eine Meldung, wenn die „Reparatur-Operation“ abgeschlossen ist.

Wir wären nicht im Zeitalter die Künstlichen Intelligenz, wenn man gleichzeitig mit dieser Vorgehensweise nicht überlegte, wie man die eben geschilderte Abfolge ihrerseits weiter automatisieren kann. So liegt es nahe, vorhandene Muster („Best Practices“) bei der Playbook-Erstellung einzubeziehen und einen Satz von Muster-Playbooks zu erstellen. Das Ganze kann man dann beispielsweise auch einem KI-Wissensmonster wie „Watson“ aus dem Hause IBM, der Red Hat-Mutter, beibringen und voilà: Man ist mitten in der Ansible-Zukunft.

Mit intelligenten Playbooks und deren Einbringen in selbstorganisierte Automatisierungsprozesse macht man diese Prozesse auch für „einfache IT-Anwender“ in den Fachabteilungen als Self-Service verfügbar und verwendbar beziehungsweise man macht solche Automatisierungsprozesse gleich komplett „maschinenlesbar“, ohne dass händische menschliche Eingriffe notwendig sind.

(ID:48770837)