… so in etwa würde wohl ein Film darüber benannt werden, wenn man das erste mal mit Ansible anfängt, die Doku öffnet und die schier unendlich scheinenden Möglichkeiten sieht. Ich habe mich die letzten Tage ein wenig mit Ansible beschäftigt und folgendes festgestellt.
Ansible - Erste Eindrücke
- Ansible ist “mächtig”. Aber auch “gefährlich”.
- Es gibt fast für alles bereits fertige Playbooks / Rollen / Tasks die man als Vorlage verwenden kann.
- Ansible kann unüberischtlich werden.
- Ansible Dokumentiert sich “tatsächlich” quasi von selbst.
Okay. Nicht ganz die ersten Eindrücke. Ich habe schon hier und da mal beruflich ein paar Tasks und/oder Playbooks anpassen müssen. Aber das waren sehr sehr Oberflächige Aufgaben. Und das ändern von IP-Adressen oder “standard Ansible-Nutzer” in der “config” ist jetzt auch nicht die rede wert, vor allem weil es quasi selbst erklärend war/ist.
Zu den einzelnen Punkten kommen wir jetzt einmal mit 1-2 Sätzen genauer.
1. Ansible ist “mächtig”. Aber auch “gefährlich”.
Ja. Das wars auch schon…
… natürlich nicht. Ich habe direkt am Anfang darüber nachgedacht, wie ich wohl am besten die Playbooks/aufgaben, die Ansible übernehmen soll, testen kann. Naja dafür gibt es zum einen –check als option. Ansible läuft dann quasi im dry run und führt einfach keine der “ändernden” Aktionen aus. Sondern gibt nur zurück was sich geändert hätte. Also die übliche anzeige “changed” ja oder nein. Da kann es aber zu Problemen kommen:
Wenn man so wie ich noch kein Ansible Profi ist, sondern sich noch rein hangelt.
Ich habe in einem playbook von mir: playbooks/ubuntu_bootstrap.yml es irgendwie geschafft eine Abhängigkeit an eine vorherige Task einzubauen.
Ich kopiere mir da einen ssh-key hin und her, da dieser in ein internes repository aufgenommen werden soll. (wilder Geschichte die ich für mich im Homelab haben möchte).
Aber wenn das playbook im –check läuft, wird die Aufgabe, mit dem kopieren des ssh keys an die passende stelle, irgendwie nicht ausgeführt. Und die spätere Task, die diesen Key “benötigt”, wirft dann einen Fehler weil es die Datei einfach nicht gibt. Da muss ich mich noch mit beschäftigen wie ein “besserer” Ablauf wäre.
Ohne –check läuft es einwandfrei.
Also habe ich mir überlegt. Das wäre doch der Moment um die momentan als Notlösung laufende proxmox Instanz zu nutzen. -> 3-4 vm’s erstellt ubuntu cloud image drauf (bzw. aus dem image heraus geklont) und alles in Ansible eingetragen.
So teste ich einfach während ich an Ansible arbeite einfach mit einem “ähnlichen” virtualisiertem Setup. Das ist tatsächlich das erste mal das ich mich “gefreut” habe Proxmox installiert zu haben.
So und beim herum testen und ausprobieren, ist mir aufgefallen, dass es sehr schnell gehen kann, sich mal eben aus einer Maschine auszusperren (mit ansible). -> Abbrechen während Ansible am laufen ist. (freiwillig oder nicht.) Kann zu korrupten ständen führen. Allgemein “falsche Angaben” oder fehlerhafte geplante Rollen/Tasks (also logik falsch) führen halt einfach zu falschen ständen auf dem Host. Jenachdem wie man es aufgebaut hatte kann man dann anfangen händisch bestimmte dinge wieder rückgängig zu machen etc.
So empfinde ich für mich, als best-practice beim “entwickeln” bzw. erweitern seiner Ansible Lösung -> einfach eine oder mehrere VM’s und sich austoben. Dabei immer wieder prüfen ob –check ebenfalls korrekt durchläuft.
2. Es gibt fast für alles bereits…
… irgendetwas auf das man aufbauen kann. Schaut auf die Ansible DokuSeite. Sucht einmal kurz auf der Suchmaschine eurer Wahl und sehet sofort. Es gibt unendlich viel input zum thema ansible.
Und als kleiner Einschub von mir in Zeiten von KI…. [Lebt den Austausch!](m2b-id: zzxklt | 2brain/blogs/vollverpeilt.de/hugo/content/posts/irgendwas/leute-kennenlernen-kein-problem/index.md)
3. Ansible kann unüberischtlich werden.
Auch wenn Ansible sich selbst durch die Syntax dokumentiert/kommentiert/ den “Task” beschreibt, kann es unübersichtlich werden. Es empfiehlt sich doch hin und wieder zu überlegen ob man die Tasks einer Rolle nicht in einzelne Task-Dateien aufteilt. Statt 30 Tasks in einer Rolle direkt definiert. Vielleicht doch lieber schauen ob man es strukturiert in 2-3 Task-Bündel Dateien auslagern kann und diese dann aufruft. Zumindest ich verliere sonst teilweise den Überblick.
4. Ansible Dokumentiert sich “tatsächlich” quasi von selbst.
Vorhin schon angesprochen. Aber die Syntax von Ansible. Wie die Aufgaben (Tasks) definiert werden. Wie die Keys heißen etc. Das lässt sich wirklich teilweise wie Arbeitsanweisungen lesen. Und somit auch relativ schnell verstehen was wo passiert. Wenn dann die Tasks noch hilfreich benannt sind, wird es ein Kinderspiel sich über die playbooks anderer einen Überblick zu verschaffen!