Ubuntu in einer VM: Ansible · Ansible

1. Zweck

Vertiefung und Abgabebeispiel zu Zweck

Eine vollständige Bearbeitung von Zweck besteht aus einem technischen Artefakt und einer kurzen fachlichen Einordnung. Das Artefakt kann ein Inventory, ein Playbook, eine Rolle, ein Template, eine Vault-Datei mit Dummy-Werten, eine CI-Konfiguration oder eine Evidence-Datei sein. Die Einordnung erklärt, warum dieser Weg gewählt wurde und welche Alternative bewusst nicht verwendet wurde.

Abgabeteil	Inhalt	Mindestqualität
Zielbeschreibung	Was soll nach dem Lauf gelten?	messbar und ohne implizite Annahmen
Scope-Nachweis	Welche Hosts sind betroffen?	Ausgabe von `--list-hosts` oder Inventory-Graph
Umsetzung	Welche Dateien wurden geändert?	kleine, reviewbare YAML-Dateien
Validierung	Wie wurde geprüft?	Syntaxcheck, Check Mode, Diff, echter Lauf, zweiter Lauf
Risikoentscheidung	Was kann schiefgehen?	Rechte, Secrets, externe Abhängigkeiten und Rollback betrachtet

Minimalartefakte für Zweck

submission/
  inventory/hosts.yml
  playbooks/site.yml
  evidence.md
  cleanup.md

Für Rollen oder Collections wird die Struktur erweitert:

submission/
  ansible.cfg
  collections/requirements.yml
  inventory/hosts.yml
  roles/<role>/defaults/main.yml
  roles/<role>/tasks/main.yml
  roles/<role>/handlers/main.yml
  playbooks/site.yml
  evidence.md

Prüferwartung für Zweck

Eine prüfbare Lösung muss auch für Personen verständlich sein, die den Lauf nicht selbst ausgeführt haben. Deshalb reichen Screenshots oder unkommentierte Terminalausgaben nicht aus. Gute Evidence beschreibt Kontext, Kommando, relevante Ausgabe und Bewertung. Wenn ein Modul im Check Mode abweicht, wird diese Einschränkung ausdrücklich genannt.

Transfer in reale Teams

Im Teamkontext wird Zweck zusätzlich mit Code Review, Branch-Regeln, CI, Rollenownership, Release-Notizen und Betriebsfreigabe verbunden. Für produktionsnahe Nutzung werden außerdem Zuständigkeit, Wartungsfenster, Monitoring, Alarmierung und Rollback-Kriterien dokumentiert.

Praxisbezug zu Zweck

Dieser Abschnitt ist nicht als reine Begriffserklärung gedacht. Im Workshop wird Zweck immer an einem konkreten Ablauf überprüft: Inventory lesen, Zielhosts beweisen, Playbook prüfen, Änderung simulieren, Änderung ausführen, zweiten Lauf bewerten und Rückbau dokumentieren. Dadurch wird sichtbar, ob Ansible wirklich einen Zielzustand beschreibt oder nur zufällig einen Befehl erfolgreich ausgeführt hat.

Prüffrage	Erwartete Antwort
Welche Hosts sind betroffen?	Pattern, Gruppe, `--limit` und Inventory-Ausgabe sind dokumentiert.
Welche Datenquellen wirken?	`group_vars`, `host_vars`, Defaults, Extra Vars und Facts sind bekannt.
Welche Rechte werden benötigt?	`become` ist tasknah und fachlich begründet.
Wie wird Erfolg bewiesen?	Syntaxcheck, Check Mode, Diff, Play Recap und zweiter Lauf liegen vor.

Beispielablauf für Zweck

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

Der Ablauf ist bewusst vollständig. In echten Teams werden einzelne Schritte oft automatisiert, aber nicht übersprungen. CI kann Syntaxcheck und Linting übernehmen; die fachliche Bewertung von Scope, Rechten, Secret-Flows und Rollout-Risiko bleibt eine Review-Aufgabe.

Review-Kriterien für Zweck

Inventory und Pattern sind enger als all, sofern kein guter Grund dokumentiert ist.
Module aus ansible.builtin oder klar geprüften Collections werden bevorzugt.
Shell- oder Command-Tasks haben changed_when, failed_when oder eine Begründung.
Variablen sind nachvollziehbar platziert und überschreiben sich nicht überraschend.
Secrets erscheinen nicht in Klartext, Diff-Ausgaben, Debug-Tasks oder CI-Logs.
Das Playbook kann mehrfach laufen, ohne unnötige Änderungen zu melden.
Rückbau, Fix-forward oder kontrolliertes Belassen des Zielzustands ist dokumentiert.

Typische Fehler bei Zweck

Fehlerbild	Ursache	Diagnose
falsche Hosts getroffen	Pattern oder Inventory falsch verstanden	`--list-hosts`, `ansible-inventory --host`
`unreachable`	SSH, Benutzer, Python oder Netzwerkproblem	`-vvvv`, SSH-Test, Inventory-Variablen
unerwartete Änderung	Modul nicht idempotent oder falsche Datenquelle	zweiter Lauf, Diff, Variablenprüfung
Secret-Leak	Debug, Diff oder Log nicht begrenzt	`no_log`, Vault, CI-Artefakte prüfen
Handler läuft nicht	kein `changed` oder falscher Handlername	Task-Ergebnis und Handler-Name prüfen

Betriebsnotiz für Zweck

Für produktionsnahe Nutzung muss aus dem Lab ein Runbook entstehen. Dieses Runbook nennt Zielsysteme, Verantwortliche, Vorbedingungen, Stop-Kriterien, erwartete Dauer, Validierung, Monitoring und Rückbau. Ohne diese Angaben bleibt ein Playbook technisch ausführbar, aber nicht betriebsreif.

Zweck ist ein praktischer Baustein des Ansible-Workshops. Entscheidend ist, dass der gewünschte Zustand nicht nur beschrieben, sondern vor und nach der Ausführung überprüft wird. Ein guter Ansible-Arbeitsablauf beantwortet immer vier Fragen: Welche Hosts sind betroffen, welche Änderung wird durchgeführt, welche Rechte werden dafür benötigt und wie wird der Erfolg gemessen?

Aspekt	Bedeutung im Workshop	Prüfpunkt
Scope	Inventory, Pattern, `--limit`, Tags und Umgebung bestimmen die Zielsysteme.	`ansible-inventory --graph`, `ansible-playbook --list-hosts`
Zustand	Module sollen Zielzustände modellieren und wiederholbare Ergebnisse liefern.	zweiter Lauf ohne unnötige Änderungen
Rechte	`become` wird tasknah und begründet eingesetzt.	kein globales Privileg ohne Review
Evidence	Ausgaben, Diffs und Zusammenfassung werden dokumentiert.	Play Recap, Diff, Evidence-Datei

Typische Kommandos:

ansible --version
ansible-config dump --only-changed
ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff

Für Reviews gilt: Ein Playbook ist erst dann gut genug, wenn es seine Zielgruppe beweist, seine Datenquellen offenlegt, sensible Werte schützt, Fehlerpfade beschreibt und nach einem zweiten Lauf stabil bleibt. Wenn ein Modul Check Mode oder Diff Mode nicht vollständig unterstützt, muss die Einschränkung im Runbook stehen.

Typische Fehler in diesem Bereich sind zu breite Patterns wie all, unklare Variablenquellen, Shell-Workarounds ohne Idempotenz, Secrets in Debug-Ausgaben, fehlende Rollback-Notiz und fehlende Trennung zwischen Lab- und Produktionsinventory.

2. Eignung

Vertiefung und Abgabebeispiel zu Eignung

Eine vollständige Bearbeitung von Eignung besteht aus einem technischen Artefakt und einer kurzen fachlichen Einordnung. Das Artefakt kann ein Inventory, ein Playbook, eine Rolle, ein Template, eine Vault-Datei mit Dummy-Werten, eine CI-Konfiguration oder eine Evidence-Datei sein. Die Einordnung erklärt, warum dieser Weg gewählt wurde und welche Alternative bewusst nicht verwendet wurde.

Abgabeteil	Inhalt	Mindestqualität
Zielbeschreibung	Was soll nach dem Lauf gelten?	messbar und ohne implizite Annahmen
Scope-Nachweis	Welche Hosts sind betroffen?	Ausgabe von `--list-hosts` oder Inventory-Graph
Umsetzung	Welche Dateien wurden geändert?	kleine, reviewbare YAML-Dateien
Validierung	Wie wurde geprüft?	Syntaxcheck, Check Mode, Diff, echter Lauf, zweiter Lauf
Risikoentscheidung	Was kann schiefgehen?	Rechte, Secrets, externe Abhängigkeiten und Rollback betrachtet

Minimalartefakte für Eignung

submission/
  inventory/hosts.yml
  playbooks/site.yml
  evidence.md
  cleanup.md

Für Rollen oder Collections wird die Struktur erweitert:

submission/
  ansible.cfg
  collections/requirements.yml
  inventory/hosts.yml
  roles/<role>/defaults/main.yml
  roles/<role>/tasks/main.yml
  roles/<role>/handlers/main.yml
  playbooks/site.yml
  evidence.md

Prüferwartung für Eignung

Eine prüfbare Lösung muss auch für Personen verständlich sein, die den Lauf nicht selbst ausgeführt haben. Deshalb reichen Screenshots oder unkommentierte Terminalausgaben nicht aus. Gute Evidence beschreibt Kontext, Kommando, relevante Ausgabe und Bewertung. Wenn ein Modul im Check Mode abweicht, wird diese Einschränkung ausdrücklich genannt.

Transfer in reale Teams

Im Teamkontext wird Eignung zusätzlich mit Code Review, Branch-Regeln, CI, Rollenownership, Release-Notizen und Betriebsfreigabe verbunden. Für produktionsnahe Nutzung werden außerdem Zuständigkeit, Wartungsfenster, Monitoring, Alarmierung und Rollback-Kriterien dokumentiert.

Praxisbezug zu Eignung

Dieser Abschnitt ist nicht als reine Begriffserklärung gedacht. Im Workshop wird Eignung immer an einem konkreten Ablauf überprüft: Inventory lesen, Zielhosts beweisen, Playbook prüfen, Änderung simulieren, Änderung ausführen, zweiten Lauf bewerten und Rückbau dokumentieren. Dadurch wird sichtbar, ob Ansible wirklich einen Zielzustand beschreibt oder nur zufällig einen Befehl erfolgreich ausgeführt hat.

Prüffrage	Erwartete Antwort
Welche Hosts sind betroffen?	Pattern, Gruppe, `--limit` und Inventory-Ausgabe sind dokumentiert.
Welche Datenquellen wirken?	`group_vars`, `host_vars`, Defaults, Extra Vars und Facts sind bekannt.
Welche Rechte werden benötigt?	`become` ist tasknah und fachlich begründet.
Wie wird Erfolg bewiesen?	Syntaxcheck, Check Mode, Diff, Play Recap und zweiter Lauf liegen vor.

Beispielablauf für Eignung

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

Der Ablauf ist bewusst vollständig. In echten Teams werden einzelne Schritte oft automatisiert, aber nicht übersprungen. CI kann Syntaxcheck und Linting übernehmen; die fachliche Bewertung von Scope, Rechten, Secret-Flows und Rollout-Risiko bleibt eine Review-Aufgabe.

Review-Kriterien für Eignung

Inventory und Pattern sind enger als all, sofern kein guter Grund dokumentiert ist.
Module aus ansible.builtin oder klar geprüften Collections werden bevorzugt.
Shell- oder Command-Tasks haben changed_when, failed_when oder eine Begründung.
Variablen sind nachvollziehbar platziert und überschreiben sich nicht überraschend.
Secrets erscheinen nicht in Klartext, Diff-Ausgaben, Debug-Tasks oder CI-Logs.
Das Playbook kann mehrfach laufen, ohne unnötige Änderungen zu melden.
Rückbau, Fix-forward oder kontrolliertes Belassen des Zielzustands ist dokumentiert.

Typische Fehler bei Eignung

