Wie verwaltet man Änderungen und Fehler in Ansible-Playbooks?

In Ansible spielt das Verständnis des Status von Aufgaben eine entscheidende Rolle für die Effizienz und den Erfolg von Automatisierungsprozessen. Ein häufig auftretendes Szenario ist, dass eine Aufgabe ohne tatsächliche Änderungen an einem Remote-Host als "ok" markiert wird, obwohl der Statuscode 200 zurückgegeben wurde. Dabei wird oft nicht beachtet, dass auch bei erfolgreichem HTTP-Request der Host möglicherweise verändert wurde. In solchen Fällen bietet Ansible die Möglichkeit, mit der Bedingung changed_when festzulegen, wann eine Aufgabe als verändert (changed) und nicht nur als erfolgreich (ok) gewertet wird. Zum Beispiel kann man in einem Playbook eine HTTP-Anfrage definieren, die bei einem Statuscode von 200 als "changed" markiert wird:

yaml
Copy code
- name: Site prüfen

  hosts: all
  tasks:
    - name: Webseite abrufen
      ansible.builtin.uri:
        url: http://meinewebseite.com
        return_content: true
      register: output
      changed_when: "output.status == 200"

Diese Konfiguration sorgt dafür, dass die Aufgabe als geändert (changed) und nicht nur als ok gemeldet wird, was in komplexeren Szenarien, etwa bei automatisierten Rollouts, wichtig ist.

Ein weiteres wichtiges Konzept in Ansible ist das Abbrechen von Playbooks bei Fehlern. Normalerweise läuft ein Playbook auch dann weiter, wenn auf einem Host ein Fehler auftritt, was manchmal zu unerwünschtem Verhalten führen kann. Um dies zu verhindern, kann man mit der Direktive any_errors_fatal: true sicherstellen, dass bei einem Fehler auf einem beliebigen Host der gesamte Playbook-Prozess abgebrochen wird. Ein typisches Beispiel wäre, wenn eine Wartungsseite auf allen Frontend-Servern kopiert werden soll, bevor Backend-Updates durchgeführt werden. Falls der Schritt bei einem Frontend-Host fehlschlägt, wird das Playbook gestoppt, ohne fortzufahren:

yaml
Copy code
- hosts: frontends

  any_errors_fatal: true
  tasks:
    - name: Wartungsseite veröffentlichen
      ansible.builtin.copy: ....
- hosts: backends
  tasks:
    - name: Service stoppen
      ansible.builtin.service: ....
    - name: Backend aktualisieren
      ansible.builtin.copy: ....
    - name: Service starten
      ansible.builtin.service: ....

Das bedeutet, dass die Backend-Updates erst dann ausgeführt werden, wenn alle Frontend-Server erfolgreich mit der Wartungsseite versorgt wurden. Wird any_errors_fatal: true jedoch nicht gesetzt, könnte das Playbook auch bei Fehlern im Frontend-Teil fortgesetzt werden, was unter Umständen zu Problemen führt.

Ein weiteres Konzept, das für die Strukturierung großer Playbooks hilfreich ist, sind Blöcke. Durch die Verwendung von Blöcken können Aufgaben logisch gruppiert werden, wobei alle Aufgaben innerhalb eines Blocks von den Anweisungen auf Blockebene erben. Ein Block kann auch Fehlerbehandlung auf Blockebene ermöglichen, was das Fehlermanagement vereinfacht. In Ansible verwendet man dafür die Direktiven rescue und always, die dem Prinzip von try/catch/finally in vielen Programmiersprachen entsprechen.

Beispielsweise könnte ein Block in einem Playbook so aussehen:

yaml
Copy code
- name: Webseiten-Update

  hosts: webservers
  tasks:
    - name: Seiten aktualisieren
      block:
        - name: index.html kopieren
          ansible.builtin.copy:
            src: index.html
            dest: /usr/share/nginx/html/index.html
            mode: 0644
        - name: Nginx neustarten
          ansible.builtin.service:
            name: nginx
            state: restarted
      when: update_page == true

