Wie verwaltet man Dateien und Verzeichnisse effizient mit Ansible?

In der Automatisierung von Infrastrukturprozessen spielt die Verwaltung von Dateien und Verzeichnissen eine zentrale Rolle. In Ansible werden dafür verschiedene Module verwendet, die eine Vielzahl von Aufgaben ermöglichen – von der einfachen Attributzuweisung bis hin zur komplexen Kompression und Archivierung von Dateien. Im Folgenden wird ein Überblick über die wichtigsten Module zur Dateiverwaltung gegeben, die in Ansible zur Verfügung stehen.

Das file Modul ist das grundlegende Werkzeug, wenn es darum geht, Dateieigenschaften wie Besitzer, Gruppe und Berechtigungen zu setzen. Ein einfaches Beispiel zeigt, wie man den Besitzer, die Gruppe und die Berechtigungen für eine Datei ändert:

yaml
Copy code
- name: Change file ownership, group, and permissions

  ansible.builtin.file:
    path: /home/alex/application.properties
    owner: natale
    group: devs
    mode: '0644'

Mit diesem Befehl wird die Datei application.properties im Verzeichnis /home/alex auf den Benutzer natale und die Gruppe devs gesetzt, mit den entsprechenden Berechtigungen. Der Modus wird dabei im Oktalformat angegeben.

Ein weiteres häufig genutztes Feature des file Moduls ist das Erstellen von symbolischen Links. Dies geschieht über die Felder src (Ziel des Links), dest (Zielpfad des Links) und state: link:

yaml
Copy code
- name: Create a symbolic link
  ansible.builtin.file:
    src: /proc/meminfo
    dest: /home/alex/meminfo
    owner: alex
    group: alex
    state: link

Hier wird ein symbolischer Link namens meminfo erstellt, der auf die Datei /proc/meminfo verweist.

Zusätzlich kann mit dem file Modul der Zustand von Verzeichnissen kontrolliert werden, etwa um ein Verzeichnis zu erstellen, falls es nicht existiert:

yaml
Copy code
- name: Create a directory if it does not exist

  ansible.builtin.file:
    path: /etc/some_directory
    state: directory
    mode: '0755'

Ein weiteres wichtiges Argument des file Moduls ist recurse, mit dem rekursiv Änderungen auf alle Dateien und Unterverzeichnisse innerhalb eines Verzeichnisses angewendet werden können. Dies ist besonders nützlich, wenn man beispielsweise den Besitz oder die Berechtigungen für alle Dateien in einem Verzeichnis ändern möchte:

yaml
Copy code
- name: Recursively change ownership of a directory

  ansible.builtin.file:
    path: /home/alex
    state: directory
    recurse: yes
    owner: alex
    group: alex

Neben dem file Modul bietet Ansible auch das archive Modul, das zum Erstellen komprimierter Archive verwendet wird. Diese Archive können verwendet werden, um Sicherungen zu erstellen oder Daten zu komprimieren, bevor sie an einen anderen Ort verschoben werden. Hier ein Beispiel, um ein Verzeichnis in eine ZIP-Datei zu komprimieren:

yaml
Copy code
- name: Compress directory

  ansible.builtin.archive:
    path: /usr/share/nginx/html
    dest: /opt/website-backup.zip
    format: zip
    owner: root
    group: root

Das archive Modul unterstützt mehrere Formate, darunter bz2, gz, tar, xz und zip. Um sicherzustellen, dass bestimmte Dateien oder Verzeichnisse nicht archiviert werden, kann das Argument exclude_path genutzt werden:

