Linux automation mit Ansible

tl;dr Mit der Einführung eines Configuration Management haben wir uns in der Linux Administration für Ansible entschieden. Ich gebe ein Beispiel wie wir Ansible dort zur Automatisierung verwenden und welche Herausforderungen dabei entstanden sind.

$ whoami

Wie man an der Überschrift erahnen kann, bin ich bei Netfonds als Linux Systems Administrator tätig. Ich kümmere mich um den Betrieb der Linux und Cloud Infrastruktur, setze die Anforderungen an die Systeme um und kümmere mich darum, dass alles aktuell und stabil ist. Effizienz ist auch bei uns in der IT Operations ein nicht zu unterschätzender Faktor. Man schaut sich gerne um und findet gelegentlich Tools die sich lohnen näher betrachtet zu werden.

lets go!?

Zugegeben ist Ansible eines der genialsten Tools, das ich bisher kennengelernt habe und ist für einen Systemadministrator mit überschaubarem Aufwand zu beherrschen. Man beschreibt einfach, was man gerne hätte und das Programm spult in feinster Matrix Magie Schritt für Schritt den beschriebenen Zustand auf das Ziel. Idempotent. 

---
- name: update web servers
  hosts: webservers
  remote_user: root
  tasks:
  - name: ensure apache is at the latest version
    yum:
      name: httpd
      state: latest
  - name: write the apache config file
    template:
      src: /srv/httpd.j2
      dest: /etc/httpd.conf

Das Großartige ist, dass nichts nachinstalliert werden muss. Ansible loggt sich per SSH auf den Systemen ein und führt die gewünschten Aufgaben aus. Ich habe auch schnell etwas gefunden, womit ich Ansible ausprobieren konnte. Ich spiele gerne auf sicherem Grund herum und teste das Verhalten von Programmen nicht auf einem Livesystem (falls einmal etwas schief geht). Die bekannten Snapshots in VirtualBox waren mir schon immer zu messy. Immer muss man noch ein Update machen, vergisst den Zustand zu speichern und wenn etwas kaputt geht, dann wieder alles von vorne… wieso derart viel Zeit verschwenden, wenn es Vagrant gibt?
Vagrant erstellt dir bei Bedarf die gewünschte Maschine und konfiguriert sie wie du sie brauchst – mit Ansible. Betriebssystem ausgesucht – Box heruntergeladen – “vagrant up” und im Anschluss wird direkt das gewünschte Ansible Playbook abgefeuert. 

Das Ergebnis ist eine frisch installierte virtuelle Maschine. Immer derselbe aktuelle Zustand. Bereit um von mir kaputt gemacht zu werden und in 2 Minuten mit 2 Kommandos wieder komplett gelöscht und erneut einsatzbereit! Genial! 

Dann fangen wir mal an – so viel wird da doch nicht zu tun sein und dann kann ich alle Standardkonfigurationen mit Ansible verteilen.

puh…

…. das ist ganz schön komplex. Mehrere Release Versionen, eine wachsende Anzahl unterschiedlicher Distributionen. Und am Ende soll es gegen alle produktiven Server laufen. 

• per Hand gepflegte Config Files (Formatierung)
• Unterschiedlichste Inhalte (Variablen)
• Distributions spezifische Software (yum, dnf, apt)

Mal schnell eine Rolle zu schreiben um automatische Updates und die korrekte Paketmanager Konfiguration zu garantieren… uff. Aber es lohnt sich und die Entscheidung für Ansible war richtig. Man lernt viel über die einzelnen Programme (Config Files, Cache Verzeichnisse, Verifikationsparameter) und das macht tatsächlich richtig viel Spaß – wirklich!

just fun!?

