Dateien auf RHEL mit Ansible bereitstellen und verwalten

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 die grundlegenden Fähigkeiten für die Bereitstellung und Verwaltung von Dateien auf einem Red Hat Enterprise Linux (RHEL) System mit Ansible. Sie werden praktische Erfahrungen mit einigen der gängigsten und leistungsfähigsten Ansible-Module für Dateioperationen sammeln, beginnend mit der einfachen Bereitstellung von Dateien bis hin zur fortgeschrittenen Inhaltsmanipulation und Zustandsverwaltung.

Sie beginnen mit der Verwendung des Moduls ansible.builtin.copy, um eine statische Datei zu übertragen und ihre Attribute festzulegen. Als Nächstes modifizieren Sie den Dateiinhalt mit lineinfile und blockinfile und generieren ein benutzerdefiniertes MOTD (Message of the Day) mit dem Modul ansible.builtin.template. Das Lab deckt auch die Erstellung von symbolischen Links, die Überprüfung von Dateizuständen mit stat, das Abrufen von Protokollen mit fetch und die Bereinigung verwalteter Dateien ab und bietet so einen umfassenden Überblick über die Dateiverwaltungsfähigkeiten von Ansible.

Eine statische Datei kopieren und Attribute mit dem Modul ansible.builtin.copy festlegen

In diesem Schritt lernen Sie, wie Sie eines der grundlegendsten Ansible-Module verwenden: ansible.builtin.copy. Dieses Modul wird verwendet, um Dateien von Ihrem Steuerknoten (der LabEx VM) an einen bestimmten Speicherort auf Ihren verwalteten Hosts zu übertragen. In unserem Fall ist der verwaltete Host localhost selbst. Neben dem reinen Kopieren ermöglicht das copy-Modul die präzise Steuerung der Dateiattribute, wie z. B. Besitzer, Gruppe und Berechtigungsmodus, was für eine ordnungsgemäße Systemkonfiguration unerlässlich ist.