In diesem Beispiel werden beide Aufgaben nur ausgeführt, wenn die Bedingung update_page == true erfüllt ist. Blockstrukturen bieten nicht nur eine bessere Lesbarkeit und Wartbarkeit von Playbooks, sondern auch eine gezielte Fehlerbehandlung. Bei einem Fehler innerhalb des Blocks können spezifische Fehlerbehandlungsmaßnahmen ergriffen werden, wie in diesem Beispiel:

yaml
Copy code
tasks:

  - name: Fehlerbehandlung im Block
    block:

      - name: Falsches Paket installieren

        ansible.builtin.dnf:
          name: ungültiges_paket
    rescue:
      - ansible.builtin.debug:
          msg: "Ein Fehler ist aufgetreten."
    always:
      - ansible.builtin.debug:
          msg: "Diese Nachricht wird immer ausgegeben."

In diesem Fall wird die Aufgabe, das ungültige Paket zu installieren, fehlschlagen und die Fehlerbehandlungslogik im rescue-Block ausgeführt. Danach wird der always-Block ausgeführt, der immer nach den anderen Aufgaben ausgeführt wird, unabhängig vom Erfolg oder Fehler der Aufgaben.

Neben der Fehlerbehandlung auf Blockebene ermöglicht Ansible auch die Konfiguration eines maximalen Fehlerschwellenwerts mit der Direktive max_fail_percentage. Dies ist besonders nützlich, wenn eine bestimmte Anzahl von Fehlern in einem Playbook die gesamte Ausführung stoppen soll. Beispielsweise könnte die Einstellung max_fail_percentage: 50 bewirken, dass Ansible den Vorgang stoppt, wenn mehr als 50 % der Aufgaben fehlschlagen.

Ein Playbook mit dieser Direktive könnte folgendermaßen aussehen:

yaml
Copy code
- hosts: all

  max_fail_percentage: 50
  tasks:
    - name: Testaufgabe
      ansible.builtin.shell: /bin/false

In diesem Beispiel wird die Ausführung des Playbooks abgebrochen, sobald 50 % der Aufgaben fehlschlagen.

Es ist wichtig, dass der Leser versteht, wie diese Werkzeuge in komplexen Automatisierungsprozessen eingesetzt werden können. Ansible bietet zahlreiche Möglichkeiten, das Verhalten von Aufgaben und Playbooks genau zu steuern, sei es durch das Setzen von Bedingungen, Fehlerbehandlung oder das Stoppen der Ausführung bei bestimmten Schwellenwerten. Durch die Anwendung dieser Techniken können Playbooks effizienter und robuster gemacht werden, was zu einer besseren Wartbarkeit und Kontrolle über die Infrastruktur führt.

Wie SSH-Schlüssel mit Ansible verwaltet werden können

SSH-basierte Authentifizierung spielt eine zentrale Rolle, wenn es darum geht, sichere Verbindungen zwischen einem Steuerungsrechner und entfernten Hosts herzustellen. Besonders in der Automatisierung, etwa mit Ansible, ist die Verwaltung dieser Schlüssel entscheidend, um eine konsistente und effiziente Verwaltung von Systemen zu gewährleisten. In dieser Kapitel wird erläutert, wie SSH-Schlüssel generiert und verwaltet werden können und wie Ansible dazu genutzt wird, diesen Prozess zu automatisieren.

SSH-Authentifizierung erfordert typischerweise zwei asymmetrische Schlüssel: einen privaten und einen öffentlichen. Der private Schlüssel bleibt dabei auf dem Steuerungsrechner (Client) gespeichert, während der öffentliche Schlüssel an jedem Remote-Host hinterlegt wird, mit dem eine Verbindung hergestellt werden soll. Die Authentifizierung erfolgt durch den Austausch von verschlüsselten Nachrichten zwischen Client und Server. Der Server stellt sicher, dass nur autorisierte Clients Zugang erhalten, indem er den verschlüsselten Nachrichtentext mithilfe des öffentlichen Schlüssels entschlüsselt.

