© Andriy Popov / 123RF.com

Der leistungsfähige Automatisierer Ansible kommt ohne Allüren daher. Er verzichtet auf eine komplexe Syntax und dokumentiert sich selbst. Den Vergleich mit Puppet & Co. braucht er nicht zu scheuen.

2014 war die Welt der Automation unter Linux noch eine andere als heute. Der Autor dieses Artikels hatte gerade frisch eine Stelle in Berlin angetreten, bei der es um den Bau einer OpenStack-Plattform ging. Im Unternehmen gaben die Puppet-Fans den Ton an, und so sollte auch die OpenStack-Cloud ein Werk von Puppenspielern sein. Doch OpenStack war damals weit vom heutigen Reifegrad entfernt, und die von den Entwicklern dafür feilgebotenen Module glichen eher einem großen Chaos als einer produktiv einsetzbaren Lösung. Was das im Alltag der Plattformentwicklung bedeutete, trat bald äußerst unangenehm zutage.

Die Art der Puppet-Nutzung, die die OpenStack-Entwickler vorgaben, war ineffizient und langsam. Ehe Puppet überhaupt anfing, etwas auf Systemen zu ändern, vergingen etliche Minuten. Im schlechtesten Fall produzierte der Vorgang am Ende einen Fehler, der eine ganze Stunde Puppet-Laufzeit in die Tonne trat (Abbildung 1). Die Nutzung von Puppet bot wenig Komfort, da die OpenStack-Entwickler die Versionierung ihrer Module nicht im Griff hatten, die einzelnen Module jedoch wild aufeinander referenzieren ließen.

Abbildung 1: Komplexe Suites wie Puppet, Chef oder andere benötigen so viele Ressourcen, dass manchmal sogar der OOM-Killer anspringt. Quelle: Geoff Williams

Obendrein erwies sich das Vorbereiten von Konfigurationen für Dienste als extrem mühsam: Puppet wollte seine Konfiguration über die eingebaute Key-Value-Komponente Hiera beziehen. Dabei bemühten sich die Entwickler, jeden konfigurierbaren Parameter aus OpenStack in Puppet und mithin auch in Hiera abzubilden. Deswegen übersetzte man früher oder später ganze OpenStack-Konfigurationsdateien aus dem INI-Format in YAML für Hiera. Der im Linux-Magazin seither gelegentlich benutzte Begriff der “YAML-Schaufeln” wurde in eben jener Zeit geboren.

Doch nicht nur die Puppet-Konfiguration war verbesserungswürdig, sondern auch deren Feature-Set im Hinblick auf OpenStack: Das Prozedere “Erledige auf Host A dieses, dann auf Host B jenes und schließlich auf Host C das Nächste” war mit Puppet schlechterdings nicht abzubilden. Es war für das OpenStack-Deployment aber von zentraler Bedeutung, etwa für Galera.

“Ansible? WTF?”

Es war ein Kollege des Autors, der seinerzeit Ansible ins Spiel brachte. Das war zu jenem Zeitpunkt gerade zwei Jahre alt und mithin weit von seinem aktuellen Feature-Umfang entfernt. Wo Puppet eher schockierte, vermochte Ansible auf Anhieb zu begeistern. Das lag an der Einfachheit seiner Benutzung, an der Art und Weise, wie es Verschachtelung unattraktiv machte, und an der Methode, wie es sich quasi selbst dokumentierte. Anstelle einer riesigen YAML-Schaufel ließ Ansible einfach die Möglichkeit zu, ein Template für die Konfiguration mit allen gewünschten Parametern zu hinterlegen. Darin waren nur Host-spezifische Einträge dynamisch auszutauschen, etwa die IP-Adressen.

Dieser Artikel stellt Ansible und seine grundlegenden Fähigkeiten vor. Außerdem zeigt er, wie man diese nutzt und welche Komponenten um Ansible herum Admins das Leben zusätzlich erleichtern. Am Ende wagt der Text noch einen Ausblick auf Ansibles Zukunft unter Red Hat als aktuellem Eigentümer.

