Verwaltung von Variablen und Fakten in RHEL mit Ansible

Einführung

In diesem Lab lernen Sie grundlegende Techniken zur Verwaltung von Variablen, Fakten und Geheimnissen innerhalb von Ansible-Playbooks auf einem Red Hat Enterprise Linux (RHEL)-System kennen. Sie werden erforschen, wie Sie Ihre Automatisierung flexibler und leistungsfähiger gestalten können, indem Sie Playbook-Variablen verwenden, Systeminformationen mit integrierten und benutzerdefinierten Ansible-Fakten sammeln und sensible Daten wie Passwörter mit Ansible Vault schützen.

Durch eine Reihe praktischer Schritte erstellen Sie ein Playbook zur Bereitstellung und Konfiguration eines Apache-Webservers. Sie beginnen mit der Definition einfacher Variablen für den Paketnamen und die Webinhalte, nutzen dann benutzerdefinierte Fakten, um die Konfiguration des Webservers dynamisch zu aktualisieren. Abschließend verwenden Sie Ansible Vault, um sicher einen neuen Systembenutzer mit einem verschlüsselten Passwort zu erstellen, führen das vollständige Playbook aus und überprüfen, ob alle Konfigurationen erfolgreich angewendet wurden.

Playbook-Variablen definieren und zur Bereitstellung eines Apache-Webservers verwenden

In diesem Schritt lernen Sie, wie Sie Variablen in einem Ansible-Playbook verwenden. Variablen sind entscheidend, um Ihre Automatisierung flexibel, wiederverwendbar sowie leichter lesbar und wartbar zu machen. Anstatt Werte wie Paketnamen oder Dateipfade direkt in Ihre Aufgaben (Tasks) fest zu kodieren, können Sie diese als Variablen definieren und im gesamten Playbook referenzieren. Wir erstellen ein einfaches Playbook, das Variablen verwendet, um den Apache-Webserver (httpd) zu installieren und eine grundlegende Webseite bereitzustellen.

1. In das Projektverzeichnis navigieren

   Stellen Sie zunächst sicher, dass Sie sich im richtigen Arbeitsverzeichnis befinden. Ihre gesamte Arbeit für dieses Lab erfolgt im Verzeichnis ~/project, das bereits für Sie erstellt wurde.

   cd ~/project
   

   Installieren Sie das Paket ansible-core.

   sudo dnf install -y ansible-core
   

2. Das Ansible-Playbook erstellen

   Lassen Sie uns nun unsere Playbook-Datei erstellen. Wir nennen sie playbook.yml. Sie können einen Befehlszeilen-Texteditor wie nano verwenden, um die Datei zu erstellen und zu bearbeiten.

   nano playbook.yml
   

   Dieser Befehl öffnet eine leere Datei im nano-Editor. Fügen Sie nun den ersten Teil des Playbooks hinzu. Dieser Abschnitt definiert den Namen des Plays, den Ziel-Host (localhost, da wir es auf derselben Maschine ausführen) und einen vars-Abschnitt, in dem wir unsere Variablen definieren.

   ---
   - name: Deploy Apache using variables
     hosts: localhost
     become: true
     vars:
       web_pkg: httpd
       web_content: "Hello from Ansible Variables"
   

   Hier ist eine Aufschlüsselung der Playbook-Struktur:

   • hosts: localhost: Gibt an, dass das Playbook auf der lokalen Maschine ausgeführt werden soll.
   • become: true: Weist Ansible an, eine Privilegieneskalation (entspricht sudo) für die Aufgaben zu verwenden, was für die Installation von Software erforderlich ist.
   • vars: Dies ist ein Dictionary, in dem wir unsere Schlüssel-Wert-Paare für Variablen definieren. Wir haben web_pkg für den Paketnamen und web_content für den Inhalt unserer Test-Webseite definiert.

3. Aufgaben zum Playbook hinzufügen

   Fügen Sie als Nächstes unterhalb des vars-Abschnitts die tasks hinzu, die diese Variablen verwenden werden. Die erste Aufgabe installiert das Apache-Paket, und die zweite erstellt eine index.html-Datei. Fügen Sie den folgenden tasks-Block zu Ihrer playbook.yml-Datei hinzu, während Sie sich noch im nano-Editor befinden.

   tasks:
     - name: Install the latest version of Apache
       ansible.builtin.dnf:
         name: "{{ web_pkg }}"
         state: latest
   
     - name: Create a basic index.html file
       ansible.builtin.copy:
         content: "{{ web_content }}"
         dest: /var/www/html/index.html
   

   Beachten Sie, wie wir {{ variable_name }} verwenden, um auf die zuvor definierten Variablen zu verweisen. Dies ist Jinja2-Templating, das Ansible für Variablen verwendet. Dies macht die Aufgabendefinitionen generisch; wenn Sie stattdessen Nginx installieren wollten, müssten Sie nur die Variable web_pkg ändern, nicht die Aufgabe selbst.

