Einführung
Ein wiederverwendbares Playbook sollte Umgebungsdaten verwenden, statt separate Entwicklungs- und Produktionsantworten fest zu codieren. Inventarauswahl, Variablengeltungsbereich und Ziel-Facts bestimmen, was jeder Knoten erhält.
Sie verwenden zwei Inventare, die unterschiedliche SSH-Knoten auswählen, speichern Gruppen- und Hostdaten neben der jeweiligen Quelle und erzeugen Einstellungen mit einem einzigen Playbook. Außerdem wenden Sie eine temporäre Überschreibung durch eine zusätzliche Variable an und stellen eine stabile Ausgangskonfiguration wieder her.
Inventardaten nach Umgebung trennen
In diesem Schritt geben Sie Entwicklung und Produktion separate Inventarquellen und Gruppenvariablenwerte.
Wechseln Sie ins Projekt:
cd /home/labex/project
Die Übung stellt zwei kleine Inventare bereit. Lesen Sie jedes, bevor Sie Automatisierung ausführen:
cat inventories/dev/hosts.ini
cat inventories/prod/hosts.ini
Die app-Gruppe von dev enthält web1; die app-Gruppe von prod enthält web2. Ihre Adressen und SSH-Einstellungen sind vorbereitet. Dies sind tatsächlich eigenständige Knoten, keine zwei Namen für localhost.
-i wählt für diesen Aufruf eine Inventarquelle aus und überschreibt das Standardinventar des Projekts. Zeigen Sie jede Umgebung separat vorab an:
ansible app -i inventories/dev/hosts.ini --list-hosts
ansible app -i inventories/prod/hosts.ini --list-hosts
Erwarten Sie web1 für dev und web2 für prod. Kombinieren Sie diese beiden Quellen nicht, um isolierte Umgebungen zu simulieren: Quellen können zusammengeführt werden, und derselbe Inventarhostname identifiziert weiterhin einen Host. Halten Sie den Aufruf jeder Umgebung ausdrücklich getrennt.
Eine Variable ist ein benannter Wert, den die Automatisierung verwendet. Eine YAML-Zuordnung verwendet Zeilen der Form name: value. Ansible lädt group_vars/app.yml neben einem Inventar für dessen app-Gruppe. Erstellen Sie für denselben Gruppennamen in jeder Umgebung unterschiedliche Daten:
cat > inventories/dev/group_vars/app.yml <<'EOF'
environment_label: development
release_channel: preview
EOF
cat > inventories/prod/group_vars/app.yml <<'EOF'
environment_label: production
release_channel: stable
EOF
Untersuchen Sie die aufgelösten Inventardaten. --list gibt JSON zurück, einschließlich eines Objekts _meta.hostvars für Hostwerte:
ansible-inventory -i inventories/dev/hosts.ini --list
ansible-inventory -i inventories/prod/hosts.ini --list
Der dev-Host sollte development/preview auflösen; der prod-Host production/stable. Eine Variablendatei ist nur wirksam, wenn das vorgesehene Inventar und die vorgesehene Gruppe sie tatsächlich laden.
Hostvariablen und tatsächliche Facts verwenden
In diesem Schritt überschreiben Sie den Gruppenwert eines Hosts und erzeugen aus Umgebungsdaten tatsächliche verwaltete Einstellungen.
Eine Datei unter host_vars wird nach einem Inventarhost benannt. Für denselben Host und Schlüssel überschreibt dessen Hostvariable die hier verwendete Gruppenvariable. Geben Sie dem Entwicklungs-Canary einen hostspezifischen Veröffentlichungskanal:
cat > inventories/dev/host_vars/web1.yml <<'EOF'
release_channel: canary
EOF
Entwicklung hat weiterhin environment_label development, aber web1 löst release_channel nun zu canary auf. Produktion bleibt stable. Bestätigen Sie die dev-Auflösung:
ansible-inventory -i inventories/dev/hosts.ini --list
Schreiben Sie ein wiederverwendbares Playbook für beide Inventare:
cat > deploy-info.yml <<'EOF'
- name: Configure environment-specific application settings
hosts: app
gather_facts: true
vars:
banner_prefix: Managed environment
tasks:
- name: Write settings from variables and facts
ansible.builtin.copy:
dest: /home/automation/app-settings.conf
content: |
[application]
environment={{ environment_label }}
channel={{ release_channel }}
host={{ inventory_hostname }}
distribution={{ ansible_facts.distribution }}
label={{ banner_prefix }}
mode: "0640"
EOF
vars definiert den Wert banner_prefix auf Play-Ebene. Innerhalb des copy-Inhalts fügt {{ variable_name }} zur Ausführungszeit einen Wert ein. Dies ist einfache Wertersetzung; eine spätere Übung verwaltet eigenständige Jinja-Vorlagen.
Das YAML-Zeichen | erhält den folgenden eingerückten Inhalt als mehrzeiligen Text einschließlich seines abschließenden Zeilenumbruchs. inventory_hostname ist der aktuelle Inventarname. Mit gather_facts true sammelt Ansible vor den Aufgaben Zieldaten; ansible_facts.distribution liefert die tatsächliche Betriebssystemdistribution. Dies sind Zieldaten, kein Fact über den Controller.
Prüfen Sie die Syntax und führen Sie dasselbe Playbook anschließend separat für jede Umgebung aus:
ansible-playbook -i inventories/dev/hosts.ini deploy-info.yml --syntax-check
ansible-playbook -i inventories/dev/hosts.ini deploy-info.yml
ansible-playbook -i inventories/prod/hosts.ini deploy-info.yml
Lesen Sie beide tatsächlichen Dateien über ihr jeweiliges Inventar:
ansible app -i inventories/dev/hosts.ini -m ansible.builtin.command -a 'cat /home/automation/app-settings.conf'
ansible app -i inventories/prod/hosts.ini -m ansible.builtin.command -a 'cat /home/automation/app-settings.conf'
Entwicklung sollte environment=development, channel=canary und host=web1 enthalten. Produktion sollte environment=production, channel=stable und host=web2 enthalten. Beide sollten distribution=Ubuntu und label=Managed environment enthalten. Das gemeinsame Playbook hat durch die Verwendung unterschiedlicher Daten unterschiedliche Zielinhalte erzeugt.
Einen Aufruf überschreiben und die Ausgangskonfiguration wiederherstellen
In diesem Schritt verwenden Sie eine zusätzliche Variable, ohne die gespeicherten Inventardaten zu bearbeiten, und kehren anschließend zu einer konvergierten Ausgangskonfiguration zurück.
-e übergibt für diese Ausführung eine zusätzliche Variable. Sie überschreibt die hier gezeigten Gruppen- und Hostwerte. Wählen Sie ausschließlich in der Entwicklung vorübergehend einen Hotfix-Kanal:
ansible-playbook -i inventories/dev/hosts.ini deploy-info.yml -e release_channel=hotfix
Lesen Sie die daraus entstandene dev-Konfiguration:
ansible app -i inventories/dev/hosts.ini -m ansible.builtin.command -a 'cat /home/automation/app-settings.conf'
Ihr Kanal sollte hotfix sein. Die Quelldateien group_vars und host_vars wurden von -e nicht bearbeitet, und Produktion wurde nicht ausgewählt.
Führen Sie den Aufruf ohne zusätzliche Variable aus, um den gespeicherten canary-Kanal von web1 wiederherzustellen:
ansible-playbook -i inventories/dev/hosts.ini deploy-info.yml
Zeigen Sie nun eine Vorschau beider Ausgangsumgebungen an:
ansible-playbook -i inventories/dev/hosts.ini deploy-info.yml --check
ansible-playbook -i inventories/prod/hosts.ini deploy-info.yml --check
Jeder ausgewählte Host sollte null ausstehende Änderungen und keine Fehler/unerreichbaren Ergebnisse melden. Die hier geübten begrenzten Prioritätsbeziehungen sind Gruppendaten, eine Hostüberschreibung und eine Überschreibung durch eine zusätzliche Variable. Komplexere Prioritätsregeln gehören nicht zu dieser Übung.
Zusammenfassung
Sie haben unterschiedliche Umgebungsinventare ausgewählt, Gruppendaten geladen, eine hostspezifische Überschreibung angewendet und mit einem gemeinsamen Playbook tatsächliche Ziel-Facts ausgegeben. Eine temporäre zusätzliche Variable änderte einen Aufruf, und anschließende Ausführungen mit den Ausgangsdaten brachten beide Umgebungen zu stabilen deklarierten Einstellungen zurück.
