Curriculum: Ansible · Ansible

1. Ziel des Curriculums

Vertiefung und Abgabebeispiel zu Ziel des Curriculums

Eine vollständige Bearbeitung von Ziel des Curriculums 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 Ziel des Curriculums

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 Ziel des Curriculums

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 Ziel des Curriculums 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 Ziel des Curriculums

Dieser Abschnitt ist nicht als reine Begriffserklärung gedacht. Im Workshop wird Ziel des Curriculums 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 Ziel des Curriculums

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 Ziel des Curriculums

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 Ziel des Curriculums

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 Ziel des Curriculums

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.

Ziel des Curriculums 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. Didaktisches Modell

Vertiefung und Abgabebeispiel zu Didaktisches Modell

Eine vollständige Bearbeitung von Didaktisches Modell 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 Didaktisches Modell

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 Didaktisches Modell

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 Didaktisches Modell 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 Didaktisches Modell

Dieser Abschnitt ist nicht als reine Begriffserklärung gedacht. Im Workshop wird Didaktisches Modell 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 Didaktisches Modell

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 Didaktisches Modell

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 Didaktisches Modell

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 Didaktisches Modell

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.

Didaktisches Modell 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. Zielgruppen und Rollen

Vertiefung und Abgabebeispiel zu Zielgruppen und Rollen

Eine vollständige Bearbeitung von Zielgruppen und Rollen 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 Zielgruppen und Rollen

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 Zielgruppen und Rollen

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 Zielgruppen und Rollen 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 Zielgruppen und Rollen

Dieser Abschnitt ist nicht als reine Begriffserklärung gedacht. Im Workshop wird Zielgruppen und Rollen 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 Zielgruppen und Rollen

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 Zielgruppen und Rollen

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 Zielgruppen und Rollen

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 Zielgruppen und Rollen

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.

Zielgruppen und Rollen 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. Voraussetzungen

Vertiefung und Abgabebeispiel zu Voraussetzungen

Eine vollständige Bearbeitung von Voraussetzungen 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 Voraussetzungen

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 Voraussetzungen

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 Voraussetzungen 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 Voraussetzungen

Dieser Abschnitt ist nicht als reine Begriffserklärung gedacht. Im Workshop wird Voraussetzungen 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 Voraussetzungen

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 Voraussetzungen

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 Voraussetzungen

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 Voraussetzungen

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.

Voraussetzungen 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. Lernpfade

Vertiefung und Abgabebeispiel zu Lernpfade

Eine vollständige Bearbeitung von Lernpfade 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 Lernpfade

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 Lernpfade

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 Lernpfade 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 Lernpfade

Dieser Abschnitt ist nicht als reine Begriffserklärung gedacht. Im Workshop wird Lernpfade 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 Lernpfade

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 Lernpfade

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 Lernpfade

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 Lernpfade

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.

Lernpfade 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. Kompetenzstufen

Vertiefung und Abgabebeispiel zu Kompetenzstufen

Eine vollständige Bearbeitung von Kompetenzstufen 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 Kompetenzstufen

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 Kompetenzstufen

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 Kompetenzstufen 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 Kompetenzstufen

Dieser Abschnitt ist nicht als reine Begriffserklärung gedacht. Im Workshop wird Kompetenzstufen 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 Kompetenzstufen

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 Kompetenzstufen

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 Kompetenzstufen

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 Kompetenzstufen

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.

Kompetenzstufen 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. Gesamtstruktur

Vertiefung und Abgabebeispiel zu Gesamtstruktur

Eine vollständige Bearbeitung von Gesamtstruktur 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 Gesamtstruktur

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 Gesamtstruktur

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 Gesamtstruktur 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 Gesamtstruktur

Dieser Abschnitt ist nicht als reine Begriffserklärung gedacht. Im Workshop wird Gesamtstruktur 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 Gesamtstruktur

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 Gesamtstruktur

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 Gesamtstruktur

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 Gesamtstruktur

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.

Gesamtstruktur 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. Level 1 Fundamentals

Vertiefung und Abgabebeispiel zu Level 1 Fundamentals

Eine vollständige Bearbeitung von Level 1 Fundamentals 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 Level 1 Fundamentals

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 Level 1 Fundamentals

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 Level 1 Fundamentals 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 Level 1 Fundamentals

