Erfahrungen mit Ansible

Seit mehreren Jahren bauen wir für unsere Kunden hochverfügbare Cluster mit Pacemaker und Corosync. Zwei physische Server mit Red Hat Enterprise Linux 7 und mehrfach redundanter Verkabelung bilden einen High-Availability-Cluster, auf dem virtuelle Maschinen laufen. Mit DRBD wird einfach und kostengünstig hochverfügbarer Speicher realisiert. Um die Kosten gering zu halten und einen hohen Automatisierungsgrad zu erreichen, bedienen wir uns Ansible.

Folgende Punkte konnten wir unter Lessons-Learned verbuchen.

Gewählte Datentypen

Zu Beginn haben wir einige Überlegungen angestellt, wie wir unsere Projektinformationen im Variablen-File repräsentieren. Benutzen wir zum Beispiel Listen, um unsere VM’s abzubilden oder benutzen wir Dictionaries?

Listen:

Dictionaries:

Über Listen lässt sich leicht loopen und über Dictionaries lassen sich leicht einzelne Elemente ansprechen. Schlussendlich konnten wir jedoch bei jedem Datentypen die gwünschten Informationen auslesen.
Nach unserer Erfahrung nach, ist es effizienter sich früh für einen Datentypen zu entscheiden und einen Weg konsequent zu verfolgen, als von Beginn weg viel Zeit aufzuwenden, um den besten Datentyp abzuschätzen. Alles hat Vor- und Nachteile!

Idempotenz

Unsere Playbooks stellen kein klassisches Konfigurations-Management dar, das zyklisch angewandt wird. Unsere Absicht ist es einzelne Arbeitsschritte automatisiert auszuführen. Ist der gewünschte Endzustand des Systems erreicht, gelangt dieses zum Kunden und ist unserem Einfluss entzogen. Aus diesem Grund ist es für uns vertretbar, dass es Tasks gibt, die bei jeder Ausführung den Status «changed» haben – auch wenn sich das System bereits im Zielzustand befindet. Wir haben gewisse Arbeitsschritte mit dem Command-Modul realisiert, da es keine passenden Ansible-Module dazu gab und das Schreiben solcher im Projektumfang nicht enthalten war. Beispiele hierzu sind das Konfigurieren des IPMI’s mittels ipmitool oder das Initialisieren von DRBD-Resourcen mittels drbd-admin Befehlen. Diese Tasks sind nicht idempotent, erfüllen aber ihre Aufgabe perfekt.

Ansible-Module können viel aber nicht alles

Die Stärke von Ansible ist unter anderem die grosse Fülle an qualitativ hochwertigen Modulen. Wir mussten aber auch einsehen, dass diese nicht alle unsere Konfigurationswünsche abdecken konnten. Unser Setup verlangte es, dass auf den Hypervisors jeweils zwei Netzwerkinterfaces zu einem Bonding zusammengeführt werden. Dieses Bond-Device wiederum wird an ein Bridge-Interface gehängt. Mit dem nmcli-Modul von Ansible können alle Typen konfiguriert werden: ethernet, bond, bond-slave, bridge, bridge-slave. Es lässt sich aber leider nur ein Typ konfigurieren. Da unser Bond-Interface aber gleichzeitig auch ein Bridge-slave ist, mussten wir schlussendlich die Konfiguration der Netzwerkinterfaces über das Erstellen der Ifcfg-file’s mittels Templates realisieren. Das Gute ist, das die Ansible-Module opensource sind und bei vorhandener Zeit und Knowhow jederzeit erweitert werden können.

Ansible yum-Modul auf subskribierten Systemen

Ein bisher ungelöstes Problem besteht aus der langen Dauer von Tasks, die mittels dem Ansible yum-Modul Pakete installieren. Dabei ist die lange Dauer darauf zurückzuführen, dass die RHEL-Systeme mittels Subscription-manager bei Red Hat registriert sind. Führt man den Task auf unsubskribierten Systemen durch, erfolgt die Installation vergleichbar schnell mit dem direkten Ausführen der entsprechenden yum-Befehle.

Unser Fazit zum Gebrauch von Ansible gleicht der berühmten Aussage von Bruce Lee: Absorb what is useful!