4. Das Playbook überprüfen und speichern

   Ihre vollständige playbook.yml-Datei sollte nun wie folgt aussehen. Überprüfen Sie den Inhalt und die Einrückung, da YAML sehr empfindlich auf Abstände reagiert.

   ---
   - name: Deploy Apache using variables
     hosts: localhost
     become: true
     vars:
       web_pkg: httpd
       web_content: "Hello from Ansible Variables"
     tasks:
       - name: Install the latest version of Apache
         ansible.builtin.dnf:
           name: "{{ web_pkg }}"
           state: latest
   
       - name: Create a basic index.html file
         ansible.builtin.copy:
           content: "{{ web_content }}"
           dest: /var/www/html/index.html
   

   Um die Datei in nano zu speichern, drücken Sie Ctrl+X, dann Y, um die Änderungen zu bestätigen, und schließlich Enter, um die Datei unter dem Namen playbook.yml zu schreiben.

5. Die Playbook-Syntax überprüfen

   Bevor Sie ein Playbook ausführen, ist es immer eine gute Praxis, dessen Syntax auf Fehler zu prüfen.

   ansible-playbook --syntax-check playbook.yml
   

   Wenn die Syntax korrekt ist, sehen Sie den Dateipfad des Playbooks als Ausgabe, was bestätigt, dass es gültig ist:

   playbook: playbook.yml
   

   Falls Sie Fehler sehen, öffnen Sie die Datei erneut mit nano playbook.yml und beheben Sie diese. Achten Sie besonders auf die korrekte Einrückung (normalerweise zwei Leerzeichen).

6. Das Playbook ausführen

   Führen Sie nun das Playbook aus. Ansible verbindet sich mit localhost, liest die Variablen und führt die Aufgaben aus.

   ansible-playbook playbook.yml
   

   Sie sollten eine Ausgabe sehen, die die erfolgreiche Ausführung jeder Aufgabe anzeigt. Der Status changed bedeutet, dass Ansible eine Änderung am System vorgenommen hat, wie z. B. die Installation eines Pakets oder das Erstellen einer Datei.

   PLAY [Deploy Apache using variables] *******************************************
   
   TASK [Gathering Facts] *********************************************************
   ok: [localhost]
   
   TASK [Install the latest version of Apache] ************************************
   changed: [localhost]
   
   TASK [Create a basic index.html file] ******************************************
   changed: [localhost]
   
   PLAY RECAP *********************************************************************
   localhost                  : ok=3    changed=2    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
   

   Wenn Sie das Playbook ein zweites Mal ausführen, sollten die Aufgaben ok anstelle von changed melden, da das Paket bereits installiert ist und die Datei bereits den korrekten Inhalt hat. Dies demonstriert die Idempotenz von Ansible.

7. Die Konfiguration manuell überprüfen

   Obwohl das Playbook abgeschlossen ist, können Sie manuell überprüfen, ob die Aufgaben wie erwartet funktioniert haben. Überprüfen Sie zunächst, ob das Paket httpd installiert wurde:

   rpm -q httpd
   

   Die Ausgabe sollte den Paketnamen und die Version anzeigen:

   httpd-2.4.57-7.el9.x86_64
   

   Überprüfen Sie als Nächstes den Inhalt der Datei index.html:

   cat /var/www/html/index.html
   

   Die Ausgabe sollte mit dem Wert Ihrer web_content-Variable übereinstimmen:

   Hello from Ansible Variables
   

   Sie haben erfolgreich Variablen in einem Ansible-Playbook verwendet, um ein System zu konfigurieren.

Systeminformationen mit Ansible Facts anzeigen

In diesem Schritt erkunden Sie Ansible Facts. Facts sind Informationen, die Ansible über die von ihm verwalteten Systeme (in diesem Fall localhost) sammelt. Diese Informationen umfassen Details wie das Betriebssystem, Netzwerkschnittstellen, Arbeitsspeicher und vieles mehr. Standardmäßig sammelt Ansible Facts zu Beginn jedes Plays und stellt sie in einer speziellen Variable namens ansible_facts zur Verfügung. Die Verwendung von Facts ermöglicht es Ihnen, dynamische Playbooks zu erstellen, die sich an die Umgebung anpassen, in der sie ausgeführt werden.

1. In das Projektverzeichnis navigieren

   Stellen Sie zunächst sicher, dass Sie sich im Verzeichnis ~/project befinden, in dem Sie das neue Playbook erstellen werden.

   cd ~/project
   

2. Ein Playbook zum Anzeigen aller Facts erstellen

   Beginnen wir mit der Erstellung eines Playbooks, das einfach alle Facts anzeigt, die Ansible über Ihr System sammeln kann. Dies gibt Ihnen eine Vorstellung von der enormen Menge an verfügbaren Informationen. Verwenden Sie nano, um eine neue Datei namens display_facts.yml zu erstellen.

   nano display_facts.yml
   

   Fügen Sie im nano-Editor den folgenden Inhalt hinzu. Dieses Playbook zielt auf localhost ab und verwendet das Modul ansible.builtin.debug, um den Inhalt der Variable ansible_facts auszugeben.

   ---
   - name: Display all Ansible facts
     hosts: localhost
     tasks:
       - name: Print all available facts
         ansible.builtin.debug:
           var: ansible_facts
   

   Speichern Sie die Datei und beenden Sie nano durch Drücken von Ctrl+X, dann Y und Enter.

