Ansible Playbooks und Hosts unter RHEL beheben | Automatisierungsprobleme lösen

Einführung

In diesem Lab lernen Sie, wie Sie häufige Probleme beheben, die bei der Arbeit mit Ansible unter Red Hat Enterprise Linux auftreten. Sie sammeln praktische Erfahrungen bei der Identifizierung und Lösung einer Vielzahl von Problemen, von der anfänglichen Umgebungsaufstellung bis hin zu gängigen Playbook-Fehlern und Konnektivitätsproblemen mit verwalteten Hosts. Die Übungen umfassen die Korrektur von YAML-Syntax, die Behebung von Jinja2-Templating-Fehlern und die Diagnose von Problemen auf entfernten Systemen.

Sie beginnen mit der Vorbereitung einer RHEL-Umgebung und der Konfiguration von Ansible für effektives Logging. Anschließend tauchen Sie in praktische Fehlerbehebungsszenarien ein, nutzen den Check-Modus von Ansible zur Diagnose von dienstbezogenen Problemen und korrigieren Firewall-Konfigurationen, um die Nichterreichbarkeit von Hosts zu beheben. Am Ende dieses Labs werden Sie mit einem umfassenden Satz von Fähigkeiten ausgestattet sein, um robuste Ansible-Automatisierungs-Workflows aufrechtzuerhalten.

RHEL-Umgebung vorbereiten und Ansible-Logging konfigurieren

In diesem Schritt bereiten Sie Ihre Red Hat Enterprise Linux-Umgebung für die Ansible-Automatisierung vor. Dies beinhaltet die Installation der notwendigen Software, die Erstellung eines dedizierten Projektverzeichnisses und die Einrichtung einer grundlegenden Konfigurationsdatei zur Steuerung des Ansible-Verhaltens und zur Aktivierung des Loggings. Eine ordnungsgemäße Einrichtung ist der erste Schritt zu effektiver Automatisierung und Fehlerbehebung.

Ansible installieren

Zuerst müssen Sie Ansible installieren. Die Kern-Automatisierungs-Engine wird durch das Paket ansible-core bereitgestellt. Verwenden Sie den Paketmanager dnf mit sudo zur Installation. Das Flag -y beantwortet automatisch alle Bestätigungsaufforderungen mit "ja".

sudo dnf install -y ansible-core

Sie sollten eine Ausgabe sehen, die anzeigt, dass das Paket zusammen mit seinen Abhängigkeiten installiert wird.

Last metadata expiration check: ...
Dependencies resolved.
================================================================================
 Package             Architecture   Version                Repository      Size
================================================================================
Installing:
 ansible-core        x86_64         <version>              <repo>          2.8 M
...
Transaction Summary
================================================================================
Install  XX Packages

Total download size: XX M
Installed size: XX M
...
Complete!

Projektverzeichnis erstellen

Es ist eine bewährte Methode, Ihre Ansible-Projekte in dedizierten Verzeichnissen zu organisieren. Dies hält Ihre Playbooks, Inventare und Konfigurationsdateien sauber getrennt. Erstellen wir ein Verzeichnis namens ansible_troubleshooting in Ihrem Home-Projektordner und wechseln dorthin.
```
mkdir -p ~/project/ansible_troubleshooting
cd ~/project/ansible_troubleshooting
```
Von nun an werden alle Befehle in diesem Lab vom Verzeichnis ~/project/ansible_troubleshooting aus ausgeführt.
Ansible-Inventardatei erstellen

Ein Inventar ist eine Datei, die die Hosts (oder Knoten) auflistet, die Ansible verwalten wird. Da Sie auf einer einzelnen LabEx VM arbeiten, konfigurieren Sie Ansible so, dass es die lokale Maschine selbst verwaltet.

Erstellen Sie eine Datei namens inventory und fügen Sie localhost hinzu. Der Teil ansible_connection=local weist Ansible an, Befehle direkt auf dem Control Node (Ihrer VM) auszuführen, ohne SSH zu verwenden.
```
echo "localhost ansible_connection=local" > inventory
```
Sie können den Inhalt der Datei mit dem Befehl cat überprüfen:
```
cat inventory
```
Erwartete Ausgabe:
```
localhost ansible_connection=local
```
Ansible-Logging konfigurieren