yaml
Copy code
- name: Create a backup without logs

  ansible.builtin.archive:
    path:
      - /usr/share/nginx/html/*
    dest: /opt/website-backup.gz
    exclude_path:
      - /usr/share/nginx/html/logs*
    format: gz

Das entgegengesetzte Modul ist das unarchive Modul, das zum Entpacken von Archiven dient. Dies ist besonders nützlich, wenn man beispielsweise eine Backup-Datei auf einem Remote-Host entpacken möchte:

yaml
Copy code
- name: Extract webpage
  ansible.builtin.unarchive:
    src: website-backup.gz
    dest: /usr/share/nginx/html/

Das assemble Modul ist ein weiteres wichtiges Werkzeug, wenn es darum geht, mehrere kleinere Dateien zu einer größeren Konfigurationsdatei zusammenzuführen. Ein typisches Szenario ist das Erstellen einer Konfigurationsdatei aus mehreren Fragmenten:

yaml
Copy code
- name: Assemble from fragments from a directory

  ansible.builtin.assemble:
    src: /tmp/app/fragments
    dest: /etc/app/application.properties
    owner: root
    group: root
    mode: '644'
    regexp: 'conf$'

Das assemble Modul liest die Dateien alphabetisch und fügt sie zu einer einzigen Datei zusammen, die dann auf dem Remote-Host gespeichert wird.

Ein weiteres unverzichtbares Modul ist das copy Modul, mit dem Dateien vom lokalen System auf den Remote-Host kopiert werden können. Dies kann entweder durch direkte Kopie von Dateien oder durch das Erstellen einer neuen Datei mit Inline-Inhalt erfolgen:

yaml
Copy code
- name: Copy using inline content
  ansible.builtin.copy:
    content: 'connection_pool=true'
    dest: /etc/app/application.properties.fragment1
    backup: true

Das copy Modul bietet auch die Möglichkeit, eine Sicherung der Datei zu erstellen, falls diese bereits existiert.

Wenn es darum geht, Dateien vom Remote-Host zurück auf den Control-Node zu kopieren, wird das fetch Modul verwendet. Ein Beispiel dafür, wie man eine Datei von einem Remote-Host auf das lokale System kopiert:

yaml
Copy code
- name: Store file into /tmp/fetched/host.example.com/etc/hosts

  ansible.builtin.fetch:
    src: /etc/hosts
    dest: /tmp

Mit dem fetch Modul wird die Datei auf das lokale System kopiert, wobei der Hostname des Remote-Systems in der Verzeichnisstruktur berücksichtigt wird.

Ein weiteres hilfreiches Modul ist das stat Modul, mit dem verschiedene Informationen über Dateien oder Verzeichnisse abgerufen werden können, wie etwa Berechtigungen, Besitzer oder Änderungszeitpunkte. Dies ist besonders nützlich, wenn man bestimmte Bedingungen prüfen muss, bevor man mit der Bearbeitung einer Datei fortfährt.

Wie man eine Ausführungsumgebung mit Ansible Builder erstellt und nutzt

Im Prozess der Erstellung einer Ausführungsumgebung mit Ansible Builder gibt es mehrere Phasen, die es zu verstehen gilt. Zunächst ist es wichtig zu verstehen, dass Ansible Builder das Werkzeug ist, mit dem Ansible-Ausführungsumgebungen in Form von Container-Images erstellt werden können. Diese Umgebungen beinhalten alle Abhängigkeiten und Tools, die für die Ausführung von Ansible-Playbooks notwendig sind.

Zu Beginn einer solchen Build-Pipeline könnte man die Notwendigkeit haben, den PIP-Paketmanager zu aktualisieren, bevor das Basis-Image erstellt wird. Dies lässt sich durch ein zusätzliches Build-Skript erreichen. In einem typischen Build-Prozess könnte man zum Beispiel Befehle in mehreren Phasen einfügen, um den PIP-Paketmanager zu aktualisieren und die Ansible-Konfigurationsdatei in das Standardverzeichnis zu kopieren, bevor das Ansible Galaxy Collection heruntergeladen wird. Ein Beispiel für ein solches Setup sieht folgendermaßen aus:

yaml
Copy code
additional_build_steps:

  append_base:
    - RUN $PYCMD -m pip install -U pip
  prepend_galaxy:
    - COPY _build/configs/ansible.cfg /etc/ansible/ansible.cfg

yaml
Copy code
version: 3
build_arg_defaults:
  ANSIBLE_GALAXY_CLI_COLLECTION_OPTS: '--pre'
dependencies:
  galaxy:
    collections:
      - community.general
  python:
    - jmespath

Sobald diese Datei erstellt ist, kann der Build-Prozess mit dem Ansible Builder-Werkzeug gestartet werden. Dies geschieht in zwei Schritten: Zuerst wird die Ausführungsumgebungsdatei verarbeitet, wodurch eine Containerfile generiert wird, die alle notwendigen Schritte für den endgültigen Build enthält. Danach wird das Containerfile unter Verwendung des festgelegten Container-Runtimes wie Docker oder Podman gebaut. Ein Beispielbefehl zur Erstellung des Containerfiles lautet:

bash
Copy code
ansible-builder create

Dieses Kommando erzeugt einen Build-Kontext, der nicht nur das Containerfile enthält, sondern auch alle anderen Dateien, die für den Build-Prozess benötigt werden. Diese Dateien werden in einem Verzeichnis namens context abgelegt. Der Standardpfad kann jedoch durch die Angabe der Option -c geändert werden. Neben dem Containerfile sind dort auch alle benötigten Abhängigkeiten und Skripte vorhanden, die den Build-Prozess unterstützen:

bash
Copy code
context
├── _build
│   ├── requirements.txt
│   ├── requirements.yml
│   └── scripts
│       ├── assemble
│       ├── check_ansible
│       ├── check_galaxy
│       ├── entrypoint
│       ├── install-from-bindep
│       └── introspect.py
└── Containerfile

Um das Container-Image zu erstellen, verwendet man den folgenden Befehl:

bash
Copy code
ansible-builder build -t localhost/ee-build:latest

Ein wichtiger Aspekt bei der Erstellung von Ausführungsumgebungen sind die Authentifizierungsmechanismen. Wenn die Basis-Images aus geschützten Registries stammen, wie es bei Images aus dem Red Hat Container Catalog der Fall ist, muss eine Authentifizierung am Container-Runtime erfolgen. Mit Podman kann dies durch den folgenden Befehl geschehen:

bash
Copy code
podman login

Nach Abschluss des Builds kann das fertige Image im Container-Runtime gefunden und weiterverwendet werden. Es ist sogar möglich, dieses Image in einer Container-Registry wie quay.io oder im Ansible Private Automation Hub zu veröffentlichen, sodass andere Nutzer darauf zugreifen können. Weitere Informationen zu den Möglichkeiten, Images im Private Automation Hub zu verwalten, finden sich in der offiziellen Produktdokumentation.

Anschließend steht das Image zur Verfügung, um es in Automatisierungsaktivitäten zu verwenden. Eine der wichtigsten Entwicklungen in dieser Hinsicht ist der Ansible Navigator, ein Tool, das eine einfache und effiziente Möglichkeit bietet, Automatisierungsinhalte zu entwickeln und auszuführen. Der Automation Content Navigator ist ein Kommandozeilen-Tool sowie eine textbasierte Benutzeroberfläche (TUI), die eine nahtlose Methode zur Verwaltung von Ansible-Inhalten bietet. Mit diesem Tool kann man Playbooks ausführen, Automatisierungsumgebungen erkunden und Bestandslisten anzeigen.

Ansible Navigator kann auf verschiedene Arten installiert werden, sei es über den Paketmanager des Betriebssystems, mit PIP oder durch den Download von Quellcode oder Tarballs. Nach der Installation kann man den Erfolg der Installation mit dem folgenden Befehl überprüfen:

bash
Copy code
ansible-navigator --version

Mit der Version des Tools im System kann man dann zwischen verschiedenen Modi wechseln: dem klassischen CLI-Modus und dem erweiterten TUI-Modus. Der TUI-Modus ermöglicht eine interaktive Benutzererfahrung, die sich gut in Entwicklungsumgebungen wie Visual Studio Code integrieren lässt. Hierbei stehen verschiedene Funktionen wie farbcodierte Ausgaben, eine einfache Navigation und eine lineare Anzeige der Ergebnisse zur Verfügung, die die Nutzung von Ansible effizienter machen.

Endtext.

Wie funktioniert der Automation Content Navigator für Ansible?

Der Automation Content Navigator bietet eine benutzerfreundliche Oberfläche zur Verwaltung und Ausführung von Ansible-Playbooks und zur Integration in verschiedene Teile des Ansible-Ökosystems. Besonders hervorzuheben ist seine Verwendung im TUI-Modus (Text User Interface), der eine interaktive und leicht verständliche Benutzererfahrung ermöglicht. In diesem Modus können Nutzer durch die verschiedenen Funktionen des Navigators navigieren und ihre Automatisierungsaufgaben effizient ausführen.

Der Automation Content Navigator ist in erster Linie darauf ausgelegt, Ansible Playbooks innerhalb einer sogenannten Execution Environment auszuführen. Diese Umgebung stellt sicher, dass alle benötigten Ressourcen und Abhängigkeiten für die Automatisierung konsistent und isoliert bereitgestellt werden. Über den Befehl ansible-navigator wird der Navigator gestartet, der dann die Standard-Execution Environment aus dem Red Hat Container-Registry lädt, um als Betriebssystem für alle folgenden Aktivitäten zu dienen. Diese Umgebungen garantieren, dass die Playbooks in einer stabilen und kontrollierten Umgebung laufen, unabhängig vom Host-System, auf dem der Navigator ausgeführt wird.

Die Benutzeroberfläche des Automation Content Navigators zeigt nach dem Start eine Begrüßungsseite an, die eine Übersicht der verfügbaren Optionen enthält. Diese Optionen werden in Form von Kommandos im sogenannten "Colon-Command"-Format angezeigt, wobei der Benutzer durch einfache Eingabe der entsprechenden Zahl die gewünschte Aktion auswählen kann. Zu den grundlegenden Funktionen gehören das Durchsuchen von Collections, das Überprüfen der Ansible-Konfiguration, das Aufrufen von Dokumentationen für Module oder Plugins sowie das Ausführen und Testen von Playbooks.

Die Option :collections ermöglicht es, alle verfügbaren Collections zu durchsuchen, die in der aktuellen Execution Environment enthalten sind. Jede Collection ist mit einer Zahl versehen, die es dem Benutzer ermöglicht, detaillierte Informationen darüber zu erhalten. Um zu einer vorherigen Ansicht zurückzukehren, genügt das Drücken der Escape-Taste (Esc), was besonders nützlich ist, wenn man durch mehrere Menüs navigiert.

Die Anpassung des Automation Content Navigators an individuelle Bedürfnisse ist ebenfalls möglich. Der Navigator kann über Kommandozeilenargumente, Umgebungsvariablen oder eine Konfigurationsdatei gesteuert werden. Diese Konfigurationsdatei kann im JSON- oder YAML-Format vorliegen und an mehreren Speicherorten abgelegt sein, beispielsweise im aktuellen Arbeitsverzeichnis oder im Home-Verzeichnis des Nutzers. Ein Beispiel für eine solche Konfigurationsdatei könnte folgendermaßen aussehen:

yaml
Copy code
ansible-navigator:

  execution-environment:
    enabled: true
    container-engine: podman
    pull:
      policy: missing
  logging:
    level: warning
    append: true
    file: .ansible-navigator.log
  mode: stdout
  playbook-artifact:
    enable: false
  time-zone: local

Ein solcher Ansatz ermöglicht es, sowohl die Ausführungsumgebung als auch das Logging-Verhalten und andere Parameter flexibel zu steuern.

Der wichtigste Anwendungsbereich des Automation Content Navigators bleibt jedoch das Ausführen von Ansible Playbooks. Dabei wird der ansible-navigator run-Befehl genutzt, um Playbooks innerhalb der Execution Environment auszuführen. Die grundlegenden Funktionen, die auch beim direkten Einsatz des Ansible CLI über den Befehl ansible-playbook zur Anwendung kommen, sind weiterhin verfügbar. Es gibt jedoch entscheidende Unterschiede in der Art und Weise, wie Playbooks im Kontext des Automation Content Navigators ausgeführt werden. Ein wichtiger Unterschied besteht darin, dass die Playbooks innerhalb eines Containers laufen. Dies bedeutet, dass Ressourcen vom Host-System in den Container eingebunden werden, wobei nur bestimmte Verzeichnisse zugänglich sind. Dies hat Auswirkungen auf die Nutzung von Dateien, die außerhalb des Arbeitsverzeichnisses auf dem Host-System gespeichert sind, da diese standardmäßig nicht im Container zur Verfügung stehen. Möchte man zusätzliche Verzeichnisse oder Umgebungsvariablen einbinden, so können die Flags --eev und --penv verwendet werden.

Ein weiteres zentrales Thema ist die Verwendung von SSH-Schlüsseln für die Verbindung zu entfernten Hosts. Ansible nutzt SSH als primäre Methode zur Kommunikation mit Zielmaschinen, jedoch kann es aufgrund bestimmter SSH-Konfigurationen zu Problemen kommen. So können SSH-Schlüssel, die sich an nicht standardisierten Orten befinden, mit dem Flag --eev in den Container eingebunden werden. Die Verwendung von ssh-agent, einem SSH-Schlüsselmanager, wird empfohlen, da der Automation Content Navigator eine Integration mit diesem Tool bietet und die Verwaltung von SSH-Schlüsseln somit erheblich vereinfacht wird.