26 Einführung in Playbooks

26.1 Definition und Bedeutung von Playbooks in Ansible

Ein Playbook ist das Herzstück der Ansible-Automatisierung. Es ist eine YAML-Datei, die eine Reihe von Aufgaben (Tasks) definiert, die auf Zielsystemen ausgeführt werden sollen. Playbooks sind deklarativ und beschreiben den gewünschten Zustand der Systeme, ohne die spezifischen Schritte im Detail festzulegen. Ansible kümmert sich darum, die erforderlichen Änderungen vorzunehmen, um diesen Zustand zu erreichen.

Abgrenzung zu Ad-hoc-Befehlen: Im Gegensatz zu Ad-hoc-Kommandos (ansible CLI), die einmalig ausgeführt werden, ermöglichen Playbooks wiederholbare, strukturierte Abläufe mit komplexer Logik und Fehlerbehandlung.

26.1.1 Bedeutung von Playbooks:

1. Automatisierung von IT-Prozessen: Playbooks ermöglichen die Automatisierung von wiederkehrenden Aufgaben, wie Software-Installationen, Konfigurationsänderungen, Benutzerverwaltung und vieles mehr.

2. Infrastruktur als Code: Mit Playbooks können Sie Ihre gesamte IT-Infrastruktur als Code behandeln. Dies fördert die Wiederholbarkeit und Konsistenz der Deployments und Konfigurationen.

3. Modularität und Wiederverwendbarkeit: Playbooks können in kleinere, wiederverwendbare Rollen unterteilt werden, was die Wartbarkeit und Skalierbarkeit erhöht.

4. Klarheit und Transparenz: Durch die Verwendung einer menschenlesbaren YAML-Syntax sind Playbooks leicht verständlich, selbst für Personen ohne tiefes technisches Wissen.

26.2 Grundstruktur eines Playbooks

Die Grundstruktur eines Playbooks besteht aus verschiedenen Schlüsselkomponenten, die zusammenarbeiten, um Aufgaben auf den Zielsystemen auszuführen. Ein einfaches Playbook enthält mindestens die folgenden Elemente:

1. Hosts: Bestimmt die Zielsysteme, auf denen das Playbook ausgeführt wird.
2. Tasks: Die spezifischen Aktionen, die auf den Zielsystemen ausgeführt werden sollen.
3. Module: Die ausführenden Einheiten, die die eigentlichen Aufgaben implementieren (z.B., Installieren von Paketen, Bearbeiten von Dateien).
4. Handlers: Aktionen, die als Reaktion auf eine Änderung ausgeführt werden (z.B., Neustart eines Dienstes nach einer Konfigurationsänderung).
5. Variables (vars): Ermöglichen die Parametrisierung von Playbooks für verschiedene Umgebungen.
6. Rollen (Roles): Die Zerlegung von Playbooks in Rollen (Roles) erlaubt die modulare Strukturierung großer Projekte. Rollen werden in einem späteren Kapitel vertieft behandelt.

Beispiel für ein strukturiertes Playbook:

---
- name: Installiere und konfiguriere Apache Webserver
  hosts: webservers
  become: yes
  
  vars:
    apache_package: apache2
    apache_service: apache2

  tasks:
    - name: Installiere Apache, nur auf Debian-Systemen
      apt:
        name: "{{ apache_package }}"
        state: present
      when: ansible_facts['os_family'] == 'Debian'
      tags:
        - apache
        - packages
      notify:
        - Starte Apache neu

    - name: Starte Apache-Service
      service:
        name: "{{ apache_service }}"
        state: started
        enabled: yes
      tags:
        - apache
        - services

  handlers:
    - name: Starte Apache neu
      service:
        name: "{{ apache_service }}"
        state: restarted

26.2.1 Erläuterung der erweiterten Komponenten:

• vars: Definiert Variablen, die im gesamten Playbook verwendet werden können. Dies erhöht die Flexibilität und Wiederverwendbarkeit.
• when: Ermöglicht bedingte Ausführung von Tasks basierend auf Fakten oder Variablen.
• tags: Erlaubt die selektive Ausführung bestimmter Tasks (z.B. ansible-playbook site.yml --tags apache).
• notify: Verknüpft eine Task mit einem Handler, der nur bei tatsächlichen Änderungen ausgeführt wird.