Begrifflichkeiten

Wie bei jedem Automatisierer hat sich bei Ansible mittlerweile eine Art Fachsprache herausgebildet, die interessierte Admins kennen sollten, bevor sie das Abenteuer Ansible beginnen. Da dieser Artikel ohne diese Begriffe und das Wissen um sie nur schwer verständlich wäre, gehen wir hier auf sie ein.

Zentrale Bedeutung hat der Begriff Inventory. Das Inventar erfasst die Zielsysteme, auf denen Ansible Befehle ausführt, sobald der Admin die Anweisung dazu erteilt. Das erledigt er mittels eines Playbooks. Es führt neben den Host-Definitionen aus dem Inventar, auf das das jeweilige Playbook sich bezieht, auch die aufzurufenden Rollen auf. Eine Rolle wiederum besteht aus einer Liste abzuarbeitender Tasks sowie mit dieser Aufgabe verbundener Konfigurationsdateien und -Templates sowie Handlern, also Diensten, die nach einer Konfigurationsänderung neu starten oder andere, Event-getriebene Aufgaben erledigen.

Das Dreigespann aus Inventar, Playbook und Rolle genügt, um Ansible auf einem spezifischen Host Aufgaben erledigen zu lassen – fast: Unter der Haube arbeiten bei Ansible die sogenannten Module, die bestimmte Arbeitsschritte erledigen. Sie sind so feingliedrig wie möglich gestaltet; der Administrator ruft sie aus seinen Playbooks heraus auf. Bei Bedarf kann er auch eigene Module schreiben. Doch dank Ansibles bereits ab Werk enormen Funktionsumfangs ist das meist gar nicht mehr nötig.

Simples SSH statt Client-Server

So simpel die Voraussetzungen sind, um Ansible an den Start zu bringen, so simpel gestaltet sich auch die Architektur der Lösung. Andere Automatisierer setzten früh auf Client-Server-Protokolle und verlangen nach entsprechenden Diensten sowohl auf dem zentralen Managementserver als auch auf den Zielsystemen. Ansible war von Anfang an anders konzipiert: Es nutzt das etablierte und hochperformante SSH-Protokoll (Abbildung 2), um auf anderen Systemen Befehle auszuführen.

Abbildung 2: Ansible setzt im Hintergrund auf SSH und braucht keinen eigenen Agenten auf den Zielsystemen. Das skaliert sehr gut.

Dadurch erbt es eine Menge an Vorteilen, aber auch manche Nachteile: Nutzer können per SSH etwa auf Systemen Befehle ausführen, wenn ihr eigener SSH-Schlüssel dort hinterlegt ist und das Forwarding im SSH-Agenten funktioniert. Zudem müssen sie mittels Sudo auf dem betroffenen System die Rechte des Systemadministrators erlangen können. Damit die Performance passt, kopiert Ansible zudem jene Module, die es auf den Zielsystemen ausführen soll, zuvor per Scp auf diese. Wo bei Puppet und Chef also der jeweilige Automationsserver erst einmal rödelt, um die Module für alle Zielrechner auszuführen, verteilt Ansible diese Aufgabe auf die Systeme selbst. Das skaliert naturgemäß deutlich besser.

Mit Ansible loslegen

Dem Fehlen einer Client-Server-Architektur ist auch zu verdanken, dass aus Sicht des Admins der Einstieg in Ansible schnell vonstatten geht. Gegeben sei ein Benutzer mit SSH-basiertem Login auf allen Systemen und der Erlaubnis, Sudo ohne Password auszuführen. Auf einem beliebigen System, das an die anderen Systeme per SSH herankommt, installiert der Admin danach das für seine Distribution vorgesehene Ansible-Paket. Weil Ansible mittlerweile eine sehr weite Verbreitung erreicht hat, stehen für alle gängigen Linux-Systeme Pakete zur Auswahl. Danach sollte der Aufruf »ansible-playbook« zu einem entsprechenden Hilfetext führen.