3. Das Playbook ausführen

   Führen Sie nun das Playbook aus, um das Ergebnis zu sehen.

   ansible-playbook display_facts.yml
   

   Die Ausgabe wird sehr lang sein, da Ansible viele Daten sammelt. Es wird eine große JSON-Struktur sein, die alle Systemdetails enthält. Dies ist zu erwarten.

   PLAY [Display all Ansible facts] ***********************************************
   
   TASK [Gathering Facts] *********************************************************
   ok: [localhost]
   
   TASK [Print all available facts] ***********************************************
   ok: [localhost] => {
       "ansible_facts": {
           "ansible_all_ipv4_addresses": [
               "172.17.0.2"
           ],
           "ansible_all_ipv6_addresses": [
               "fe80::42:acff:fe11:2"
           ],
           "ansible_apparmor": {
               "status": "disabled"
           },
           "ansible_architecture": "x86_64",
           "ansible_bios_date": "01/01/2011",
           "ansible_bios_version": "1.0",
           "ansible_cmdline": {
               "BOOT_IMAGE": "/boot/vmlinuz-5.14.0-427.16.1.el9_4.x86_64",
               "root": "UUID=...",
               "ro": true
           },
           "ansible_date_time": {
               "date": "2024-05-21",
               "day": "21",
               "epoch": "1716298855",
               ...
           },
           "ansible_distribution": "RedHat",
           "ansible_distribution_major_version": "9",
           "ansible_distribution_version": "9.4",
           ...
       }
   }
   
   PLAY RECAP *********************************************************************
   localhost                  : ok=2    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
   

4. Ein Playbook zum Anzeigen spezifischer Facts erstellen

   Das Anzeigen aller Facts ist nützlich für die Erkundung, aber in den meisten Fällen benötigen Sie nur bestimmte Informationen. Lassen Sie uns ein weiteres Playbook, display_specific_facts.yml, erstellen, um eine formatierte Nachricht mit nur wenigen Schlüsselfakten anzuzeigen.

   nano display_specific_facts.yml
   

   Fügen Sie den folgenden Inhalt hinzu. Dieses Playbook verwendet den Parameter msg des debug-Moduls, um eine benutzerdefinierte Zeichenfolge auszugeben. Wir greifen auf einzelne Facts mithilfe der Klammernotation zu, wie ansible_facts['distribution'].

   ---
   - name: Display specific Ansible facts
     hosts: localhost
     tasks:
       - name: Print a summary of system facts
         ansible.builtin.debug:
           msg: >
             The operating system is {{ ansible_facts['distribution'] }}
             version {{ ansible_facts['distribution_major_version'] }}.
             It has {{ ansible_facts['processor_cores'] }} processor cores and
             {{ ansible_facts['memtotal_mb'] }} MB of total memory.
   

   Das Zeichen > in msg: > ist ein YAML-Feature, das es Ihnen ermöglicht, eine mehrzeilige Zeichenfolge sauberer zu schreiben. Speichern Sie die Datei und beenden Sie nano.

5. Das Playbook für spezifische Facts ausführen

   Führen Sie nun dieses neue Playbook aus.

   ansible-playbook display_specific_facts.yml
   

   Die Ausgabe wird viel sauberer und lesbarer sein und nur die von Ihnen angeforderten Informationen anzeigen.

   PLAY [Display specific Ansible facts] ******************************************
   
   TASK [Gathering Facts] *********************************************************
   ok: [localhost]
   
   TASK [Print a summary of system facts] *****************************************
   ok: [localhost] => {
       "msg": "The operating system is RedHat version 9. It has 2 processor cores and 3925 MB of total memory."
   }
   
   PLAY RECAP *********************************************************************
   localhost                  : ok=2    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
   

   Dies zeigt, wie Sie Ansible Facts nutzen können, um Ihre Playbooks auf die Umgebung aufmerksam zu machen, in der sie ausgeführt werden, was eine intelligentere und bedingte Automatisierung ermöglicht.

Webserver mit benutzerdefinierten Fakten vom verwalteten Host konfigurieren

In diesem Schritt lernen Sie, wie Sie benutzerdefinierte Fakten (Custom Facts) verwenden. Während Ansible automatisch eine breite Palette von Standard-Facts sammelt, können Sie auch Ihre eigenen definieren. Diese werden als "lokale Fakten" oder "benutzerdefinierte Fakten" bezeichnet. Dies ist ein leistungsstarkes Feature, das es Ihnen ermöglicht, spezifische Informationen von einem verwalteten Host an Ihre Playbooks zu übermitteln, wie z. B. Anwendungseinstellungen oder hardwarespezifische Daten, die Ansible nicht standardmäßig sammelt.

