Automatisierung mit Ansible

Konfigurationsmanagement für Linux ist mittlerweile ja ein alter Hut. Es ist eine Unmenge an Tools und Programmen erhältlich. Bloss eins haben sie meist gemeinsam: Man muss viel Zeit investieren, um sich erst einmal mit dem Konfigurationsmanagement vertraut zu machen. Also ist das nichts, was man nebenbei anfangen kann – außer man verwendet Ansible.

Vergleich zu anderen Programmen

Ich hatte davor bereits Chef und Puppet als Konfigurationsmanagement angesehen und bin dabei auf keinen grünen Zweig gekommen. Es musste sowohl am Server als auch auf den Clients zusätzlich Software installiert werden, dann war der Sprachsyntax für die Konfigurationen zu lernen. Das geht nicht einfach mal so, hier muss viel Zeit investiert werden – und die ist meist für solche Automatisierungsthemen nicht vorhanden.

Nicht so bei Ansible: Der Einstieg ist denkbar einfach. Ansible wird auf einem Server installiert (am Besten über die Paketverwaltung, bei Ubuntu gibt es auch ein PPA dafür), als Abhängigkeit gibt es nur eine funktionierende Python-Installation. Dies wird allerdings auch von der Paketverwaltung übernommen. Auf den zu verwaltenden Clients wird nur SSH benötigt. Das war es auch schon. Zudem ist der Syntax der Sprache der verwendeten Dateien einfach und gut zu lesen. Obwohl die Sprache einfach gehalten ist, lassen sich damit Konstrukte wie Variablen, bedingte Anweisungen und Schleifen verwenden. Zudem gibt es die Möglichkeit Rollen zu erstellen, die sich dann auf Server anwenden lassen.

Hier nochmal meine Gründe für die Verwendung von Ansible:

  • Sichere und einfache Verbindung über SSH
  • Keine Clientsoftware notwendig
  • Einfacher Sprachsyntax (YAML)
  • Flexibilität durch die Verwendung von Variablen und Rollen

Clients vorbereiten

Damit der zentrale Server die Clients verwalten kann, benötigt dieser SSH-Zugriff. Will man Ansible-Aufgaben auch automatisiert ausführen (z.B. regelmäßig die Konfiguration überschreiben), so muss der SSH-Schlüssel ohne Passwort erzeugt werden. Dies erfolgt mittels ssh-keygen. Nun muss der Schlüssel nur noch auf die zu verwaltetenden Clients kopiert werden:

ssh-copy-id user@server

Playbooks erstellen

In Ansible werden die Konfigurationen in sog. Playbooks abgespeichert. Das sind Dateien, die in YAML, einer einfachen Auszeichnungssprache, verfasst sind. Dort beschreibt man im Prinzip den Zustand, in dem man das System haben möchte. Wie sieht so etwas aus? Hier z.B. die Installation von NTP:


- hosts: 10.1.1.1
tasks:
- name: install ntp
apt: pkg=ntp state=installed

Im Vergleich: Apache-Installation manuell vs. Ansible

So installiert man einen Apache-Server über die Shell:


apt-get install apache2

Und diesen Code benötigt man für Ansible:

- apt: name=apache2 state=present

Damit Ansible die Clients kennt, müssen diese entweder in die /etc/ansible/hosts eingetragen werden, oder in eine eigene Datei (nach den Best Practices sollte hierfür eine production und eine stage Datei erstellt werden).

Ausgeführt wird es dann mittels „ansible-playbook -i production apache2-install.yml“. Somit ist die Ansible-Variante eigentlich genauso einfach wie das Shell-Skript. Der Vorteil ergibt sich aber nun, wenn die Installation komplexer wird und z.B. Variablen ins Spiel kommen.

Ansible-Module

Was lässt sich auf den Systemen nun mit Ansible anstellen? Für viele Aufgaben existieren spezielle Module, die das Arbeiten vereinfachen. Selbst, wenn es kein Modul gibt: Ansible kann auch shell-Befehle ausführen. Somit ist der einfachste Weg der Migration von bestehenden Shell-Skripten hin zu Ansible diese Skripte lediglich in ein Playbook zu überführen.

Natürlich ist es im zweiten Schritt dann auch sinnvoll die Ansible Module zu verwenden, da damit z.B. Variablen befüllt werden können, die in weiteren Befehlen verwendet werden können.

Ausblick

Nun weiß ich also, wie ich Playbooks schreibe und was ich damit machen kann. Was bleibt als Ausblick? Ansible bietet die Möglichkeit, Rollen zu erstellen, die wiederum in Tasks gegliedert sind. Dadurch kann ich mir für jeden Server eine passende Konfiguration aus einzelnen Rollen zusammensetzen. So wäre z.B. alle Server Mitglieder der Rolle „common“, in der z.B. die Grundkonfiguration (SSH, NTP, Firewall usw.) integriert ist. Dann gibt es eine spezialisierte Rolle „apache“, die den Apache-Server bereitstellt. Schließlich kann es eine Rolle „apache-php“ geben, die mir den Apache-Server zum Einsatz mit PHP vorbereitet.

Das ist aber alles nur ein kleiner Teil der Funktionen, die Ansible bietet. Bisher habe ich wohl nur an der Oberfläche gekratzt. Weitere Erfahrungen folgen…

Weiterführende Links

Ein Kommentar

  1. Gute Einführung in Ansible. 🙂

    Habe es die letzten Wochen intensiv genutzt und bin begeistert. Was mir noch fehlt ist eine Art eingebaute Rollback Funktion, Ansible verteilt ja immer nur aber baut altes, verteiltes nicht mehr ab.

    Ja es gibt ja brauchbare Strategien mit zusatzlichen Tasks und when-state option. Atm ok 🙂 für später waere eine durchdachte generelle best practice lösung von Ansible wünschenswert

Schreibe einen Kommentar