© 36clicks, 123RF

Mit einer überarbeiteten und schnelleren Engine geht die neue Version 2.0 der in Python geschriebenen Orchestrierungssoftware Ansible an den Start. Reicht das für eine Pole Position?

Der Name Ansible stammt laut [1] aus Ursula Le Guins Roman “Rocannon’s World” von 1966. Ihr Apparat kommuniziert in Überlichtgeschwindigkeit und ohne Verzögerung überallhin. Der Admin von heute kennt Ansible eher als Orchestrierungstool und Mitbewerber von Puppet, Chef und Salt.

Seit Ansible [2] zu Red Hat gehört (seit 2015), gibt es zwar keine großen Schlagzeilen mehr, wohl aber neue Releases. Die Neuerungen der aktuellen listet [3] auf. Eine davon bemerkt der Admin allenfalls an der Ausführungsgeschwindigkeit: Das Team hat Teile der Engine überarbeitet, die nun Playbooks und andere Yaml-Dateien schneller parst. Daneben bringt Ansible 2.0 nützliche Erweiterungen und mehr als 200 neue Module (vor allen für Open Stack und Cloud Stack sowie für Windows) mit.

Ansible gibt es in einer freien und einer kommerziellen Version. Anders als viele Konkurrenten setzt es auf den verwalteten Systemen keine Agenten, sondern lediglich einen Python-Interpreter voraus. Das vereinfacht den Start, allerdings muss der Admin Konfigurationswechsel aktiv anstoßen.

Ausführungsblöcke

Task Blocks (Abbildung 1) ermöglichen es dem Admin, zusammenhängende Aufgaben zu bündeln. Abhängig davon, ob Ansible einen solchen Block erfolgreich ausführt, stößt es im Anschluss andere Aktionen an. Dieses Vorgehen folgt dabei dem Try-Except-Finally-Mechanismus von Python (oder dem Try-Catch-Finally-Konstrukt von Java), Listing 1 zeigt ein Beispiel.

01 - hosts: test-hosts
02   tasks:
03   - block:
04     - name: Test Block
05       command: /bin/false
06       tags: gehtnicht
07     - name: Test Block 2
08       command: /bin/true
09       tags: geht
10     rescue:
11       - debug: msg="Fehler Fehler Fehler"
12     always:
13       - debug: msg="Immer Immer Immer"

Abbildung 1: Task Blocks orientieren sich am Try-Except-Finally-Mechanismus von Python.

Tritt ein Fehler auf, was im Beispiel dank des Ausdrucks »/bin/false« stets der Fall ist, greifen die Anweisungen im »rescue« -Block. Den »always« -Block führt Ansible hingegen immer aus. Das kann beispielsweise erforderlich sein, wenn es sich um Aufräumarbeiten handelt, die immer wieder nötig sind.

Neue Ausführungsstrategien

Ab Version 2.0 beeinflusst der Admin auf Wunsch, in welcher Reihenfolge Ansible Aufgaben abarbeitet. Diese Entscheidung fällte die Software bislang allein. Um etwa Konfigurationen auf eine Reihe von Hosts zu verteilen, fasste der Admin diese in Ansibles Hosts-Datei (meist »/etc/ansible/hosts« ) unter einem Namen zusammen, den das Playbook dann als Ziel seiner Aktionen auserkor. Um mehrere Schritte abzuarbeiten, wartete Ansible stets, bis für alle Hosts der Gruppe ein Ergebnis vorlag, und schritt erst dann zur nächsten Tat.

Über das eingeführte Keyword »strategy« erhält der Admin nun mehr Einfluss auf den Ablauf. Setzt er den Wert »free« ein, erledigt Ansible alle Tasks schnellstmöglich, unabhängig davon, wie weit die anderen Hosts der Gruppe sind. Verzichten sollte er darauf, wenn bei Abhängigkeiten inkonsistente Zuständen drohen.

An dieser Stelle lässt sich auch der Parameter »serial« erwähnen, der aber bereits länger existiert. Mit ihm steuert der Verwalter, wie viele Hosts Ansible zeitgleich aufs Korn nimmt. So lassen sich innerhalb von Clustern Updates anbringen, ohne dass der ganze Cluster ausfällt.

Module

Die Ankündigung nennt zudem 200 neue Module, eine vollständige Liste liefert [4]. Eine große Zahl davon betrifft Cloud Stack und Open Stack. Mit ihrer Hilfe steuert der Admin viele Verwaltungsaufgaben direkt aus einem Playbook heraus (etwa das Anlegen von Netzen, Images und so weiter). Einen ähnlichen Satz an Modulen stellt die 2.0 auch für VMware-Umgebungen bereit, die VMwares V-Center nutzen. Lässt der Admin die Cloud nicht “im Haus”, sondern bei Amazons Web Services laufen, helfen entsprechende AWS-Module weiter. Auch ein neues Docker-Connection-Plugin hat Ansible 2.0 an Bord.

