Software mit Ansible automatisiert einrichten: So funktioniert es

[DMW007]

Die Zeiten, in denen Systeme händisch installiert werden & dadurch früher oder später Testsysteme von Produktivsystemen abweichen, sind vorbei: Ansible ermöglicht es, ein System automatisch nach Wunsch einrichten - etwa Software installieren, konfigurieren und testen, ob diese wie gewünscht funktioniert. Mit sogenannten Playbooks legt man dabei den gewünschten Zielzustand des Systems (z.B. Apache2 Webserver soll installiert & gestartet sein) fest. Ansible kümmert sich darum, diesen Zustand zu erreichen: Beispielsweise ein APT Paket installieren & den Dienst starten. So kann man nicht nur Konsistenz gewährleisten, da jedes System identisch konfiguriert wird. Sondern auch spielend leicht weitere aufsetzen, z.B. zu Testzwecken. Dieser Beitrag richtet sich an Einsteiger, er stellt Ansible mit seinen Vor- und Nachteilen vor: Zum kompletten Beitrag im U-Labs Portal

[U-Labs YouTube]

Kommentar von @matthias2912:
Sehr schön!

Nur versteht man nicht, wie man einen Task definieren muss, damit dieser auch funktioniert.
Die Module, die ein Task ausführen, müssen doch erst geschrieben werden.
Heißt: Was passiert genau bei
Apache aktualisieren

Sehr viele Präsentationen dazu enden genau hier für mich ist das ein wenig wie Prosa-Wünsch-Dir-Was und hoppala hat es was gemacht oder auch nicht

Mir scheint da die Kontrolle, was genau ausgeführt wird, etwas vernachlässigt zu werden

[DMW007]

Danke!
Ich vermute, du meinst "Apache installieren". Dabei verwendet man bereits ein Ansible-Modul namens APT. Letztendlich greift das per API/CLI-Aufruf auf APT zurück und führt im Hintergrund die notwendigen Befehle aus. In meinem Beispiel wären das etwa die folgenden:

sudo apt-get update
sudo apt-get install apache2

Ein Modul musst du dafür nicht schreiben, da Ansible bereits eine ganze Reihe von sich aus mitbringt. Neben verbreiteten Paketmanagern sind dort auch diverse Module für verbreitete GNU/Linux-Werkzeuge enthalten. Beispielsweise "ansible.builtin.replace", um Zeichenketten in Dateien zu ersetzen - wahlweise inklusive regulärer Ausdrücke. Es bietet damit die Funktion von sed. Dies befindet sich (neben vielen anderen) im eingebauten Namensraum "Ansible.Builtin". Hier kann man sich für die gewünschte Aufgabe ein passendes Modul heraus suchen. In vielen Fällen wird das bereits ausreichen. Falls nicht, ist das Schreiben eines eigenen Moduls auch kein Hexenwerk. Letztendlich muss man lediglich per Python den Status abfragen und den Zielzustand herstellen, z.B. durch Ausführung eines Kommandozeilenwerkzeugs.

Das sind aber eher erweiterte Szenarien. Kern von Ansible ist, das "wie" zu abstrahieren, da es Zustandsorientiert ist: Du gibst an, dass im Playbook z.B. das APT-Paket von Apache2 installiert sein soll. Wie das im Hintergrund geschieht, ist die Aufgabe von Ansible. Ob das funktioniert hat, sollte dir die Ausgabe immer anzeigen: Entweder wurde nichts verändert, weil der gewünschte Zustand bereits erreicht wurde - das prüfen die Module. Heißt, bei dem Apache2 Beispiel guckt der erst mal, ob das Paket schon da ist. Wenn ja, wird nichts gemacht (grün). Musste er etwas verändern, um den gewünschten Zustand zu erreichen, wird die Aufgabe gelb. Und wenn dabei ein Fehler aufgetreten ist (z.B. ein Job soll ein APT-Paket installieren, wurde aber nicht mit den notwendigen Rechten ausgeführt), wird er rot. In diesem Falle kann man mit dem Verbose-Log (-v so oft wiederholen, wie detailliert es werden soll, z.B. -vvv) sehen, was die exakte Fehlermeldung war.

[U-Labs YouTube]

Kommentar von @keksber:
Cooles Video und super Überblick in der kurzen Zeit.

Die besten 10 Minuten meines Tages bis jetzt

[U-Labs YouTube]

Antwort von @matthias2912:
@ULabs Danke!
Hört sich schlüssig an… nur so ganz ohne manuelle Eingriffe bekomme ich es nicht hin.
Wird schon…

[DMW007]

Kommt drauf an, von welchen manuellen Eingriffen wir reden. Ansible deckt die Installation und Einrichtung von Software ab. Das Aufsetzen eines Systems zählt nicht dazu - unabhängig davon ob es beim RPI darum geht, z.B. das Raspberry Pi OS auf die Karte zu überspielen, SSH zu aktivieren usw. Oder um das Erstellen einer VM. Hardware lässt sich teilweise automatisieren, etwa durch das Booten vom Netzwerk. Virtualisiert kann man diesen Schritt komplett automatisch ablaufen lassen. Das kann allerdings Ansible nicht abdecken. Hierfür benötigt man weitere Software wie etwa Terraform.

Im weiteren Lebenszyklus kann Ansible auch Aktualisierungen und andere Änderungen übernehmen. Beispielsweise auf mehreren Servern PHP 8.2 durch 8.3 ersetzen, die Passwort-Authentifizierung für SSH überall deaktivieren und andere Routine-Aufgaben. Dafür muss man sich einmalig ein Playbook schreiben und testen. Macht vor allem dann Sinn, wenn man mehrere Systeme hat. Wo Ansible dagegen nicht wirklich helfen kann, ist bei der Fehlersuche. Die wird man (zumindest auf einem System) immer händisch durchführen müssen. Erst wenn das Problem gefunden und der Fix auf andere Systeme angewendet werden soll, kann Ansible diese wiederholende Tätigkeit abnehmen.

In der Endstufe erstellst du automatisierte VMs, die Ansible provisioniert & verwaltet. Das händische Eingreifen wird dabei auf ein Minimum reduziert, darum geht es letztendlich. Wenn der Großteil automatisiert & damit auch gleich dokumentiert wurde, kann das schon vieles einfacher machen.