Wie kann Ansible Playbooks effizient einsetzen und konfigurieren?

Im Kontext von Ansible ist es wichtig, dass Playbooks nicht nur zur Automatisierung von Aufgaben genutzt werden, sondern dass sie auch strukturiert und modular aufgebaut sind. Das Ziel dieser Herangehensweise ist es, die Wiederverwendbarkeit von Code zu maximieren und Redundanzen zu vermeiden. Ein zentrales Konzept hierbei sind die sogenannten Collections. Diese bieten eine Art Container, in dem Ansible-Inhalte wie Playbooks, Rollen und Module gespeichert werden, die dann in anderen Playbooks wiederverwendet werden können. Dies erspart die wiederholte Definition derselben Aufgaben in verschiedenen Playbooks und steigert die Effizienz.

Ansible bietet eine Vielzahl von Modulen, die in Playbooks verwendet werden können, und die Modularität durch Collections ermöglicht eine saubere Strukturierung. Im folgenden Beispiel wird gezeigt, wie ein einfaches Playbook für die Installation und Konfiguration eines Webservers erstellt wird.

Ausführung eines einfachen Playbooks

Falls bereits ein Fedora-Server vorhanden ist, kann dieser Schritt übersprungen werden. In diesem Beispiel verwenden wir eine vorgefertigte Fedora-VM, die über die nötigen Benutzerrechte verfügt. Nach dem Starten der virtuellen Maschine erfolgt die Anmeldung mit den Zugangsdaten und die IP-Adresse wird mit dem Befehl ifconfig ermittelt. Diese IP-Adresse muss im Inventar-File angegeben werden, um die Zielmaschine für Ansible zu definieren.

Zunächst muss die HTML-Datei erstellt werden, die als Indexseite dient. Der Inhalt dieser Datei lautet wie folgt:

html
Copy code
nginx, konfiguriert durch Ansible
Wenn Sie dies sehen, hat Ansible erfolgreich nginx installiert.

Zusätzlich wird eine Konfigurationsdatei für Nginx erstellt, um den Server korrekt zu konfigurieren. Die Konfiguration umfasst grundlegende Angaben wie die Zuhörparameter auf Port 80 und den Speicherort der HTML-Datei.

Erstellen der Inventar- und Playbook-Dateien

Das Inventar-File, in dem die Maschinen definiert werden, auf denen Ansible die Aufgaben ausführt, wird erstellt und sieht folgendermaßen aus:

ini
Copy code
[node1]

192.168.1.115 ansible_user=alex ansible_ssh_pass=alex

In diesem Fall ist node1 der Name der Gruppe, die die IP-Adresse und Anmeldedaten für den SSH-Zugang enthält. Es wird darauf hingewiesen, dass es eine schlechte Praxis ist, Passwörter im Klartext zu speichern, und dass in späteren Kapiteln des Buches gezeigt wird, wie dieses Sicherheitsproblem behoben werden kann.

Das Playbook selbst wird erstellt und enthält die folgenden Aufgaben:

1. Installation von Nginx

2. Installation und Konfiguration der Firewall

3. Kopieren der HTML-Datei und der Nginx-Konfigurationsdatei

4. Neustarten von Nginx, um die Änderungen zu übernehmen

5. Überprüfung, ob die Seite erfolgreich bereitgestellt wurde

6. Konfiguration der Firewall, um den HTTP-Verkehr zuzulassen

Das Playbook könnte folgendermaßen aussehen:

yaml
Copy code
- name: Konfigurieren von nginx

  hosts: all
  become: true
  tasks:
    - name: nginx installieren
      ansible.builtin.dnf:
        name: nginx
    - name: firewalld installieren
      dnf:
        name: firewalld
    - name: nginx Konfigurationsdatei kopieren
      ansible.builtin.copy:
        src: nginx.conf
        dest: /etc/nginx/conf.d/localhost.conf
    - name: index.html kopieren
      ansible.builtin.copy:
        src: index.html
        dest: /usr/share/nginx/html/index.html
        mode: 0644
      tags: ['deploy']

    - name: nginx neu starten

      ansible.builtin.service:
        name: nginx
        state: restarted
      tags: ['deploy']
    - name: HTTP-Status 200 überprüfen
      ansible.builtin.uri:
        url: http://localhost/index.html
        return_content: yes
      register: response
      tags: ['deploy']
    - name: Ergebnis ausgeben
      ansible.builtin.debug:
        var: response.content
      tags: ['deploy', 'test']
    - name: HTTP-Verkehr zulassen
      ansible.posix.firewalld:
        service: http
        permanent: true
        state: enabled

    - name: firewalld neu starten

      ansible.builtin.service:
        name: firewalld
        state: restarted

