1. Ziel

Fehlerstatus unterscheiden.

2. Was gemacht wird

Das Beispiel wird über Inventory-Review, Playbook-Review, Syntaxcheck, Check Mode, Diff Mode, echten Lauf und zweiten Lauf untersucht. Es arbeitet mit sicheren Dummy-Werten.

3. Warum es gemacht wird

Ansible automatisiert Änderungen über Zielgruppen und Module. Jede Änderung braucht deshalb eine klare Zielauswahl, ein nachvollziehbares Modul und eine Validierung nach dem Lauf.

4. Typische Kommandos

ansible-inventory --graph
ansible-playbook playbooks/site.yml --list-hosts
ansible-playbook playbooks/site.yml --syntax-check
ansible-playbook playbooks/site.yml --check --diff

5. Erfolg prüfen

• Inventory zeigt die erwarteten Hosts.
• Syntaxcheck ist erfolgreich.
• Check Mode und Diff Mode sind plausibel.
• Play Recap enthält keine unerwarteten Fehler.
• Zweiter Lauf meldet keine unnötigen Änderungen.

6. Typische Fehler

• falsches Arbeitsverzeichnis.
• ansible.cfg wird nicht geladen.
• Rollenpfad oder Templatepfad stimmt nicht.
• Variable wird aus falscher Quelle überschrieben.
• Check Mode unterstützt das Modul nur teilweise.

7. Sicherheitsaspekte

Keine echten Secrets verwenden. Keine produktiven Hosts verwenden. become nur einsetzen, wenn es im Beispiel ausdrücklich begründet ist. Dummy-Keys und Dummy-Tokens bleiben als solche erkennbar.

8. Realistischer Einsatz

Das Beispiel lässt sich in Runbooks, Review-Checklisten, CI-Jobs, Betriebsdokumentation und Assessment-Aufgaben übertragen.