Ansible Playbook

Eine Playbook-Datei (setup_web.yml) sieht so aus:

---
- name: Setup Webservers  # Name des Plays
  hosts: webservers       # Zielgruppe aus Inventory
  become: yes             # Nutze 'sudo' (Root-Rechte)
  
  tasks:                  # Liste der Aufgaben
    - name: Install nginx (Paket)
      apt:
        name: nginx
        state: present    # "Sorge dafür, dass es da ist"

    - name: Start nginx (Service)
      service:
        name: nginx
        state: started

Ausführen: ansible-playbook -i inventory.ini setup_web.yml. Ansible verbindet sich per SSH, prüft den Zustand und ändert nur das, was nötig ist.

1. Idempotenz & State Management

Das wichtigste Konzept: Idempotenz. Ein Shell-Skript (apt-get install nginx) schlägt fehl, wenn Nginx schon da ist oder macht unnötige Arbeit. Ein Ansible Playbook beschreibt den Zielzustand (state: present). Lauf 1: Nginx fehlt -> Installieren -> Status "Changed". Lauf 2: Nginx ist da -> Nichts tun -> Status "Ok". Das macht Playbooks sicher wiederholbar (Re-runnable). Man kann sie jede Stunde laufen lassen ("Convergence").

2. Jinja2 Templating

Playbooks sind nicht statisch. Du nutzt Jinja2 Templates, um Konfigurationsdateien dynamisch zu bauen. Task: "Kopiere nginx.conf". Inhalt der Config: worker_processes {{ ansible_processor_vcpus }};. Ansible ersetzt die Variable automatisch mit der Anzahl der CPUs des Zielservers. So passt sich die Config automatisch an die Hardware an.

3. Handlers & Notifications

Manchmal darf eine Aktion nur passieren, wenn sich etwas geändert hat. Beispiel: "Starte Nginx neu" NUR wenn "nginx.conf geändert wurde". Dafür nutzt man Handlers. Task A (Config Copy) hat notify: Restart Nginx. Nur wenn Task A "Changed" meldet, wird der Handler am Ende des Playbooks ausgeführt. Das verhindert unnötige Downtime durch ständige Restarts.

Directory Layout & Best Practices

Bei großen Setups wird eine flache Playbook-Struktur schnell zum Alptraum. Die Best Practice (oft als Ansible "Good Practices" referenziert) verlangt strikte Trennung von Inventories und Code. Zentral sind Roles und Collections. Ein sauberes Deployment-Playbook (site.yml) sieht oft nur so aus:

---
- name: Apply DB Configuration
  hosts: databases
  roles:
    - role: postgresql_setup
      tags: db, config
    - role: monitoring_agent
      tags: monitoring

Es "orchestriert" nur. Die echte Logik liegt versteckt in roles/postgresql_setup/tasks/main.yml. Dies ermöglicht sauberes Testing (via Molecule) und Wiederverwendbarkeit in verschiedenen Playbooks.

Asynchrone Tasks & Polling

Wenn du in einem Playbook ein großes Datenbank-Backup anstößt, blockiert Ansible normalerweise die SSH-Verbindung, bis der Task fertig ist. Bei Tasks, die Stunden dauern, bricht das oft durch Timeout ab. Lösung: Asynchronous Actions.

- name: Update massive database table
  command: /opt/scripts/long_update.sh
  async: 3600  # Maximal 1 Stunde Laufzeit
  poll: 0      # Fire and forget / kein Polling
  register: db_update_sleeper

- name: Do other things while waiting
  debug:
    msg: "Doing other tasks..."

- name: Check on the DB update
  async_status:
    jid: "{{ db_update_sleeper.ansible_job_id }}"
  register: job_result
  until: job_result.finished
  retries: 30
  delay: 60

So startest du den Prozess, machst andere Dinge (oder schließt die Verbindung) und fragst den Status später ab.

Strategien (Linear vs. Free)

Standardmäßig arbeitet Ansible linear: Task 1 wird auf allen Servern abgeschlossen, bevor Task 2 beginnt. Wenn einige Server sehr schnell sind und andere extrem langsam, wartet das ganze Cluster auf die Nachzügler. Mit der Einstellung strategy: free auf Playbook-Ebene arbeiten alle Hosts unabhängig voneinander. Server A kann in Task 10 sein, während Server B noch an Task 2 hängt. Dies reduziert Laufzeiten signifikant, ist aber gefährlich, wenn spätere Tasks von globalen Side-Effects abhängen.