Ansible sucht auf dem verwalteten Host im Verzeichnis /etc/ansible/facts.d nach benutzerdefinierten Fakten. Jede Datei in diesem Verzeichnis mit der Endung .fact wird verarbeitet. Diese Dateien können einfache Textdateien im INI-Stil oder JSON-Dateien sein.

1. Das Verzeichnis für benutzerdefinierte Fakten erstellen

   Zuerst müssen Sie das Verzeichnis erstellen, in dem Ansible nach benutzerdefinierten Faktendateien sucht. Da es sich um ein Systemverzeichnis handelt, müssen Sie sudo verwenden, um es zu erstellen.

   sudo mkdir -p /etc/ansible/facts.d
   

   Das Flag -p stellt sicher, dass der Befehl keinen Fehler zurückgibt, falls das Verzeichnis bereits existiert.

2. Eine benutzerdefinierte Faktendatei erstellen

   Lassen Sie uns nun eine benutzerdefinierte Faktendatei erstellen, um eine Willkommensnachricht für unseren Webserver zu definieren. Wir erstellen eine Datei im INI-Format namens web_config.fact im Verzeichnis /etc/ansible/facts.d.

   sudo nano /etc/ansible/facts.d/web_config.fact
   

   Fügen Sie den folgenden Inhalt zur Datei hinzu. Dies definiert einen Abschnitt [webserver] mit einem Schlüssel welcome_message.

   [webserver]
   welcome_message = Welcome to the server configured by Custom Facts!
   

   Speichern Sie die Datei und beenden Sie nano durch Drücken von Ctrl+X, dann Y und Enter.

3. Ein Playbook zur Verwendung des benutzerdefinierten Fakts erstellen

   Mit dem benutzerdefinierten Fakt an Ort und Stelle können wir nun ein Playbook erstellen, das diesen Fakt liest und ihn zur Konfiguration der Startseite unseres Webservers verwendet. Erstellen Sie in Ihrem Verzeichnis ~/project ein neues Playbook namens configure_web.yml.

   cd ~/project
   nano configure_web.yml
   

   Fügen Sie den folgenden Inhalt zum Playbook hinzu. Dieses Playbook aktualisiert die Datei /var/www/html/index.html mit der Nachricht, die in unserem benutzerdefinierten Fakt definiert ist.

   ---
   - name: Configure web server using custom facts
     hosts: localhost
     become: true
     tasks:
       - name: Update index.html with custom message
         ansible.builtin.copy:
           content: "{{ ansible_facts.ansible_local.web_config.webserver.welcome_message }}"
           dest: /var/www/html/index.html
   

   Lassen Sie uns die Variable {{ ansible_facts.ansible_local.web_config.webserver.welcome_message }} aufschlüsseln:

   • ansible_facts: Das Root-Dictionary für alle Fakten.
   • ansible_local: Der Schlüssel, unter dem alle benutzerdefinierten Fakten gespeichert sind.
   • web_config: Der Name unserer Faktendatei (web_config.fact), ohne die Erweiterung.
   • webserver: Der Abschnittsname [webserver] aus unserer INI-Datei.
   • welcome_message: Der Schlüssel für den Wert, den wir verwenden möchten.

   Speichern Sie die Datei und beenden Sie nano.

4. Das Konfigurations-Playbook ausführen

   Führen Sie nun das Playbook aus, um die Konfiguration anzuwenden.

   ansible-playbook configure_web.yml
   

   Die Ausgabe sollte zeigen, dass die copy-Aufgabe die Datei index.html changed hat.

   PLAY [Configure web server using custom facts] *********************************
   
   TASK [Gathering Facts] *********************************************************
   ok: [localhost]
   
   TASK [Update index.html with custom message] ***********************************
   changed: [localhost]
   
   PLAY RECAP *********************************************************************
   localhost                  : ok=2    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
   

5. Das Ergebnis überprüfen

   Überprüfen wir abschließend, ob die Webseite korrekt aktualisiert wurde. Verwenden Sie den Befehl cat, um den Inhalt der Datei index.html anzuzeigen.

   cat /var/www/html/index.html
   

   Die Ausgabe sollte nun die Nachricht aus Ihrer benutzerdefinierten Faktendatei anzeigen:

   Welcome to the server configured by Custom Facts!
   

   Sie haben erfolgreich einen benutzerdefinierten Fakt auf dem verwalteten Host erstellt und ihn innerhalb eines Playbooks verwendet, um einen Dienst dynamisch zu konfigurieren. Diese Technik ist unglaublich nützlich, um Ihre Automatisierung flexibler und datengesteuerter zu gestalten.

Einen Systembenutzer mit verschlüsselten Variablen mittels Ansible Vault erstellen

In diesem Schritt lernen Sie, wie Sie sensible Daten wie Passwörter oder API-Schlüssel mit Ansible Vault verwalten. Das Speichern sensibler Informationen im Klartext innerhalb Ihrer Playbooks stellt ein großes Sicherheitsrisiko dar. Ansible Vault bietet eine Möglichkeit, Dateien oder einzelne Variablen zu verschlüsseln und Ihre Geheimnisse sicher aufzubewahren. Sie können diese verschlüsselten Dateien dann in Ihren Playbooks verwenden, und Ansible entschlüsselt sie zur Laufzeit, wenn Sie das korrekte Passwort angeben.

