Herzlich Willkommen zu meinem Vortrag. Schön, dass trotz Mittagstiefst auch einige geschafft haben. Ich verspreche, dass ich versuche mich kurz zu fassen, damit mir nicht alle einschlafen. Der Titel meines Vortrags ist

Orchestration of Lifecycle Management Tools und wie schon der Untertitel sagt, soll es im Folgenden darauf gehen, wie das Zusammenspiel zwischen Formen und Ansible aussehen soll. Bevor ich das Ganze etwas weiter leutere, möchte ich kurz mich vorstellen. Mein Name ist Bernhard Hopfemüller, ich bin IT-Consultant bei der Artix AG. Ich bin im Internet zu finden, falls

jemand das Bedürfnis hätte. Mein Arbeitgeber, die Artix AG, sitzt bei München unter Schleißheim und unter dem Titel Linux und Open Source Company machen wir seit über 15 Jahren schwerpunktmäßig in den Themen Rechenzentrums, Automatisierung, Linux und Open Source Software,

Consulting, Engineering, Support und Training. Gut, worum soll es heute im Wesentlichen gehen? Jetzt muss ich mal vorab fragen, wer hat schon mal was mit Formen gemacht oder Satellite oder sowas in die Richtung? Okay, doch ein paar. Ansible

auch, Grundwissen vorhanden. Sehr gut, wunderbar. Ich möchte heute ein bisschen erzählen, wie das Zusammenspiel zwischen Ansible und Formen aussehen kann. Ich möchte keinen Vortrag zu behalten, wie Ansible funktioniert. Ich möchte auch keinen Vortrag zu behalten, wie Formen funktioniert. Ich habe trotzdem ein paar Basics zur Ansible noch mal

drin. Da habe ich aber gleich noch was dazu. Jetzt ganz kurz noch mal was zu Formen. Formen ist ein Life-Circle-Management-Tool für virtuelle und physikalische Server und mit dem entsprechenden Plangens kann man auch Softwarestände verwalten. Ocarino, ich habe es ab und zu in dem Vortrag auch drin stehen, ist so ähnlich wie Satellite von Red Hat gibt es ein Thema

Formen, von unserer Firma Artex unsere Version von Formen, die wir dem Kunden mit Support anbieten und unser Anspruch ist dabei, dass wir Hersteller unabhängig sind. Das heißt, wir versuchen möglichst alle Betriebssysteme zu unterstützen. Gut, zur Agenda. Ich möchte kurz zu

Anfang erläutern, wie überhaupt dieses Thema entstanden und erwachsen ist, also so eine Art Szenario erläutern. Dann möchte ich ganz kurz noch mal ein paar Ansible Basics wiederholen und möchte dann im Folgenden ein bisschen zeigen, wie man diese Basics oder auch ein bisschen

fortgeschrittenere Ansible Sachen tatsächlich in unserem Fall anwenden kann und im letzten Teil möchte ich ganz kurz darauf eingehen, was man macht, wenn man an dem Punkt ist, dass es das Ansible Modul, das man gerne hätte nicht gibt, nämlich wie man so ein Modul selber schreiben könnte. Kommen wir zum Szenario. Das ist, was wir hier sehen, ist ganz typisch

für jede Firma, die in irgendeiner Form Softwareentwicklung macht. Wir haben rechts oben in der Ecke ein Softwareprojekt, in dem Fall ist das unser Orcarino. Den entwickeln wir und stellen unsere Softwarestände auf einem Git-Server zur Verfügung und über eine CI oder CD bauen wir verschiedene Stände von unserer Software und diese wollen wir dann

natürlich auch in gewisser Weise testen, möglicherweise oder im Idealfall jede Nacht zum Beispiel, das bauen und das Ganze wollen wir testen auf einem VM-Server. Das Tool unserer Wahl in dem Fall ist Ansible. Sprich, es geht eigentlich im Folgenden darum, wie bekomme ich von einer CI oder CD

mein Softwareprojekt hier rüber auf einem VM-Server und bringe es da zum Laufen. Die Schritte, die ich also in meinem Ansible tun will, könnten folgendes sein. Zunächst mal räume ich auf. Ich habe in der letzten Nacht davor virtuelle Maschinen hochgefahren, die brauche ich alle nicht mehr, das heißt ich schmeiße die weg. Dann baue ich mir eine

neue virtuelle Maschine, auf der ich meinen Formen, meine neueste Version installieren will. Ich schaue, ob die da ist und ob sie das tut, was sie tun soll. Ich kümmere mich darum, diese virtuelle Maschine in gewisser Weise vorzubereiten, ein bisschen updaten. Dann installiere ich tatsächlich meinen Formen, ich konfiguriere ihn und nach dem Formen ob er ein Tool ist, um Hosts zu verwalten oder auch zu professionieren,

