Ansible – einfach und elegant, doch etwas sperrig Einstieg ins Configuration Management mit Ansible

Anbieter zum Thema

Red Hat GmbH

Windhoff Group

Die angenehm altmodische Open-Source-Lösung Ansible vereinfacht die Konfiguration entfernter Systeme und sollte in keinem Developer-Arsenal fehlen. Hier eine Einführung bis zum ersten konkreten Einsatz.

Ansible hat bereits stolze elf Jahre auf dem Buckel, die letzten sechs davon als Teil des Red-Hat-Line-ups. Es gibt Ansible als SaaS-Angebot, just startete eine KI-unterstützte Version, viele Projekte spendieren ihren Nutzern Ansible-Sammlungen – mit anderen Worten: Ansible ist ebenso aktiv wie verbreitet.

Wer sich mit Administration, DevOps, Entwicklung und dergleichen befasst, wird früher oder später auf dieses mächtige Werkzeug treffen. Der Einstieg fällt allerdings teils ein wenig schwer; und wer Ansible zunächst in der Praxis antrifft, in Form einer Ansible Collection zum Beispiel, könnte sich von den Ordnerstrukturen, den vielen Dateien und nicht zuletzt den Begrifflichkeiten erschlagen fühlen.

Dabei ist Ansible im Grunde einfach zu erklären: Man kann von einer zentralen Position aus Skripte auf anderen Rechnern im Netz ausführen, um diese zu konfigurieren. Klingt nach SSH? Das ist gar nicht so falsch, Ansible arbeitet grundlegend genauso, wie es Admins ganz traditionell tun: Es verbindet sich per SSH mit einem Rechner und führt dort Konfigurationsskripte aus.

Damit Ansible als Automatisierungsplattform durchgeht, kommt natürlich allerhand Abstraktion hinzu. So müssen Systeme nicht einzeln angesteuert werden, stattdessen gibt es Inventare von betroffenen Rechnern. Überdies müssen Skripte nicht für unterschiedliche Zielsysteme und Konfigurationen angepasst werden, stattdessen liegen die Nutzerdaten in separaten Dateien. Zudem lassen sich Skripte und Nutzerdaten auf unterschiedliche Arten organisieren und miteinander verknüpfen.

Ansible bringt keine Magie in die Konfiguration entfernter Systeme, sondern simuliert die händische Arbeit von Admins und fügt ein wenig Stapelverarbeitung hinzu. Das mag nun fast zu einfach klingen, um weiterzulesen. Aber vielleicht können Sie ein paar unumgängliche Begriffe überzeugen: YAML, Playbook, Play, Modul, Task, Role – und nicht alles ist, was man beim Namen intuitiv erwarten würde.

Das Ansible-Konzept

Bei Ansible lohnt es sich, die Erklärung ganz unten in der Kette zu beginnen. Damit Sie aber zunächst eine Übersicht bekommen, hier eine beispielhafte Struktur innerhalb von Ansible:

Schon ist es mit der Einfachheit ein Stück weit vorbei. Los geht es auf der untersten Ebene:

Module sind die eigentlichen Skripte (oder Ansible-interne Befehle, etwa zum Installieren von Paketen), die für die Konfiguration auf den entfernten Systemen zuständig sind. Diese können in beliebigen Sprachen geschrieben werden. Skripte werden in der Regel ja mit irgendwelchen Variablen aufgerufen. In Ansible können solche Variablen für einzelne Module oder Gruppen von Modulen gesetzt werden.

Zusammen wird das Konstrukt dann als Role bezeichnet. Das klingt zunächst verwirrend, weil hier keine Rolle im Sinne von Nutzerrolle gemeint ist, sondern, welche Rolle die Kombination aus Variablen und Modulen für die Konfiguration eines Hosts spielt. Eigentlich sind Roles die wichtigsten Einheiten in Ansible – sie sind nämlich teil- und wiederverwendbar! Roles sind in sich abgeschlossen und bringen alle Skripte und organisatorischen Informationen mit sich, um sie mit anderen Nutzern teilen zu können.

Übergeordnet sind die Tasks: Hierin werden einzelne Module und/oder Rollen und weitere Parameter zusammengefasst. Letztlich handelt es sich also um konkrete Aufgaben, innerhalb derer Rollen/Module in der gegebenen Reihenfolge abgearbeitet werden. Mehrere Tasks wiederum können in Plays organisiert werden. Und für Plays können nun auch endlich Inventare übergeben werden: Im Inventar stehen die Rechner/Hosts, auf die das Play angewendet werden soll.

Ganz oben ergibt sich nun recht selbstverständlich der Name Playbook. Allerdings muss ein Playbook nicht zwangsläufig all diese Elemente enthalten. Ein simples Playbook könnte schlicht aus Inventarverweis und einem simplen Task (etwa „installiere foobar“) bestehen.

