Kommandoreferenz: Ansible · Ansible

1. Grundregeln für sicheres Arbeiten

Vertiefung und Abgabebeispiel zu Grundregeln für sicheres Arbeiten

Eine vollständige Bearbeitung von Grundregeln für sicheres Arbeiten 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 Grundregeln für sicheres Arbeiten

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 Grundregeln für sicheres Arbeiten

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 Grundregeln für sicheres Arbeiten 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 Grundregeln für sicheres Arbeiten

Dieser Abschnitt ist nicht als reine Begriffserklärung gedacht. Im Workshop wird Grundregeln für sicheres Arbeiten 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 Grundregeln für sicheres Arbeiten

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 Grundregeln für sicheres Arbeiten

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 Grundregeln für sicheres Arbeiten

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 Grundregeln für sicheres Arbeiten

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.

Grundregeln für sicheres Arbeiten 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.

Zusätzliche Kommandobeispiele:

ansible all -i inventory/hosts.yml --list-hosts
ansible all -i inventory/hosts.yml -m ansible.builtin.ping
ansible all -i inventory/hosts.yml -m ansible.builtin.setup -a "filter=ansible_distribution*"
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --limit web --tags config
ansible-vault encrypt group_vars/all/vault.yml
ansible-galaxy collection install -r collections/requirements.yml

2. Notation und Platzhalter

Vertiefung und Abgabebeispiel zu Notation und Platzhalter

Eine vollständige Bearbeitung von Notation und Platzhalter 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 Notation und Platzhalter

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 Notation und Platzhalter

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 Notation und Platzhalter 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 Notation und Platzhalter

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

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 Notation und Platzhalter

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 Notation und Platzhalter

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 Notation und Platzhalter

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.

Notation und Platzhalter 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.

Zusätzliche Kommandobeispiele:

ansible all -i inventory/hosts.yml --list-hosts
ansible all -i inventory/hosts.yml -m ansible.builtin.ping
ansible all -i inventory/hosts.yml -m ansible.builtin.setup -a "filter=ansible_distribution*"
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --limit web --tags config
ansible-vault encrypt group_vars/all/vault.yml
ansible-galaxy collection install -r collections/requirements.yml

3. Installation und Versionen

Vertiefung und Abgabebeispiel zu Installation und Versionen

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

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

Minimalartefakte für Installation und Versionen

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

Für Rollen oder Collections wird die Struktur erweitert:

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

Prüferwartung für Installation und Versionen

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

Transfer in reale Teams

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

Praxisbezug zu Installation und Versionen

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

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

Beispielablauf für Installation und Versionen

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

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

Review-Kriterien für Installation und Versionen

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

Typische Fehler bei Installation und Versionen

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

Betriebsnotiz für Installation und Versionen

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

Installation und Versionen 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.

Zusätzliche Kommandobeispiele:

ansible all -i inventory/hosts.yml --list-hosts
ansible all -i inventory/hosts.yml -m ansible.builtin.ping
ansible all -i inventory/hosts.yml -m ansible.builtin.setup -a "filter=ansible_distribution*"
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --limit web --tags config
ansible-vault encrypt group_vars/all/vault.yml
ansible-galaxy collection install -r collections/requirements.yml

4. ansible-config

Vertiefung und Abgabebeispiel zu ansible-config

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

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

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

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

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

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

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

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.

ansible-config 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.

Zusätzliche Kommandobeispiele:

ansible all -i inventory/hosts.yml --list-hosts
ansible all -i inventory/hosts.yml -m ansible.builtin.ping
ansible all -i inventory/hosts.yml -m ansible.builtin.setup -a "filter=ansible_distribution*"
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --limit web --tags config
ansible-vault encrypt group_vars/all/vault.yml
ansible-galaxy collection install -r collections/requirements.yml

5. ansible-inventory

Vertiefung und Abgabebeispiel zu ansible-inventory

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

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

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

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

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

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

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

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.

ansible-inventory 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.

Zusätzliche Kommandobeispiele:

ansible all -i inventory/hosts.yml --list-hosts
ansible all -i inventory/hosts.yml -m ansible.builtin.ping
ansible all -i inventory/hosts.yml -m ansible.builtin.setup -a "filter=ansible_distribution*"
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --limit web --tags config
ansible-vault encrypt group_vars/all/vault.yml
ansible-galaxy collection install -r collections/requirements.yml

6. Ad-hoc-Kommandos

Vertiefung und Abgabebeispiel zu Ad-hoc-Kommandos

Eine vollständige Bearbeitung von Ad-hoc-Kommandos 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 Ad-hoc-Kommandos

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 Ad-hoc-Kommandos

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 Ad-hoc-Kommandos 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 Ad-hoc-Kommandos

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

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 Ad-hoc-Kommandos

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 Ad-hoc-Kommandos

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 Ad-hoc-Kommandos

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.

Ad-hoc-Kommandos 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.

Zusätzliche Kommandobeispiele:

ansible all -i inventory/hosts.yml --list-hosts
ansible all -i inventory/hosts.yml -m ansible.builtin.ping
ansible all -i inventory/hosts.yml -m ansible.builtin.setup -a "filter=ansible_distribution*"
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --limit web --tags config
ansible-vault encrypt group_vars/all/vault.yml
ansible-galaxy collection install -r collections/requirements.yml

7. ansible-playbook

Vertiefung und Abgabebeispiel zu ansible-playbook

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

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

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

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

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

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

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

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.

ansible-playbook 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.

Zusätzliche Kommandobeispiele:

ansible all -i inventory/hosts.yml --list-hosts
ansible all -i inventory/hosts.yml -m ansible.builtin.ping
ansible all -i inventory/hosts.yml -m ansible.builtin.setup -a "filter=ansible_distribution*"
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --limit web --tags config
ansible-vault encrypt group_vars/all/vault.yml
ansible-galaxy collection install -r collections/requirements.yml

8. Syntaxcheck

Vertiefung und Abgabebeispiel zu Syntaxcheck

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

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 Syntaxcheck

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

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

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 Syntaxcheck

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 Syntaxcheck

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 Syntaxcheck

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.

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

Zusätzliche Kommandobeispiele:

ansible all -i inventory/hosts.yml --list-hosts
ansible all -i inventory/hosts.yml -m ansible.builtin.ping
ansible all -i inventory/hosts.yml -m ansible.builtin.setup -a "filter=ansible_distribution*"
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --limit web --tags config
ansible-vault encrypt group_vars/all/vault.yml
ansible-galaxy collection install -r collections/requirements.yml

9. Check Mode und Diff Mode

Vertiefung und Abgabebeispiel zu Check Mode und Diff Mode

Eine vollständige Bearbeitung von Check Mode und Diff Mode 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 Check Mode und Diff Mode

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 Check Mode und Diff Mode

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 Check Mode und Diff Mode 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 Check Mode und Diff Mode

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

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 Check Mode und Diff Mode

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 Check Mode und Diff Mode

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 Check Mode und Diff Mode

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.

Check Mode und Diff Mode 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.

Zusätzliche Kommandobeispiele:

ansible all -i inventory/hosts.yml --list-hosts
ansible all -i inventory/hosts.yml -m ansible.builtin.ping
ansible all -i inventory/hosts.yml -m ansible.builtin.setup -a "filter=ansible_distribution*"
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --limit web --tags config
ansible-vault encrypt group_vars/all/vault.yml
ansible-galaxy collection install -r collections/requirements.yml

10. Limit, Tags und Start-at-task

Vertiefung und Abgabebeispiel zu Limit, Tags und Start-at-task

Eine vollständige Bearbeitung von Limit, Tags und Start-at-task 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 Limit, Tags und Start-at-task

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 Limit, Tags und Start-at-task

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 Limit, Tags und Start-at-task 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 Limit, Tags und Start-at-task

Dieser Abschnitt ist nicht als reine Begriffserklärung gedacht. Im Workshop wird Limit, Tags und Start-at-task 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 Limit, Tags und Start-at-task

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 Limit, Tags und Start-at-task

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 Limit, Tags und Start-at-task

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 Limit, Tags und Start-at-task

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.

Limit, Tags und Start-at-task 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.

Zusätzliche Kommandobeispiele:

ansible all -i inventory/hosts.yml --list-hosts
ansible all -i inventory/hosts.yml -m ansible.builtin.ping
ansible all -i inventory/hosts.yml -m ansible.builtin.setup -a "filter=ansible_distribution*"
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --limit web --tags config
ansible-vault encrypt group_vars/all/vault.yml
ansible-galaxy collection install -r collections/requirements.yml

11. Vault-Kommandos

Vertiefung und Abgabebeispiel zu Vault-Kommandos

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

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

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

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

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

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

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

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.

Vault-Kommandos 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.

Zusätzliche Kommandobeispiele:

ansible all -i inventory/hosts.yml --list-hosts
ansible all -i inventory/hosts.yml -m ansible.builtin.ping
ansible all -i inventory/hosts.yml -m ansible.builtin.setup -a "filter=ansible_distribution*"
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --limit web --tags config
ansible-vault encrypt group_vars/all/vault.yml
ansible-galaxy collection install -r collections/requirements.yml

12. Galaxy und Collections

Vertiefung und Abgabebeispiel zu Galaxy und Collections

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

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

Galaxy und 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.

Zusätzliche Kommandobeispiele:

ansible all -i inventory/hosts.yml --list-hosts
ansible all -i inventory/hosts.yml -m ansible.builtin.ping
ansible all -i inventory/hosts.yml -m ansible.builtin.setup -a "filter=ansible_distribution*"
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --limit web --tags config
ansible-vault encrypt group_vars/all/vault.yml
ansible-galaxy collection install -r collections/requirements.yml

13. Rollen und Skeletons