Eine ansible.cfg-Datei ermöglicht es Ihnen, das Verhalten von Ansible für ein bestimmtes Projekt anzupassen. Wenn sie im Projektverzeichnis platziert wird, überschreiben ihre Einstellungen die systemweiten Standardeinstellungen. Hier erstellen Sie diese Datei, um den Speicherort Ihres Inventars anzugeben und das Logging zu aktivieren. Logging ist für die Fehlerbehebung unerlässlich, da es detaillierte Informationen über jeden Playbook-Lauf aufzeichnet.

Verwenden Sie den nano-Editor, um die Datei ansible.cfg zu erstellen.
```
nano ansible.cfg
```
Kopieren Sie nun den folgenden Inhalt und fügen Sie ihn in den nano-Editor ein. Diese Konfiguration weist Ansible an, die inventory-Datei im aktuellen Verzeichnis zu verwenden und die gesamte Log-Ausgabe in eine Datei namens ansible.log zu schreiben.
```
[defaults]
inventory = /home/labex/project/ansible_troubleshooting/inventory
log_path = /home/labex/project/ansible_troubleshooting/ansible.log
```
Um die Datei in nano zu speichern, drücken Sie Ctrl+X, dann Y zur Bestätigung und schließlich Enter, um die Datei zu schreiben.

Ihre Umgebung ist nun vollständig vorbereitet. Sie haben Ansible installiert und ein Projektverzeichnis mit einem lokalen Inventar und aktiviertem Logging konfiguriert, bereit für die nächsten Schritte.

YAML-Syntax- und Einrückungsfehler in einem Playbook beheben

In diesem Schritt lernen Sie, wie Sie zwei der häufigsten Fehler in Ansible-Playbooks diagnostizieren und beheben: YAML-Syntaxfehler und falsche Einrückung. YAML, die Sprache, die zum Schreiben von Playbooks verwendet wird, ist sehr streng in Bezug auf ihre Struktur. Ein einzelnes falsch platziertes Leerzeichen oder ein nicht in Anführungszeichen gesetztes Sonderzeichen kann verhindern, dass ein Playbook ausgeführt wird. Sie verwenden den Befehl ansible-playbook --syntax-check, ein wichtiges Werkzeug zur Validierung Ihrer Playbooks vor der Ausführung.

Erstellen eines Playbooks mit beabsichtigten Fehlern

Zuerst erstellen Sie eine neue Playbook-Datei namens webserver.yml in Ihrem Projektverzeichnis (~/project/ansible_troubleshooting). Diese Datei enthält absichtliche Fehler, die Sie beheben werden.

Verwenden Sie nano, um die Datei zu erstellen:
```
nano webserver.yml
```
Kopieren Sie den folgenden Inhalt und fügen Sie ihn in den Editor ein. Beachten Sie die beiden absichtlichen Fehler: eine Zeichenkette ohne Anführungszeichen, die einen Doppelpunkt enthält, und eine falsche Einrückung für die zweite Aufgabe.
```
---
- name: Configure Web Server
  hosts: localhost
  vars:
    ## ERROR 1: Unquoted colon in string
    package_comment: This is a package: httpd
  tasks:
    - name: Install httpd package
      ansible.builtin.dnf:
        name: httpd
        state: present

    ## ERROR 2: Incorrect indentation
      - name: Create a test index page
        ansible.builtin.copy:
          content: "<h1>Welcome to Ansible</h1>"
          dest: /var/www/html/index.html
```
Speichern Sie die Datei und beenden Sie nano, indem Sie Ctrl+X, dann Y und Enter drücken.
Identifizieren und Beheben des YAML-Syntaxfehlers (Doppelpunkt ohne Anführungszeichen)