mache ich das gleich auch noch. Das heißt, ich haue mir noch zwei, drei, vier Hosts raus und schaue, ob das alles so tut, wie es soll. Kommen wir nochmal ein bisschen zurück zu Ansible. Ganz kurz nur, was braucht Ansible, um überhaupt zu laufen? Ansible braucht

eigentlich nur eine Unix-Note, die die Managed-Note sein soll. Wir brauchen sowas wie eine SSH-Verbindung zu einer Note, die gemanagt werden soll. Wir brauchen Python auf beiden Maschinen. Das war es eigentlich schon. Das Operation Principle ist dann im Prinzip, dass ich auf meinem Managed-Note einen Python-Skript

zusammenbaue. Das wird per SSH an den Server rausgeschickt und dort ausgeführt. Das wichtigste Prinzip von Ansible, so ähnlich wie von jedem anderen Configuration Management, ist das Idem-Potenz- Modus. Das heißt, ich beschreibe nicht das, was ich tun will, sondern

der Zustand, zu dem ich hin will. Also ich sage nicht Ansible, bitte installiere mir mal yum, sondern ich sage Ansible, ich möchte gerne, wenn du fertig bist, yum in der Version so und so drauf haben. Dann kann sich Ansible überlegen, wenn es zweimal läuft, dass es das nicht mehr tun muss, weil es beim ersten Mal schon passiert ist. Ein paar Grundbegriffe,

die ich im Folgenden auch benutzen werde. Ansible kann im Wesentlichen in zwei Modes betrieben werden. Das eine ist Art-Hoc-Mode, sprich ich setze mich tatsächlich an einen Terminal hin und tippe da einen Task rein. Der wird dann ausgeführt. Oder ich schreibe mir ein Playbook. Das kann eine Sammlung von Tasks oder Rolls sein. Dabei ist eine Roll eine Sammlung von Tasks und ein Task wäre im Prinzip

ein Ansible-Kommando, also sowas wie das Pendant hier nano installieren. Ansible benutzt Tynjar-2-Templating. Das kann ich zum Beispiel normalerweise oder im häufigsten Fall für Variablen benutzen, aber ich kann mir auch ganze Templates freilich zusammenbauen in der Tynjar-Syntax. Der Kernbaustein von Ansible sind

natürlich die Module. Hier mal zwei Beispiele, zum Beispiel das Yum-Modul oder das Ping-Modul. Das sind die Bausteine, die tatsächlich benutzt werden, um dann die Tasks auszuführen. Diese Module können im Wesentlichen, nicht nur im Wesentlichen, können in jeder Programmiersprache geschrieben werden, in der

man sie gerne schreiben möchte. Einzige Voraussetzung ist, sie müssen über Jason mit der Management-Node kommunizieren können. Gut, dann sehen wir uns doch mal an, wie so ein Playbook aussehen könnte, mit dem ich das, was ich jetzt alles erzählt habe, machen würde. Die Playbooks sind immer so aufgebaut, dass ich zunächst mal sage, wo sie laufen sollen. Die

ersten zwei Tasks sind diese Aufräum-Tasks. Also Aufräum-Tasks und neue Herstellungstasks. Ich lösche alle alten virtuellen Maschinen und ich brauche mir eine neue virtuelle Maschine. Und nachdem das Ganze mit einem Modul passiert, das mit meinem VM-Server kommuniziert, soll das

ganze lokal passieren. Also tatsächlich von meinem Management-Node Rechner aus laufen. Sprich, wir haben hier sowas wie Host-Local ausstehen und Connection-Local, weil wir keine SSH-Verbindung brauchen. Wenn wir das gemacht haben, dann wollen wir uns mit der Node verbinden, die wir erstellt haben, wollen dann ein paar Sachen

machen, die wir als Sudo ausführen müssen. Deswegen steht hier ein Become True. Dann wollen wir sie pingen, so wie man sich das tatsächlich vorstellt, schauen, ob sie da ist. Dann wollen wir das System soweit vorbereiten, dass wir Formen installieren können und updaten. Dann wollen wir Formen installieren, konfigurieren und wieder die Hosts erstellen, wie ich es

schon beschrieben hatte. Wir könnten jetzt, Entschuldigung, ich greife vor. Bitte einmal die Überschrift hier nicht beachten, die ist falsch. Da ist mir ein kleiner Bug unterlaufen. Was ich noch zeigen wollte an dieser Stelle, ist, wie das Verzeichnisstruktur von so einem Playbook-Verzeichnis aussehen könnte.

Wir haben hier ganz klassisch das Playbook liegen. Wir haben sowas wie generelle Variablen, sprich, die für das komplette Playbook und alle Roles, die da drin sind, interessant sein könnten. Wir haben sowas wie eine Konfigurationsdatei, eine Inidatei, die Hosts beinhaltet, die Inventory und dann haben