Wir erstellen eine verschlüsselte Datei, die einen Benutzernamen und ein gehashtes Passwort enthält, und verwenden dann ein Playbook, um einen neuen Systembenutzer mit diesen Anmeldeinformationen zu erstellen.

1. In das Projektverzeichnis navigieren

   Stellen Sie sicher, dass Sie sich für diese Aufgabe im Verzeichnis ~/project befinden.

   cd ~/project
   

2. Eine verschlüsselte Vault-Datei erstellen

   Wir verwenden den Befehl ansible-vault create, um eine neue, verschlüsselte YAML-Datei namens secrets.yml zu erstellen. Dieser Befehl fordert Sie auf, ein Passwort für den Vault zu erstellen. Dieses Passwort ist erforderlich, um die Datei später zu öffnen, zu bearbeiten oder zu verwenden.

   Lassen Sie uns zunächst den Editor auf nano setzen, um die Arbeit zu erleichtern:

   export EDITOR=nano
   

   Erstellen Sie nun die Vault-Datei:

   ansible-vault create secrets.yml
   

   Geben Sie bei Aufforderung ein Passwort für Ihren Vault ein. Verwenden wir für dieses Lab labex als Vault-Passwort, um es einfach zu halten. Sie müssen es zweimal eingeben.

   New Vault password:
   Confirm New Vault password:
   

   Nachdem Sie das Passwort bestätigt haben, öffnet der Befehl die Datei secrets.yml im Texteditor nano.

3. Geheime Variablen zur Vault-Datei hinzufügen

   Fügen Sie im nano-Editor, der nun die verschlüsselte Datei secrets.yml bearbeitet, die folgenden Variablen hinzu. Wir definieren einen Benutzernamen und ein vor-gehashtes Passwort für einen neuen Benutzer. Die Verwendung eines gehashten Passworts ist wesentlich sicherer als das Speichern eines Passworts im Klartext.

   username: myappuser
   pwhash: $6$mysalt$QwMzWSEyCAGmz7tzVrAi5o.8k4d05i2QsfGGwmPtlJsWhGjSjCW6yFCH/OEqEsHk7GMSxqYNXu5sshxPmWyxo0
   

   • username: Der Name des Systembenutzers, den wir erstellen möchten.
   • pwhash: Ein sicher gehashtes Passwort. Dieser spezifische Hash entspricht dem Passwort AnsibleUserP@ssw0rd und liegt in einem Format vor, das das Modul ansible.builtin.user versteht.

   Speichern Sie die Datei und beenden Sie nano (Ctrl+X, dann Y, dann Enter). Die Datei secrets.yml in Ihrem Verzeichnis ~/project ist nun verschlüsselt. Wenn Sie versuchen, sie mit cat secrets.yml anzuzeigen, sehen Sie nur verschlüsselten Text.

4. Ein Playbook zur Verwendung der Vault-Datei erstellen

   Erstellen Sie nun ein neues Playbook namens create_user.yml, das die Variablen aus Ihrer verschlüsselten secrets.yml-Datei verwendet.

   nano create_user.yml
   

   Fügen Sie den folgenden Inhalt hinzu. Die Anweisung vars_files weist Ansible an, Variablen aus der angegebenen Datei zu laden.

   ---
   - name: Create a user from secret variables
     hosts: localhost
     become: true
     vars_files:
       - secrets.yml
     tasks:
       - name: Create the {{ username }} user
         ansible.builtin.user:
           name: "{{ username }}"
           password: "{{ pwhash }}"
           state: present
   

   Dieses Playbook erstellt einen Benutzer mit dem Namen und dem Passwort-Hash, die in secrets.yml definiert sind. Speichern Sie die Datei und beenden Sie nano.

5. Das Playbook mit dem Vault-Passwort ausführen

   Um ein Playbook auszuführen, das eine Vault-Datei verwendet, müssen Sie das Vault-Passwort angeben. Sie können dies interaktiv mit dem Flag --ask-vault-pass tun.

   ansible-playbook --ask-vault-pass create_user.yml
   

   Ansible wird Sie nach dem Vault-Passwort fragen. Geben Sie labex ein (das Passwort, das Sie in Schritt 2 festgelegt haben).

   Vault password:
   

   Nachdem Sie das korrekte Passwort angegeben haben, entschlüsselt Ansible die Datei im Speicher und führt das Playbook aus. Sie sollten die folgende Ausgabe sehen, die anzeigt, dass der Benutzer erstellt wurde.

   PLAY [Create a user from secret variables] *************************************
   
   TASK [Gathering Facts] *********************************************************
   ok: [localhost]
   
   TASK [Create the myappuser user] ***********************************************
   changed: [localhost]
   
   PLAY RECAP *********************************************************************
   localhost                  : ok=2    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
   

