Einführung
Ein Playbook kann für jeden Host unterschiedliche Arbeit auswählen, ohne die gesamte Aufgabenliste zu duplizieren. Sie kombinieren boolesche Richtlinieneingaben mit Betriebssystem-Facts, verarbeiten jeden Eintrag einer strukturierten Liste und verwenden tatsächliche registrierte Untersuchungsergebnisse für eine unabhängige Genehmigungsentscheidung. Tatsächliche Dateien und ausdrückliches Aufräumen machen sowohl ausgewähltes als auch übersprungenes Verhalten beobachtbar.
Aufgaben mit booleschen Eingaben und Facts auswählen
In diesem Schritt lassen Sie ein wiederverwendbares Playbook auf den beiden Hosts unterschiedlich handeln und entfernen Ausgaben ausdrücklich, wenn die Richtlinie deaktiviert wird.
Die vorbereitete Umgebung besitzt nur auf web1 eine separate Genehmigungseingabe unter /home/automation/maintenance-approved. Lassen Sie diese Eingabe vorerst unverändert; die erste Richtlinienentscheidung verwendet stattdessen eine boolesche Variable und ermittelte Betriebssystem-Facts.
Wechseln Sie ins Controller-Projekt:
cd /home/labex/project
Hostvariablendateien ordnen jedem Inventarnamen Daten zu. Schreiben Sie boolesche YAML-Werte ohne Anführungszeichen, damit sie true-/false-Werte statt Zeichenfolgen bleiben:
cat > host_vars/web1.yml <<'YAML'
maintenance_enabled: true
YAML
cat > host_vars/web2.yml <<'YAML'
maintenance_enabled: false
YAML
Das Schlüsselwort when wertet einen booleschen Ausdruck für den aktuellen Host aus. Umschließen Sie den Ausdruck nicht mit Jinja-Klammern. Hier verlangt and sowohl eine aktivierte Richtlinie als auch Facts der Debian-Familie. not kehrt einen booleschen Wert um, und or lässt einen von beiden Gründen den Aufräumzweig auswählen.
cat > maintenance.yml <<'YAML'
- name: Apply a host-specific maintenance policy
hosts: all
gather_facts: true
tasks:
- name: Prepare the common policy directory
ansible.builtin.file:
path: /home/automation/maintenance-policy
state: directory
mode: "0750"
- name: Record enabled Debian maintenance
ansible.builtin.copy:
dest: /home/automation/maintenance-policy/enabled.txt
content: "Enabled maintenance\n"
mode: "0640"
when: maintenance_enabled and ansible_facts.os_family == "Debian"
- name: Remove the marker when the policy is disabled
ansible.builtin.file:
path: /home/automation/maintenance-policy/enabled.txt
state: absent
when: not maintenance_enabled or ansible_facts.os_family != "Debian"
YAML
Das gemeinsame Verzeichnis existiert auf beiden Hosts. Nur aktivierte Debian-Hosts erhalten die Markierungsdatei; die ergänzende absent-Aufgabe entfernt sie bei deaktivierter Richtlinie. Eine lediglich übersprungene Erstellungsaufgabe würde eine alte Markierungsdatei zurücklassen; Aufräumen ist daher eine separate Sollzustandsaufgabe.
Validieren Sie die Richtlinie und wenden Sie sie an:
ansible-playbook maintenance.yml --syntax-check
ansible-playbook maintenance.yml
Die Ausgabe sollte für web1 und web2 unterschiedliche changed-/ok-/skipped-Entscheidungen zeigen. Untersuchen Sie die tatsächlichen Metadaten der Markierungsdatei auf beiden Hosts:
ansible all -m ansible.builtin.stat -a 'path=/home/automation/maintenance-policy/enabled.txt'
Stat sollte exists true auf web1 und false auf web2 melden. Überschreiben Sie den booleschen Wert für beide Hosts, um das Aufräumen zu erproben. JSON-Zusatzvariablen erhalten den booleschen Typ false; die umschließenden einfachen Anführungszeichen schützen JSON vor der Interpretation durch die Shell:
ansible-playbook maintenance.yml -e '{"maintenance_enabled":false}'
ansible all -m ansible.builtin.stat -a 'path=/home/automation/maintenance-policy/enabled.txt'
Beide Markierungsdateien sollten nun fehlen. Stellen Sie die gespeicherte hostspezifische Richtlinie durch eine Ausführung ohne temporäre Überschreibung wieder her:
ansible-playbook maintenance.yml
Web1 sollte die Markierungsdatei wieder erhalten, während web2 deaktiviert bleibt. Die Überschreibung hat die gespeicherten Hostvariablendateien nicht bearbeitet.
Jeden Eintrag einer strukturierten Schleife anwenden
In diesem Schritt erzeugen Sie auf dem aktivierten Host für jeden deklarierten Eintrag einen tatsächlichen Wartungsprüfungsdatensatz.
Eine YAML-Liste enthält mehrere mit einem Bindestrich eingeleitete Einträge. Jeder folgende Eintrag ist eine Zuordnung mit den Feldern name und purpose. Gruppenvariablen für all machen diese Liste beiden Hosts verfügbar, während die bestehende boolesche Bedingung weiterhin entscheidet, welcher Host Ausgaben erhält.
cat > group_vars/all.yml <<'YAML'
maintenance_checks:
- name: disk
purpose: Inspect disk space
- name: logs
purpose: Inspect application logs
- name: packages
purpose: Inspect package state
YAML
loop wiederholt eine Aufgabe für jeden Listeneintrag. Innerhalb eines Durchlaufs lesen item.name und item.purpose die Felder dieses Eintrags. Die when-Bedingung wird für jeden Host und Eintrag ausgewertet. Hängen Sie diese Aufgaben an das bestehende Playbook an und richten Sie die Einrückung an den früheren Aufgaben aus:
cat >> maintenance.yml <<'YAML'
- name: Prepare checks only for enabled Debian hosts
ansible.builtin.file:
path: /home/automation/maintenance-policy/checks
state: directory
mode: "0750"
when: maintenance_enabled and ansible_facts.os_family == "Debian"
- name: Write every declared maintenance check
ansible.builtin.copy:
dest: "/home/automation/maintenance-policy/checks/{{ item.name }}.txt"
content: |
host={{ inventory_hostname }}
check={{ item.name }}
purpose={{ item.purpose }}
mode: "0640"
loop: "{{ maintenance_checks }}"
when: maintenance_enabled and ansible_facts.os_family == "Debian"
- name: Remove check outputs when the policy is disabled
ansible.builtin.file:
path: /home/automation/maintenance-policy/checks
state: absent
when: not maintenance_enabled or ansible_facts.os_family != "Debian"
YAML
Die Aufräumaufgabe entfernt auf deaktivierten Hosts das gesamte Prüfverzeichnis einschließlich alter Ausgaben einer früher aktivierten Richtlinie. Die Schleife schreibt auf aktivierten Hosts stabilen Inhalt und ausdrückliche Berechtigungen.
Wenden Sie das erweiterte Playbook an:
ansible-playbook maintenance.yml
Web1 sollte drei Schleifenergebnisse haben, eines pro Prüfung. Web2 sollte diese Schreibvorgänge überspringen und kein Prüfverzeichnis behalten. Lesen Sie alle drei tatsächlichen web1-Artefakte, statt einen erfolgreichen Eintrag als Nachweis für die gesamte Liste zu behandeln:
ansible web1 -m ansible.builtin.command -a 'cat /home/automation/maintenance-policy/checks/disk.txt /home/automation/maintenance-policy/checks/logs.txt /home/automation/maintenance-policy/checks/packages.txt'
Die Ausgabe sollte jeden Datensatz mit host=web1 identifizieren und den jeweiligen Prüfungsnamen und Zweck zeigen. Untersuchen Sie den deaktivierten Host unabhängig:
ansible web2 -m ansible.builtin.stat -a 'path=/home/automation/maintenance-policy/checks'
Sein stat-Ergebnis sollte exists false melden. Diese Datensätze deklarieren Anweisungen für Wartungsprüfungen; sie geben nicht vor, die Untersuchungen von Festplatte, Protokollen oder Paketen selbst auszuführen.
Anhand eines registrierten Untersuchungsergebnisses verzweigen
In diesem Schritt verwenden Sie ein tatsächliches stat-Ergebnis als unabhängige Entscheidungseingabe und bestätigen, dass die vollständige Richtlinie bei Wiederholung stabil bleibt.
Die Genehmigungseingabe ist von maintenance_enabled getrennt. Eine stat-Aufgabe untersucht immer jeden Host; register speichert anschließend das Ergebnis dieses Hosts. Sein boolescher Wert stat.exists unterscheidet sicher eine vorhandene Eingabe von einem fehlenden Pfad. Hängen Sie die Untersuchung und die ergänzenden Ausgabeaufgaben an:
cat >> maintenance.yml <<'YAML'
- name: Inspect the independent approval input
ansible.builtin.stat:
path: /home/automation/maintenance-approved
register: approval_info
- name: Record an existing approval input
ansible.builtin.copy:
dest: /home/automation/maintenance-policy/approved.txt
content: "Approval input exists\n"
mode: "0640"
when: approval_info.stat.exists
- name: Remove the output when approval input is absent
ansible.builtin.file:
path: /home/automation/maintenance-policy/approved.txt
state: absent
when: not approval_info.stat.exists
YAML
Die copy-Aufgabe verwendet den registrierten Wert exists. Die absent-Aufgabe deckt dessen Gegenteil ab, sodass eine entfernte Genehmigungseingabe auch veraltete Genehmigungsausgabe entfernen würde. Dieser Zweig basiert auf untersuchtem Zustand statt einer festen debug-Nachricht.
Führen Sie die vollständige Richtlinie aus:
ansible-playbook maintenance.yml
Die vorbereitete Genehmigungseingabe existiert nur auf web1; daher sollte nur web1 approved.txt besitzen. Untersuchen Sie beide tatsächlichen Ausgabepfade:
ansible all -m ansible.builtin.stat -a 'path=/home/automation/maintenance-policy/approved.txt'
Web1 sollte exists true melden und web2 false. Wiederholen Sie das Playbook:
ansible-playbook maintenance.yml
Beide Zusammenfassungszeilen sollten changed=0, failed=0 und unreachable=0 melden. Übersprungene Aufgaben sind dort zu erwarten, wo eine Bedingung false ist; jeder erforderliche Schleifeneintrag und jede ausgewählte Ausgabe müssen dennoch mit korrektem Inhalt existieren.
Zusammenfassung
Sie haben hostspezifische boolesche Daten und ermittelte Facts zur Aufgabenauswahl verwendet, jede Zuordnung in einer Schleife verarbeitet und anhand registrierter stat-Metadaten verzweigt. Ergänzende absent-Aufgaben entfernten veraltete Ausgaben, statt anzunehmen, dass übersprungene Erstellung alten Zustand rückgängig macht. Beide Hosts erreichten ihre unterschiedlichen Richtlinienergebnisse ohne unnötige wiederholte Änderungen.
