Ansible lernen: vom ersten Playbook zur eigenen Rolle

Ansible richtet Server über SSH ein, ohne dass auf ihnen ein Agent laufen muss. Du beschreibst in YAML, wie ein Server aussehen soll, und Ansible ändert nur, was davon abweicht. Ein gutes Playbook ist idempotent: Der zweite Lauf meldet keine Änderung mehr. Wächst ein Playbook, machst Du daraus eine Rolle, schützt Geheimnisse mit ansible-vault und prüfst den Code mit ansible-lint.

01Wofür wir Ansible nutzen

Ansible ist bei uns das Werkzeug für alles, was in einem Server passiert: Pakete, Konfiguration, Benutzer, Härtung. Die VM selbst legt vorher Terraform an. Jede Änderung steht zuerst im Repository, läuft im Prüfmodus und wird erst dann eingespielt.

02Installation, Inventar und Ad-hoc-Befehle

Ansible läuft auf Linux und macOS, unter Windows in WSL. Am einfachsten installierst Du es mit pipx install --include-deps ansible, ansible-lint mit pipx install ansible-lint.

Das Inventar sagt Ansible, welche Server es gibt und wie es sie erreicht. Leg in Deinem Repository ein Verzeichnis ansible/ an und darin inventory.ini. Die Adressen sind Beispiele:

[debian]
uebung-01 ansible_host=192.168.178.51
uebung-02 ansible_host=192.168.178.52

[debian:vars]
ansible_user=debian

Für eine schnelle Frage an alle Server der Gruppe reicht ein Ad-hoc-Befehl:

ansible debian -i inventory.ini -m ansible.builtin.ping
ansible debian -i inventory.ini -m ansible.builtin.command -a "uptime"

Antwortet jeder Server mit pong, stimmen SSH-Zugang und Python auf dem Ziel. Ad-hoc-Befehle hinterlassen keine Spur im Repository. Für alles, was bleiben soll, schreibst Du ein Playbook.

03Das erste Playbook

webserver.yml installiert nginx, liefert eine eigene Startseite aus und lädt nginx neu, wenn sich die Konfiguration ändert:

---
- name: Webserver einrichten
  hosts: debian
  become: true
  vars:
    webserver_begruessung: "Hallo aus Ansible"
  tasks:
    - name: Nginx installieren
      ansible.builtin.apt:
        name: nginx
        state: present
        update_cache: true
        cache_valid_time: 3600

    - name: Seitenkonfiguration ausliefern
      ansible.builtin.template:
        src: default.conf.j2
        dest: /etc/nginx/sites-available/default
        mode: "0644"
      notify: Nginx neu laden

    - name: Startseite ausliefern
      ansible.builtin.template:
        src: index.html.j2
        dest: /var/www/html/index.html
        mode: "0644"

  handlers:
    - name: Nginx neu laden
      ansible.builtin.service:
        name: nginx
        state: reloaded

Die Vorlagen liegen im Ordner templates/ neben dem Playbook. In index.html.j2 steht etwa <h1>{{ webserver_begruessung }} auf {{ inventory_hostname }}</h1>, in default.conf.j2 ein Server-Block mit listen 80 default_server;, root /var/www/html; und index index.html;.

• Modul: apt, template und service sind Module. Schreib sie mit vollem Namen wie ansible.builtin.apt, dann ist klar, woher sie kommen.
• Variable: webserver_begruessung wird in der Vorlage ersetzt. Variablen können auch aus group_vars/ oder host_vars/ kommen.
• Handler: Er läuft nur, wenn ein Task ihn per notify ruft und dabei etwas geändert hat. Rufen ihn mehrere Tasks, läuft er trotzdem nur einmal am Ende.

04Idempotenz und Prüfmodus

Idempotent heißt: Egal wie oft das Playbook läuft, das Ergebnis ist dasselbe. Module wie apt und template prüfen zuerst den Ist-Zustand und ändern nur bei Abweichung. Spiel das Playbook zweimal ein:

ansible-playbook -i inventory.ini webserver.yml
ansible-playbook -i inventory.ini webserver.yml

Der zweite Lauf muss in der Zusammenfassung changed=0 melden. Ab jetzt läuft jede Änderung zuerst im Prüfmodus. Ändere den Text in webserver_begruessung und hänge --check --diff an den Befehl. Ansible ändert dann nichts, zeigt aber, welche Tasks etwas ändern würden, bei Dateien Zeile für Zeile. Passt das Ergebnis, spielst Du ohne --check ein.

05Vom Playbook zur Rolle

Eine Rolle bündelt Tasks, Handler, Vorlagen und Variablen in einer festen Ordnerstruktur und lässt sich in vielen Playbooks wiederverwenden. Das Gerüst legst Du mit ansible-galaxy role init --init-path roles webserver an, die Kurzform ansible-galaxy init macht dasselbe. Dann ziehst Du um: Tasks nach roles/webserver/tasks/main.yml, den Handler nach handlers/main.yml, die Vorlagen nach templates/ und die Variable mit Standardwert nach defaults/main.yml. Variablen einer Rolle beginnen mit ihrem Namen, darum heißt sie schon webserver_begruessung. Im Playbook ersetzt dann roles: [webserver] den ganzen Block tasks und handlers.

06Geheimnisse mit ansible-vault

