1. Gesamtarchitektur

Vertiefung und Abgabebeispiel zu Gesamtarchitektur

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

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 Gesamtarchitektur

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

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

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 Gesamtarchitektur

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

Betriebsnotiz für Gesamtarchitektur

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.

Gesamtarchitektur ist ein praktischer Baustein des Ansible-Workshops. Entscheidend ist, dass der gewünschte Zustand nicht nur beschrieben, sondern vor und nach der Ausführung überprüft wird. Ein guter Ansible-Arbeitsablauf beantwortet immer vier Fragen: Welche Hosts sind betroffen, welche Änderung wird durchgeführt, welche Rechte werden dafür benötigt und wie wird der Erfolg gemessen?

Typische Kommandos:

ansible --version
ansible-config dump --only-changed
ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff

Für Reviews gilt: Ein Playbook ist erst dann gut genug, wenn es seine Zielgruppe beweist, seine Datenquellen offenlegt, sensible Werte schützt, Fehlerpfade beschreibt und nach einem zweiten Lauf stabil bleibt. Wenn ein Modul Check Mode oder Diff Mode nicht vollständig unterstützt, muss die Einschränkung im Runbook stehen.

Typische Fehler in diesem Bereich sind zu breite Patterns wie all, unklare Variablenquellen, Shell-Workarounds ohne Idempotenz, Secrets in Debug-Ausgaben, fehlende Rollback-Notiz und fehlende Trennung zwischen Lab- und Produktionsinventory.

flowchart LR
  user[Operator] --> control[Control Node]
  control --> inventory[Inventory]
  control --> playbook[Playbook]
  playbook --> tasks[Tasks]
  tasks --> modules[Modules]
  modules --> target[Managed Nodes]
  control --> evidence[Logs and Evidence]

2. Ausführungsablauf

Vertiefung und Abgabebeispiel zu Ausführungsablauf

Eine vollständige Bearbeitung von Ausführungsablauf 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 Ausführungsablauf

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 Ausführungsablauf

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 Ausführungsablauf 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 Ausführungsablauf

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

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 Ausführungsablauf

• 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 Ausführungsablauf

Betriebsnotiz für Ausführungsablauf

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.

Ausführungsablauf ist ein praktischer Baustein des Ansible-Workshops. Entscheidend ist, dass der gewünschte Zustand nicht nur beschrieben, sondern vor und nach der Ausführung überprüft wird. Ein guter Ansible-Arbeitsablauf beantwortet immer vier Fragen: Welche Hosts sind betroffen, welche Änderung wird durchgeführt, welche Rechte werden dafür benötigt und wie wird der Erfolg gemessen?

Typische Kommandos:

ansible --version
ansible-config dump --only-changed
ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff

Für Reviews gilt: Ein Playbook ist erst dann gut genug, wenn es seine Zielgruppe beweist, seine Datenquellen offenlegt, sensible Werte schützt, Fehlerpfade beschreibt und nach einem zweiten Lauf stabil bleibt. Wenn ein Modul Check Mode oder Diff Mode nicht vollständig unterstützt, muss die Einschränkung im Runbook stehen.

Typische Fehler in diesem Bereich sind zu breite Patterns wie all, unklare Variablenquellen, Shell-Workarounds ohne Idempotenz, Secrets in Debug-Ausgaben, fehlende Rollback-Notiz und fehlende Trennung zwischen Lab- und Produktionsinventory.

flowchart LR
  user[Operator] --> control[Control Node]
  control --> inventory[Inventory]
  control --> playbook[Playbook]
  playbook --> tasks[Tasks]
  tasks --> modules[Modules]
  modules --> target[Managed Nodes]
  control --> evidence[Logs and Evidence]

3. Inventory-Modell

Vertiefung und Abgabebeispiel zu Inventory-Modell

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

Minimalartefakte für Inventory-Modell

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

Für Rollen oder Collections wird die Struktur erweitert:

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

