1. Ziel

Vertiefung und Abgabebeispiel zu Ziel

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

Minimalartefakte für Ziel

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

Für Rollen oder Collections wird die Struktur erweitert:

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

Prüferwartung für Ziel

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

Transfer in reale Teams

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

Praxisbezug zu Ziel

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

Beispielablauf für Ziel

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

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

Review-Kriterien für Ziel

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

Typische Fehler bei Ziel

Betriebsnotiz für Ziel

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

Diese Übungen ergänzen den Workshop Intermediate. Sie führen von Erklärung über Umsetzung zu Validierung und Musterlösung.

2. Ausgangssituation

Vertiefung und Abgabebeispiel zu Ausgangssituation

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

Minimalartefakte für Ausgangssituation

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 Ausgangssituation

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

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

Beispielablauf für Ausgangssituation

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 Ausgangssituation

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

Betriebsnotiz für Ausgangssituation

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.

Du arbeitest in einem isolierten Ansible-Lab. Nutze localhost oder dedizierte Lab-VMs. Produktive Hosts, echte Secrets und Kundendaten sind ausgeschlossen.

3. Arbeitsregeln

Vertiefung und Abgabebeispiel zu Arbeitsregeln

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

Minimalartefakte für Arbeitsregeln

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 Arbeitsregeln

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

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

Beispielablauf für Arbeitsregeln

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 Arbeitsregeln

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

Betriebsnotiz für Arbeitsregeln

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.

1. Prüfe Inventory und Scope vor jeder Änderung.
2. Nutze Syntaxcheck, Check Mode und Diff Mode.
3. Begründe become.
4. Dokumentiere Play Recap und zweiten Lauf.
5. Räume Lab-Artefakte zurück.

4. Aufgabenübersicht

Vertiefung und Abgabebeispiel zu Aufgabenübersicht

Eine vollständige Bearbeitung von Aufgabenübersicht 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.

Minimalartefakte für Aufgabenübersicht

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 Aufgabenübersicht

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 Aufgabenübersicht 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 Aufgabenübersicht

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

Beispielablauf für Aufgabenübersicht

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 Aufgabenübersicht

• 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 Aufgabenübersicht

Betriebsnotiz für Aufgabenübersicht

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.

5. Teil A: Aufgaben

Vertiefung und Abgabebeispiel zu Teil A: Aufgaben

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

Minimalartefakte für Teil A: Aufgaben

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

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

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

Beispielablauf für Teil A: Aufgaben

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

• 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: Aufgaben

Betriebsnotiz für Teil A: Aufgaben

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.

Aufgabe 1: Variablenpräzedenz

Vertiefung und Abgabebeispiel zu Aufgabe 1: Variablenpräzedenz

Eine vollständige Bearbeitung von Aufgabe 1: Variablenpräzedenz 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.

Minimalartefakte für Aufgabe 1: Variablenpräzedenz

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 Aufgabe 1: Variablenpräzedenz

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 Aufgabe 1: Variablenpräzedenz 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 Aufgabe 1: Variablenpräzedenz

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

Beispielablauf für Aufgabe 1: Variablenpräzedenz

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 Aufgabe 1: Variablenpräzedenz

• 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 Aufgabe 1: Variablenpräzedenz

Betriebsnotiz für Aufgabe 1: Variablenpräzedenz

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

Ziel

Du wendest Variablenpräzedenz in einem kleinen, ungefährlichen Lab an und dokumentierst Scope, Umsetzung, Ergebnis und Rückbau.

Arbeitsauftrag

1. Erstelle oder prüfe ein passendes Inventory.
2. Beweise den Zielscope mit --list-hosts.
3. Erstelle ein Playbook oder passe ein bestehendes Beispiel an.
4. Nutze ein geeignetes ansible.builtin-Modul.
5. Führe Syntaxcheck, Check Mode, echten Lauf und zweiten Lauf aus.
6. Dokumentiere Play Recap, relevante Ausgabe und eine kurze Bewertung.

Erwartetes Ergebnis

• Das Playbook ist syntaktisch korrekt.
• Die Zielhosts sind eindeutig.
• Der zweite Lauf meldet keine unnötigen Änderungen.
• Risiken und Grenzen sind dokumentiert.