wir die Roles. Hier habe ich mal beispielsweise eine Rolle ein bisschen aufgedröselt. Das wäre der Formen Installer. Die hat dann sowas wie Default Values, also Rollenspezifische Variablen, die jetzt tatsächlich nur für den Scope dieser Rolle interessant wären. Ich habe hier verschiedene Tasks drin, wobei der Main immer der Entry Point für jede

Rolle ist. Von diesem Main aus könnte ich noch andere Tasks aufrufen, die ich da drin hätte. Jetzt aber schauen wir uns mal an, wie dieser erste Schritt für die virtuellen Maschinen aussehen könnte. Wir wollen erst mal alle virtuellen Maschinen, die wir vielleicht noch von letzter Nacht haben, ausschalten, bevor wir die löschen. Wie machen wir das? Wir

benutzen das Vmware-Gest-Modul und hier sehen wir schon, dass ich Jinja-21-Tasks benutzt habe, nämlich Hostname, Username, Password und vielleicht noch ein paar andere Konfigurationseinstellungen. Ich habe jetzt hier tatsächlich ein paar rausgenommen, die sind in dieser Syntax definiert, damit ich dann nicht jedes Mal einen Klartext reinschreiben muss. Dann sehen wir ein Beispiel für

idempotenz. Hier steht nämlich jetzt nicht Shutdown, sondern hier steht sowas wie Powered Off. Also wenn du fertig bist, sollen alle Maschinen, von denen ich gesprochen habe, ausgeschaltet sein. Und nachdem wir das vielleicht nicht nur für eine Maschine machen wollen, sondern gleich für mehrere, wäre es doch ganz schick, wenn wir hier einen Loop benutzen könnten und nicht jede Maschine einzeln diesen Task

neu schreiben müssten. Und das geht in Ansible auch. Und zwar mit der With Items Strategie. Ich schreibe hier oben tatsächlich einfach nur Name Item rein und hier unten eine Liste von, übergebe ich dann eine Liste, die wir gleich unten am Bild dran noch sehen werden und das wird dann für jedes dieser Items ausgeführt. Dann habe ich hier was

eingebaut, was tatsächlich sehr gefährlich ist und mit Vorsicht zu genießen ist. Hier steht ein Ignore Errors True. Was tut das? So wie es schon sagt, wenn du einen Ansible Fehler bekommst an dieser Stelle, ignorierts den einfach und läuft weiter. Das ist normalerweise natürlich nicht besonders klug. Warum habe ich das an dieser Stelle drin? Gut, wir sind ein

Softwareentwicklungsbetrieb. Wir haben Entwickler, die spielen gerne mal an virtuellen Maschinen rum, fahren die hoch oder runter. Das heißt, ich kann mir zum Zeitpunkt, wo ich diese Ansible Role ausfüre, gar nicht mehr sicher sein, dass diese Maschinen überhaupt noch so da sind. Sprich, wenn sie nicht da ist, okay, dann schalte ich sie halt nicht aus, dann ist es in dem Fall egal, wenn ich einen Fehler mache. Prinzipiell ist es aber

durchaus mit Vorsicht zu genießen. Was ich dann hier noch schon mal anreißen möchte, ist Text, so was wie selektives Ausführen von Rollen. Da komme ich gleich auf der nächsten Folie noch zu sprechen. Zuerst möchte ich noch kurz auf das hier oben eingehen, was ich gesagt hatte, Liste. Hier sehen wir jetzt, wie so zwei

Variablen aussehen, die zum Beispiel in meiner General Mains Variablen Datei aussehen könnten. Also hier Hostname und hier Beispiel halber eine Liste mit zwei virtuellen Maschinen. Gut, die Selective Rolls, von denen ich gerade gesprochen hatte. Wir erinnern uns, der erste Task war jetzt, die

virtuellen Maschinen runter zu fahren, und im zweiten Schritt wollen wir sie löschen. Sprich, wir haben wieder dasselbe Modul, v.a. Guest. Und der einzige Unterschied, den wir jetzt haben, ist, dass wir hier nicht state powered off, sondern state absent haben. Und wir sehen auch, dass wir hier zusätzlich, vorne hatten wir den Tag Vibe VMs hier. Jetzt haben wir denselben Tag Vibe VMs, aber auch noch einen

zweiten Tag Delete VMs. Was hilft mir das? Relativ simpel erklärt. Ich kann, wenn ich den Tag Vibe VMs, der bei beiden dabei steht, ausführe, beide Tasks ausführen. Ich kann, wenn ich nur den Task, den Tag Shutdown VMs ausführe, nur einen der beiden ausführen. Oder ich könnte sogar, wenn