Das Playbook kann dann mit dem Befehl ansible-playbook -i inventory -K playbook.yaml ausgeführt werden, wobei -K für die Eingabe des BECOME-Passworts steht, um Root-Rechte zu erhalten.

Wichtige Hinweise für den Leser

Es ist von entscheidender Bedeutung, dass der Leser bei der Verwendung von Ansible darauf achtet, dass Playbooks nicht nur zur Installation und Konfiguration von Software dienen, sondern auch als Grundlage für die Automatisierung komplexer Infrastrukturbereitstellungen und Wartungsaufgaben dienen können. Die strukturierte und saubere Aufteilung von Aufgaben und die Wiederverwendbarkeit von Code durch Collections sind dabei zentrale Merkmale für effizientes Arbeiten mit Ansible. Zudem muss bei der Arbeit mit Ansible auf Sicherheitsaspekte geachtet werden, insbesondere beim Umgang mit Passwörtern und vertraulichen Daten.

Wie funktioniert das dynamische Inventar in Ansible mit Docker?

Ansible ermöglicht die Verwaltung von Servern und Containern durch eine Vielzahl von Modulen und Plugins, darunter das Plugin für die dynamische Inventarisierung von Docker-Containern. Dieses Plugin ist Teil der community.docker Sammlung und bietet eine einfache Möglichkeit, Container als Inventarobjekte zu verwenden. Besonders nützlich wird es, wenn Sie eine dynamische Umgebung verwalten möchten, in der Container regelmäßig erstellt und gestoppt werden.

Die Nutzung des Docker-Inventar-Plugins erfordert zunächst eine funktionierende Docker-Umgebung. Das Plugin liest die Daten der Container direkt über die Docker-API und stellt diese in Form einer YAML-Datei bereit. Diese Datei endet mit der Erweiterung '.yml' oder '.yaml' und ermöglicht es, den Docker-Host und die zu verwendenden Parameter zu konfigurieren.

Ein einfacher Beispiel-Workflow sieht folgendermaßen aus: Nach der Installation der Docker-Sammlung mit ansible-galaxy collection install community.docker und dem Start eines Containers (z.B. mit docker run -it --rm --name test redhat/ubi8), können Sie die Konfiguration für das Inventar erstellen. Diese Konfiguration besteht in der Regel aus einer Datei namens main_docker.yaml, die folgendermaßen aussieht:

yaml
Copy code
plugin: community.docker.docker_containers

docker_host: unix://var/run/docker.sock
connection_type: docker-cli

Diese Konfiguration legt fest, dass das Plugin über den docker-cli Befehl auf den Docker-Host zugreift. Danach können Sie den ansible-inventory Befehl ausführen, um die Liste der Container im Inventar zu erhalten.

Wenn der Container läuft, können Sie ihn als Host im Ansible-Inventar sehen:

sql
Copy code
ansible-inventory -i main_docker.yaml --graph
@all:
  |--@ungrouped:
  |  |--test

Wenn der Container gestoppt wird, verschwindet er aus dem Inventar:

arduino
Copy code
docker stop test

Dies ist ein einfaches Beispiel dafür, wie Ansible Container-Verwaltung in einem dynamischen Umfeld automatisieren kann, ohne dass eine manuelle Pflege des Inventars erforderlich ist. Diese Funktion wird besonders in DevOps-Umgebungen geschätzt, in denen Container regelmäßig erstellt und entfernt werden.

Beispielsweise könnte man in einem Playbook eine Liste von Paketen definieren, die auf einem Host installiert werden sollen:

yaml
Copy code
tasks:
  - name: Install Packages
    ansible.builtin.dnf:
      name: "{{ item }}"
    loop:
      - 'java-17-openjdk-devel'
      - 'maven'

