1. Prüfen

cd examples/14-assertions-preflight
ansible-inventory --graph
ansible-playbook playbooks/site.yml --syntax-check
ansible-playbook playbooks/site.yml --check --diff
ansible-playbook playbooks/site.yml
ansible-playbook playbooks/site.yml

2. Lernpunkte

• Inventory und Scope werden vor Ausführung geprüft.
• Das Playbook ist klein genug für Review im Training.
• Check Mode und Diff Mode werden genutzt, wenn das Modul sie unterstützt.
• Der zweite Lauf dient als Idempotenznachweis.

3. Ziel

Dieses Beispiel zeigt einen konkreten, lokal nachvollziehbaren Anwendungsfall für Ansible. Es nutzt localhost, lokale Dummy-Dateien oder Dokumentationsdaten und vermeidet produktive Änderungen.

4. Voraussetzungen

• Ubuntu-basierte Lab-Umgebung.
• Ansible ist installiert.
• Die Workshop-Dateien liegen lokal vor.
• Keine echten Secrets oder produktiven Daten verwenden.

5. Dateien

• ansible.cfg setzt Inventory und lokale Rollenpfade.
• inventory/ enthält Lab-Zielsysteme.
• playbooks/site.yml enthält den auszuführenden Ablauf.
• Weitere Dateien wie templates/, tasks/, roles/ oder collections/ ergänzen das jeweilige Thema.

6. Ausführung

1. Lies README und Sprachdokumentation.
2. Prüfe Inventory und Zielhosts.
3. Führe Syntaxcheck aus.
4. Führe Check Mode und Diff Mode aus.
5. Führe das Playbook aus.
6. Führe es erneut aus und bewerte Idempotenz.

7. Erwartetes Ergebnis

Das Beispiel liefert eine nachvollziehbare Ausgabe, eine Markerdatei unter /tmp oder eine reine Debug-/Validierungsausgabe. Es darf keine echten Secrets offenlegen und keine produktiven Systeme ändern.

8. Erklärung

Die Umsetzung demonstriert einen typischen Praxisbaustein. Wichtig sind Reproduzierbarkeit, Lesbarkeit, sichere Dummy-Werte, enger Scope und einfache Rückbaubarkeit.

9. Typische Fehler

• Beispiel wird aus falschem Arbeitsverzeichnis gestartet.
• Inventory wird nicht geladen.
• Check Mode wird als vollständige Simulation missverstanden.
• Markerdateien unter /tmp werden mit produktivem Zustand verwechselt.
• Ein Pattern wie all wird ohne --list-hosts verwendet.

10. Erweiterungsmöglichkeiten

• Beispiel um zweite Umgebung erweitern.
• Validierung automatisieren.
• Security- und Troubleshooting-Notizen ergänzen.
• In eine Workshop-Übung oder Assessment-Frage überführen.