Führen Sie nun eine Syntaxprüfung für das gerade erstellte Playbook durch. Dieser Befehl analysiert die Datei und meldet alle Syntaxprobleme, ohne die Aufgaben tatsächlich auszuführen.
```
ansible-playbook --syntax-check webserver.yml
```
Erwartete Ausgabe (Fehler): Sie sehen einen Fehler, da der Wert für package_comment einen Doppelpunkt (:) enthält, aber nicht in Anführungszeichen gesetzt ist. YAML interpretiert den Doppelpunkt als Trennzeichen für Schlüssel-Wert-Paare, was zu einem Syntaxfehler führt.
```
ERROR! We were unable to read either as JSON nor YAML, these are the errors we found:
- Syntax Error while loading YAML.
  did not find expected ':'

The error appears to be in '/home/labex/project/ansible_troubleshooting/webserver.yml': line 6, column 41, but may be elsewhere in the file depending on the exact syntax problem.

The offending line appears to be:

  vars:
    package_comment: This is a package: httpd
                                        ^ here
```
Lösung: Um dies zu beheben, müssen Sie die Zeichenkette in doppelte Anführungszeichen setzen. Öffnen Sie die Datei erneut mit nano:
```
nano webserver.yml
```
Ändern Sie die Zeile unter vars, um Anführungszeichen hinzuzufügen:
```
## ... (rest of the file)
vars:
  ## FIX: Add quotes around the string with a colon
  package_comment: "This is a package: httpd"
## ... (rest of the file)
```
Speichern und beenden Sie den Editor.
Identifizieren und Beheben des YAML-Einrückungsfehlers

Nachdem der erste Fehler behoben ist, führen Sie die Syntaxprüfung erneut durch.
```
ansible-playbook --syntax-check webserver.yml
```
Erwartete Ausgabe (Fehler): Diesmal meldet Ansible einen anderen Fehler im Zusammenhang mit der Struktur des Playbooks.
```
ERROR! A malformed block was encountered.

The error appears to be in '/home/labex/project/ansible_troubleshooting/webserver.yml': line 13, column 11, but may be elsewhere in the file depending on the exact syntax problem.

The offending line appears to be:


      ## ERROR 2: Incorrect indentation
      - name: Create a test index page
        ^ here
```
Dieser Fehler tritt auf, weil YAML Einrückungen zur Definition der Struktur verwendet. Alle Elemente einer Liste (in diesem Fall die Aufgaben, die Listenelemente sind, die mit - beginnen) müssen die gleiche Einrückungsebene haben. Die zweite Aufgabe, Create a test index page, ist zu stark eingerückt.

Lösung: Öffnen Sie die Datei ein weiteres Mal, um die Einrückung zu korrigieren.
```
nano webserver.yml
```
Entfernen Sie die zusätzlichen Leerzeichen vor der zweiten Aufgabe, sodass ihr Bindestrich (-) perfekt mit dem Bindestrich der ersten Aufgabe ausgerichtet ist.
```
## ... (rest of the file)
tasks:
  - name: Install httpd package
    ansible.builtin.dnf:
      name: httpd
      state: present

  ## FIX: Correct the indentation to align with the previous task
  - name: Create a test index page
    ansible.builtin.copy:
      content: "<h1>Welcome to Ansible</h1>"
      dest: /var/www/html/index.html
```
Speichern und beenden Sie den Editor.
Überprüfen des korrigierten Playbooks

Führen Sie abschließend die Syntaxprüfung ein letztes Mal durch.
```
ansible-playbook --syntax-check webserver.yml
```
Diesmal sollte der Befehl ohne Fehler abgeschlossen werden, und der Name des Playbooks wird angezeigt, was bestätigt, dass die Syntax nun korrekt ist.

Erwartete Ausgabe (Erfolg):
```
playbook: webserver.yml
```

Jinja2-Anführungszeichen- und Template-Pfadfehler beheben

In diesem Schritt befassen Sie sich mit Fehlern im Zusammenhang mit Jinja2, dem leistungsstarken Template-Engine von Ansible. Sie lernen, warum Jinja2-Ausdrücke oft in Anführungszeichen gesetzt werden müssen und wie Sie Probleme beheben, wenn ein Playbook eine angegebene Template-Datei nicht finden kann. Dies sind häufige Laufzeitfehler, die auftreten, nachdem ein Playbook eine Syntaxprüfung bestanden hat.