Ansible bietet eine einfache Möglichkeit, diesen Vorgang zu automatisieren. Dies geschieht über das ansible.posix.authorized_key Modul, das es ermöglicht, SSH-Schlüssel auf entfernten Hosts hinzuzufügen oder zu entfernen. Um dieses Modul effektiv zu nutzen, muss die SSH-Schlüsselverwaltung auf den entsprechenden Hosts implementiert werden. Dabei wird der öffentliche Schlüssel in der Datei authorized_keys des Benutzerkontos auf dem Remote-Host abgelegt. Dieser Vorgang kann ohne manuelles Eingreifen in das Dateisystem des Hosts durchgeführt werden.

Ein typisches Beispiel zur Verwaltung der SSH-Schlüssel in Ansible könnte folgendermaßen aussehen:

yaml
Copy code
- name: SSH-Schlüssel zum Remote-Host hinzufügen
  hosts: remote_host
  tasks:
    - name: Füge den öffentlichen SSH-Schlüssel hinzu
      ansible.posix.authorized_key:
        user: "{{ ansible_user }}"
        state: present
        key: "{{ lookup('file', '/pfad/zum/öffentlichen/Schlüssel') }}"

Ein weiterer Aspekt der SSH-basierte Authentifizierung ist der Umgang mit Schlüsselpaaren, die sowohl für den Initialzugang als auch für spätere Automatisierungsaufgaben verwendet werden. Die Erstellung eines SSH-Schlüsselpaares erfolgt üblicherweise durch Tools wie ssh-keygen auf dem Steuerungsrechner. Der private Schlüssel bleibt dabei geheim und wird nur auf dem Steuerungsrechner genutzt, während der öffentliche Schlüssel an alle Zielhosts verteilt wird.

Zusätzlich zu den grundlegenden Funktionen von Ansible zur Verwaltung von SSH-Schlüsseln kann auch die Möglichkeit genutzt werden, Ansible in Verbindung mit einem "Execution Environment" zu betreiben. Hierbei wird eine Containerumgebung erzeugt, in der alle notwendigen Ansible-Ressourcen und -Module zur Verfügung stehen. Ein solcher Container sorgt dafür, dass die Automatisierung auf verschiedenen Systemen identisch ausgeführt wird, was die Wiederholbarkeit und Konsistenz der Automatisierungsprozesse erheblich verbessert.

Der Vorteil eines solchen Vorgehens liegt nicht nur in der Flexibilität der Ansible-Playbooks, sondern auch in der Sicherheit. Der gesamte Schlüsselmanagementprozess wird automatisiert, was das Risiko von menschlichen Fehlern oder versehentlichen Fehlkonfigurationen verringert. Dies ist besonders wichtig, wenn viele Hosts verwaltet werden müssen, da manuelle Eingriffe in das Schlüsselmanagement fehleranfällig und zeitraubend sein können.

Ein wesentlicher Punkt, der beachtet werden muss, ist die korrekte Konfiguration der SSH-Schlüssel und das regelmäßige Management dieser Schlüssel. Der Zugang zu sensiblen Systemen muss stets gut geschützt werden, weshalb es ratsam ist, die Schlüssel regelmäßig zu rotieren und den Zugriff auf die richtigen Personen zu beschränken. Dazu kann Ansible durch die Implementierung von Playbooks und Ansible-Rollen beitragen, die sicherstellen, dass die richtigen Schlüssel auf den richtigen Hosts liegen und der Zugriff ordnungsgemäß überwacht wird.

