Konfiguration von ansible.cfg und Projekt-Standardwerten

AnsibleBeginner
Jetzt üben

Einführung

Ansible sucht in einer festgelegten Reihenfolge nach Konfigurationsdateien. Eine ansible.cfg auf Projektebene ist wichtig, da sie sicherstellt, dass Befehle unabhängig von der verwendeten Shell-Sitzung reproduzierbar sind.

In diesem Lab erstellen Sie ein kleines Projekt, schreiben eine ansible.cfg, definieren Standardwerte für das Inventory, fügen gemeinsam genutzte Variablen hinzu und führen Ihre ersten Ansible-Prüfungen aus dem Projektverzeichnis heraus durch.

Erstellen eines minimalen Projekts und Inventories

In diesem Schritt erstellen Sie die Verzeichnisse und die Inventory-Datei, die für die Ansible-Konfiguration auf Projektebene erforderlich sind. Da dieses Lab auf einer frischen VM beginnt, erstellen Sie nur die hier benötigten Dateien.

Erstellen Sie die Projektstruktur.

cd /home/labex/project
mkdir -p rhce-ansible/{inventory,group_vars,playbooks}

Dieses Lab hält das Projekt bewusst klein. inventory enthält die Liste der verwalteten Hosts, group_vars enthält Variablen, die Ansible automatisch lädt, und playbooks ist für spätere Automatisierungsdateien reserviert.

Wechseln Sie in das Projektverzeichnis.

cd rhce-ansible

Erstellen Sie ein Inventory mit einem lokalen verwalteten Host.

cat > inventory/hosts <<'EOF'
[managed]
node1 ansible_connection=local
EOF

Der Hostname node1 ist ein Alias im Inventory, keine separate VM. Die Einstellung ansible_connection=local sorgt dafür, dass Ansible Module auf diesem RHEL-System ausführt, während Sie dennoch das gezielte Ansprechen von Gruppen üben können.

Schreiben der ansible.cfg für das Projekt

In diesem Schritt erstellen Sie die Datei ansible.cfg. Der Abschnitt [defaults] steuert das allgemeine Verhalten. Durch die Einstellung inventory müssen Sie bei jedem Befehl nicht mehr -i inventory/hosts angeben.

Bevor Sie in diesem Schritt Befehle ausführen, kehren Sie in das Projektverzeichnis zurück, damit sich relative Pfade auf das Ansible-Projekt beziehen.

cd /home/labex/project/rhce-ansible

Schreiben Sie die Konfigurationsdatei.

cat > ansible.cfg <<'EOF'
[defaults]
inventory = ./inventory/hosts
remote_user = labex
host_key_checking = False
retry_files_enabled = False
interpreter_python = auto_silent
stdout_callback = default
EOF

Jede Einstellung erspart Ihnen eine wiederkehrende Auswahl in der Befehlszeile. inventory verweist auf die statische Inventory-Datei, remote_user legt den Standard-Benutzer für die Anmeldung fest, host_key_checking = False verhindert SSH-Host-Key-Abfragen in Lab-Umgebungen und interpreter_python = auto_silent erlaubt es Ansible, Python ohne störende Warnungen zur Erkennung auszuwählen.

Fragen Sie Ansible, welche Konfigurationsdatei verwendet wird.

ansible --version | sed -n '1,4p'

Die Ausgabe sollte config file = /home/labex/project/rhce-ansible/ansible.cfg enthalten.

Dies ist eine wichtige Gewohnheit: Wenn Ansible eine andere Konfigurationsdatei liest, könnten spätere Befehle ein anderes Inventory, einen anderen Callback oder ein anderes Verbindungsverhalten verwenden, als im Lab vorgesehen.

Überprüfen des Inventories durch Projekt-Standardwerte

In diesem Schritt testen Sie, ob die ansible.cfg Ansible tatsächlich auf Ihr Inventory verweist. Da der Pfad zum Inventory konfiguriert ist, benötigt dieser Befehl die Option -i nicht.

Bevor Sie in diesem Schritt Befehle ausführen, kehren Sie in das Projektverzeichnis zurück, damit sich relative Pfade auf das Ansible-Projekt beziehen.

cd /home/labex/project/rhce-ansible

Lassen Sie sich das Inventory-Diagramm anzeigen.

ansible-inventory --graph