Vertiefung und Abgabebeispiel zu Rollen und Skeletons

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

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

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

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

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

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

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

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 und Skeletons 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.

Zusätzliche Kommandobeispiele:

ansible all -i inventory/hosts.yml --list-hosts
ansible all -i inventory/hosts.yml -m ansible.builtin.ping
ansible all -i inventory/hosts.yml -m ansible.builtin.setup -a "filter=ansible_distribution*"
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --limit web --tags config
ansible-vault encrypt group_vars/all/vault.yml
ansible-galaxy collection install -r collections/requirements.yml

14. ansible-lint

Vertiefung und Abgabebeispiel zu ansible-lint

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

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

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

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

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

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

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

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.

ansible-lint 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.

Zusätzliche Kommandobeispiele:

ansible all -i inventory/hosts.yml --list-hosts
ansible all -i inventory/hosts.yml -m ansible.builtin.ping
ansible all -i inventory/hosts.yml -m ansible.builtin.setup -a "filter=ansible_distribution*"
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --limit web --tags config
ansible-vault encrypt group_vars/all/vault.yml
ansible-galaxy collection install -r collections/requirements.yml

15. Molecule

Vertiefung und Abgabebeispiel zu Molecule

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

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

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.

Zusätzliche Kommandobeispiele:

ansible all -i inventory/hosts.yml --list-hosts
ansible all -i inventory/hosts.yml -m ansible.builtin.ping
ansible all -i inventory/hosts.yml -m ansible.builtin.setup -a "filter=ansible_distribution*"
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --limit web --tags config
ansible-vault encrypt group_vars/all/vault.yml
ansible-galaxy collection install -r collections/requirements.yml

16. Runner und AWX-Einordnung

Vertiefung und Abgabebeispiel zu Runner und AWX-Einordnung

Eine vollständige Bearbeitung von Runner und AWX-Einordnung 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 Runner und AWX-Einordnung

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 Runner und AWX-Einordnung

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 Runner und AWX-Einordnung 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 Runner und AWX-Einordnung

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

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 Runner und AWX-Einordnung

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 Runner und AWX-Einordnung

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 Runner und AWX-Einordnung

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.

Runner und AWX-Einordnung 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.

Zusätzliche Kommandobeispiele:

ansible all -i inventory/hosts.yml --list-hosts
ansible all -i inventory/hosts.yml -m ansible.builtin.ping
ansible all -i inventory/hosts.yml -m ansible.builtin.setup -a "filter=ansible_distribution*"
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --limit web --tags config
ansible-vault encrypt group_vars/all/vault.yml
ansible-galaxy collection install -r collections/requirements.yml

17. JSON, YAML und Ausgabeformate

Vertiefung und Abgabebeispiel zu JSON, YAML und Ausgabeformate

Eine vollständige Bearbeitung von JSON, YAML und Ausgabeformate 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 JSON, YAML und Ausgabeformate

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 JSON, YAML und Ausgabeformate

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 JSON, YAML und Ausgabeformate 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 JSON, YAML und Ausgabeformate

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

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 JSON, YAML und Ausgabeformate

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 JSON, YAML und Ausgabeformate

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 JSON, YAML und Ausgabeformate

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.

JSON, YAML und Ausgabeformate 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.

Zusätzliche Kommandobeispiele:

ansible all -i inventory/hosts.yml --list-hosts
ansible all -i inventory/hosts.yml -m ansible.builtin.ping
ansible all -i inventory/hosts.yml -m ansible.builtin.setup -a "filter=ansible_distribution*"
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --limit web --tags config
ansible-vault encrypt group_vars/all/vault.yml
ansible-galaxy collection install -r collections/requirements.yml

18. Troubleshooting-Kommandos

Vertiefung und Abgabebeispiel zu Troubleshooting-Kommandos

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

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

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

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

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

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

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

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.

Troubleshooting-Kommandos 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.

Zusätzliche Kommandobeispiele:

ansible all -i inventory/hosts.yml --list-hosts
ansible all -i inventory/hosts.yml -m ansible.builtin.ping
ansible all -i inventory/hosts.yml -m ansible.builtin.setup -a "filter=ansible_distribution*"
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --limit web --tags config
ansible-vault encrypt group_vars/all/vault.yml
ansible-galaxy collection install -r collections/requirements.yml

19. Betriebs-Checklisten

Vertiefung und Abgabebeispiel zu Betriebs-Checklisten

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

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

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

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

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

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

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

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.

Betriebs-Checklisten 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.

Zusätzliche Kommandobeispiele:

ansible all -i inventory/hosts.yml --list-hosts
ansible all -i inventory/hosts.yml -m ansible.builtin.ping
ansible all -i inventory/hosts.yml -m ansible.builtin.setup -a "filter=ansible_distribution*"
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --limit web --tags config
ansible-vault encrypt group_vars/all/vault.yml
ansible-galaxy collection install -r collections/requirements.yml

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