Musterlösung: Ansible-Prüfung 03 – Professional · Ansible

1. Hinweise zur Verwendung

Vertiefung und Abgabebeispiel zu Hinweise zur Verwendung

Eine vollständige Bearbeitung von Hinweise zur Verwendung 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 Hinweise zur Verwendung

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 Hinweise zur Verwendung

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 Hinweise zur Verwendung 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 Hinweise zur Verwendung

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

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 Hinweise zur Verwendung

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 Hinweise zur Verwendung

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 Hinweise zur Verwendung

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.

Diese Musterlösung zeigt Erwartungshorizonte. Konkrete Hostnamen, Pfade und Ausgaben dürfen im Lab abweichen, solange Scope, Sicherheit und Validierung stimmen.

2. Teil A: Musterantworten

Vertiefung und Abgabebeispiel zu Teil A: Musterantworten

Eine vollständige Bearbeitung von Teil A: Musterantworten 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 Teil A: Musterantworten

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 Teil A: Musterantworten

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 Teil A: Musterantworten 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 Teil A: Musterantworten

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

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 Teil A: Musterantworten

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 Teil A: Musterantworten

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 Teil A: Musterantworten

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.