36C3 ChaosWest: Ansible all the Things

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!