ich mir denke, okay, ich will jetzt nicht jedes Mal die virtuellen Maschinen anfassen, sondern einfach nur den Rest vom Playbook aus probieren. Diesen Task skippen. Fehlt ein Underscore. Aber dann würde tatsächlich der Rest des Playbooks passieren, bis auf diese Sachen, die ich hier vordefiniert hatte. Gut, dann haben wir diese beiden

ersten Punkte abgehandelt. Und auf den Punkt mit dem Pingen möchte ich jetzt auch nicht weiter eingehen. Das ist wirklich nicht so wahnsinnig spektakulär. Genauso wenig wie die Requirements. Da geht es im Wesentlichen darum, jede Menge von Paketen zu installieren. Das kann man mit dem Yum-Modul machen. Da komme ich aber nachher noch drauf zu sprechen. Für einen Moment stelle ich das mal kurz zurück, weil es, wie

gesagt, unspektakulär ist. Ich möchte stattdessen kurz über das Systemupdate sprechen, weil das ein Feature von Yum ist, das ganz nett ist und dass wir, da komme ich gleich noch drauf, dass wir auch gerne für andere Module passieren wollen, nämlich Bulk-Features. So,

wir wollen das System updaten von der virtuellen Maschine. Sprich, ich benutze das Yum-Modul und statt jetzt hier eine Liste von allen Paketen zu benutzen, manuell oder in jedes einzelne Paket, schreibe ich hier Stern rein und den state latest. Dann checkt Ansible, dass ich hier tatsächlich ein Update von allen Paketen machen wollen würde und

tut das. Es ist ein Feature, das bisher leider in wenigen Modulen eingebaut ist. Es macht natürlich auch nicht für alle Module Sinn. Aber wir haben jetzt beispielsweise aktuell ein Modul geschrieben, das mit Templates in Formen umgehen kann und da haben wir auch diesen Stern eingebaut, weil wir eine große Menge von Textdateien behandeln wollen und in dem Fall, dass dann

alle sein sollen. Genau, kommen wir noch einen Schritt weiter zum Formen-Installer. Da möchte ich jetzt auf eine Besonderheit rauskommen, nämlich das Shell-Modul und das ist eigentlich eher so was wie das Last Resort. Warum? Das Shell-Modul macht

eigentlich einfach nur einen Raw-Execution von einem Shell-Befehl. Wenn man nicht aufpasst, nicht besonders idempotent ist, ist klar. Also es mit Vorsicht zu genießen. In dem Fall geht es. Leider, ich sage noch nicht anders, weil wir den Formen-Installer so benutzen,

wie er von Formen mitgeliefert wird und das ist nun mal eine CLI. Es gibt aber Projekte und Ideen, das vielleicht auch ohne diese CLI zu benutzen. Nichtsdestotrotz benutzen wir das so. Und wie sieht es dann in der Implementierung aus? Wir haben tatsächlich das Shell-Modul und dann schreiben wir

drunter in so viele Zahlen, wie wir es brauchen, den Formen-Installer rein und übergeben hier wieder mit Ginger-Syntax die Werte, die wir gerne hätten, um das Ganze auszuführen. Ja, wie gesagt, ein Wort der Warnung an dieser Stelle, damit wir nicht in den Potenz-Falle laufen und uns irgendwas kaputt machen. Ich zage aber

auch immer dazu, an dieser Stelle, es gibt sehr viele Leute, die nach wie vor Bash-Skripte bevorzugen als Configuration-Management, das meines Erachtens vollkommen legitim. Man sollte nur wissen, was man tut. Gut, dann haben wir jetzt soweit die Schritte abgehandelt und wollen jetzt tatsächlich einen Formen,

den wir installiert haben, durchkonfigurieren. Und bevor wir das tun, müssen wir uns vielleicht einmal kurz überlegen, was genau wir in Formen machen wollen bzw. auf welchen Stand wir den Formen bringen wollen. Und der Stand, den wir haben wollen, ist, dass wir Formen soweit haben, dass wir tatsächlich ready to deploy sind. Sprich, wir

wollen sowas wie Environments aufsetzen, also in the staging, production area, whatever. Wir wollen sowas wie Netzwerk aufsetzen, damit wir mit unseren Hosts natürlich auch kommunizieren können. Wir wollen Provider aufsetzen, weil wir benutzen ja vielleicht Docker oder Lipvirt oder AWS oder was auch immer. Und wir müssen

natürlich Operating-Systeme einrichten, damit wir auch irgendwas haben, was wir professionieren können auf unsere Hosts. Diese Liste lässt sich natürlich noch beliebig erweitern, je nach dem, was man, man kann natürlich auch Host-Groups reinschieben oder sonst was. Die basic steps sind jetzt mal die vier, Entschuldigung. Und je nach

