Ein idempotentes Playbook schreiben

Einführung

Mehrere zusammengehörige einmalige Befehle lassen sich leichter wiederholen und überprüfen, wenn sie in einem Playbook gespeichert sind. Ein nützliches Playbook beschreibt einen stabilen Sollzustand und erzeugt beobachtbare Ergebnisse auf jedem vorgesehenen Ziel.

Sie schreiben ein kleines YAML-Playbook mit den Modulen file und copy, wenden es auf zwei SSH-Knoten an und überprüfen sowohl die erstellten Dateien als auch eine erneute Ausführung ohne Änderungen. Diese Übung führt Plays, Aufgaben und Idempotenz ohne Variablen, Schleifen oder Rollen ein.

Ein Playbook in YAML schreiben

In diesem Schritt kombinieren Sie die bereits geübten Module file und copy zu einem wiederverwendbaren Playbook.

Wechseln Sie im Terminal ins Projekt:

cd /home/labex/project

Ein Playbook ist eine YAML-Liste von Plays. Jedes Play verbindet ein Hostmuster mit einer geordneten Aufgabenliste. Jede Aufgabe benennt ein Modul und dessen Argumente. name-Bezeichnungen helfen Menschen beim Lesen der Ausgabe; sie erzeugen selbst keine Konfiguration.

YAML verwendet Einrückung zur Verschachtelung von Daten. Verwenden Sie Leerzeichen, keine Tabulatoren. Ein führendes - beginnt einen Listeneintrag, und ein Doppelpunkt leitet den Wert eines Schlüssels ein. Hier enthält tasks zwei Modulaufgaben. Modi in Anführungszeichen wie "0750" bleiben Berechtigungszeichenfolgen. gather_facts: false überspringt die automatische Fact-Erfassung, da diese Aufgaben mit festem Zustand keine Facts verwenden.

Erstellen Sie die Datei mit einem Here-Dokument mit in Anführungszeichen gesetzter Begrenzung, wie zuvor geübt. Kopieren Sie bis einschließlich der letzten EOF-Zeile:

cat > workspace.yml <<'EOF'
- name: Prepare managed workspaces
  hosts: all
  gather_facts: false
  tasks:
    - name: Create the workspace directory
      ansible.builtin.file:
        path: /home/automation/workspace
        state: directory
        mode: "0750"

    - name: Write the workspace notice
      ansible.builtin.copy:
        dest: /home/automation/workspace/README.txt
        content: "Workspace managed by Ansible\n"
        mode: "0640"
EOF

Die erste Aufgabe deklariert ein Verzeichnis. Die zweite stellt über das copy-Argument content wörtlichen Text direkt bereit, statt eine src-Datei auf dem Controller zu lesen. Die YAML-Zeichenfolge in doppelten Anführungszeichen interpretiert \n als abschließenden Zeilenumbruch. Fester Inhalt hält wiederholte Ausführungen stabil; fügen Sie keinen sich ändernden Zeitstempel hinzu.

Das Play verwendet hosts: all, also beide bereitgestellten SSH-Knoten. Gewöhnliche Aufgaben laufen als automation, dessen Benutzerverzeichnis daher ohne become beschreibbar ist.

ansible-playbook führt Playbook-Dateien aus. Verwenden Sie zunächst --syntax-check, um die Struktur zu prüfen, ohne Aufgaben anzuwenden:

ansible-playbook workspace.yml --syntax-check

Erwarten Sie eine Zeile zur Playbook-Identifikation und keinen Parserfehler. Syntaxprüfung allein belegt weder entfernte Verbindungen noch korrekte endgültige Dateien.

Zeigen Sie die Hostauswahl des Plays mit --list-hosts vorab an:

ansible-playbook workspace.yml --list-hosts

Das Play muss web1 und web2 auflisten. Eine leere Liste ist kein nutzbares Zwei-Host-Playbook.

Den Sollzustand anwenden

In diesem Schritt führen Sie das Playbook aus und untersuchen seine tatsächlichen entfernten Ergebnisse.

Führen Sie die Datei aus dem Projekt heraus aus, damit dessen Konfiguration und Inventar ausgewählt werden:

ansible-playbook workspace.yml

Ansible gibt den Namen jedes Plays und jeder Aufgabe aus, gefolgt von einem PLAY RECAP. In einer frischen Umgebung sollten die beiden Aufgaben jeden Host ändern:

web1 : ok=2 changed=2 unreachable=0 failed=0 ...
web2 : ok=2 changed=2 unreachable=0 failed=0 ...

Abstände und Hostreihenfolge können abweichen. ok zählt erfolgreiche Aufgaben, changed zählt Aufgaben, die Änderungen benötigten, und unreachable/failed sollten beide null sein. Ein erfolgreicher Aufgabenname allein belegt nicht die erforderlichen Dateibytes oder Berechtigungen.

Lesen Sie jeden entfernten Hinweis mit dem Ad-hoc-command-Modul:

ansible all -m ansible.builtin.command -a 'cat /home/automation/workspace/README.txt'

Beide Standardausgaben sollten Workspace managed by Ansible zeigen. Die ausschließlich lesende Befehlsabfrage kann trotzdem CHANGED melden; die file-/copy-Ergebnisse des Playbooks beschreiben den deklarierten Zustand. Das verwaltete Verzeichnis hat Modus 0750, der Hinweis Modus 0640, und beide gehören automation.

Idempotente Konvergenz überprüfen

In diesem Schritt wiederholen Sie das Playbook und bestätigen, dass übereinstimmender Zustand keine zusätzlichen Änderungen erfordert.

Idempotenz bedeutet, dass die wiederholte Anwendung desselben Sollzustands nach der Konvergenz keine unnötigen Änderungen hervorruft. Führen Sie dasselbe Playbook erneut aus:

ansible-playbook workspace.yml

Erwarten Sie für jedes Ziel eine Zusammenfassung mit ok=2, changed=0, unreachable=0 und failed=0. Beide Dateien bleiben vorhanden und korrekt. Ein sich ändernder Zeitstempel oder ein bedingungslos ausgeführter allgemeiner Befehl würde dieses stabile Ergebnis beeinträchtigen.

--check fordert eine Vorschau an: Unterstützte Module prognostizieren Änderungen, ohne sie anzuwenden. Sowohl file als auch copy unterstützen diesen Ablauf. Zeigen Sie eine Vorschau des konvergierten Playbooks an:

ansible-playbook workspace.yml --check

Erwarten Sie erneut null Änderungen für beide Hosts. Eine Vorschau ersetzt weder die erste tatsächliche Ausführung noch die Untersuchung des tatsächlichen Zustands. Hier bestätigt sie, dass die bereits erstellten Arbeitsbereiche den Deklarationen entsprechen.

Behalten Sie das Playbook zur späteren Wiederverwendung. Unterdrücken Sie Änderungen nicht mit changed_when und zwingen Sie Aufgaben nicht aus dem Prüfmodus, um eine saubere Zusammenfassung zu erzeugen; das Ergebnis sollte tatsächlich übereinstimmenden Zustand widerspiegeln.

Zusammenfassung

Sie haben Hostauswahl und geordnete Modulaufgaben in YAML ausgedrückt, Syntax und Zielgeltungsbereich geprüft und das Playbook auf zwei echte verwaltete Knoten angewendet. Der tatsächliche Dateizustand entsprach den Anforderungen, eine zweite tatsächliche Ausführung nahm keine zusätzlichen Änderungen vor, und der ausschließlich lesende Prüfmodus fand keine ausstehenden Änderungen.