In unserer vierteiligen „profi.com LAB-Serie“ haben wir euch bereits vorgestellt, wie wir mit dem LAB eine technische Infrastruktur geschaffen haben, um – aufbauend auf Entwicklungsprojekten oder Business Development-Ansätzen – unternehmensweite Services bereitzustellen. Daran wollen wir anknüpfen und euch unseren neuen „VMMaster“-Selfservice vorstellen.
Für die Entwicklung komplexer End-to-End-Automatisierungslösungen nutzten wir in der Vergangenheit oft Produkte aus der Tool-Chain unseres Partners Micro Focus. Mit unserer Red Hat-Partnerschaft stehen uns seit einiger Zeit jedoch weitere interessante Produkte für Service- und Prozessautomatisierung zur Verfügung, welche unser Portfolio passend erweitern.
Bei unserem VMMaster handelt es sich um eine standardisierte Provisionierung und Deprovisionierung von virtuellen Maschinen (VM) in einer End-to-End-Ausbaustufe auf der Basis von Red Hat-Produkten. Als Grundgerüst kommt Ansible/Ansible Tower zum Einsatz, womit sowohl die Kommunikation der Umsysteme stattfindet als auch die Basiskonfiguration der jeweiligen VM an sich.
Folgend wird der Blogbeitrag sich tiefer mit diesen Inhalten auseinandersetzen:
- Was sind die Bestandteile einer VM-Servicebereitstellung?
- Wie erfolgt eine End-to-End-Automatisierung mit Ansible/Ansible Tower?
- Welche Vorteile/Nachteile gibt es bei der Umsetzung mit Ansible/Ansible Tower?
Der Use Case im Detail
Der erste Schritt bei einer Automatisierung ist immer, den bestehenden Prozess zu verstehen und zu standardisieren. So musste auch für das Projekt VMMaster zuerst eine Prozess- und Anforderungsanalyse erfolgen. Am Ende stand ein definierter Prozess, der wie folgt aussah:
Im ersten Schritt soll der User über eine Bestellmaske die Bestelloptionen wie die vCenter-Umgebung oder die VM-Spezifikation anpassen können. Löst er die Bestellungen aus, so ist für ihn der Prozess abgeschlossen. Im Hintergrund werden nun folgende Teilaufgaben ausgelöst:
Zuerst wird ein Schlüsselpaar aus Hostname und System-ID generiert, um eine eindeutige Identifikation der VM zu ermöglichen. Ohne dieses Schlüsselpaar lässt sich die Konfiguration oder das Undeployment der VM nicht durchführen. Zur Verwaltung und Überwachung der IP-Adressen wird im nächsten Schritt ein Eintrag in das IP-Management System (IPAM) erzeugt. Anschließend wird im vCenter die VM mit den definierten Konfigurationsparametern aus einer Auswahl an Vorlagen beziehungsweise Templates erzeugt. Im letzten Schritt wird ein User-Account auf der VM generiert und der User über die Fertigstellung seiner VM per E-Mail benachrichtigt.
Doch was bringt diese Prozessautomatisierung eigentlich? Bisher hat ein Nutzer seine Bestellung an einem Admin übergeben müssen und alle oben genannten Schritte mussten manuell ausgeführt werden. Vervielfacht man die Anzahl der bestellten VMs erhöht es das Aufgabenvolumen enorm, ohne das ein wesentlicher Mehrwert generiert wird. Genau im Fall von sich immer gleichen und wiederholenden Aufgaben in hoher Frequenz unterstützt Automatisierung bei der Effizienzsteigerung, als auch der Befreiung von monotonen Aufgaben und der Vermeidung von Fehlern. Die dadurch freiwerdenden Kapazitäten können in andere Prozesse verlagert werden, wodurch auf langfristige Sicht eine deutlich größere Wertschöpfung erzeugt wird.
Was ist Ansible Tower?
Für die Automatisierung des beschriebenen Uses-Cases kommen Ansible Playbooks zum Einsatz. Ansible ist eine von Red Hat gesponsorte Open Source-Engine, die es ermöglicht, Konfigurations-, Deployment-, Orchestrierungs- und viele weitere IT-Prozesse zu automatisieren und wiederholbar anzuwenden. Die Kernunterschiede zu anderen Lösungen liegen am Open-Source basierten Ansatz sowie der deklarativen und agentenlosen Funktionsweise. Falls ihr mehr über Ansible erfahren wollt, schaut einfach in unsere Ansible-Webinarreihe hinein.
Mit Ansible allein fehlen jedoch viele Funktionalitäten wie Zugriffsteuerung, Orchestrierung oder eine Benutzeroberfläche, um aus der reinen IT-Automation eine komplexe IT-Service Automatisierung zu erstellen. Hier kommt Ansible Tower (in der neusten Version „Automation Platform 2“ genannt) zum Einsatz. Der Ansible Tower fungiert als zentrale Plattform für die Verwaltung und Steuerung von Ansible Playbooks. In Kombination ermöglichen diese beiden Red Hat-Werkzeuge die Bereitstellung einer komplexen End-to-End-Automatisierung für verschiedene IT-Services.
Ansible Tower kommt mit einer eigenen Benutzeroberfläche (UI) daher. Damit bietet es den Anwendern eine Möglichkeit, ohne komplizierte Kommandobefehle Workflows und Automationsprozesse zu definieren und zu steuern. Über die UI lassen sich aber auch alle Administrationsaufgaben des Ansible Towers ausführen. So bietet es zum Beispiel rollenbasierte Zugriffskontrollen (RBAC) mit der Möglichkeit, es an ein bestehendes LDAP oder anderen Authentifizierungsmöglichkeiten wie Github, Azure AD oder auch Google OAuth 2.0 anzubinden. Damit lässt sich das Nutzermanagement einfach und flexibel gestalten und in Kombination mit der UI ermöglicht es die Umsetzung des VMMasters als Selfservice. Die nachfolgende Übersicht gibt ein vereinfachtes Beispiel für die Eingabemaske bei der Bestellung einer VM.
Umsetzung mit Ansible Tower
Für die Zusammenstellung einer Prozessautomatisierung nutzt Ansible Tower zwei wesentliche Komponenten – die Workflow Templates und Job Templates. In einem Job Template werden einzelne Playbooks ausgeführt, bei welchem verschiedene Parameter mitgegeben werden können. So lassen sich Branch, Inventory oder auch extra Variablen für eine flexible Wiederverwendung der Playbooks anpassen.
Workflow Templates hingegen bilden den Automationsprozess ab und bestehen aus der logischen Aneinanderreihung von Job Templates1, Synchronisationsaufgaben2 oder Workflow Templates3 selbst. Somit beinhalt das Workflow Template die logische Abfolge aller Prozessschritte zur Bereitstellung des VMMaster Services.
Um die Funktionsfähigkeit des VMMasters bestmöglich zu gewährleisten ist es notwendig, Komplikationen während der Bestellung so schnell wie möglich zu identifizieren und daraus die entsprechenden Maßnahmen abzuleiten. Je nachdem in welchem Stadium sich die Bestellung bereits befindet, wird die Provisionierung wieder zurückgesetzt oder in einem definierten Pfad fortgesetzt. Die übersprungenen Schritte müssen anschließend manuell bearbeitet werden. Unabhängig vom Szenario wird das Operations-Team zur Problemlösung per E-Mail benachrichtigt.
Besonderheiten der Lösung
Da wir bereits in vielen Projekten mit unterschiedlichen Werkzeugen Automatisierungsprozesse umgesetzt haben, war es sehr spannend mit Ansible und Ansible Tower im VMMaster-Projekt neue Ansätze kennenzulernen und weitere Erfahrungen zu sammeln. Mit der Tool Chain von Red Hat konnten wir in Hinblick auf unseren Use-Case folgende Vor- und Nachteile identifizieren.
| Vorteile | Nachteile |
| – Open Source oder Enterprise Version möglich – Dynamisches Inventory Management aus verschiedenen Quellen möglich – Viele Optionen bei der Zugriffsteuerung – Mächtige REST-APISoftware ist sehr ressourcenschonend | – Workflow begrenzt gestaltbar (wiederholen oder verweisen auf vorherige Schritte nicht möglich) – Error Handling-Möglichkeiten begrenzt – Selfservice Portal-Möglichkeiten wie dynamische Listen oder Kataloge fehlen |
Wie man an den Nachteilen sieht, ist Ansible Tower noch nicht optimal, um allen Herausforderungen der Serviceautomatisierung gerecht zu werden. Hierbei sind die Wurzeln des Konfigurations- und Servermanagement noch deutlich zu sehen. Jedoch arbeitet Red Hat intensiv daran, um Ansible Tower im Automationsbereich weiter auszubauen. So bekommt der Ansible Tower mit Ansible Automation Platform 2 nicht nur einen neuen Namen, sondern auch eine neue Architektur mit neuen Features spendiert. Somit könnte die Lösung von Red Hat eine echte Alternative für unsere Kunden sein, um in Zukunft komplexe End-to-End-Automatisierungen umzusetzen.
Ausblick
Auch wenn unser VMMaster in seiner ersten Iteration abgeschlossen ist, so ist das Projekt noch längst nicht beendet. Mit der Einführung von Custom Templates als Klonvorlage, dem automatischen Undeployment von nicht genutzten VMs oder auch der Anbindung an einem dedizierten Frontend stehen schon die nächsten Features in der Agenda. Aber auch von der DevOps-Seite soll der VMMaster weiter ausgebaut werden. So ist ein wichtiges Ziel, den VMMaster in eine CI/CD-Pipeline zu integrieren – für mehr Effizienz und eine flexiblere Skalierbarkeit.