Eine weitere wichtige Überlegung betrifft die Verwaltung der Zugriffsrechte. Während die Erstellung eines SSH-Schlüsselpaares und dessen Verteilung einfach durchzuführen sind, kann die Verwaltung der Berechtigungen für diese Schlüssel komplexer werden. Insbesondere bei der Nutzung von SSH-Schlüsseln auf mehreren Hosts ist es entscheidend, dass nur autorisierte Benutzer auf bestimmte Maschinen zugreifen können. Dies kann durch die präzise Konfiguration der Benutzerrechte und durch die Verwendung von zusätzlichen Ansible-Tasks wie ansible.builtin.user und ansible.builtin.group erreicht werden, die helfen, Benutzer und Gruppen sicher zu verwalten.

Automatisierungswerkzeuge wie Ansible bieten hier eine wertvolle Unterstützung, indem sie die Verwaltung von SSH-Schlüsseln und Benutzerrechten systematisch und fehlerfrei durchführen. Um eine wirklich sichere und effiziente Automatisierung zu erreichen, ist es unerlässlich, Ansible so zu konfigurieren, dass die Verwaltung von Schlüsseln, Benutzerrechten und anderen sicherheitsrelevanten Aspekten in einem konsistenten und wiederholbaren Prozess erfolgt.

Wie man mit Ansible Benutzer und Dateisysteme verwaltet: Ein praktischer Leitfaden

Ein typisches Szenario besteht darin, Benutzer auf mehreren Hosts zu erstellen und deren SSH-Schlüssel zur Authentifizierung zu konfigurieren. Statt die Benutzerdaten direkt in einem Playbook zu hinterlegen, empfiehlt es sich, diese aus einer externen JSON-Datei zu laden, um den Code flexibel und wartbar zu halten. Ein Beispiel für eine solche JSON-Datei könnte folgendermaßen aussehen:

json
Copy code
{

  "users": [
    {
      "username": "Ada",
      "password": "$y$j9T$68mjAbPmPM.0veTrWjXNx.$FdvdDAE92QRWE/L2p.mcMjB3gOqEu0Ki3rPtZvxLCLC",
      "keyfile": "./id_rsa_ada.pub"
    },
    {
      "username": "Alexandra",

      "password": "$y$j9T$68mjAbPmPM.0veTrWjXNx.$FdvdDAE92QRWE/L2p.mcMjB3gOqEu0Ki3rPtZvxLCLC",

      "keyfile": "./id_rsa_aixa.pub"
    }
  ]
}

In diesem Beispiel enthält die Datei eine Liste von Benutzern, wobei jeder Benutzer durch einen username, ein password und den Pfad zu einem öffentlichen SSH-Schlüssel (keyfile) definiert ist. Diese Daten können dann mit einem Ansible-Playbook weiterverarbeitet werden, um die Benutzer zu erstellen und die SSH-Schlüssel auf den entsprechenden Hosts zu kopieren.

Ein einfaches Playbook, das diese Aufgaben erledigt, könnte wie folgt aussehen:

yaml
Copy code
---

- hosts: all
  become: yes
  vars_files:
    - users.json
  tasks:
    - name: Erstelle Benutzer
      ansible.builtin.user:
        name: "{{ item.username }}"
        password: "{{ item.password }}"
        shell: /bin/bash
        state: present
      loop: "{{ users }}"
    - name: Lade SSH-Schlüssel des Benutzers in die autorisierten Schlüssel
      ansible.builtin.authorized_key:
        user: "{{ item.username }}"
        state: present
        manage_dir: yes
        key: "{{ lookup('file', './{{ item.keyfile }}') }}"
      loop: "{{ users }}"

In diesem Playbook wird für jeden Benutzer aus der JSON-Datei ein Benutzerkonto erstellt, der öffentliche SSH-Schlüssel in die Datei authorized_keys des jeweiligen Benutzers kopiert und so die SSH-Authentifizierung für alle definierten Hosts aktiviert.