Fehlerbild	Ursache	Diagnose
falsche Hosts getroffen	Pattern oder Inventory falsch verstanden	`--list-hosts`, `ansible-inventory --host`
`unreachable`	SSH, Benutzer, Python oder Netzwerkproblem	`-vvvv`, SSH-Test, Inventory-Variablen
unerwartete Änderung	Modul nicht idempotent oder falsche Datenquelle	zweiter Lauf, Diff, Variablenprüfung
Secret-Leak	Debug, Diff oder Log nicht begrenzt	`no_log`, Vault, CI-Artefakte prüfen
Handler läuft nicht	kein `changed` oder falscher Handlername	Task-Ergebnis und Handler-Name prüfen

Betriebsnotiz für Eignung

Für produktionsnahe Nutzung muss aus dem Lab ein Runbook entstehen. Dieses Runbook nennt Zielsysteme, Verantwortliche, Vorbedingungen, Stop-Kriterien, erwartete Dauer, Validierung, Monitoring und Rückbau. Ohne diese Angaben bleibt ein Playbook technisch ausführbar, aber nicht betriebsreif.

Eignung ist ein praktischer Baustein des Ansible-Workshops. Entscheidend ist, dass der gewünschte Zustand nicht nur beschrieben, sondern vor und nach der Ausführung überprüft wird. Ein guter Ansible-Arbeitsablauf beantwortet immer vier Fragen: Welche Hosts sind betroffen, welche Änderung wird durchgeführt, welche Rechte werden dafür benötigt und wie wird der Erfolg gemessen?

Aspekt	Bedeutung im Workshop	Prüfpunkt
Scope	Inventory, Pattern, `--limit`, Tags und Umgebung bestimmen die Zielsysteme.	`ansible-inventory --graph`, `ansible-playbook --list-hosts`
Zustand	Module sollen Zielzustände modellieren und wiederholbare Ergebnisse liefern.	zweiter Lauf ohne unnötige Änderungen
Rechte	`become` wird tasknah und begründet eingesetzt.	kein globales Privileg ohne Review
Evidence	Ausgaben, Diffs und Zusammenfassung werden dokumentiert.	Play Recap, Diff, Evidence-Datei

Typische Kommandos:

ansible --version
ansible-config dump --only-changed
ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff

Für Reviews gilt: Ein Playbook ist erst dann gut genug, wenn es seine Zielgruppe beweist, seine Datenquellen offenlegt, sensible Werte schützt, Fehlerpfade beschreibt und nach einem zweiten Lauf stabil bleibt. Wenn ein Modul Check Mode oder Diff Mode nicht vollständig unterstützt, muss die Einschränkung im Runbook stehen.

Typische Fehler in diesem Bereich sind zu breite Patterns wie all, unklare Variablenquellen, Shell-Workarounds ohne Idempotenz, Secrets in Debug-Ausgaben, fehlende Rollback-Notiz und fehlende Trennung zwischen Lab- und Produktionsinventory.

3. Ressourcen

Vertiefung und Abgabebeispiel zu Ressourcen

Eine vollständige Bearbeitung von Ressourcen besteht aus einem technischen Artefakt und einer kurzen fachlichen Einordnung. Das Artefakt kann ein Inventory, ein Playbook, eine Rolle, ein Template, eine Vault-Datei mit Dummy-Werten, eine CI-Konfiguration oder eine Evidence-Datei sein. Die Einordnung erklärt, warum dieser Weg gewählt wurde und welche Alternative bewusst nicht verwendet wurde.

Abgabeteil	Inhalt	Mindestqualität
Zielbeschreibung	Was soll nach dem Lauf gelten?	messbar und ohne implizite Annahmen
Scope-Nachweis	Welche Hosts sind betroffen?	Ausgabe von `--list-hosts` oder Inventory-Graph
Umsetzung	Welche Dateien wurden geändert?	kleine, reviewbare YAML-Dateien
Validierung	Wie wurde geprüft?	Syntaxcheck, Check Mode, Diff, echter Lauf, zweiter Lauf
Risikoentscheidung	Was kann schiefgehen?	Rechte, Secrets, externe Abhängigkeiten und Rollback betrachtet

Minimalartefakte für Ressourcen

submission/
  inventory/hosts.yml
  playbooks/site.yml
  evidence.md
  cleanup.md

Für Rollen oder Collections wird die Struktur erweitert:

submission/
  ansible.cfg
  collections/requirements.yml
  inventory/hosts.yml
  roles/<role>/defaults/main.yml
  roles/<role>/tasks/main.yml
  roles/<role>/handlers/main.yml
  playbooks/site.yml
  evidence.md

Prüferwartung für Ressourcen

Eine prüfbare Lösung muss auch für Personen verständlich sein, die den Lauf nicht selbst ausgeführt haben. Deshalb reichen Screenshots oder unkommentierte Terminalausgaben nicht aus. Gute Evidence beschreibt Kontext, Kommando, relevante Ausgabe und Bewertung. Wenn ein Modul im Check Mode abweicht, wird diese Einschränkung ausdrücklich genannt.

Transfer in reale Teams

Im Teamkontext wird Ressourcen zusätzlich mit Code Review, Branch-Regeln, CI, Rollenownership, Release-Notizen und Betriebsfreigabe verbunden. Für produktionsnahe Nutzung werden außerdem Zuständigkeit, Wartungsfenster, Monitoring, Alarmierung und Rollback-Kriterien dokumentiert.

Praxisbezug zu Ressourcen

Dieser Abschnitt ist nicht als reine Begriffserklärung gedacht. Im Workshop wird Ressourcen immer an einem konkreten Ablauf überprüft: Inventory lesen, Zielhosts beweisen, Playbook prüfen, Änderung simulieren, Änderung ausführen, zweiten Lauf bewerten und Rückbau dokumentieren. Dadurch wird sichtbar, ob Ansible wirklich einen Zielzustand beschreibt oder nur zufällig einen Befehl erfolgreich ausgeführt hat.

Prüffrage	Erwartete Antwort
Welche Hosts sind betroffen?	Pattern, Gruppe, `--limit` und Inventory-Ausgabe sind dokumentiert.
Welche Datenquellen wirken?	`group_vars`, `host_vars`, Defaults, Extra Vars und Facts sind bekannt.
Welche Rechte werden benötigt?	`become` ist tasknah und fachlich begründet.
Wie wird Erfolg bewiesen?	Syntaxcheck, Check Mode, Diff, Play Recap und zweiter Lauf liegen vor.

Beispielablauf für Ressourcen

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

Der Ablauf ist bewusst vollständig. In echten Teams werden einzelne Schritte oft automatisiert, aber nicht übersprungen. CI kann Syntaxcheck und Linting übernehmen; die fachliche Bewertung von Scope, Rechten, Secret-Flows und Rollout-Risiko bleibt eine Review-Aufgabe.

Review-Kriterien für Ressourcen

Inventory und Pattern sind enger als all, sofern kein guter Grund dokumentiert ist.
Module aus ansible.builtin oder klar geprüften Collections werden bevorzugt.
Shell- oder Command-Tasks haben changed_when, failed_when oder eine Begründung.
Variablen sind nachvollziehbar platziert und überschreiben sich nicht überraschend.
Secrets erscheinen nicht in Klartext, Diff-Ausgaben, Debug-Tasks oder CI-Logs.
Das Playbook kann mehrfach laufen, ohne unnötige Änderungen zu melden.
Rückbau, Fix-forward oder kontrolliertes Belassen des Zielzustands ist dokumentiert.

Typische Fehler bei Ressourcen

Fehlerbild	Ursache	Diagnose
falsche Hosts getroffen	Pattern oder Inventory falsch verstanden	`--list-hosts`, `ansible-inventory --host`
`unreachable`	SSH, Benutzer, Python oder Netzwerkproblem	`-vvvv`, SSH-Test, Inventory-Variablen
unerwartete Änderung	Modul nicht idempotent oder falsche Datenquelle	zweiter Lauf, Diff, Variablenprüfung
Secret-Leak	Debug, Diff oder Log nicht begrenzt	`no_log`, Vault, CI-Artefakte prüfen
Handler läuft nicht	kein `changed` oder falscher Handlername	Task-Ergebnis und Handler-Name prüfen

Betriebsnotiz für Ressourcen

Für produktionsnahe Nutzung muss aus dem Lab ein Runbook entstehen. Dieses Runbook nennt Zielsysteme, Verantwortliche, Vorbedingungen, Stop-Kriterien, erwartete Dauer, Validierung, Monitoring und Rückbau. Ohne diese Angaben bleibt ein Playbook technisch ausführbar, aber nicht betriebsreif.

Ressourcen ist ein praktischer Baustein des Ansible-Workshops. Entscheidend ist, dass der gewünschte Zustand nicht nur beschrieben, sondern vor und nach der Ausführung überprüft wird. Ein guter Ansible-Arbeitsablauf beantwortet immer vier Fragen: Welche Hosts sind betroffen, welche Änderung wird durchgeführt, welche Rechte werden dafür benötigt und wie wird der Erfolg gemessen?

Aspekt	Bedeutung im Workshop	Prüfpunkt
Scope	Inventory, Pattern, `--limit`, Tags und Umgebung bestimmen die Zielsysteme.	`ansible-inventory --graph`, `ansible-playbook --list-hosts`
Zustand	Module sollen Zielzustände modellieren und wiederholbare Ergebnisse liefern.	zweiter Lauf ohne unnötige Änderungen
Rechte	`become` wird tasknah und begründet eingesetzt.	kein globales Privileg ohne Review
Evidence	Ausgaben, Diffs und Zusammenfassung werden dokumentiert.	Play Recap, Diff, Evidence-Datei

Typische Kommandos:

ansible --version
ansible-config dump --only-changed
ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff

Für Reviews gilt: Ein Playbook ist erst dann gut genug, wenn es seine Zielgruppe beweist, seine Datenquellen offenlegt, sensible Werte schützt, Fehlerpfade beschreibt und nach einem zweiten Lauf stabil bleibt. Wenn ein Modul Check Mode oder Diff Mode nicht vollständig unterstützt, muss die Einschränkung im Runbook stehen.

Typische Fehler in diesem Bereich sind zu breite Patterns wie all, unklare Variablenquellen, Shell-Workarounds ohne Idempotenz, Secrets in Debug-Ausgaben, fehlende Rollback-Notiz und fehlende Trennung zwischen Lab- und Produktionsinventory.

4. Netzwerk

Vertiefung und Abgabebeispiel zu Netzwerk

Eine vollständige Bearbeitung von Netzwerk besteht aus einem technischen Artefakt und einer kurzen fachlichen Einordnung. Das Artefakt kann ein Inventory, ein Playbook, eine Rolle, ein Template, eine Vault-Datei mit Dummy-Werten, eine CI-Konfiguration oder eine Evidence-Datei sein. Die Einordnung erklärt, warum dieser Weg gewählt wurde und welche Alternative bewusst nicht verwendet wurde.

Abgabeteil	Inhalt	Mindestqualität
Zielbeschreibung	Was soll nach dem Lauf gelten?	messbar und ohne implizite Annahmen
Scope-Nachweis	Welche Hosts sind betroffen?	Ausgabe von `--list-hosts` oder Inventory-Graph
Umsetzung	Welche Dateien wurden geändert?	kleine, reviewbare YAML-Dateien
Validierung	Wie wurde geprüft?	Syntaxcheck, Check Mode, Diff, echter Lauf, zweiter Lauf
Risikoentscheidung	Was kann schiefgehen?	Rechte, Secrets, externe Abhängigkeiten und Rollback betrachtet

Minimalartefakte für Netzwerk

submission/
  inventory/hosts.yml
  playbooks/site.yml
  evidence.md
  cleanup.md

Für Rollen oder Collections wird die Struktur erweitert:

submission/
  ansible.cfg
  collections/requirements.yml
  inventory/hosts.yml
  roles/<role>/defaults/main.yml
  roles/<role>/tasks/main.yml
  roles/<role>/handlers/main.yml
  playbooks/site.yml
  evidence.md

Prüferwartung für Netzwerk

Eine prüfbare Lösung muss auch für Personen verständlich sein, die den Lauf nicht selbst ausgeführt haben. Deshalb reichen Screenshots oder unkommentierte Terminalausgaben nicht aus. Gute Evidence beschreibt Kontext, Kommando, relevante Ausgabe und Bewertung. Wenn ein Modul im Check Mode abweicht, wird diese Einschränkung ausdrücklich genannt.

Transfer in reale Teams

