Einführung
Idempotenz bedeutet, dass ein Playbook wiederholt ausgeführt werden kann und das System nur dann verändert, wenn der gewünschte Zustand nicht vorhanden oder abweichend ist.
In diesem Lab verwenden Sie gängige Ansible-Module, um Verzeichnisse und Konfigurationsdateien für Host-Aliase zu erstellen. Anschließend führen Sie das Playbook zweimal aus, um zu beweisen, dass der zweite Durchlauf stabil ist.
Ein Projekt für Idempotenz-Übungen erstellen
In diesem Schritt erstellen Sie ein kleines Ansible-Projekt mit zwei lokalen verwalteten Host-Aliasen. Jeder Alias schreibt in sein eigenes Verzeichnis, sodass Sie hostspezifische Ergebnisse sehen können, während Sie innerhalb einer einzigen RHEL 10 VM bleiben.
Beginnen Sie im Standard-LabEx-Arbeitsbereich.
cd /home/labex/project
Die Option -p weist mkdir an, bei Bedarf übergeordnete Verzeichnisse zu erstellen und erfolgreich abzuschließen, falls ein Verzeichnis bereits existiert.
mkdir -p rhce-ansible/{inventory/group_vars,playbooks,managed,reports}
cd rhce-ansible
Erstellen Sie Projekt-Standardeinstellungen, die Ansible auf Ihr Inventory verweisen und die Erstellung von Retry-Dateien deaktivieren.
cat > ansible.cfg <<'EOF'
[defaults]
inventory = ./inventory/hosts
host_key_checking = False
retry_files_enabled = False
EOF
Das Verzeichnis managed nimmt die vom Playbook erzeugten Dateien auf, während reports die gespeicherten Playbook-Ausgaben enthält. Diese Trennung erleichtert den Vergleich zwischen dem gewünschten Inhalt und den Nachweisen der Ansible-Ausführung.
Lokale verwaltete Hosts und Variablen definieren
In diesem Schritt erstellen Sie ein Inventory und Gruppenvariablen. Die Aliase verwenden ansible_connection=local, was bedeutet, dass Ansible die benannten Hosts anspricht, während es sicher auf dieser VM ausgeführt wird.
Bevor Sie in diesem Schritt Befehle ausführen, kehren Sie in das Ansible-Projektverzeichnis zurück. Dies sorgt für konsistente Befehlspfade, auch wenn LabEx jeden Schritt separat ausführt.
cd /home/labex/project/rhce-ansible
Erstellen Sie zwei App-Host-Aliase in einer Gruppe.
cat > inventory/hosts <<'EOF'
[app]
app1 ansible_connection=local
app2 ansible_connection=local
EOF
Gruppenvariablen beschreiben den gewünschten Zustand, der für jeden Host in der Gruppe gilt.
cat > inventory/group_vars/app.yml <<'EOF'
app_owner: labex
app_environment: training
app_message: Managed by Ansible common modules
EOF
Bestätigen Sie, dass Ansible die beiden Hosts erkennt.
ansible app --list-hosts
Die Ausgabe sollte app1 und app2 auflisten. Diese Überprüfung ist nützlich, bevor Sie ein Playbook schreiben, da ein Play, das auf app abzielt, nur Hosts beeinflussen kann, die das Inventory dieser Gruppe zuordnet.
Ein Playbook für den gewünschten Zustand schreiben
In diesem Schritt schreiben Sie ein Playbook, das file, copy und lineinfile verwendet. Diese Module beschreiben den Endzustand, anstatt manuell Shell-Befehle auszuführen.
Bevor Sie in diesem Schritt Befehle ausführen, kehren Sie in das Ansible-Projektverzeichnis zurück.
cd /home/labex/project/rhce-ansible
Erstellen Sie das Playbook. Die Pfade enthalten {{ inventory_hostname }}, sodass jeder Alias sein eigenes Ausgabeverzeichnis erhält.
cat > playbooks/common-modules.yml <<'EOF'
---
- name: Configure app host directories with common modules
hosts: app
gather_facts: false
tasks:
- name: Ensure host directory exists
ansible.builtin.file:
path: "/home/labex/project/rhce-ansible/managed/{{ inventory_hostname }}"
state: directory
mode: '0755'
- name: Install base application configuration
ansible.builtin.copy:
dest: "/home/labex/project/rhce-ansible/managed/{{ inventory_hostname }}/app.conf"
content: |
owner={{ app_owner }}
environment={{ app_environment }}
message={{ app_message }}
mode: '0644'
- name: Ensure managed message is present
ansible.builtin.lineinfile:
path: "/home/labex/project/rhce-ansible/managed/{{ inventory_hostname }}/app.conf"
line: "message={{ app_message }}"
create: true
mode: '0644'
EOF
Die file-Aufgabe erstellt das Verzeichnis, die copy-Aufgabe schreibt die vollständige Konfiguration und die lineinfile-Aufgabe demonstriert, wie eine einzelne Zeile erzwungen wird. Diese Module vergleichen den aktuellen Zustand mit dem gewünschten Zustand, weshalb sie idempotent arbeiten können.
Führen Sie vor der Ausführung eines neuen Playbooks eine Syntaxprüfung durch.
ansible-playbook playbooks/common-modules.yml --syntax-check
Playbook ausführen und Dateien prüfen
In diesem Schritt führen Sie das Playbook für den gewünschten Zustand zum ersten Mal aus. Der erste Durchlauf sollte Änderungen melden, da die Zieldateien noch nicht existieren. Bevor Sie in diesem Schritt Befehle ausführen, kehren Sie in das Ansible-Projektverzeichnis zurück.
cd /home/labex/project/rhce-ansible
Führen Sie das Playbook aus und speichern Sie die Ausgabe für einen späteren Vergleich.
ansible-playbook playbooks/common-modules.yml | tee reports/first-run.txt
Der erste Durchlauf sollte Änderungen melden, da die Host-Verzeichnisse und app.conf-Dateien neu sind. tee ermöglicht es Ihnen, die Ausführung zu verfolgen und gleichzeitig die Ausgabe für die Idempotenz-Prüfung zu speichern.
Überprüfen Sie die hostspezifischen Dateien, die Ansible erstellt hat.
cat managed/app1/app.conf managed/app2/app.conf
Beide Dateien sollten dieselben Werte für Owner, Environment und Message enthalten, befinden sich jedoch in unterschiedlichen Host-Alias-Verzeichnissen. Dies zeigt, dass das Playbook denselben gewünschten Zustand auf jeden Inventory-Host angewendet hat.
Playbook erneut ausführen, um Idempotenz zu beweisen
In diesem Schritt führen Sie dasselbe Playbook erneut aus. Da die Dateien bereits dem gewünschten Zustand entsprechen, sollte Ansible für beide Hosts null Änderungen melden. Bevor Sie in diesem Schritt Befehle ausführen, kehren Sie in das Ansible-Projektverzeichnis zurück.
cd /home/labex/project/rhce-ansible
Führen Sie das Playbook ein zweites Mal aus und speichern Sie die Ausgabe.
ansible-playbook playbooks/common-modules.yml | tee reports/second-run.txt
Achten Sie in den Zusammenfassungszeilen auf changed=0.
grep -E 'app[12].*changed=0' reports/second-run.txt
changed=0 beim zweiten Durchlauf ist das entscheidende Signal für Idempotenz. Es bedeutet, dass die Module die vorhandenen Dateien überprüft haben und festgestellt haben, dass keine Reparatur erforderlich war.
Zusammenfassung
Sie haben ein Ansible-Projekt erstellt, Standardmodule verwendet, um den gewünschten Zustand zu beschreiben, das Playbook ausgeführt und die Idempotenz durch einen zweiten Durchlauf bewiesen, der keine Änderungen meldete.
