Einführung
Ein einmaliger Ansible-Befehl kann eine Hostflotte untersuchen oder einen kleinen, ausdrücklich definierten Konfigurationszustand anwenden. Die Wahl des richtigen Moduls erleichtert das Verständnis seines Verhaltens und seiner zurückgegebenen Ergebnisse.
Sie untersuchen zwei Linux-Ziele, bereiten ein verwaltetes Verzeichnis vor und verteilen eine Quelldatei vom Controller. Dabei vergleichen Sie die Befehlsausführung mit Modulen, die melden, ob der angeforderte Zustand tatsächlich eine Änderung erforderte. Inventar und SSH-Verbindungen sind bereits vorbereitet.
Eine Hostgruppe mit Modulen untersuchen
In diesem Schritt wählen Sie Ansible-Module für einmalige Aufrufe, um die beiden vorbereiteten verwalteten Knoten zu untersuchen.
Öffnen Sie das Terminal und wählen Sie den Arbeitsbereich aus:
cd /home/labex/project
Ein Ad-hoc-Befehl führt ein Modul direkt auf ausgewählten Inventarhosts aus, ohne ein Playbook. Seine Grundform lautet ansible PATTERN -m MODULE -a ARGUMENTS. Die Übung stellt eine Gruppe webservers mit beiden SSH-Zielen bereit. Zeigen Sie diese Gruppe vorab an:
ansible webservers --list-hosts
Erwarten Sie genau web1 und web2. Führen Sie mit dem command-Modul aus der vorherigen Übung uname -s aus; dieser Befehl gibt den Namen des Betriebssystemkernels aus:
ansible webservers -m ansible.builtin.command -a 'uname -s'
Jeder Host sollte Linux ausgeben. Das command-Modul meldet normalerweise selbst bei einer ausschließlich lesenden Abfrage CHANGED. Prüfen Sie Standardausgabe und Rückgabestatus, statt diese Kennzeichnung als Konfigurationsänderung zu interpretieren.
Das setup-Modul sammelt Facts, strukturierte Informationen, die auf einem verwalteten Knoten ermittelt werden. Das Modulargument filter beschränkt die zurückgegebenen Facts. Untersuchen Sie den Distributionsnamen:
ansible webservers -m ansible.builtin.setup -a 'filter=ansible_distribution'
Jedes erfolgreiche Ergebnis sollte ein Objekt ansible_facts mit "ansible_distribution": "Ubuntu" enthalten. setup meldet für diese Untersuchung gewöhnlich changed: false. Facts beschreiben das Ziel, nicht Ihren Controller; spätere Übungen verwenden sie in der Automatisierung.
Ein Aufgabenergebnis ungleich null ist ein Fehler, und UNREACHABLE weist auf ein Verbindungsproblem hin. Zwei erwartete Hosts erfordern zwei erfolgreiche Ergebnisse. Verwechseln Sie eine leere Auswahl nicht mit einer abgeschlossenen Untersuchung.
Ein verwaltetes Verzeichnis deklarieren
In diesem Schritt bereiten Sie mit einem zustandsorientierten Modul dasselbe Verzeichnis auf beiden Zielen vor.
Das file-Modul verwaltet den Dateisystemzustand. Sein path identifiziert den Zielpfad, und state=directory fordert ein Verzeichnis statt einer leeren Datei an. mode=0750 gewährt dem Eigentümer vollen Zugriff, der Gruppe Lese-/Suchzugriff und allen anderen keinen Zugriff. Die führende Null kennzeichnet einen oktalen Berechtigungswert.
Gewöhnliche Aufgaben laufen als vorbereitetes Konto automation. Erstellen Sie ein Verzeichnis im Benutzerverzeichnis dieses Kontos, sodass kein become benötigt wird:
ansible webservers -m ansible.builtin.file -a 'path=/home/automation/ops state=directory mode=0750'
Beide Hosts sollten beim erstmaligen Erstellen des Verzeichnisses changed: true melden, wobei ein Feld path oder dest auf /home/automation/ops verweist. Das Verzeichnis gehört automation, weil dieses Konto es erstellt.
Führen Sie dieselbe Deklaration erneut aus:
ansible webservers -m ansible.builtin.file -a 'path=/home/automation/ops state=directory mode=0750'
Erwarten Sie nun changed: false auf beiden Hosts: Der angeforderte Zustand besteht bereits. Dies unterscheidet sich von wiederholten allgemeinen Befehlen wie touch, die möglicherweise weiterhin Zeitstempel aktualisieren.
Eine Controller-Datei auf beide Ziele kopieren
In diesem Schritt erstellen Sie eine kleine Quelldatei auf dem Controller und verteilen ihren exakten Inhalt mit ausdrücklich festgelegten Zielberechtigungen.
printf schreibt den Text und einen abschließenden Zeilenumbruch; > erstellt oder ersetzt die Quelldatei im aktuellen Projekt. Das in Anführungszeichen gesetzte Format hält die Nachricht zusammen, während \n den Zeilenumbruch anfordert:
printf 'Managed by Ansible\n' > message.txt
Das copy-Modul überträgt eine Controller-Quelle an ein verwaltetes Ziel. src liegt auf dem Controller, während dest auf jedem Ziel liegt. Bei einer regulären Datei gibt mode=0640 dem Eigentümer Lese-/Schreibzugriff, der Gruppe Lesezugriff und allen anderen keinen Zugriff:
ansible webservers -m ansible.builtin.copy -a 'src=/home/labex/project/message.txt dest=/home/automation/ops/message.txt mode=0640'
Jedes Ziel sollte beim ersten Kopieren changed: true melden. Führen Sie dieselbe Übertragung erneut aus:
ansible webservers -m ansible.builtin.copy -a 'src=/home/labex/project/message.txt dest=/home/automation/ops/message.txt mode=0640'
Erwarten Sie changed: false, wenn Bytes und angeforderte Berechtigungen bereits übereinstimmen. Das file-Modul hat das übergeordnete Verzeichnis vorbereitet; das Kopieren einer Datei ersetzt diesen Schritt zur Verzeichniserstellung nicht.
Lesen Sie den tatsächlichen entfernten Inhalt mit dem command-Modul:
ansible webservers -m ansible.builtin.command -a 'cat /home/automation/ops/message.txt'
Die Standardausgabe beider Ergebnisse sollte Managed by Ansible zeigen. Die Befehlsabfrage kann CHANGED melden, aber das frühere Ergebnis changed:false des copy-Moduls beschreibt eine bereits übereinstimmende verwaltete Datei. Ihre Controller-Quelle bleibt von beiden entfernten Kopien getrennt.
Zusammenfassung
Sie haben Ad-hoc-Module auf einer echten Zwei-Host-Gruppe ausgeführt, Befehlsausgaben interpretiert und Distributions-Facts ermittelt. Sie haben ein Verzeichnis deklariert, eine separate Controller-Quelle mit ausdrücklichen Berechtigungen kopiert und unveränderte Ergebnisse beobachtet, als zustandsorientierte Module bei einer Wiederholung einen übereinstimmenden Zustand vorfanden.
