DevOps-Enabler Ansible, Teil 1 Ansible, AWX und Ansible Tower im Überblick

Mit Blick auf die Veröffentlichung von Ansible 2.5 und Ansible Tower 3.2.2 bringt Dev-Insider ein Rundum-Spezial im Kontext von Puppet, Chef und Salt. Dieser Teil klärt, was der Open-Source-Star besser macht als die etablierte Konkurrenz, worin sich Ansible, Ansible Tower und AWX unterscheiden und wer die Player hinter Ansible sind.

Anbieter zum Thema

PresseBox - unn | UNITED NEWS NETWORK GmbH

Windhoff Group

Ansible ist eine Open-Source-Lösung für ein vereinfachtes und automatisiertes Konfigurieren von Rechnern in der Cloud oder in lokalen Umgebung sowie für deren Orchestrierung. Genau genommen erlaubt Ansible das Automatisieren von Konfigurationsprozessen und bildet damit die Grundlage zur zentralen Administration multipler Systeme.

Im Vergleich zur Konkurrenz (Chef/Puppet) fehlt es Ansible an einer grafischen Schnittstelle, die Red Hat mit dem kommerziell ausgerichteten Ansible Tower ergänzend anbietet. Davon gibt es seit Herbst 2017 mit AWX auch eine quelloffene Variante.

Historisches

Für eine adäquate Beurteilung von AWX und Ansible Tower sollte man wissen, worin sich Ansible von Puppet und Chef unterscheidet bzw. wo Ansible seine prinzipiellen Grenzen hat. Zur Historie: Ansible wurde erst im Jahr 2012 von Michael DeHaan als Open-Source-Projekt ins Leben gerufen und derart schnell erfolgreich, dass bereits 2013 die neu gegründete Firma AnsibleWorks (später Ansible Inc.) nennenswerte Umsätze mit Ansible-Support generieren konnte und die Weiterentwicklung vorantrieb.

Ansible Inc. wurde dann im Jahr 2015 von Red Hat übernommen. Das Open-Source-Projekt blieb aber ganz im Sinne der Gepflogenheiten der Rothüte bis heute frei verfügbar. Red Hat professionalisierten lediglich als Hauptsponsor die Weiterentwicklung, achtet aber darauf, dass der Charakter eines bei Github geführten Community-Projekts erhalten bleibt.

Verwandtschaften

Im Gegensatz zu Puppet und Chef ist Ansible nicht in Ruby, sondern in Python geschrieben. Zudem gilt Ansible im direkten Vergleich als weniger komplex und leichtgewichtig. Allerdings ist pures Ansible lediglich als CLI-Werkzeug implementiert. Wer eine grafische Oberfläche bevorzugt musste bis Herbst vergangenen Jahres zu Ansible Tower greifen, welches nur per Subskription erhältlich war und ist.

Red Hat allerdings hat im August 2017 den Quellcode von Ansible Tower unter eine Open-Source-Lizenz und diesen der Community unter der Bezeichnung Ansible AWX auf GitHub zur Verfügung gestellt. Ansible Tower bleibt nebenher bestehen. So soll AWX-Projekt neue Versionen in recht hohe Frequenz ausspucken, während Ansible Tower die Rolle der Version mit Long-Term-Support einnimmt.

Dabei hat der unter der Apache 2 Lizenz stehende Quell-Code eine eigene Versionierung erhalten, die vom Start weg mit der Version 1.0.0 debütierte, die 1 vor dem Komma also keineswegs für stabil steht. Red Hat empfiehlt AWX unabhängig von der Version ausdrücklich nicht für den produktiven Einsatz. Auch wenn das Projekt derzeit noch sehr stark von Red Hat dominiert wird, begrüßt das Unternehmens aus Raleigh externe Beiträge wie schon bei Ansible.

Dabei sind die Spendierhosen wie üblich strategischer Natur, denn schließlich erhofft sich Red Hat im Gegenzug auch von der Community schnelle Verbesserungen für AWX und damit Ansible Tower. Unternehmenskunden daher aber ihr Augenmerk nach wie vor in erster Linie auf Ansible Tower richten, für das Red Hat umfassenden Support bietet, während die Community AWX-Unterstützung nur per IRC und eine AWX Mailing List gibt.

Wie funktioniert Ansible?

Doch zunächst zu Ansible selbst. Dieses arbeitet nicht wie Puppet oder Chef mit eine Master-/Client-Beziehung, was eine zugehörige Agent-Komponente auf den zu verwaltenden Knoten voraussetzen würde. Das leichtgewichtige Ansible benötigt auf den zu verwaltenden Cloud- oder Netzwerk-Knoten lediglich SSH und Python.

Sobald eine SSH-Verbindung zum Zielsystem möglich ist, was für nahezu jedes Betriebssystem leicht konfigurierbar ist, überträgt Ansible sämtliche für deren Konfiguration benötigten Komponenten zur Laufzeit auf das Zielsystem, führt sie fort aus, entfernt die Komponenten/Tools anschließend wieder und beendet die SSH-Verbindung.