Erstellen einer Jinja2-Template-Datei

Zuerst benötigen Sie eine Template-Datei. Im Gegensatz zu einer statischen Datei kann ein Template Variablen enthalten, die Ansible während der Ausführung des Playbooks durch tatsächliche Werte ersetzt. Sie erstellen ein einfaches HTML-Template.

Verwenden Sie nano, um eine Datei namens index.html.j2 in Ihrem Projektverzeichnis (~/project/ansible_troubleshooting) zu erstellen. Die Erweiterung .j2 ist eine gängige Konvention für Jinja2-Templates.
```
nano index.html.j2
```
Kopieren Sie den folgenden HTML-Inhalt und fügen Sie ihn in den Editor ein. Beachten Sie den Platzhalter {{ welcome_message }}, der eine Jinja2-Variable ist.
```
<h1>{{ welcome_message }}</h1>
<p>This page was deployed by Ansible.</p>
```
Speichern Sie die Datei und beenden Sie nano (Ctrl+X, Y, Enter).
Anpassen des Playbooks zur Verwendung des Templates und Einführen von Fehlern

Ändern Sie nun Ihr webserver.yml-Playbook, um das Modul ansible.builtin.template zu verwenden. Sie werden auch zwei neue Fehler einführen: eine Jinja2-Variable ohne Anführungszeichen und einen falschen Template-Pfad.

Öffnen Sie webserver.yml mit nano:
```
nano webserver.yml
```
Ersetzen Sie den gesamten Inhalt der Datei durch Folgendes. Die Direktive become: true weist Ansible an, Aufgaben mit Administratorrechten (mittels sudo) auszuführen, was für die Installation von Software und das Schreiben von Dateien in Systemverzeichnisse wie /var/www/html erforderlich ist.
```
---
- name: Configure Web Server
  hosts: localhost
  become: true
  vars:
    package_name: httpd
    welcome_message: "Welcome to Ansible with Jinja2"
  tasks:
    - name: Install httpd package
      ansible.builtin.dnf:
        ## ERROR 1: Unquoted Jinja2 variable
        name: { { package_name } }
        state: present

    - name: Create a test index page from template
      ansible.builtin.template:
        ## ERROR 2: Incorrect template source path
        src: index.j2
        dest: /var/www/html/index.html
```
Speichern und beenden Sie den Editor.
Identifizieren und Beheben des Jinja2-Anführungszeichen-Fehlers