dem, ja, nach Gusto könnte man die Liste auch noch erweitern. Wie tun wir das jetzt? Im Wesentlichen wissen wir jetzt Enzyme dazu kriegen, mit der Formen API zu kommunizieren. Und dafür gibt's, ich sag mal, prinzipiell zwei Wege. Es gibt noch mehr Wege, die sind aber jetzt nicht so schön und nicht so bekannt.

Deswegen möchte ich in dem Fall jetzt nur über die zwei hier sprechen. Das eine ist die Hammer CLI, die auch schon angesprochen wurde in Talks gestern und heute von Formen selber. Die könnten wir benutzen. Da müssten wir wieder das Shell-Modul benutzen oder wir benutzen die Nailgarn Bibliothek. Das ist eine Bibliothek, die ursprünglich

für Satellite geschrieben wurde, um da Tests an Satellite durchzuführen. Und mit Hilfe dieser Nailgarn Bibliothek können wir Enzyme-Module in Python schreiben oder schon vorhandene benutzen, die dann ebenfalls wieder mit meinen Formen kommunizieren. Sprich, wir müssen diese API erst mal aufsetzen, mit der wir

kommunizieren wollen. Und das machen wir über PIP. Sprich, wir installieren erst mal PIP. Wir updateen PIP auf die neueste Version, weil seltsamerweise bisher ein Latest hier nicht das getan hat, was es sollte, beim PIP installieren. Dann installieren wir Nailgarn. Das ist auch als PIP-Paket

verfügbar. Und dann starten wir Formen neu und dann sind wir ready to go mit unseren Modulen. Und diese Module, ich habe jetzt hier beispielsweise halber mal den Fall des Operating Systems genommen. Wie würde das aussehen, wenn wir jetzt ein Operating System anlegen? Zunächst mal brauchen wir ein Medium, auf das ein Operating

System in Formen zurückgreifen kann. Und das tun wir einfach, indem wir das Formen Medium-Modul benutzen. Hier haben wir sowas wie in einem Pfad drinstehen, an welcher Stelle die SUSE-DVD jetzt hier tatsächlich liegen soll. OS-Family ist klar. State ist auch wiederum klar. Und die Verbindungsparameter

zu meinen Formen sind hier wieder in Ginger-Syntax drin. Im nächsten Schritt kann ich dann auf dieses Medium, das ich gerade erstellt habe, zurückgreifen und kann ein Formen-Operating-System anlegen. Da stimmt der Name nicht. Das sollte Slash-12 sein, Entschuldigung dafür. Das jetzt hier auf

mein Medium Slash-12 zurückgreift und dann dafür sorgt, dass dieses Medium in meiner Operating System-Liste auftaucht. Was hier in dieser Stelle fehlt, weil es einfach vom Platz, der nicht hinpasst, sind wiederum die Credentials. Aber es ist klar, es ist komplett analog zum Fall davor. Wenn ich das dann gemacht habe, dann habe ich mein Operating System und dann kann ich im Prinzip mein Operating System deployen,

wenn ich das gerne möchte. So einfach ist es aber leider noch nicht. Warum? Weil sehr viele Module oder sehr viel Funktionalität, die man gerne hätte, entweder noch nicht vorhanden ist oder gerade dabei ist, implementiert zu werden. Und wir standen vor diesem Problem tatsächlich und deswegen haben wir

gesagt, okay, es hilft alles nicht, dann müssen wir selber sehen, dass wir Module schreiben dafür. Und da möchte ich jetzt ganz kurz etwas dazu zeigen. Und zwar habe ich hier, sieht man das ja, das sieht man wunderbar, jetzt meinen Formen bzw. in diesem Fall ein Orcherino. Und worum es

dem Folgenden gehen soll, sind globale Parameter. Was sind globale Parameter? Gut, der Name ist relativ selbsterklärend, glaube ich. Wozu braucht man globale Parameter? Sehr oft braucht man die, wenn man zum Beispiel Templates benutzt. Also beim Kickstarten soll das und das und das umgesetzt werden. Und dazu lege ich einen globalen Parameter an. Und das kann ich natürlich

von Hand ganz einfach machen. Ich nenne den jetzt mal whatever test und gibt ihm einen Wert. Und dann habe ich hier einen globalen Parameter drin. Kann ich natürlich von Hand machen, aber wir wollen ja das Ganze automatisieren. Deswegen soll mein Ansible das jetzt tun. Und der Quellcode für ein Modul,

wie das aussehen könnte, sehen wir jetzt hier. Ich glaube, ich mache es noch ein bisschen größer. Genau. Sehen wir jetzt hier. Wir haben das in Python geschrieben. Wie schon gesagt, man könnte das im Prinzip in jeder Programmiersprache schreiben, in der man lustig ist. Unsere Wahl war Python. Was tun wir hier? Zunächst mal importieren wir

