 Guten Tag. Ich bin Felix Kaiser und ich möchte euch halt Ansible vorstellen. Das geht, muss ich gleich sagen, nicht darum euch eine vollständige Einleitung zu geben, wie man Ansible benutzt und euch alles zu erklären, sondern es geht mir mehr darum, euch mal einen Überblick zu zeigen, wie einfach das geht und euch zu zeigen und darzulegen, dass das vielleicht auch für euch Probleme helfen könnte und dass das gar nicht so schwer ist, da reinzukommen und damit anzufangen, dass man das einfach für seine Probleme benutzen kann und einfach mal ein bisschen vielleicht Appetit zu wecken auf Ansible. Ansible ist ein Configurationsmanagement-Tool, so wie andere, wie beispielsweise Puppet oder Chef oder Saltstack. Ansible hat den Vorteil, dass es Agent lässt, das heißt auf den Servern, die ihr damit konfiguriert, läuft kein Demon, sondern es gibt einen Klein, der verbindet sich zu Servern, macht eine Konfigurationsänderung und nachdem er fertig ist, läuft er nicht mehr auf dem Server, sondern er läuft nur während der Konfigurationsänderungen gemacht werden. Ansible verwendet zur Verbindung mit den Servern einfach SSH, das heißt da ist nichts, wo man sich irgendwie zusätzlich Sicherheitsgedanken machen müsste, dass es da jetzt irgendwie einen neuen Demon gibt, der irgendwie geschützt werden muss. Und Ansible hat keine Anforderungen auf den Servern, außer dass dort ein Python installiert ist, aber das ist eigentlich auf allen Gängen Distribution sowieso der Fall, das heißt man kann das eigentlich fast überall verwenden. Ansible-Konfig-Dateien werden in Symformaten um ins Jammel geschrieben, das kennt vielleicht einige, das ist so ein Stand-up-Format. Die Konfig-Dateien sind deklarativ, das heißt das ist anders als im Shell-Skript. Bei einem Shell-Skript gebe ich die Reihe nach, an welche Befehle ausgeführt werden. Bei so Konfig-Management-Systemen wie Ansible gebe ich eigentlich eher an, in welchen Zustand mein System gebracht werden möchte und das Tool kümmert sich darum, dass das System auch tatsächlich in den Zustand gebracht werden muss. Außerdem zeige ich dann nachher noch, es gibt da so eine Templating-Sprache, namens Ginger2, die hat auch nicht Ansible frei erfunden, die gab es auch schon vorher, die wird verwendet, um Konfig-Dateien automatisch zu generieren. Ein weiteres wichtiges Konzept, das ich euch dann zeige, ist idempotenz. Wenn ich Ansible mehrmals starte, dann ist das genauso gut wie wenn ich es nur einmal starte, das heißt, wenn Ansible feststellt, die Änderung, die ich dort ausführen möchte, gibt es schon, dann macht Ansible einfach gar nichts. Was auch noch schön ist, ist, Ansible arbeitet die Dinge, die ich konfigurieren möchte, einfach von oben nach unten ab. Das heißt, wir können da gleich nachvollziehen, wenn ich was in einer Rennvölker hinschreibe, wird das auch in der Rennvölker ausgeführt. Und ich muss mich um sehr viele Funktionen auch nicht selber kümmern, sondern es gibt da fertige Module für, das zeige ich euch auch gleich, für eigentlich alle möglichen Aufgaben. Der Rest des Vortrags ist im Wesentlichen eine große Demo. Und wir gehen das da rein nach ab. Dann fangen wir mal an. Ich habe da mal was vorbereitet. Erstmal das ist so die Zeichnessstruktur, die wir dann am Ende haben werden, also, oder die ich mal vorbereitet habe. Wir fangen gleich mit einem Tool an, das nicht Ansible ist, sondern das Vacrant heißt, das aber nur ganz kurz, was uns das bringt, ist, wir kriegen automatisch einen Test-VM aufgesetzt, der wir jetzt hier live im Vortrag mal eine neue VM haben, die wir nicht irgendwie von Hand aufsetzen müssen, sondern das macht Vacrant für uns, und dann können wir die mit Ansible konfigurieren. Entsible-Cfg ist eine kurze Konfig-Datei, das ist nichts spannendes drin. Side-EML ist das sogenannte Playbook. In Ansible sind Playbooks einfach unsere Anweisungen, wie sonst diese Systeme konfiguriert werden müssen. Und damit das alles ein bisschen übersichtlicher wird, hat Ansible so ein Konzept von Rollen. Rollen sind einfach bestimmte, wiederverwendbare Komponenten, die ich auf bestimmte Hosts drauf konfigurieren kann. Ich kann sagen, ich möchte jetzt sagen mal eine Rolle SNMPD, das werden wir nachher machen, das wird uns einen SNMP-Server installieren und konfigurieren. Oder ich habe hier eine Rolle User, die wird uns benutzte Accounts anlegen und konfigurieren. Okay, fangen wir oben an. Wir brauchen zuallererst mal eine vor MNDiverse testen können. Da habe ich auch wieder was vorbereitet. Wir haben das ein Vacrant-File. Das ist einfach eine ganz kurze Konfig, das ist wirklich nicht lang. Und die wird uns gleich ein leeres, frisches Debian bereitstellen. Das dauert so was wir finden 40 Sekunden, deswegen habe ich das hier schon mal gemacht. Hier ist die Ausgabe von Vacrant. Und wir haben jetzt ein neues leeres Debian. Ich kann da reingehen mit Vacrant SSH. Jetzt habe ich hier einen Benutzer, ich kann auch Route werden oder so. Das ist wirklich ein ganz normales Debian, das ist nichts Spezielles unter. Der Haupt ist, dass jetzt ein LibWord vor allem auf einem Host, auf einem Rechner. So, Enzybil, ich hatte ja gesagt, das Playbook ist dieses Side-Point-Jammel-File. Da trage ich ein, was ich alles machen möchte. Das ist eine Jamel-Datei und das oberste Element ist einfach eine Liste. Das ist jetzt eine leere Liste, das heißt, da passiert genau gar nichts. Das heißt, ich führ jetzt einfach mal Vacrant-Provision aus. Und dann werden alle Aufgaben abgearbeitet, die ich definiert habe. Da ich keine definiert habe, ging das jetzt relativ schnell. Also machen wir mal irgendwas. Wir wollen, sagen wir mal, ein paar Pakete installieren und wir wollen gerne Wim als Editor haben. Also definieren wir, wir möchten gerne auf alle Hosts, die definiert wurden. Das ist jetzt hier nur der eine Testhost. Aber das wird jetzt auf alle angewendet werden. Hier könnte ich jetzt auch einzelne Hosts nennen. Also wenn ich irgendwie eine Testhost hätte, der Test einsieße, dann könnte ich das hinschreiben. Ich kann Hosts auch gruppieren und quasi da eine Gruppe hinschreiben. Aber ich mache es jetzt einfach auf alle, aber es ist nur der eine. Dann definiere ich mir Aufgaben, die ich auf diesen Host anmelden möchte. Und da möchte ich zwei Sachen machen. Erst mal möchte ich überhaupt Pakete installieren. Dazu muss ich immer das Paket angeben. Und ich muss sagen, es soll da sein. Ich könnte statt Present auch App-Send hinschreiben, wenn ich möchte, dass das Paket nicht installiert ist. Also ich sage quasi nicht installiere mir das Paket, sondern ich möchte, dass das Paket soll installiert sein. Wenn sie geprüft ist, ist es schon installiert. Wenn ja, dann macht es gar nichts. Wenn nein, dann installiert es das Paket. Und Wurf-Items ist jetzt eine Liste von Paketen, die ich installieren möchte. Weil es ein DBN, vor allem ist das jetzt DBN-Paket-Namen einfach. Und diese Paket-Namen werden dann in dieses Stückchen Ginger2-Config in diesen Ansible-Playbook immer hier eingefügt. Und dann wird quasi dreimal diese App-Taske ausgeführt. Nämlich einmal für das Package Wimlocks, einmal für das Package Screen und einmal für das Package Hardtop. Das sind ja Pakete, die wir alle kennen und die wir eigentlich auch alle immer überall installiert haben wollen. Deswegen dachte ich, das ist vielleicht ein gutes Beispiel. Außerdem wollen wir, vielleicht, nachdem wir so ein Wim installiert haben, mal den Wim als Default-Editor auf unserem System einrichten. Da gibt es jetzt ein Task, der heißt Alternatives. Der ist auch von Ansible vor definiert, genauso wie der App-Task hier oben. Und der verwendet das DBN Alternatives-System, um meine Editor auszuwählen. Ich habe das jetzt mal so definiert. Und dann provisionieren wir das oder konfigurieren wir das mal da drauf. Das geht jetzt relativ fix. Jetzt prüft er, macht erst mal ein Update von den Paket-Listen. Jetzt prüft er, es sind die Pakete, die ich da haben möchte, bereits vorhanden. Und er hat festgestellt, sie waren noch nicht vorhanden. Deswegen hat er sie installiert. Und deswegen steht jetzt hier auch Changed. Also an diesem Task, den ich da definiert habe, installiert mit diesen drei Pakete oder Sorge dafür, dass sie vorhanden sind, hat er festgestellt, da war noch irgendwas, war noch nicht richtig. Deswegen hat er das jetzt geändert und mir das als Changed markiert und das jetzt gemacht. Und wenn ich jetzt weg rinde SSH mache, sehe ich, ich habe jetzt auch ein Hardtop installiert. Hurra, das war vorher nicht der Fall. Item Potenz hatten wir vorher gesagt, wenn ich das mehrmals mache, passiert genau gar nichts. Der einzige Unterschied ist, Enzybel merkt jetzt, ich muss nichts machen und zeigt mir die Zeilen nicht mehr in gelb mit Changed an, sondern in grün und sagt, okay, da war schon so, ich habe gar nichts getan. Genau, machen wir nochmal noch ein bisschen was anderes. Sagen wir, wir wollen mal Benutzer anlegen. Sorry, wir sind hier unten. Und da zeige ich euch jetzt zwei Konzepte. Das erste sind Variablen, ich kann mir Variablen definieren, damit das jetzt ein bisschen lesbarer und kurz bleibt für den Vortrag, habe ich das hier direkt in der Datei gemacht. Ich kann aber Variablen an verschiedensten anderen Stellen definieren. Ganz global für Gruppen von Hosts, für einzelne Hosts, für einzelne Tasks. Ich kann Variablen sogar dynamisch erzeugen lassen oder ich kann auch von externen Skripten mir Variablen holen lassen. Da gibt es relativ unbegrenzte Möglichkeiten. Und zwar habe ich jetzt eine Variable, der ist admin keys. Diese admin keys Variable enthält, ist ein Dictionary mit dem Schlüssel Entropia und als Value habe ich dann jetzt hier diesen SSH RSA. Das ist natürlich kein echter SSH Key, das ist nur damit man das jetzt im Vortrag schön sieht. Das ist jetzt ein schöner, kurzer SSH Key. Und den würde ich gerne für den Benutzer eintragen lassen. Außerdem würde ich überhaupt gerne erstmal Benutzer anlegen lassen. Und sagen wir mal, der Benutzer soll den Username Entropia haben und Role User sagt, dass ich diese Userrolle, die ich mir jetzt irgendwo definieren muss, weil es die erstmal noch nicht gibt, die Sachen machen muss, als sinnvoll, als default vorhanden sein oder denkbar sind, genau diese Rolle soll es verwenden. So, jetzt zeige ich euch nochmal die Gesamtstruktur von dem Projekt. Wir haben hier so ein Ordner, das heißt Roles. In dem Ordner Roles gibt es ein Ordner User, darin gibt es einen Ordner Tasks und darunter gibt es einen Datei Main.email, die heißt immer so. Also geben wir mal da rein. Roles, User, Tasks, Main jammel und da haben wir jetzt drei Tasks definiert. Der erste Task ist ein User Task. Das ist wieder ein von Ansible bereits vordefiniertes Modul. Das muss ich nicht selber schreiben. Das funktioniert auch auf allen gängigen Linux-Distributionen. Also das kümmert sich automatisch um so Plattform-Varianzen, wenn das irgendwo verschieden funktioniert. Und der braucht natürlich den Benutzername. Das heißt, ich füge wieder eine Variable ein und die Variable habe ich ja hier oben im Playbook definiert. Nämlich hier bei Username habe ich gesagt Entropia. Und außerdem soll der Benutzer sag mal mal in die Sudo-Auchs-Gruppe reingetan werden. Und wenn ich von Hunter noch um die andere Gruppen hinzugefügt habe, dann soll die nicht überschrieben werden, sondern die Sudo-Gruppe soll nur angehängt werden. Außerdem würde ich den Benutzer gerne SSH-Kies mitgeben können. Da füge ich hier wieder als Variable den Username ein. Und ich würde gerne alle SSH-Kies aus diesem in der Liste in dem Dictionary unter dem Schlüssel von dem Benutzername gerne für den Benutzer eintragen. Das heißt, ich habe hier ja Admin-Kies als Variable. Das ist wieder ein Dictionary von Benutzername zu einer Liste von SSH-Kies gewesen. Über diese SSH-Kies rede ich jetzt einmal drüber. Und für jeden von diesen SSH-Kies ist es jetzt nur einer, ruf ich einem Authorized-Kies auf den Task. Das ist auch von Ansible-Fore definiert, der mir das SSH-Authorized-Kies-File anlegt, ändert wie auch immer um meine Ziele zu erreichen. Und zwar für diesen Benutzer. Und außerdem, wenn ich den sowieso schon in Sudow gepackt habe, den Benutzer da, da kann ich so ein SSH-Kies auch gleich noch unter dem Benutzer-Root speichern, warum nicht. Mehr ist das nicht, das führen wir jetzt einfach mal aus. Ansible stellt jetzt wieder fest weiter oben die Tasks, die ich schon vorhin ausgeführt habe, nämlich dieses Alternatives und das Pakete installieren, sind nach wie vor ungeändert. Und hier unten die Tasks habe ich jetzt neu definiert. Das heißt, die haben sich offensichtlich geändert, mit einem Benutzer angelegt und Authorized-Kies eingetragen. Und wenn ich jetzt mal in diese vor allem reingehe und die Kies zeige, dann, sorry, falsche User. LSD Home, da hat er irgendwie so ein Homeverzeihung angelegt. Es gibt jetzt auch irgendwie Benutzer in die DTC Password, PassWD. Und natürlich gibt es auch in Tropia SSH Authorized-Kies, ein Authorized-Kie, der jetzt eingetragen wurde. Das ist auch tatsächlich so ein bisschen das, was man immer als Lernübungen, als allererste Config Management-Übung macht, SSH-Kies verteilen wird. Das ist eine super simple Aufgabe. Die kann man, die ist relativ gut dokumentiert und damit kriegt man so ein generelles Gefühl, wie man irgendwie dieses Ansible verwendet. Und von dort an kann man dann natürlich weiterarbeiten. Und genau das machen wir jetzt. Wir wollen mal noch ein bisschen mehr von Ansible sehen. Deswegen wollen wir jetzt, sagen wir mal, noch ein paar andere Tasks verwenden. Wie wir sind hier. Beispielsweise wollen wir jetzt mal eine Config-Datei ändern, also eine existierende Datei ändern. Dann nehmen wir jetzt zum Beispiel mal die ETC All-Yeses-Datei. Wir sind jetzt ein bisschen geschummelt, weil die ETC All-Yeses gibt es tatsächlich bereits ein Ansible-Task, aber angenommen, es gäbe noch kein und ich möchte wirklich in einer Datei rumeditieren. Das ist ja ein häufiger Anwendungsfall, dass ich irgendeine Config-Datei habe und ich möchte dann die Zeile austauschen. All-Yeses sieht unter die Beeren starten wir sie erstmal so aus und ich möchte jetzt hier diese Rout-Zeile irgendwie ändern. Da gibt es von Ansible-Modul, das heißt Line in File. Das macht genau das. Das sucht nach einer Zeile, die diesen regulären Ausdruck matcht und sorgt dafür, dass die Zeile, die diesen regulären Ausdruck matcht, hinterher so aussieht, nämlich Rout-Doppelpunkt und dann fügt man ja die Variable Admin-Mail ein. Die haben wir hier oben definiert, das soll textletexample.com stehen und zwar in der Datei etc. All-Yeses. Außerdem, also das ist jetzt eine Möglichkeit, wie ich Dateien ändern kann, eine andere Möglichkeit wäre der Copy-Task. Da kann ich eine Datei einfach eins zu eins von meiner Ansible-Konfiguration auf den Server, den ich da gerade konfiguriere, hochkopieren. Das kann jetzt entweder nur eine lokale Datei sein oder wenn ich aber weiß, dass ich da nur ein Einzahler reinschreiben möchte, dann kann ich das auch direkt hier in den Playbook mit hinschreiben und deswegen habe ich jetzt einfach mal Content auf den Lernstring gesetzt, weil ich dieses Mod Defile einfach mal löschen möchte. Jetzt füge ich mal die beiden Sachen aus. Das sollte jetzt wieder relativ fix gehen. Hallo, Ansible. Aber warum? Das ist interessant, das ist beim Testen nicht passiert. Wie bitte? Wenn du auswendig weißt, wie das geht. Okay. Na gut. Nächstes tatsächlich. Ansible, Paar Staff. Ich könnte doch jetzt hinschreiben, das ist ein bisschen unaufgreuen. Probieren wir es aus, bis es tatsächlich schneller geht. Wow, vielen Dank. Hilfe aus dem Publikum, sehr wünscht. Na gut. Wo waren wir? Wir wollten jetzt diese aliases Datei ändern und die modd-Datei ändern und das ist natürlich auch selbstverständlich passiert. Das heißt, wenn ich mir jetzt irgendwie eine Shell gebe, ich zeige euch jetzt mal nicht beide, sondern nur eine von beiden, dann ist das da jetzt eingetragen worden. Und was auch noch ein wichtiges Feature ist, ist, wenn ich natürlich ein bisschen eine komplizierte Datei-Enderung machen möchte, wenn ich eine Config-Datei habe und ich möchte irgendwo in der Mitte-Variable einfügen, dann wäre das natürlich ein bisschen aufwendig, wenn ich das jetzt leider in den Fall machen würde, wenn ich jede Datei einzel definieren müsste. Und da hat Ansible so ein Templating-Modul für. Ich habe mir da jetzt mal das Beispiel, was wir da jetzt nehmen, ist, wir wollen SNMP-Demon aufsetzen, also einfach ein kleiner Demon, der mir jetzt über das Netzwerk erlaubt, eine Werte abzufragen. Und SNMP hat so ein Community-String als Passwort. Das ist jetzt sehr geheim, natürlich. Und außerdem wollen wir gerne den Zugang auf eine Reihe von Subnetzen beschränken. Roles SNMP-D habe ich schon mal definiert. Da müssen wir jetzt erstmal sagen, wir brauchen irgendwie ein paar Pakete, deswegen installieren wir, wie vorhin schon gezeigt, ein paar Pakete. Und dann führen wir dieses Template aus. Und dieses Template ist jetzt in einer Sprache geschrieben, die heißt Ginger2. Und das sieht so aus, das ist einfach jetzt ein ganz normales Config-File. Aber hier in der Mitte sind so spezielle Ginger2-Anwendungen. Hier iterieren wir jetzt einfach mal über alle Hosts in Trusted Subnets. Das ist tatsächlich ein spannender Back. Das sollte eigentlich so aussehen, denn wir wollen eine Liste von Alpiatrassen dort einfügen und keine Einzelne. Interessieren wir da einfach mal drüber. Für jeden von diesen Trusted Subnets, das wir da definiert haben, das ist nur eins, wir können ja mal irgendwie noch ein zweites machen. Fügen wir so eine Zeil-Row-Community ein und dann die entsprechenden Variablen. Und SNMP-Community ist ja die Variable, die wir einmal global gesetzt haben. Das ist dieser Zugangswert. Und Subnet sind halt die Alpiatrassen, die dafür freigeschalten sind. Genau. Und natürlich haben wir jetzt noch das Problem, wenn wir diese Konflikt-Datei geändert haben, müssen wir natürlich den SNP-Demon auch hinterher neu starten. Und dafür hat Ansible ein System, das heißt Notify und Handler. Und deswegen kann ich einfach unter so einem Task Notify-Doppelpunkt hinschreiben und dann ein String, das ist kein besonderes Format, das ist ein beliebiger String. Und dann kann ich mir in meiner Rolle unter Handlers ein Handler definieren. Hier ist der gleiche String nochmal, darüber matched Ansible das und der Handler ruft dann den Ansible-Service-Task auf. Das ist jetzt wieder ein vordefinierter Ansible-Task, der sich um das Handling von Demons kümmert. Also wenn ich ein Demon enable möchte, disable möchte, starten und stoppen möchte oder restarten möchte, dann kann Ansible das einfach für mich übernehmen. Und zwar unabhängig davon, ob ich jetzt auf dem DB-Jahren bin, ob ich unter einem Fedura bin oder wo ich bin. Gut seit SystemD ist das jetzt nicht mehr so spannend. Da gibt es eh noch den einen Weg. Aber ich möchte den SNMP-Demand restarten. Genau. Und wenn ich das jetzt mal wieder ausführe, dann kriegen wir da ein SNMP-Demand installiert. Wir haben eine schnelle Interface-Einbindung, das sollte sehr fix gehen. Theoretisch. Hura. Vacrant SSH. Wenn ich mir jetzt mal irgendwie sagen lasse, ob der läuft, dann sollte der auch tatsächlich laufen. Hura. Genau. Das ist ein bisschen der Demoteur von dem Vortrag gewesen. Wir haben gesehen, wir können relativ einfach so Sachen machen.gomare Pakete installieren, Benutzer anlegen, Konflikt-Dateien auf verschiedene weisen ändern. Und wenn ich irgendwie erweitertere Aufgaben hab, dann kann ich, gibt es da ja auch meistens schon was... Wenn ich jetzt mal was mit Datenbanken machen möchte, sagen wir mal, wir haben ja eine Postgres und wollen da jetzt so eine Datenbank anlegen, dann gibt es hier immer eigentlich für die allermeisten kann man auch selber machen. Das schreibt man dann bestens in Python, aber muss man nicht. Und da gibt es auch meistens Copy-Paste-Bauer-Examples, die ich nutzen kann. Das sagt man mal, wenn ich jetzt hier irgendwie so ein System, wenn ich so irgendwie so einen Benutzer anlegen möchte, dann suche ich mal irgendwie nach User. Und da sollte es irgendwie unten eine Liste von Examples geben, wo ich mir einfach eins nehmen kann, dass Copy-Paste kann. Also man muss da, man kann da relativ fix zu relativ fehlsachen hinschreiben. Außerdem gibt es von der Community, also das sind, was ich jetzt gerade gezeigt habe, diese Module sind die direkt in Ansible integrierten. Außerdem gibt es Ansible Galaxy, da werden komplette Rollen, also quasi Sammlungen von Modul aufrufen, ausgetauscht. Wenn ich jetzt was Größeres vorhab, sagt man mal, ich möchte irgendwie einen Telefonieserver aufsetzen, dann ist das natürlich nicht mit einem einzigen Task getan, sondern dann muss da natürlich ein bisschen mehr passieren. Und da gibt es unter Ansible Galaxy bereits von anderen Leuten fertige Konfigurationen, die ich mir einfach in meine eigene Konfig reinklonen kann und damit ausführen kann, vielleicht ein bisschen konfigurieren kann, aber ich muss nicht alles neu schreiben. Das ist ganz nett. Ich würde gerne wieder dahin, wo wir gewesen sind. Wir haben gesehen, wir haben irgendwie Tasks, wir haben Playbooks und Rollen. Plays sind innerhalb der Rollen, die einzelnen Dateien und Playbooks waren, sind ganz oben in der Obersen-Heraschie-Ibne, die Dateien, wo ich meine Aufgaben definieren, gruppen, habe ich jetzt nicht gezeigt. Ich kann Hosts auch einfach in Gruppen hinzufügen und auf ganze Gruppensachen anwenden. Facts ist das, was wir vorhin abgeschaltet haben. Ansible sammelt automatisch eine, Verzeihung, Hallo Computer. Ansible sammelt automatisch eine Reihe von Fakten ein, an der ich euch Entscheidungen treffen kann. Das sind Sachen wie was ist in meine Akt, was ist denn, was habe ich denn für eine Linux-Systemation, welche Version ist das, was sind meine IP-Attressen, brauche ich alles nicht selber bestimmen. Ansible sammelt das ein, ich kann das natürlich erweitern. Wenn ich jetzt Ansible mal irgendwie direkt ausführe und Hosts, das ist jetzt die Liste von Hosts, die ich habe und ich möchte ein, ich möchte mir mal anzeigen lassen, was es da so für Fakten bereits gibt, dann kann ich das einfach mal ausführen. Und dann zeigt mir Ansible das an, was es da alles gibt. Also es ist ein sehr nützliches Feature. Außerdem habe ich euch jetzt dadurch gerade gezeigt, sobald ich einmal so ein Ansible Konfig hat, kann ich den natürlich auch benutzen, um wie jetzt hier in dem Beispiel so AdToc-Befil auszuführen. Also jedes einzelne Ansible-Modul kann ich auch direkt von der Kommando-Zeile aus ausführen. Das ist natürlich ein bisschen langweilig, wenn ich sage, ich möchte einen Shell-Befil ausführen und zum Beispiel die Abtime rauskriegen auf all meinen Hosts, auf allen meinen Hosts. Das ist jetzt auch ein bisschen langweilig, weil es gibt jetzt natürlich nur ein Host, aber wenn ich da jetzt ein paar hundert Hosts habe, ist das vielleicht leichter, als wenn ich mir da irgendwie ein eigenes Bash Script schreibe, dass ich überall hin ist hart und dann ändert sich die Gruppe von Hosts sich ab, fragt man sich, das ist ganz nett, wenn das Ansible für mich alles abnimmt. Und das könnte ich natürlich auch benutzen, um jetzt sagen wir mal irgendwie eine Konfig-Änderung gezielt manuell auf allen Hosts zu machen, indem ich irgendwie sagen wir mal das Leinen-Fall-Modul verwenden würde oder ein anderes Modul, was auch immer. Ich habe halt alle Module zur Auswahl. Genau Ansible hat, wie gesagt, ja relativ viele Tasks und ich habe euch auch ein paar davon gezeigt, also Template zum Beispiel, um irgendwie Konfig-Dateien zu generieren, Service und Service zu restarten. Ein nützliches Tool, was ich euch gerne noch zeigen möchte, ist Checkmode. Ich kann nämlich Ansible auch einfach ausführen, ohne dass er tatsächlich Änderungen macht. Also ich führ das jetzt mal wieder auf. Minus e Host, der Vorstellung, die Liste an Hosts sehen. Side Yumble ist mein Playbook und ich möchte Checkmode haben. Jetzt macht er keine Änderungen selber, sondern prüft nur mal, welche Änderungen er machen würde, ohne die bereits anzuwenden. Das heißt, wenn ich jetzt hier eine Änderung mache und erwarte, dass ich mit Checkmode ausführe, dann erwarte ich, dass er mir das herausfindet und mir das sagt. Das ist sehr praktisch beim Debacken, weil dadurch kann ich erwarte, dass es keine Änderungen gibt oder wenn ich erwarte, dass ich keinen Fehler gemacht habe und kann ich dadurch testen, ob mein Playbook immer noch funktioniert. Genau, da sind so ein paar grundlegende Features. Atok-Commands habe ich euch ja gerade gezeigt. Ich kann die ganzen Ansible-Module auch von der Kommandezelle ausführen. Und genau, das ist so ein bisschen das, was ich euch zeigen wollte. Es gibt dann noch sehr viele weitere Themen, die ich euch nicht gezeigt habe. Warum eigentlich? Variablen haben eine gewisse Hierarchie. Das heißt, ich kann erst mal relativ allgemein Defaults machen. Zum Beispiel kann ich für eine Gruppe von Hosts irgendeinen Default festlegen und dann kann ich den Default für einen einzelnen Host überschreiben. Es gibt eine lange Liste von Hierarchiestufen, die aber trotzdem relativ logisch ist und das kann ich verwenden, um quasi Defaults festzulegen. Ansible hat es relativ viel an weiteren Sintags noch. Was heißt viel? So viel ist es nicht. Aber wenn ich jetzt sage mal, eine Abhängigkeit von irgendeiner Bedingung, irgendwas machen wir stark, gibt es dabei einen Führer und es gibt noch viele, viele andere. Es gibt was für Fehlerbehandlungen und so weiter. Secrets Management ist ein Thema, das wollte ich jetzt im Vortrag auch nicht zeigen. Ansible hat eine Möglichkeit, Variablen in der Verschlüsselten-Datei anzuspeichern und die dann quasi nur zu entschlüsseln. Während des Deployments, dadurch kann ich, wenn ich möchte und relativ schnell fertig sein möchte, meine Geheimnisse, meine Routepassworte oder so, auch einfach mit in meinen Git Repositoriereinkommitten und es kann trotzdem niemand lesen, denn es ist verschlüsselt. Da man kann sich da auch sehr problemlos GPG Integration bauen. Wenn ich mehrere Admins habe, ist es sehr praktisch. Dann kann jeder das mit seinem eigenen GPG Key entschlüsseln. Das kann man machen. Ich habe euch ja vorhin gezeigt, dass Ansible so Fakten automatisch einsammelt. Das kann ich natürlich auch erweitern und außerdem kann ich diese Fakten, nachdem ich sie eingesammelt habe, natürlich auch in der externen Datenbank abwerfen. Also wenn ich jetzt, sag mal mal, meine Datenbank von allen meinen Hosts haben möchte, wer das eine Möglichkeit oder ein Klassiker ist, wenn ich, sag mal mal, eine ganze Reihe von Hosts übereinander mit gleichzeitig professionieren, dann kenne ich ja auch alle, die er ssh kies. Und da könnte ich ja jetzt, sagen wir mal, zum Beispiel auch einen SSH known Hosts fall automatisch generieren für alle meine Hosts. Und das ist auch ein Fall, den Ansible Halpex einfach macht. Aber es gibt das Problem ist ein bisschen Ansible selber hat. Keine hat da nichts integriert, um irgendwie externen Daten zu speichern. Man müsste sich dann, man müsste dann halt zu externer Software greifen. Also der Klassiker wäre, dass man den ACID aufsetzt. Und Ansible hat dann wieder eine Module, um in so ein ACID, das so ein verteilter Keyvaluestore für, zum Betrieb von Netzwerken eigentlich ist, dort einen Wert reinzuschreiben. Also das könnte ich auch alles in Ansible integrieren. Es gibt noch eine einfache Möglichkeit, du kannst das inventory-File, das executable bit setzen, dann wird das von Ansible ausgeführt und erwartet halt als Rückgabewerten JSON. Und da drüber kannst du dann halt diverse APIs etc. alles polen und variablen halt auf inventory Ebene setzen. Ja, das kannst du machen. Das Problem ist, oder das heißt kein Problem, das kannst du natürlich machen. Das ist besonders nützlich, wenn du keine eigenen festen physischen Hosts hast, sondern wenn du irgendwo so einen Amazon-AWS-Account sag mal mal hast und da viele VMs drin hast, die willst du natürlich nicht fest konfigurieren, sondern dynamisch auslesen können, welche du hast. Dann kannst du auch ein dynamisches inventory von Hosts haben. Genau dafür ist es da. Aber das löst nur ein Teil des Problems, denn der Fall, den ich ja gerade hatte, ist, dass du Informationen über die Hosts wieder in die Hosts reinkonfigurieren möchtest und das können ja potenziell sag mal mal auch mal Hosts sein, die nicht unbedingt von Ansible gemanagt werden, sondern noch von woanders, oder sag mal mal du möchtest hinterher die Informationen nicht in Ansible haben, sondern du möchtest sag mal in dem Webinterfessen eine Liste von allen Hosts haben oder was auch immer und dann bist du doch wieder gut beraten, wenn du eine externe Datenbank hast, wo du die Werte reinspeichern kannst. Aber Ansible selber hat da keine, hat da nichts integriert, ist aber da flexibel und hat da zumindest Support für verschiedene solche Datenbanken. Ja, was du aufhochst, ist hier einfach nur ein Rapperscript, da kann ja eine Datenbank oder sonst irgendwas dahinter stehen, das muss nicht unbedingt die Amazon-App sein. Es war jetzt Amazon war natürlich nur ein Beispiel selbstverständlich, also ich wollte auch nicht unbedingt Werbung für Amazon machen. Naja, Ansible unterstützt offensichtlich natürlich mehrere Linux-Distros, also eigentlich alles gängige, es hat auch Windows-Support, wobei man nur Windows-Rechner konfigurieren kann, man kann Ansible selber, also man kann quasi als Administrator nicht Windows verwenden, aber man kann da für seine Server Windows verwenden. Keine Kommentar. Ansible hat, das habe ich jetzt auch nicht gezeigt, verschiedene Möglichkeiten an verschiedenen Stellen nochmal tatsächlich Code einzufügen und Plugins zu schreiben, um Ansible an verschiedenen Stellen zu erweitern. Eine so eine Sache, die man so bei so Config Management Tools, gerade wenn man jetzt nicht alleine arbeitet, sondern in einem Team gerne haben möchte, sind Frontends, die einem so ein bisschen die Koordination zwischen den Administratoren erleichtern. Da gibt es bei Ansible de facto nur einen Frontend von Tower, das ist direkt von den Entwicklern von Ansible geschrieben, ist Close Source gewesen und ist, wie sich Ansible Works die Firma hinter Ansible finanziert. Glücklicherweise wird Ansible Works gerade von Red Hat gekauft und weil Red Hat eine Open Source Firma ist, wird Tower dann jetzt auch Open Source werden, was sehr schön ist. Eine Frage, die man sich stellen muss, die Ansible überhaupt nicht löst, ist Provisionierung, also sprich, wie kriege ich eigentlich, wie komme ich eigentlich zu meinem Server oder wie komme ich eigentlich zu meiner VM, die ich dann mit Ansible konfiguriere. Da hat Ansible keine Antwort drauf, weil das einfach Auto aufs Grupp von Ansible ist. Ich habe das jetzt in dem Vortrag mit Vagrant gelöst, was zum Testen eigentlich eine gute Entscheidung ist. In Produktion ist Vagrant keine gute Idee, da gibt es aber andere Tools, wie zum Beispiel Kubernetes. Eine wichtige Frage, vor der ich persönlich gestanden habe, weil ich Ansible angefangen habe, in unserem Hackerspace einzuführen, um die Konfiguration ein bisschen zu erleichtern und um dafür zu sorgen, dass es akkurate Doku gibt, denn Ansible Playbook selber sind ja effektiv ausführbare Dokumentationen, weil das sind einfach relativ kurze, relativ prägnante Konfigurationsdateien und die dienen dann noch gleich als Dokumentation. Das Problem ist aber in unserem Hackerspace wollen wir nicht immer alle vor allem komplett redeployen, weil es halt dann doch wieder einige Sachen gibt, die von Hand gemacht werden und das ist nicht so der übliche Use Case für so Config Management Tools, das klappt mit Ansible relativ gut tatsächlich in der Praxis. Da ist man aber in einer Nischen Anwendungsgruppe, wenn man das machen möchte. Aber genau, was wollte ich nur mal erwähnen, das geht sowohl, wenn man es immer alles redeployt, als auch, wenn man nur das nicht macht, sondern das langelebig sind. Genau, das waren ein paar Themen, über die ich sprechen wollte. Ein letzter Fakt, auf den ich hinweisen wollte ist, ich habe ja gesagt, diese Playbooks sind in Jammel geschrieben und auch hier zitat aus der Ansible Doku, Playbooks are expressed in Jammel Format and have a minimum of syntax. Das ist immer ein bisschen ein Werbeversprechen von Ansible. In der Praxis stimmt das aber nicht. Hier in Grünen gezeigt ist tatsächlich, was Jammel ist. Grau sind von Menschen vergeben, also von mir in dem Fall vergeben ist Trings, das ist natürlich zu entschuldigen. Ansible hat so ein Custom Key Value Format erfunden, mit dem MSG ist gleich. Das ist überhaupt kein Standard Format und ist auch manchmal speziell im Pausing. Also braucht dann ein bisschen Intuition, wie Ansible, dass der dann Pausen mescht. Das ist nicht hundertprozentig vorhersehbar. Man kann den Ansible an verschiedenen Stellen Python Code einfügen und macht das auch. Jetzt ist hier in Blau gezeigt und bevor der Python Code ausgeführt wird, ist das erstmal ein Ginger Template, das den Python Code generiert und hier wird jetzt quasi in Rot eine Variable über diese Ginger syntax eingefügt. Also das ist jetzt alles in einer Datei. Das ist eine Datei, die offiziell laut Doku alles Jammel ist, aber de facto sind das jetzt hier vier verschiedene Sprachen. Fand ich lustig, wollte ich noch mal darauf hinweisen. Den Code, den ich vorhin durchgegeben, den ich vorhin gezeigt habe, verlinke ich nach einem Wiki, was beziehungsweise ist bereits verlinkt. Und genau, das war so ein bisschen mein Vortrag. Ich hoffe, ich konnte euch zumindest zeigen, dass es nicht schwierig ist, damit anzufangen, dass man nicht umfangreiche Konfig Dateien schreiben muss, bevor man damit anfängt und dass man einfach relativ schnell relativ kleine Probleme wie zum Beispiel legt mir meine Benutzer auf allen meinen Hosts an und fügt meinen, es ist Hackies überall ein mit Ansible lösen kann und dadurch relativ schnell sich Arbeit sparen kann. Und wenn man dann anfängt mehr mit Ansible zu machen, dann kann man da natürlich weitergehen, aber man muss natürlich nicht. Okay, vielen Dank. Habt ihr Fragen? Ja, eine Frage. Mikrofon bitte für die Streams. Fängt alles an, kaputt zu gehen, wenn mal ein Administrator eine Konfigurationsdatei doch von Hand editiert oder? Ansible würde das ja in dem Fall erkennen, das habe ich ja vorhin auch gezeigt, wenn eine Konfigurationsdateien vorhand editiert wurde und würde die natürlich überschreiben und würde das auch sagen, dass die überschrieben wurde. Man kann über einen Mischte und was man also gibt ein sehr nutzliches Tool namens ATC Keeper, das einem in ATC Changes tracked und ich habe da vor eine Weile für genau diesen Fall für unseren Hackers Best mal Ansible ATC Keeper Integration geschrieben, liegt auf GitHub, kann man verwenden und dadurch würden so von Hand gemachte Changes auch automatisch getrackt werden und nachdem die von Ansible überschrieben wurden, kann man auch wieder auf die alte zurückgehen. Also sowas müsste man dann verwenden, wenn man so ein Mischbetrieb fährt. Beantwortet das deine Frage? Mikrofon, bitte. Mischbetrieb klingt ein bisschen nach Abweichung von gängigen Best Practices. Es ist Abweichung von den gängigen Best Practices, aber das liegt einfach daran, dass das Konfigurationsmanagement-Themen aus einer Gruppe von Einwendungen kommt, die deutlich mehr Sauber haben als ich zu Hause, als Student und wenn man seine Server teils von Hand und teils automatisiert betreibt, ist man definitiv nicht der klassische Anwender, aber Ansible kommt da in der Praxis sehr gut damit zurecht und wenn man eine halbwegs offensichtliche Trennung hat, was von Ansible gemacht ist und was von Hand gemacht ist, dann wird man überhaupt keine Probleme haben. Also wenn man zum Beispiel sagt, ich installiere so ein Basispaket über Ansible, ich lege Benutzer über Ansible an, aber ich mache jetzt sagen mal zum Beispiel nicht meine Webserver-Config über Ansible, dann wird es in der Praxis da einfach überhaupt keine Probleme geben. Also ich habe zum einen eine Anmerkung, man kann Ansible auch so konfigurieren, dass es die Dinge, die es überschreiben würde, in Wirklichkeit unbenannt, mit irgendwie tilde Backup, sonst noch was, wenn man das möchte, so dass die Sachen da nicht verloren gehen und zum anderen wollte ich dich fragen, was dein Workflow ist, wenn du mit mehreren Menschen, mehreren anderen Menschen irgendwie administriert hast, hast du dann irgendwie die Ansible-Config in einem Git und jeder macht das von seinem Rechner aus oder habt eine VM, wo das drauf läuft, wie läuft das? Also was ich in den drei separaten, dreieinhalb separaten Infrastrukturen, wo ich Ansible verwende, mache ist auf jeden Fall ein Git für die Ansible-Konfiguration verwenden, das ist eigentlich in meinen Augen absolut unerlässlich, aber das ist sowieso einfach nur Best Practice für Softwareentwicklung oder Konfigurationsentwicklung generell, also ich verwende immer überall so viel Git wie nur Git. Das löst zumindest das Problem, dass irgendwann die Änderungen nachvollziehbar sind und dass man hinterher sagen wir mal auch Änderungen, dass man leicht auf einen vorherigen Stand zurückkommt. Du hast natürlich so ein bisschen so ein Koordinationsproblem, was passiert, wenn zwei Leute gleichzeitig ein Server anfassen. Da hat Ansible selber keine gute Lösung für. Du kannst entweder, du bist ungefähr ein bisschen in Kommunikation mit deinen Mitarbeitern oder du fürst einen zentralen Server ein über den deploy wird und sorgst dann dort dafür, dass alle immer auf dem gleichen Stand sind und nicht sagen wir mal einen älteren Stand über einen neueren Stand deployen oder du verwendest eins der Frontends wie zum Beispiel Tower. Es gibt tatsächlich sogar Leute, die Ansible und Continuous Integration Systeme miteinander kombiniert haben, was dann dazu führen würde, dass du niemals direkt auf Produktions-Server deployen würdest, sondern immer nur in deine Testumgebung, dann würdest du den Code an deinen Code-Review-Tool pushen, das würde dort reviut werden, das würde dort von dem Server in einer Stadion-Umgebung getestet werden und wenn das funktioniert, automatisiert in deine Live-Umgebung gepusht werden. Also man kann das beliebig weit treiben. Ansible selber hat da keine Antwort für, das müsstest du selber bauen. Ja, ich komme aus der Puppet-Wells und ich wollte mal fragen, du definierst da Magic, war variablen an irgendeinem Punkt, woher kann ich, wie habe ich die Kontrolle darüber, wo, also das ist mich andersherum ausbrücken angenommen, ich definiere irgendwo war, wie verhindernst du, dass das überall weiter runter die ganze Schiene magischer variablen erzeugt. Verstehe ich das richtig, dass es dir um die Reihenfolge geht, damit du, dass du den Überblick haben möchtest, wo variablen definiert werden und wo die dann wieder herkommen. Angenommen nicht, also in der Puppet-Welt ruf ich ein Modul mit Parametern auf. In dieser Welt definiere ich variablen global. Ich habe jetzt nur für den Vortrag variablen global definiert. In der Realität würdest du variablen dann natürlich pro host definieren oder pro Gruppe von host oder in deinem Inventory, es gibt da verschiedene Möglichkeiten. Ich habe das jetzt hier nur, damit es alles in einer Datei ist, damit es leichter zu präsentieren ist, direkt global definiert, das musst du nicht machen. Das kannst du natürlich machen, wenn du sag mal eine globale E-Mail-Adresse hast, an die, was weiß ich, an die die irgendwo als gut E-Mail gesetzt werden möchte, dann ist das ein guter Kandidat für eine globale Variable, aber du musst nicht. Da du Puppet ansprichst, möchte ich einen der wichtigsten Unterschiede zwischen Ansible und Puppet vielleicht nochmal hervorheben. Bei Ansible werden alle Sachen von oben nach unten durchgearbeitet. Das hat den Vorteil, dass man sowas auch relativ leicht von Hand abarbeiten könnte und dass man nachvollziehen kann, was in welcher Reihenfolge gemacht wird. Bei Puppet gibt man Aufgaben einzeln an und legt Abhängigkeiten zwischen Aufgaben fest und Puppet rechnet dann eine sehr realisierte Ausführungsreihenfolge aus. Das hat den Vorteil, dass man Sachen an manchen Stellen eleganter strukturieren kann, aber es ist, wenn man so eine Puppet-Config liest, als Leser nicht klar, in welche Reihenfolge die Sachen später ausgeführt werden und das kann auch zur Verwirrung führen. Und dieses Problem hat Ansible nicht, einfach dadurch, dass Ansible an der Stelle weniger flexibel ist und immer die Sachen von oben nach unten ausführt. Ja, das war eigentlich auch schon fast meine Frage. Ich wollte noch mal hören, wenn du Puppet auch kennst, was so für dich noch die wesentlichen Unterschiede sind, außer dem, was du gerade gesagt hast. Der offensichtlichste Unterschied zwischen Puppet und Ansible ist, dass das Puppet einfach größer ist. Wenn ich jetzt eine sehr, sehr große Firma hätte, würde ich vermutlich eher darüber nachdenken, mit Puppet anzufangen, als mit Ansible anzufangen. Wie dann die Entscheidungen im Detailgrad ausfallen würde, ist natürlich jetzt nicht klar, aber das wäre eine gute Höreristik. Ein anderer Unterschied ist, der sehr, sehr auffällig ist, dass Puppet hat einen sogenannten Resource Abstraction Layer, den REL, der abstrahiert Ressourcen. Also angenommen, ich möchte eine Konfig-Datei anpassen, die liegt unter Puppet, sorry, unter, sag mal, Debian, unter Fedora, oder sag, das ist equivalent vielleicht eher Zentres als Fedora, an verschiedenen Orten. Bei Puppet habe ich diesen Resource Abstraction Layer, wo ich sagen kann, ich möchte die Konfig-Datei, die zu meinem, sag mal mal, Engine X-Webserver gehört, updaten. Währenddessen bei Ansible würde ich den Fahrtart kodieren und mich selber drum kümmern, dass ich jetzt feststelle, dass ich auf einmal für einen beiden Distros bin und den richtigen Fahrtanfasse diesen Resource Abstraction Layer gibt es bei Ansible überhaupt nicht. Kann man als Vorteil sehen, wenn man groß genug ist, wenn der Anwendungsfall groß genug ist, ist ein Nachteil, wenn man ein einzelner Admin ist für eine eher kleine Anzahl von Servern, denn dann ist es einfach übersichtlicher. Das ist ein Vorteil von Ansible. Kommt halt auf den Anwendungsfall drauf an immer. Gibt es noch Fragen? Nein, keine weiteren Fragen? Okay, dann bedanke ich mich für Ihre Aufmerksamkeit. Vielen, vielen Dank und einen schönen Tag.