Obwohl dies ein Jinja2-Problem ist, kann es sich als YAML-Syntaxfehler manifestieren. Führen Sie die Syntaxprüfung durch, um zu sehen, wie Ansible dies interpretiert.
```
ansible-playbook --syntax-check webserver.yml
```
Erwartete Ausgabe (Fehler): Sie erhalten einen Syntaxfehler, da ein YAML-Wert, der mit {{ beginnt, als spezielles Konstrukt behandelt wird und in Anführungszeichen gesetzt werden muss, um als Zeichenkette interpretiert zu werden.
```
ERROR! A malformed block was encountered.

The error appears to be in '/home/labex/project/ansible_troubleshooting/webserver.yml': line 11, column 19, but may be elsewhere in the file depending on the exact syntax problem.

The offending line appears to be:

          ## ERROR 1: Unquoted Jinja2 variable
          name: {{ package_name }}
                  ^ here
```
Lösung: Öffnen Sie webserver.yml und setzen Sie die Jinja2-Variable in doppelte Anführungszeichen.
```
nano webserver.yml
```
Ändern Sie die Aufgabe Install httpd package:
```
## ... (rest of the file)
tasks:
  - name: Install httpd package
    ansible.builtin.dnf:
      ## FIX: Quote the Jinja2 expression
      name: "{{ package_name }}"
      state: present
## ... (rest of the file)
```
Speichern und beenden Sie. Die Syntaxprüfung sollte nun erfolgreich sein.
Identifizieren und Beheben des Template-Pfadfehlers

Nachdem die Syntax korrekt ist, versuchen Sie, das Playbook auszuführen.
```
ansible-playbook webserver.yml
```
Erwartete Ausgabe (Fehler): Das Playbook schlägt fehl, aber diesmal ist es ein Laufzeitfehler, kein Syntaxfehler. Die Fehlermeldung besagt eindeutig, dass die Quelldatei index.j2 nicht gefunden werden konnte.
```
TASK [Create a test index page from template] **********************************
fatal: [localhost]: FAILED! => {"changed": false, "msg": "Could not find or access '/home/labex/project/ansible_troubleshooting/index.j2' on the Ansible Controller."}
```
Dies geschieht, weil der Parameter src in Ihrem Playbook auf index.j2 verweist, die von Ihnen erstellte Datei jedoch index.html.j2 heißt.

Lösung: Öffnen Sie webserver.yml ein letztes Mal und korrigieren Sie den Dateinamen.
```
nano webserver.yml
```
Ändern Sie den Parameter src in der Aufgabe Create a test index page from template:
```
## ... (rest of the file)
- name: Create a test index page from template
  ansible.builtin.template:
    ## FIX: Correct template source filename
    src: index.html.j2
    dest: /var/www/html/index.html
## ... (rest of the file)
```
Speichern und beenden Sie den Editor.

Ausführen des Playbooks erfolgreich

Führen Sie das Playbook erneut aus. Es sollte nun alle Aufgaben erfolgreich abschließen.

ansible-playbook webserver.yml

Erwartete Ausgabe (Erfolg):

PLAY [Configure Web Server] ****************************************************

TASK [Gathering Facts] *********************************************************
ok: [localhost]

TASK [Install httpd package] ***************************************************
changed: [localhost]

TASK [Create a test index page from template] **********************************
changed: [localhost]

PLAY RECAP *********************************************************************
localhost                  : ok=3    changed=2    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

Check-Modus zur Fehlerbehebung bei Diensten auf verwalteten Hosts verwenden

In diesem Schritt lernen Sie eine der leistungsfähigsten Fehlerbehebungsfunktionen von Ansible kennen: den Check-Modus. Der Check-Modus (aktiviert mit dem Flag --check) ermöglicht es Ihnen, ein Playbook auszuführen, um zu sehen, welche Änderungen vorgenommen würden, ohne tatsächlich etwas am System zu ändern. Dies ist unglaublich nützlich, um Playbooks sicher zu testen und Probleme wie falsche Servicenamen zu diagnostizieren, bevor sie echte Probleme verursachen.

Erstellen eines Playbooks zur Verwaltung eines Dienstes

Sie erstellen nun ein neues Playbook, service.yml, das sicherstellt, dass der Webserver-Dienst httpd ausgeführt wird. Sie werden jedoch absichtlich einen falschen Servicenamen verwenden, um einen häufigen Fehler zu simulieren.

Verwenden Sie nano, um die Datei service.yml in Ihrem Verzeichnis ~/project/ansible_troubleshooting zu erstellen.
```
nano service.yml
```
Kopieren Sie den folgenden Inhalt und fügen Sie ihn ein. Beachten Sie, dass der Servicename auf apache2 gesetzt ist, was ein gängiger Name für den Apache-Webserver auf anderen Linux-Distributionen ist, aber für RHEL falsch ist.
```
---
- name: Manage Web Server Service
  hosts: localhost
  become: true
  tasks:
    - name: Ensure web server service is started
      ansible.builtin.service:
        ## ERROR: Incorrect service name for RHEL
        name: apache2
        state: started
        enabled: true
```
Speichern Sie die Datei und beenden Sie nano (Ctrl+X, Y, Enter).
Verwenden des Check-Modus zur Identifizierung des Service-Fehlers

Anstatt das Playbook normal auszuführen, führen Sie es im Check-Modus aus. Dies verhindert, dass Ansible Änderungen vornimmt, ermöglicht es ihm jedoch, den Zustand des Systems zu überprüfen und zu melden, was es tun würde.
```
ansible-playbook --check service.yml
```
Erwartete Ausgabe (Fehler): Das Playbook schlägt fehl. Die Fehlermeldung wird deutlich darauf hinweisen, dass der Dienst mit dem Namen apache2 nicht gefunden werden konnte. Dies sagt Ihnen sofort, dass der Parameter name in Ihrem Playbook falsch ist.
```
TASK [Ensure web server service is started] ************************************
fatal: [localhost]: FAILED! => {"changed": false, "msg": "Could not find the requested service 'apache2': host"}

PLAY RECAP *********************************************************************
localhost                  : ok=1    changed=0    unreachable=0    failed=1    skipped=0    rescued=0    ignored=0
```
Finden des korrekten Servicenamens

Um das Playbook zu korrigieren, müssen Sie den korrekten Servicenamen für das Paket httpd auf RHEL finden. Eine zuverlässige Methode hierfür ist die Auflistung der vom Paket installierten Dateien und die Suche nach der Service-Unit-Datei, die sich typischerweise in /usr/lib/systemd/system/ befindet.

Verwenden Sie den Befehl rpm, um das Paket httpd abzufragen:
```
rpm -ql httpd | grep systemd
```
Erwartete Ausgabe: Dieser Befehl listet die systemd-bezogenen Dateien auf, einschließlich der Service-Datei.
```
/usr/lib/systemd/system/httpd.service
/usr/lib/systemd/system/httpd@.service
...
```
Die Ausgabe httpd.service zeigt Ihnen, dass der korrekte Servicename httpd ist.
Korrigieren des Playbooks und erneutes Ausführen im Check-Modus

Nachdem Sie nun den korrekten Servicenamen kennen, bearbeiten Sie die Datei service.yml.
```
nano service.yml
```
Ändern Sie den Servicenamen von apache2 zu httpd.
```
## ... (rest of the file)
- name: Ensure web server service is started
  ansible.builtin.service:
    ## FIX: Correct service name for RHEL
    name: httpd
    state: started
    enabled: true
```
Speichern und beenden Sie den Editor. Führen Sie nun das Playbook erneut im Check-Modus aus.
```
ansible-playbook --check service.yml
```
Erwartete Ausgabe (Erfolg im Check-Modus): Diesmal sollte das Playbook den Status changed melden. Im Check-Modus bedeutet changed, dass "eine Änderung vorgenommen worden wäre, wenn dies ein echter Durchlauf gewesen wäre". Es zeigt an, dass Ihre Playbook-Logik nun korrekt ist und Ansible erkannt hat, dass der Dienst httpd gestartet werden muss.
```
TASK [Ensure web server service is started] ************************************
changed: [localhost]

PLAY RECAP *********************************************************************
localhost                  : ok=2    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
```
Hinweis: In dieser spezifischen containerbasierten Laborumgebung läuft kein vollständiges systemd-Init-System. Obwohl der Check-Modus korrekt funktioniert, kann ein normaler Durchlauf des Moduls ansible.builtin.service immer noch auf Probleme stoßen. Die wichtigste Lektion hier ist die Verwendung des Check-Modus, um die Logik Ihres Playbooks gegen die Konfiguration des Systems zu validieren.

Korrigieren der Firewall-Konfiguration und Beheben von Problemen mit der Nichterreichbarkeit von Hosts

In diesem letzten Schritt befassen Sie sich mit zwei kritischen Laufzeitproblemen: Fehlern, die durch falsche Systemkonfigurationen wie die Firewall verursacht werden, und Konnektivitätsproblemen, die sich aus Fehlern in Ihrer Ansible-Inventardatei ergeben. Die Beherrschung dieser Probleme hilft Ihnen, einige der häufigsten Hürden bei der Automatisierung zu überwinden.

Teil 1: Korrigieren der Firewall-Konfiguration

Eine häufige Aufgabe bei der Serverkonfiguration ist das Öffnen von Ports in der Firewall. Ein Playbook kann leicht fehlschlagen, wenn es sich auf einen Firewall-Dienst bezieht, der auf dem Zielsystem nicht vorhanden ist.

Installieren und Vorbereiten von firewalld

Stellen Sie zunächst sicher, dass das Paket firewalld installiert ist, da es den Firewall-Verwaltungsdienst auf RHEL bereitstellt.
```
sudo dnf install -y firewalld
```
Starten Sie den Dienst firewalld.
```
sudo systemctl start firewalld
```
Sie müssen auch die Sammlung ansible.posix installieren, die das in dieser Übung verwendete firewalld-Modul enthält.
```
ansible-galaxy collection install ansible.posix
```
Hinweis: Möglicherweise sehen Sie eine Warnung bezüglich der Kompatibilität der Ansible-Version, aber die Sammlung funktioniert für diese Übung trotzdem korrekt.
Erstellen eines Playbooks mit einem Firewall-Fehler

Erstellen Sie ein neues Playbook namens firewall.yml, das versucht, den Dienst http zu aktivieren. Sie werden jedoch absichtlich einen falschen Servicenamen, web, verwenden, um einen Fehler auszulösen.
```
nano firewall.yml
```
Kopieren Sie den folgenden Inhalt und fügen Sie ihn in den Editor ein:
```
---
- name: Configure System Firewall
  hosts: localhost
  become: true
  tasks:
    - name: Allow web traffic through firewall
      ansible.posix.firewalld:
        ## ERROR: 'web' is not a standard firewalld service
        service: web
        permanent: true
        state: enabled
```
Speichern Sie die Datei und beenden Sie nano (Ctrl+X, Y, Enter).

Ausführen des Playbooks und Diagnostizieren des Fehlers

Führen Sie das Playbook aus. Es wird fehlschlagen, da firewalld keinen Dienst namens web erkennt.

ansible-playbook firewall.yml

Erwartete Ausgabe (Fehler): Die Fehlermeldung besagt deutlich, dass web kein unterstützter Dienst ist, und weist Sie direkt auf das Problem hin.

TASK [Allow web traffic through firewall] **************************************
fatal: [localhost]: FAILED! => {"changed": false, "msg": "web is not a supported service. This is what I have."}

PLAY RECAP *********************************************************************
localhost                  : ok=1    changed=0    unreachable=0    failed=1    skipped=0    rescued=0    ignored=0

Finden des korrekten Firewall-Servicenamens

Um die Liste der gültigen, vordefinierten Servicenamen zu finden, können Sie das Befehlszeilentool firewall-cmd verwenden.
```
firewall-cmd --get-services
```
Erwartete Ausgabe: Sie sehen eine lange Liste verfügbarer Dienste. Suchen Sie in der Liste nach dem richtigen Dienst für den Webverkehr, der http ist.
```
RH-Satellite-6 ... ftp http https imaps ipp ipp-client ...
```
Korrigieren des Playbooks und erfolgreiches Ausführen

Bearbeiten Sie firewall.yml und ersetzen Sie den falschen Servicenamen web durch den korrekten Namen http.
```
nano firewall.yml
```
Die korrigierte Aufgabe sollte wie folgt aussehen:
```
## ... (rest of the file)
- name: Allow web traffic through firewall
  ansible.posix.firewalld:
    ## FIX: Use the correct firewalld service name
    service: http
    permanent: true
    state: enabled
```
Speichern und beenden Sie. Führen Sie das Playbook nun erneut aus. Es sollte erfolgreich abgeschlossen werden.
```
ansible-playbook firewall.yml
```

Teil 2: Fehlerbehebung bei Nichterreichbarkeit von Hosts

Ein "unreachable"-Fehler bedeutet, dass Ansible keine Verbindung zu einem Host herstellen kann, der in Ihrer Inventardatei aufgeführt ist. Dies wird oft durch einen einfachen Tippfehler im Hostnamen verursacht.

Simulieren eines nicht erreichbaren Hosts

Führen Sie absichtlich einen Tippfehler in Ihrer inventory-Datei ein und entfernen Sie die lokale Verbindungseinstellung. Dies zwingt Ansible, eine tatsächliche Netzwerkverbindung zum falsch geschriebenen Hostnamen herzustellen.
```
nano inventory
```
Ändern Sie localhost in localhossst und entfernen Sie ansible_connection=local.
```
## ERROR: Intentional typo in hostname, no local connection
localhossst
```
Speichern Sie die Datei und beenden Sie den Editor.
Anpassen des Playbooks zur Verwendung von Inventar-Hosts

Zuerst müssen Sie das Playbook webserver.yml anpassen, um die Inventar-Hosts anstelle des hartcodierten localhost zu verwenden. Wenn ein Playbook hosts: localhost verwendet, behandelt Ansible dies als Sonderfall und umgeht die Inventardatei vollständig.
```
nano webserver.yml
```
Ändern Sie die Zeile hosts von localhost zu all:
```
---
- name: Configure Web Server
  hosts: all ## Changed from 'localhost' to use inventory hosts
  become: true
  ## ... rest of the playbook remains the same
```
Speichern Sie die Datei und beenden Sie den Editor.

Ausführen des Playbooks, um den Fehler auszulösen

Versuchen Sie nun, das geänderte Playbook auszuführen. Es wird fehlschlagen, da das Inventar den Tippfehler localhossst enthält.

ansible-playbook webserver.yml

Erwartete Ausgabe (Fehler): Ansible schlägt fehl und meldet den Host als UNREACHABLE. Die Fehlermeldung zeigt an, dass der Hostname nicht aufgelöst werden konnte.

PLAY [Configure Web Server] ****************************************************

TASK [Gathering Facts] **********************************************************
fatal: [localhossst]: UNREACHABLE! => {"changed": false, "msg": "Failed to connect to the host via ssh: ssh: Could not resolve hostname localhossst: Name or service not known", "unreachable": true}

PLAY RECAP *********************************************************************
localhossst                : ok=0    changed=0    unreachable=1    failed=0    skipped=0    rescued=0    ignored=0

Korrigieren der Inventardatei

Der Status UNREACHABLE ist Ihr Signal, Hostnamen und Netzwerkverbindungen zu überprüfen. In diesem Fall besteht die Lösung darin, den Tippfehler in der inventory-Datei zu korrigieren.
```
nano inventory
```
Ändern Sie localhossst zurück zu localhost.
```
## FIX: Corrected hostname
localhost ansible_connection=local
```
Speichern und beenden Sie. Wenn Sie ansible-playbook webserver.yml erneut ausführen, wird es nun erfolgreich sein.
Optional: Wiederherstellen des ursprünglichen Playbooks

Wenn Sie das Playbook für zukünftige Übungen wieder auf hosts: localhost zurücksetzen möchten, können Sie dies ändern:
```
nano webserver.yml
```
Ändern Sie die Zeile hosts zurück zu localhost:
```
---
- name: Configure Web Server
  hosts: localhost ## Restored to original
  become: true
  ## ... rest of the playbook
```
Speichern und beenden Sie. Dieser Schritt demonstriert den Unterschied zwischen der Verwendung des hartcodierten localhost (der das Inventar umgeht) und der Verwendung von im Inventar definierten Hosts.

Zusammenfassung

In diesem Lab haben Sie eine Red Hat Enterprise Linux-Umgebung für Ansible vorbereitet, indem Sie ansible-core installiert und die Protokollierung konfiguriert haben. Anschließend haben Sie eine Vielzahl gängiger Probleme behoben. Sie haben gelernt, Fehler in Playbooks zu diagnostizieren und zu beheben, wie z. B. die Korrektur falscher YAML-Syntax, Einrückungen, Jinja2-Anführungszeichen und ungültiger Template-Pfade. Diese Fähigkeiten sind grundlegend für das Schreiben von gültigem und zuverlässigem Automatisierungscode.

Darüber hinaus haben Sie Probleme im Zusammenhang mit der verwalteten Host-Umgebung behandelt. Sie haben den Check-Modus von Ansible genutzt, um sicher einen Trockenlauf durchzuführen und potenzielle Dienstfehler auf einem Zielknoten zu identifizieren, ohne tatsächliche Änderungen vorzunehmen. Das Lab endete mit der Behandlung von Konnektivitätsproblemen, bei denen Sie Firewall-Konfigurationen korrigiert haben, um die Nichterreichbarkeit von Hosts zu beheben, und so einen umfassenden Ansatz zur Fehlerbehebung vom Steuerknoten bis zum verwalteten Host boten.