Einführung
Sie bereiten einen Ansible-Steuerknoten zur Verwaltung zweier Linux-Server vor. Bevor Sie Automatisierung schreiben, benötigen Sie eine verlässliche Installation und den Nachweis, dass der Controller Python-Module auf beiden Zielen ausführen kann.
In dieser Übung erstellen Sie eine virtuelle Projektumgebung, installieren Ansible Core aus einem Offline-Paketcache, aktivieren es im Terminal und testen mit einem bereitgestellten Inventar zwei echte SSH-Verbindungen. Grundkenntnisse der Befehlszeile genügen; Ansible-Vorkenntnisse sind nicht erforderlich.
Eine isolierte Controller-Umgebung erstellen
In diesem Schritt erstellen Sie die Python-Umgebung für Ihre eigene Ansible-Installation.
Ansible läuft auf einem Steuerknoten und verbindet sich über SSH mit verwalteten Knoten. Ihr LabEx-Terminal ist der Ubuntu-Steuerknoten. Zwei vorbereitete Linux-Container, web1 und web2, dienen als separate verwaltete Knoten: Sie haben unterschiedliche Adressen, Hostnamen und Dateisysteme, teilen sich aber den Kernel der VM. Sie benötigen weder Docker-Befehle noch Änderungen an den Anmeldeeinstellungen der Plattform.
Eine virtuelle Python-Umgebung (virtual environment) trennt Projektpakete vom Betriebssystem und den gemeinsam genutzten Kurswerkzeugen. Das Image enthält bereits einen gemeinsam genutzten Ansible-Befehl für die Infrastruktur; Ihre Aufgabe besteht jedoch darin, eine separate Kopie in /home/labex/project/.venv zu installieren.
Öffnen Sie das Terminal. Wählen Sie mit cd das Projektverzeichnis aus; nachfolgende relative Pfade werden von hier aus aufgelöst:
cd /home/labex/project
pwd gibt Ihr aktuelles Arbeitsverzeichnis aus:
pwd
Die Ausgabe sollte /home/labex/project lauten. Verwenden Sie dieses Verzeichnis während der gesamten Übung.
ansible-python wählt das vorbereitete Kurs-Python aus. --version zeigt dessen Version an:
ansible-python --version
Erwarten Sie Python 3.12.15. Das System-Python des Steuerknotens bleibt davon getrennt; ersetzen Sie es nicht.
Die Option -m venv führt das Python-Modul für virtuelle Umgebungen aus. Das letzte Argument .venv benennt das Verzeichnis, das innerhalb des Projekts erstellt werden soll. Ein führender Punkt verbirgt es in gewöhnlichen Verzeichnisauflistungen:
ansible-python -m venv .venv
Dies endet normalerweise ohne Ausgabe. Es erstellt die Umgebung und pip, das Paketinstallationsprogramm von Python; Ansible ist damit noch nicht installiert.
Führen Sie das Python der neuen Umgebung über seinen relativen Pfad aus. Damit bestätigen Sie, dass Sie den isolierten Interpreter auch ohne vorherige Aktivierung verwenden können:
.venv/bin/python --version
Es sollte ebenfalls Python 3.12.15 ausgeben. Die beiden Python-Befehle verwenden dieselbe Python-Version, aber in .venv installierte Pakete gehören zu diesem Projekt.
Ansible offline installieren und aktivieren
In diesem Schritt installieren Sie die festgelegte Version von Ansible Core in .venv und sorgen dafür, dass das Terminal sie verwendet.
Ansible Core stellt den Befehl ansible und die in diesem Kurs verwendeten integrierten Module bereit. Vorbereitete Wheel-Dateien sind lokale Python-Pakete; die Installation hängt daher nicht von Downloads aus dem Internet ab. Die Requirements-Datei legt kompatible, fest vorgegebene Versionen fest.
Der folgende Befehl führt pip mit dem Projekt-Python aus. install installiert Pakete, --no-index deaktiviert Online-Paketindizes, --find-links wählt das lokale Wheel-Verzeichnis aus und -r liest die Requirements-Datei:
.venv/bin/python -m pip install --no-index --find-links /opt/labex/ansible-course/wheels -r /opt/labex/ansible-course/requirements.txt
Die Ausgabe listet die aus dem lokalen Cache verarbeiteten Pakete auf und endet mit Successfully installed ..., einschließlich ansible-core-2.21.5. Bei einer erneuten Installation kann stattdessen Requirement already satisfied erscheinen.
Die Aktivierung setzt das Befehlsverzeichnis der Umgebung an die erste Stelle im Suchpfad dieser Shell. source führt das Aktivierungsskript im aktuellen Terminal aus, sodass die Änderung für spätere Befehle bestehen bleibt:
source .venv/bin/activate
Die Eingabeaufforderung beginnt jetzt möglicherweise mit (.venv). Das Terminal verwendet zsh; rehash aktualisiert nach der Installation neuer ausführbarer Dateien die zwischengespeicherten Befehlspfade:
rehash
command -v zeigt, welche ausführbare Datei ein Befehlsname auswählt:
command -v ansible
Erwarten Sie /home/labex/project/.venv/bin/ansible. Ein gemeinsam genutzter Pfad wie /usr/local/bin/ansible belegt nicht, dass Ihre Projektinstallation aktiv ist. Wenn Sie ein neues Terminal öffnen, kehren Sie zum Projekt zurück, aktivieren Sie die Umgebung erneut und führen Sie rehash aus.
Prüfen Sie nun die ausgeführte Ansible-Version:
ansible --version
Achten Sie in der Ausgabe auf diese Felder:
ansible [core 2.21.5]
config file = /home/labex/project/ansible.cfg
...
ansible python module location = /home/labex/project/.venv/lib/python3.12/site-packages/ansible
executable location = /home/labex/project/.venv/bin/ansible
python version = 3.12.15 ...
...
Die Pfade der ausführbaren Datei und des Moduls zeigen, dass Sie die Projektinstallation ausführen. Die Konfigurationsdatei wird von der Übung bereitgestellt; in der nächsten Themengruppe lernen Sie, sie zu konfigurieren.
Abschließend prüft der pip-Befehl check, ob die Abhängigkeiten der installierten Pakete kompatibel sind:
.venv/bin/python -m pip check
Erwarten Sie No broken requirements found. Sie verfügen nun über einen funktionierenden Controller, ohne Systempakete oder die gemeinsam genutzte Werkzeugumgebung zu ändern.
Beide verwalteten Knoten verbinden
In diesem Schritt untersuchen Sie das vorbereitete Inventar und führen auf beiden SSH-Zielen einen Python-basierten Verbindungstest aus.
Ein Inventar teilt Ansible mit, welche Hosts es verwalten kann. cat gibt den Inhalt einer Datei aus; lesen Sie das bereitgestellte Projektinventar:
cat inventory.ini
Es hat folgende Form:
web1 ansible_host=...
web2 ansible_host=...
[all:vars]
ansible_user=automation
ansible_ssh_private_key_file=/home/labex/.local/share/ansible-course/id_ed25519
ansible_python_interpreter=/usr/bin/python3
Die tatsächlichen Adressen ersetzen ...; verwenden Sie die vorhandenen Werte. web1 und web2 sind Inventarnamen, während ansible_host das jeweilige SSH-Ziel angibt. [all:vars] wendet die folgenden Verbindungseinstellungen auf beide Hosts an. automation ist das gewöhnliche Benutzerkonto innerhalb der verwalteten Knoten, nicht Ihr labex-Anmeldekonto auf dem Steuerknoten. Die Übung stellt einen neuen Schulungsschlüssel und vertrauenswürdige Hostschlüssel bereit; Sie müssen weder Schlüssel erzeugen noch SSH-Einstellungen ändern.
Der Ziel-Python-Pfad /usr/bin/python3 gehört zum jeweiligen verwalteten Knoten. Er unterscheidet sich vom Projekt-Python des Controllers: Die meisten Ansible-Module benötigen Python sowohl auf dem Ziel als auch auf dem Controller.
Die bereitgestellte ansible.cfg wählt dieses Inventar aus, wenn Befehle aus dem Projekt ausgeführt werden. all wählt jeden Inventarhost aus; --list-hosts zeigt diese Auswahl vorab an, ohne ein Modul auszuführen:
ansible all --list-hosts
Erwarten Sie genau diese beiden Hostnamen; ihre Reihenfolge kann abweichen:
hosts (2):
web1
web2
Die Option -m wählt ein Modul aus, eine Arbeitseinheit von Ansible. ansible.builtin.ping ist der vollständig qualifizierte Name des integrierten Ping-Moduls. Es verbindet sich über SSH und führt Python auf jedem Ziel aus; es ist kein ICMP-Netzwerk-Ping:
ansible all -m ansible.builtin.ping
Beide Hosts sollten Ergebnisse mit diesen beständigen Feldern zurückgeben; die Reihenfolge der Ergebnisse kann abweichen:
web1 | SUCCESS => {
"changed": false,
"ping": "pong"
}
web2 | SUCCESS => {
"changed": false,
"ping": "pong"
}
Ein pong belegt, dass SSH-Authentifizierung und Python-Ausführung auf dem Ziel für diesen Host funktioniert haben. changed: false bedeutet, dass dieser Verbindungstest keine Konfigurationsänderung angefordert hat. Ein erfolgreicher Host reicht nicht aus: Achten Sie auf beide Namen. UNREACHABLE bedeutet, dass die Verbindung fehlgeschlagen ist; FAILED bedeutet, dass eine Aufgabe fehlgeschlagen ist. Auch eine leere Hostliste weist keine funktionierende Verbindung nach.
Falls der Befehl fehlschlägt, prüfen Sie zunächst, ob Sie noch im Projektverzeichnis sind, ob command -v ansible die Datei .venv/bin/ansible auswählt und ob das bereitgestellte Inventar weiterhin beide ursprünglichen Ziele enthält. Lassen Sie die Anmelde-, SSH- und sudo-Konfiguration der Plattform unverändert.
Zusammenfassung
Sie haben eine isolierte Controller-Umgebung erstellt, Ansible-Core-Pakete in festgelegten Versionen aus einem Offline-Cache installiert, die Projektbefehle aktiviert und ihre Pfade sowie Abhängigkeiten überprüft. Sie haben das bereitgestellte Inventar gelesen und von jedem eigenständigen, über SSH verwalteten Knoten ein Python-pong erhalten. Sie können nun Controller-Python, Ziel-Python und Inventarnamen unterscheiden, bevor Sie die Projektkonfiguration kennenlernen.