Prüferwartung für Inventory-Modell

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

Transfer in reale Teams

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

Praxisbezug zu Inventory-Modell

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

Beispielablauf für Inventory-Modell

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

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

Review-Kriterien für Inventory-Modell

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

Typische Fehler bei Inventory-Modell

Betriebsnotiz für Inventory-Modell

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

Inventory-Modell ist ein praktischer Baustein des Ansible-Workshops. Entscheidend ist, dass der gewünschte Zustand nicht nur beschrieben, sondern vor und nach der Ausführung überprüft wird. Ein guter Ansible-Arbeitsablauf beantwortet immer vier Fragen: Welche Hosts sind betroffen, welche Änderung wird durchgeführt, welche Rechte werden dafür benötigt und wie wird der Erfolg gemessen?

Typische Kommandos:

ansible --version
ansible-config dump --only-changed
ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff

Für Reviews gilt: Ein Playbook ist erst dann gut genug, wenn es seine Zielgruppe beweist, seine Datenquellen offenlegt, sensible Werte schützt, Fehlerpfade beschreibt und nach einem zweiten Lauf stabil bleibt. Wenn ein Modul Check Mode oder Diff Mode nicht vollständig unterstützt, muss die Einschränkung im Runbook stehen.

Typische Fehler in diesem Bereich sind zu breite Patterns wie all, unklare Variablenquellen, Shell-Workarounds ohne Idempotenz, Secrets in Debug-Ausgaben, fehlende Rollback-Notiz und fehlende Trennung zwischen Lab- und Produktionsinventory.

flowchart LR
  user[Operator] --> control[Control Node]
  control --> inventory[Inventory]
  control --> playbook[Playbook]
  playbook --> tasks[Tasks]
  tasks --> modules[Modules]
  modules --> target[Managed Nodes]
  control --> evidence[Logs and Evidence]

4. Variablenfluss

Vertiefung und Abgabebeispiel zu Variablenfluss

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

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 Variablenfluss

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

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

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 Variablenfluss

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

Betriebsnotiz für Variablenfluss

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.

Variablenfluss ist ein praktischer Baustein des Ansible-Workshops. Entscheidend ist, dass der gewünschte Zustand nicht nur beschrieben, sondern vor und nach der Ausführung überprüft wird. Ein guter Ansible-Arbeitsablauf beantwortet immer vier Fragen: Welche Hosts sind betroffen, welche Änderung wird durchgeführt, welche Rechte werden dafür benötigt und wie wird der Erfolg gemessen?

Typische Kommandos:

ansible --version
ansible-config dump --only-changed
ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff

Für Reviews gilt: Ein Playbook ist erst dann gut genug, wenn es seine Zielgruppe beweist, seine Datenquellen offenlegt, sensible Werte schützt, Fehlerpfade beschreibt und nach einem zweiten Lauf stabil bleibt. Wenn ein Modul Check Mode oder Diff Mode nicht vollständig unterstützt, muss die Einschränkung im Runbook stehen.

Typische Fehler in diesem Bereich sind zu breite Patterns wie all, unklare Variablenquellen, Shell-Workarounds ohne Idempotenz, Secrets in Debug-Ausgaben, fehlende Rollback-Notiz und fehlende Trennung zwischen Lab- und Produktionsinventory.

flowchart LR
  user[Operator] --> control[Control Node]
  control --> inventory[Inventory]
  control --> playbook[Playbook]
  playbook --> tasks[Tasks]
  tasks --> modules[Modules]
  modules --> target[Managed Nodes]
  control --> evidence[Logs and Evidence]

5. Rollenmodell

Vertiefung und Abgabebeispiel zu Rollenmodell

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

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 Rollenmodell

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

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

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 Rollenmodell

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

Betriebsnotiz für Rollenmodell

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.

