Ansible Playbooks und Hosts unter RHEL beheben

AnsibleAnsibleBeginner
Jetzt üben

💡 Dieser Artikel wurde von AI-Assistenten übersetzt. Um die englische Version anzuzeigen, können Sie hier klicken

Einleitung

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.

Vorbereiten der RHEL-Umgebung und Konfigurieren des Ansible-Loggings

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.

  1. 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!
  2. 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.

  3. 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
  4. 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.

Beheben von YAML-Syntax- und Einrückungsfehlern in einem Playbook

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.

  1. 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.

  2. 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.

  3. 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.

  4. Ü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

Beheben von Jinja2-Anführungszeichen- und Template-Pfadfehlern

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.

  1. 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).

  2. 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.

  3. 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.

  4. 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.

  5. 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

Verwenden des Check-Modus zur Fehlerbehebung bei Diensten auf verwalteten Hosts

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.

  1. 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).

  2. 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
  3. 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/[email protected]
    ...

    Die Ausgabe httpd.service zeigt Ihnen, dass der korrekte Servicename httpd ist.

  4. 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.

  1. 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.

  2. 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).

  3. 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
  4. 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 ...
  5. 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.

  1. 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.

  2. 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.

  3. 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
  4. 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.

  5. 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.