Eine dauerhafte „Beziehung“ wird nicht aufgebaut. Man könnte meinen, dass die Arbeitsgeschwindigkeit durch dieses relativ simple Verfahren negativ beeinträchtigt wird, was aber in der Praxis nicht der Fall ist. Zudem entfällt der Aufwand zur Pflege der Agenten und Updates für Ansible selbst spielen nur bei lokaler Installation eine Rolle.

Ansible arbeitet in größeren Umgebungen in der Regel simultan mit/auf mehreren Knoten der zu verwaltenden Infrastruktur, weshalb der Admin zuerst einmal wissen muss, wie das jeweilige System zu erreichen ist. Ansible löst dieses Problem derart, dass aller Ziel-Systeme in einem zentralen Inventar, dem so genannten Ansible-Inventory gepflegt werden.

Es basiert auf einer einfachen Textdatei, die standardmäßig unter /etc/ansible/hosts zu finden ist; abweichende Pfade können mit der Option -i <path> angeben werden. Das SSH-Verfahren ist zwar einfach und effizient, erlaubt aber im Vergleich zu den Konkurrenten Puppet oder Chef kein Bare-Metal-Provisioning, da auf den zu verwaltenden Koten ein Betriebssystem mit SSH-Zugang erforderlich ist.

Was sind Playbooks?

Die „Beschreibungssprache“ von Ansible ist wie bei Chef imperativ und besteht aus in YAML verfassten Handlungsanweisungen, die bei Ansible „Playbooks“ heißen, vergleichbar mit den Cookbooks bzw. Rezepten in Chef. Während diese Anweisungen in YAML verfasst sind, verwenden die sogenannten Ansible-Module JSON als Ausgabe-Syntax. Die einfachste Form eines Ansible-Playbooks könnte z. B. so aussehen:

Jedes Playbook besteht aus einem oder mehreren „Plays“ (Spielen) in einer Liste. Das Ziel jedes Spiels besteht darin, eine Gruppe von Hosts auf einige definierte Rollen abzubilden, repräsentiert durch Dinge, die in Ansible „Tasks“ genannt werden. Auf einer grundlegenden Ebene ist so ein Task nicht anderes, als der Aufruf eines Ansible-Moduls.

Durch das Erstellen eines Playbooks mit mehreren Plays ist es möglich, Multi-Maschinen-Implementierungen zu orchestrieren, etwa bestimmte Schritte auf allen Maschinen in einer Webserver-Gruppe auszuführen, dann bestimmte Schritte in der Datenbank-Server-Gruppe auszuführen und schließlich weitere Befehle in der Webserver-Gruppe usw.

Dabei sind Plays weit mehr als eine Metapher. Admins können in Ansible sehr viele Spiele spielen, die Ihre Systeme beeinflussen, um verschiedene Dinge zu tun. Dabei ist es durchaus nicht so, dass man als Admin einen bestimmten Zustand oder ein bestimmtes Modell definiert, d. h. der Admin kann durchaus verschiedene „Spiele“ zu „verschiedenen Zeiten“ spielen.

Ansible-Module und Ad-hoc-Modus

Eine weitere Besonderheit von Ansible besteht darin, dass Ansible nicht nur für die Orchestrierung, Software-Verteilung und das Konfigurationsmanagement zum Einsatz kommt, sondern auch einen „Ad-hoc-Modus“ kennt. In diesem kann der Admin einfache Befehle parallel auf einer Gruppe von Knoten ausführen, ohne dafür vorab explizit ein Playbook erstellen zu müssen. Ad-hoc-Kommandos verwenden folgende recht einfache Syntax:

Ansible wird stets mit einer Anzahl von Modulen (auch „Modul-Library“ genannt) ausgeliefert, die man wahlweise direkt auf Remote-Hosts (Ad Hoc) oder via Playbook ausführen kann. Der komplette Modul-Index findet sich in Ansible-Dokumentation. Eine etwas bessere Übersicht liefert die gruppierte Version des Modul-Index.

Neben den mehreren hundert Standard-Modulen können Benutzer bei Bedarf selbstredend auch eigene Module schreiben. Diese Module können Systemressourcen wie Services, Pakete oder Dateien steuern oder Systembefehle ausführen. Einige einfache Beispiele für Ad-hoc-Kommandos könnten wie folgt aussehen:

So findet sich z. B. in der Modul-Kategorie „Managing Packages“ Ansible-Module für yum und apt. Das Ad-hoc-Kommando …

… prüft z. B., ob der acme-Support für Apache installiert ist, nimmt aber kein Update vor.

Man kann auch prüfen, ob eine ganz bestimmte Version des Paketes installiert ist …

… oder die jeweils neueste Version:

Im nächsten Teil unserer Ansible-Serie wenden wir uns konkret der Inbetriebnahme, also der Installation und Konfiguration von Ansible zu und zeigen anschließend, wie man Ansible im Rahmen von Ansible Tower installiert. Eine interessante Anekdote im Vorgriff: eine der möglichen Installations-Methoden für Ansible Tower ist die, dass Ansible Tower über ein Ansible-Playbook installiert wird.

(ID:45311774)