Im Teamkontext wird Netzwerk zusätzlich mit Code Review, Branch-Regeln, CI, Rollenownership, Release-Notizen und Betriebsfreigabe verbunden. Für produktionsnahe Nutzung werden außerdem Zuständigkeit, Wartungsfenster, Monitoring, Alarmierung und Rollback-Kriterien dokumentiert.

Praxisbezug zu Netzwerk

Dieser Abschnitt ist nicht als reine Begriffserklärung gedacht. Im Workshop wird Netzwerk immer an einem konkreten Ablauf überprüft: Inventory lesen, Zielhosts beweisen, Playbook prüfen, Änderung simulieren, Änderung ausführen, zweiten Lauf bewerten und Rückbau dokumentieren. Dadurch wird sichtbar, ob Ansible wirklich einen Zielzustand beschreibt oder nur zufällig einen Befehl erfolgreich ausgeführt hat.

Prüffrage	Erwartete Antwort
Welche Hosts sind betroffen?	Pattern, Gruppe, `--limit` und Inventory-Ausgabe sind dokumentiert.
Welche Datenquellen wirken?	`group_vars`, `host_vars`, Defaults, Extra Vars und Facts sind bekannt.
Welche Rechte werden benötigt?	`become` ist tasknah und fachlich begründet.
Wie wird Erfolg bewiesen?	Syntaxcheck, Check Mode, Diff, Play Recap und zweiter Lauf liegen vor.

Beispielablauf für Netzwerk

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

Der Ablauf ist bewusst vollständig. In echten Teams werden einzelne Schritte oft automatisiert, aber nicht übersprungen. CI kann Syntaxcheck und Linting übernehmen; die fachliche Bewertung von Scope, Rechten, Secret-Flows und Rollout-Risiko bleibt eine Review-Aufgabe.

Review-Kriterien für Netzwerk

Inventory und Pattern sind enger als all, sofern kein guter Grund dokumentiert ist.
Module aus ansible.builtin oder klar geprüften Collections werden bevorzugt.
Shell- oder Command-Tasks haben changed_when, failed_when oder eine Begründung.
Variablen sind nachvollziehbar platziert und überschreiben sich nicht überraschend.
Secrets erscheinen nicht in Klartext, Diff-Ausgaben, Debug-Tasks oder CI-Logs.
Das Playbook kann mehrfach laufen, ohne unnötige Änderungen zu melden.
Rückbau, Fix-forward oder kontrolliertes Belassen des Zielzustands ist dokumentiert.

Typische Fehler bei Netzwerk

Fehlerbild	Ursache	Diagnose
falsche Hosts getroffen	Pattern oder Inventory falsch verstanden	`--list-hosts`, `ansible-inventory --host`
`unreachable`	SSH, Benutzer, Python oder Netzwerkproblem	`-vvvv`, SSH-Test, Inventory-Variablen
unerwartete Änderung	Modul nicht idempotent oder falsche Datenquelle	zweiter Lauf, Diff, Variablenprüfung
Secret-Leak	Debug, Diff oder Log nicht begrenzt	`no_log`, Vault, CI-Artefakte prüfen
Handler läuft nicht	kein `changed` oder falscher Handlername	Task-Ergebnis und Handler-Name prüfen

Betriebsnotiz für Netzwerk

Für produktionsnahe Nutzung muss aus dem Lab ein Runbook entstehen. Dieses Runbook nennt Zielsysteme, Verantwortliche, Vorbedingungen, Stop-Kriterien, erwartete Dauer, Validierung, Monitoring und Rückbau. Ohne diese Angaben bleibt ein Playbook technisch ausführbar, aber nicht betriebsreif.

Netzwerk ist ein praktischer Baustein des Ansible-Workshops. Entscheidend ist, dass der gewünschte Zustand nicht nur beschrieben, sondern vor und nach der Ausführung überprüft wird. Ein guter Ansible-Arbeitsablauf beantwortet immer vier Fragen: Welche Hosts sind betroffen, welche Änderung wird durchgeführt, welche Rechte werden dafür benötigt und wie wird der Erfolg gemessen?

Aspekt	Bedeutung im Workshop	Prüfpunkt
Scope	Inventory, Pattern, `--limit`, Tags und Umgebung bestimmen die Zielsysteme.	`ansible-inventory --graph`, `ansible-playbook --list-hosts`
Zustand	Module sollen Zielzustände modellieren und wiederholbare Ergebnisse liefern.	zweiter Lauf ohne unnötige Änderungen
Rechte	`become` wird tasknah und begründet eingesetzt.	kein globales Privileg ohne Review
Evidence	Ausgaben, Diffs und Zusammenfassung werden dokumentiert.	Play Recap, Diff, Evidence-Datei

Typische Kommandos:

ansible --version
ansible-config dump --only-changed
ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff

Für Reviews gilt: Ein Playbook ist erst dann gut genug, wenn es seine Zielgruppe beweist, seine Datenquellen offenlegt, sensible Werte schützt, Fehlerpfade beschreibt und nach einem zweiten Lauf stabil bleibt. Wenn ein Modul Check Mode oder Diff Mode nicht vollständig unterstützt, muss die Einschränkung im Runbook stehen.

Typische Fehler in diesem Bereich sind zu breite Patterns wie all, unklare Variablenquellen, Shell-Workarounds ohne Idempotenz, Secrets in Debug-Ausgaben, fehlende Rollback-Notiz und fehlende Trennung zwischen Lab- und Produktionsinventory.

5. Installation

Vertiefung und Abgabebeispiel zu Installation

Eine vollständige Bearbeitung von Installation besteht aus einem technischen Artefakt und einer kurzen fachlichen Einordnung. Das Artefakt kann ein Inventory, ein Playbook, eine Rolle, ein Template, eine Vault-Datei mit Dummy-Werten, eine CI-Konfiguration oder eine Evidence-Datei sein. Die Einordnung erklärt, warum dieser Weg gewählt wurde und welche Alternative bewusst nicht verwendet wurde.

Abgabeteil	Inhalt	Mindestqualität
Zielbeschreibung	Was soll nach dem Lauf gelten?	messbar und ohne implizite Annahmen
Scope-Nachweis	Welche Hosts sind betroffen?	Ausgabe von `--list-hosts` oder Inventory-Graph
Umsetzung	Welche Dateien wurden geändert?	kleine, reviewbare YAML-Dateien
Validierung	Wie wurde geprüft?	Syntaxcheck, Check Mode, Diff, echter Lauf, zweiter Lauf
Risikoentscheidung	Was kann schiefgehen?	Rechte, Secrets, externe Abhängigkeiten und Rollback betrachtet

Minimalartefakte für Installation

submission/
  inventory/hosts.yml
  playbooks/site.yml
  evidence.md
  cleanup.md

Für Rollen oder Collections wird die Struktur erweitert:

submission/
  ansible.cfg
  collections/requirements.yml
  inventory/hosts.yml
  roles/<role>/defaults/main.yml
  roles/<role>/tasks/main.yml
  roles/<role>/handlers/main.yml
  playbooks/site.yml
  evidence.md

Prüferwartung für Installation

Eine prüfbare Lösung muss auch für Personen verständlich sein, die den Lauf nicht selbst ausgeführt haben. Deshalb reichen Screenshots oder unkommentierte Terminalausgaben nicht aus. Gute Evidence beschreibt Kontext, Kommando, relevante Ausgabe und Bewertung. Wenn ein Modul im Check Mode abweicht, wird diese Einschränkung ausdrücklich genannt.

Transfer in reale Teams

Im Teamkontext wird Installation zusätzlich mit Code Review, Branch-Regeln, CI, Rollenownership, Release-Notizen und Betriebsfreigabe verbunden. Für produktionsnahe Nutzung werden außerdem Zuständigkeit, Wartungsfenster, Monitoring, Alarmierung und Rollback-Kriterien dokumentiert.

Praxisbezug zu Installation

Dieser Abschnitt ist nicht als reine Begriffserklärung gedacht. Im Workshop wird Installation immer an einem konkreten Ablauf überprüft: Inventory lesen, Zielhosts beweisen, Playbook prüfen, Änderung simulieren, Änderung ausführen, zweiten Lauf bewerten und Rückbau dokumentieren. Dadurch wird sichtbar, ob Ansible wirklich einen Zielzustand beschreibt oder nur zufällig einen Befehl erfolgreich ausgeführt hat.

Prüffrage	Erwartete Antwort
Welche Hosts sind betroffen?	Pattern, Gruppe, `--limit` und Inventory-Ausgabe sind dokumentiert.
Welche Datenquellen wirken?	`group_vars`, `host_vars`, Defaults, Extra Vars und Facts sind bekannt.
Welche Rechte werden benötigt?	`become` ist tasknah und fachlich begründet.
Wie wird Erfolg bewiesen?	Syntaxcheck, Check Mode, Diff, Play Recap und zweiter Lauf liegen vor.

Beispielablauf für Installation

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

Der Ablauf ist bewusst vollständig. In echten Teams werden einzelne Schritte oft automatisiert, aber nicht übersprungen. CI kann Syntaxcheck und Linting übernehmen; die fachliche Bewertung von Scope, Rechten, Secret-Flows und Rollout-Risiko bleibt eine Review-Aufgabe.

Review-Kriterien für Installation

Inventory und Pattern sind enger als all, sofern kein guter Grund dokumentiert ist.
Module aus ansible.builtin oder klar geprüften Collections werden bevorzugt.
Shell- oder Command-Tasks haben changed_when, failed_when oder eine Begründung.
Variablen sind nachvollziehbar platziert und überschreiben sich nicht überraschend.
Secrets erscheinen nicht in Klartext, Diff-Ausgaben, Debug-Tasks oder CI-Logs.
Das Playbook kann mehrfach laufen, ohne unnötige Änderungen zu melden.
Rückbau, Fix-forward oder kontrolliertes Belassen des Zielzustands ist dokumentiert.

Typische Fehler bei Installation

Fehlerbild	Ursache	Diagnose
falsche Hosts getroffen	Pattern oder Inventory falsch verstanden	`--list-hosts`, `ansible-inventory --host`
`unreachable`	SSH, Benutzer, Python oder Netzwerkproblem	`-vvvv`, SSH-Test, Inventory-Variablen
unerwartete Änderung	Modul nicht idempotent oder falsche Datenquelle	zweiter Lauf, Diff, Variablenprüfung
Secret-Leak	Debug, Diff oder Log nicht begrenzt	`no_log`, Vault, CI-Artefakte prüfen
Handler läuft nicht	kein `changed` oder falscher Handlername	Task-Ergebnis und Handler-Name prüfen

Betriebsnotiz für Installation

Für produktionsnahe Nutzung muss aus dem Lab ein Runbook entstehen. Dieses Runbook nennt Zielsysteme, Verantwortliche, Vorbedingungen, Stop-Kriterien, erwartete Dauer, Validierung, Monitoring und Rückbau. Ohne diese Angaben bleibt ein Playbook technisch ausführbar, aber nicht betriebsreif.

Installation ist ein praktischer Baustein des Ansible-Workshops. Entscheidend ist, dass der gewünschte Zustand nicht nur beschrieben, sondern vor und nach der Ausführung überprüft wird. Ein guter Ansible-Arbeitsablauf beantwortet immer vier Fragen: Welche Hosts sind betroffen, welche Änderung wird durchgeführt, welche Rechte werden dafür benötigt und wie wird der Erfolg gemessen?

Aspekt	Bedeutung im Workshop	Prüfpunkt
Scope	Inventory, Pattern, `--limit`, Tags und Umgebung bestimmen die Zielsysteme.	`ansible-inventory --graph`, `ansible-playbook --list-hosts`
Zustand	Module sollen Zielzustände modellieren und wiederholbare Ergebnisse liefern.	zweiter Lauf ohne unnötige Änderungen
Rechte	`become` wird tasknah und begründet eingesetzt.	kein globales Privileg ohne Review
Evidence	Ausgaben, Diffs und Zusammenfassung werden dokumentiert.	Play Recap, Diff, Evidence-Datei

Typische Kommandos:

ansible --version
ansible-config dump --only-changed
ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff

Für Reviews gilt: Ein Playbook ist erst dann gut genug, wenn es seine Zielgruppe beweist, seine Datenquellen offenlegt, sensible Werte schützt, Fehlerpfade beschreibt und nach einem zweiten Lauf stabil bleibt. Wenn ein Modul Check Mode oder Diff Mode nicht vollständig unterstützt, muss die Einschränkung im Runbook stehen.