26.3 YAML-Syntax und Best Practices

YAML (YAML Ain’t Markup Language) ist eine menschenlesbare Datenserialisierungssprache, die für die Erstellung von Playbooks in Ansible verwendet wird. Die einfache und klare Syntax von YAML ist ideal für die Darstellung von hierarchischen Datenstrukturen, wie sie in Playbooks benötigt werden.

26.3.1 Kritische YAML-Grundlagen für Einsteiger

⚠️ Häufiger Einsteiger-Fehler: Ein häufiger Fehler bei Einsteigern sind falsch gesetzte Einrückungen. YAML benötigt präzise Leerzeichen, keine Tabs. Syntaxfehler führen oft zu schwer verständlichen Fehlermeldungen wie mapping values are not allowed here.

26.3.2 Grundlegende YAML-Syntax

• Einrückungen: YAML verwendet Einrückungen, um Hierarchien darzustellen. Eine korrekte Einrückung ist entscheidend für die Lesbarkeit und Funktionalität eines Playbooks.
• Listen: Listen werden durch einen Bindestrich - eingeleitet.
• Schlüssel-Wert-Paare: Diese werden durch : getrennt, wobei der Schlüssel auf der linken Seite und der Wert auf der rechten Seite steht.

Beispiel für YAML-Grundlagen:

---
- name: Einfache YAML-Struktur
  key: value
  list:
    - item1
    - item2
  dictionary:
    nested_key: nested_value

26.3.3 Best Practices für YAML in Playbooks

1. Konsistente Einrückungen: Verwenden Sie immer dieselbe Anzahl von Leerzeichen für Einrückungen (empfohlen: zwei Leerzeichen). Verwenden Sie niemals Tabs.

2. YAML-Syntax-Prüfung: Nutzen Sie Tools wie yamllint oder Online-YAML-Validatoren, um Syntaxfehler frühzeitig zu erkennen.

3. Klare Namensgebung: Verwenden Sie beschreibende Namen für Tasks, Variablen und Playbooks, um deren Zweck klar zu kommunizieren.

4. Vermeidung von Duplikaten: Definieren Sie gemeinsame Variablen und Aufgaben an zentralen Stellen (z.B., in group_vars oder roles), um Duplikate zu vermeiden.

5. Dokumentation: Nutzen Sie die name-Felder und Kommentarzeilen, um den Zweck und die Funktion jeder Komponente des Playbooks zu dokumentieren.

6. Versionskontrolle: Behandeln Sie Playbooks wie Code und verwalten Sie sie in einem Versionskontrollsystem (z.B., Git), um Änderungen nachverfolgen und verwalten zu können.

26.4 Playbook-Cheat-Sheet

# Grundstruktur eines Ansible-Playbooks
---
- name: Beschreibung des Plays
  hosts: <zielgruppe>          # z.B. webservers, all, localhost
  become: yes                  # Erhöhte Rechte (sudo)
  gather_facts: yes           # Sammle Systemfakten (Standard)
  
  vars:                       # Playbook-Variablen
    variable_name: wert
    package_list:
      - package1
      - package2

  tasks:                      # Liste der Aufgaben
    - name: Beschreibung der Aufgabe
      <modul_name>:            # z.B. apt, yum, copy, template
        parameter: wert
        state: present         # desired state
      when: <bedingung>        # z.B. ansible_os_family == "Debian"
      tags:                    # Für selektive Ausführung
        - tag1
        - tag2
      notify: <handler_name>   # Trigger für Handler
      register: result_var     # Speichere Ausgabe in Variable

  handlers:                   # Event-basierte Aktionen
    - name: <handler_name>
      service:
        name: <service_name>
        state: restarted
      listen: <alternative_name>  # Alternative zum direkten Namen

26.4.1 Wichtige Playbook-Befehle

# Playbook ausführen
ansible-playbook playbook.yml

# Mit spezifischen Tags
ansible-playbook playbook.yml --tags "apache,packages"

# Dry-run (Simulation)
ansible-playbook playbook.yml --check

# Verbose-Modus für Debugging
ansible-playbook playbook.yml -vvv

# Nur auf bestimmten Hosts
ansible-playbook playbook.yml --limit "webserver1,webserver2"