von der Nelgan Bibliothek eine ganze Menge Sachen, die wir brauchen. Und dann kümmern wir uns tatsächlich um die globalen Parameter. In dem Fall heißt das Ding in Nelgan leider Common Parameter. Es liegt dran, dass Nelgan tatsächlich für Satellite geschrieben wurde. Da heißen manche Parameter ein bisschen anders

als in Formen. Es tut aber im Wesentlichen dasselbe, weil aber die globalen Parameter, so wie sie in Nelgan implementiert haben, weder erstellt, noch gelöscht, noch geupdated werden konnten, haben wir dann Basisfunktionalität hier vererbt, damit wir das alles tun können.

Dann haben wir uns eine Funktion geschrieben, die Nelgan benutzt, um tatsächlich so einen Parameter zu erstellen. Wir haben eine Funktion, um einen Parameter abzudaten. Wir haben eine Funktion, die uns mit dem Server verbindet. Wenig spektakulär. Wir haben eine Funktion, die mir tatsächlich meine

Entity, also in dem Fall meinen globalen Parameter in der Form der Datenbank sucht und findet und zurückgibt. Und hier unten kommt jetzt der interessante Teil, nämlich der Ansible-Teil selber. Jedes Ansible-Modul hat im ganz zu oben ein Modul drin, das im Wesentlichen eine Sammlung von allen Parametern

ist, die ich verwende. Diese Parameter können entweder required true oder required false sein, sprich bei so einem Formen Management-Modul ist natürlich sinnvoll, dass Server-UIL, Username, Passwort required sind. Klar, ich muss mich ja irgendwie mit dem Ding verbinden.

Ob die Verbindung dann verschlüsselt sein soll oder nicht, das überlassen wir mal dem User selber. Wir setzen es aber defaultmäßig mal auf true. Sprich, wenn er es wirklich anders haben will, dann soll er das bitte reinschreiben. Ansonsten nehmen wir ihm diese Wahl ab. Klar ist auch, wir wollen hier einen bestimmten globalen Parameter

anlegen oder behandeln. Deswegen brauche ich definitiv auch den Namen des Ganzen. Den Value brauche ich eigentlich nicht unbedingt, weil ich kann ihn ja auch löschen. Einfach nur, dafür muss ich nicht wissen, welchen Value er hat. Was ich wiederum brauche, ist der State. Da sind wir jetzt wieder an dem Potenzpunkt.

Der Parameter soll entweder da sein oder weg sein. Und wenn er da ist, aber ein Wert hat, den er vorher nicht hatte, dann soll er geupdated werden. Sprich, den State brauchen wir definitiv. Und dann bietet Ansible tatsächlich schickerweise schon eine Menge Logik selbst an,

die es einem abnimmt, jede Menge If-Abfragen zu schreiben. Was diese Teile hier tut, required if, ist eigentlich relativ simpel. Sie sagt, wenn der State present ist, den der User definiert, dann muss es auch ein Value geben in meinem Playbook. Macht Sinn, oder? Wenn ich den Parameter anlegen will, möchte ich ihn eigentlich auch befüllen.

Gut, man könnte auch einen leeren Parameter anlegen. Ob das jetzt so sinnvoll ist, lässt sich zu überstreiten. Aber ich glaube, man versteht ganz gut, was hier das Prinzip ist, auf das ich hinausgehen wollte. Dann haben wir hier so was wie einen Ausstiegspunkt. Ich hatte schon erwähnt, dass alle Module mittels

Chasen-Input und Output kommunizieren. Sprich meine ganzen Fehlermeldungen, Ausstiegsmeldungen, Rückgabemeldungen müssen alle in Chasen erfolgen. Da bietet Ansible auch schon einiges eingebaut mit an. Und in dem Fall wollen wir das Ansible-Modul hier an dieser Stelle aussteigen lassen, wenn die Nailgarn-Bibliothek nicht installiert ist. Weil dann bringt das alles nichts.

Wir können nämlich nicht kommunizieren. Was machen wir dann weiter? Wir ziehen uns ein paar Werte aus dem Dictionary oben raus. Setzen die um. Ist auch nicht so wahnsinnig spektakulär. Interessant wird es dann wieder hier unten, wo wir tatsächlich Nailgarn benutzen.

Wir verbinden uns mit dem Server hier. Und wir suchen nach meinem globalen Parameter an dieser Stelle hier. Wenn es den globalen Parameter gibt, dann bekomme ich ihn zurückgeliefert an dieser Stelle. Wenn es den globalen Parameter nicht gibt, bekomme ich eine leere Liste zurück. Wenn die Verbindung