Das Einsatzszenario für Ansible bei Netfonds ist im übergeordneten Sinne mit der Einführung eines „Configuration Management“ verbunden. Als eher streng reglementiertes, mittelständisches Unternehmen haben wir besondere Richtlinien zu erfüllen. Neben unseren eigenen Ansprüchen an einen sauberen Betrieb kann und muss man sich daran orientieren und diese umsetzen. Sich auf jedem Server einzuloggen und die Änderungen händisch vorzunehmen bzw. zu kontrollieren ist nicht besonders zielführend – “Bin dann mal ne Woche beschäftigt… “. Neben den betriebsnotwendigen Themen, wie Installation von Standardsoftware, der korrekten Einrichtung des Mail Relays und der bereits erwähnten Sicherstellung von automatischen Updates, wird man z.B. gerne gefragt, wie der Zugriff auf die Systeme passiert und welche Benutzer sich dort anmelden können. Wie kommen die SSH Keys drauf und wieder runter? Welche gibt es und welche Authentifizierungsmethoden sind erlaubt? Um nur an der Oberfläche zu kratzen.

Wir betreiben mittlerweile eine dreistellige Anzahl an Servern und eine Ansible Rolle, inklusive Variablen, ist da immens aussagekräftig. Wir haben also ein Tool, mit dem garantiert werden kann, dass eine Konfiguration auf einem bestimmten Server genau so aussieht, wie wir das wollen. Änderungen an Parametern können innerhalb von ein paar Minuten durchgeführt werden und am Ende ist das ganze direkt dokumentiert. 

yes fun!

Mit Ansible hat sich aber auch meine Arbeitsweise verändert. Man hinterfragt seine früheren Arbeitsweisen. Wieso so und nicht anders? Gibt es da nicht ein Best Practice? Wäre es so nicht noch besser? Das macht Spaß! Standards erarbeiten, umsetzen und dokumentieren. Wenn man damit fertig ist, muss man sich nie wieder damit beschäftigen ( … in der Theorie 🙂 ).

Die Begeisterung für das Tool hat viel mit Effizienz zu tun. Wenn ich heute einen neuen Linux Server installiere, habe ich vier Minuten Arbeit. Und davon warte ich zwei Minuten darauf, dass der neue DNS Eintrag der Maschine endlich aufgelöst wird. Wenn ich später das System ins Monitoring einbinden möchte, wird mit Ansible der Client installiert, der Host im Monitoring angelegt, alle Dienste erkannt und jegliche selbstgeschriebenen, für das System relevanten Checks an den korrekten Ort kopiert. Komplett ohne weiteres Zutun. 

In gewisser Weise treibt mich natürlich auch meine Faulheit. Ich suche darum gerne etwas, was mich fasziniert. Für mich gesprochen kann ich da generell als Linux Administrator nicht klagen.. leider musste ich feststellen, dass das Klischee mit dem dunklen Keller und der Pizza direkt neben der Serverfarm nicht mehr existiert. Große Schande!!! 

Zur Dokumentation von Ansible verwenden wir eine Mischung aus Wiki und GitHub. GitHub mag für den ein oder anderen eine Selbstverständlichkeit sein, hat sich in unserem IT Operations Team aber erst richtig mit der Einführung von Ansible aufgezwungen. Wenn man mit solch mächtigen Tools arbeitet, kann auch ganz schnell etwas kaputt gehen. Und das nicht nur auf meiner Vagrant VM. Sondern auf jedem einzelnen Server und in unter 2 Minuten.

Aua!

Verlässlichkeit ist also etwas, das in Verbindung mit IT Automatisierung generell und in dieser Corona Zeit besonders wichtig ist. Wir arbeiten größtenteils aus dem Homeoffice und bauen auf Verlässlichkeit. Egal, wer etwas ausführt und wie oft er es ausführt. Das Ergebnis muss immer feststehen und Anpassungen verständlich und nachvollziehbar sein. Zu Anfang des Beitrags habe ich ein Wort in den Raum geworfen, dass ich nicht weiter kommentiert habe:

Idempotenz
“In der Informatik wird ein Stück Programmcode, das mehrfach hintereinander ausgeführt das gleiche Ergebnis wie bei einer einzigen Ausführung liefert, als idempotent bezeichnet.”
Ansible ist nicht per se idempotent. Es gibt diverse Module die beispielsweise einfach Kommandos ausführen oder Parameter die einen entscheiden lassen wie das entsprechende Modul sich zu verhalten hat. Ganz zu schweigen davon, wenn man bei Variablen oder Regular Expressions nicht aufpasst.