Im nächsten Schritt steht das Erstellen eines Inventars auf dem Plan. Das hinterlegt der Admin wahlweise im YAML- oder im INI-Format. Es unterteilt sich in Host-Gruppen, deren Namen jeweils die Überschrift eines Blocks angibt. Die Datei aus Listing 1 legt also ein Inventar mit zwei Host-Einträgen an, die zur Gruppe »lmtest« gehören. Die Direktive »ansible_user« weist Ansible an, sich am Host als Nutzer »mloschwitz« anzumelden.

<pre>
[lmtest]
server1.local ansible_user=mloschwitz
server2.local ansible_user=mloschwitz
<pre>

Das Kommando »ansible -i Datei all -m ping« führt anschließend einen Ping auf sämtliche Hosts aus dem Inventory aus. Dabei gibt »Datei« den Namen der Inventardatei an – im Normalfall heißt sie »hosts«.

Die Verzeichnisstruktur

Die Ansible-Entwickler geben in der Dokumentation [1] einen guten Einblick, wie der Admin das Ansible-Verzeichnis idealerweise gestaltet. Das Beispiel sieht einen Ordner vor, in dem eine Datei namens »hosts« liegt. Das erste Playbook – im Beispiel einfach »lmtest.yml« – platziert der Admin auf derselben Verzeichnisebene, ebenso wie eine Ansible-Vault-Datei (dazu später mehr). Große Bedeutung kommt zwei zusätzlichen Ordnern zu, »host_vars/« und »group_vars/«. In Letzterem legt der Admin Dateien an, deren Namen mit den im Inventar definierten Gruppen übereinstimmen. Die Gruppe im Beispiel heißt »lmtest«, also ließen sich für diese Gruppe in der Datei »group_vars/lmtest« Variablen definieren. In »host_vars/« hinterlegt der Admin Dateien für die einzelnen Hosts, etwa »server1.local.yml«. Dabei ist es wichtig, stets den vollen Hostnamen zu verwenden, wie er im Inventar steht. Andernfalls stellt Ansible die Verbindung zwischen der Datei und dem Host nicht her und scheitert mit einer Fehlermeldung, weil Variablen nicht definiert sind.

Der letzte benötigte Ordner ist der wichtigste: »roles/«. Darin legt der Admin Rollen an, die einzelne Arbeitsschritte auf den Zielsystemen ausführen. Zwar könnte er die Rollen Aufgaben auch unmittelbar in die Playbooks schreiben, das wird mit der Zeit allerdings unübersichtlich. Es hat sich deshalb eingebürgert, Rollen zu schreiben, die logisch zusammenhängende Aufgaben auf den Servern des Setups abwickeln. Im Ordner »roles/« finden sich dann Unterordner mit den Namen der Rollen, etwa »lmtestrolle«. Auch diese Ordner haben eine spezifische Struktur.

Der wichtigste Ordner einer Rolle heißt »tasks/«. Darin gibt es zumindest eine Datei namens »main.yml«, die wahlweise Includes auf andere Dateien im selben Verzeichnis enthält oder direkt die gewünschten Tasks. Die Aufgabe, ein Paket auf einem Zielsystem zu installieren, würde in der Datei »lmtestrolle/tasks/main.yml« etwa so aussehen, wie in Listing 2 gezeigt.

<pre>
- name: Install helloworld
  package:
    name: hello-world
    state: present
<pre>

