Einführung
Ansible kann korrekt installiert sein und dennoch das falsche Inventar, den falschen Interpreter oder falsche Berechtigungen verwenden. Ein zuverlässiges Projekt legt diese Entscheidungen ausdrücklich fest und bestätigt ihre Wirkung auf tatsächlichen Zielen.
In dieser Übung erstellen Sie eine Projektkonfiguration, untersuchen die geladenen Werte, legen Ziel-Python über das Inventar fest und vergleichen gewöhnliche Ausführung mit ausdrücklicher Rechteerhöhung auf zwei vorbereiteten SSH-Knoten. Diese unabhängige Umgebung stellt Ansible und Verbindungen bereit; Paketinstallationen oder Änderungen am SSH-Server sind nicht erforderlich.
Die Projektkonfiguration erstellen und laden
In diesem Schritt erstellen Sie eine Projektkonfiguration und bestätigen, dass Ansible sie tatsächlich lädt.
Sie haben Ansible bereits in der vorherigen Übung installiert. Diese unabhängige Umgebung stellt die gemeinsam genutzte Kursinstallation bereit, damit Sie sich auf die Konfiguration konzentrieren können. Öffnen Sie das Terminal und wählen Sie den Arbeitsbereich aus:
cd /home/labex/project
Ansible verwendet eine einzige Konfigurationsdatei und wählt die erste verfügbare Datei aus ANSIBLE_CONFIG, der ansible.cfg im aktuellen Verzeichnis, der Konfiguration im Benutzerverzeichnis und der Systemkonfiguration aus. Ein Verzeichniswechsel kann daher ändern, welche Projektkonfiguration geladen wird. Eine Umgebungsvariable kann eine andere Datei auswählen, selbst wenn eine Projektdatei vorhanden ist.
Die vorbereitete connection-reference.cfg enthält die ursprünglichen Verbindungseinstellungen der Schulung. cat zeigt sie an:
cat connection-reference.cfg
Sie wählt das Projektinventar und eine Datei mit vertrauenswürdigen Hostschlüsseln aus. Die Übung hat Schlüssel und Knoten bereits erstellt; ändern Sie weder Ihre Plattformanmeldung noch den SSH-Server.
Erstellen Sie die folgende ansible.cfg. cat > schreibt die Standardeingabe in eine Datei und ersetzt vorhandenen Inhalt. <<'EOF' beginnt ein Here-Dokument: Fügen Sie alle Zeilen bis einschließlich des abschließenden EOF ein. Die Anführungszeichen um die Begrenzungsmarkierung erhalten den Text wörtlich. INI-Abschnittsnamen in eckigen Klammern gruppieren Einstellungen, und jede Zeile name = value legt eine Option fest.
cat > ansible.cfg <<'EOF'
[defaults]
inventory = /home/labex/project/inventory.ini
host_key_checking = True
interpreter_python = /usr/bin/python3
[privilege_escalation]
become = False
[ssh_connection]
ssh_args = -o UserKnownHostsFile=/home/labex/.local/share/ansible-course/known_hosts -o StrictHostKeyChecking=yes -o ControlMaster=auto -o ControlPersist=30s
EOF
inventory wählt die Hostliste aus. host_key_checking lässt die Prüfung der Serveridentität aktiviert. interpreter_python legt das standardmäßige Ziel-Python fest, nicht den Controller-Interpreter. become = False lässt gewöhnliche Aufgaben ohne erhöhte Rechte laufen. Die vorbereiteten ssh_args verwenden die known_hosts-Datei der Schulung, verlangen vertrauenswürdige Schlüssel und verwenden kurzlebige SSH-Verbindungen wieder.
Zeigen Sie Versions- und Konfigurationsinformationen an:
ansible --version
Suchen Sie nach config file = /home/labex/project/ansible.cfg. Der Modulpfad gehört in dieser Übung zur gemeinsam genutzten Kursinstallation; Ihre vorherige Installationsübung verwendete eine separate Lernumgebung.
ansible-config dump zeigt die wirksame Konfiguration. --only-changed beschränkt die Ausgabe auf Einstellungen, die vom Standard abweichen, und nennt ihre jeweilige Quelle:
ansible-config dump --only-changed
Achten Sie auf CONFIG_FILE() = /home/labex/project/ansible.cfg, eine projektbezogene DEFAULT_HOST_LIST und INTERPRETER_PYTHON mit dem Wert /usr/bin/python3. Die Ausgabe verwendet interne Optionsnamen, deren Schreibweise von der INI-Datei abweichen kann. Eine Datei lediglich zu lesen belegt nicht, dass Ansible sie geladen hat.
Testen Sie die Projektkonfiguration mit dem bereits bekannten Python-Ping-Modul:
ansible all -m ansible.builtin.ping
Sowohl web1 als auch web2 sollten pong zurückgeben. Führen Sie die Befehle weiterhin in diesem Arbeitsbereich aus, damit die vorgesehene Konfiguration aktiv bleibt.
Den Zielinterpreter im Inventar festlegen
In diesem Schritt legen Sie eine Verbindungsvariable für beide Hosts fest und verstehen deren Verhältnis zum Projektstandard.
Lesen Sie das vorbereitete Inventar:
cat inventory.ini
Es enthält zwei unterschiedliche ansible_host-Ziele, gefolgt von [all:vars]. Einstellungen nach diesem Abschnitt gelten für beide Hosts, darunter ansible_user=automation und der Pfad zum privaten Schulungsschlüssel. Sie beschreiben das SSH-Konto und die Authentifizierung auf den verwalteten Knoten.
Eine Verbindungsvariable namens ansible_python_interpreter überschreibt für ihre Hosts den Konfigurationsstandard interpreter_python. Verwenden Sie sie, wenn ein Inventar einen bestimmten Zielinterpreter benötigt. Ein korrekter Standardwert kann eine Inventarvariable, die auf eine fehlende ausführbare Datei verweist, nicht ausgleichen.
printf gibt Text aus; \n bedeutet einen Zeilenumbruch. >> hängt Inhalt an, ohne das bestehende Inventar zu ersetzen. Hängen Sie die Interpretervariable unter dem vorhandenen Abschnitt [all:vars] an:
printf '\nansible_python_interpreter=/usr/bin/python3\n' >> inventory.ini
Zeigen Sie das Inventar erneut an und suchen Sie die neue Einstellung unter [all:vars]:
cat inventory.ini
Die Python-Installation des Controllers bleibt unverändert. Dieser Pfad wird separat innerhalb jedes verwalteten Knotens ausgeführt. Testen Sie beide Ziele:
ansible all -m ansible.builtin.ping
Jedes sollte weiterhin pong und changed: false zurückgeben. Sie verfügen nun zusätzlich zu einem Projektstandard über eine funktionierende inventarspezifische Interpretereinstellung. Die Konfigurationsausgabe beschreibt Standardwerte; Verbindungsvariablen können diese während der Ausführung überschreiben.
Gewöhnliche Ausführung und Ausführung mit erhöhten Rechten vergleichen
In diesem Schritt beobachten Sie den tatsächlichen entfernten Benutzer vor und nach einer ausdrücklichen Rechteerhöhung.
Das Modul command führt ein Programm auf dem Ziel aus. -a übergibt Modulargumente; setzen Sie id -un in Anführungszeichen, damit die Shell Programm und Option als eine Argumentzeichenfolge übergibt. id -un gibt den Namen des effektiven Benutzers aus:
ansible all -m ansible.builtin.command -a 'id -un'
Beide Hosts sollten automation melden. Dies ist das vom Inventar ausgewählte Konto auf den verwalteten Knoten, nicht der Controller-Benutzer labex.
--become fordert für diesen Aufruf eine Rechteerhöhung an. Die Schulungsknoten erlauben dem Konto automation die Verwendung von sudo ohne Passwort; Ihr Projektstandard lässt die Rechteerhöhung für gewöhnliche Ausführungen weiterhin ausgeschaltet:
ansible all -m ansible.builtin.command -a 'id -un' --become
Beide Hosts sollten root melden. Das command-Modul von Ansible meldet normalerweise CHANGED, wenn es einen Befehl ausführt, selbst bei dieser ausschließlich lesenden Identitätsabfrage. Diese Kennzeichnung allein belegt keine Änderung der Systemkonfiguration; werten Sie die tatsächliche Standardausgabe und den Rückgabestatus aus.
Wiederholen Sie den Aufruf ohne --become:
ansible all -m ansible.builtin.command -a 'id -un'
Die Ausgabe lautet wieder automation. Die Rechteerhöhung war für einen Aufruf ausdrücklich angefordert und keine dauerhafte Änderung des Anmeldekontos. Lassen Sie die globale Rechteerhöhung deaktiviert und die Kontokonfiguration der Plattform unverändert.
Zusammenfassung
Sie haben eine Projektkonfiguration erstellt und geladen, wirksame Standardwerte untersucht und über das Inventar einen Zielinterpreter mit höherer Priorität angegeben. Die tatsächliche Modulausführung über SSH bestätigte beide Ziele, und Identitätsabfragen zeigten den Unterschied zwischen gewöhnlichem Zugriff als automation und ausdrücklichem become. Diese Prüfungen bilden eine Grundlage zur Diagnose von Verbindungseinstellungen, ohne den Plattformzugriff zu ändern.