zu meinem Formen nicht funktioniert, dann kriege ich einen Fehler zurück und dann steige ich hier aus. Auf diese Art und Weise habe ich Verbindungstest und eventuelles Finden und Suchen des Parameters, mit dem ich gerne weiter verfahren möchte, auf einen Schlag erledigt. Wenn dann mein State auf Present gesetzt ist

und ich einen Wert zurück bekomme, also sprich, dass er schon da ist, dann sehe ich mir an, ob irgendwelche Werte ungleich sind zu der Upstream Version. Wenn das der Fall ist, dann möchte ich es bitte updaten. Ansonsten möchte ich ihn neu erstellen. Ja, und wenn der Parameter State auf Upsand ist,

dann möchte ich ihn einfach löschen. Das ist auch wiederum nicht so spektakulär. Danach, wenn das alles falls es fehlt schlagen sollte, steige ich wieder aus, gebe eine Fehlermeldung zurück und wenn das Ganze funktioniert hat, dann beende ich mein Modul an dieser Stelle und gebe den State zurück. Sprich, ob sich was geändert hat oder nicht. Wenn ich was erstellt

oder geupdatet habe oder gelöscht erfolgreich, dann würde ich an dieser Stelle einen True zurückbekommen, ansonsten ein False. Gut, so weit zum Modul. So würde dann beispielsweise ein Playbook aussehen, mit dem ich dieses Modul benutzen würde. Sprich, der Name meines Tages,

in dem Fall jetzt einen neuen Parameter erstellen. Ich benutze das Modul Form and Global Parameter. Username, Passwort und URL stehen jetzt hier im Klartext drin. Kann man natürlich schicker machen. Zur Demonstrationszwecken reicht es jetzt, glaube ich. Genauso, dass ich hier jetzt keine gesichert oder verschüsselte Verbindungen habe.

Ja, egal. Ich lege einen Parameter an und der hat den Namen The Answer und ich sehe gerade, der hat kein Value. Das darf natürlich nicht sein. Deswegen geben wir ihm da noch ein Value.

Dann mal 42. So, und dann füge ich dieses Playbook einfach mal aus. Dann passiert folgendes. Ich verbinde mich mit meinem Server und lasse sowas,

das ist jetzt sehr vorsichtig gesagt, wie den Factor laufen für die Leute, die auch wissen, was Puppet so tut. Ich sammle letztlich Informationen über den Server, mit dem ich mich verbinde. Dann läuft der tatsächliche Task ab, in dem ich den neuen Parameter stelle. Sagt mir Ansible auch sehr schön hier in gelber Farbe, dass sich was geändert hat. Und danach bekomme ich so was

wie eine Zusammenfassung. Es sind zwei Sachen gelaufen. Eine davon hat was geändert. Keine Fehler. Hat es funktioniert? Ja, hat es. Ich habe jetzt hier diesen neuen Parameter drin, der die Anzei heißt und den der 42 hat. Schön. Sehr schön.

Das ist allerdings der Stand, an dem man ist, wenn man, sagen wir mal, zwischen ein Tag und eine Woche an so einem Ding rumgedoktert hat, bis es funktioniert. Debugging ist nämlich so ein ganz spezielles Thema beim Entwickeln von Ansible Modulen. Warum? Ja, weil ich ganz einfach einen Printbefehl

zwischendrin nicht ausführen kann, weil halt mein blödes Ding nur JSON Outputs mir zurückgibt. Was mache ich da? Ja, gut. Also entweder ich benutze Modul Fail JSON und gebe mir als Message dann meinen Parameter zurück. Ja, geht schon. Kann man auch mal schnell zwischendurch machen. Ist aber jetzt auch nicht so ideal und nicht so schön.

Deswegen möchte ich jetzt noch ganz kurz zum Abschluss zeigen, wie man das Ganze eventuell ein bisschen schöner machen kann. Man kann nämlich ganz einfach Ansible bitten, die Skripte, die es erstellt und dann den anderen Server schickt zu behalten dort.

Also ich habe vorhin gesagt, Ansible baut so was wie ein Python-Skript zusammen, verschickt es und führt es dort aus und löscht es dann anschließend. Und jetzt möchte ich einfach mal, dass es das Ganze behält, damit ich es mir ansehen kann auf dem anderen Rechner. Das mache ich, indem ich jetzt einfach das Ding behalte und danach Ansible im Verbus-Mode laufen lasse. Da kommt ja jede Menge

Output dazu. Da steht alles Mögliche drin, was auch sonst ja sinnvoll sein kann. Worauf es mir aber in dem Fall ankommt, ist, dass ich moment hier an dieser Stelle sehe, wo sieht man das überhaupt? Wo Ansible mir