Das Diagramm sollte die Gruppe managed und den Host node1 anzeigen.

Die grafische Ansicht ist nützlich, bevor Sie Befehle ausführen, da sie das Inventory anzeigt, nachdem Ansible es geparst hat. Wenn hier eine Gruppe oder ein Host fehlt, wird ein Playbook-Ziel diese ebenfalls nicht finden.

Listen Sie die Host-Variablen für node1 auf.

ansible-inventory --host node1

Sie sollten sehen, dass ansible_connection auf local gesetzt ist.

Die Host-Ansicht zeigt die aufgelösten Host-Variablen an, nicht nur die rohe Zeile aus dem Inventory. In späteren Labs verwenden Sie denselben Befehl, um zu prüfen, ob Variablen aus dem Inventory, group_vars oder host_vars stammen.

Hinzufügen von gemeinsam genutzten Variablen

In diesem Schritt fügen Sie Variablen für alle verwalteten Hosts hinzu. Dateien unter group_vars werden automatisch geladen, wenn ihre Namen mit Inventory-Gruppen oder all übereinstimmen.

Bevor Sie in diesem Schritt Befehle ausführen, kehren Sie in das Projektverzeichnis zurück, damit sich relative Pfade auf das Ansible-Projekt beziehen.

cd /home/labex/project/rhce-ansible

Erstellen Sie group_vars/all.yml. YAML verwendet key: value-Paare. Achten Sie auf ein Leerzeichen nach jedem Doppelpunkt.

cat > group_vars/all.yml <<'EOF'
project_owner: labex
baseline_message: Managed by the RHCE Ansible prep project
EOF

Der Dateiname all.yml hat eine besondere Bedeutung: Ansible wendet sie auf jeden Host im Inventory an. Da es sich um YAML handelt, sind die Einrückung und das Leerzeichen nach jedem Doppelpunkt Teil der Gültigkeit der Datei.

Verwenden Sie das Modul debug, um eine Variable vom verwalteten Host auszugeben.

ansible managed -m ansible.builtin.debug -a 'var=baseline_message'

Die Ausgabe sollte die Nachricht aus group_vars/all.yml enthalten.

Der Ad-hoc-Befehl besteht aus drei Teilen: managed ist das Host-Muster, -m wählt das Modul aus und -a übergibt das Modul-Argument. Ein erfolgreiches Ergebnis beweist, dass das konfigurierte Inventory und das Laden der Variablen korrekt zusammenarbeiten.

Durchführen einer Konnektivitätsprüfung

In diesem Schritt führen Sie das Modul ping aus. Dies ist kein ICMP-Ping; es ist ein Ansible-Modul, das prüft, ob Ansible Python auf dem Ziel-Host ausführen kann.

Bevor Sie in diesem Schritt Befehle ausführen, kehren Sie in das Projektverzeichnis zurück, damit sich relative Pfade auf das Ansible-Projekt beziehen.

cd /home/labex/project/rhce-ansible

Führen Sie die Prüfung für die Gruppe managed durch.

ansible managed -m ansible.builtin.ping

Ein erfolgreiches Ergebnis enthält pong.

Das ping-Modul von Ansible ist ein Test für die Modulausführung, kein ICMP-Netzwerk-Ping. Es beweist, dass Ansible den Host erreichen, Python starten und ein Modulergebnis zurückgeben kann.

Speichern Sie eine kleine Nachweisdatei über einen Ad-hoc-Befehl. Das Modul copy schreibt Inhalte in einen Zielpfad.

ansible managed -m ansible.builtin.copy -a 'content=ansible_cfg_ready dest=/home/labex/project/rhce-ansible/config-check.txt mode=0644'

Wenn dieser Befehl changed meldet, hat Ansible die Datei erstellt oder aktualisiert. Wenn Sie ihn erneut mit demselben Inhalt und Modus ausführen, sollte das Ergebnis ok lauten, da der gewünschte Zustand bereits existiert.

Zusammenfassung

Sie haben eine ansible.cfg auf Projektebene erstellt, bestätigt, dass Ansible das konfigurierte Inventory lädt, gemeinsam genutzte Variablen hinzugefügt und Ad-hoc-Modulprüfungen durchgeführt. Spätere Labs werden auf dieser reproduzierbaren Projektkonfiguration aufbauen.