Typische Fehler in diesem Bereich sind zu breite Patterns wie all, unklare Variablenquellen, Shell-Workarounds ohne Idempotenz, Secrets in Debug-Ausgaben, fehlende Rollback-Notiz und fehlende Trennung zwischen Lab- und Produktionsinventory.

6. SSH-Zugriff

Vertiefung und Abgabebeispiel zu SSH-Zugriff

Eine vollständige Bearbeitung von SSH-Zugriff besteht aus einem technischen Artefakt und einer kurzen fachlichen Einordnung. Das Artefakt kann ein Inventory, ein Playbook, eine Rolle, ein Template, eine Vault-Datei mit Dummy-Werten, eine CI-Konfiguration oder eine Evidence-Datei sein. Die Einordnung erklärt, warum dieser Weg gewählt wurde und welche Alternative bewusst nicht verwendet wurde.

Abgabeteil	Inhalt	Mindestqualität
Zielbeschreibung	Was soll nach dem Lauf gelten?	messbar und ohne implizite Annahmen
Scope-Nachweis	Welche Hosts sind betroffen?	Ausgabe von `--list-hosts` oder Inventory-Graph
Umsetzung	Welche Dateien wurden geändert?	kleine, reviewbare YAML-Dateien
Validierung	Wie wurde geprüft?	Syntaxcheck, Check Mode, Diff, echter Lauf, zweiter Lauf
Risikoentscheidung	Was kann schiefgehen?	Rechte, Secrets, externe Abhängigkeiten und Rollback betrachtet

Minimalartefakte für SSH-Zugriff

submission/
  inventory/hosts.yml
  playbooks/site.yml
  evidence.md
  cleanup.md

Für Rollen oder Collections wird die Struktur erweitert:

submission/
  ansible.cfg
  collections/requirements.yml
  inventory/hosts.yml
  roles/<role>/defaults/main.yml
  roles/<role>/tasks/main.yml
  roles/<role>/handlers/main.yml
  playbooks/site.yml
  evidence.md

Prüferwartung für SSH-Zugriff

Eine prüfbare Lösung muss auch für Personen verständlich sein, die den Lauf nicht selbst ausgeführt haben. Deshalb reichen Screenshots oder unkommentierte Terminalausgaben nicht aus. Gute Evidence beschreibt Kontext, Kommando, relevante Ausgabe und Bewertung. Wenn ein Modul im Check Mode abweicht, wird diese Einschränkung ausdrücklich genannt.

Transfer in reale Teams

Im Teamkontext wird SSH-Zugriff zusätzlich mit Code Review, Branch-Regeln, CI, Rollenownership, Release-Notizen und Betriebsfreigabe verbunden. Für produktionsnahe Nutzung werden außerdem Zuständigkeit, Wartungsfenster, Monitoring, Alarmierung und Rollback-Kriterien dokumentiert.

Praxisbezug zu SSH-Zugriff

Dieser Abschnitt ist nicht als reine Begriffserklärung gedacht. Im Workshop wird SSH-Zugriff immer an einem konkreten Ablauf überprüft: Inventory lesen, Zielhosts beweisen, Playbook prüfen, Änderung simulieren, Änderung ausführen, zweiten Lauf bewerten und Rückbau dokumentieren. Dadurch wird sichtbar, ob Ansible wirklich einen Zielzustand beschreibt oder nur zufällig einen Befehl erfolgreich ausgeführt hat.

Prüffrage	Erwartete Antwort
Welche Hosts sind betroffen?	Pattern, Gruppe, `--limit` und Inventory-Ausgabe sind dokumentiert.
Welche Datenquellen wirken?	`group_vars`, `host_vars`, Defaults, Extra Vars und Facts sind bekannt.
Welche Rechte werden benötigt?	`become` ist tasknah und fachlich begründet.
Wie wird Erfolg bewiesen?	Syntaxcheck, Check Mode, Diff, Play Recap und zweiter Lauf liegen vor.

Beispielablauf für SSH-Zugriff

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

Der Ablauf ist bewusst vollständig. In echten Teams werden einzelne Schritte oft automatisiert, aber nicht übersprungen. CI kann Syntaxcheck und Linting übernehmen; die fachliche Bewertung von Scope, Rechten, Secret-Flows und Rollout-Risiko bleibt eine Review-Aufgabe.

Review-Kriterien für SSH-Zugriff

Inventory und Pattern sind enger als all, sofern kein guter Grund dokumentiert ist.
Module aus ansible.builtin oder klar geprüften Collections werden bevorzugt.
Shell- oder Command-Tasks haben changed_when, failed_when oder eine Begründung.
Variablen sind nachvollziehbar platziert und überschreiben sich nicht überraschend.
Secrets erscheinen nicht in Klartext, Diff-Ausgaben, Debug-Tasks oder CI-Logs.
Das Playbook kann mehrfach laufen, ohne unnötige Änderungen zu melden.
Rückbau, Fix-forward oder kontrolliertes Belassen des Zielzustands ist dokumentiert.

Typische Fehler bei SSH-Zugriff

Fehlerbild	Ursache	Diagnose
falsche Hosts getroffen	Pattern oder Inventory falsch verstanden	`--list-hosts`, `ansible-inventory --host`
`unreachable`	SSH, Benutzer, Python oder Netzwerkproblem	`-vvvv`, SSH-Test, Inventory-Variablen
unerwartete Änderung	Modul nicht idempotent oder falsche Datenquelle	zweiter Lauf, Diff, Variablenprüfung
Secret-Leak	Debug, Diff oder Log nicht begrenzt	`no_log`, Vault, CI-Artefakte prüfen
Handler läuft nicht	kein `changed` oder falscher Handlername	Task-Ergebnis und Handler-Name prüfen

Betriebsnotiz für SSH-Zugriff

Für produktionsnahe Nutzung muss aus dem Lab ein Runbook entstehen. Dieses Runbook nennt Zielsysteme, Verantwortliche, Vorbedingungen, Stop-Kriterien, erwartete Dauer, Validierung, Monitoring und Rückbau. Ohne diese Angaben bleibt ein Playbook technisch ausführbar, aber nicht betriebsreif.

SSH-Zugriff ist ein praktischer Baustein des Ansible-Workshops. Entscheidend ist, dass der gewünschte Zustand nicht nur beschrieben, sondern vor und nach der Ausführung überprüft wird. Ein guter Ansible-Arbeitsablauf beantwortet immer vier Fragen: Welche Hosts sind betroffen, welche Änderung wird durchgeführt, welche Rechte werden dafür benötigt und wie wird der Erfolg gemessen?

Aspekt	Bedeutung im Workshop	Prüfpunkt
Scope	Inventory, Pattern, `--limit`, Tags und Umgebung bestimmen die Zielsysteme.	`ansible-inventory --graph`, `ansible-playbook --list-hosts`
Zustand	Module sollen Zielzustände modellieren und wiederholbare Ergebnisse liefern.	zweiter Lauf ohne unnötige Änderungen
Rechte	`become` wird tasknah und begründet eingesetzt.	kein globales Privileg ohne Review
Evidence	Ausgaben, Diffs und Zusammenfassung werden dokumentiert.	Play Recap, Diff, Evidence-Datei

Typische Kommandos:

ansible --version
ansible-config dump --only-changed
ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff

Für Reviews gilt: Ein Playbook ist erst dann gut genug, wenn es seine Zielgruppe beweist, seine Datenquellen offenlegt, sensible Werte schützt, Fehlerpfade beschreibt und nach einem zweiten Lauf stabil bleibt. Wenn ein Modul Check Mode oder Diff Mode nicht vollständig unterstützt, muss die Einschränkung im Runbook stehen.

Typische Fehler in diesem Bereich sind zu breite Patterns wie all, unklare Variablenquellen, Shell-Workarounds ohne Idempotenz, Secrets in Debug-Ausgaben, fehlende Rollback-Notiz und fehlende Trennung zwischen Lab- und Produktionsinventory.

7. Snapshots

Vertiefung und Abgabebeispiel zu Snapshots

Eine vollständige Bearbeitung von Snapshots besteht aus einem technischen Artefakt und einer kurzen fachlichen Einordnung. Das Artefakt kann ein Inventory, ein Playbook, eine Rolle, ein Template, eine Vault-Datei mit Dummy-Werten, eine CI-Konfiguration oder eine Evidence-Datei sein. Die Einordnung erklärt, warum dieser Weg gewählt wurde und welche Alternative bewusst nicht verwendet wurde.

Abgabeteil	Inhalt	Mindestqualität
Zielbeschreibung	Was soll nach dem Lauf gelten?	messbar und ohne implizite Annahmen
Scope-Nachweis	Welche Hosts sind betroffen?	Ausgabe von `--list-hosts` oder Inventory-Graph
Umsetzung	Welche Dateien wurden geändert?	kleine, reviewbare YAML-Dateien
Validierung	Wie wurde geprüft?	Syntaxcheck, Check Mode, Diff, echter Lauf, zweiter Lauf
Risikoentscheidung	Was kann schiefgehen?	Rechte, Secrets, externe Abhängigkeiten und Rollback betrachtet

Minimalartefakte für Snapshots

submission/
  inventory/hosts.yml
  playbooks/site.yml
  evidence.md
  cleanup.md

Für Rollen oder Collections wird die Struktur erweitert:

submission/
  ansible.cfg
  collections/requirements.yml
  inventory/hosts.yml
  roles/<role>/defaults/main.yml
  roles/<role>/tasks/main.yml
  roles/<role>/handlers/main.yml
  playbooks/site.yml
  evidence.md

Prüferwartung für Snapshots

Eine prüfbare Lösung muss auch für Personen verständlich sein, die den Lauf nicht selbst ausgeführt haben. Deshalb reichen Screenshots oder unkommentierte Terminalausgaben nicht aus. Gute Evidence beschreibt Kontext, Kommando, relevante Ausgabe und Bewertung. Wenn ein Modul im Check Mode abweicht, wird diese Einschränkung ausdrücklich genannt.

Transfer in reale Teams

Im Teamkontext wird Snapshots zusätzlich mit Code Review, Branch-Regeln, CI, Rollenownership, Release-Notizen und Betriebsfreigabe verbunden. Für produktionsnahe Nutzung werden außerdem Zuständigkeit, Wartungsfenster, Monitoring, Alarmierung und Rollback-Kriterien dokumentiert.

Praxisbezug zu Snapshots

Dieser Abschnitt ist nicht als reine Begriffserklärung gedacht. Im Workshop wird Snapshots immer an einem konkreten Ablauf überprüft: Inventory lesen, Zielhosts beweisen, Playbook prüfen, Änderung simulieren, Änderung ausführen, zweiten Lauf bewerten und Rückbau dokumentieren. Dadurch wird sichtbar, ob Ansible wirklich einen Zielzustand beschreibt oder nur zufällig einen Befehl erfolgreich ausgeführt hat.

Prüffrage	Erwartete Antwort
Welche Hosts sind betroffen?	Pattern, Gruppe, `--limit` und Inventory-Ausgabe sind dokumentiert.
Welche Datenquellen wirken?	`group_vars`, `host_vars`, Defaults, Extra Vars und Facts sind bekannt.
Welche Rechte werden benötigt?	`become` ist tasknah und fachlich begründet.
Wie wird Erfolg bewiesen?	Syntaxcheck, Check Mode, Diff, Play Recap und zweiter Lauf liegen vor.

Beispielablauf für Snapshots

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

Der Ablauf ist bewusst vollständig. In echten Teams werden einzelne Schritte oft automatisiert, aber nicht übersprungen. CI kann Syntaxcheck und Linting übernehmen; die fachliche Bewertung von Scope, Rechten, Secret-Flows und Rollout-Risiko bleibt eine Review-Aufgabe.

Review-Kriterien für Snapshots

Inventory und Pattern sind enger als all, sofern kein guter Grund dokumentiert ist.
Module aus ansible.builtin oder klar geprüften Collections werden bevorzugt.
Shell- oder Command-Tasks haben changed_when, failed_when oder eine Begründung.
Variablen sind nachvollziehbar platziert und überschreiben sich nicht überraschend.
Secrets erscheinen nicht in Klartext, Diff-Ausgaben, Debug-Tasks oder CI-Logs.
Das Playbook kann mehrfach laufen, ohne unnötige Änderungen zu melden.
Rückbau, Fix-forward oder kontrolliertes Belassen des Zielzustands ist dokumentiert.