Über die Module rollt der Admin nicht nur einzelne VMs, sondern ganze virtuelle Rechenzentren aus, inklusive virtueller Netzwerke und der passenden Sicherheitseinstellungen. Da alle Module ähnliche Funktionen aufweisen und somit abstrahieren, verwaltet er mit etwas Geschick die Hypervisoren unabhängig und lässt Ansible abstrakte Konfigurationen auf konkrete Hypervisoren übersetzen. Wer auch Windows-Maschinen unter seiner Fuchtel hat, erhält einen Satz Module zur Pflege des Internet Information Server (IIS) sowie einige Parameter zu Firewallregeln oder Windows-Updates.

Kleinere Häppchen

Mit bestimmten Tasks verbundene Dateien (Includes) band Ansible bislang bereits während des Parsens ein, nach Art des C-Präprozessors. Oft stieß schon der Parser auf Inkonsistenzen. Die neue Version 2.0 liest die Dateien erst ein, wenn Ansible sie abarbeitet. Das kann zu Problemen mit Schleifen führen, die über alle Interfaces laufen sollen. Ansible weiß nicht im Voraus, welche Aufgaben in einer noch auszuwertenden Include-Datei warten. Die Entwickler wollen das Problem, das sich auch auf Tags auswirkt, in den nächsten Releases beheben.

Eine Flag namens »delegate_facts« ergänzt neuerdings das »delegate_to« -Kommando. Letzteres macht es möglich, Fakten von einem anderen Host zu importieren. Das ist etwa von Interesse, wenn der Admin auf Host A für eine Konfigurationseinstellung die IP-Adresse von Host B benötigt. Ohne die neue Flag landen diese Daten in den Fakten des bearbeiteten Hosts. Setzt er die Flag »delegate_to« auf »True« , greift er dagegen auf »hostvars[‘B’]« zu, das diese Fakten sonst nicht erhalten würde.

Nicht zuletzt schlägt Ansible in externen Dateien Parameter nach. Das betraf bislang CSV-Dateien, seit Version 2.0 durchsucht Ansible auch INI-Dateien. Diese bestehen in der Regel aus von eckigen Klammern umrandeten Abschnitten und Schlüssel-Wert-Paaren. Für die INI-Datei aus Listing 2 ergibt der Aufruf

01 [foo]
02 bar=1
03
04 [test]
05 schluessel=wert

{{ lookup('ini', 'schluessel section=test file=test.ini') }}

den String »wert« . Auch die in Java verfassten Properties-Dateien lassen sich so verwenden. Sie bringen zwar keine Abschnitte mit, dafür steht im Aufruf statt des »section=test« einfach »type=properties« .

Inkompatibilitäten

Die vollständigen Release Notes unter [5] weisen auf viele “API changes” hin. Worin diese Änderungen im Detail bestehen, führen die Entwickler allerdings nicht weiter aus. Lediglich zum Einsatz von Backslashes zum Escapen gibt es einen Abschnitt. Danach sind vierfache Backslashes nicht mehr nötig. An anderer Stelle ist von den APIs für Callback-, Connection-, Cache- und Lookup-Plugins die Rede.

Im Schnelltest fiel außerdem auf, dass ein vom Autor häufig benutztes Junos-Modul zur Konfiguration von Juniper-Devices bereits an der Junos-Versionsnummer scheiterte (Abbildung 2). Mit der Version 1.9.4 funktionierte es am selben Gerät hingegen tadellos, ein Testlauf aller Playbooks sei vor einer Migration also angeraten.

Abbildung 2: Wer mit Version 2.0 liebäugelt, sollte vorher einen Testlauf mit den Playbooks starten.

Fazit

Insbesondere zum Einsatz in Cloudumgebungen bringt Ansible 2.0 viele neue Module mit, die dem Admin das Leben erleichtern können. Auch die zu erwartenden Geschwindigkeitssteigerungen sowie die Möglichkeit, zu bestimmen, wann Ansible welchen Host einer Gruppe im Playbook berücksichtigt, sind spürbare Verbesserungen.

Admins, die Ansible bereits einsetzen, sollten vor einem Upgrade in einer Testumgebung allerdings erst einmal ihre Playbooks (und ebenso die zusätzlich installierten Module) durchtesten, da es aufgrund der spärlich dokumentierten API-Änderungen zu Inkompatibilitäten kommen kann.