Task-Einträge sowie generell alle Einträge in Ansible folgen einem ähnlichen Muster. Hinter »name« folgt eine kurze Beschreibung, danach das aufzurufende Modul und schließlich dessen Parameter. Die Struktur einer Rolle in Ansible ähnelt damit jener eines Shell-Skripts, was die Einstiegshürden für Automatisierungsneulinge erheblich senkt. Durch den zwingend nötigen »name«-Eintrag dokumentieren Ansible-Rollen sich zudem zumindest teilweise selbst. Das macht sie auch für andere Personen als den Autor selbst verständlich .

Das dargestellte Beispiel deckt nur einen Bruchteil der Funktionalität von Ansible ab. Im Ordner »tasks/« innerhalb der Rolle könnte der Admin etwa Trigger definieren, die Dienste starten, stoppen oder neu starten. Mittels »notify«-Parameter im Task könnte er den definierten Trigger anschließend aufrufen. Ebenso wichtig sind gegebenenfalls die Ordner »templates/« sowie »files/«. In Letzterem landen Dateien, die unverändert ihren Weg auf die Systeme finden sollen. Dagegen enthält »templates/« an verschiedenen Stellen Platzhalter, die Ansible vor dem Ausrollen auf einen Host dynamisch durch den für den Host zutreffenden Wert ersetzt. So braucht der Admin nur ein Template, um auf mehreren Hosts die Konfigurationsdatei mit der passenden IP für den jeweiligen Host auszurollen.

Vordefinierte Variablen

Um dem Administrator genau das zu erleichtern, definiert Ansible eine Vielzahl von Umgebungsvariablen pro Host. Im Ansible-Jargon heißen diese Facts, der Zugriff funktioniert jedoch wie der auf normale Variablen.

Eine oft genutzte Variable ist beispielsweise »ansible_distribution«. Sie verrät dem Admin im Modul, ob er es mit einem Debian, einem Ubuntu, einem CentOS oder einer Suse zu tun hat. Mithilfe des »ansible_distribution_version«-Fakts lässt sich zusätzlich noch die spezielle Version überprüfen. Die Stellen, an denen »when«-Bedingungen möglich sind, führt Ansible nur dann aus, wenn die in der Bedingung festgelegten Kriterien zutreffen.

Mittels der beschriebenen Fakten könnte ein Admin die Rolle also so gestalten, dass Ansible bestimmte Aufgaben nur auf spezifischen Distributionen ausführt. Das macht die Arbeit mit Ansible in einer heterogenen Umgebung viel einfacher.

Kompaktes Playbook

Nutzt der Admin wie empfohlen Rollen, bleibt das eigentliche Playbook sehr kurz. Es definiert nur die Host-Gruppe, auf die es sich bezieht, und die Rollen, die es darauf anwendet (Listing 3). Anschließend lässt sich das Playbook mittels »ansible-playbook -i hosts playbook.yml« aufrufen. Der Task aus dem Beispiel würde dazu führen, dass auf allen Zielsystemen anschließend »hello-world« installiert ist.

<pre>
- hosts: infra
  become: yes
  roles:
    - lmtestrolle
<pre>

Dynamisches Inventory

Kritiker wie Befürworter attestieren Ansible, eine seiner größten Stärken ergebe sich bei der Kompilation seines Inventars. Die einfachste Variante, ein solches zu bauen, ist die gute alte Textdatei im Hauptordner der Ansible-Installation. Das bietet jedoch nicht sonderlich viel Flexibilität, und gerade in dynamischen Umgebungen wie Clouds stößt der Admin mit diesem Ansatz bald an seine Grenzen. Ansible bietet deshalb die Möglichkeit des dynamischen Inventars (Dynamic Inventory), wobei »ansible« oder »ansible-playbook« das Inventory-File erst zur Laufzeit aus verschiedenen Quellen zusammenstellt.

