Best Practices: Ansible · Ansible

1. Ziel

Vertiefung und Abgabebeispiel zu Ziel

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

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

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

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

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

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

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

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

Vertiefung und Abgabebeispiel zu Projektstruktur

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

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 Projektstruktur

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

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

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 Projektstruktur

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 Projektstruktur

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 Projektstruktur

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.

Projektstruktur 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. Inventory-Design

Vertiefung und Abgabebeispiel zu Inventory-Design

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

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 Inventory-Design

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 Inventory-Design 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 Inventory-Design

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

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 Inventory-Design

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 Inventory-Design

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 Inventory-Design

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.

Inventory-Design 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. Playbook-Design

Vertiefung und Abgabebeispiel zu Playbook-Design

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

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 Playbook-Design

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 Playbook-Design 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 Playbook-Design

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

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 Playbook-Design

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 Playbook-Design

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 Playbook-Design

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.

Playbook-Design 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. Modulwahl

Vertiefung und Abgabebeispiel zu Modulwahl

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

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 Modulwahl

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

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

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 Modulwahl

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 Modulwahl

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 Modulwahl

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.

Modulwahl 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. Idempotenz

Vertiefung und Abgabebeispiel zu Idempotenz

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

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 Idempotenz

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

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

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 Idempotenz

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 Idempotenz

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 Idempotenz

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.

Idempotenz 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. Variablenmodell

Vertiefung und Abgabebeispiel zu Variablenmodell

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

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 Variablenmodell

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

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

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 Variablenmodell

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 Variablenmodell

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 Variablenmodell

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.

Variablenmodell 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. Templates

Vertiefung und Abgabebeispiel zu Templates

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

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 Templates

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

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

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 Templates

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 Templates

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 Templates

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.

Templates 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. Rollen

Vertiefung und Abgabebeispiel zu Rollen

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

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

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.

10. Collections

Vertiefung und Abgabebeispiel zu Collections

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

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 Collections

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

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

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 Collections

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 Collections

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 Collections

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.

Collections 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. Secrets

Vertiefung und Abgabebeispiel zu Secrets

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

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 Secrets

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

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

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 Secrets

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 Secrets

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 Secrets

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.

Secrets 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. Privilege Escalation

Vertiefung und Abgabebeispiel zu Privilege Escalation

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

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 Privilege Escalation

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 Privilege Escalation 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 Privilege Escalation

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

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 Privilege Escalation

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 Privilege Escalation

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 Privilege Escalation

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.

Privilege Escalation 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. CI und Linting

Vertiefung und Abgabebeispiel zu CI und Linting

Eine vollständige Bearbeitung von CI und Linting 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 CI und Linting

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 CI und Linting

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 CI und Linting 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 CI und Linting

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

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 CI und Linting

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 CI und Linting

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 CI und Linting

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.

CI und Linting 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. Testing mit Molecule

Vertiefung und Abgabebeispiel zu Testing mit Molecule

Eine vollständige Bearbeitung von Testing mit Molecule 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 Testing mit Molecule

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 Testing mit Molecule

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 Testing mit Molecule 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 Testing mit Molecule

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

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 Testing mit Molecule

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 Testing mit Molecule

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 Testing mit Molecule

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.

Testing mit Molecule 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. Runbooks

Vertiefung und Abgabebeispiel zu Runbooks

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

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 Runbooks

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

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

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 Runbooks

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 Runbooks

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 Runbooks

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.

Runbooks 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. Anti-Patterns

Vertiefung und Abgabebeispiel zu Anti-Patterns

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

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 Anti-Patterns

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 Anti-Patterns 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 Anti-Patterns

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

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 Anti-Patterns

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 Anti-Patterns

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 Anti-Patterns

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.

Anti-Patterns 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. Review-Checkliste

Vertiefung und Abgabebeispiel zu Review-Checkliste

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

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 Review-Checkliste

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 Review-Checkliste 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 Review-Checkliste

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

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 Review-Checkliste

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 Review-Checkliste

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 Review-Checkliste

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.

Review-Checkliste 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