Typische Fehler bei Snapshots

Fehlerbild	Ursache	Diagnose
falsche Hosts getroffen	Pattern oder Inventory falsch verstanden	`--list-hosts`, `ansible-inventory --host`
`unreachable`	SSH, Benutzer, Python oder Netzwerkproblem	`-vvvv`, SSH-Test, Inventory-Variablen
unerwartete Änderung	Modul nicht idempotent oder falsche Datenquelle	zweiter Lauf, Diff, Variablenprüfung
Secret-Leak	Debug, Diff oder Log nicht begrenzt	`no_log`, Vault, CI-Artefakte prüfen
Handler läuft nicht	kein `changed` oder falscher Handlername	Task-Ergebnis und Handler-Name prüfen

Betriebsnotiz für Snapshots

Für produktionsnahe Nutzung muss aus dem Lab ein Runbook entstehen. Dieses Runbook nennt Zielsysteme, Verantwortliche, Vorbedingungen, Stop-Kriterien, erwartete Dauer, Validierung, Monitoring und Rückbau. Ohne diese Angaben bleibt ein Playbook technisch ausführbar, aber nicht betriebsreif.

Snapshots ist ein praktischer Baustein des Ansible-Workshops. Entscheidend ist, dass der gewünschte Zustand nicht nur beschrieben, sondern vor und nach der Ausführung überprüft wird. Ein guter Ansible-Arbeitsablauf beantwortet immer vier Fragen: Welche Hosts sind betroffen, welche Änderung wird durchgeführt, welche Rechte werden dafür benötigt und wie wird der Erfolg gemessen?

Aspekt	Bedeutung im Workshop	Prüfpunkt
Scope	Inventory, Pattern, `--limit`, Tags und Umgebung bestimmen die Zielsysteme.	`ansible-inventory --graph`, `ansible-playbook --list-hosts`
Zustand	Module sollen Zielzustände modellieren und wiederholbare Ergebnisse liefern.	zweiter Lauf ohne unnötige Änderungen
Rechte	`become` wird tasknah und begründet eingesetzt.	kein globales Privileg ohne Review
Evidence	Ausgaben, Diffs und Zusammenfassung werden dokumentiert.	Play Recap, Diff, Evidence-Datei

Typische Kommandos:

ansible --version
ansible-config dump --only-changed
ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff

Für Reviews gilt: Ein Playbook ist erst dann gut genug, wenn es seine Zielgruppe beweist, seine Datenquellen offenlegt, sensible Werte schützt, Fehlerpfade beschreibt und nach einem zweiten Lauf stabil bleibt. Wenn ein Modul Check Mode oder Diff Mode nicht vollständig unterstützt, muss die Einschränkung im Runbook stehen.

Typische Fehler in diesem Bereich sind zu breite Patterns wie all, unklare Variablenquellen, Shell-Workarounds ohne Idempotenz, Secrets in Debug-Ausgaben, fehlende Rollback-Notiz und fehlende Trennung zwischen Lab- und Produktionsinventory.

8. Workshop-Artefakte prüfen

Vertiefung und Abgabebeispiel zur Prüfung der Workshop-Artefakte

Eine vollständige Bearbeitung dieses Schritts besteht aus einem technischen Artefakt und einer kurzen fachlichen Einordnung. Das Artefakt kann ein Inventory, ein Playbook, eine Rolle, ein Template, eine Vault-Datei mit Dummy-Werten, eine CI-Konfiguration oder eine Evidence-Datei sein. Die Einordnung erklärt, warum dieser Weg gewählt wurde und welche Alternative bewusst nicht verwendet wurde.

Abgabeteil	Inhalt	Mindestqualität
Zielbeschreibung	Was soll nach dem Lauf gelten?	messbar und ohne implizite Annahmen
Scope-Nachweis	Welche Hosts sind betroffen?	Ausgabe von `--list-hosts` oder Inventory-Graph
Umsetzung	Welche Dateien wurden geändert?	kleine, reviewbare YAML-Dateien
Validierung	Wie wurde geprüft?	Syntaxcheck, Check Mode, Diff, echter Lauf, zweiter Lauf
Risikoentscheidung	Was kann schiefgehen?	Rechte, Secrets, externe Abhängigkeiten und Rollback betrachtet

Minimalartefakte für die Prüfung der Workshop-Artefakte

submission/
  inventory/hosts.yml
  playbooks/site.yml
  evidence.md
  cleanup.md

Für Rollen oder Collections wird die Struktur erweitert:

submission/
  ansible.cfg
  collections/requirements.yml
  inventory/hosts.yml
  roles/<role>/defaults/main.yml
  roles/<role>/tasks/main.yml
  roles/<role>/handlers/main.yml
  playbooks/site.yml
  evidence.md

Prüferwartung für die Workshop-Artefakte

Eine prüfbare Lösung muss auch für Personen verständlich sein, die den Lauf nicht selbst ausgeführt haben. Deshalb reichen Screenshots oder unkommentierte Terminalausgaben nicht aus. Gute Evidence beschreibt Kontext, Kommando, relevante Ausgabe und Bewertung. Wenn ein Modul im Check Mode abweicht, wird diese Einschränkung ausdrücklich genannt.

Transfer in reale Teams

Im Teamkontext wird die Arbeit mit Workshop-Artefakten zusätzlich mit Code Review, Branch-Regeln, CI, Rollenownership, Release-Notizen und Betriebsfreigabe verbunden. Für produktionsnahe Nutzung werden außerdem Zuständigkeit, Wartungsfenster, Monitoring, Alarmierung und Rollback-Kriterien dokumentiert.

Praxisbezug zur Prüfung der Workshop-Artefakte

Dieser Abschnitt ist nicht als reine Begriffserklärung gedacht. Im Workshop wird die Prüfung der Workshop-Artefakte immer an einem konkreten Ablauf überprüft: Inventory lesen, Zielhosts beweisen, Playbook prüfen, Änderung simulieren, Änderung ausführen, zweiten Lauf bewerten und Rückbau dokumentieren. Dadurch wird sichtbar, ob Ansible wirklich einen Zielzustand beschreibt oder nur zufällig einen Befehl erfolgreich ausgeführt hat.

Prüffrage	Erwartete Antwort
Welche Hosts sind betroffen?	Pattern, Gruppe, `--limit` und Inventory-Ausgabe sind dokumentiert.
Welche Datenquellen wirken?	`group_vars`, `host_vars`, Defaults, Extra Vars und Facts sind bekannt.
Welche Rechte werden benötigt?	`become` ist tasknah und fachlich begründet.
Wie wird Erfolg bewiesen?	Syntaxcheck, Check Mode, Diff, Play Recap und zweiter Lauf liegen vor.

Beispielablauf zur Prüfung der Workshop-Artefakte

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

Der Ablauf ist bewusst vollständig. In echten Teams werden einzelne Schritte oft automatisiert, aber nicht übersprungen. CI kann Syntaxcheck und Linting übernehmen; die fachliche Bewertung von Scope, Rechten, Secret-Flows und Rollout-Risiko bleibt eine Review-Aufgabe.

Review-Kriterien für Workshop-Artefakte

Inventory und Pattern sind enger als all, sofern kein guter Grund dokumentiert ist.
Module aus ansible.builtin oder klar geprüften Collections werden bevorzugt.
Shell- oder Command-Tasks haben changed_when, failed_when oder eine Begründung.
Variablen sind nachvollziehbar platziert und überschreiben sich nicht überraschend.
Secrets erscheinen nicht in Klartext, Diff-Ausgaben, Debug-Tasks oder CI-Logs.
Das Playbook kann mehrfach laufen, ohne unnötige Änderungen zu melden.
Rückbau, Fix-forward oder kontrolliertes Belassen des Zielzustands ist dokumentiert.

Typische Fehler bei der Prüfung der Workshop-Artefakte

Fehlerbild	Ursache	Diagnose
falsche Hosts getroffen	Pattern oder Inventory falsch verstanden	`--list-hosts`, `ansible-inventory --host`
`unreachable`	SSH, Benutzer, Python oder Netzwerkproblem	`-vvvv`, SSH-Test, Inventory-Variablen
unerwartete Änderung	Modul nicht idempotent oder falsche Datenquelle	zweiter Lauf, Diff, Variablenprüfung
Secret-Leak	Debug, Diff oder Log nicht begrenzt	`no_log`, Vault, CI-Artefakte prüfen
Handler läuft nicht	kein `changed` oder falscher Handlername	Task-Ergebnis und Handler-Name prüfen

Betriebsnotiz zur Prüfung der Workshop-Artefakte

Für produktionsnahe Nutzung muss aus dem Lab ein Runbook entstehen. Dieses Runbook nennt Zielsysteme, Verantwortliche, Vorbedingungen, Stop-Kriterien, erwartete Dauer, Validierung, Monitoring und Rückbau. Ohne diese Angaben bleibt ein Playbook technisch ausführbar, aber nicht betriebsreif.

Die Prüfung der Workshop-Artefakte ist ein praktischer Baustein des Ansible-Workshops. Entscheidend ist, dass der gewünschte Zustand nicht nur beschrieben, sondern vor und nach der Ausführung überprüft wird. Ein guter Ansible-Arbeitsablauf beantwortet immer vier Fragen: Welche Hosts sind betroffen, welche Änderung wird durchgeführt, welche Rechte werden dafür benötigt und wie wird der Erfolg gemessen?

Aspekt	Bedeutung im Workshop	Prüfpunkt
Scope	Inventory, Pattern, `--limit`, Tags und Umgebung bestimmen die Zielsysteme.	`ansible-inventory --graph`, `ansible-playbook --list-hosts`
Zustand	Module sollen Zielzustände modellieren und wiederholbare Ergebnisse liefern.	zweiter Lauf ohne unnötige Änderungen
Rechte	`become` wird tasknah und begründet eingesetzt.	kein globales Privileg ohne Review
Evidence	Ausgaben, Diffs und Zusammenfassung werden dokumentiert.	Play Recap, Diff, Evidence-Datei

Typische Kommandos:

ansible --version
ansible-config dump --only-changed
ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff

Für Reviews gilt: Ein Playbook ist erst dann gut genug, wenn es seine Zielgruppe beweist, seine Datenquellen offenlegt, sensible Werte schützt, Fehlerpfade beschreibt und nach einem zweiten Lauf stabil bleibt. Wenn ein Modul Check Mode oder Diff Mode nicht vollständig unterstützt, muss die Einschränkung im Runbook stehen.

Typische Fehler in diesem Bereich sind zu breite Patterns wie all, unklare Variablenquellen, Shell-Workarounds ohne Idempotenz, Secrets in Debug-Ausgaben, fehlende Rollback-Notiz und fehlende Trennung zwischen Lab- und Produktionsinventory.

9. Provisionierung

Vertiefung und Abgabebeispiel zu Provisionierung

Eine vollständige Bearbeitung von Provisionierung besteht aus einem technischen Artefakt und einer kurzen fachlichen Einordnung. Das Artefakt kann ein Inventory, ein Playbook, eine Rolle, ein Template, eine Vault-Datei mit Dummy-Werten, eine CI-Konfiguration oder eine Evidence-Datei sein. Die Einordnung erklärt, warum dieser Weg gewählt wurde und welche Alternative bewusst nicht verwendet wurde.

Abgabeteil	Inhalt	Mindestqualität
Zielbeschreibung	Was soll nach dem Lauf gelten?	messbar und ohne implizite Annahmen
Scope-Nachweis	Welche Hosts sind betroffen?	Ausgabe von `--list-hosts` oder Inventory-Graph
Umsetzung	Welche Dateien wurden geändert?	kleine, reviewbare YAML-Dateien
Validierung	Wie wurde geprüft?	Syntaxcheck, Check Mode, Diff, echter Lauf, zweiter Lauf
Risikoentscheidung	Was kann schiefgehen?	Rechte, Secrets, externe Abhängigkeiten und Rollback betrachtet

Minimalartefakte für Provisionierung

submission/
  inventory/hosts.yml
  playbooks/site.yml
  evidence.md
  cleanup.md

Für Rollen oder Collections wird die Struktur erweitert:

submission/
  ansible.cfg
  collections/requirements.yml
  inventory/hosts.yml
  roles/<role>/defaults/main.yml
  roles/<role>/tasks/main.yml
  roles/<role>/handlers/main.yml
  playbooks/site.yml
  evidence.md

Prüferwartung für Provisionierung

Eine prüfbare Lösung muss auch für Personen verständlich sein, die den Lauf nicht selbst ausgeführt haben. Deshalb reichen Screenshots oder unkommentierte Terminalausgaben nicht aus. Gute Evidence beschreibt Kontext, Kommando, relevante Ausgabe und Bewertung. Wenn ein Modul im Check Mode abweicht, wird diese Einschränkung ausdrücklich genannt.

Transfer in reale Teams

Im Teamkontext wird Provisionierung zusätzlich mit Code Review, Branch-Regeln, CI, Rollenownership, Release-Notizen und Betriebsfreigabe verbunden. Für produktionsnahe Nutzung werden außerdem Zuständigkeit, Wartungsfenster, Monitoring, Alarmierung und Rollback-Kriterien dokumentiert.

Praxisbezug zu Provisionierung

Dieser Abschnitt ist nicht als reine Begriffserklärung gedacht. Im Workshop wird Provisionierung immer an einem konkreten Ablauf überprüft: Inventory lesen, Zielhosts beweisen, Playbook prüfen, Änderung simulieren, Änderung ausführen, zweiten Lauf bewerten und Rückbau dokumentieren. Dadurch wird sichtbar, ob Ansible wirklich einen Zielzustand beschreibt oder nur zufällig einen Befehl erfolgreich ausgeführt hat.

Prüffrage	Erwartete Antwort
Welche Hosts sind betroffen?	Pattern, Gruppe, `--limit` und Inventory-Ausgabe sind dokumentiert.
Welche Datenquellen wirken?	`group_vars`, `host_vars`, Defaults, Extra Vars und Facts sind bekannt.
Welche Rechte werden benötigt?	`become` ist tasknah und fachlich begründet.
Wie wird Erfolg bewiesen?	Syntaxcheck, Check Mode, Diff, Play Recap und zweiter Lauf liegen vor.

Beispielablauf für Provisionierung

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

Der Ablauf ist bewusst vollständig. In echten Teams werden einzelne Schritte oft automatisiert, aber nicht übersprungen. CI kann Syntaxcheck und Linting übernehmen; die fachliche Bewertung von Scope, Rechten, Secret-Flows und Rollout-Risiko bleibt eine Review-Aufgabe.

Review-Kriterien für Provisionierung

Inventory und Pattern sind enger als all, sofern kein guter Grund dokumentiert ist.
Module aus ansible.builtin oder klar geprüften Collections werden bevorzugt.
Shell- oder Command-Tasks haben changed_when, failed_when oder eine Begründung.
Variablen sind nachvollziehbar platziert und überschreiben sich nicht überraschend.
Secrets erscheinen nicht in Klartext, Diff-Ausgaben, Debug-Tasks oder CI-Logs.
Das Playbook kann mehrfach laufen, ohne unnötige Änderungen zu melden.
Rückbau, Fix-forward oder kontrolliertes Belassen des Zielzustands ist dokumentiert.

Typische Fehler bei Provisionierung

Fehlerbild	Ursache	Diagnose
falsche Hosts getroffen	Pattern oder Inventory falsch verstanden	`--list-hosts`, `ansible-inventory --host`
`unreachable`	SSH, Benutzer, Python oder Netzwerkproblem	`-vvvv`, SSH-Test, Inventory-Variablen
unerwartete Änderung	Modul nicht idempotent oder falsche Datenquelle	zweiter Lauf, Diff, Variablenprüfung
Secret-Leak	Debug, Diff oder Log nicht begrenzt	`no_log`, Vault, CI-Artefakte prüfen
Handler läuft nicht	kein `changed` oder falscher Handlername	Task-Ergebnis und Handler-Name prüfen

Betriebsnotiz für Provisionierung

Für produktionsnahe Nutzung muss aus dem Lab ein Runbook entstehen. Dieses Runbook nennt Zielsysteme, Verantwortliche, Vorbedingungen, Stop-Kriterien, erwartete Dauer, Validierung, Monitoring und Rückbau. Ohne diese Angaben bleibt ein Playbook technisch ausführbar, aber nicht betriebsreif.

Provisionierung ist ein praktischer Baustein des Ansible-Workshops. Entscheidend ist, dass der gewünschte Zustand nicht nur beschrieben, sondern vor und nach der Ausführung überprüft wird. Ein guter Ansible-Arbeitsablauf beantwortet immer vier Fragen: Welche Hosts sind betroffen, welche Änderung wird durchgeführt, welche Rechte werden dafür benötigt und wie wird der Erfolg gemessen?

Aspekt	Bedeutung im Workshop	Prüfpunkt
Scope	Inventory, Pattern, `--limit`, Tags und Umgebung bestimmen die Zielsysteme.	`ansible-inventory --graph`, `ansible-playbook --list-hosts`
Zustand	Module sollen Zielzustände modellieren und wiederholbare Ergebnisse liefern.	zweiter Lauf ohne unnötige Änderungen
Rechte	`become` wird tasknah und begründet eingesetzt.	kein globales Privileg ohne Review
Evidence	Ausgaben, Diffs und Zusammenfassung werden dokumentiert.	Play Recap, Diff, Evidence-Datei

Typische Kommandos:

ansible --version
ansible-config dump --only-changed
ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff

Für Reviews gilt: Ein Playbook ist erst dann gut genug, wenn es seine Zielgruppe beweist, seine Datenquellen offenlegt, sensible Werte schützt, Fehlerpfade beschreibt und nach einem zweiten Lauf stabil bleibt. Wenn ein Modul Check Mode oder Diff Mode nicht vollständig unterstützt, muss die Einschränkung im Runbook stehen.

Typische Fehler in diesem Bereich sind zu breite Patterns wie all, unklare Variablenquellen, Shell-Workarounds ohne Idempotenz, Secrets in Debug-Ausgaben, fehlende Rollback-Notiz und fehlende Trennung zwischen Lab- und Produktionsinventory.

10. Validierung

Vertiefung und Abgabebeispiel zu Validierung

Eine vollständige Bearbeitung von Validierung besteht aus einem technischen Artefakt und einer kurzen fachlichen Einordnung. Das Artefakt kann ein Inventory, ein Playbook, eine Rolle, ein Template, eine Vault-Datei mit Dummy-Werten, eine CI-Konfiguration oder eine Evidence-Datei sein. Die Einordnung erklärt, warum dieser Weg gewählt wurde und welche Alternative bewusst nicht verwendet wurde.

Abgabeteil	Inhalt	Mindestqualität
Zielbeschreibung	Was soll nach dem Lauf gelten?	messbar und ohne implizite Annahmen
Scope-Nachweis	Welche Hosts sind betroffen?	Ausgabe von `--list-hosts` oder Inventory-Graph
Umsetzung	Welche Dateien wurden geändert?	kleine, reviewbare YAML-Dateien
Validierung	Wie wurde geprüft?	Syntaxcheck, Check Mode, Diff, echter Lauf, zweiter Lauf
Risikoentscheidung	Was kann schiefgehen?	Rechte, Secrets, externe Abhängigkeiten und Rollback betrachtet

Minimalartefakte für Validierung

submission/
  inventory/hosts.yml
  playbooks/site.yml
  evidence.md
  cleanup.md

Für Rollen oder Collections wird die Struktur erweitert:

submission/
  ansible.cfg
  collections/requirements.yml
  inventory/hosts.yml
  roles/<role>/defaults/main.yml
  roles/<role>/tasks/main.yml
  roles/<role>/handlers/main.yml
  playbooks/site.yml
  evidence.md

Prüferwartung für Validierung

Eine prüfbare Lösung muss auch für Personen verständlich sein, die den Lauf nicht selbst ausgeführt haben. Deshalb reichen Screenshots oder unkommentierte Terminalausgaben nicht aus. Gute Evidence beschreibt Kontext, Kommando, relevante Ausgabe und Bewertung. Wenn ein Modul im Check Mode abweicht, wird diese Einschränkung ausdrücklich genannt.

Transfer in reale Teams

Im Teamkontext wird Validierung zusätzlich mit Code Review, Branch-Regeln, CI, Rollenownership, Release-Notizen und Betriebsfreigabe verbunden. Für produktionsnahe Nutzung werden außerdem Zuständigkeit, Wartungsfenster, Monitoring, Alarmierung und Rollback-Kriterien dokumentiert.

Praxisbezug zu Validierung

Dieser Abschnitt ist nicht als reine Begriffserklärung gedacht. Im Workshop wird Validierung immer an einem konkreten Ablauf überprüft: Inventory lesen, Zielhosts beweisen, Playbook prüfen, Änderung simulieren, Änderung ausführen, zweiten Lauf bewerten und Rückbau dokumentieren. Dadurch wird sichtbar, ob Ansible wirklich einen Zielzustand beschreibt oder nur zufällig einen Befehl erfolgreich ausgeführt hat.

Prüffrage	Erwartete Antwort
Welche Hosts sind betroffen?	Pattern, Gruppe, `--limit` und Inventory-Ausgabe sind dokumentiert.
Welche Datenquellen wirken?	`group_vars`, `host_vars`, Defaults, Extra Vars und Facts sind bekannt.
Welche Rechte werden benötigt?	`become` ist tasknah und fachlich begründet.
Wie wird Erfolg bewiesen?	Syntaxcheck, Check Mode, Diff, Play Recap und zweiter Lauf liegen vor.

Beispielablauf für Validierung

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

Der Ablauf ist bewusst vollständig. In echten Teams werden einzelne Schritte oft automatisiert, aber nicht übersprungen. CI kann Syntaxcheck und Linting übernehmen; die fachliche Bewertung von Scope, Rechten, Secret-Flows und Rollout-Risiko bleibt eine Review-Aufgabe.

Review-Kriterien für Validierung

Inventory und Pattern sind enger als all, sofern kein guter Grund dokumentiert ist.
Module aus ansible.builtin oder klar geprüften Collections werden bevorzugt.
Shell- oder Command-Tasks haben changed_when, failed_when oder eine Begründung.
Variablen sind nachvollziehbar platziert und überschreiben sich nicht überraschend.
Secrets erscheinen nicht in Klartext, Diff-Ausgaben, Debug-Tasks oder CI-Logs.
Das Playbook kann mehrfach laufen, ohne unnötige Änderungen zu melden.
Rückbau, Fix-forward oder kontrolliertes Belassen des Zielzustands ist dokumentiert.

Typische Fehler bei Validierung

Fehlerbild	Ursache	Diagnose
falsche Hosts getroffen	Pattern oder Inventory falsch verstanden	`--list-hosts`, `ansible-inventory --host`
`unreachable`	SSH, Benutzer, Python oder Netzwerkproblem	`-vvvv`, SSH-Test, Inventory-Variablen
unerwartete Änderung	Modul nicht idempotent oder falsche Datenquelle	zweiter Lauf, Diff, Variablenprüfung
Secret-Leak	Debug, Diff oder Log nicht begrenzt	`no_log`, Vault, CI-Artefakte prüfen
Handler läuft nicht	kein `changed` oder falscher Handlername	Task-Ergebnis und Handler-Name prüfen

Betriebsnotiz für Validierung

Für produktionsnahe Nutzung muss aus dem Lab ein Runbook entstehen. Dieses Runbook nennt Zielsysteme, Verantwortliche, Vorbedingungen, Stop-Kriterien, erwartete Dauer, Validierung, Monitoring und Rückbau. Ohne diese Angaben bleibt ein Playbook technisch ausführbar, aber nicht betriebsreif.

Validierung ist ein praktischer Baustein des Ansible-Workshops. Entscheidend ist, dass der gewünschte Zustand nicht nur beschrieben, sondern vor und nach der Ausführung überprüft wird. Ein guter Ansible-Arbeitsablauf beantwortet immer vier Fragen: Welche Hosts sind betroffen, welche Änderung wird durchgeführt, welche Rechte werden dafür benötigt und wie wird der Erfolg gemessen?