Man liest in Verbindung mit Ansible häufig: “Wenn du dich nicht traust dein Script alle 15 Minuten laufen zu lassen, dann machst du es nicht richtig”. Auch wenn unter Zeitdruck etwas Neues gebaut wird, darf das nicht vernachlässigt werden. Das Beherrschen von Regular Expressions hat viel damit zu tun. Meiner Erfahrung nach ein besonderes tolles Streitthema. Wenn man mit Linux arbeitet, kommt man eigentlich nicht daran vorbei. grep macht ohne einfach keinen Spaß. Spätestens aber mit Ansible gibt es keine Ausrede mehr.

• URLs in einem Text zu finden sieht z.B. so aus “https:\/\/[^\s]*”
• Suche die Zeile die mit A anfängt und nach 3 beliebigen Buchstaben kommt ein Leerzeichen und am Ende steht kein Y:  „^A...\s.*[^Y]$„

Nicht genau das, aber in etwa so etwas braucht man, um Konfigurationsdateien anzupassen. Finde -> ersetze / validiere.

Frage ich mit „^root.*ALL„, ob eine Zeile existiert und sie den benötigten Inhalt hat, werde ich vielleicht ungewollt einen neuen Eintrag bekommen, weil die Regular Expression auf alles was mit root beginnt und nicht auf ALL endet nicht zutrifft.
Möchte ich theoretisch mehrere Einträge erhalten, die mit root beginnen, werde ich auch mit „^root “ nicht weiter kommen, da so der erste Treffer immer ersetzt und dann gestoppt wird. Ist das erste Zeichen nach root kein Leerzeichen, sondern ein Tab, ist es auch nicht das was ich tun will.
Man muss das Benötigte also teilweise sehr spezifisch formulieren können.

Die einen hassen, die anderen lieben es. Egal, wen der beiden es trifft. Ist ein Fehler drin, dann ist ein Fehler drin und dann ist es vorbei mit der Idempotency oder die Konfigurationsdatei besteht nur noch aus einem Wort. 

Es wird einem nicht langweilig. 

Wenn man mit Ansible anfängt und der erste run auf die komplette Infrastruktur losläuft, dann muss man schon hartgesotten sein, um nicht zumindest ein bisschen Gänsehaut zu haben. Man lernt sehr schnell Methoden zu entwickeln, nichts kaputt zu machen. Man sieht wie unterschiedlich Konfigurationsdateien aussehen können, die am Ende dasselbe machen. Die bereits erwähnte Vielfalt der unterschiedlichen Programme und der Varianz in den Konfigurationsdateien macht den Start mit Ansible in einer bestehenden Infrastruktur nicht unbedingt einfach. Mal werden Konfigurationsdateien Inline bearbeitet und mal schreibt man alles ans Ende. Das gilt es abzufangen und zu vereinheitlichen, Variablen herauszuarbeiten und in den korrekten Hosts zu hinterlegen. Am Ende muss jedes Script für jeden Host dasselbe individuelle Ergebnis haben. Das korrekte und funktionierende Ergebnis. Neue Hosts anzulegen ist dagegen eine wahre Wonne!

@work(s)

…die erste heiße Phase.

Nachdem ich den Großteil unserer Standard Infrastruktur in Ansible beschrieben, Erfahrungen in der Strukturierung gemacht und aus meinen ersten Fehlern gelernt habe, kam das erste größere Projekt bei dem Ansible eine wichtige Rolle gespielt hat. Es geht darum, eine neue Infrastruktur aufzubauen, bei der noch nicht absehbar ist wie die Dimension am Ende aussehen wird. Diverse Loadbalancer, Server für eine Sitzungsverteilung und eine unbestimmte Anzahl an Nodes, die am Ende die eigentliche Last aufnehmen und je nach Auslastung horizontal und/oder vertikal skaliert werden müssen. Ein Hinzufügen und Entfernen von Systemen während des laufenden Betriebs muss gewährleistet sein und das ganze natürlich neben dem normalen Betrieb des Daily Business. 

… für mich ein total neues Terrain!

