Einführung
Automatisierung ist nur dann sicher, wenn sie die vorgesehenen Hosts erreicht. Zwei Aliase für einen Rechner, ein fehlender Host oder eine zu breite Auswahl können einen erfolgreichen Befehl irreführend erscheinen lassen.
In dieser Übung ordnen Sie zwei eigenständige SSH-Ziele den Gruppen canary und stable zu, untersuchen eine übergeordnete Gruppe, zeigen Hostmuster vorab an und erstellen eine Markierungsdatei nur auf dem Canary-Host. Ansible und die Schulungsverbindungen sind bereits vorbereitet; Sie arbeiten mit dem Inventar und dem Geltungsbereich von Befehlen.
Hosts in Gruppen organisieren
In diesem Schritt gruppieren Sie die beiden vorhandenen SSH-Hosts, ohne ihre Identitäten oder Adressen zu duplizieren.
Öffnen Sie das Terminal und wechseln Sie ins Projekt:
cd /home/labex/project
Lesen Sie das bereitgestellte Inventar vor der Bearbeitung:
cat inventory.ini
Es definiert web1 und web2 mit unterschiedlichen ansible_host-Werten. Behalten Sie diese Zeilen und die Verbindungseinstellungen unter [all:vars] bei. Inventarnamen identifizieren Hosts; derselbe Name in mehreren Gruppen erstellt keinen weiteren Server.
Eine Gruppe beschreibt eine Menge von Hosts. Wir verwenden canary für den ersten Host, stable für den zweiten und webservers als übergeordnete Gruppe, die beide Gruppen enthält. Hängen Sie diese Abschnitte an. >> erhält die bestehende Datei, und die in Anführungszeichen gesetzte Here-Dokument-Markierung bewahrt den eingefügten Text wörtlich:
cat >> inventory.ini <<'EOF'
[canary]
web1
[stable]
web2
[webservers:children]
canary
stable
EOF
[canary] und [stable] enthalten Hostnamen. Ein Abschnitt mit der Endung :children enthält Gruppennamen; webservers übernimmt daher die Hosts von canary und stable. Tragen Sie unter diesen Gruppen keine neuen Zieladressen ein.
ansible-inventory --graph stellt die aufgelöste Zugehörigkeit grafisch dar:
ansible-inventory --graph
Erwarten Sie web1 unter canary und web2 unter stable, wobei beide Gruppen unter webservers stehen. Die besonderen Einträge all und ungrouped können ebenfalls erscheinen. Ein Host kann in mehreren Zweigen der Darstellung auftauchen und dennoch ein einziger Inventarhost bleiben.
Ein Hostmuster wählt die Ziele für einen Befehl aus. Zeigen Sie die übergeordnete Gruppe vorab an, ohne ein Modul auszuführen:
ansible webservers --list-hosts
Erwarten Sie genau web1 und web2. In einem Muster bedeutet :& Schnittmenge: Es werden Hosts ausgewählt, die zu beiden Teilen gehören. Setzen Sie es in Anführungszeichen, damit die Shell & nicht interpretiert:
ansible 'webservers:&canary' --list-hosts
Erwarten Sie nur web1. Diese Vorschau bietet die Gelegenheit, einen Auswahlfehler zu erkennen, bevor Sie einen Host ändern.
Eine Änderung auf den Canary-Host begrenzen
In diesem Schritt führen Sie eine kleine Änderung auf dem Canary-Host durch und lassen dabei den stabilen Host und den Controller unverändert.
Das erste Muster eines Befehls wählt eine Ausgangsmenge aus. --limit schränkt sie weiter ein; es fügt keine Hosts außerhalb dieser Menge hinzu. Zeigen Sie eine eingeschränkte Auswahl vor ihrer Verwendung an:
ansible webservers --limit canary --list-hosts
Erwarten Sie einen Host, web1. Eine Einschränkung ohne Treffer würde keine erfolgreiche Änderung nachweisen, selbst wenn der Befehl ohne Modulfehler endet.
Verwenden Sie das command-Modul aus der vorherigen Übung, um touch auszuführen. Dieser Linux-Befehl erstellt eine leere Datei, falls sie nicht existiert, und aktualisiert andernfalls ihren Zeitstempel. Die Markierungsdatei gehört in das Benutzerverzeichnis des verwalteten Benutzers automation. Der in Anführungszeichen gesetzte Wert für -a hält ausführbare Datei und Pfad zusammen:
ansible webservers --limit canary -m ansible.builtin.command -a 'touch /home/automation/canary-ready'
Erwarten Sie ausschließlich für web1 ein erfolgreiches Befehlsergebnis. Diese Aktion ist bewusst eine einfache Übung zum Geltungsbereich; touch kann bei wiederholten Ausführungen Zeitstempel aktualisieren, sein Status CHANGED ist daher keine Demonstration von Idempotenz.
Untersuchen Sie die sichtbaren Dateien im Benutzerverzeichnis jedes verwalteten Benutzers. ls listet das Verzeichnis auf jedem Ziel auf, weil es durch das command-Modul von Ansible ausgeführt wird:
ansible webservers -m ansible.builtin.command -a 'ls /home/automation'
Das Ergebnis von web1 sollte canary-ready enthalten. Das Ergebnis von web2 sollte diesen Namen nicht enthalten; seine Standardausgabe kann leer sein. Dies sind entfernte Verzeichnisse, getrennt vom Arbeitsbereich Ihres Controllers.
Untersuchen Sie abschließend das aktuelle Verzeichnis des Controllers:
ls
Es sollte die Projektkonfiguration und das Inventar zeigen, ohne eine lokale Markierungsdatei canary-ready. Sie haben einen tatsächlichen verwalteten Host ausgewählt, statt eine Änderung auf dem Controller vorzunehmen. Spätere Übungen verwenden Module, die den Dateizustand direkt deklarieren, und überprüfen anschließend die Idempotenz.
Zusammenfassung
Sie haben zwei eigenständige Inventaridentitäten erhalten, Hosts und Untergruppen organisiert, ein in Anführungszeichen gesetztes Schnittmengenmuster vorab angezeigt und einen Befehl mit --limit eingeschränkt. Der tatsächliche Zielzustand zeigte die Markierungsdatei ausschließlich auf dem Canary-Host, während der stabile Host und der Controller von der Änderung unberührt blieben.