Neben der Benutzerverwaltung spielt auch das Management von Festplatten und Dateisystemen eine zentrale Rolle bei der Verwaltung von Serversystemen. In diesem Zusammenhang wird Ansible häufig verwendet, um Partitionen zu erstellen, Dateisysteme zu formatieren, zu mounten oder logische Volumes zu verwalten. Ein Ansible-Modul, das häufig zum Erstellen und Verwalten von Dateisystemen verwendet wird, ist das community.general.filesystem Modul.

Um beispielsweise ein ext4-Dateisystem auf einem Gerät zu erstellen, kann folgendes Playbook verwendet werden:

yaml
Copy code
- name: Erstelle ein ext4-Dateisystem

  community.general.filesystem:
    fstype: ext4
    dev: /dev/sdb1

Dieser Task formatiert das Gerät /dev/sdb1 mit dem ext4-Dateisystem. Ebenso können erweiterte Optionen, wie etwa die Durchführung eines Block-Überprüfungschecks beim Formatieren, hinzugefügt werden:

yaml
Copy code
- name: Erstelle ein ext4-Dateisystem und prüfe Blockstrukturen
  community.general.filesystem:
    fstype: ext4
    dev: /dev/sdb1
    opts: -cc

Falls ein vorhandenes Dateisystem gelöscht werden soll, wird der Parameter state: absent verwendet, um das Dateisystem zu entfernen:

yaml
Copy code
- name: Lösche das Dateisystem

  community.general.filesystem:
    dev: /dev/sdb1
    state: absent

Darüber hinaus ist das Mounten von Geräten eine häufige Aufgabe. Das ansible.posix.mount Modul ermöglicht das Mounten und Unmounten von Volumes und das Verwalten von Einträgen in der Datei /etc/fstab, die für das automatische Mounten von Dateisystemen beim Systemstart verantwortlich ist. Hier ein Beispiel, wie ein Gerät in das Verzeichnis /data1 gemountet wird:

yaml
Copy code
- name: Mounten des Geräts auf /data1

  ansible.posix.mount:
    path: /data1
    src: /dev/sdb1
    fstype: ext4
    state: mounted

Zum Unmounten eines Geräts setzt man den state auf unmounted:

yaml
Copy code
- name: Unmounten des Volumes
  ansible.posix.mount:
    path: /data1
    state: unmounted

Es gibt eine Reihe von Parametern, die die Funktionsweise des mount-Moduls steuern, etwa die Option absent, die dafür sorgt, dass das Dateisystem sowohl aus der Datei /etc/fstab entfernt als auch unmountet wird.

Mit diesen grundlegenden Beispielen lässt sich ein effektives Systemmanagement über Ansible realisieren, das sowohl Benutzerverwaltung als auch die Verwaltung von Festplatten und Dateisystemen umfasst.

Wie verwaltet man Variablen und Inventar in Ansible?

Die Verwaltung von Variablen und Inventaren ist ein wesentlicher Bestandteil der Arbeit mit Ansible, da sie es ermöglichen, Infrastruktur dynamisch zu konfigurieren und zu verwalten. Besonders die Fähigkeit, Variablen in Abhängigkeit von verschiedenen Umgebungen und Hosts zu verwenden, macht Ansible zu einem äußerst flexiblen Werkzeug. Es gibt viele Möglichkeiten, wie man Variablen definiert und anwendet, um die Automatisierung noch effizienter zu gestalten.

Ein zentraler Aspekt von Ansible ist der Umgang mit Variablen. Diese können entweder fest definiert oder dynamisch durch die Umgebung bestimmt werden. Ein häufiges Beispiel ist das Passwort für einen Datenbankserver, das je nach Umgebung unterschiedlich sein kann. Für eine Entwicklungsumgebung kann ein anderes Passwort verwendet werden als für eine Produktionsumgebung. Solche Variablen können an verschiedenen Stellen eingesetzt werden, etwa in Modul-Argumenten, innerhalb von Bedingungsausdrücken, in Templates oder in Schleifen.

