# Ansible Playbooks: Struktur & Logik für komplexe Automatisierungen

TL;DR / Management Summary Während Ad-hoc Befehle (Artikel 793) für schnelle Checks gut sind, bilden Playbooks die eigentliche Macht von Ansible. In einer YAML-Datei definieren wir den vollständigen Soll-Zustand eines Systems. Ein Senior Admin nutzt Playbooks zur Orchestrierung: Wir definieren Tasks (Aufgaben), nutzen Variables zur Anpassung und setzen Handlers ein, um Dienste nur dann neuzustarten, wenn sich eine Konfiguration wirklich geändert hat.

# 1. Aufbau eines Playbooks

Die Sprache der Ordnung.

Ein Playbook besteht aus einem oder mehreren “Plays”:

---
- name: Configure Webservers
  hosts: webservers
  become: yes
  vars:
    http_port: 80
  
  tasks:
    - name: Install Apache
      apt:
        name: apache2
        state: present

    - name: Copy index.html
      template:
        src: index.html.j2
        dest: /var/www/html/index.html
      notify: Restart Apache
  
  handlers:
    - name: Restart Apache
      service:
        name: apache2
        state: restarted

# 2. Kern-Konzepte: Tasks & Module

Präzise Anweisungen.

Jeder Task ruft ein Modul auf.

• Name: JEDER Task braucht einen beschreibenden Namen. Dies ist Ihre Dokumentation.
• Module: z.B. apt, copy, file, systemd, user.
• Loops: Führen Sie Aufgaben für eine Liste aus:

- name: Create Users
  user:
    name: "{{ item }}"
  loop:
    - alice
    - bob
    - charlie

# 3. Deep Dive: Handlers & Benachrichtigungen

Intelligente Neustarts.

Ein Handler ist ein spezieller Task, der nur ausgeführt wird, wenn ein anderer Task den Status changed meldet.

• Szenario: Sie kopieren eine neue Config-Datei.
• Aktion: Der copy Task ruft via notify den Handler auf.
• Vorteil: Wenn die Config-Datei schon identisch auf dem Server liegt, wird der Dienst nicht unnötig neugestartet (Vermeidung von Downtime).

# 4. Day-2 Operations: Variablen & Templates (Jinja2)

Ein Playbook für alle Umgebungen.

Nutzen Sie Jinja2 Templates, um Konfigurationsdateien dynamisch zu generieren.

• Template: listen {{ http_port }};
• Vars: Setzen Sie den Port in der host_vars oder group_vars Datei fest.
• Ergebnis: Das gleiche Playbook konfiguriert den Dev-Server auf Port 8080 und den Prod-Server auf Port 80.

# 5. Troubleshooting & “War Stories”

Wenn YAML nicht will.

# Top 3 Fehlerbilder

1. Symptom: “Syntax Error: Mapping values are not allowed here”.

   • Ursache: Einrückungsfehler (Indentation). In YAML zählt jeder Leerschritt.
   • Lösung: Nutzen Sie einen Editor mit YAML-Validierung (VS Code) oder ansible-lint.

2. Symptom: Variablen werden als {{ my_var }} ausgegeben statt ersetzt.

   • Ursache: Die Anführungszeichen fehlen.
   • Fix: Nutzen Sie dest: "{{ my_path }}" (Immer Quoten, wenn ein String mit einer Variablen beginnt).

3. Symptom: Playbook hängt endlos bei einem Task.

   • Fix: Nutzen Sie -vvv (Verbose Mode), um die rohen SSH-Befehle zu sehen.

# “War Story”: Der “Blind-Copy” Fehler

Ein Admin nutzte das copy Modul, um eine /etc/fstab auf 20 Server gleichzeitig zu verteilen. Das Ereignis: Er hatte vergessen, dass die Server unterschiedliche UUIDs für ihre Festplatten hatten. Das Ergebnis: Nach dem nächsten Reboot startete kein einziger Server mehr, da sie versuchten, die (falschen) Partitionen des Quell-Servers zu mounten. Lehre: Nutzen Sie für Systemdateien niemals copy, sondern immer template oder das Modul lineinfile, um nur spezifische Zeilen sicher zu ändern.

# 6. Monitoring & Reporting

Qualitäts-Checks.

# Check Mode (Dry Run)

Führen Sie Playbooks erst testweise aus:

ansible-playbook site.yml --check --diff

• KPI: Changed Count. Wenn ein täglicher Wartungslauf plötzlich 100 Änderungen meldet, obwohl Sie nichts geändert haben -> Gefahr von Configuration Drift!

# 7. Fazit & Empfehlung

Playbooks sind die Standard-Arbeitsanweisungen Ihres Teams.

• Empfehlung: Halten Sie Playbooks klein und fokussiert (z.B. ein Playbook nur für “Security Hardening”).
• Wichtig: Kommentieren Sie komplexe Regex-Ausdrücke in lineinfile oder replace Modulen. Niemand versteht diese 6 Monate später ohne Hilfe.

# Anhang: Die wichtigsten Module für Admins

# Referenzen

• Ansible: Playbook Best Practices
• Jinja2 Template Designer Documentation
• Ansible-Lint (Code Quality Tool)