6. Überprüfen, ob der Benutzer erstellt wurde

   Sie können bestätigen, dass der myappuser erfolgreich auf dem System erstellt wurde, indem Sie den Befehl id verwenden.

   id myappuser
   

   Wenn der Benutzer existiert, sehen Sie seine Benutzer-ID (uid) und Gruppen-ID (gid)-Informationen.

   uid=1002(myappuser) gid=1002(myappuser) groups=1002(myappuser)
   

   Dies bestätigt, dass Sie Ansible Vault erfolgreich zur Verwaltung sensibler Daten für Ihre Automatisierungsaufgaben eingesetzt haben.

Ein Playbook mit einer Vault-Passwortdatei ausführen, um Konfigurationen anzuwenden

In diesem Schritt lernen Sie eine automatisiertere Methode kennen, um das Vault-Passwort an Ansible zu übermitteln. Im vorherigen Schritt haben Sie --ask-vault-pass verwendet, um das Passwort interaktiv einzugeben. Obwohl dies sicher ist, ist es für automatisierte Umgebungen wie CI/CD-Pipelines, in denen kein Benutzer anwesend ist, um ein Passwort einzugeben, nicht geeignet.

Die Lösung besteht darin, eine Vault-Passwortdatei zu verwenden. Dies ist eine einfache Textdatei, die das Vault-Passwort enthält. Sie können dann beim Ausführen Ihres Playbooks auf diese Datei verweisen, und Ansible liest das Passwort automatisch daraus. Aus Sicherheitsgründen ist es entscheidend, die Berechtigungen dieser Passwortdatei so einzuschränken, dass nur autorisierte Benutzer sie lesen können.

1. In das Projektverzeichnis navigieren

   Stellen Sie sicher, dass Sie sich im Verzeichnis ~/project befinden, in dem sich Ihr Playbook und Ihre Vault-Datei befinden.

   cd ~/project
   

2. Die Vault-Passwortdatei erstellen

   Lassen Sie uns eine Datei erstellen, um unser Vault-Passwort zu speichern. Wir nennen sie vault_pass.txt. Wir können den Befehl echo verwenden, um die Datei zu erstellen und das Passwort (labex) in einem einzigen Schritt hineinzuschreiben.

   echo "labex" > vault_pass.txt
   

   Sie können den Inhalt der Datei mit cat überprüfen:

   cat vault_pass.txt
   

   Die Ausgabe sollte sein:

   labex
   

3. Die Passwortdatei sichern

   Das Speichern eines Passworts in einer Klartextdatei ist riskant. Sie müssen die Dateiberechtigungen einschränken, um sie zu schützen. Der Befehl chmod ermöglicht es Ihnen, Dateiberechtigungen zu ändern. Wir setzen die Berechtigungen auf 600, was bedeutet, dass nur der Dateieigentümer (in diesem Fall der Benutzer labex) Lese- und Schreibberechtigungen hat. Kein anderer Benutzer auf dem System kann darauf zugreifen.

   chmod 600 vault_pass.txt
   

   Sie können die neuen Berechtigungen mit dem Befehl ls -l überprüfen:

   ls -l vault_pass.txt
   

   Die Ausgabe sollte mit -rw------- beginnen, was die eingeschränkten Berechtigungen bestätigt.

   -rw-------. 1 labex labex 6 May 21 14:30 vault_pass.txt
   

4. Das Playbook ändern, um einen Benutzer zu einer Gruppe hinzuzufügen

   Lassen Sie uns unser Playbook create_user.yml ändern, um eine zusätzliche Aktion auszuführen. Wir fügen den myappuser zur Gruppe wheel hinzu, was auf vielen Systemen administrative (sudo) Privilegien gewährt. Dies demonstriert die Ausführung eines Playbooks, das eine Änderung an einer bestehenden Konfiguration vornimmt.

   Öffnen Sie zunächst das Playbook create_user.yml zur Bearbeitung.

   nano create_user.yml
   

   Ändern Sie die Aufgabe ansible.builtin.user, um die Parameter groups und append einzubeziehen.

   ---
   - name: Create a user from secret variables
     hosts: localhost
     become: true
     vars_files:
       - secrets.yml
     tasks:
       - name: Create the {{ username }} user and add to wheel group
         ansible.builtin.user:
           name: "{{ username }}"
           password: "{{ pwhash }}"
           state: present
           groups: wheel
           append: true
   

   • groups: wheel: Gibt die Gruppe an, zu der der Benutzer hinzugefügt werden soll.
   • append: true: Stellt sicher, dass der Benutzer zu dieser Gruppe hinzugefügt wird, ohne ihn aus anderen Gruppen zu entfernen, denen er möglicherweise angehört.

   Speichern Sie die Datei und beenden Sie nano.