Zuerst richten wir unsere Projektumgebung ein. Alle unsere Arbeiten werden im Verzeichnis ~/project durchgeführt.

  1. Navigieren Sie zum Projektverzeichnis und erstellen Sie ein Unterverzeichnis für unsere Quelldateien. Dies ist eine gängige Praxis, um Ihr Projekt organisiert zu halten.

    Installieren Sie das Paket ansible-core.

    sudo dnf install -y ansible-core

    Navigieren Sie dann zum Projektverzeichnis und erstellen Sie ein Unterverzeichnis für unsere Quelldateien.

    cd ~/project
    mkdir files
  2. Erstellen Sie als Nächstes eine einfache Textdatei, die wir kopieren werden. Wir verwenden einen cat-Befehl mit einem "Here-Dokument", um die Datei info.txt im Verzeichnis files zu erstellen.

    cat << EOF > ~/project/files/info.txt
    This file was deployed by Ansible.
    It contains important system information.
    EOF
  3. Erstellen Sie nun eine Ansible-Inventardatei. Das Inventar teilt Ansible mit, welche Hosts verwaltet werden sollen. Für dieses Lab verwalten wir die lokale Maschine. Erstellen Sie eine Datei namens inventory.ini.

    cat << EOF > ~/project/inventory.ini
    localhost ansible_connection=local
    EOF

    In diesem Inventar ist localhost der Host, den wir anvisieren. Die Variable ansible_connection=local weist Ansible an, die Aufgaben direkt auf dem Steuerknoten auszuführen, ohne SSH zu verwenden.

  4. Erstellen Sie Ihr erstes Ansible-Playbook. Dieses Playbook enthält die Anweisungen zum Kopieren der Datei. Verwenden Sie nano oder cat, um eine Datei namens copy_file.yml zu erstellen.

    nano ~/project/copy_file.yml

    Fügen Sie den folgenden Inhalt in die Datei ein. Dieses Playbook definiert eine Aufgabe: info.txt nach /tmp/ zu kopieren und seine Attribute festzulegen.

    ---
    - name: Deploy a static file to localhost
      hosts: localhost
      tasks:
        - name: Copy info.txt and set attributes
          ansible.builtin.copy:
            src: files/info.txt
            dest: /tmp/info.txt
            owner: labex
            group: labex
            mode: "0640"

    Lassen Sie uns die Parameter in der copy-Aufgabe aufschlüsseln:

    • src: files/info.txt: Der Pfad zur Quelldatei auf dem Steuerknoten, relativ zum Speicherort des Playbooks.
    • dest: /tmp/info.txt: Der absolute Pfad, an dem die Datei auf dem verwalteten Host platziert wird.
    • owner: labex: Legt den Besitzer der Datei auf den Benutzer labex fest.
    • group: labex: Legt die Gruppe der Datei auf die Gruppe labex fest.
    • mode: '0640': Legt die Berechtigungen der Datei fest. 0640 bedeutet, dass der Besitzer lesen/schreiben darf, die Gruppe lesen darf und andere keine Berechtigungen haben.
  5. Führen Sie das Playbook mit dem Befehl ansible-playbook aus. Das Flag -i gibt unsere Inventardatei an.

    ansible-playbook -i inventory.ini copy_file.yml

    Sie sollten eine Ausgabe sehen, die die erfolgreiche Ausführung des Playbooks anzeigt, ähnlich dieser:

    PLAY [Deploy a static file to localhost] ***************************************
    
    TASK [Gathering Facts] *********************************************************
    ok: [localhost]
    
    TASK [Copy info.txt and set attributes] ****************************************
    changed: [localhost]
    
    PLAY RECAP *********************************************************************
    localhost                  : ok=2    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
  6. Überprüfen Sie abschließend, ob die Datei korrekt kopiert wurde und die richtigen Attribute hat. Verwenden Sie den Befehl ls -l, um die Berechtigungen, den Besitzer und die Gruppe zu überprüfen.

    ls -l /tmp/info.txt

    Die Ausgabe sollte zeigen, dass labex der Besitzer und die Gruppe ist und die Berechtigungen -rw-r----- lauten.

    -rw-r----- 1 labex labex 72 Jul 10 14:30 /tmp/info.txt

    Sie können auch den Inhalt der Datei anzeigen, um sicherzustellen, dass sie vollständig kopiert wurde.

    cat /tmp/info.txt
    This file was deployed by Ansible.
    It contains important system information.

Sie haben erfolgreich das Modul ansible.builtin.copy verwendet, um eine Datei bereitzustellen und ihre Attribute auf Ihrem lokalen System zu konfigurieren.

Dateiinhalte mit lineinfile und blockinfile ändern

In diesem Schritt lernen Sie, wie Sie vorhandene Dateien auf einem verwalteten Host ändern, ohne die gesamte Datei zu ersetzen. Ansible bietet hierfür leistungsstarke Module: ansible.builtin.lineinfile zur Verwaltung einzelner Zeilen und ansible.builtin.blockinfile zur Verwaltung von mehrzeiligen Textblöcken. Diese sind äußerst nützlich für Aufgaben wie das Ändern von Konfigurationseinstellungen oder das Hinzufügen von Einträgen zu Protokolldateien.