Besonders profitieren von diesem Prinzip die Setups, in denen es ohnehin eine zentrale Single Source of Truth mit Informationen über sämtliche Systeme gibt. Wer beispielsweise Cobbler für das Bare-Metal-Deployment nutzt, generiert mittels eines eigenen Python-Skripts [2] das Inventar aus der Host-Liste der in Ansible hinterlegten Systeme. Wer OpenStack verwendet, sei es als Werkzeug zum Verwalten von Bare-Metal-Systemen oder für den Betrieb virtueller Maschinen, bekommt die Liste der Zielinstanzen mittels des Skripts »openstack_inventory« [3] direkt aus der OpenStack-API.

Noch ein Quäntchen eleganter ist es, Ansible direkt mit einem DCIM-Werkzeug wie Netbox zu verbinden. Ein DCIM-Tool (Datacenter Inventory Management) listet ja per Definition die vorhandenen Server auf. Da insbesondere Netbox eine komplett maschinell auslesbare API enthält, fällt das Herstellen einer Verbindung hier besonders leicht. Ein beispielhaftes Netbox-Skript [4] für Ansibles dynamisches Inventar verdeutlicht das.

Infrastructure as Code

Wer für seine Automation lediglich ein paar Ansible-Rollen schreibt oder ein paar fertige Rollen aus dem Netz miteinander kombiniert, erhält ein einigermaßen übersichtliches, aber trotzdem sehr mächtiges Ansible-Verzeichnis. Im Sinne von Infrastructure as Code sei die dringende Empfehlung ausgesprochen, das gesamte Ansible-Verzeichnis in einem Git-Repository zu verwalten, denn das bringt eine Reihe von Vorteilen.

Einerseits etabliert man für den genutzten Code automatisch eine Single Source of Truth, indem man bestimmt, dass HEAD dieses Git-Verzeichnisses immer der in Produktion ausgerollte Zustand sein muss. Andererseits macht ein in Git verwaltetes Ansible-Verzeichnis es leicht, als Team daran zu arbeiten und Änderungen nachzuvollziehen.

Ansible-Playbooks und -Rollen müssen laut Definition immer idempotent geschrieben sein. Lässt man Ansible zehn Mal auf seine Systeme los, muss also zehn Mal am Ende ein funktionsfähiges System vorliegen, das die in Ansible verankerten Schritte erfolgreich abgearbeitet hat. Vertut man sich bei der Arbeit mit Ansible einmal, kann man bei Vorliegen eines Git-Verzeichnisses sehr leicht Änderungen revidieren und Ansible nochmals laufen lassen. Das stellt im Normalfall den vorherigen Zustand wieder her und löst durch eine (temporäre) Fehlkonfiguration entstandene Probleme.

Umgang mit Passwörtern

Früher oder später bekommt es der Administrator im Rahmen seiner alltäglichen Arbeit mit Passwörtern zu tun. Die sollen die Automation zwar nicht ausbremsen, doch sie im Klartext in irgendwelchen Ansible-Playbooks zu speichern, ist keine Option.

Das gilt umso mehr, wenn die Ansible-Playbooks wie vorgeschlagen in einem zentralen Git-Verzeichnis liegen, auf das viele Menschen Zugriff haben. In vielen Unternehmen schließt das Compliance-Regime eine solche Situation ohnehin aus: Im Rahmen von Separation of Concern dürfen Teams vielerorts gar keinen Zugriff auf andere Daten haben als jene, die sie für die eigene Arbeit zwingend benötigen. Posaunt ein Team aber Passwörter der eigenen Infrastruktur ins Git-Verzeichnis, auf das die gesamte Firma zugreift, ist kein Schutz mehr gegeben.

Die Ansible-Entwickler kennen das Problem und begegnen ihm mit Ansible Vault. Der Name ist insofern etwas unglücklich gewählt, als er mit HashiCorp Vault kollidiert. Zwar gibt es ein Ansible-Community-Modul, das Ansible direkt an HashiCorp Vault anbindet; mit Ansible Vault hat das jedoch nichts zu tun. Das kleine Werkzeug Ansible Vault verschlüsselt eine vom Admin angelegte Textdatei so (Abbildung 3), dass Ansible sie wie jede andere Variablendatei auslesen kann.