Rollenmodell ist ein praktischer Baustein des Ansible-Workshops. Entscheidend ist, dass der gewünschte Zustand nicht nur beschrieben, sondern vor und nach der Ausführung überprüft wird. Ein guter Ansible-Arbeitsablauf beantwortet immer vier Fragen: Welche Hosts sind betroffen, welche Änderung wird durchgeführt, welche Rechte werden dafür benötigt und wie wird der Erfolg gemessen?

Typische Kommandos:

ansible --version
ansible-config dump --only-changed
ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff

Für Reviews gilt: Ein Playbook ist erst dann gut genug, wenn es seine Zielgruppe beweist, seine Datenquellen offenlegt, sensible Werte schützt, Fehlerpfade beschreibt und nach einem zweiten Lauf stabil bleibt. Wenn ein Modul Check Mode oder Diff Mode nicht vollständig unterstützt, muss die Einschränkung im Runbook stehen.

Typische Fehler in diesem Bereich sind zu breite Patterns wie all, unklare Variablenquellen, Shell-Workarounds ohne Idempotenz, Secrets in Debug-Ausgaben, fehlende Rollback-Notiz und fehlende Trennung zwischen Lab- und Produktionsinventory.

flowchart LR
  user[Operator] --> control[Control Node]
  control --> inventory[Inventory]
  control --> playbook[Playbook]
  playbook --> tasks[Tasks]
  tasks --> modules[Modules]
  modules --> target[Managed Nodes]
  control --> evidence[Logs and Evidence]

6. Secret-Flow

Vertiefung und Abgabebeispiel zu Secret-Flow

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

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

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

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

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

• 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 Secret-Flow

Betriebsnotiz für Secret-Flow

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.

Secret-Flow ist ein praktischer Baustein des Ansible-Workshops. Entscheidend ist, dass der gewünschte Zustand nicht nur beschrieben, sondern vor und nach der Ausführung überprüft wird. Ein guter Ansible-Arbeitsablauf beantwortet immer vier Fragen: Welche Hosts sind betroffen, welche Änderung wird durchgeführt, welche Rechte werden dafür benötigt und wie wird der Erfolg gemessen?

Typische Kommandos:

ansible --version
ansible-config dump --only-changed
ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff

Für Reviews gilt: Ein Playbook ist erst dann gut genug, wenn es seine Zielgruppe beweist, seine Datenquellen offenlegt, sensible Werte schützt, Fehlerpfade beschreibt und nach einem zweiten Lauf stabil bleibt. Wenn ein Modul Check Mode oder Diff Mode nicht vollständig unterstützt, muss die Einschränkung im Runbook stehen.

Typische Fehler in diesem Bereich sind zu breite Patterns wie all, unklare Variablenquellen, Shell-Workarounds ohne Idempotenz, Secrets in Debug-Ausgaben, fehlende Rollback-Notiz und fehlende Trennung zwischen Lab- und Produktionsinventory.

flowchart LR
  user[Operator] --> control[Control Node]
  control --> inventory[Inventory]
  control --> playbook[Playbook]
  playbook --> tasks[Tasks]
  tasks --> modules[Modules]
  modules --> target[Managed Nodes]
  control --> evidence[Logs and Evidence]

7. CI- und Review-Ablauf

Vertiefung und Abgabebeispiel zu CI- und Review-Ablauf

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

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

Für Rollen oder Collections wird die Struktur erweitert:

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

Prüferwartung für CI- und Review-Ablauf

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

Transfer in reale Teams

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

Praxisbezug zu CI- und Review-Ablauf

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

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

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

Review-Kriterien für CI- und Review-Ablauf

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

Typische Fehler bei CI- und Review-Ablauf

Betriebsnotiz für CI- und Review-Ablauf

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

CI- und Review-Ablauf ist ein praktischer Baustein des Ansible-Workshops. Entscheidend ist, dass der gewünschte Zustand nicht nur beschrieben, sondern vor und nach der Ausführung überprüft wird. Ein guter Ansible-Arbeitsablauf beantwortet immer vier Fragen: Welche Hosts sind betroffen, welche Änderung wird durchgeführt, welche Rechte werden dafür benötigt und wie wird der Erfolg gemessen?