Wir arbeiten weiterhin mit der Datei info.txt, die Sie im vorherigen Schritt erstellt haben und die sich unter /tmp/info.txt befindet.

  1. Stellen Sie zunächst sicher, dass Sie sich im Projektverzeichnis befinden.

    cd ~/project
  2. Erstellen Sie ein neues Playbook namens modify_file.yml. Dieses Playbook enthält zwei Aufgaben: eine zum Hinzufügen einer einzelnen Zeile und eine weitere zum Hinzufügen eines Textblocks zu unserer vorhandenen Datei.

    nano ~/project/modify_file.yml
  3. Fügen Sie Ihrer modify_file.yml-Playbook den folgenden Inhalt hinzu. Dieses Playbook zielt auf localhost ab und verwendet sowohl lineinfile als auch blockinfile, um Inhalte an /tmp/info.txt anzuhängen.

    ---
    - name: Modify an existing file
      hosts: localhost
      tasks:
        - name: Add a single line of text to a file
          ansible.builtin.lineinfile:
            path: /tmp/info.txt
            line: This line was added by the lineinfile module.
            state: present
    
        - name: Add a block of text to an existing file
          ansible.builtin.blockinfile:
            path: /tmp/info.txt
            block: |
              ## BEGIN ANSIBLE MANAGED BLOCK
              This block of text consists of two lines.
              They have been added by the blockinfile module.
              ## END ANSIBLE MANAGED BLOCK
            state: present

    Betrachten wir die verwendeten Module:

    • ansible.builtin.lineinfile: Dieses Modul stellt sicher, dass eine bestimmte Zeile in einer Datei vorhanden ist. Wenn die Zeile bereits existiert, tut Ansible nichts, was die Aufgabe idempotent macht.
      • path: Die zu ändernde Datei.
      • line: Die Textzeile, die in der Datei vorhanden sein soll.
      • state: present: Stellt sicher, dass die Zeile vorhanden ist. Sie könnten state: absent verwenden, um sie zu entfernen.
    • ansible.builtin.blockinfile: Dieses Modul verwaltet einen Textblock, der von Markierungszeilen umgeben ist (z. B. ## BEGIN ANSIBLE MANAGED BLOCK). Dies ist ideal für die Verwaltung von Konfigurationsabschnitten.
      • path: Die zu ändernde Datei.
      • block: Der mehrzeilige String, der eingefügt werden soll. Das | ist YAML-Syntax für einen Literalblock, der Zeilenumbrüche beibehält.
      • state: present: Stellt sicher, dass der Block vorhanden ist.
  4. Führen Sie das Playbook mit dem Befehl ansible-playbook und Ihrer inventory.ini-Datei aus.

    ansible-playbook -i inventory.ini modify_file.yml

    Die Ausgabe zeigt, dass beide Aufgaben Änderungen an der Datei vorgenommen haben.

    PLAY [Modify an existing file] *************************************************
    
    TASK [Gathering Facts] *********************************************************
    ok: [localhost]
    
    TASK [Add a single line of text to a file] *************************************
    changed: [localhost]
    
    TASK [Add a block of text to an existing file] *********************************
    changed: [localhost]
    
    PLAY RECAP *********************************************************************
    localhost                  : ok=3    changed=2    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
  5. Überprüfen Sie abschließend die Änderungen, indem Sie den Inhalt von /tmp/info.txt anzeigen.

    cat /tmp/info.txt

    Sie sollten den ursprünglichen Inhalt sehen, gefolgt von der neuen Zeile und dem neuen Textblock.

    This file was deployed by Ansible.
    It contains important system information.
    This line was added by the lineinfile module.
    ## BEGIN ANSIBLE MANAGED BLOCK
    This block of text consists of two lines.
    They have been added by the blockinfile module.
    ## END ANSIBLE MANAGED BLOCK

    Wenn Sie das Playbook erneut ausführen, meldet Ansible ok=3 und changed=0, da der Inhalt bereits vorhanden ist, was die idempotente Natur dieser Module demonstriert.

Generieren eines benutzerdefinierten MOTD mit dem Modul ansible.builtin.template

In diesem Schritt gehen Sie von der Kopie statischer Dateien zur Generierung dynamischer Dateien mit dem Modul ansible.builtin.template über. Dieses Modul nutzt die Jinja2-Templating-Engine, um Dateien zu erstellen, die mit Variablen und Systeminformationen, sogenannten "Facts", angepasst werden, die Ansible von Ihren verwalteten Hosts sammelt. Wir erstellen eine dynamische Message of the Day (MOTD), die systemspezifische Informationen anzeigt.

  1. Stellen Sie zunächst sicher, dass Sie sich im Verzeichnis ~/project befinden, und erstellen Sie ein eigenes Unterverzeichnis für Ihre Templates. Es ist eine gängige Best Practice in Ansible, Jinja2-Templates in einem templates-Verzeichnis zu speichern.

    cd ~/project
    mkdir templates
  2. Erstellen Sie als Nächstes die Jinja2-Template-Datei. Diese Datei, motd.j2, enthält die Struktur unseres MOTD mit Platzhaltern für dynamische Daten. Die Erweiterung .j2 ist eine übliche Konvention für Jinja2-Templates.

    nano ~/project/templates/motd.j2

    Fügen Sie den folgenden Inhalt in die Datei ein. Beachten Sie die Syntax {{ ... }}, die einen Platzhalter für eine Variable oder einen Fact kennzeichnet.

    #################################################################
    ##          Welcome to {{ ansible_facts['fqdn'] }}
    #
    ## This is a {{ ansible_facts['distribution'] }} system.
    ## System managed by Ansible.
    #
    ## For support, contact: {{ admin_email }}
    #################################################################

    In diesem Template:

    • {{ ansible_facts['fqdn'] }} wird durch den Fully Qualified Domain Name (FQDN) des Hosts ersetzt.
    • {{ ansible_facts['distribution'] }} wird durch den Namen der Linux-Distribution (z. B. RedHat) ersetzt.
    • {{ admin_email }} ist eine benutzerdefinierte Variable, die wir in unserem Playbook definieren werden.
  3. Erstellen Sie nun ein neues Playbook namens template_motd.yml. Dieses Playbook verwendet das Template, um /etc/motd zu generieren.

    nano ~/project/template_motd.yml

    Fügen Sie den folgenden Inhalt hinzu. Dieses Playbook erfordert erhöhte Berechtigungen (become: true), um in das Verzeichnis /etc schreiben zu können. Es definiert auch die benutzerdefinierte Variable admin_email.

    ---
    - name: Deploy a custom MOTD from a template
      hosts: localhost
      become: true
      vars:
        admin_email: [email protected]
      tasks:
        - name: Generate /etc/motd from template
          ansible.builtin.template:
            src: templates/motd.j2
            dest: /etc/motd
            owner: root
            group: root
            mode: "0644"

    Wichtige Parameter in diesem Playbook:

    • become: true: Dies weist Ansible an, sudo zur Ausführung der Aufgabe zu verwenden, was zum Schreiben in /etc/motd erforderlich ist.
    • vars: In diesem Abschnitt definieren wir benutzerdefinierte Variablen wie admin_email.
    • ansible.builtin.template: Das Modul, das das Jinja2-Template verarbeitet. src verweist auf unsere .j2-Datei, und dest ist die Zieldatei auf dem verwalteten Host.
  4. Führen Sie das Playbook aus.

    ansible-playbook -i inventory.ini template_motd.yml

    Die Ausgabe sollte bestätigen, dass die Aufgabe erfolgreich war.

    PLAY [Deploy a custom MOTD from a template] ************************************
    
    TASK [Gathering Facts] *********************************************************
    ok: [localhost]
    
    TASK [Generate /etc/motd from template] ****************************************
    changed: [localhost]
    
    PLAY RECAP *********************************************************************
    localhost                  : ok=2    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
  5. Überprüfen Sie das Ergebnis. Überprüfen Sie den Inhalt der neu generierten Datei /etc/motd.

    cat /etc/motd

    Sie sehen die gerenderte Ausgabe, bei der die Jinja2-Platzhalter durch tatsächliche System-Facts und die von Ihnen definierte benutzerdefinierte Variable ersetzt wurden. Der fqdn entspricht dem Hostnamen Ihrer Laborumgebung.

    #################################################################
    ##          Welcome to host.labex.io
    #
    ## This is a RedHat system.
    ## System managed by Ansible.
    #
    ## For support, contact: [email protected]
    #################################################################

Sie haben nun erfolgreich eine Vorlage verwendet, um eine benutzerdefinierte Datei zu erstellen, eine Kernkompetenz in der Infrastrukturautomatisierung.

In diesem Schritt kombinieren Sie Ihr Wissen über das copy-Modul mit einem neuen, vielseitigen Modul: ansible.builtin.file. Während copy zum Übertragen von Inhalten verwendet wird, dient file zur Verwaltung des Zustands von Dateien, Verzeichnissen und symbolischen Links auf dem verwalteten Host. Sie werden es verwenden, um Verzeichnisse zu erstellen, Berechtigungen festzulegen und, was für diese Übung am wichtigsten ist, symbolische Links zu erstellen.

Unser Szenario ist die Konfiguration der Pre-Login-Nachrichten, die vom System angezeigt werden. In vielen Linux-Systemen wird /etc/issue für lokale Terminalbenutzer angezeigt, und /etc/issue.net wird für Remote-Benutzer (z. B. über SSH) angezeigt. Wir werden eine einzelne issue-Datei bereitstellen und dann einen symbolischen Link erstellen, damit /etc/issue.net auf /etc/issue verweist, um sicherzustellen, dass sie immer dieselbe Nachricht anzeigen.

  1. Stellen Sie zunächst sicher, dass Sie sich im Verzeichnis ~/project befinden, und erstellen Sie die Quelldatei für unsere Issue-Nachricht. Wir werden diese Datei im zuvor erstellten Unterverzeichnis files ablegen.

    cd ~/project
    cat << EOF > ~/project/files/issue
    Authorized access only.
    All connections are logged and monitored.
    EOF
  2. Erstellen Sie ein neues Playbook namens deploy_issue.yml. Dieses Playbook enthält zwei Aufgaben: eine zum Kopieren der issue-Datei und eine weitere zum Erstellen des symbolischen Links.

    nano ~/project/deploy_issue.yml
  3. Fügen Sie Ihrer deploy_issue.yml-Playbook den folgenden Inhalt hinzu. Dieses Playbook erfordert erhöhte Berechtigungen (become: true), um Dateien im Verzeichnis /etc/ zu verwalten.

    ---
    - name: Configure system issue files
      hosts: localhost
      become: true
      tasks:
        - name: Copy custom /etc/issue file
          ansible.builtin.copy:
            src: files/issue
            dest: /etc/issue
            owner: root
            group: root
            mode: "0644"
    
        - name: Ensure /etc/issue.net is a symlink to /etc/issue
          ansible.builtin.file:
            src: /etc/issue
            dest: /etc/issue.net
            state: link
            force: yes

    Analysieren wir die neue Aufgabe ansible.builtin.file:

    • src: /etc/issue: Wenn state auf link gesetzt ist, gibt src die Datei an, auf die der symbolische Link verweisen soll.
    • dest: /etc/issue.net: Dies ist der Pfad, an dem der symbolische Link selbst erstellt wird.
    • state: link: Dieser entscheidende Parameter weist das file-Modul an, einen symbolischen Link zu erstellen, keine reguläre Datei oder ein Verzeichnis.
    • force: yes: Dies ist eine nützliche Option, die die Idempotenz sicherstellt. Wenn /etc/issue.net bereits als reguläre Datei existiert, wird Ansible diese entfernen und den Link erstellen. Ohne force: yes würde das Playbook in dieser Situation fehlschlagen.
  4. Führen Sie das Playbook aus.

    ansible-playbook -i inventory.ini deploy_issue.yml

    Die Ausgabe zeigt, dass beide Aufgaben erfolgreich Änderungen vorgenommen haben.

    PLAY [Configure system issue files] ********************************************
    
    TASK [Gathering Facts] *********************************************************
    ok: [localhost]
    
    TASK [Copy custom /etc/issue file] *********************************************
    changed: [localhost]
    
    TASK [Ensure /etc/issue.net is a symlink to /etc/issue] ************************
    changed: [localhost]
    
    PLAY RECAP *********************************************************************
    localhost                  : ok=3    changed=2    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
  5. Überprüfen Sie das Ergebnis mit dem Befehl ls -l. Dieser Befehl liefert eine detaillierte Auflistung, die symbolische Links klar anzeigt.

    ls -l /etc/issue /etc/issue.net

    Die Ausgabe sollte zeigen, dass /etc/issue eine reguläre Datei ist und /etc/issue.net ein symbolischer Link ist, der darauf verweist. Das l am Anfang der Berechtigungen für /etc/issue.net zeigt an, dass es sich um einen Link handelt.

    -rw-r--r--. 1 root root 65 Jul 10 15:00 /etc/issue
    lrwxrwxrwx. 1 root root 10 Jul 10 15:00 /etc/issue.net -> /etc/issue

Sie haben nun erfolgreich eine Konfigurationsdatei bereitgestellt und das Modul ansible.builtin.file verwendet, um einen symbolischen Link zu erstellen, ein gängiges und leistungsfähiges Muster für die Verwaltung von Systemkonfigurationen.

Überprüfen des Dateizustands mit stat und Abrufen von Protokollen mit fetch

In diesem Schritt lernen Sie zwei wichtige Module zur Datenerfassung kennen: ansible.builtin.stat und ansible.builtin.fetch. Das stat-Modul wird verwendet, um den Status einer Datei oder eines Verzeichnisses auf einem verwalteten Host zu überprüfen – zum Beispiel, um festzustellen, ob es existiert, welche Berechtigungen es hat oder wann es zuletzt geändert wurde. Es ändert nichts und ist daher perfekt für Überprüfungen und bedingte Logik geeignet. Das fetch-Modul tut das Gegenteil von copy: Es ruft Dateien vom verwalteten Host ab und speichert sie auf Ihrem Steuerknoten, was ideal für die Sicherung von Konfigurationen oder das Sammeln von Protokolldateien zur Analyse ist.

Wir erstellen ein Playbook, das zuerst die Existenz der zuvor erstellten Datei /etc/motd überprüft und dann die Protokolldatei des DNF-Paketmanagers (/var/log/dnf.log) in ein lokales Verzeichnis auf Ihrer LabEx VM abruft.

  1. Stellen Sie zunächst sicher, dass Sie sich im Verzeichnis ~/project befinden, und erstellen Sie ein neues Unterverzeichnis, um die abzurufenden Dateien zu speichern.

    cd ~/project
    mkdir fetched_logs
  2. Erstellen Sie ein neues Playbook namens check_and_fetch.yml. Dieses Playbook enthält die Aufgaben zur Überprüfung der Datei und zum Abrufen des Protokolls.

    nano ~/project/check_and_fetch.yml
  3. Fügen Sie Ihrer check_and_fetch.yml-Playbook den folgenden Inhalt hinzu. Dieses Playbook verwendet stat, um Dateidetails abzurufen, register, um diese Details in einer Variablen zu speichern, debug, um die Variable anzuzeigen, und fetch, um die Protokolldatei abzurufen.

    ---
    - name: Check file status and fetch logs
      hosts: localhost
      become: true
      tasks:
        - name: Check if /etc/motd exists
          ansible.builtin.stat:
            path: /etc/motd
          register: motd_status
    
        - name: Display stat results
          ansible.builtin.debug:
            var: motd_status.stat
    
        - name: Fetch the dnf log file from managed host
          ansible.builtin.fetch:
            src: /var/log/dnf.log
            dest: fetched_logs/
            flat: yes

    Lassen Sie uns die Schlüsselkonzepte aufschlüsseln:

    • register: motd_status: Dies ist eine entscheidende Ansible-Funktion. Sie nimmt die gesamte Ausgabe einer Aufgabe und speichert sie in einer neuen Variablen namens motd_status.
    • ansible.builtin.debug: Dieses Modul wird verwendet, um Werte während der Ausführung eines Playbooks auszugeben. Hier geben wir das stat-Objekt innerhalb unserer registrierten Variablen (motd_status.stat) aus, um die Eigenschaften der Datei anzuzeigen.
    • ansible.builtin.fetch: Dieses Modul ruft eine Datei vom verwalteten Host ab.
      • src: Der Pfad der abzurufenden Datei vom verwalteten Host.
      • dest: Das Verzeichnis auf dem Steuerknoten (Ihrer LabEx VM), in dem die Datei gespeichert wird.
      • flat: yes: Standardmäßig erstellt fetch eine Unterverzeichnisstruktur, die dem Host und dem Quellpfad entspricht. flat: yes vereinfacht dies, indem die Datei direkt in das dest-Verzeichnis kopiert wird, ohne zusätzliche Unterverzeichnisse.
  4. Führen Sie das Playbook aus. Da wir eine Systemprotokolldatei lesen, wird become: true verwendet, um die erforderlichen Berechtigungen zu erhalten.

    ansible-playbook -i inventory.ini check_and_fetch.yml

    Die Ausgabe zeigt die Ergebnisse der stat-Überprüfung in der Debug-Aufgabe, gefolgt von der fetch-Aufgabe.

    PLAY [Check file status and fetch logs] ****************************************
    
    TASK [Gathering Facts] *********************************************************
    ok: [localhost]
    
    TASK [Check if /etc/motd exists] ***********************************************
    ok: [localhost]
    
    TASK [Display stat results] ****************************************************
    ok: [localhost] => {
        "motd_status.stat": {
            "exists": true,
            "gid": 0,
            "isreg": true,
            "mode": "0644",
            "path": "/etc/motd",
            ...
        }
    }
    
    TASK [Fetch the dnf log file from managed host] ********************************
    changed: [localhost]
    
    PLAY RECAP *********************************************************************
    localhost                  : ok=4    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
  5. Überprüfen Sie, ob die Protokolldatei erfolgreich abgerufen wurde. Listen Sie den Inhalt des Verzeichnisses fetched_logs auf.

    ls -l ~/project/fetched_logs/

    Sie sollten die Datei dnf.log sehen, die nun lokal auf Ihrem Steuerknoten gespeichert ist.

    total 4
    -rw-r--r--. 1 labex labex 1234 Jul 10 15:30 dnf.log

Sie haben nun gelernt, wie Sie Dateieigenschaften überprüfen, ohne Änderungen vorzunehmen, und wie Sie wichtige Dateien von Ihren verwalteten Systemen zurück auf Ihren Steuerknoten abrufen.

Bereinigen verwalteter Host-Dateien mit dem file-Modul

In diesem letzten Schritt lernen Sie, wie Sie das Modul ansible.builtin.file verwenden, um sicherzustellen, dass Dateien und Verzeichnisse nicht auf einem System vorhanden sind. Ein wichtiger Teil der Konfigurationsverwaltung ist nicht nur die Erstellung und Änderung von Ressourcen, sondern auch deren Bereinigung. Durch Setzen des Parameters state auf absent können Sie Ansible anweisen, Dateien, symbolische Links oder sogar ganze Verzeichnisse zu entfernen.

Zum Abschluss dieses Labs schreiben wir ein einzelnes "Cleanup"-Playbook, das alle Artefakte entfernt, die wir in den vorherigen Schritten erstellt haben: /tmp/info.txt, /etc/motd, /etc/issue und den symbolischen Link /etc/issue.net.

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

    cd ~/project
  2. Erstellen Sie ein neues Playbook namens cleanup.yml. Dieses Playbook enthält alle Aufgaben, die zur Rückgängigmachung unserer Änderungen erforderlich sind.

    nano ~/project/cleanup.yml
  3. Fügen Sie Ihrer cleanup.yml-Playbook den folgenden Inhalt hinzu. Dieses Playbook verwendet eine Liste von Aufgaben, die jeweils auf eine der von uns erstellten Dateien abzielen. Beachten Sie, dass become: true auf Play-Ebene gesetzt ist, sodass alle Aufgaben mit erhöhten Berechtigungen ausgeführt werden.

    ---
    - name: Clean up managed files from the system
      hosts: localhost
      become: true
      tasks:
        - name: Remove the temporary info file
          ansible.builtin.file:
            path: /tmp/info.txt
            state: absent
    
        - name: Remove the custom MOTD file
          ansible.builtin.file:
            path: /etc/motd
            state: absent
    
        - name: Remove the custom issue file
          ansible.builtin.file:
            path: /etc/issue
            state: absent
    
        - name: Remove the issue.net symbolic link
          ansible.builtin.file:
            path: /etc/issue.net
            state: absent

    Der Schlüssel zu diesem Playbook ist der Parameter state: absent in jeder Aufgabe. Dies weist das file-Modul an, sicherzustellen, dass das Element unter dem angegebenen path nicht existiert. Wenn es die Datei findet, wird sie entfernt. Wenn die Datei bereits fehlt, tut es nichts und behält die Idempotenz bei.

  4. Führen Sie das Cleanup-Playbook aus.

    ansible-playbook -i inventory.ini cleanup.yml

    Die Ausgabe zeigt, dass jede Aufgabe erfolgreich eine Änderung vorgenommen hat, indem sie eine Datei entfernt hat.

    PLAY [Clean up managed files from the system] **********************************
    
    TASK [Gathering Facts] *********************************************************
    ok: [localhost]
    
    TASK [Remove the temporary info file] ******************************************
    changed: [localhost]
    
    TASK [Remove the custom MOTD file] *********************************************
    changed: [localhost]
    
    TASK [Remove the custom issue file] ********************************************
    changed: [localhost]
    
    TASK [Remove the issue.net symbolic link] **************************************
    changed: [localhost]
    
    PLAY RECAP *********************************************************************
    localhost                  : ok=5    changed=4    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
  5. Überprüfen Sie, ob die Dateien entfernt wurden. Sie können den Befehl ls verwenden, um deren Existenz zu überprüfen. Der Befehl meldet, dass er nicht darauf zugreifen kann, da sie nicht mehr vorhanden sind.

    ls /tmp/info.txt /etc/motd /etc/issue /etc/issue.net

    Die erwartete Ausgabe ist eine Reihe von Fehlermeldungen, die bestätigen, dass die Bereinigung erfolgreich war.

    ls: cannot access '/tmp/info.txt': No such file or directory
    ls: cannot access '/etc/motd': No such file or directory
    ls: cannot access '/etc/issue': No such file or directory
    ls: cannot access '/etc/issue.net': No such file or directory

Sie haben nun erfolgreich Ansible verwendet, um Dateien zu entfernen und ein System zu bereinigen, und damit den vollständigen Lebenszyklus der Dateiverwaltung von der Erstellung bis zur Löschung abgeschlossen.

Zusammenfassung

In diesem Lab haben Sie die Grundlagen der Dateiverwaltung auf RHEL-Systemen mit Ansible gelernt. Sie begannen mit der Verwendung des Moduls ansible.builtin.copy, um eine statische Datei auf einen verwalteten Host zu übertragen und dabei spezifische Eigentümerschaft und Berechtigungen festzulegen. Anschließend haben Sie untersucht, wie vorhandene Dateien modifiziert werden, indem Sie mit lineinfile sicherstellen, dass eine bestimmte Zeile vorhanden ist, und mit blockinfile mehrzeilige Textblöcke verwalten. Eine wichtige abgedeckte Fähigkeit war die Generierung dynamischer Dateiinhalte mithilfe des Moduls ansible.builtin.template und der Jinja2-Syntax, um eine benutzerdefinierte Nachricht des Tages (MOTD) zu erstellen, die mit Systeminformationen (facts) gefüllt ist.

Darüber hinaus haben Sie die Bereitstellung unterstützender Dateien und die Erstellung symbolischer Links mit dem Modul ansible.builtin.file geübt. Um sicherzustellen, dass Ihre Bereitstellungen erfolgreich waren, haben Sie das Modul stat verwendet, um den Zustand und die Attribute von Dateien zu überprüfen, und das Modul fetch, um Dateien, wie z. B. Protokolle, vom verwalteten Host zurück zum Steuerknoten abzurufen. Schließlich haben Sie gelernt, wie Sie Bereinigungsoperationen durchführen, indem Sie das Modul file mit state: absent verwenden, um die während des Labs erstellten Dateien und Verzeichnisse zu entfernen und so einen sauberen Zustand auf dem verwalteten Host zu gewährleisten.