Abbildung 3: Ansible Vault ermöglicht das Speichern von Passwörtern in verschlüsselter Weise – so lassen sie sich in Git verwalten.

Sobald der Admin Ansible installiert hat, steht auch »ansible-vault« als Kommando auf der Shell zur Verfügung. Mittels »ansible-vault create passwords.yml« lässt sich ein Tresor für Passwörter anlegen. Darin definiert der Administrator dann seine Passwörter als Variablen, etwa »ldap_admin_password: sehrgeheim«. Aus seinen Rollen und Playbooks greift er danach auf die Variable zu wie auf jede andere auch. Beim Aufruf von Ansible fügt er dem Kommando allerdings ein »–vault-id« hinzu, um auf die Passwortdatei zu referenzieren.

Auch für Zertifikate

Der Vault-Mechanismus eignet sich nicht nur für Passwörter, sondern auch für andere vertrauliche Inhalte, wie etwa die SSL-Schlüssel, die zu Zertifikaten gehören. Soll ein Webserver mit aktiviertem SSL ohne automatisches Let’s Encrypt ausgerollt werden, benötigt er in der Regel den zum Zertifikat passenden Schlüssel ohne gesetztes Passwort.

Das klappt mit Vault ganz leicht: Per »ansible-vault encrypt key.pem« verschlüsselt der Admin zunächst den Schlüssel des Zertifikats. Die kodierte Datei platziert er im »files/«-Unterordner der Rolle, die das Zertifikat ausrollt. Per Content-Direktive im Playbook greift er dann auf die verschlüsselte Datei zu. Hat er »ansible-playbook« den Tresor mittels »–vault-id« mit auf den Weg gegeben, entschlüsselt Ansible beim Playbook-Aufruf den Tresor automatisch und nutzt den Inhalt der Datei.

Ansible Tower

Dass Ansible nicht auf ewig das kleine, schnörkellose Automationswerkzeug der ersten Stunde bleiben würde, war zu befürchten. Red Hat als neuer Eigentümer der Lösung bemüht sich allerdings nach Kräften, Änderungen behutsam durchzuziehen und sie obendrein so zu gestalten, dass Administratoren sie nicht zwangsläufig benutzen müssen. Parallel dazu versucht der Hersteller, ein Portfolio um Ansible herum aufzubauen, das für die eigene Kundschaft zusätzliche Funktionen bietet. Ansible Tower, das auf der Open-Source-Software Ansible AWX basiert, ist dafür ein gutes Beispiel.

Im Kern ist Tower einerseits eine REST-API und andererseits eine grafische Benutzeroberfläche (Abbildung 4) samt eigener Benutzer- wie Rechteverwaltung, über die sich Ansible auf einer Vielzahl von Zielsystemen komfortabel steuern lässt. Zudem lässt Tower sich auch an bestehende Benutzerverzeichnisse wie LDAP ankoppeln. Es bildet eine Art Frontend für den schnellen Zugriff auf das gesamte Ansible-Setup eines Unternehmens. Aus Tower heraus kann man neue Playbooks und Rollen in das Setup integrieren, auf Hosts ausführen und in CI/CD-Toolchains integrieren. Zudem lassen sich in Tower wiederkehrende Tasks definieren, die Tower dann automatisch in den festgelegten Intervallen ausführt.

Abbildung 4: Ansible Tower funktioniert als REST-API und GUI zu Ansible. Es macht das Management großer Ansible-Setups übersichtlicher. Quelle: Red Hat

Ein besonderes Feature neuerer Tower-Versionen stellt die nahtlose Integration mit diversen Public-Cloud-Providern dar. Ansible selbst bringt Module für etliche Clouds mit, darunter Amazon EC2 und Microsoft Azure. Die aus Tower heraus ausgerollten Cloud-Workloads kann das Tool anschließend selbst visualisiert darstellen und im Rahmen seiner Möglichkeiten auch überwachen (Abbildung 5).