Dieser Abschnitt ist nicht als reine Begriffserklärung gedacht. Im Workshop wird Level 1 Fundamentals 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 Level 1 Fundamentals

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 Level 1 Fundamentals

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 Level 1 Fundamentals

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 Level 1 Fundamentals

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.

Level 1 Fundamentals 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. Level 2 Intermediate

Vertiefung und Abgabebeispiel zu Level 2 Intermediate

Eine vollständige Bearbeitung von Level 2 Intermediate 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 Level 2 Intermediate

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 Level 2 Intermediate

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 Level 2 Intermediate 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 Level 2 Intermediate

Dieser Abschnitt ist nicht als reine Begriffserklärung gedacht. Im Workshop wird Level 2 Intermediate 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 Level 2 Intermediate

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 Level 2 Intermediate

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 Level 2 Intermediate

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 Level 2 Intermediate

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.

Level 2 Intermediate 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. Level 3 Professional

Vertiefung und Abgabebeispiel zu Level 3 Professional

Eine vollständige Bearbeitung von Level 3 Professional 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 Level 3 Professional

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 Level 3 Professional

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 Level 3 Professional 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 Level 3 Professional

Dieser Abschnitt ist nicht als reine Begriffserklärung gedacht. Im Workshop wird Level 3 Professional 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 Level 3 Professional

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 Level 3 Professional

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 Level 3 Professional

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 Level 3 Professional

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.

Level 3 Professional 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. Level 4 Advanced und Security

Vertiefung und Abgabebeispiel zu Level 4 Advanced und Security

Eine vollständige Bearbeitung von Level 4 Advanced und Security 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 Level 4 Advanced und Security

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 Level 4 Advanced und Security

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 Level 4 Advanced und Security 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 Level 4 Advanced und Security

Dieser Abschnitt ist nicht als reine Begriffserklärung gedacht. Im Workshop wird Level 4 Advanced und Security 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 Level 4 Advanced und Security

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 Level 4 Advanced und Security

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 Level 4 Advanced und Security

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 Level 4 Advanced und Security

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.

Level 4 Advanced und Security 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. Praxisumgebung

Vertiefung und Abgabebeispiel zu Praxisumgebung

Eine vollständige Bearbeitung von Praxisumgebung 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 Praxisumgebung

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 Praxisumgebung

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 Praxisumgebung 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 Praxisumgebung

Dieser Abschnitt ist nicht als reine Begriffserklärung gedacht. Im Workshop wird Praxisumgebung 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 Praxisumgebung

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 Praxisumgebung

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 Praxisumgebung

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 Praxisumgebung

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.

Praxisumgebung 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. Workshop-Labs

Vertiefung und Abgabebeispiel zu Workshop-Labs

Eine vollständige Bearbeitung von Workshop-Labs 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 Workshop-Labs

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 Workshop-Labs

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 Workshop-Labs 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 Workshop-Labs

Dieser Abschnitt ist nicht als reine Begriffserklärung gedacht. Im Workshop wird Workshop-Labs 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 Workshop-Labs

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-Labs

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 Workshop-Labs

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 Workshop-Labs

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.

Workshop-Labs 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.

14. Abschlussprojekte

Vertiefung und Abgabebeispiel zu Abschlussprojekte

Eine vollständige Bearbeitung von Abschlussprojekte 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 Abschlussprojekte

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 Abschlussprojekte

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 Abschlussprojekte 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 Abschlussprojekte

Dieser Abschnitt ist nicht als reine Begriffserklärung gedacht. Im Workshop wird Abschlussprojekte 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 Abschlussprojekte

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 Abschlussprojekte

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 Abschlussprojekte

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 Abschlussprojekte

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.

Abschlussprojekte 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.

15. Bewertungsraster

Vertiefung und Abgabebeispiel zu Bewertungsraster

Eine vollständige Bearbeitung von Bewertungsraster 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 Bewertungsraster

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 Bewertungsraster

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 Bewertungsraster 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 Bewertungsraster

Dieser Abschnitt ist nicht als reine Begriffserklärung gedacht. Im Workshop wird Bewertungsraster 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 Bewertungsraster

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 Bewertungsraster

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 Bewertungsraster

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 Bewertungsraster

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.

