*36C3 Vorspannmusik*
Herald: Applaus, Applaus, Applaus, Applaus, weil an der Stelle ein riesiges
Applaus für Heiko Borchers. *Applaus*
Herald: 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 „Ansible all the
things“. Darum viel Spaß und ich lerne jetzt bestimmt auch viel.
*Applaus*
Heiko Borchers: Ja, dann erst mal guten Morgen an Tag 1. Ich hätte nicht
gedacht, dass an Tag 1 um die frühe Uhrzeit schon 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. Zu mir: Ich bin Sysadmin, mach
hauptsächlich Cloud-Infrastruktur, wie der Pupe ja auch schon gesagt hatte. Großteil
davon ist für Elektroautos und eigentlich automatisiere ich mir halt am liebsten
alles weg. 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 hab auf Twitter viel dieses Jahr gelesen: Ja eigentlich würde
ich das sehr gerne lernen aber wie fange ich an? Irgendwie kam viel, habe ich von
vielen Leuten gehört, dass sie keinen Startpunkt gefunden haben und da wollte
ich jetzt dann halt mal einen Startpunkt liefern. Erstmal: Warum mag ich Ansible so?
Ich arbeite viel mit Kundensystemen und da dann noch mal 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 Ansbile-Rollen richtig geschrieben hat, kann man sie einmal
laufen lassen, zweimal laufen lassen, das Ergebnis wird am Ende immer das Gleiche
sein. Ja, vielleicht: Warum nicht Ansible? Es ist nicht unbedingt schnell und man
muss YAML lernen und YAML ist pingelig, was Leerzeichen und Tabstops angeht. Da hat
man gerne mal ’ne falsche Einrückung und am Ende fliegt einem alles um die Ohren.
Dann fange ich auch direkt mit den Basics an: so sieht so eine Standard-
Ordnerstruktur 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 ein hosts-File, wo sämtliche Server drin stehen, die man hat. Man hat
ein sogenanntes Playbook, in dem drin steht, 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 hier halt noch ein Variablen-File an und hat dann
verschiedene Rollen. Das ist jetzt so das Playbook, was ich tatsächlich
immer als allererstes laufen lasse, installiert die Rolle Packages,
da werden einfach so die Standardpakete, die ich gerne habe, werden installiert.
Dann date_time: wird ein NTP-Server konfiguriert. Über 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 halt auch
wieder so eine Ordnerstruktur. Die Ordnerstruktur lege ich mir für, jedes mal
wenn ich eine neue Rolle schreibe, lege ich mir diese Ordnerstruktur mit defaults,
files, handlers, tasks und vars halt einfach mit einem kleinen Bashskript an.
Die Ordner werden halt eh alle fast immer gebraucht. Das 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 sudoer-File erstmal an einen 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-daemon einfach neu
gestartet, damit man nicht … der Task ist tatsächlich dafür da dass man nicht immer
als root auf den Server connecten muss sondern mit seinem Nutzernamen und dann
mit seinem Nutzernamen sudo verwenden kann. Das ist der Handler, der dann
aufgerufen wird, um den ssh-daemon neu zu starten. Wird dann das Ansible-
Modul für systemd oder initV-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 Handler dann auch abgeschlossen. So
sieht halt auch so ein Task aus, hat einen Namen, installiere die Base-Software, die
Pakete, wird geguckt, je nachdem welches OS, ob jetzt ein CentOS haben oder ein
Debian, und dann wird die Liste an Paketen einfach durch geguckt und das jeweilige
Paket installiert. Hier haben wir auch noch mal dieses notify, es gibt halt dann dem
Handler 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-File. Bei Debian heißen die
monitoring plugins, 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 jetzt in dem Fall drei verschiedene Plugins, also 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
Privat-Keys auf eine Maschine kopieren muss oder für ein Cluster oder
Datenbankserver-Sync, wenn man mit Key- Files arbeitet. Die schiebt man vielleicht
auch aus Versehen einmal ins git und dann liegen sie im Klartext in irgendeinem git-
Repo. Ist doof. Dafür hat Ansible halt das Ansible-Vault. Und dann steht da halt
erstmal nur drinnen: Ansible_Vault ist AES256 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 IDEs
machen. Aber eigentlich braucht man nur einen Texteditor und Ansible als Software
selber. Und was mir dabei tatsächlich geholfen hat, es vernünftig zu lernen,
war, ich habe mir meinen RaspberryPi zuhause genommen …
Moment, da hat ich doch auch noch eine Slide, wo ist die denn hin verschwunden?
Warum habe ich diese Slide übersprüngen? Das war nämlich das Inventory, das ist
halt auch wieder eine YAML-Datei. Hier habe ich jetzt die Gruppe
MeineServer: mein root-Server, auf dem auch die Präsentation gerade läuft und
mein RaspberryPi und um es mir selber beizubringen, habe ich tatsächlich auf dem
RaspberryPi so die kleinste Debian Installation genommen, die ich finden
konnte, und dann alles, was ich auf dem Pi zuhause haben wollte,
per Ansible drauf installiert. Erst mal mit kleinen Sachen
angefangen wie halt dem ntp-daemon konfigurieren, dann für zuhause
vielleicht nicht ganz so relevant, aber fail2ban 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 den Kleinstcomputer der
Wahl, packt da ein Linux drauf und bewirft den erstmal mit Ansible. Von der
Performance her tut sich da eh nicht soviel, ob man jetzt ein RaspberryPi oder
einen großen Rechner nimmt. Viel bei Ansible ist Ausprobieren, Warten, Failen,
noch mal ausprobieren. Und, ja, ansonsten wäre ich jetzt durch. Wenn Fragen sind,
könnt ihr gerne auch noch Fragen stellen. Herald: Erstmal einen warmen Applaus bevor
wir hier irgendwie mit Fragen anfangen, weil …
*Applaus*
Herald: So, es werden sich ja gleich hier links und rechts die Lampen zum
Telefonjoker 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 Congress noch mal auf dich zukommt, in welchem …
Heiko: auf dem Congress, ich renn eigentlich immer rum
Herald: Stehst unter deinen Namen im DECT-System?
Heiko: Ja, ich stehe unter meinem Namen im DECT-System. Die Slides werde ich auch
gleich dann by 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. Herald: Ja, das ist ja vorbildlich! Da
würde ich sagen volle Punktzahl, keine Fragen mehr, an der Stelle dann aber
nochmal ein Applaus, weil so einfach lassen wir keinen von der Bühne gehen.
*Applaus*
*Abspannmusik*
Untertitel erstellt von c3subtitles.de im Jahr 2020. Mach mit und hilf uns!