Typische Kommandos:

ansible --version
ansible-config dump --only-changed
ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff

Für Reviews gilt: Ein Playbook ist erst dann gut genug, wenn es seine Zielgruppe beweist, seine Datenquellen offenlegt, sensible Werte schützt, Fehlerpfade beschreibt und nach einem zweiten Lauf stabil bleibt. Wenn ein Modul Check Mode oder Diff Mode nicht vollständig unterstützt, muss die Einschränkung im Runbook stehen.

Typische Fehler in diesem Bereich sind zu breite Patterns wie all, unklare Variablenquellen, Shell-Workarounds ohne Idempotenz, Secrets in Debug-Ausgaben, fehlende Rollback-Notiz und fehlende Trennung zwischen Lab- und Produktionsinventory.

flowchart LR
  user[Operator] --> control[Control Node]
  control --> inventory[Inventory]
  control --> playbook[Playbook]
  playbook --> tasks[Tasks]
  tasks --> modules[Modules]
  modules --> target[Managed Nodes]
  control --> evidence[Logs and Evidence]

8. Rollout-Ablauf

Vertiefung und Abgabebeispiel zu Rollout-Ablauf

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

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

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

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

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

• 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 Rollout-Ablauf

Betriebsnotiz für Rollout-Ablauf

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.

Rollout-Ablauf ist ein praktischer Baustein des Ansible-Workshops. Entscheidend ist, dass der gewünschte Zustand nicht nur beschrieben, sondern vor und nach der Ausführung überprüft wird. Ein guter Ansible-Arbeitsablauf beantwortet immer vier Fragen: Welche Hosts sind betroffen, welche Änderung wird durchgeführt, welche Rechte werden dafür benötigt und wie wird der Erfolg gemessen?

Typische Kommandos:

ansible --version
ansible-config dump --only-changed
ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff

Für Reviews gilt: Ein Playbook ist erst dann gut genug, wenn es seine Zielgruppe beweist, seine Datenquellen offenlegt, sensible Werte schützt, Fehlerpfade beschreibt und nach einem zweiten Lauf stabil bleibt. Wenn ein Modul Check Mode oder Diff Mode nicht vollständig unterstützt, muss die Einschränkung im Runbook stehen.

Typische Fehler in diesem Bereich sind zu breite Patterns wie all, unklare Variablenquellen, Shell-Workarounds ohne Idempotenz, Secrets in Debug-Ausgaben, fehlende Rollback-Notiz und fehlende Trennung zwischen Lab- und Produktionsinventory.

flowchart LR
  user[Operator] --> control[Control Node]
  control --> inventory[Inventory]
  control --> playbook[Playbook]
  playbook --> tasks[Tasks]
  tasks --> modules[Modules]
  modules --> target[Managed Nodes]
  control --> evidence[Logs and Evidence]

9. Troubleshooting-Pfad

Vertiefung und Abgabebeispiel zu Troubleshooting-Pfad

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

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

Für Rollen oder Collections wird die Struktur erweitert:

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

Prüferwartung für Troubleshooting-Pfad

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

Transfer in reale Teams

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

Praxisbezug zu Troubleshooting-Pfad

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

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

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

Review-Kriterien für Troubleshooting-Pfad

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

Typische Fehler bei Troubleshooting-Pfad

Betriebsnotiz für Troubleshooting-Pfad

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

Troubleshooting-Pfad ist ein praktischer Baustein des Ansible-Workshops. Entscheidend ist, dass der gewünschte Zustand nicht nur beschrieben, sondern vor und nach der Ausführung überprüft wird. Ein guter Ansible-Arbeitsablauf beantwortet immer vier Fragen: Welche Hosts sind betroffen, welche Änderung wird durchgeführt, welche Rechte werden dafür benötigt und wie wird der Erfolg gemessen?