Aufgabe 2: Facts

Vertiefung und Abgabebeispiel zu Aufgabe 2: Facts

Eine vollständige Bearbeitung von Aufgabe 2: Facts 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.

Minimalartefakte für Aufgabe 2: Facts

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 Aufgabe 2: Facts

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 Aufgabe 2: Facts 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 Aufgabe 2: Facts

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

Beispielablauf für Aufgabe 2: Facts

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 Aufgabe 2: Facts

• 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 Aufgabe 2: Facts

Betriebsnotiz für Aufgabe 2: Facts

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

Ziel

Du wendest Facts in einem kleinen, ungefährlichen Lab an und dokumentierst Scope, Umsetzung, Ergebnis und Rückbau.

Arbeitsauftrag

1. Erstelle oder prüfe ein passendes Inventory.
2. Beweise den Zielscope mit --list-hosts.
3. Erstelle ein Playbook oder passe ein bestehendes Beispiel an.
4. Nutze ein geeignetes ansible.builtin-Modul.
5. Führe Syntaxcheck, Check Mode, echten Lauf und zweiten Lauf aus.
6. Dokumentiere Play Recap, relevante Ausgabe und eine kurze Bewertung.

Erwartetes Ergebnis

• Das Playbook ist syntaktisch korrekt.
• Die Zielhosts sind eindeutig.
• Der zweite Lauf meldet keine unnötigen Änderungen.
• Risiken und Grenzen sind dokumentiert.

Aufgabe 3: Templates

Vertiefung und Abgabebeispiel zu Aufgabe 3: Templates

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

Minimalartefakte für Aufgabe 3: Templates

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

Für Rollen oder Collections wird die Struktur erweitert:

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

Prüferwartung für Aufgabe 3: Templates

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

Transfer in reale Teams

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

Praxisbezug zu Aufgabe 3: Templates

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

Beispielablauf für Aufgabe 3: Templates

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

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

Review-Kriterien für Aufgabe 3: Templates

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

Typische Fehler bei Aufgabe 3: Templates

Betriebsnotiz für Aufgabe 3: Templates

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

Ziel

Du wendest Templates in einem kleinen, ungefährlichen Lab an und dokumentierst Scope, Umsetzung, Ergebnis und Rückbau.

Arbeitsauftrag

1. Erstelle oder prüfe ein passendes Inventory.
2. Beweise den Zielscope mit --list-hosts.
3. Erstelle ein Playbook oder passe ein bestehendes Beispiel an.
4. Nutze ein geeignetes ansible.builtin-Modul.
5. Führe Syntaxcheck, Check Mode, echten Lauf und zweiten Lauf aus.
6. Dokumentiere Play Recap, relevante Ausgabe und eine kurze Bewertung.

Erwartetes Ergebnis

• Das Playbook ist syntaktisch korrekt.
• Die Zielhosts sind eindeutig.
• Der zweite Lauf meldet keine unnötigen Änderungen.
• Risiken und Grenzen sind dokumentiert.

Aufgabe 4: Rollen

Vertiefung und Abgabebeispiel zu Aufgabe 4: Rollen

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

Minimalartefakte für Aufgabe 4: Rollen

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

Für Rollen oder Collections wird die Struktur erweitert:

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

Prüferwartung für Aufgabe 4: Rollen

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

Transfer in reale Teams

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

Praxisbezug zu Aufgabe 4: Rollen

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

Beispielablauf für Aufgabe 4: Rollen

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

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

Review-Kriterien für Aufgabe 4: Rollen

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

Typische Fehler bei Aufgabe 4: Rollen

Betriebsnotiz für Aufgabe 4: Rollen

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

Ziel

Du wendest Rollen in einem kleinen, ungefährlichen Lab an und dokumentierst Scope, Umsetzung, Ergebnis und Rückbau.

Arbeitsauftrag

1. Erstelle oder prüfe ein passendes Inventory.
2. Beweise den Zielscope mit --list-hosts.
3. Erstelle ein Playbook oder passe ein bestehendes Beispiel an.
4. Nutze ein geeignetes ansible.builtin-Modul.
5. Führe Syntaxcheck, Check Mode, echten Lauf und zweiten Lauf aus.
6. Dokumentiere Play Recap, relevante Ausgabe und eine kurze Bewertung.

