Kennen Sie das? Es steht eine regelmäßige Wartung für einen virtuellen Server an. Ein Mitarbeiter patcht das System. Fünf Minuten später kommt ein dringender Anruf vom First-Level-Support: „Die Maschine ist nicht mehr verfügbar.“
Was ist passiert? Der Mitarbeiter hat den Updateprozess manuell ausgeführt. Danach meldet das Monitoring, dass essenzielle Dienste nicht mehr verfügbar sind. Was ist die Ursache? Der Mitarbeiter hat vergessen, im Monitoringsystem das Wartungsfenster zu setzen. Weiterhin fährt die Maschine nach dem Neustart nicht mehr hoch. Was hat er noch vergessen? Er hat keinen Snapshot erstellt, so dass jetzt auch kein Backup für einen Rollback verfügbar ist.
Zum Glück existieren seit vielen Jahren schlaue Werkzeuge, die der Administration helfen, dass solche Fehler nicht mehr vorkommen. Als wir uns im Jahr 2010 auf die Suche nach einem Automatisierungstool für den Rechenzentrumsbetrieb machten, gab es Ansible noch nicht. Am Open-Source-Markt existierten Tools wie Chef und Puppet, die einen entscheidenden Nachteil hatten: sie waren agentenbasiert. Wenn man bei der Konfiguration einen Fehler machte, konnte eine virtuelle Maschine (VM) oder eine komplette Infrastruktur von einer Sekunde auf die nächste tot sein.
Wir legten das Thema Automatisierung erstmal auf Eis und behalfen uns mit selbst geschriebenen Shell-Skripten als Übergangslösungen. Diese haben uns über viele Jahre gute Dienste geleistet.
Ende 2012 erschien das Open-Source-Tool Ansible auf der Bildfläche und hat die Administrationswelt von Anfang an elektrisiert. Ansible ist eine radikal einfache Lösung und automatisiert vieles: von der Codebereitstellung über die Netzwerkkonfiguration bis hin zur Verwaltung von Cloud-Infrastrukturen. Und zwar in einer einfachen Sprache, ohne dass jemand Agenten auf entfernten Systemen installieren muss. Stattdessen nutzt Ansible unter Linux das SSH-Protokoll, um Befehle auf Zielsystemen auszuführen. Bereits in der Version 2.7 gab es mehr als 2.000 Module für die Produkte unterschiedlichster Hersteller.
Ansible befreit IT-Personal von ungeliebten, manuellen Aufgaben und macht den IT-Betrieb konsistenter und produktiver: egal ob im eigenen Rechenzentrum oder in der Cloud. Seit der Version 0.9 setzen wir es produktiv ein. *
Im Inventar werden die Zielsysteme erfasst, auf denen die Software mithilfe des leistungsfähigen SSH-Protokolls Befehle ausführen soll. Im einfachsten Fall handelt es sich hierbei um eine INI-Datei. Hierbei können die einzelnen Einträge gruppiert werden.
Um alle notwendigen Aufgaben auf einem System auszuführen, wie z. B. die eingangs beschriebenen Wartungsarbeiten, bedienen wir uns eines Playbooks. Innerhalb des Playbooks werden die einzelnen Aufgaben der Reihenfolge nach abgearbeitet, etwa:
Die einzelnen Teilaufgaben in den unterschiedlichen Systemen Monitoring, Hypervisor und VM werden hierbei über Rollen abgewickelt. Eine Rolle kapselt die Tätigkeiten an einem einzelnen System. Jede Rolle hat hierbei eine fest definierte Ordnerstruktur für die einzelnen Komponenten, um Standardeinstellungen, Vorlagen für Konfigurationsdateien oder Tasks zu speichern. (Ausführliche Informationen zur Struktur sind in einem Ansible Bootcamp festgehalten. Schulungen zum Einsatz von Ansible im Unternehmen bieten wir bei Bedarf gerne an.)
Die obligatorische Vorgabe in unserem DevOps-Team lautet: Jeder, der eine virtuelle Linux-Maschine aufsetzt, muss das Linux-Playbook verwenden.
Die Entwicklung und Bereitstellung der Rollen und Playbooks erfolgt durch ein dediziertes Team mithilfe eines SVN-Code-Repositories. Hierfür gibt es eine gesonderte Entwicklungs- und Testumgebung. Die Dokumentation der Rollen erfolgt hierbei automatisiert aus dem zentralen Repository, so dass Informationen bzgl. eventuell notwendiger Konfigurationsparameter jederzeit zur Verfügung stehen. Die Dokumentation wird dabei automatisiert direkt aus den Rollen erzeugt und als durchsuchbare HTML-Dokumentation aufbereitet.
Nach Abschluss der Tests und Freigabe der Rollen und Playbooks stellt das Ansible-Team diese auf dem Produktivsystem bereit. Erst wenn alles reibungslos geklappt hat, darf ein Playbook aktiv genommen werden. Das hat mehrere Vorteile: wir beugen Problemen vor, beseitigen Fehler früher und es macht die Bereitstellung z. B. von virtuellen Maschinen wesentlich schneller, zuverlässiger und koordinierter. Im Linux-Bereich liegt unsere Automatisierungsquote bei mehr als 90 Prozent. Den Rest erledigen wir aus Kosten-Nutzen-Gründen manuell.
Generell ist das Erstellen der Rollen mit Aufwand verbunden, welcher im Einzelfall abgewogen werden muss. Für die Installation einer einzelnen Maschine rechnet sich dieser Aufwand wohl kaum. Dadurch, dass Ansible jedoch „Batteries included“ geliefert wird, hält sich der Aufwand für einfache Rollen in Grenzen, so dass es z. T. bereits ab fünf Maschinen, die ein Playbook verwenden, sinnvoll ist, sich Gedanken über die Automatisierung mittels Ansible zu machen.
Stand heute verwalten wir in unseren Rechenzentren mit Ansible eine Infrastruktur von etwa 200 physischen und virtuellen Maschinen für unsere Kunden und die Concat AG selbst. Seit wir Ansible einsetzen, haben wir viel Zeit gewonnen. Als zum Jahreswechsel 2020-2021 eine Aktualisierung von 20 Knoten unseres Überwachungssystems Zabbix anstand, war das in weniger als einer Stunde erledigt. Ohne Ansible wären wir damit locker zwei bis drei Stunden beschäftigt gewesen.
In unserem Selbstverständnis als Managed-Service-Provider forschen wir permanent nach weiteren klugen Werkzeugen, die uns helfen, die Automatisierung auf ein noch höheres Level zu bringen. Und werden dabei immer wieder fündig. Seit 2019 setzen wir NetBox als Inventardatenbank ein. Zugleich dient es als Managementlösung für Rechenzentrumsinfrastrukturen (DCIM) und IP-Adressen (IPAM). Wir haben NetBox vor allem deshalb gewählt, weil es sich so leicht mit Ansible koppeln lässt: So können wir das Inventar für Ansible bequem über die NetBox-GUI pflegen.
2020 haben wir noch zwei weitere Werkzeuge aus der Open-Source-Gemeinde dazu genommen: Neo4j erleichtert uns die Visualisierung von Datenflüssen, Buildbot nutzen wir als komfortable grafische Benutzeroberfläche – alternativ zu Ansible Tower. Vor einigen Jahren stießen wir auf ProcessMaker, das wir für die Automatisierung von Prozessen verwenden. Über diese Tools berichten wir in künftigen Teilen der Artikelserie, zuvor folgen vertiefende kurze Beiträge über Ansible.
* https://github.com/ansible/ansible/tree/v0.9
Eine schöne Übersicht über Configuration Management-Tools (Open Source) finden Sie hier.
Sie möchten Ansible live erleben? Kontaktieren Sie uns für eine Demo.