In einem Playbook finden sich also alle nötigen organisatorischen Informationen (Hosts, Variablen, Reihenfolge der Aufgaben) und Verweise auf die konkret anzuwendenden Skripte/Module. Ausgeführt wird es anschließend einfach auf der Kommandozeile mit „ansible-playbook mein-playbook.yml“ – und sofern die Hosts aus dem Inventar (standardmäßig) per SSH erreichbar sind, werden die Befehle dort ausgeführt.

Ein simples Playbook könnte zum Beispiel so aussehen:

Zwar handelt es sich hier nur um ein einziges Play, dennoch spricht man von Playbook. Das Modul ist hier die Ansible-interne Funktion des apt-Aufrufs, welches das Paket „foobar“ installiert, beziehungsweise für den Status „latest“ (aktuellste Version installiert) sorgt.

Die zugehörige Inventardatei (/etc/ansible/hosts) wiederum kann im einfachsten Fall schlicht die zu verwaltenden Hosts aufführen:

Natürlich können Playbooks, Inventare und Module deutlich komplexer sein. Es lassen sich etliche Variablen nutzen, Metainformationen bereitstellen, Playbooks aus Playbooks heraus aufrufen, Handler als spezielle Tasks nutzen und die über 6.600 internen Module verlangen ebenfalls nach etwas mehr Beschäftigung.

Oft verliert ein Thema aber an Komplexität, wenn man die Basics einmal durchgespielt hat – und das geht mit Ansible ziemlich fix.

Ansible in der Praxis

Die folgenden Anweisungen funktionieren auf Ubuntu Server 22.04. Insbesondere bei der Installation kann es je nach Paketmanager und dessen Version zu Abweichungen kommen. Aber zunächst müssen Sie für den SSH-Zugang ohne Passwort sorgen, sprich ein Schlüsselpaar erstellen und den öffentlichen Schlüssel auf die zu verwaltenden Hosts kopieren. Also auf dem Kontrollrechner …

… ausführen und das Ergebnis auf dem Host in die Datei „~/.ssh/authorized_keys“ kopieren.

Nun folgt die Ansible-Installation via pip:

Bei der Installation kommt die Warnmeldung, dass nicht alle Skripte im PATH liegen, was sich temporär fix erledigen lässt, indem der Installationspfad „~/.local/bin“ übernommen wird:

Testen lässt sich die Installation bis hierher mit

Anschließend benötigen wir ein Inventar in der Datei „/etc/ansible/hosts“:

Die Erreichbarkeit der Hosts lässt sich per Ping testen:

Über „-u ubuntu“ wird hier der Nutzer des Ziel-Hosts festgelegt, was natürlich nur sein muss, wenn dieser vom Rechner des Control Nodes abweicht. Und „all“ spricht schlicht alle Hosts im Standardinventar an, die dann über das ping-Modul angepingt werden.

Was hier so ganz nebenbei eingeführt wurde: Ansible kann nicht nur Playbooks ausführen, sondern auch Ad-hoc-Kommandos. Aber jetzt wird es erst interessant: Ein erstes Play/Playbook soll schlicht dafür sorgen, dass das Programm „cowsay“ auf allen Hosts im Inventar installiert wird, beziehungsweise in aktuellster Version vorhanden ist.

Der Name des Plays lässt sich freilich nach Belieben vergeben. Es folgt wieder die Angabe der betroffenen Hosts, hier also alle im Standardinventar vorhandenen. Dann wird der „remote_user“ angegeben; das ginge zwar wie bei den Ad-hoc-Kommandos über die „-u“-Option auf der Kommandozeile, sinnvoller ist die Nutzerangabe aber freilich an dieser Stelle – zumal ja ein zweites Play für Rechner mit anderen Nutzernamen folgen könnte.

Die „become“-Angabe meint „become root/superuser“, sorgt also für die nötige Rechteeskalation, um lokal via apt Pakete installieren zu können. Anschließend kann das Playbook ausgeführt werden:

Die Ausgabe zeigt deutlich, wie tief Ansible in der Techie-Szene verwurzelt ist. Cowsay sorgt hier nicht nur für ein Schmunzeln, sondern auch für Übersicht. Natürlich ließe sich so eine Installation auch via Kommandozeile erledigen:

Dieser kurze praktische Einstieg sollte genügen, um Ansibles Arbeitsweise zu verstehen – für die vielen Optionen und Module sowie Best Practices können aber schnell noch ein paar Dutzend Stunden draufgehen.

Ansible schafft jedenfalls wunderbar den Spagat aus Mächtigkeit und Schlankheit und bietet sich daher sowohl für kleine Netzwerke mit einer Handvoll Rechnern als auch für riesige Unternehmensnetze mit Tausenden Hosts an – dann allerdings könnten plötzlich weitere Hilfswerkzeuge rund um den Ansible-Kern relevant werden.

(ID:49642676)