Aspekt	Bedeutung im Workshop	Prüfpunkt
Scope	Inventory, Pattern, `--limit`, Tags und Umgebung bestimmen die Zielsysteme.	`ansible-inventory --graph`, `ansible-playbook --list-hosts`
Zustand	Module sollen Zielzustände modellieren und wiederholbare Ergebnisse liefern.	zweiter Lauf ohne unnötige Änderungen
Rechte	`become` wird tasknah und begründet eingesetzt.	kein globales Privileg ohne Review
Evidence	Ausgaben, Diffs und Zusammenfassung werden dokumentiert.	Play Recap, Diff, Evidence-Datei

Typische Kommandos:

ansible --version
ansible-config dump --only-changed
ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff

Für Reviews gilt: Ein Playbook ist erst dann gut genug, wenn es seine Zielgruppe beweist, seine Datenquellen offenlegt, sensible Werte schützt, Fehlerpfade beschreibt und nach einem zweiten Lauf stabil bleibt. Wenn ein Modul Check Mode oder Diff Mode nicht vollständig unterstützt, muss die Einschränkung im Runbook stehen.

Typische Fehler in diesem Bereich sind zu breite Patterns wie all, unklare Variablenquellen, Shell-Workarounds ohne Idempotenz, Secrets in Debug-Ausgaben, fehlende Rollback-Notiz und fehlende Trennung zwischen Lab- und Produktionsinventory.

11. Mehrere VMs

Vertiefung und Abgabebeispiel zu Mehrere VMs

Eine vollständige Bearbeitung von Mehrere VMs besteht aus einem technischen Artefakt und einer kurzen fachlichen Einordnung. Das Artefakt kann ein Inventory, ein Playbook, eine Rolle, ein Template, eine Vault-Datei mit Dummy-Werten, eine CI-Konfiguration oder eine Evidence-Datei sein. Die Einordnung erklärt, warum dieser Weg gewählt wurde und welche Alternative bewusst nicht verwendet wurde.

Abgabeteil	Inhalt	Mindestqualität
Zielbeschreibung	Was soll nach dem Lauf gelten?	messbar und ohne implizite Annahmen
Scope-Nachweis	Welche Hosts sind betroffen?	Ausgabe von `--list-hosts` oder Inventory-Graph
Umsetzung	Welche Dateien wurden geändert?	kleine, reviewbare YAML-Dateien
Validierung	Wie wurde geprüft?	Syntaxcheck, Check Mode, Diff, echter Lauf, zweiter Lauf
Risikoentscheidung	Was kann schiefgehen?	Rechte, Secrets, externe Abhängigkeiten und Rollback betrachtet

Minimalartefakte für Mehrere VMs

submission/
  inventory/hosts.yml
  playbooks/site.yml
  evidence.md
  cleanup.md

Für Rollen oder Collections wird die Struktur erweitert:

submission/
  ansible.cfg
  collections/requirements.yml
  inventory/hosts.yml
  roles/<role>/defaults/main.yml
  roles/<role>/tasks/main.yml
  roles/<role>/handlers/main.yml
  playbooks/site.yml
  evidence.md

Prüferwartung für Mehrere VMs

Eine prüfbare Lösung muss auch für Personen verständlich sein, die den Lauf nicht selbst ausgeführt haben. Deshalb reichen Screenshots oder unkommentierte Terminalausgaben nicht aus. Gute Evidence beschreibt Kontext, Kommando, relevante Ausgabe und Bewertung. Wenn ein Modul im Check Mode abweicht, wird diese Einschränkung ausdrücklich genannt.

Transfer in reale Teams

Im Teamkontext wird Mehrere VMs zusätzlich mit Code Review, Branch-Regeln, CI, Rollenownership, Release-Notizen und Betriebsfreigabe verbunden. Für produktionsnahe Nutzung werden außerdem Zuständigkeit, Wartungsfenster, Monitoring, Alarmierung und Rollback-Kriterien dokumentiert.

Praxisbezug zu Mehrere VMs

Dieser Abschnitt ist nicht als reine Begriffserklärung gedacht. Im Workshop wird Mehrere VMs immer an einem konkreten Ablauf überprüft: Inventory lesen, Zielhosts beweisen, Playbook prüfen, Änderung simulieren, Änderung ausführen, zweiten Lauf bewerten und Rückbau dokumentieren. Dadurch wird sichtbar, ob Ansible wirklich einen Zielzustand beschreibt oder nur zufällig einen Befehl erfolgreich ausgeführt hat.

Prüffrage	Erwartete Antwort
Welche Hosts sind betroffen?	Pattern, Gruppe, `--limit` und Inventory-Ausgabe sind dokumentiert.
Welche Datenquellen wirken?	`group_vars`, `host_vars`, Defaults, Extra Vars und Facts sind bekannt.
Welche Rechte werden benötigt?	`become` ist tasknah und fachlich begründet.
Wie wird Erfolg bewiesen?	Syntaxcheck, Check Mode, Diff, Play Recap und zweiter Lauf liegen vor.

Beispielablauf für Mehrere VMs

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

Der Ablauf ist bewusst vollständig. In echten Teams werden einzelne Schritte oft automatisiert, aber nicht übersprungen. CI kann Syntaxcheck und Linting übernehmen; die fachliche Bewertung von Scope, Rechten, Secret-Flows und Rollout-Risiko bleibt eine Review-Aufgabe.

Review-Kriterien für Mehrere VMs

Inventory und Pattern sind enger als all, sofern kein guter Grund dokumentiert ist.
Module aus ansible.builtin oder klar geprüften Collections werden bevorzugt.
Shell- oder Command-Tasks haben changed_when, failed_when oder eine Begründung.
Variablen sind nachvollziehbar platziert und überschreiben sich nicht überraschend.
Secrets erscheinen nicht in Klartext, Diff-Ausgaben, Debug-Tasks oder CI-Logs.
Das Playbook kann mehrfach laufen, ohne unnötige Änderungen zu melden.
Rückbau, Fix-forward oder kontrolliertes Belassen des Zielzustands ist dokumentiert.

Typische Fehler bei Mehrere VMs

Fehlerbild	Ursache	Diagnose
falsche Hosts getroffen	Pattern oder Inventory falsch verstanden	`--list-hosts`, `ansible-inventory --host`
`unreachable`	SSH, Benutzer, Python oder Netzwerkproblem	`-vvvv`, SSH-Test, Inventory-Variablen
unerwartete Änderung	Modul nicht idempotent oder falsche Datenquelle	zweiter Lauf, Diff, Variablenprüfung
Secret-Leak	Debug, Diff oder Log nicht begrenzt	`no_log`, Vault, CI-Artefakte prüfen
Handler läuft nicht	kein `changed` oder falscher Handlername	Task-Ergebnis und Handler-Name prüfen

Betriebsnotiz für Mehrere VMs

Für produktionsnahe Nutzung muss aus dem Lab ein Runbook entstehen. Dieses Runbook nennt Zielsysteme, Verantwortliche, Vorbedingungen, Stop-Kriterien, erwartete Dauer, Validierung, Monitoring und Rückbau. Ohne diese Angaben bleibt ein Playbook technisch ausführbar, aber nicht betriebsreif.

Mehrere VMs ist ein praktischer Baustein des Ansible-Workshops. Entscheidend ist, dass der gewünschte Zustand nicht nur beschrieben, sondern vor und nach der Ausführung überprüft wird. Ein guter Ansible-Arbeitsablauf beantwortet immer vier Fragen: Welche Hosts sind betroffen, welche Änderung wird durchgeführt, welche Rechte werden dafür benötigt und wie wird der Erfolg gemessen?

Aspekt	Bedeutung im Workshop	Prüfpunkt
Scope	Inventory, Pattern, `--limit`, Tags und Umgebung bestimmen die Zielsysteme.	`ansible-inventory --graph`, `ansible-playbook --list-hosts`
Zustand	Module sollen Zielzustände modellieren und wiederholbare Ergebnisse liefern.	zweiter Lauf ohne unnötige Änderungen
Rechte	`become` wird tasknah und begründet eingesetzt.	kein globales Privileg ohne Review
Evidence	Ausgaben, Diffs und Zusammenfassung werden dokumentiert.	Play Recap, Diff, Evidence-Datei

Typische Kommandos:

ansible --version
ansible-config dump --only-changed
ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff

Für Reviews gilt: Ein Playbook ist erst dann gut genug, wenn es seine Zielgruppe beweist, seine Datenquellen offenlegt, sensible Werte schützt, Fehlerpfade beschreibt und nach einem zweiten Lauf stabil bleibt. Wenn ein Modul Check Mode oder Diff Mode nicht vollständig unterstützt, muss die Einschränkung im Runbook stehen.

Typische Fehler in diesem Bereich sind zu breite Patterns wie all, unklare Variablenquellen, Shell-Workarounds ohne Idempotenz, Secrets in Debug-Ausgaben, fehlende Rollback-Notiz und fehlende Trennung zwischen Lab- und Produktionsinventory.

12. Sicherheitsregeln

Vertiefung und Abgabebeispiel zu Sicherheitsregeln

Eine vollständige Bearbeitung von Sicherheitsregeln besteht aus einem technischen Artefakt und einer kurzen fachlichen Einordnung. Das Artefakt kann ein Inventory, ein Playbook, eine Rolle, ein Template, eine Vault-Datei mit Dummy-Werten, eine CI-Konfiguration oder eine Evidence-Datei sein. Die Einordnung erklärt, warum dieser Weg gewählt wurde und welche Alternative bewusst nicht verwendet wurde.

Abgabeteil	Inhalt	Mindestqualität
Zielbeschreibung	Was soll nach dem Lauf gelten?	messbar und ohne implizite Annahmen
Scope-Nachweis	Welche Hosts sind betroffen?	Ausgabe von `--list-hosts` oder Inventory-Graph
Umsetzung	Welche Dateien wurden geändert?	kleine, reviewbare YAML-Dateien
Validierung	Wie wurde geprüft?	Syntaxcheck, Check Mode, Diff, echter Lauf, zweiter Lauf
Risikoentscheidung	Was kann schiefgehen?	Rechte, Secrets, externe Abhängigkeiten und Rollback betrachtet

Minimalartefakte für Sicherheitsregeln

submission/
  inventory/hosts.yml
  playbooks/site.yml
  evidence.md
  cleanup.md

Für Rollen oder Collections wird die Struktur erweitert:

submission/
  ansible.cfg
  collections/requirements.yml
  inventory/hosts.yml
  roles/<role>/defaults/main.yml
  roles/<role>/tasks/main.yml
  roles/<role>/handlers/main.yml
  playbooks/site.yml
  evidence.md

Prüferwartung für Sicherheitsregeln

Eine prüfbare Lösung muss auch für Personen verständlich sein, die den Lauf nicht selbst ausgeführt haben. Deshalb reichen Screenshots oder unkommentierte Terminalausgaben nicht aus. Gute Evidence beschreibt Kontext, Kommando, relevante Ausgabe und Bewertung. Wenn ein Modul im Check Mode abweicht, wird diese Einschränkung ausdrücklich genannt.

Transfer in reale Teams

Im Teamkontext wird Sicherheitsregeln zusätzlich mit Code Review, Branch-Regeln, CI, Rollenownership, Release-Notizen und Betriebsfreigabe verbunden. Für produktionsnahe Nutzung werden außerdem Zuständigkeit, Wartungsfenster, Monitoring, Alarmierung und Rollback-Kriterien dokumentiert.

Praxisbezug zu Sicherheitsregeln

Dieser Abschnitt ist nicht als reine Begriffserklärung gedacht. Im Workshop wird Sicherheitsregeln immer an einem konkreten Ablauf überprüft: Inventory lesen, Zielhosts beweisen, Playbook prüfen, Änderung simulieren, Änderung ausführen, zweiten Lauf bewerten und Rückbau dokumentieren. Dadurch wird sichtbar, ob Ansible wirklich einen Zielzustand beschreibt oder nur zufällig einen Befehl erfolgreich ausgeführt hat.

Prüffrage	Erwartete Antwort
Welche Hosts sind betroffen?	Pattern, Gruppe, `--limit` und Inventory-Ausgabe sind dokumentiert.
Welche Datenquellen wirken?	`group_vars`, `host_vars`, Defaults, Extra Vars und Facts sind bekannt.
Welche Rechte werden benötigt?	`become` ist tasknah und fachlich begründet.
Wie wird Erfolg bewiesen?	Syntaxcheck, Check Mode, Diff, Play Recap und zweiter Lauf liegen vor.