Abbildung 5: Zusätzlich zur Fähigkeit, Ansible-Workloads zu starten, hat Tower einen Auto-Run-Modus und zeichnet Aktionen Compliance-konform auf. Quelle: Red Hat

Umsonst, so sagt man, ist aber nur der Tod, und selbst der kostet das Leben. In Form von Tower versucht Red Hat erstmals prominent, aus dem Ansible-Zukauf zusätzlichen Umsatz zu generieren. Wie für andere Managementwerkzeuge braucht der Admin auch für Tower eine eigene Subskription. Für die Premium-Variante fallen laut diverser Quellen im Netz dabei Kosten von rund 14 000 US-Dollar pro Jahr an. Das ist nicht gerade ein Schnäppchen; Unternehmen tun insofern gut daran, Ansible Tower vor dem Kauf ausgiebig zu evaluieren.

Quo vadis, Ansible?

Man mag kaum glauben, dass schon wieder fünf Jahre ins Land gezogen sind, seit Red Hat sich Ansible einverleibt hat. Das gilt vor allem, weil die roten Hüte bisher bei Ansible gar nicht so viel verändert haben, wie man erwarten könnte oder es anhand anderer Red-Hat-Käufe vorhergesagt wurde. An manchen Stellen merkt man zwar, dass Red-Hat-Ziele die To-do-Liste für den Automatisierer dominieren, doch in Summe wirkt es so, als könnten dessen Entwickler weiterhin weitgehend frei schalten und walten.

Entsprechend hat das Ansible-Team auch seinen Modus Operandi beibehalten, die Feature-Planung auf den Zeitraum zwischen zwei Major-Releases zu beschränken. Das zu Redaktionsschluss noch aktuelle Major-Release von Ansible war 2.10, bei Erscheinen dieser Ausgabe dürfte wohl aber schon die Version 3.0 das Licht der Welt erblickt haben. Eine Vision für die Ansible-Entwicklung innerhalb der kommenden Jahre gibt es insofern nicht. Stattdessen reagieren die Entwickler der Automationslösung gern auf Feature Requests wahlweise direkt von Red Hat oder aus den Reihen der Nutzer.

Vorhersagen lässt sich mit einiger Sicherheit für Ansible nur, dass Red Hat das Produkt weiterhin als ein wichtiges Asset im Kontext seiner eigenen Produkte betrachten und behandeln wird. Für Ansible-Fans bedeutet das, dass momentan nicht mit allzu tiefgreifenden Veränderungen im Design der Software oder in der Art, wie die Ansible-Entwicklung verläuft, zu rechnen ist.

Fazit

Ansible besticht weder durch einen riesigen Funktionsumfang noch durch ausgefallene Technologie oder waghalsige Features mit tollen Automatismen. Stattdessen präsentiert sich das Tool vor allem als ehrlicher Automatisierer: Wer aus einer Welt von Bash- und Shell-Skripten kommt, findet hier am leichtesten den Einstieg in das Thema. Die Tatsache, dass Ansible-Rollen sich fast zwangsläufig selbst dokumentieren, erleichtert die Arbeit mit dem Werkzeug zusätzlich.

Hinzu kommen weitere Bonuspunkte für die Software: Es gibt eine Reihe von Integrationen in externe Werkzeuge, das Inventory lässt sich als Textdatei pflegen oder dynamisch generieren, und das Erweitern von Ansible stellt selbst einfache Admins nicht vor Probleme. Somit können auch in Sachen Automation wenig erfahrene Admins mit Ansible ruckzuck Automation in ihre Umgebungen einführen. Ansible sei daher allen ans Herz gelegt, die einen Einstieg in die Automation suchen oder einen Automatisierer mit wenig Lametta präferieren. (jcb/jlu)