Da die Umsetzung zeitkritisch war, wurde auf einen externen Mitarbeiter zurückgegriffen, mit dem es galt die Kommunikation und Dokumentation der Umsetzung zu besprechen. Wie hätte man das normalerweise gemacht? Ich hätte einen Server zur Verfügung gestellt, das System wäre aufgesetzt worden, alles dokumentiert und man hätte ein Image vorgehalten um neue Nodes zu erstellen. Per Hand dann die Konfigurationen angepasst und ja… was alles nicht in der Dokumentation steht…. es gibt diverse Möglichkeiten was nicht optimal wäre. Alle Kollegen, die sich später mit dem System auseinandersetzen müssen, hätten geschult werden müssen. An sich keine Raketentechnik, aber komplex genug um viel Arbeit damit zu haben. 

Glücklicherweise hat der externe Kollege meinen Vorschlag Ansible und GitHub für unser Projekt zu verwenden sofort mit aufgegriffen.

Die Vorteile:

Transparenz! Sowohl Ansible als auch GitHub erlauben eine schmale Kommunikation. Ansible ist extrem einfach zu verstehen. Man beschreibt einen Zustand und das Programm kümmert sich darum, dass es genau so ist. Lineinfile. “This module will search a file for a line, and ensure that it is present or absent.“

- lineinfile:
    path: /etc/httpd/conf/httpd.conf
    state: present
    regexp: '^Listen '
    insertafter: '^#Listen '
    line: 'Listen 8080'

In einer Dokumentation zu beschreiben, wie mehrere Parameter in einer Konfigurationsdatei angepasst werden müssen, ist unübersichtlicher und umfangreicher als das gezeigte Modul. Pragmatisch, kompakt und auf den Punkt.

Nachvollziehbar! Durch die Arbeit mit Github kann auch im Nachhinein nachvollzogen werden, was bisher gemacht wurde. Wo wurden Anpassungen gemacht? Wieso wurde etwas geändert? Man kann es separat testen und wenn es funktioniert, wird es übernommen.

Kollaboration! Jeder kann getrennt voneinander an einem Problem arbeiten und wenn man fertig ist, gibt man kurz Bescheid, damit sich das Gegenüber die fertigen Änderungen holen kann.

Wo ist hier der Unterschied, wenn man zusammen auf einem System arbeitet!? Man sieht sofort das Essentielle im Ansible Format. <Transparenz>

Dokumentation! Zusammenfassend sei noch einmal erwähnt, dass die Dokumentation per Definition aktuell ist. Wenn es am Ende funktioniert, ist alles fertig! Keine Nacharbeit.

Das Projekt wurde also zu 90% mit Ansible umgesetzt. Vor allem die zu skalierenden Nodes werden komplett von Ansible konfiguriert und können bei Bedarf erstellt werden. Ansible installiert den kompletten Node und springt dann auf die Sitzungshosts und fügt ihn der Konfiguration hinzu => Live. 

Vielen Dank nochmal in dem Zusammenhang an den externen Kollegen, der die meiste Arbeite geleistet hat!

next!

Automatisierung von IT Systemen ist ein breites Spektrum und je nach Anforderung kann man das unglaublich ausbauen. Wir sind jetzt soweit Systeme vordefiniert auszuspielen, Konfigurationen anzupassen und Software komplett fertig einzurichten. Virtuelle Infrastruktur hat etwas Tolles ermöglicht. Sei es VMWare oder eine Google Cloud Platform. Netzwerkkomponenten von Routern zu Firewalls. Alles ermöglicht mittlerweile ein Ansteuern per API oder zumindest SSH und CLI . Es gibt immer mehr Produkte, die genau darauf abzielen. 

Vieles davon kann Ansible auch schon. Ich könnte neue Server nicht nur in meinem Virtualbox sondern auch in VMWare oder der Google Cloud Platform nach Bedarf erstellen und hochfahren, einrichten und einbinden. Die Firewall der Infrastruktur kann gleichzeitig auf den Server angepasst, ein neues Netzwerk erstellt werden und holla die Waldfee. Die Sammlung an Rollen für die aktuelle Infrastruktur wächst und wächst. Diverse Probleme werden abgearbeitet, standardisiert und ausgerollt. 

Die Liste ist lang und es gibt noch viel zu tun 🙂

Bild: Canva