Durch den Einsatz von Loops wird das Playbook kompakter und wartungsfreundlicher, da neue Pakete einfach zur Liste hinzugefügt werden können, ohne den Task erneut zu wiederholen. Diese Herangehensweise spart nicht nur Platz, sondern macht das Playbook auch flexibler.

Ein Beispiel für das Registrieren von Variablen innerhalb einer Schleife könnte folgendermaßen aussehen:

yaml
Copy code
- name: Echoing in loops
  hosts: all
  tasks:
    - name: Echo var

      ansible.builtin.command: /bin/echo "Hello World {{item}}"

      loop:
        - 'Ada'
        - 'Aixa'
      register: response
    - name: Print result
      debug:
        var: response

In diesem Fall gibt das Playbook nach der Ausführung ein Array zurück, das die Ausgaben der beiden Iterationen enthält. Die Fähigkeit, in Schleifen registrierte Variablen zu verarbeiten, eröffnet neue Möglichkeiten zur Automatisierung komplexer Prozesse in Ansible.

Abschließend lässt sich sagen, dass Ansible mit seinen flexiblen Mechanismen für die dynamische Inventarisierung und das Arbeiten mit Loops eine mächtige Plattform zur Automatisierung von System- und Containerverwaltungsaufgaben bietet. Die Integration von Docker in diese Automatisierung macht es einfach, die wechselnden Anforderungen einer dynamischen Infrastruktur zu bewältigen. Um jedoch wirklich von Ansible zu profitieren, ist es entscheidend, nicht nur die grundlegenden Konzepte zu verstehen, sondern auch zu lernen, wie man Playbooks so schreibt, dass sie wiederverwendbar, flexibel und einfach zu warten sind. Dies erfordert ein tiefgehendes Verständnis von Variablen, Schleifen und der Strukturierung von Aufgaben, um die bestmögliche Performance und Flexibilität zu gewährleisten.

Wie man Rollen in Ansible entwickelt, verwendet und teilt

Zu Beginn führt Ansible die in der Rolle definierten Abschnitte gemäß der Reihenfolge aus, in der die Rollen im Playbook aufgelistet sind. Diese Reihenfolge kann jedoch durch Abhängigkeiten innerhalb der Rollen selbst beeinflusst werden, da Abhängigkeiten in der Datei meta/main.yml einer Rolle definiert werden können. Diese Abhängigkeiten werden vor der Ausführung der Hauptrolle verarbeitet und unterliegen den gleichen Tag- und Bedingungsfiltern wie normale Aufgaben. Nachdem alle Rollen abgearbeitet wurden, führt Ansible die Aufgaben des Playbooks aus. Dies ist das Standardverhalten.

Obwohl dieses Vorgehen einfach und geradlinig ist, gibt es auch Einschränkungen, insbesondere wenn es darum geht, Rollen zwischen Aufgaben auszuführen. Ein besserer Ansatz besteht darin, eine Aufgabe zu definieren und innerhalb dieser Aufgabe das Modul include_role oder import_role zu verwenden. Dadurch kann man die gleichen Einschränkungen umgehen und die Ausführung von Rollen innerhalb eines Tasks weiter anpassen. Hier ein Beispiel, wie man das Modul include_role verwendet, um eine Rolle namens geerlingguy.java in eine Liste von Aufgaben zu integrieren:

yaml
Copy code
- hosts: all
  become: true
  tasks:
    - name: Installiere JDK
      ansible.builtin.include_role:
        name: geerlingguy.java
      vars:
        java_packages:
          - java-1.8.0-openjdk

Entwicklung einer eigenen Rolle

Es gibt viele Rollen, die bereits auf Ansible Galaxy verfügbar sind und in Playbooks verwendet werden können. Es kann jedoch Gründe geben, warum eine benutzerdefinierte Rolle notwendig wird, sei es aufgrund von organisatorischen Richtlinien oder dem Wunsch, mehr Kontrolle über den Prozess zu haben. In einem solchen Fall ist es notwendig, eine eigene Rolle zu entwickeln.

Zunächst scaffolden wir die Verzeichnisstruktur der Rolle mit dem Befehl ansible-galaxy role init, was automatisch die notwendige Ordnerstruktur für die Rolle anlegt. Diese Struktur umfasst unter anderem Ordner wie defaults, files, handlers, tasks und vars.