Kennwörter und Tokens stehen nie im Klartext im Repository. ansible-vault verschlüsselt sie mit AES256. Bewährt hat sich eine Trennung in zwei Dateien unter group_vars/debian/:

ansible-vault create group_vars/debian/vault.yml
ansible-playbook -i inventory.ini webserver.yml --ask-vault-pass

In der verschlüsselten vault.yml steht zum Beispiel vault_monitoring_token: <Dein-Geheimnis>. In der lesbaren vars.yml daneben steht monitoring_token: "{{ vault_monitoring_token }}". So siehst Du im Code, welche Variable es gibt, ohne ihren Wert zu kennen. Mit ansible-vault edit änderst Du die Datei später.

07Code prüfen mit ansible-lint

Ein ansible-lint --profile production im Verzeichnis ansible/ findet fehlende Namen, kurze Modulnamen, Befehle ohne changed_when, zu offene Dateirechte und vieles mehr. production ist das strengste Profil. Lass ansible-lint vor jedem Commit laufen, am besten automatisch.

Die Rolle aus diesem Artikel ist das Muster für alles Weitere. Im Artikel Linux-Server nach CIS Benchmark härten baust Du nach demselben Prinzip eine Rolle mit Härtungsregeln und misst das Ergebnis mit Wazuh.

08Übung

1. Leg zwei Debian-13-VMs mit Snapshot an, schreib das Inventar und prüfe den Zugang mit ping.
2. Schreib webserver.yml mit beiden Vorlagen, spiel es ein und ruf die Startseiten im Browser auf.
3. Lass das Playbook ein zweites Mal laufen und prüfe changed=0.
4. Ändere die Begrüßung, sieh Dir die Änderung mit --check --diff an und spiel sie dann ein.
5. Bau daraus die Rolle webserver und leg ein Geheimnis mit ansible-vault an.
6. Bring ansible-lint --profile production auf null Meldungen.

Geschafft, wenn: Der zweite Lauf keine Änderung meldet, eine Änderung an der Seitenkonfiguration genau einmal den Handler auslöst und ansible-lint nichts mehr findet.

09Typische Fallen

• Prüfmodus scheitert auf neuen Servern: Im Prüfmodus wird nginx nicht wirklich installiert. Ein späterer Task, der ein Verzeichnis des Pakets oder den Dienst braucht, schlägt dann fehl. Spiel den allerersten Lauf deshalb auf einer VM mit Snapshot direkt ein.
• command und shell melden immer eine Änderung: Nimm ein passendes Modul oder setz changed_when und creates.
• Handler laufen nicht: Bricht ein Lauf vor dem Ende ab, laufen gerufene Handler nicht mehr. Beim nächsten Lauf ist die Datei schon geändert, also ruft sie niemand. Lade den Dienst dann einmal gezielt neu.
• sudo will ein Kennwort: Braucht Dein Benutzer für sudo ein Kennwort, scheitert become. Gib dann -K mit, damit Ansible nachfragt.
• Meldungen aus dem Rollengerüst: Die Dateien von ansible-galaxy role init enthalten Platzhalter, etwa in meta/main.yml, die ansible-lint meldet. Füll sie aus oder lösch, was Du nicht brauchst.
• Vault-Kennwort im Repository: Wer das Kennwort in eine Datei schreibt, darf diese Datei nie committen. Trag sie in die .gitignore ein.

10Häufige Fragen zu Ansible

Brauche ich auf den Servern einen Agenten? Nein. Ansible braucht auf dem Ziel nur SSH und Python, beides bringt Debian in der Regel schon mit. Gesteuert wird alles von Deinem Rechner aus, dem sogenannten Control Node.

Was ist der Unterschied zwischen Playbook und Rolle? Ein Playbook sagt, welche Aufgaben auf welchen Servern laufen. Eine Rolle ist ein wiederverwendbares Paket solcher Aufgaben mit Vorlagen, Handlern und Standardwerten. Ein Playbook ruft eine oder mehrere Rollen auf.

Warum soll der zweite Lauf nichts mehr ändern? Nur dann beschreibt Dein Code wirklich einen Zustand. Ein Playbook, das bei jedem Lauf etwas umbaut, verdeckt echte Abweichungen. Nur ein idempotentes Playbook kannst Du gefahrlos im Prüfmodus gegen den Live-Stand laufen lassen.

Darf ich mir Playbooks von einer KI schreiben lassen? Ja, das machen wir auch. Prüfe aber jede Zeile, lass das Ergebnis durch ansible-lint und den Prüfmodus laufen und gib nie Zugangsdaten in ein KI-Werkzeug ein. Mehr dazu steht im Artikel Arbeiten mit KI in der IT.

11Weiter im Lernpfad

Zurück zur Übersicht: Lernpfad IT-Infrastruktur. Die VMs für die Übung baust Du in der Proxmox-Übungsumgebung oder per Terraform. Danach geht es weiter mit der Härtung nach CIS Benchmark und einem Inventar aus NetBox. Ansible gehört zum Alltag in unserem Praktikum Fachinformatiker Systemintegration. Wenn Du lieber eigene Module und Werkzeuge rund um die Automatisierung schreibst, sieh Dir das Praktikum Fachinformatiker Anwendungsentwicklung an.

Zuletzt geprüft: Oktober 2026