Erwartetes Ergebnis

• Das Playbook ist syntaktisch korrekt.
• Die Zielhosts sind eindeutig.
• Der zweite Lauf meldet keine unnötigen Änderungen.
• Risiken und Grenzen sind dokumentiert.

Aufgabe 5: Includes

Vertiefung und Abgabebeispiel zu Aufgabe 5: Includes

Eine vollständige Bearbeitung von Aufgabe 5: Includes 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.

Minimalartefakte für Aufgabe 5: Includes

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 Aufgabe 5: Includes

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 Aufgabe 5: Includes 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 Aufgabe 5: Includes

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

Beispielablauf für Aufgabe 5: Includes

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 Aufgabe 5: Includes

• 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 Aufgabe 5: Includes

Betriebsnotiz für Aufgabe 5: Includes

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

Ziel

Du wendest Includes in einem kleinen, ungefährlichen Lab an und dokumentierst Scope, Umsetzung, Ergebnis und Rückbau.

Arbeitsauftrag

1. Erstelle oder prüfe ein passendes Inventory.
2. Beweise den Zielscope mit --list-hosts.
3. Erstelle ein Playbook oder passe ein bestehendes Beispiel an.
4. Nutze ein geeignetes ansible.builtin-Modul.
5. Führe Syntaxcheck, Check Mode, echten Lauf und zweiten Lauf aus.
6. Dokumentiere Play Recap, relevante Ausgabe und eine kurze Bewertung.

Erwartetes Ergebnis

• Das Playbook ist syntaktisch korrekt.
• Die Zielhosts sind eindeutig.
• Der zweite Lauf meldet keine unnötigen Änderungen.
• Risiken und Grenzen sind dokumentiert.

Aufgabe 6: Imports

Vertiefung und Abgabebeispiel zu Aufgabe 6: Imports

Eine vollständige Bearbeitung von Aufgabe 6: Imports 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.

Minimalartefakte für Aufgabe 6: Imports

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 Aufgabe 6: Imports

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 Aufgabe 6: Imports 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 Aufgabe 6: Imports

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

Beispielablauf für Aufgabe 6: Imports

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 Aufgabe 6: Imports

• 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 Aufgabe 6: Imports

Betriebsnotiz für Aufgabe 6: Imports

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

Ziel

Du wendest Imports in einem kleinen, ungefährlichen Lab an und dokumentierst Scope, Umsetzung, Ergebnis und Rückbau.

Arbeitsauftrag

1. Erstelle oder prüfe ein passendes Inventory.
2. Beweise den Zielscope mit --list-hosts.
3. Erstelle ein Playbook oder passe ein bestehendes Beispiel an.
4. Nutze ein geeignetes ansible.builtin-Modul.
5. Führe Syntaxcheck, Check Mode, echten Lauf und zweiten Lauf aus.
6. Dokumentiere Play Recap, relevante Ausgabe und eine kurze Bewertung.

Erwartetes Ergebnis

• Das Playbook ist syntaktisch korrekt.
• Die Zielhosts sind eindeutig.
• Der zweite Lauf meldet keine unnötigen Änderungen.
• Risiken und Grenzen sind dokumentiert.

Aufgabe 7: Blocks

Vertiefung und Abgabebeispiel zu Aufgabe 7: Blocks

Eine vollständige Bearbeitung von Aufgabe 7: Blocks 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.

Minimalartefakte für Aufgabe 7: Blocks

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 Aufgabe 7: Blocks

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 Aufgabe 7: Blocks 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 Aufgabe 7: Blocks

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

Beispielablauf für Aufgabe 7: Blocks

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 Aufgabe 7: Blocks

• 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 Aufgabe 7: Blocks

Betriebsnotiz für Aufgabe 7: Blocks

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

Ziel

Du wendest Blocks in einem kleinen, ungefährlichen Lab an und dokumentierst Scope, Umsetzung, Ergebnis und Rückbau.

Arbeitsauftrag