Beispielablauf für Sicherheitsregeln

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

Der Ablauf ist bewusst vollständig. In echten Teams werden einzelne Schritte oft automatisiert, aber nicht übersprungen. CI kann Syntaxcheck und Linting übernehmen; die fachliche Bewertung von Scope, Rechten, Secret-Flows und Rollout-Risiko bleibt eine Review-Aufgabe.

Review-Kriterien für Sicherheitsregeln

Inventory und Pattern sind enger als all, sofern kein guter Grund dokumentiert ist.
Module aus ansible.builtin oder klar geprüften Collections werden bevorzugt.
Shell- oder Command-Tasks haben changed_when, failed_when oder eine Begründung.
Variablen sind nachvollziehbar platziert und überschreiben sich nicht überraschend.
Secrets erscheinen nicht in Klartext, Diff-Ausgaben, Debug-Tasks oder CI-Logs.
Das Playbook kann mehrfach laufen, ohne unnötige Änderungen zu melden.
Rückbau, Fix-forward oder kontrolliertes Belassen des Zielzustands ist dokumentiert.

Typische Fehler bei Sicherheitsregeln

Fehlerbild	Ursache	Diagnose
falsche Hosts getroffen	Pattern oder Inventory falsch verstanden	`--list-hosts`, `ansible-inventory --host`
`unreachable`	SSH, Benutzer, Python oder Netzwerkproblem	`-vvvv`, SSH-Test, Inventory-Variablen
unerwartete Änderung	Modul nicht idempotent oder falsche Datenquelle	zweiter Lauf, Diff, Variablenprüfung
Secret-Leak	Debug, Diff oder Log nicht begrenzt	`no_log`, Vault, CI-Artefakte prüfen
Handler läuft nicht	kein `changed` oder falscher Handlername	Task-Ergebnis und Handler-Name prüfen

Betriebsnotiz für Sicherheitsregeln

Für produktionsnahe Nutzung muss aus dem Lab ein Runbook entstehen. Dieses Runbook nennt Zielsysteme, Verantwortliche, Vorbedingungen, Stop-Kriterien, erwartete Dauer, Validierung, Monitoring und Rückbau. Ohne diese Angaben bleibt ein Playbook technisch ausführbar, aber nicht betriebsreif.

Sicherheitsregeln ist ein praktischer Baustein des Ansible-Workshops. Entscheidend ist, dass der gewünschte Zustand nicht nur beschrieben, sondern vor und nach der Ausführung überprüft wird. Ein guter Ansible-Arbeitsablauf beantwortet immer vier Fragen: Welche Hosts sind betroffen, welche Änderung wird durchgeführt, welche Rechte werden dafür benötigt und wie wird der Erfolg gemessen?

Aspekt	Bedeutung im Workshop	Prüfpunkt
Scope	Inventory, Pattern, `--limit`, Tags und Umgebung bestimmen die Zielsysteme.	`ansible-inventory --graph`, `ansible-playbook --list-hosts`
Zustand	Module sollen Zielzustände modellieren und wiederholbare Ergebnisse liefern.	zweiter Lauf ohne unnötige Änderungen
Rechte	`become` wird tasknah und begründet eingesetzt.	kein globales Privileg ohne Review
Evidence	Ausgaben, Diffs und Zusammenfassung werden dokumentiert.	Play Recap, Diff, Evidence-Datei

Typische Kommandos:

ansible --version
ansible-config dump --only-changed
ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff

Für Reviews gilt: Ein Playbook ist erst dann gut genug, wenn es seine Zielgruppe beweist, seine Datenquellen offenlegt, sensible Werte schützt, Fehlerpfade beschreibt und nach einem zweiten Lauf stabil bleibt. Wenn ein Modul Check Mode oder Diff Mode nicht vollständig unterstützt, muss die Einschränkung im Runbook stehen.

Typische Fehler in diesem Bereich sind zu breite Patterns wie all, unklare Variablenquellen, Shell-Workarounds ohne Idempotenz, Secrets in Debug-Ausgaben, fehlende Rollback-Notiz und fehlende Trennung zwischen Lab- und Produktionsinventory.

13. Cleanup

Vertiefung und Abgabebeispiel zu Cleanup

Eine vollständige Bearbeitung von Cleanup besteht aus einem technischen Artefakt und einer kurzen fachlichen Einordnung. Das Artefakt kann ein Inventory, ein Playbook, eine Rolle, ein Template, eine Vault-Datei mit Dummy-Werten, eine CI-Konfiguration oder eine Evidence-Datei sein. Die Einordnung erklärt, warum dieser Weg gewählt wurde und welche Alternative bewusst nicht verwendet wurde.

Abgabeteil	Inhalt	Mindestqualität
Zielbeschreibung	Was soll nach dem Lauf gelten?	messbar und ohne implizite Annahmen
Scope-Nachweis	Welche Hosts sind betroffen?	Ausgabe von `--list-hosts` oder Inventory-Graph
Umsetzung	Welche Dateien wurden geändert?	kleine, reviewbare YAML-Dateien
Validierung	Wie wurde geprüft?	Syntaxcheck, Check Mode, Diff, echter Lauf, zweiter Lauf
Risikoentscheidung	Was kann schiefgehen?	Rechte, Secrets, externe Abhängigkeiten und Rollback betrachtet

Minimalartefakte für Cleanup

submission/
  inventory/hosts.yml
  playbooks/site.yml
  evidence.md
  cleanup.md

Für Rollen oder Collections wird die Struktur erweitert:

submission/
  ansible.cfg
  collections/requirements.yml
  inventory/hosts.yml
  roles/<role>/defaults/main.yml
  roles/<role>/tasks/main.yml
  roles/<role>/handlers/main.yml
  playbooks/site.yml
  evidence.md

Prüferwartung für Cleanup

Eine prüfbare Lösung muss auch für Personen verständlich sein, die den Lauf nicht selbst ausgeführt haben. Deshalb reichen Screenshots oder unkommentierte Terminalausgaben nicht aus. Gute Evidence beschreibt Kontext, Kommando, relevante Ausgabe und Bewertung. Wenn ein Modul im Check Mode abweicht, wird diese Einschränkung ausdrücklich genannt.

Transfer in reale Teams

Im Teamkontext wird Cleanup zusätzlich mit Code Review, Branch-Regeln, CI, Rollenownership, Release-Notizen und Betriebsfreigabe verbunden. Für produktionsnahe Nutzung werden außerdem Zuständigkeit, Wartungsfenster, Monitoring, Alarmierung und Rollback-Kriterien dokumentiert.

Praxisbezug zu Cleanup

Dieser Abschnitt ist nicht als reine Begriffserklärung gedacht. Im Workshop wird Cleanup immer an einem konkreten Ablauf überprüft: Inventory lesen, Zielhosts beweisen, Playbook prüfen, Änderung simulieren, Änderung ausführen, zweiten Lauf bewerten und Rückbau dokumentieren. Dadurch wird sichtbar, ob Ansible wirklich einen Zielzustand beschreibt oder nur zufällig einen Befehl erfolgreich ausgeführt hat.

Prüffrage	Erwartete Antwort
Welche Hosts sind betroffen?	Pattern, Gruppe, `--limit` und Inventory-Ausgabe sind dokumentiert.
Welche Datenquellen wirken?	`group_vars`, `host_vars`, Defaults, Extra Vars und Facts sind bekannt.
Welche Rechte werden benötigt?	`become` ist tasknah und fachlich begründet.
Wie wird Erfolg bewiesen?	Syntaxcheck, Check Mode, Diff, Play Recap und zweiter Lauf liegen vor.

Beispielablauf für Cleanup

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

Der Ablauf ist bewusst vollständig. In echten Teams werden einzelne Schritte oft automatisiert, aber nicht übersprungen. CI kann Syntaxcheck und Linting übernehmen; die fachliche Bewertung von Scope, Rechten, Secret-Flows und Rollout-Risiko bleibt eine Review-Aufgabe.

Review-Kriterien für Cleanup

Inventory und Pattern sind enger als all, sofern kein guter Grund dokumentiert ist.
Module aus ansible.builtin oder klar geprüften Collections werden bevorzugt.
Shell- oder Command-Tasks haben changed_when, failed_when oder eine Begründung.
Variablen sind nachvollziehbar platziert und überschreiben sich nicht überraschend.
Secrets erscheinen nicht in Klartext, Diff-Ausgaben, Debug-Tasks oder CI-Logs.
Das Playbook kann mehrfach laufen, ohne unnötige Änderungen zu melden.
Rückbau, Fix-forward oder kontrolliertes Belassen des Zielzustands ist dokumentiert.

Typische Fehler bei Cleanup

Fehlerbild	Ursache	Diagnose
falsche Hosts getroffen	Pattern oder Inventory falsch verstanden	`--list-hosts`, `ansible-inventory --host`
`unreachable`	SSH, Benutzer, Python oder Netzwerkproblem	`-vvvv`, SSH-Test, Inventory-Variablen
unerwartete Änderung	Modul nicht idempotent oder falsche Datenquelle	zweiter Lauf, Diff, Variablenprüfung
Secret-Leak	Debug, Diff oder Log nicht begrenzt	`no_log`, Vault, CI-Artefakte prüfen
Handler läuft nicht	kein `changed` oder falscher Handlername	Task-Ergebnis und Handler-Name prüfen

Betriebsnotiz für Cleanup

Für produktionsnahe Nutzung muss aus dem Lab ein Runbook entstehen. Dieses Runbook nennt Zielsysteme, Verantwortliche, Vorbedingungen, Stop-Kriterien, erwartete Dauer, Validierung, Monitoring und Rückbau. Ohne diese Angaben bleibt ein Playbook technisch ausführbar, aber nicht betriebsreif.

Cleanup ist ein praktischer Baustein des Ansible-Workshops. Entscheidend ist, dass der gewünschte Zustand nicht nur beschrieben, sondern vor und nach der Ausführung überprüft wird. Ein guter Ansible-Arbeitsablauf beantwortet immer vier Fragen: Welche Hosts sind betroffen, welche Änderung wird durchgeführt, welche Rechte werden dafür benötigt und wie wird der Erfolg gemessen?

Aspekt	Bedeutung im Workshop	Prüfpunkt
Scope	Inventory, Pattern, `--limit`, Tags und Umgebung bestimmen die Zielsysteme.	`ansible-inventory --graph`, `ansible-playbook --list-hosts`
Zustand	Module sollen Zielzustände modellieren und wiederholbare Ergebnisse liefern.	zweiter Lauf ohne unnötige Änderungen
Rechte	`become` wird tasknah und begründet eingesetzt.	kein globales Privileg ohne Review
Evidence	Ausgaben, Diffs und Zusammenfassung werden dokumentiert.	Play Recap, Diff, Evidence-Datei

Typische Kommandos:

ansible --version
ansible-config dump --only-changed
ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff

Für Reviews gilt: Ein Playbook ist erst dann gut genug, wenn es seine Zielgruppe beweist, seine Datenquellen offenlegt, sensible Werte schützt, Fehlerpfade beschreibt und nach einem zweiten Lauf stabil bleibt. Wenn ein Modul Check Mode oder Diff Mode nicht vollständig unterstützt, muss die Einschränkung im Runbook stehen.

Typische Fehler in diesem Bereich sind zu breite Patterns wie all, unklare Variablenquellen, Shell-Workarounds ohne Idempotenz, Secrets in Debug-Ausgaben, fehlende Rollback-Notiz und fehlende Trennung zwischen Lab- und Produktionsinventory.

Quellen und weiterführende Referenzen

Offizielle Ansible Community Documentation: https://docs.ansible.com/
Ansible Getting Started: https://docs.ansible.com/projects/ansible/latest/getting_started/index.html
Inventory Guide: https://docs.ansible.com/projects/ansible/latest/inventory_guide/index.html
Playbook Guide: https://docs.ansible.com/projects/ansible/latest/playbook_guide/index.html
Module Index: https://docs.ansible.com/ansible/latest/collections/ansible/builtin/index.html
Vault Guide: https://docs.ansible.com/projects/ansible/latest/vault_guide/index.html
Ansible Lint: https://ansible.readthedocs.io/projects/lint/
Molecule: https://ansible.readthedocs.io/projects/molecule/
AWX: https://github.com/ansible/awx
Red Hat Certifications: https://www.redhat.com/en/services/certifications