Die Hauptarbeit erfolgt im Ordner tasks, in dem wir eine Datei main.yml erstellen und zwei Aufgaben definieren:

yaml
Copy code
- name: Zeige den Inhalt der Datei an

  ansible.builtin.command: "cat {{show_file}}"
  register: command_output
- name: Ausgabe auf der Konsole
  ansible.builtin.debug:
    msg: "{{command_output.stdout}}"

Verwendung und Installation der Rolle

Nach der Entwicklung der Rolle wird sie in einem Playbook verwendet, um die gewünschten Aufgaben zu erfüllen. Es gibt mehrere Methoden, um Rollen zu installieren und zu verwenden. Eine Möglichkeit besteht darin, eine Datei requirements.yml zu erstellen, die alle benötigten Rollen listet, und diese dann mit dem Befehl ansible-galaxy role install -r zu installieren. Hier ein Beispiel einer solchen requirements.yml:

yaml
Copy code
- name: geerlingguy.java
- src: git+file:///roles/nginx
- name: nginx_role
  src: https://github.com/ansiblebook/nginx
  version: main
- name: myrole
  src: https://some.webserver.example.com/files/myrole.tar.gz

yaml
Copy code
- hosts: all
  become: true
  tasks:

    - name: Zeige Hosts an

      ansible.builtin.include_role:
        name: printfile

Diese Methode ermöglicht es, eine Rolle auf einfache Weise in einem Playbook zu verwenden und von außen zu verwalten.

Handler in Rollen

Ein weiteres wichtiges Konzept in Ansible-Rollen sind Handler. Handler sind spezielle Aufgaben, die nur dann ausgeführt werden, wenn eine andere Aufgabe in der Rolle sie explizit anfordert, häufig nach einer Änderung eines Konfigurationsobjekts. Ein Beispiel für einen Handler, der die Ausgabe auf der Konsole anzeigt, könnte folgendermaßen aussehen:

yaml
Copy code
- name: Print to console

  ansible.builtin.debug:
    msg: "{{command_output.stdout}}"

Um diesen Handler zu nutzen, muss eine Aufgabe innerhalb der Rolle diesen explizit benachrichtigen:

yaml
Copy code
- name: Zeige den Inhalt der Datei an
  ansible.builtin.command: "cat {{show_file}}"
  register: command_output
  notify: Print to console

Dies stellt sicher, dass der Handler nur dann ausgeführt wird, wenn die Aufgabe erfolgreich abgeschlossen wurde, und bietet eine größere Flexibilität und Wartbarkeit.

Teilen von Rollen

Nachdem eine Rolle entwickelt und lokal getestet wurde, stellt sich die Frage, wie diese mit anderen geteilt werden kann. Eine Möglichkeit ist die Verwendung des src-Felds in der requirements.yml-Datei, um eine Rolle zu referenzieren, die entweder lokal oder über eine externe Quelle wie Git oder eine HTTP-Server-URL bereitgestellt wird. Mit der Ansible-Galaxy-CLI können die Rollen dann installiert werden, unabhängig davon, ob sie lokal oder remote gehostet werden.

Wichtige Aspekte bei der Nutzung von Rollen

Die Verwendung von Rollen in Ansible spielt eine zentrale Rolle bei der Strukturierung und Modularisierung von Playbooks. Rollen ermöglichen es, Aufgaben zu kapseln, wiederverwendbar zu machen und so die Wartbarkeit und Erweiterbarkeit von Ansible-Playbooks zu verbessern.

Wie man mit Ansible ad-hoc Befehle nutzt und Konfigurationen anpasst

Ansible ist ein leistungsstarkes Werkzeug zur Automatisierung von IT-Aufgaben. Neben den umfangreichen Möglichkeiten zur Erstellung von Playbooks, bietet Ansible auch einfache ad-hoc Befehle, die es ermöglichen, schnell auf verwaltete Hosts zuzugreifen und spezifische Aufgaben auszuführen. Diese Befehle sind besonders hilfreich für einmalige oder einfache Aufgaben, bei denen kein umfassendes Playbook notwendig ist.

