Was ist Ansible?

Wofür Ansible eingesetzt wird

Ansible nimmt Administratoren wiederkehrende Arbeit an vielen Systemen ab. Typische Aufgaben sind das Einrichten frisch installierter Server, das Verteilen von Konfigurationsdateien, Benutzern und Firewallregeln, das Einspielen von Updates in festgelegter Reihenfolge und das Ausrollen von Anwendungen. Neben Linux-Servern steuert Ansible Windows-Systeme, Netzwerkgeräte von Herstellern wie Cisco oder Juniper sowie Cloud-Dienste.

Gesteuert wird alles von einer Steuerstation, dem Control Node, auf dem Ansible installiert ist. Das muss ein Linux- oder macOS-System sein, unter Windows geht es nur über das Linux-Subsystem WSL. Die Zielsysteme, die Managed Nodes, brauchen dagegen nichts außer einem SSH-Zugang und Python, das auf Linux ohnehin vorhanden ist.

Inventar, Playbook, Modul, Rolle

Vier Begriffe tragen das ganze Werkzeug:

• Inventar

  Listet die Hosts und ordnet sie Gruppen zu, etwa Webserver, Datenbanken oder Standorte. Es kann eine statische Datei sein oder dynamisch aus einer Cloud-Umgebung erzeugt werden.

• Modul

  Ein fertiger Baustein für eine Aufgabe, etwa Pakete installieren, Dienste starten, Dateien anlegen oder Benutzer verwalten. Ansible bringt Tausende davon mit, gebündelt in Collections.

• Playbook

  Eine YAML-Datei, die festlegt, welche Hostgruppe welche Aufgaben bekommt. Jede Aufgabe ruft ein Modul mit Parametern auf.

• Rolle

  Ein wiederverwendbares Paket aus Aufgaben, Vorlagen, Dateien und Standardwerten, das mehrere Playbooks einbinden können.

Variablen hängen an Gruppen oder einzelnen Hosts, damit dieselbe Aufgabe im Testsystem andere Werte bekommt als in der Produktion. Konfigurationsdateien entstehen aus Jinja2-Vorlagen, in die Ansible diese Variablen einsetzt.

Ein Playbook im Beispiel

Das folgende Playbook sorgt dafür, dass auf allen Hosts der Gruppe webserver der Webserver nginx installiert ist und läuft. Mit become: true führt Ansible die Aufgaben mit Root-Rechten aus.

- name: Webserver einrichten
  hosts: webserver
  become: true
  tasks:
    - name: nginx installieren
      ansible.builtin.package:
        name: nginx
        state: present

    - name: nginx starten und beim Booten aktivieren
      ansible.builtin.service:
        name: nginx
        state: started
        enabled: true

# Ausführen, zuerst als Trockenlauf:
# ansible-playbook -i inventory.ini site.yml --check --diff

Auffällig ist, dass nirgends „installiere“ oder „starte“ als Befehl steht. Die Aufgaben beschreiben einen Zustand: present heißt installiert, started heißt läuft. Ist nginx schon da und aktiv, meldet Ansible ok und tut nichts. Fehlt etwas, stellt es den Zustand her und meldet changed.

Idempotenz ist der eigentliche Punkt

Diese Eigenschaft heißt Idempotenz: Dasselbe Playbook kann beliebig oft laufen, und ab dem zweiten Lauf ändert sich nichts mehr, solange niemand am System gedreht hat. Dadurch taugt ein Playbook nicht nur zum Einrichten, sondern auch zur Kontrolle. Meldet ein Lauf auf einem eingerichteten Server plötzlich changed, hat jemand von Hand etwas verändert.

Wer Aufgaben über die Module shell oder command löst, gibt genau diese Eigenschaft auf, denn ein roher Befehl läuft bei jedem Durchlauf, egal wie das System gerade aussieht. Wenn es ohne ihn nicht geht, gehört eine Bedingung dazu, etwa creates mit dem Pfad einer Datei, die der Befehl erzeugt, oder changed_when, das festlegt, wann das Ergebnis als Änderung gilt.

Ad-hoc-Befehle und die wichtigsten Optionen

Nicht alles braucht ein Playbook. Für einmalige Aufgaben ruft der Befehl ansible ein einzelnes Modul direkt auf, ein sogenannter Ad-hoc-Befehl. Diese Optionen brauchst du dabei am häufigsten:

Drei typische Aufrufe sehen so aus:

ansible all -i inventory.ini -m ansible.builtin.ping
ansible webserver -i inventory.ini -a "uptime"
ansible webserver -i inventory.ini -b -m ansible.builtin.service -a "name=nginx state=restarted"

Die drei Beispielzeilen prüfen, ob alle Hosts erreichbar sind, fragen auf allen Webservern die Laufzeit ab und starten dort nginx mit Root-Rechten neu. Dieselben Optionen gelten auch für ansible-playbook, und gerade -l und --check sind die Absicherung, bevor eine Änderung auf die ganze Produktion geht.

Ansible, ansible-core und die Automation Platform

Unter dem Namen Ansible laufen mehrere Dinge. ansible-core ist die Laufzeit mit den Befehlen und den eingebauten Modulen. Das Paket ansible bringt zusätzlich eine große Auswahl von Community-Collections mit. Weitere Collections und Rollen holst du über Ansible Galaxy.

Die Red Hat Ansible Automation Platform ist das kommerzielle Produkt darüber. Sie ergänzt eine Weboberfläche zum Starten und Planen von Läufen, Rechteverwaltung, Protokollierung und zertifizierte Collections. Das freie Projekt AWX ist die quelloffene Grundlage dieser Oberfläche.