5. Das Playbook mit der Vault-Passwortdatei ausführen

   Führen Sie nun das Playbook erneut aus. Verwenden Sie diesmal anstelle von --ask-vault-pass die Option --vault-password-file (oder ihren kürzeren Alias --vault-pass-file), um den Pfad zu Ihrer Passwortdatei anzugeben.

   ansible-playbook --vault-password-file vault_pass.txt create_user.yml
   

   Ansible wird nun ausgeführt, ohne nach einem Passwort zu fragen, da es dieses direkt aus vault_pass.txt liest. Sie sollten eine Ausgabe sehen, die anzeigt, dass die Konfiguration des Benutzers geändert wurde.

   PLAY [Create a user from secret variables] *************************************
   
   TASK [Gathering Facts] *********************************************************
   ok: [localhost]
   
   TASK [Create the myappuser user and add to wheel group] ************************
   changed: [localhost]
   
   PLAY RECAP *********************************************************************
   localhost                  : ok=2    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
   

   Der Status changed bestätigt, dass Ansible den Benutzer durch Hinzufügen zur Gruppe wheel modifiziert hat.

6. Die Gruppenzugehörigkeit des Benutzers überprüfen

   Überprüfen Sie abschließend, ob myappuser nun Mitglied der Gruppe wheel ist. Sie können dies mit dem Befehl groups tun.

   groups myappuser
   

   Die Ausgabe sollte sowohl die primäre Gruppe des Benutzers (myappuser) als auch die Gruppe wheel anzeigen.

   myappuser : myappuser wheel
   

   Sie haben erfolgreich eine Vault-Passwortdatei verwendet, um ein Playbook nicht-interaktiv auszuführen – eine Schlüsselkompetenz für die Automatisierung sicherer Workflows.

Webserver- und Benutzerkonfiguration überprüfen

In diesem letzten Schritt festigen Sie Ihr Wissen, indem Sie ein dediziertes Verifizierungs-Playbook erstellen. Bisher haben Sie die Ergebnisse Ihrer Playbooks manuell mit Standard-Linux-Befehlen wie cat, id und groups überprüft. Ein leistungsfähigerer und wiederholbarer Ansatz ist die Verwendung von Ansible selbst, um den Zustand Ihres Systems zu prüfen und zu validieren.

Dieses Playbook fungiert als Testsuite, die programmatisch überprüft, ob der Webserver installiert ist, die Webseite den korrekten Inhalt hat und der Systembenutzer mit der richtigen Gruppenzugehörigkeit existiert. Dies demonstriert, wie Ansible nicht nur für das Konfigurationsmanagement, sondern auch für Compliance und Zustandsvalidierung verwendet werden kann.

1. In das Projektverzeichnis navigieren

   Stellen Sie zunächst sicher, dass Sie sich im Verzeichnis ~/project befinden.

   cd ~/project
   

2. Das Verifizierungs-Playbook erstellen

   Lassen Sie uns ein neues Playbook namens verify_config.yml erstellen. Dieses Playbook enthält eine Reihe von Aufgaben, die die Konfigurationen überprüfen, die Sie in den vorherigen Schritten angewendet haben.

   nano verify_config.yml
   

3. Aufgaben zur Überprüfung der Konfiguration hinzufügen

   Fügen Sie im nano-Editor den folgenden Inhalt hinzu. Wir bauen dieses Playbook mit mehreren Aufgaben auf, von denen jede darauf ausgelegt ist, sicherzustellen, dass eine bestimmte Bedingung wahr ist. Wenn eine Zusicherung (Assertion) fehlschlägt, stoppt das Playbook und meldet einen Fehler, der Ihnen sofort mitteilt, was falsch ist.

   ---
   - name: Verify system configuration
     hosts: localhost
     become: true
     tasks:
       - name: Check if httpd package is installed
         ansible.builtin.dnf:
           list: httpd
         register: httpd_pkg_info
   
       - name: Assert that httpd is installed
         ansible.builtin.assert:
           that:
             - httpd_pkg_info.results | length > 0
           fail_msg: "Apache (httpd) package is not installed."
           success_msg: "Apache (httpd) package is installed."
   
       - name: Read the content of the index.html file
         ansible.builtin.slurp:
           src: /var/www/html/index.html
         register: index_file
   
       - name: Assert that the web page content is correct
         ansible.builtin.assert:
           that:
             - "'Custom Facts' in (index_file.content | b64decode)"
           fail_msg: "Web page content is incorrect."
           success_msg: "Web page content is correct."
   
       - name: Check if myappuser exists
         ansible.builtin.getent:
           database: passwd
           key: myappuser
         register: user_info
   
       - name: Assert that myappuser exists
         ansible.builtin.assert:
           that:
             - user_info.ansible_facts.getent_passwd['myappuser'] is defined
           fail_msg: "User 'myappuser' does not exist."
           success_msg: "User 'myappuser' exists."
   
       - name: Query the wheel group members
         ansible.builtin.getent:
           database: group
           key: wheel
         register: wheel_group_info
   
       - name: Assert that myappuser is in the wheel group
         ansible.builtin.assert:
           that:
             - "'myappuser' in (wheel_group_info.ansible_facts.getent_group['wheel'][2] | default('') | split(','))"
           fail_msg: "User 'myappuser' is not in the wheel group."
           success_msg: "User 'myappuser' is in the wheel group."
   

   Lassen Sie uns die hier verwendeten Schlüsselmodule überprüfen:

   • ansible.builtin.dnf mit list: Dies prüft auf ein Paket und registert das Ergebnis.
   • ansible.builtin.slurp: Dies "saugt" den gesamten Inhalt einer Datei vom Remote-Host auf. Der Inhalt ist für den sicheren Transport base64-kodiert.
   • ansible.builtin.getent: Dies ist eine sichere Methode, um Systemdatenbanken wie passwd und group abzufragen. Die Ergebnisse werden unter ansible_facts gespeichert, daher greifen Sie über Schlüssel wie user_info.ansible_facts.getent_passwd auf die zurückgegebenen Daten zu.
   • ansible.builtin.assert: Dies ist der Kern unserer Verifizierung. Es prüft, ob eine gegebene Bedingung wahr ist. Wenn nicht, schlägt das Play fehl. Wir stellen benutzerdefinierte Erfolgs- und Fehlermeldungen bereit.
   • b64decode: Dies ist ein Jinja2-Filter, der verwendet wird, um den base64-Inhalt zu dekodieren, den wir vom slurp-Modul erhalten haben.

   Beachten Sie, dass wir die Datenbanken passwd und group separat abfragen. Dies hält die Überprüfung der Benutzerexistenz und die Überprüfung der Gruppenzugehörigkeit zur wheel-Gruppe im Einklang mit den tatsächlichen Daten, die von getent zurückgegeben werden.

   Speichern Sie die Datei und beenden Sie nano (Ctrl+X, Y, Enter).

