[Musik]
Hallo und herzlich willkommen zur 22. Tür des Virtual Advents Kalenders unseres Focus- und Lienungspodcasts.
Nachdem wir neulich schon mal über Ansible Zimmer vorgesprochen haben, geht es heute wieder um Ansible und zwar um das Tool Arra.
Das Ganze bespreche ich nicht alleine, sondern dafür habe ich wieder unseren Ansibilisierungsbeauftragten, den Felix, eingeladen.
Moin.
Ja und wir gucken uns heute mal das Tool Arra an. Hast du damit schon mal gearbeitet?
Ich muss tatsächlich gestehen, ich habe das hauptsächlich mal ein bisschen angeguckt und bei Kollegen testet, ich habe es aber noch nicht irgendwo verbaut.
Aber das ist ja im Prinzip auch so ein bisschen die Runde, um zu besprechen, wann man das denn verbauen könnte.
Und ich habe es auf jeden Fall für die richtige Situation im Hinterkopf, wie jedes Tool.
Es ist ja mal wichtig seinen Baukasten gepflegt zu haben, seinen Werkzeugkasten.
Und ja, das ist auf jeden Fall in seinen Situationen ein cooles Tool.
Sehr gut. Ja, also ich habe das im Labor schon öfters mal gesehen, habe das auch selbst schon eingesetzt und gucke mir das auch im Home Lab gerade an.
Also steig mal am besten einfach mal an, was ist denn Arra überhaupt?
Also Arra ist ein rekursives Akronym für Arra Records Ansible.
Ja, es ist ein weiteres Projekt, das sich mit Ansible beschäftigt.
Da steckt keine Firma dahinter. Es gibt aber trotzdem eine aktive Entwicklung.
Man kann sich da jederzeit auf GitHub mit einbringen, wenn man das möchte.
Und das ist im Prinzip eine Anwendung, die verschiedene Metriken, Ausführungen und Informationen aus Ansible Runs speichert.
Also es ist egal, ob ich jetzt ein Playbook ausführe, ob ich so einen Ad-hoc-Kommando habe, ob ich AWX benutze, ob ich sie mal vor benutze.
Das würde auch gehen.
Oder ob ich eine CI/CD Pipeline habe, die eben Ansible Runs ausführt.
Oder auch wenn ich selbst Ansible Rollen entwickle, beispielsweise in Test Stream Development, man ja mit Molekülen.
Also eigentlich all das, was ihr seht, wenn ihr -vvvv in euer Ansible-Kommando reindüngelt, das wird hier einfach zentral gesammelt.
Das heißt, das sind so Dinge wie Datum und Uhrzeit, dann die einzelnen Tasks, die Return Codes dazu, die Ausgaben,
CLI Argumente, die ihr an das Kommando angehängt habt, die Hosts, die da ferngesteuert wurden, sowie deren Stati und System Facts.
Also so Dinge wie CPU, RAM, Festbutton-Parditionierung und so weiter.
Gefolgt von Ansible und Python Versionen und eben Tags, die das Playbook oder die Roller entsprechend enthalten.
Das ist also wirklich sehr viel.
Die Frage ist, warum will man das sammeln?
Naja, vielleicht wollt ihr zentral einfach mal sammeln, was, wo, wie, wann ausgeführt wurde, um Trends zu erkennen.
Oder im Fehlerfall möchtet ihr vielleicht die Option haben, euch genau oder genauer anschauen zu können, woran es denn eigentlich gelegen hat,
dass eine bestimmte spezifische Aktion nicht funktioniert hat.
Und das Schöne ist, das Ganze ist als Callback Plugin implementiert.
Das heißt, diese Informationen, die wir gerade erwähnt haben, die werden dann eben einfach beispielsweise in einer lokalen SQLite-Datenbank gespeichert.
Das liegt meistens im User Home, in dem Ordner ".ara".
Das wäre eine Option.
Das wäre auch so die einfachste Option, wenn ihr lokal einfach mal was auf eurem Rechner starten wollt und da Informationen sammeln wollt.
Aber ihr könnt das natürlich auch in einem Team benutzen.
Wenn man jetzt beispielsweise sagt, ihr habt irgendwo eine VM oder einen Container, wo eben ARA drin läuft,
und ihr wollt da zentral die Informationen von allen Anwender*innen aus eurer Gruppe reinloggen lassen.
Das würde auch gehen. Dafür gibt es den sogenannten API-Server.
Oder wie es auf der Webseite heißt, auch schon lange nicht mehr gehört, SinglePaneOfGlass.
Da hat das Marketing mal wieder richtig reingekickt.
Und das ist dann halt einfach eine kleine Applikation, wo dann eben auch eine MySQL oder eine PostgreSQL-Datenbank läuft.
Und über diesen API-Server habt ihr dann eben auch ein Webinterface.
Und das, glaube ich, ist ein wirklicher Mehrwert, weil Logs zu haben ist ja eine Sache, aber die Logs auch auswerten zu können,
das ist nochmal eine ganz andere Sache.
Also gerade wenn man diese ganzen Metriken, die Ansible so mitliefert, sich mal im Detail anschaut,
dann kann man sich da ganz schnell drin verlieren.
Zumindest geht es mir immer so. Oder hast du da andere Erfahrungen gemacht, Felix?
Ja, das ist schon so.
Vor allen Dingen ist es eben, also man muss immer so ein bisschen gucken, was man da für einen Use-Case hat.
Wir haben ja, falls ihr die verpasst habt, hört doch um den Kontext zu haben nochmal in unsere Folge zu Semmer vor rein.
Wenn man eben diese ganz klassischen Muster oder diesen Weg anfängt, ich habe einen Server zusammen mit meinem kleinen Team
und von da aus entwickeln wir eben Playbooks, da füllen wir die aus,
dann verliert man natürlich eben relativ schnell den Check, was da genau passiert ist
und hat im Zweifelsfall die History, Command-History, was da eben ausgeführt wurde.
Und da so ein bisschen Kontext zu haben über die einzelnen Runs, wer hat welches Playbook wohin ausgeführt,
wie ist das eben, ja was hat das bewirkt, auch vielleicht einfach nur für die Entwickler selbst zu sagen,
ok, ich habe jetzt hier ein Playbook ausgeführt, was hat das eben für spezielle Variable mitbekommen
oder beziehungsweise was ist da eben rausgekommen, also was sind so bestimmte Dinge,
damit ich nicht jedes Mal das wiederholen muss, vielleicht kann ich den Prozess gar nicht wiederholen,
sondern hätte ihn am liebsten quasi, ich will ja nicht jedes Mal was mit kompletten Debug-Flag ausführen,
aber wenn es crasht, dann will ich sie vielleicht doch gerne sehen,
aber ich habe vielleicht keine Möglichkeit den Prozess zu wiederholen oder genauso nochmal nachzustellen.
Also da immer so einen kleinen Begleiter, dem einen Vortrag, den wir euch verlinkt haben,
heißt es glaube ich "Programming ends with an error over your shoulder",
ist das vielleicht gar nicht so schlecht, den so ein bisschen dabei zu haben.
Ja, der ist super, also den können wir echt wärmstens empfehlen,
ist von der Vorstamp dieses Jahr von David Morioh-Simard, der da auch in dem Projekt drin war,
der hat auch glaube ich lange Community-Management bei Red Hat gemacht, also das kann man echt empfehlen.
Und was man natürlich noch sagen muss, ein Killer-Feature dieser Web GUI ist natürlich,
sie hat einen light und einen dark Mode, ganz ganz wichtig,
und diesen API-Server, der eben auch diese GUI ausführt, der kann entweder eine lokale Authentifizierung konfigurieren,
wenn ihr das möchtet, also über HTTP-Basic, wenn ihr jetzt sagt,
naja das soll jetzt nicht jeder einfach ohne Authentifizierung sehen,
oder das Teil kann halt auch wieder LDAP, also das würde dann auch funktionieren.
Und da das Ganze, also die aktuelle Version ist ARR 160 und das ist Django basiert,
das ist ja hier ein Web-Framework und Django hat auch selbst eine eigene integrierte Authentifizierung,
die kann man auch benutzen, wenn man sagt, man will sich jetzt nicht mit dem Pflegen von HTTP-Basic-Konfigurationsdateien rumärgern,
dann würde auch das gehen.
Und man kann auch, also das das Schöne ist, das sollte man vielleicht auch nochmal betonen,
man muss an den Playbook im Prinzip nichts anpassen und sie könnt jedes beliebige Playbook,
jeder spezifische Ansible-Rolle, die ihr vorher benutzt habt, einfach eins zu eins weiter verwenden.
Man kann aber nochmal Variablen ergänzen, wenn ihr das möchtet, beispielsweise ARR Playbook Name oder ARR Playbook Labels,
dann hat halt eben dieser Lauf in der GUI von ARR dann nochmal einen anderen Namen
oder hat in der GUI dann spezifische Labels, nach denen man sortieren kann.
Also das würde entsprechend auch funktionieren.
Ich glaube ich würde ganz gerne an der Stelle auch nochmal darauf eingehen,
wir sind da so ein bisschen darüber weggesprungen am Anfang, welchen Mechanismus das Ganze eigentlich benutzt.
Das stößt eine ganz interessante Tür auf, wir haben ja auch uns ein bisschen zum Auftrag gemacht,
einfach mal interessante Sachen zu zeigen, die man sich vielleicht mal angucken kann.
Und eben eins der Themen, die auf der Ansible-Reise oft übersprungen werden, so ein bisschen mit dem Hinweis,
ja das später oder das braucht man nicht so häufig, ist einfach dieses ganze Thema Plugins.
Dabei ist das ziemlich zentral in Ansible und auch ein ziemlich cooles Feature.
Also wenn man sich einfach nur mal anguckt, ok Ansible Plugins, dann stellt man fest, viele der Features, die man kennt,
also zum Beispiel das ganz Kernelement Module sind eigentlich Plugins, sind Module Plugins
oder auch Lookups, sind halt Lookup Plugins, aber es gibt halt neben diesen sehr bekannten oder sehr elementaren Dingen
eben noch andere Plugin-Varianten, wie eben die Coreback Plugins,
die dann den Output der Playbooks, der Runs einfach aufnehmen können und damit halt was auch immer machen können.
Und diese Logik halt in Python dann zu implementieren eben als Plugin,
bietet halt Möglichkeiten für alle möglichen Anschlusstools.
Das ist ein schönes Beispiel dafür, wie halt Tools, im Prinzip Kerntools wie Ansible durch Plugin-Mechanismen erweiterbar werden können
und eben auch ja einfach Fenster öffnen für weitere Community-Arbeit eben für alle da draußen, die halt eben den Need haben,
Playbook-Runs aufzuzeichnen, die besser zu visualisieren, die Runs darzustellen, alles möglichen.
Ist Ara nämlich ein Tool, das da genau an diese Stelle andockt und eben in diesem ganzen Feld von Plugins
gibt es eben noch viel, ja viel mehr zu entdecken. Also bestimmte Plugins, die zum Beispiel Timing aufzeichnen,
wie lange haben bestimmte Tasks gedauert, ein bisschen Performance Tuning, also Performance nicht Tuning, sondern Monitoring halt machen.
Also da lohnt es sich auf jeden Fall mal zumindest kurz einzutauchen, zu evaluieren, ob da nicht vielleicht das eine oder andere Spannende für euch dabei ist.
Absolut, ja. Es gibt echt viele sehr nützliche Coreback Plugins, also auch so Dinge wie
Performance-Messungen, wo du dann gucken kannst, wie viel CPU, wie viel Memory-Auslastung hat jetzt dein Playbook-Run
eben verursacht, damit du auch rausfinden kannst, wo man vielleicht möglicherweise den Code ein bisschen optimieren könnte.
Das ist echt ein Thema, da kann man auf jeden Fall mal reingucken, das lohnt sich da mal sich zu belesen.
Gut, ja Ara 1.6.0 ist die aktuelle Version, die braucht Python 3.5 oder neuer, man kann es per PIP installieren
oder es gibt auch Docker und Podman-Images, da kann man sich ganz schnell mal mit so einem Docker Compose eben diesen Ara-API-Server
gebündelt mit der Datenbank hochziehen, ist eine ganz nette Sache.
Und abschließend sei noch angemerkt, es gibt zwei CLI-Tools, es gibt einmal das Ara-Manage-Kommando, das ist für die administrativen Tätigkeiten.
Da gibt es beispielsweise das prune-Kommand, was dann halt eben Inhalte aus der Datenbank entfernt, also
dokumentierte Playbook-Runs, die älter als X Tage sind. Also man möchte vielleicht nicht, gerade wenn man das im Team einsetzt, im größeren Stil,
alle Playbook-Runs der letzten sechs Monate aufheben, das könnte ich mir vorstellen, dass die Datenbank dann relativ voll ist.
Genauso kann man mit Change-Password eben das Passwort ändern,
was dann relevant ist für diesen API-Server, aber das zweite Tool ist vielleicht ein bisschen
nützlicher oder wird vielleicht häufiger benutzt, das ist die Ara-CLI
und das gibt die Möglichkeit, die Informationen, die man über die GUI einziehen kann, auch auf der Kommandozeile einzusehen oder zu manipulieren.
Das heißt, man kann dann so Dinge tun wie Ara-Host-List oder Ara-Host-Show oder Ara-Host-Delete, um halt eben die Host-Informationen, die man so gesammelt hat durch die Läufe,
eben anzuzeigen oder zu manipulieren. Das Ganze geht aber auch mit Play, Playbook und Task.
Also die einzelnen Elemente, die kann man jeweils eben entsprechend mit Delete-List und Show ansprechen beispielsweise.
Das heißt, egal ob man die GUI präferiert oder lieber eine Kommandozeile haben will, man kann auf beiden Wegen die Informationen zentral sammeln und anschauen.
Das ist auf jeden Fall etwas, das ich jetzt mir mal näher anschaue und das ich jetzt auch im Laborschritt im Einsatz habe und sehr nützlich finde und vielleicht hilft das ja auch dem einen oder der anderen da draußen.
In dem Kontext, liebe Zuhörer, lasst uns gerne wissen, wie ihr dieses Tool findet. Habt ihr da vielleicht auch andere Erfahrungen mitgemacht? Habt ihr es vielleicht selbst schon mal im größeren Umfeld eingesetzt?
Das würde uns sehr interessieren. Könnt ihr gerne auch gebündelt mit Feedback wieder per E-Mail an uns richten.
Und das geht am einfachsten über die Adresse podcast@sva.de. Und dann hören wir uns morgen mit einem neuen Thema wieder.
[Musik]