1. Erstelle oder prüfe ein passendes Inventory.
2. Beweise den Zielscope mit --list-hosts.
3. Erstelle ein Playbook oder passe ein bestehendes Beispiel an.
4. Nutze ein geeignetes ansible.builtin-Modul.
5. Führe Syntaxcheck, Check Mode, echten Lauf und zweiten Lauf aus.
6. Dokumentiere Play Recap, relevante Ausgabe und eine kurze Bewertung.

Erwartetes Ergebnis

• Das Playbook ist syntaktisch korrekt.
• Die Zielhosts sind eindeutig.
• Der zweite Lauf meldet keine unnötigen Änderungen.
• Risiken und Grenzen sind dokumentiert.

Aufgabe 8: Rescue

Vertiefung und Abgabebeispiel zu Aufgabe 8: Rescue

Eine vollständige Bearbeitung von Aufgabe 8: Rescue 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.

Minimalartefakte für Aufgabe 8: Rescue

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 Aufgabe 8: Rescue

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 Aufgabe 8: Rescue 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 Aufgabe 8: Rescue

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

Beispielablauf für Aufgabe 8: Rescue

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 Aufgabe 8: Rescue

• 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 Aufgabe 8: Rescue

Betriebsnotiz für Aufgabe 8: Rescue

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

Ziel

Du wendest Rescue in einem kleinen, ungefährlichen Lab an und dokumentierst Scope, Umsetzung, Ergebnis und Rückbau.

Arbeitsauftrag

1. Erstelle oder prüfe ein passendes Inventory.
2. Beweise den Zielscope mit --list-hosts.
3. Erstelle ein Playbook oder passe ein bestehendes Beispiel an.
4. Nutze ein geeignetes ansible.builtin-Modul.
5. Führe Syntaxcheck, Check Mode, echten Lauf und zweiten Lauf aus.
6. Dokumentiere Play Recap, relevante Ausgabe und eine kurze Bewertung.

Erwartetes Ergebnis

• Das Playbook ist syntaktisch korrekt.
• Die Zielhosts sind eindeutig.
• Der zweite Lauf meldet keine unnötigen Änderungen.
• Risiken und Grenzen sind dokumentiert.

6. Teil B: Musterlösungen

Vertiefung und Abgabebeispiel zu Teil B: Musterlösungen

Eine vollständige Bearbeitung von Teil B: Musterlösungen 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.

Minimalartefakte für Teil B: Musterlösungen

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 B: Musterlösungen

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 B: Musterlösungen 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 B: Musterlösungen

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

Beispielablauf für Teil B: Musterlösungen

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 B: Musterlösungen

• 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 B: Musterlösungen

Betriebsnotiz für Teil B: Musterlösungen

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.

Musterlösung 1: Variablenpräzedenz

Vertiefung und Abgabebeispiel zu Musterlösung 1: Variablenpräzedenz

Eine vollständige Bearbeitung von Musterlösung 1: Variablenpräzedenz 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.

Minimalartefakte für Musterlösung 1: Variablenpräzedenz

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 Musterlösung 1: Variablenpräzedenz

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 Musterlösung 1: Variablenpräzedenz 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 Musterlösung 1: Variablenpräzedenz

Dieser Abschnitt ist nicht als reine Begriffserklärung gedacht. Im Workshop wird Musterlösung 1: Variablenpräzedenz 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.

Beispielablauf für Musterlösung 1: Variablenpräzedenz

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 Musterlösung 1: Variablenpräzedenz

• 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 Musterlösung 1: Variablenpräzedenz

Betriebsnotiz für Musterlösung 1: Variablenpräzedenz

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.

Eine gute Lösung zeigt zuerst den Scope:

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

Danach folgen Syntaxcheck und Vorschau:

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

Der echte Lauf wird mit einem zweiten Lauf verglichen. Abweichungen sind akzeptabel, wenn sie technisch begründet sind, zum Beispiel wenn ein Modul Check Mode nur teilweise unterstützt. Secrets werden nicht ausgegeben und nicht in Git gespeichert.

Musterlösung 2: Facts

Vertiefung und Abgabebeispiel zu Musterlösung 2: Facts

Eine vollständige Bearbeitung von Musterlösung 2: Facts 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.

Minimalartefakte für Musterlösung 2: Facts

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 Musterlösung 2: Facts

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 Musterlösung 2: Facts 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 Musterlösung 2: Facts