Mit den ad-hoc Befehlen von Ansible kann man schnell und unkompliziert einzelne Aufgaben auf verwalteten Hosts ausführen. Ein typisches Beispiel hierfür ist der ping-Befehl, mit dem man überprüft, ob eine Verbindung zu den Hosts im Inventar besteht. Solche Befehle sind sehr hilfreich, um grundlegende Operationen wie das Neustarten von Servern oder das Verwalten von Benutzerkonten durchzuführen. Allerdings haben ad-hoc Befehle auch ihre Einschränkungen: Sie können nur eine einzige Aufgabe ausführen, sind nicht wiederverwendbar und können nicht versioniert werden, da sie direkt auf dem Steuerknoten ausgeführt werden.

Die Syntax eines ad-hoc Befehls ist dabei recht einfach. Ein typischer Befehl könnte folgendermaßen aussehen:

php-template
Copy code
ansible <Host-Pattern> -m <Modul> -a "<Argumente>"

Dabei ist <Host-Pattern> die Zielgruppe (z. B. alle Hosts im Inventar), <Modul> gibt das auszuführende Modul an (z. B. ping), und <Argumente> sind die spezifischen Parameter für das Modul. Ohne die Angabe des Moduls (-m) verwendet Ansible standardmäßig das command-Modul, das es ermöglicht, beliebige Shell-Befehle auf den Zielsystemen auszuführen.

Ein häufiger Anwendungsfall für ad-hoc Befehle ist das Neustarten von Servern. Mit dem folgenden Befehl kann man beispielsweise alle Server im Inventar neustarten:

css
Copy code
ansible all -i inventory -a "/sbin/reboot"

Falls der Benutzer nicht über die nötigen Rechte verfügt, um den Reboot-Befehl auszuführen, kann über den Parameter --become eine privilegierte Ausführung erzwungen werden. Ansible fragt dann nach den entsprechenden Anmeldeinformationen, um die notwendigen Berechtigungen zu erlangen.

Ein weiteres praktisches Beispiel ist die Verwaltung von Benutzerkonten. Der Befehl zum Erstellen eines neuen Benutzers auf allen Hosts im Inventar könnte folgendermaßen aussehen:

python
Copy code
ansible all -i inventory -u root --become --ask-become-pass -m user -a "name=ada password="

Dieser Befehl erstellt den Benutzer ada auf allen verwalteten Hosts. Das Argument state=absent kann verwendet werden, um einen Benutzer zu entfernen. Diese Flexibilität macht ad-hoc Befehle zu einem wertvollen Werkzeug für die schnelle Verwaltung von Systemen.

Ein Beispiel für das Sammeln von Fakten könnte folgendermaßen aussehen:

css
Copy code
ansible all -i inventory -m ansible.builtin.setup

Das Ergebnis dieses Befehls wird im JSON-Format angezeigt und enthält eine Fülle von Informationen zu den Hosts. Diese Fakten können dann in Playbooks verwendet werden, um dynamisch auf Systeminformationen zuzugreifen und Aufgaben entsprechend anzupassen.

Obwohl ad-hoc Befehle viele nützliche Einsatzmöglichkeiten bieten, gibt es bestimmte Szenarien, in denen sie an ihre Grenzen stoßen. Beispielsweise können nur einfache Aufgaben ausgeführt werden, und die Ausführung wird nicht versioniert, was eine Wiederholbarkeit und Nachvollziehbarkeit von Operationen erschwert. Für komplexere Szenarien, bei denen mehrere Aufgaben in einer bestimmten Reihenfolge ausgeführt werden sollen, sind Playbooks die bessere Wahl. In Playbooks lassen sich diese Einschränkungen umgehen, da sie die Automatisierung komplexer Workflows ermöglichen, die versioniert und wiederverwendet werden können.

Die Flexibilität und Schnelligkeit von Ansible, zusammen mit den Möglichkeiten zur Konfiguration und Verwaltung von Systemen über einfache und klare Befehle, machen es zu einem unverzichtbaren Werkzeug in der täglichen Arbeit mit Servern und IT-Infrastrukturen. Es ist wichtig, sich mit den grundlegenden ad-hoc Befehlen vertraut zu machen, um die ersten Schritte in der Automatisierung zu gehen, bevor man sich den weiterführenden Konzepten wie Playbooks widmet.