Typische Kommandos:

ansible --version
ansible-config dump --only-changed
ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff

Für Reviews gilt: Ein Playbook ist erst dann gut genug, wenn es seine Zielgruppe beweist, seine Datenquellen offenlegt, sensible Werte schützt, Fehlerpfade beschreibt und nach einem zweiten Lauf stabil bleibt. Wenn ein Modul Check Mode oder Diff Mode nicht vollständig unterstützt, muss die Einschränkung im Runbook stehen.

Typische Fehler in diesem Bereich sind zu breite Patterns wie all, unklare Variablenquellen, Shell-Workarounds ohne Idempotenz, Secrets in Debug-Ausgaben, fehlende Rollback-Notiz und fehlende Trennung zwischen Lab- und Produktionsinventory.

flowchart LR
  user[Operator] --> control[Control Node]
  control --> inventory[Inventory]
  control --> playbook[Playbook]
  playbook --> tasks[Tasks]
  tasks --> modules[Modules]
  modules --> target[Managed Nodes]
  control --> evidence[Logs and Evidence]

10. Security-Review

Vertiefung und Abgabebeispiel zu Security-Review

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

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

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

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

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

• 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 Security-Review

Betriebsnotiz für Security-Review

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.

Security-Review ist ein praktischer Baustein des Ansible-Workshops. Entscheidend ist, dass der gewünschte Zustand nicht nur beschrieben, sondern vor und nach der Ausführung überprüft wird. Ein guter Ansible-Arbeitsablauf beantwortet immer vier Fragen: Welche Hosts sind betroffen, welche Änderung wird durchgeführt, welche Rechte werden dafür benötigt und wie wird der Erfolg gemessen?

Typische Kommandos:

ansible --version
ansible-config dump --only-changed
ansible-inventory -i inventory/hosts.yml --graph
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --syntax-check
ansible-playbook -i inventory/hosts.yml playbooks/site.yml --check --diff

Für Reviews gilt: Ein Playbook ist erst dann gut genug, wenn es seine Zielgruppe beweist, seine Datenquellen offenlegt, sensible Werte schützt, Fehlerpfade beschreibt und nach einem zweiten Lauf stabil bleibt. Wenn ein Modul Check Mode oder Diff Mode nicht vollständig unterstützt, muss die Einschränkung im Runbook stehen.

Typische Fehler in diesem Bereich sind zu breite Patterns wie all, unklare Variablenquellen, Shell-Workarounds ohne Idempotenz, Secrets in Debug-Ausgaben, fehlende Rollback-Notiz und fehlende Trennung zwischen Lab- und Produktionsinventory.

flowchart LR
  user[Operator] --> control[Control Node]
  control --> inventory[Inventory]
  control --> playbook[Playbook]
  playbook --> tasks[Tasks]
  tasks --> modules[Modules]
  modules --> target[Managed Nodes]
  control --> evidence[Logs and Evidence]

Quellen und weiterführende Referenzen

• Offizielle Ansible Community Documentation: https://docs.ansible.com/
• Ansible Getting Started: https://docs.ansible.com/projects/ansible/latest/getting_started/index.html
• Inventory Guide: https://docs.ansible.com/projects/ansible/latest/inventory_guide/index.html
• Playbook Guide: https://docs.ansible.com/projects/ansible/latest/playbook_guide/index.html
• Module Index: https://docs.ansible.com/ansible/latest/collections/ansible/builtin/index.html
• Vault Guide: https://docs.ansible.com/projects/ansible/latest/vault_guide/index.html
• Ansible Lint: https://ansible.readthedocs.io/projects/lint/
• Molecule: https://ansible.readthedocs.io/projects/molecule/
• AWX: https://github.com/ansible/awx
• Red Hat Certifications: https://www.redhat.com/en/services/certifications