Dieser Abschnitt ist nicht als reine Begriffserklärung gedacht. Im Workshop wird Musterlösung 2: Facts 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.

Beispielablauf für Musterlösung 2: Facts

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 Musterlösung 2: Facts

• 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 Musterlösung 2: Facts

Betriebsnotiz für Musterlösung 2: Facts

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.

Eine gute Lösung zeigt zuerst den Scope:

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

Danach folgen Syntaxcheck und Vorschau:

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

Der echte Lauf wird mit einem zweiten Lauf verglichen. Abweichungen sind akzeptabel, wenn sie technisch begründet sind, zum Beispiel wenn ein Modul Check Mode nur teilweise unterstützt. Secrets werden nicht ausgegeben und nicht in Git gespeichert.

Musterlösung 3: Templates

Vertiefung und Abgabebeispiel zu Musterlösung 3: Templates

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

Minimalartefakte für Musterlösung 3: Templates

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

Für Rollen oder Collections wird die Struktur erweitert:

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

Prüferwartung für Musterlösung 3: Templates

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

Transfer in reale Teams

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

Praxisbezug zu Musterlösung 3: Templates

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

Beispielablauf für Musterlösung 3: Templates

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

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

Review-Kriterien für Musterlösung 3: Templates

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

Typische Fehler bei Musterlösung 3: Templates

Betriebsnotiz für Musterlösung 3: Templates

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

Eine gute Lösung zeigt zuerst den Scope:

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

Danach folgen Syntaxcheck und Vorschau:

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

Der echte Lauf wird mit einem zweiten Lauf verglichen. Abweichungen sind akzeptabel, wenn sie technisch begründet sind, zum Beispiel wenn ein Modul Check Mode nur teilweise unterstützt. Secrets werden nicht ausgegeben und nicht in Git gespeichert.

Musterlösung 4: Rollen

Vertiefung und Abgabebeispiel zu Musterlösung 4: Rollen

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

Minimalartefakte für Musterlösung 4: Rollen

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

Für Rollen oder Collections wird die Struktur erweitert:

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

Prüferwartung für Musterlösung 4: Rollen

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

Transfer in reale Teams

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

Praxisbezug zu Musterlösung 4: Rollen

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

Beispielablauf für Musterlösung 4: Rollen

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

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

Review-Kriterien für Musterlösung 4: Rollen

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

Typische Fehler bei Musterlösung 4: Rollen

Betriebsnotiz für Musterlösung 4: Rollen

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

Eine gute Lösung zeigt zuerst den Scope:

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

Danach folgen Syntaxcheck und Vorschau:

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

Der echte Lauf wird mit einem zweiten Lauf verglichen. Abweichungen sind akzeptabel, wenn sie technisch begründet sind, zum Beispiel wenn ein Modul Check Mode nur teilweise unterstützt. Secrets werden nicht ausgegeben und nicht in Git gespeichert.

Musterlösung 5: Includes

Vertiefung und Abgabebeispiel zu Musterlösung 5: Includes

Eine vollständige Bearbeitung von Musterlösung 5: Includes 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.

Minimalartefakte für Musterlösung 5: Includes

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 Musterlösung 5: Includes

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 Musterlösung 5: Includes 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 Musterlösung 5: Includes

Dieser Abschnitt ist nicht als reine Begriffserklärung gedacht. Im Workshop wird Musterlösung 5: Includes 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.

Beispielablauf für Musterlösung 5: Includes

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 Musterlösung 5: Includes

• 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 Musterlösung 5: Includes

Betriebsnotiz für Musterlösung 5: Includes

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.

Eine gute Lösung zeigt zuerst den Scope:

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

Danach folgen Syntaxcheck und Vorschau:

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

Der echte Lauf wird mit einem zweiten Lauf verglichen. Abweichungen sind akzeptabel, wenn sie technisch begründet sind, zum Beispiel wenn ein Modul Check Mode nur teilweise unterstützt. Secrets werden nicht ausgegeben und nicht in Git gespeichert.

Musterlösung 6: Imports

Vertiefung und Abgabebeispiel zu Musterlösung 6: Imports