4. Das Verifizierungs-Playbook ausführen

   Führen Sie nun Ihr Verifizierungs-Playbook aus. Da es keine Vault-Dateien verwendet, müssen Sie kein Passwort angeben.

   ansible-playbook verify_config.yml
   

   Wenn alle Ihre vorherigen Schritte korrekt abgeschlossen wurden, wird das Playbook erfolgreich ausgeführt, und Sie sehen die benutzerdefinierte Erfolgsmeldung für jede Zusicherung.

   PLAY [Verify system configuration] *********************************************
   
   TASK [Gathering Facts] *********************************************************
   ok: [localhost]
   
   TASK [Check if httpd package is installed] *************************************
   ok: [localhost]
   
   TASK [Assert that httpd is installed] ******************************************
   ok: [localhost] => {
       "changed": false,
       "msg": "Apache (httpd) package is installed."
   }
   
   TASK [Read the content of the index.html file] *********************************
   ok: [localhost]
   
   TASK [Assert that the web page content is correct] *****************************
   ok: [localhost] => {
       "changed": false,
       "msg": "Web page content is correct."
   }
   
   TASK [Check if myappuser exists] ***********************************************
   ok: [localhost]
   
   TASK [Assert that myappuser exists] ********************************************
   ok: [localhost] => {
       "changed": false,
       "msg": "User 'myappuser' exists."
   }
   
   TASK [Query the wheel group members] *******************************************
   ok: [localhost]
   
   TASK [Assert that myappuser is in the wheel group] *****************************
   ok: [localhost] => {
       "changed": false,
       "msg": "User 'myappuser' is in the wheel group."
   }
   
   PLAY RECAP *********************************************************************
   localhost                  : ok=9    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
   

   Herzlichen Glückwunsch! Sie haben erfolgreich Ansible verwendet, um Variablen zu definieren, Systemfakten zu sammeln, Geheimnisse mit Vault zu verwalten und schließlich den Zustand Ihres Systems auf automatisierte Weise zu überprüfen.

Zusammenfassung

In diesem Lab haben Sie gelernt, verschiedene Datentypen innerhalb von Ansible-Playbooks zu verwalten, um ein RHEL-System zu konfigurieren. Sie begannen damit, Standard-Playbook-Variablen zu definieren und zu verwenden, um flexibel einen Apache-Webserver zu installieren und zu konfigurieren. Anschließend haben Sie erforscht, wie Sie die integrierten Fakten von Ansible nutzen können, um Systeminformationen anzuzeigen, was eine Grundlage für die Erstellung dynamischer und host-bewusster Automatisierungsaufgaben bildet.

Darauf aufbauend haben Sie den Webserver weiter konfiguriert, indem Sie benutzerdefinierte Fakten vom verwalteten Host erstellt und genutzt haben. Um sensible Informationen sicher zu handhaben, haben Sie Ansible Vault verwendet, um ein Benutzerpasswort zu verschlüsseln, einen neuen Systembenutzer mit dieser verschlüsselten Variable erstellt und das Playbook nicht-interaktiv mit einer Vault-Passwortdatei ausgeführt. Das Lab schloss mit der Überprüfung ab, dass sowohl der Webserver als auch der neue Systembenutzer korrekt konfiguriert wurden, was die erfolgreiche Anwendung aller erlernten Konzepte bestätigt.