In Ansible gibt es zwei Hauptarten von Variablen. Zum einen sind da die Benutzerdefinierten Variablen, die vom Anwender erstellt, gesetzt und in Logik verwendet werden. Zum anderen gibt es Sondervariablen, die von Ansible bereitgestellt werden. Diese Variablen sind entweder „magische“ Variablen, die Ansible helfen, bestimmte Informationen zu extrahieren (wie inventory_file oder groups), oder sie geben Verbindungsdetails zu Hosts an, zum Beispiel ansible_user, ansible_become_user oder ansible_ssh_private_key_file.

Ein typisches Beispiel für die Verwendung einer Variablen wäre das Setzen eines spezifischen Benutzernamens für eine SSH-Verbindung. Im folgenden Beispiel wird der Benutzer vagrant für die Verbindung mit einem Host über SSH festgelegt:

ini
Copy code
[webservers]
web1.example.com ansible_user=vagrant

In YAML-Format wäre die entsprechende Definition wie folgt:

yaml
Copy code
webservers:

  hosts:
    web1.example.com:
      ansible_user: vagrant

Es ist ebenfalls möglich, Variablen für eine gesamte Gruppe von Hosts zu definieren. Wenn alle Hosts in einer Gruppe denselben Wert für eine Variable benötigen, kann diese in einem speziellen Abschnitt namens :vars angegeben werden. Ein Beispiel für das Festlegen eines anderen Ansible-Ports für alle Hosts in der Gruppe webservers:

ini
Copy code
[webservers]

web1.example.com
web2.example.com
[webservers:vars]
ansible_port=5555

Im YAML-Format:

yaml
Copy code
webservers:
  hosts:
    web1.example.com:
  vars:
    ansible_port: 5555

Ein weiterer wichtiger Punkt ist die Möglichkeit, dynamische Inventare zu nutzen. Wenn etwa Hosts in der Cloud erstellt werden, können diese dynamisch ermittelt und in das Inventar aufgenommen werden, ohne dass die Inventardatei manuell gepflegt werden muss. Auch die Kombination von statischen und dynamischen Inventaren ist eine gängige Praxis.

Neben der Verwaltung von Variablen und Inventaren ist das Arbeiten mit der Ansible-CLI von großer Bedeutung. Zwei der wichtigsten Befehlszeilenwerkzeuge in Ansible sind ansible und ansible-playbook.

Der ansible-Befehl wird verwendet, um eine einzelne Aufgabe auf einer Gruppe von Hosts auszuführen. Ein häufiger Anwendungsfall ist das Testen der Verbindung zu Hosts. Zum Beispiel könnte man mit dem folgenden Befehl prüfen, ob ein Host erreichbar ist:

bash
Copy code
ansible all -i inventory -m ping

Hierbei wird das Modul ping verwendet, um eine Verbindung zu allen Hosts im Inventar zu testen. In einigen Fällen ist es notwendig, den Benutzernamen für die SSH-Verbindung anzugeben, falls der Standardbenutzer nicht ausreicht. Dies kann durch den --user-Parameter erfolgen.

Neben dem ansible-Befehl gibt es den ansible-playbook-Befehl, der zum Ausführen von Playbooks verwendet wird. Ein Playbook ist eine Reihe von Aufgaben, die auf den angegebenen Hosts automatisch ausgeführt werden. Playbooks ermöglichen eine detailliertere Steuerung und Automatisierung der Konfiguration von Hosts und bieten eine klare Trennung von Aufgaben, was die Wartung und das Troubleshooting erleichtert.

Zusätzlich zu den beschriebenen Funktionen gibt es in Ansible noch zahlreiche weitere Werkzeuge und Parameter, die die Verwaltung von Konfigurationen noch präziser und leistungsfähiger gestalten. So kann beispielsweise durch die Option --ask-pass im Fall von Verbindungsproblemen mit einem Host nach einem Passwort gefragt werden. Weitere nützliche Parameter wie -v, -vv, -vvv bieten die Möglichkeit, detailliertere Debugging-Informationen zu erhalten, die beim Beheben von Fehlern hilfreich sind.