mein Python-Skript auf dem Zielhost speichert. So, wenn ich jetzt mal auf den Zielhost gehe, in selbiges Verzeichnis, dann finde ich hier auch zwei Ordner. Warum zwei? Wie vorhin gesagt, erst sammle ich die Facts und dann füge ich

den tatsächlichen Task aus. Und dann sehen wir doch mal, ich glaube, dass das hier eigentlich das Richtige sein sollte. Dann sehen wir hier, dass wir die, die das Skript rübergeschickt bekommen haben. Was steht dann in diesem Skript drin? Jede Menge Text,

jede Menge Text. Und an einer Stelle hier, es ist kurz durchgesprungen, steht Zipdata. Und das ist tatsächlich mein komplettes Ansible-Teil, wie ich es brauche, um es auszuführen. Ja gut, also so ist es zu debuggen. Es ist ein bisschen schwierig. Das heißt,

bevor wir das tun, packen wir das Ganze noch aus. Dann bekommen wir ein Debug-Verzeichnis. Und was haben wir in diesem Debug-Verzeichnis drin? Im Wesentlichen ein Ansible-Ordner. In dem Ansible-Ordner steckt die komplette Funktionalität drin, die ich von dem Ansible-Core-Modul

brauche, sprich alle Module, die ich benutze, alle Module-Utils, die ich brauche, alle sämtliche Kern-Funktionalität, was auch immer. Ich habe des Weiteren ein Python-Skript, das im Wesentlichen ah, CD.

Was mache ich denn? Ein Python-Skript, das genau wiederum wie mein Modul aussieht und mir hier die komplette Funktionalität beinhaltet. Und ich habe eine Datei, die ARKS heißt und die enthält im Wesentlichen alle Werte,

die ich in meinem Playbook definiert habe, plus ein paar zusätzliche Werte, die sich Ansible selber zusammengesammelt hat. Was ist jetzt daran so schön? Ja, tatsächlich die Tatsache, dass dieses Ansible-Skript jetzt hier ausführbar ist, direkt ausführbar, nicht durch Ansible durchlaufen muss, dass ich dem hier meine Ansible-Liste

übergeben kann mit den Parametern und dann sehe, was passiert. In dem Fall habe ich jetzt das selbe Playbook nochmal laufen lassen mit dem Value 42 und kriege ja einen ChangeFalls raus. Klar, den Parameter gibt es schon, deswegen ändert sich nichts. Ich könnte jetzt an dieser Stelle, das möchte ich jetzt nicht mehr demonstrieren, aber ich könnte an dieser Stelle jetzt auch in meinen Ansible-Module-Form in Global-Parameter-Py-Skript

reingehen und zum Beispiel PDB benutzen, um tatsächlich Debugging zu betreiben. Und das funktioniert dann sehr schön und das hilft mir dann mein Playbook tatsächlich so in Stücke zu zerlegen, wie ich das gern hätte. Gut. Dann möchte ich gerne schließen, möchte kurz,

Sekunde, möchte kurz hier noch verweisen auf Formen und Ansible. Die Ansible-Dokumentation ist sehr, sehr umfangreich und tatsächlich sehr schön. Da steht auch jede Menge zum Thema Ansible-Modulentwicklung mit drin, inklusive Unity-Tests oder was da auch immer einfällt.

Dann möchte ich auf unsere eigene Ethics, auf unser Ethics-Space in GitHub verweisen, wo jede Menge von uns zu finden ist. Und im Speziellen möchte ich noch auf das Formen-Ansible-Modul-Projekt von Formen hinweisen, wo tatsächlich gerade sehr viel passiert, Module zu erstellen,

speziell auch zum Management von Catello, sprich dem Software-Stände- Verwaltungsplugin für Formen. Und ganz zum Schluss möchte ich noch auf unsere eigene Veranstaltung in München am 19.10. hinweisen, nämlich den Open Source Automation Day, wo es unter anderem auch um Ansible gehen soll. Und damit möchte ich gerne schließen

und mich für die Aufmerksamkeit bedanken und für Fragen natürlich zur Verfügung stehen. Ja, bitte.

Die Frage war von ihm, ob wir Aktiv-Module für Nailgarn schreiben. Ja, wir schreiben Ansible-Module, die die Nailgarn-Bibliothek benutzen. Ja, das tun wir aktiv und wir arbeiten auch aktiv dran, Inkonsistenzen oder Funktionalitätserweiterungen in Nailgarn zu forcieren, damit das Ganze schöner benutzbar wird.

Ja, genau. Noch Fragen? Nein? Gut, dann ansonsten bin ich auch reichbar noch und ich bin auch noch eine Stunde, glaube ich, hier, bevor wir dann leider weg müssen. Gut, danke.