We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Ansible all the Things

00:00

Formal Metadata

Title
Ansible all the Things
Subtitle
Was mir dabei geholfen hat alles mit Ansible zu automatisieren
Title of Series
Number of Parts
254
Author
License
CC Attribution 4.0 International:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
In diesem Talk wird es um die Grundlagen von Ansible gehen, warum es für den Vortragenden das beste Werkzeug ist und welche alternativen es noch gibt. Vom ersten Host Inventory im YAML Format über die kleine Rollen (NTP/Fail2Ban) und Playbooks bis hin zum ersten kompletten Einrichten des Rasberry Pi oder Servers mit eigenen Dotfiles und den Basic Paketen die man so braucht. Auch wird drauf eingegangen, wie und warum reproduzierbare Infrastruktur Builds das Leben eines Admins erleichtern können und im Alltag der händischen Arbeit vorzuziehen sind. Abschließen wird der Talk mit dem Thema "Ansible Playbooks aus dem Internet herunterladen oder selbst machen?" und worauf man achten sollte, wenn man Playbooks für mehrere unterschiedliche Linux Distributionen baut.
Keywords
Computer animation
FachinformatikerPoint cloudJSONLecture/Conference
Asynchronous Transfer ModePoint cloudJSON
Systems <München>SoftwareRollbewegungOpen sourceTwitterLecture/Conference
Mainframe computerServer (computing)Order theoryControl flow graphRollbewegungHash functionMainframe computerServer (computing)Variable (mathematics)Operating systemClefJSON
Mainframe computerServer (computing)Lecture/Conference
RollbewegungmakeService (economics)SoftwareDebian GNU/LINUXService (economics)Debian GNU/LINUXServer (computing)Task (computing)CentOSComputer fileVarianceTemplate (C++)Variable (mathematics)Operating systemPlug-in (computing)NagiosModule (mathematics)JSON
Operating systemComputer fileVariable (mathematics)Lecture/Conference
Mainframe computerInventor <Programm>EmacsText editorGit <Software>Slide ruleHausdorff spaceDebian GNU/LINUXEmailServer (computing)
Inventor <Programm>Mainframe computerHausdorff spaceLecture/Conference
Mainframe computerInventor <Programm>LAMP <Programmpaket>ComputerLINUXJSON
Inventor <Programm>Lecture/Conference
Inventor <Programm>Slide ruleLink (knot theory)Software repository
openSUSEComputer animation
Transcript: German(auto-generated)
Applaus, weil an der Stelle ein riesiges Applaus für Heiko Borchers. Er ist Fachinformatiker und in
seiner Vita steht, dass er sich von Autos in der Cloud kümmert. Also ein spannendes Thema und er redet über all the things. Darum viel Spaß und ich lern jetzt bestimmt auch viel. Ja,
dann erstmal guten Morgen an Tag 1. Ich hätte nicht gedacht, dass an Tag 1 in die frühe Uhrzeit so viele Leute hier sind. Und ja, ich werde darüber reden. Ansible all the things. Was mir dann tatsächlich geholfen hat, wie ich Ansible gelernt habe und zu mir. Ich bin
Sysadmin, mache hauptsächlich Cloud Infrastruktur, wie der Pupi auch schon gesagt hatte. Großteil davon ist für Elektroautos und eigentlich automatisiere ich mir halt am liebsten alles und da sind halt dann für die Cloud Terraform und Ansible auch im täglichen Einsatz. Und meine
Motivation für diesen Talk war tatsächlich, Ansible ist mein Lieblingstool und ich habe auf Twitter viel dieses Jahr gelesen. Ja, eigentlich würde ich das ja gerne lernen, aber wie fange ich an? Irgendwie habe ich von vielen Leuten gehört, dass sie keinen
Startpunkt liefern. Erstmal, warum mag ich Ansible so? Ich arbeite viel mit Kundensystemen und da dann nochmal irgendwas zusätzliches zu installieren, ist vielleicht nicht ganz so optimal. Deswegen Agentless. Man braucht auf dem Kundensystem später nichts mehr zusätzlich,
hat relativ wenig, was die Software noch rummüllt. Es braucht nicht noch zusätzliche zentrale Infrastruktur, wie man es teilweise mit Puppet hat. Kann man haben, muss man nicht
nutzen. Ich finde, es war relativ leicht zu lernen. Es ist Open Source, was immer praktisch ist und wenn man die Ansible Rollen richtig geschrieben hat, kann man sie einmal laufen lassen, zweimal laufen lassen. Das Ergebnis wird am Ende immer das gleiche sein. Ja,
warum nicht Ansible? Es ist nicht unbedingt schnell und man muss Jaml lernen. Jaml ist pingelig, was Leerzeichen und Tapstops angeht. Da hat man gerne mal eine falsche Eindrückung und am Ende fliegt einem alles um die Ohren. Dann fange ich auch direkt mal mit den Basics an.
So sieht so eine Standard-Ordner-Struktur aus von Ansible. Man hat seine Config, man hat eventuell Hashes von irgendwelchen Credentials, man hat Variablen, die für ganze Gruppen da sind. Man hat so einen Hosts-File, wo sämtliche Server drinstehen,
die man hat. Man hat ein sogenanntes Playbook, in dem drinsteht, was man mit seiner Infrastruktur machen will und dann hat man verschiedene Rollen. Und ja, wie sieht so eine Config aus? Das ist jetzt tatsächlich meine Config, die ich auch
normalerweise nutze. Das ist tatsächlich halt, wie jedes andere Config-File unter x-beliebigen Betriebssystemen. Einfach nur Key und Value. Dann so ein ganz einfaches Playbook. Das würde jetzt auf allen Hosts laufen, die man so in seinem Inventory
stehen hat. Wie das Inventory aussieht, zeige ich euch gleich noch. Und man gibt halt hier noch einen Variablen-File an und hat dann verschiedene Rollen. Das ist jetzt das Playbook, was ich tatsächlich immer als allererstes laufen lasse. Installiert die
Rolle Packages. Da werden einfach so die Standard-Pakete, die ich gerne habe, installiert. Dann DateTime wird ein NTP-Server konfiguriert. Bei den Hosts wird die etc-Hosts noch angepasst. Und mit der Rolle User
kopiere ich tatsächlich meine ganzen Dot-Files und alles, was ich gerne an Config habe, direkt auf den Server, damit ich überall so arbeiten kann, wie es mir am besten gefällt. Und ja, da haben wir dann jetzt so eine Rolle. Das ist die User-Rolle. Und da gibt es dann auch wieder so eine Ordner-Struktur.
Die Ordner-Struktur lege ich mir für jedes Mal, wenn ich eine neue Rolle schreibe, lege ich mir diese Ordner-Struktur mit Defaults, Files, Handlers, Tasks und Vars halt einfach mit einem kleinen Bash-Script an. Die Ordner werden
halt eh alle fast immer gebraucht. Was sind so Defaults? Wirklich Default-Werte, die man setzt. Files sind einfach nur Dateien, die ihr auf der Maschine haben wollt, die keine Templates sind, sondern tatsächlich feste Files,
Binaries oder halt bei mir meine Dot-Files. Und dann haben wir tatsächlich, das sind die verschiedenen Tasks. Es wird das Sudo-File erstmal an sicheren Ort kopiert, das Original. Dann wird
tatsächlich einfach nur in der Datei ein bisschen was geändert. Am Ende
wird noch ein Sanity-Check gemacht. Und nach dem Sanity-Check, wenn alles so funktionieren sollte, wird der SSH-Demon einfach neu gestartet. Damit man nicht, der Task ist tatsächlich dafür da, dass man nicht mal als Root auf den Server connecten muss, sondern mit seinem Nutzernamen
und dann mit seinem Nutzernamen Sudo verwenden kann. Das ist der Händler, der dann aufgerufen wird, um den SSH-Demon neu zu starten. Wird dann das Ansible-Modul für Systemd oder Unit-5-Services benutzt.
Und es wird einfach nur geguckt. Beziehungsweise der Service wird neu gestartet und wenn dann halt die Meldung zurückkommt, Service has restarted, ist der Händler dann auch abgeschlossen. So sieht halt auch
so ein Task aus. Hat ein Name, installiere die Base-Software, die Pakete wird halt geguckt, je nachdem welches OS, ob wir jetzt einen Centos haben oder ein Debian. Und dann wird die Liste an Paketen
einfach durchgeguckt und das jeweilige Paket installiert. Hier haben wir auch noch mal dieses Notify. Gibt halt dann dem Händler die Info und bei dem
Tag habe ich halt noch reingeschrieben New System. Das Tag wird dann, wenn das System einmal konfiguriert ist, auch gelöscht. Und hier haben wir jetzt so einen Auszug aus einem variablen Fall. Bei Debian heißen die
Monitoring-Plugins-Basic. Bei Red Hat heißen sie Nagios-Plugins und auf Arch Linux heißen sie halt Monitoring-Plugins. Und weil man in seiner Rolle nicht in dem Fall drei verschiedene Paketnamen angeben will,
hat man es halt in den variablen Dateien. Und Ansible guckt vorher welches Betriebssystem ist das jetzt, was ich provisioniere und nimmt dann dementsprechend aus diesen dreien das, was für das Betriebssystem das Richtige ist. Dann gibt es auch noch Variablen. Die möchte man nicht
unbedingt im Klartext haben, wenn man zum Beispiel irgendwelche Private Keys auf eine Maschine kopieren muss oder für einen Cluster oder Datenbank- Server-Sync, wenn man mit Keyfiles arbeitet. Die schiebt man vielleicht
auch aus Versehen dann mal ins Git und dann liegen sie im Klartext in irgendeinem Git-Krepo. Ist doof, da fährt Ansible halt das Ansible Vault und dann steht da halt erst mal nur drin Ansible Vault ist IIS 256 verschlüsselt und quasi zufällige Daten. Und ja, ich weiß, die sehen jetzt nicht
zufällig aus. Ich wollte hier keine verschlüsselten Daten auf die Wand werfen. Und ja, so von den Basics her war es das auch, was man für Ansible sonst noch braucht, ist einfach nur sein Lieblingseditor. Kann man mit
VI oder Emacs machen, kann man aber auch mit IDIs machen, aber eigentlich braucht man nur ein Texteditor und Ansible als Software selber. Und was mir dann dabei tatsächlich geholfen hat, es vernünftig zu lernen, war ich hab mir meinen Raspberry Pi zu Hause genommen.
Moment, da hatte ich doch tatsächlich auch noch eine Slide. Wo ist die denn hin verschwunden? Warum hab ich diese Slide übersprungen? Das war nämlich das Inventory. Das ist halt auch wieder eine YAML-Datei.
Hier habe ich jetzt die Gruppe, meine Server, mein Root Server, auf dem auch die Präsentation gerade läuft und mein Raspberry Pi. Und um es mir selber beizubringen, habe ich tatsächlich auf dem Raspberry Pi dann so die kleinste Debian-Installation genommen, die ich finden konnte und dann alles, was ich auf dem Pi zu Hause haben wollte, per Ansible drauf installiert.
Erstmal mit kleinen Sachen angefangen, wie halt den NTP-Demon konfigurieren. Dann für zu Hause vielleicht nicht ganz so relevant, aber fail-to-ban konfigurieren. Solche kleineren Sachen kann man relativ gut machen, ohne dass man sich das komplette System zerschießt und dann halt
später immer größer werden. Und das ist tatsächlich auch mein Tipp. Wer es lernen möchte, nimmt sich halt einfach seinen Kleinstcomputer der Wahl, packt da einen Linux drauf und bewirft den erstmal mit Ansible. Von der Performance her tut sich das eh nicht so viel, ob man jetzt
einen Raspberry Pi oder einen großen Rechner nimmt. Viel bei Ansible ist ausprobieren, warten, failen, noch mal ausprobieren. Und ansonsten wäre ich jetzt durch. Wenn Fragen sind, könnt ihr gerne noch Fragen stellen.
Erstmal einen warmen Applaus, bevor wir hier irgendwie mit Fragen anfangen. Es werden sich ja gleich hier links und rechts die Lampen genau zum Telefonischoker eröffnen. Das heißt, wer Fragen hat, gerne dort. Wo kann man dich erreichen, wenn man jetzt irgendwie Blut geleckt hat mit dem, was du hier gemacht hast, dass man
während des Kongress noch mal auf dich zukommt, in welchem ... Auf dem Kongress. Ich renn eigentlich immer rum. Stehst du unter deinem Namen im Decksystem? Ja, ich steh unter meinem Namen im Decksystem. Die Slides werde ich auch gleich dann bei Chaos West beim Talk noch hinzufügen, wer sie sich noch mal angucken will.
Und in den Slides steht auch später noch der Link zum GitHub Repo mit den Slides selber. Ja, das ist ja vorbildlich. Da würde ich sagen, volle Punktzahl, keine Fragen mehr. An der Stelle dann aber noch mal ein Applaus, weil so einfach lassen wir keinen von der Bühne gehen.