Eine vollständige Bearbeitung von Musterlösung 6: Imports 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.

Minimalartefakte für Musterlösung 6: Imports

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 Musterlösung 6: Imports

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 Musterlösung 6: Imports 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 Musterlösung 6: Imports

Dieser Abschnitt ist nicht als reine Begriffserklärung gedacht. Im Workshop wird Musterlösung 6: Imports 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.

Beispielablauf für Musterlösung 6: Imports

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 Musterlösung 6: Imports

• 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 Musterlösung 6: Imports

Betriebsnotiz für Musterlösung 6: Imports

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.

Eine gute Lösung zeigt zuerst den Scope:

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

Danach folgen Syntaxcheck und Vorschau:

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

Der echte Lauf wird mit einem zweiten Lauf verglichen. Abweichungen sind akzeptabel, wenn sie technisch begründet sind, zum Beispiel wenn ein Modul Check Mode nur teilweise unterstützt. Secrets werden nicht ausgegeben und nicht in Git gespeichert.

Musterlösung 7: Blocks

Vertiefung und Abgabebeispiel zu Musterlösung 7: Blocks

Eine vollständige Bearbeitung von Musterlösung 7: Blocks 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.

Minimalartefakte für Musterlösung 7: Blocks

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 Musterlösung 7: Blocks

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 Musterlösung 7: Blocks 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 Musterlösung 7: Blocks

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

Beispielablauf für Musterlösung 7: Blocks

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 Musterlösung 7: Blocks

• 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 Musterlösung 7: Blocks

Betriebsnotiz für Musterlösung 7: Blocks

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.

Eine gute Lösung zeigt zuerst den Scope:

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

Danach folgen Syntaxcheck und Vorschau:

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

Der echte Lauf wird mit einem zweiten Lauf verglichen. Abweichungen sind akzeptabel, wenn sie technisch begründet sind, zum Beispiel wenn ein Modul Check Mode nur teilweise unterstützt. Secrets werden nicht ausgegeben und nicht in Git gespeichert.

Musterlösung 8: Rescue

Vertiefung und Abgabebeispiel zu Musterlösung 8: Rescue

Eine vollständige Bearbeitung von Musterlösung 8: Rescue 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.

Minimalartefakte für Musterlösung 8: Rescue

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 Musterlösung 8: Rescue

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 Musterlösung 8: Rescue 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 Musterlösung 8: Rescue

Dieser Abschnitt ist nicht als reine Begriffserklärung gedacht. Im Workshop wird Musterlösung 8: Rescue 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.

Beispielablauf für Musterlösung 8: Rescue

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 Musterlösung 8: Rescue

• 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 Musterlösung 8: Rescue

Betriebsnotiz für Musterlösung 8: Rescue

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.

Eine gute Lösung zeigt zuerst den Scope:

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

Danach folgen Syntaxcheck und Vorschau:

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

Der echte Lauf wird mit einem zweiten Lauf verglichen. Abweichungen sind akzeptabel, wenn sie technisch begründet sind, zum Beispiel wenn ein Modul Check Mode nur teilweise unterstützt. Secrets werden nicht ausgegeben und nicht in Git gespeichert.

7. Bewertungsraster

Vertiefung und Abgabebeispiel zu Bewertungsraster

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

Minimalartefakte für Bewertungsraster

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

Für Rollen oder Collections wird die Struktur erweitert:

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

Prüferwartung für Bewertungsraster

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

Transfer in reale Teams

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

Praxisbezug zu Bewertungsraster

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

Beispielablauf für Bewertungsraster

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

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

Review-Kriterien für Bewertungsraster

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

Typische Fehler bei Bewertungsraster

Betriebsnotiz für Bewertungsraster

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

8. Rückbau

Vertiefung und Abgabebeispiel zu Rückbau

Eine vollständige Bearbeitung von Rückbau 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.

Minimalartefakte für Rückbau

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 Rückbau

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 Rückbau 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 Rückbau

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

Beispielablauf für Rückbau

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 Rückbau

• 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 Rückbau

Betriebsnotiz für Rückbau

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.

Marker-Dateien unter /tmp, Dummy-Inventories und Lab-Artefakte werden entfernt oder klar als ungefährliche Übungsartefakte belassen.