Einführung
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.
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-coreNavigieren Sie dann zum Projektverzeichnis und erstellen Sie ein Unterverzeichnis für unsere Quelldateien.
cd ~/project mkdir filesErstellen Sie als Nächstes eine einfache Textdatei, die wir kopieren werden. Wir verwenden einen
cat-Befehl mit einem "Here-Dokument", um die Dateiinfo.txtim Verzeichnisfileszu erstellen.cat << EOF > ~/project/files/info.txt This file was deployed by Ansible. It contains important system information. EOFErstellen 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 EOFIn diesem Inventar ist
localhostder Host, den wir anvisieren. Die Variableansible_connection=localweist Ansible an, die Aufgaben direkt auf dem Steuerknoten auszuführen, ohne SSH zu verwenden.Erstellen Sie Ihr erstes Ansible-Playbook. Dieses Playbook enthält die Anweisungen zum Kopieren der Datei. Verwenden Sie
nanoodercat, um eine Datei namenscopy_file.ymlzu erstellen.nano ~/project/copy_file.ymlFügen Sie den folgenden Inhalt in die Datei ein. Dieses Playbook definiert eine Aufgabe:
info.txtnach/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 Benutzerlabexfest.group: labex: Legt die Gruppe der Datei auf die Gruppelabexfest.mode: '0640': Legt die Berechtigungen der Datei fest.0640bedeutet, dass der Besitzer lesen/schreiben darf, die Gruppe lesen darf und andere keine Berechtigungen haben.
Führen Sie das Playbook mit dem Befehl
ansible-playbookaus. Das Flag-igibt unsere Inventardatei an.ansible-playbook -i inventory.ini copy_file.ymlSie 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Ü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.txtDie Ausgabe sollte zeigen, dass
labexder Besitzer und die Gruppe ist und die Berechtigungen-rw-r-----lauten.-rw-r----- 1 labex labex 72 Jul 10 14:30 /tmp/info.txtSie können auch den Inhalt der Datei anzeigen, um sicherzustellen, dass sie vollständig kopiert wurde.
cat /tmp/info.txtThis 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.
Stellen Sie zunächst sicher, dass Sie sich im Projektverzeichnis befinden.
cd ~/projectErstellen 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.ymlFügen Sie Ihrer
modify_file.yml-Playbook den folgenden Inhalt hinzu. Dieses Playbook zielt auflocalhostab und verwendet sowohllineinfileals auchblockinfile, um Inhalte an/tmp/info.txtanzuhä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: presentBetrachten 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önntenstate: absentverwenden, 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.
Führen Sie das Playbook mit dem Befehl
ansible-playbookund Ihrerinventory.ini-Datei aus.ansible-playbook -i inventory.ini modify_file.ymlDie 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Überprüfen Sie abschließend die Änderungen, indem Sie den Inhalt von
/tmp/info.txtanzeigen.cat /tmp/info.txtSie 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 BLOCKWenn Sie das Playbook erneut ausführen, meldet Ansible
ok=3undchanged=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.
Stellen Sie zunächst sicher, dass Sie sich im Verzeichnis
~/projectbefinden, und erstellen Sie ein eigenes Unterverzeichnis für Ihre Templates. Es ist eine gängige Best Practice in Ansible, Jinja2-Templates in einemtemplates-Verzeichnis zu speichern.cd ~/project mkdir templatesErstellen 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.j2ist eine übliche Konvention für Jinja2-Templates.nano ~/project/templates/motd.j2Fü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.
Erstellen Sie nun ein neues Playbook namens
template_motd.yml. Dieses Playbook verwendet das Template, um/etc/motdzu generieren.nano ~/project/template_motd.ymlFügen Sie den folgenden Inhalt hinzu. Dieses Playbook erfordert erhöhte Berechtigungen (
become: true), um in das Verzeichnis/etcschreiben zu können. Es definiert auch die benutzerdefinierte Variableadmin_email.--- - name: Deploy a custom MOTD from a template hosts: localhost become: true vars: admin_email: admin@labex.io 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,sudozur Ausführung der Aufgabe zu verwenden, was zum Schreiben in/etc/motderforderlich ist.vars: In diesem Abschnitt definieren wir benutzerdefinierte Variablen wieadmin_email.ansible.builtin.template: Das Modul, das das Jinja2-Template verarbeitet.srcverweist auf unsere.j2-Datei, unddestist die Zieldatei auf dem verwalteten Host.
Führen Sie das Playbook aus.
ansible-playbook -i inventory.ini template_motd.ymlDie 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Überprüfen Sie das Ergebnis. Überprüfen Sie den Inhalt der neu generierten Datei
/etc/motd.cat /etc/motdSie sehen die gerenderte Ausgabe, bei der die Jinja2-Platzhalter durch tatsächliche System-Facts und die von Ihnen definierte benutzerdefinierte Variable ersetzt wurden. Der
fqdnentspricht dem Hostnamen Ihrer Laborumgebung.################################################################# ## Welcome to host.labex.io # ## This is a RedHat system. ## System managed by Ansible. # ## For support, contact: admin@labex.io #################################################################
Sie haben nun erfolgreich eine Vorlage verwendet, um eine benutzerdefinierte Datei zu erstellen, eine Kernkompetenz in der Infrastrukturautomatisierung.
Bereitstellen von unterstützenden Dateien und Erstellen eines symbolischen Links mit copy und file
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.
Stellen Sie zunächst sicher, dass Sie sich im Verzeichnis
~/projectbefinden, und erstellen Sie die Quelldatei für unsere Issue-Nachricht. Wir werden diese Datei im zuvor erstellten Unterverzeichnisfilesablegen.cd ~/project cat << EOF > ~/project/files/issue Authorized access only. All connections are logged and monitored. EOFErstellen Sie ein neues Playbook namens
deploy_issue.yml. Dieses Playbook enthält zwei Aufgaben: eine zum Kopieren derissue-Datei und eine weitere zum Erstellen des symbolischen Links.nano ~/project/deploy_issue.ymlFü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: yesAnalysieren wir die neue Aufgabe
ansible.builtin.file:src: /etc/issue: Wennstateauflinkgesetzt ist, gibtsrcdie 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 dasfile-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.netbereits als reguläre Datei existiert, wird Ansible diese entfernen und den Link erstellen. Ohneforce: yeswürde das Playbook in dieser Situation fehlschlagen.
Führen Sie das Playbook aus.
ansible-playbook -i inventory.ini deploy_issue.ymlDie 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Ü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.netDie Ausgabe sollte zeigen, dass
/etc/issueeine reguläre Datei ist und/etc/issue.netein symbolischer Link ist, der darauf verweist. Daslam Anfang der Berechtigungen für/etc/issue.netzeigt 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.
Dateizustand mit stat überprüfen und Protokolle mit fetch abrufen
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.
Stellen Sie zunächst sicher, dass Sie sich im Verzeichnis
~/projectbefinden, und erstellen Sie ein neues Unterverzeichnis, um die abzurufenden Dateien zu speichern.cd ~/project mkdir fetched_logsErstellen 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.ymlFügen Sie Ihrer
check_and_fetch.yml-Playbook den folgenden Inhalt hinzu. Dieses Playbook verwendetstat, um Dateidetails abzurufen,register, um diese Details in einer Variablen zu speichern,debug, um die Variable anzuzeigen, undfetch, 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: yesLassen 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 namensmotd_status.ansible.builtin.debug: Dieses Modul wird verwendet, um Werte während der Ausführung eines Playbooks auszugeben. Hier geben wir dasstat-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 erstelltfetcheine Unterverzeichnisstruktur, die dem Host und dem Quellpfad entspricht.flat: yesvereinfacht dies, indem die Datei direkt in dasdest-Verzeichnis kopiert wird, ohne zusätzliche Unterverzeichnisse.
Führen Sie das Playbook aus. Da wir eine Systemprotokolldatei lesen, wird
become: trueverwendet, um die erforderlichen Berechtigungen zu erhalten.ansible-playbook -i inventory.ini check_and_fetch.ymlDie Ausgabe zeigt die Ergebnisse der
stat-Überprüfung in der Debug-Aufgabe, gefolgt von derfetch-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Überprüfen Sie, ob die Protokolldatei erfolgreich abgerufen wurde. Listen Sie den Inhalt des Verzeichnisses
fetched_logsauf.ls -l ~/project/fetched_logs/Sie sollten die Datei
dnf.logsehen, 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.
Verwaltung von Host-Dateien mit dem file-Modul bereinigen
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.
Stellen Sie zunächst sicher, dass Sie sich im Verzeichnis
~/projectbefinden.cd ~/projectErstellen 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.ymlFü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, dassbecome: trueauf 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: absentDer Schlüssel zu diesem Playbook ist der Parameter
state: absentin jeder Aufgabe. Dies weist dasfile-Modul an, sicherzustellen, dass das Element unter dem angegebenenpathnicht existiert. Wenn es die Datei findet, wird sie entfernt. Wenn die Datei bereits fehlt, tut es nichts und behält die Idempotenz bei.Führen Sie das Cleanup-Playbook aus.
ansible-playbook -i inventory.ini cleanup.ymlDie 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Überprüfen Sie, ob die Dateien entfernt wurden. Sie können den Befehl
lsverwenden, 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.netDie 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.