Bewertungsraster 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.

16. Agenda-Varianten

Vertiefung und Abgabebeispiel zu Agenda-Varianten

Eine vollständige Bearbeitung von Agenda-Varianten 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 Agenda-Varianten

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 Agenda-Varianten

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 Agenda-Varianten 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 Agenda-Varianten

Dieser Abschnitt ist nicht als reine Begriffserklärung gedacht. Im Workshop wird Agenda-Varianten 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 Agenda-Varianten

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 Agenda-Varianten

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 Agenda-Varianten

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 Agenda-Varianten

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.

Agenda-Varianten 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.

17. Trainerleitfaden

Vertiefung und Abgabebeispiel zu Trainerleitfaden

Eine vollständige Bearbeitung von Trainerleitfaden 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 Trainerleitfaden

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 Trainerleitfaden

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 Trainerleitfaden 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 Trainerleitfaden

Dieser Abschnitt ist nicht als reine Begriffserklärung gedacht. Im Workshop wird Trainerleitfaden 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 Trainerleitfaden

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 Trainerleitfaden

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 Trainerleitfaden

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 Trainerleitfaden

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.

Trainerleitfaden 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.

18. Lernkontrollen

Vertiefung und Abgabebeispiel zu Lernkontrollen

Eine vollständige Bearbeitung von Lernkontrollen 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 Lernkontrollen

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 Lernkontrollen

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 Lernkontrollen 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 Lernkontrollen

Dieser Abschnitt ist nicht als reine Begriffserklärung gedacht. Im Workshop wird Lernkontrollen 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 Lernkontrollen

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 Lernkontrollen

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 Lernkontrollen

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 Lernkontrollen

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.

Lernkontrollen 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.

19. Häufige Fehlannahmen

Vertiefung und Abgabebeispiel zu Häufige Fehlannahmen

Eine vollständige Bearbeitung von Häufige Fehlannahmen 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 Häufige Fehlannahmen

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 Häufige Fehlannahmen

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 Häufige Fehlannahmen 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 Häufige Fehlannahmen

Dieser Abschnitt ist nicht als reine Begriffserklärung gedacht. Im Workshop wird Häufige Fehlannahmen 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 Häufige Fehlannahmen

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 Häufige Fehlannahmen

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 Häufige Fehlannahmen

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 Häufige Fehlannahmen

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.

Häufige Fehlannahmen 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.

20. Empfohlene Dauer

Vertiefung und Abgabebeispiel zu Empfohlene Dauer

Eine vollständige Bearbeitung von Empfohlene Dauer 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 Empfohlene Dauer

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 Empfohlene Dauer

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 Empfohlene Dauer 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 Empfohlene Dauer

Dieser Abschnitt ist nicht als reine Begriffserklärung gedacht. Im Workshop wird Empfohlene Dauer 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 Empfohlene Dauer

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 Empfohlene Dauer

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 Empfohlene Dauer

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 Empfohlene Dauer

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.

Empfohlene Dauer 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.

21. Mapping zu Praxisrollen

Vertiefung und Abgabebeispiel zu Mapping zu Praxisrollen

Eine vollständige Bearbeitung von Mapping zu Praxisrollen 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 Mapping zu Praxisrollen

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 Mapping zu Praxisrollen

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 Mapping zu Praxisrollen 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 Mapping zu Praxisrollen

Dieser Abschnitt ist nicht als reine Begriffserklärung gedacht. Im Workshop wird Mapping zu Praxisrollen 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 Mapping zu Praxisrollen

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 Mapping zu Praxisrollen

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 Mapping zu Praxisrollen

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 Mapping zu Praxisrollen

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.

Mapping zu Praxisrollen 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.

22. Weiterführende Themen

Vertiefung und Abgabebeispiel zu Weiterführende Themen

Eine vollständige Bearbeitung von Weiterführende Themen 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 Weiterführende Themen

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 Weiterführende Themen

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 Weiterführende Themen 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 Weiterführende Themen

Dieser Abschnitt ist nicht als reine Begriffserklärung gedacht. Im Workshop wird Weiterführende Themen 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 Weiterführende Themen

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 Weiterführende Themen

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 Weiterführende Themen

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 Weiterführende Themen

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.

Weiterführende Themen 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