Ansible Ops mit Gitlab
"Machen wir GitOps!", schallt es aus aller Munde. Aber was ist es und was bedeutet es für die Beteiligten? "Schneller", "fehlerfreier" und "kostengünstiger" soll GitOps sein. So jedenfalls die Begründung für den Einsatz.
Nehmen wir mal das Konstrukt auseinander, "Git" und "Ops". An dem Begriff und Tool "Git" sind wir (Techniker) in irgendeiner Variation bestimmt schon vorbeigekommen. Die einen (Entwickler genannt) nutzen Git zum Verwalten ihres Sourcecodes. Hier kann man jede gute Änderung an diversen Dateien in einen Commit verpacken und zum Schluss die gesammelten Änderungen mit einem "Push" an den Server schieben. Wenn etwas am Programm nicht läuft, kann man gemeinsam oder einsam durch die Änderungen gehen und das nicht funktionierende Feature verbessern.
Solche Fehler oder auch neue Features werden neben dem Code in Tickets (oder Issues) beschrieben und nachverfolgt. Diese können dann nach den agilen Prinzipien in Sprints eingeplant und abgearbeitet werden.
Die anderen (Admins genannt) haben erkannt, dass man mit den Issues ihre Arbeit gut organisieren kann (Danke an einen Automobilhersteller aus Japan für Kanban). Der Arbeitsalltag des Admins (oder auch Ops oder Scotty genannt) ist schlecht in Sprints planbar, aber es benötigt auch eine Struktur, um die ganzen Anforderungen und Änderungswünsche abzuarbeiten.
Fehlersituationen gibt es auch hier. Und die Konfigurationen wurden brav "nebenan" gesichert. Ich denke, wir alle kennen alle die "httpd.conf.20180514", "sshd.conf.bak", ".profile.sav4" oder (vielleicht sogar am besten) "__tomcat6.conf". Dazu hatte man den Zeitstempel der Datei und konnte (fast) immer nachvollziehen, welche Veränderungen vorgenommen wurden mit der Betonung auf 'fast'. Das Wieso wurde, hoffentlich in die Kommentare der Datei eingetragen (oder vergessen).
Wenn die administrierende Person einigermaßen faul und schlau war – ich verweise hier gerne auf ein Zitat Bill Gates', welcher einst sagte: "Ich werde immer einen Faulen auswählen, um einen schwierigen Job zu erledigen, weil ein Fauler einen einfachen Weg findet, es zu tun." hat sie die Installationen und Konfigurationsänderungen mit einem Script auf die Systeme ausgerollt.
Jetzt kommen wir zu einem "Henne-und-Ei-Punkt". Ich bin auf der Seite, die sagt, die Operatoren haben zuerst die Scripte ins Git gebracht. Die andere, die sagt, die Konfigs waren zuerst im Git, kann ebenfalls Recht haben. Jedenfalls haben sich die Administrierenden auch mit den Code-Verwaltungsmöglichkeiten beschäftigt. Und es kam eins zum anderen und die Konfigs landeten neben den Änderungsscripten im Git. Und wurden mit Issues verwaltet.
Da mein Team und ich in unserem Arbeitsalltag viel (sehr viel) mit Ansible arbeiten, waren unsere Scripte natürlich Ansible Playbooks. Ansible ist ein Automatisierungstool, das für Installation und Konfiguration von Infrastruktur entwickelt wurde. Es wurde mit folgenden Designzielen entwickelt: minimalistisch, sicher, zuverlässig und leicht erlernbar.
'Minimalistisch' in dem Sinne, als dass es keine zusätzliche Clientsoftware auf dem zu automatisierenden System benötigt. So lassen sich Systeme, die "direkt aus der Wand gefallen" sind, sofort nutzen. Das lästige Henne-Ei-Problem entfällt.
Das ist auch für mich ein Punkt, der sicherheitstechnisch von Vorteil ist. Die genutzten Dienste werden durch den Betriebssystemhersteller aktualisiert. Die Kommunikation zu den Systemen erfolgt natürlich verschlüsselt, an einen anderen Weg ist aktuell nicht mehr zu denken.
Nun kommen wir zu einer der wichtigsten Eigenschaften von Ansible, die Zuverlässigkeit. Ansible funktioniert "idempotent" oder auch "deklarativ". Die kurze Erklärung dazu ist, man beschreibt den gewünschten Zustand und nicht die Schritte, die zu tun sind. Für erfahrene Script-Schreiberlinge ist dies eine "kleine" Umgewöhnung, die sich aber lohnt. Die Aufgaben sind mit weniger Codezeilen erfüllt. Man kann diese Automatisierungen auch einfach durchlaufen lassen, und es passiert im Idealfall nichts. Naja, nicht ganz "nichts". Man weiß, dass das System sich in dem Zustand befindet, den ICH möchte. Und ungeliebte Änderungen von Usern (oder Hackern, was sich manchmal gleich anfühlt) werden durch die Vorgaben der Administration ersetzt.
Den letzten Punkt "leicht erlernbar" kann man hier aus der Sichtweise erklären, dass auch Personen, die noch nicht mit Ansible in Berührung gekommen sind, die Playbooks lesen und verstehen können. Die Playbooks sind idealerweise im YAML-Format geschrieben. Idealerweise deshalb, weil dies auch in JSON möglich ist,aber dies nicht gut bei den Kolleginnen und Kollegen ankommt.
YAML ist in der Formatierung sehr restriktiv und an Python angelehnt. Es wird eingerückt, was zusammengehört. Das Ergebnis ist ein hervorragend menschenlesbarer Code. In Ansible gibt es keine Befehle oder Kommandos, sondern fertige Module für extrem viele Funktionen. In den Modulen ist die Idempotenz verbaut. Diese sind via Argumente anpassbar, und diese Argumente kann man als Variable "von außen" mitgeben. Somit ist ein Playbook für alle Stages nutzbar. Die variablen Teile, wie zum Beispiel Systemnamen, IP, Usernamen, einzelne Konfigurationen oder Verzeichnisnamen und Pfade, können in extra Variablendateien oder in den Inventories ausgelagert werden.
Was in einigen Unternehmen einen großen Vorteil bringt: Man kann die (Automatisierungs-)Logik signieren oder zertifizieren. Der dynamische Teil wird von davon ausgelassen und man muss nicht bei jedem zusätzlichen oder neuen Rechner die Logik neu zertifizieren lassen. Da freuen sich auch die Security-Abteilung und das Controlling.
Nun "lasst uns die Strahlen kreuzen", wie man in Ghostbusters hören konnte.
Man lege sich eine (YAML) Datei mit den notwendigen Namen der Softwarepakete an, die man braucht. Dies kann man mit einer initialen Liste der installierten Software ergänzen. Dies nehmen wir als Input für ein Playbook, welches dies kontrolliert und eventuelle unerwünschte Software entfernt. Jetzt besteht die Magie darin, Personen mit Admin-Rechten im Maschinenraum, zu motivieren, nur noch diese Softwareliste zu pflegen und die Automation zu starten - erstmal manuell. Systeme, die zusätzliche Programme oder Libraries benötigen, können in der Liste auch bedacht werden, da findet jeder seinen eigenen Weg
Wir starten diese Automation im Ansible Controller dann jede Woche zwei bis drei Mal per Scheduler. Dies kann man zum Beispiel für die verschiedenen Stages kaskadierend machen, sodass am Montag die Test Stage kontrolliert wird und am Donnerstag die Prod Stage. Bis dahin sollten alle Fehler aufgetaucht sein, und man kann im Notfall zurückgehen. Das Zurückgehen wird durch Git sehr einfach. Man muss lediglich den letzten Commit wieder aktiv setzen und die Automation laufen lassen.
Jetzt gibt es auch Menschen, die meinen, es müsse doch sofort durch eine Pipeline ausgerollt werden. Ich bin der Meinung, dass das jeder für sich entscheiden kann. Der Schedule hat den Vorteil, dass man nur zwei Komponenten hat, Git und Ansible (Red Hat Ansible Automation Platform oder zum Anfangen AWX, das OpenSource Upstream Projekt). Man kann auch einen direkten Webhook-Aufruf zur Automation nutzen. Aber seien wir mal ehrlich zu uns, bis wir eine saubere Änderung haben, brauchen wir mehrere Commits. Und das bedeutet viele fehlerhafte Aufrufe. Und eine Pipeline verlängert die Laufzeit und ist ein zusätzlicher fehlerbehafteter Punkt. Aber ganz nach William Shakespeare: "Wie es euch gefällt".
Mit diesem Grundsystem kann man starten und es mit vielfältigen Use Cases erweitern, zum Beispiel SSH Keys verteilen oder Userkontexte einrichten (jeder hat eine eigene .bashrc, oder diverse andere Customize-Dateien).
Ja, es geht auch, dass man ganze Applikation-Konfigurationen im Git pflegt und diese regelmäßig auf die Systeme verteilt. Denn in den meisten Fällen bleibt eine Konfiguration gleich und dies wird durch Ansible kontrolliert. Wenn so eine Automation eine Änderung feststellt, kann man sich als pflichtbewusster Systemverantwortlicher eine Mail schicken lassen oder gleich ein Ticket beim Security-Team erstellen. Das Security-Team freut sich auch über die sehr übersichtlichen manuellen administrativen Tätigkeiten und die Nachvollziehbarkeit der Änderungen. Warum man ein neues RPM auf dem System hat oder warum der Wert in der Konfiguration so eingestellt ist, steht ja in der Commit-Message im Git. Und man sieht dort auch, wer es eingetragen hat.
Die verschiedenen Konfigurationen in den Stages kann man beispielsweise mit Branchen lösen und das Mergen (die Übernahme in den oder den nächsten Branch) wird im Team durchgeführt. Da ist das Vier-Augen-Prinzip gleich gewahrt und durch die Genehmigung im Git auch bestätigt.
Zusammenfassend können wir sagen, dass wir durch Git einen "Single-Point-of-Truth" haben. Die Funktionen, die es bietet, sind für die Admin-Crew genauso gewinnbringend wie für die Entwickler beim Coding. Commits zum Nachvollziehen von Änderungen, Merges zur Übernahme in die nächste Stage.
Ansible als Ersatz für das manuelle Administrieren der Systeme ist bestimmt schon in vielen Firmen (oder im Home-Lab) im Einsatz. Durch die Nutzung von Red Hat AAP (Ansible Automation Platform) im kritischen Business Use Case oder AWX zum Einstieg (oder im Home-Lab) hat man die manuelle Arbeit automatisiert und kann die Jobs regelmäßig starten lassen. Das Vertrauen in die selbst erstellten Automationen sollte man haben, oder durch die ersten 1701 manuellen Aufrufe bekommen.Die Security-Verantwortlichen sind auch begeistert, da man kaum noch direkte manuelle Verbindungen zu den Systemen im Rechenzentrum benötigt und jede Änderung nachvollziehbar ist.
Persönlich möchte ich die Tatsache hervorheben, dass durch diese Arbeitsweise und dieses Verfahren die Mauer zwischen den Teilen Dev und Ops abgebaut wird. Dies ist ein Resultat der gemeinsamen Nutzung gleicher Tools sowie die dadurch entstandene Einsicht in die Arbeitsweise der anderen Seite. Das Management kann durch den agilen Ansatz der möglichen häufigen Aktualisierungen auch gut gestimmt sein. Und wenn der Chef dann nachfragt, was man dann den ganzen Tag macht, kann man ihm sagen, dass das Admin-Team mit Bombenentschärfern vergleichbar ist. Wenn die in Stress und Hektik sind, sollten alle im Haus nervös sein. Diese Situation beschreibt auch das "Admin-Paradoxon".
