Wie man Ansible-Rollen und -Sammlungen richtig nutzt und erstellt

Die Verwendung von Ansible zur Automatisierung von Aufgaben bietet zahlreiche Möglichkeiten, wie man verschiedene Inhalte, wie Rollen und Sammlungen, strukturieren und austauschen kann. Eine wichtige Frage, die beim Umgang mit Ansible häufig aufkommt, betrifft die geeignete Art der Verteilung und Verwaltung dieser Inhalte. Ein Git-Repository kann hier eine sehr effektive Lösung bieten, da es den Code sicher speichert, versioniert und dauerhaft aufbewahrt. Eine weitere Möglichkeit ist die Nutzung von Ansible Galaxy oder dem Automation Hub, welche zentrale Repositories für Ansible Content Collections bereitstellen. Diese Plattformen ermöglichen es, Module, Plug-ins, Rollen und Dokumentationen zu finden, herunterzuladen und zu verwalten.

Für komplexere Szenarien, in denen mehrere subtasks miteinander kombiniert werden müssen, bieten sich Ansible Collections an. Diese Methode ermöglicht die Verteilung von verschiedenen Ansible-Inhalten als eine einzige, strukturierte Einheit. Im Gegensatz zu Rollen, die auf eine spezifische Aufgabe fokussiert sind, können Sammlungen verschiedene Inhalte wie Rollen, Plug-ins, Module oder Playbooks bündeln. Collections bieten eine größere Flexibilität und sind leichter zu verwalten, da sie eine breitere Palette von Ansible-Inhalten umfassen.

Die Verwendung von Collections ist einfach. Zum Beispiel gibt es die Ansible POSIX Collection, die eine Vielzahl von Modulen zur Verwaltung von Firewalld, SELinux und Sysctl umfasst. Um diese Sammlung zu installieren, kann der Befehl ansible-galaxy collection install ansible.posix verwendet werden. Auch wenn Sammlungen und Rollen ähnliche Funktionen bieten, sind Sammlungen in der Praxis leichter zu handhaben, da sie auch andere Arten von Inhalten unterstützen. Beide, Rollen und Sammlungen, können sogar im selben requirements.yml-Dateiformat definiert werden, wobei Rollen unter dem Abschnitt roles und Sammlungen unter dem Abschnitt collections platziert werden.

yaml
Copy code
- name: set at command
  hosts: production
  become: yes
  tasks:

    - name: Install at Package

      ansible.builtin.dnf:
        name: at >= 2.4
        state: present
    - name: Schedule a command to execute in 1 minute
      ansible.posix.at:
        command: ls -d / > /tmp/ls.txt
        count: 10
        units: minutes
        unique: yes

Wenn man eine Rolle aus einer Sammlung verwenden möchte, erfolgt dies ebenfalls über das FQCN-Format, wobei der Rollenname nach der Sammlung referenziert wird, wie zum Beispiel community.mongodb.mongodb_install.

markdown
Copy code
└── mynamespace
    └── mycollection
        ├── README.md
        ├── docs
        ├── galaxy.yml
        ├── meta
        │   └── runtime.yml
        ├── plugins
        │   └── README.md
        └── roles

Nach der Erstellung einer Sammlung können Sie diese auf dieselbe Weise wie eine Rolle verwenden, indem Sie die Sammlung installieren und dann die entsprechenden Module oder Rollen über das FQCN ansprechen.

Zusammenfassend lässt sich sagen, dass sowohl Ansible-Rollen als auch -Sammlungen wichtige Bausteine der Automatisierung sind. Während Rollen für isolierte, spezifische Aufgaben gut geeignet sind, bieten Sammlungen eine flexible Möglichkeit, mehrere Inhalte zu bündeln und effizient zu verwalten. Beide Ansätze ermöglichen eine einfache Integration in bestehende Infrastrukturen und bieten durch das Konzept des „Fully Qualified Collection Name“ (FQCN) eine klare Struktur und einfache Handhabung.

Wichtig ist, dass Ansible kontinuierlich weiterentwickelt wird, und die richtige Wahl zwischen Rollen und Sammlungen kann die Effizienz und Wartbarkeit der Automatisierung erheblich steigern. Ein tieferes Verständnis dieser beiden Konzepte und ihrer Anwendung wird eine wesentliche Grundlage für den erfolgreichen Einsatz von Ansible in großen Automatisierungsprojekten sein.

Wie man SSH, YUM-Repositorys und SELinux mit Ansible sicher konfiguriert

Ein wichtiger Bestandteil der Sicherheit von Linux-Systemen ist die ordnungsgemäße Konfiguration von Diensten und Einstellungen, die potenzielle Angriffsflächen bieten könnten. In diesem Zusammenhang spielen SSH, YUM-Repositorys und SELinux eine zentrale Rolle. Ansible, als leistungsstarkes Automatisierungstool, ermöglicht es, diese Parameter effizient zu konfigurieren, sodass die Sicherheit des Systems maximiert wird. Diese Kapitelfokussierung erläutert, wie man gängige Sicherheitskonfigurationen durch Ansible verwaltet, um Schwachstellen zu minimieren.

Ein häufig übersehener Parameter in der SSH-Konfiguration ist MaxAuthTries, der die Anzahl der erlaubten Authentifizierungsversuche für einen Benutzer regelt. Der Standardwert in der Datei sshd_config ist in der Regel auskommentiert, was bedeutet, dass er nicht aktiviert ist. Der Wert kann jedoch leicht angepasst werden, um Brute-Force-Angriffe zu verhindern. In einer sicheren Umgebung sollte MaxAuthTries auf einen niedrigeren Wert gesetzt werden. Ein Beispiel:

yaml
Copy code
- name: SSH Konfiguration

  hosts: alle
  become: true
  tasks:
    - name: MaxAuthTries anpassen
      ansible.builtin.lineinfile:
        path: /etc/ssh/sshd_config
        regexp: "^#MaxAuthTries "
        line: "MaxAuthTries 3"
      notify: Neustart des SSH-Dienstes
  handlers:
    - name: Neustart des SSH-Dienstes
      ansible.builtin.service:
        name: sshd
        state: restarted

Die Verwendung des lineinfile-Moduls ermöglicht es, den auskommentierten MaxAuthTries-Wert durch einen spezifischen Wert zu ersetzen. Nach der Änderung wird der SSH-Dienst neu gestartet, damit die Änderungen wirksam werden. Es ist jedoch von großer Bedeutung, vorsichtig zu sein, wenn Ansible zur Verwaltung von SSH-Parametern verwendet wird, da eine falsche Konfiguration das Remote-Management des Hosts verhindern könnte.

Ein weiteres Beispiel für eine Sicherheitsmaßnahme in Ansible ist die Konfiguration von YUM-Repositorys. In einer sicheren Umgebung sollten alle Repositorys, aus denen Softwarepakete bezogen werden, überprüft und validiert werden, um sicherzustellen, dass sie aus vertrauenswürdigen Quellen stammen. Dies kann durch die Verwendung von GPG-Schlüsseln erreicht werden. In Ansible kann dies mit den Modulen rpm_key und yum_repository erfolgen:

yaml
Copy code
- name: YUM-Repository registrieren

  hosts: datenbank
  become: true
  tasks:
    - name: GPG-Schlüssel importieren
      ansible.builtin.rpm_key:
        state: present
        key: https://repo.mysql.com/RPM-GPG-KEY-mysql
    - name: Repository hinzufügen
      ansible.builtin.yum_repository:
        name: mysql84-community
        description: MySQL YUM-Repo
        baseurl: https://repo.mysql.com/yum/mysql-8.4-community/el/8/$basearch
        gpgcheck: true
        gpgkey: https://repo.mysql.com/RPM-GPG-KEY-mysql
        enabled: true

Hierbei wird ein MySQL-Repository hinzugefügt und die GPG-Überprüfung aktiviert, um sicherzustellen, dass die heruntergeladenen Pakete aus einer vertrauenswürdigen Quelle stammen. Das Setzen der gpgcheck-Option auf true ist entscheidend, da es sicherstellt, dass die heruntergeladenen Pakete durch einen GPG-Schlüssel validiert werden, wodurch das Risiko verringert wird, dass schadhafter Code auf das System gelangt.

Die letzte große Sicherheitskomponente, die in diesem Abschnitt behandelt wird, ist SELinux, das Sicherheitsarchitektur-Modul des Linux-Kernels. SELinux bietet eine erweiterte Zugriffskontrolle auf Systemressourcen und stellt sicher, dass nur autorisierte Benutzer und Prozesse auf bestimmte Daten zugreifen können. Ansible erleichtert die Konfiguration von SELinux über die Rolle linux-system-roles.selinux. Diese Rolle ermöglicht das Setzen des SELinux-Status (z. B. auf "enforcing"), das Mapping von Ports und das Management von SELinux-Boolean-Werten, die bestimmen, welche Policies aktiv sind.

Ein Beispiel zur Konfiguration von SELinux mit Ansible könnte wie folgt aussehen:

yaml
Copy code
- name: SELinux-Policy verwalten
  hosts: alle
  become: true
  vars:
    selinux_state: enforcing
    selinux_ports:
      - { ports: "22100", proto: "tcp", setype: "ssh_port_t", state: "present" }
  tasks:
    - name: SELinux-Rolle ausführen
      ansible.builtin.include_role:
        name: linux-system-roles.selinux
  post_tasks:

    - name: System neu starten

      ansible.builtin.reboot:

Hier wird der SELinux-Zustand auf "enforcing" gesetzt und der Port 22100 dem ssh_port_t-Typ zugewiesen. Der Neustart des Systems stellt sicher, dass alle Änderungen wirksam werden. Diese Methode der Verwaltung von SELinux über Ansible ermöglicht eine präzise und konsistente Kontrolle über die Sicherheitseinstellungen auf einer Vielzahl von Hosts.

yaml
Copy code
- name: SELinux-Policy verwalten
  hosts: alle
  become: true
  vars:
    selinux_state: enforcing
    selinux_booleans:
      - name: httpd_can_network_connect
        state: true
        persistent: true

Ein weiterer Aspekt, der in der Ansible-Sicherheitskonfiguration nicht vernachlässigt werden sollte, ist die richtige Verwaltung von SELinux-Modulen und -Benutzern. Ansible bietet dazu die Variablen selinux_modules und selinux_logins, mit denen zusätzliche SELinux-Module installiert und Benutzer bestimmte SELinux-Rollen zugewiesen werden können.

Wie man ein Ansible Execution Environment erstellt und verwaltet: Ein praktischer Leitfaden

Ansible ist ein mächtiges Tool für Automatisierung und Configuration Management, das insbesondere in komplexen IT-Infrastrukturen und DevOps-Prozessen eine bedeutende Rolle spielt. Eine der zentralen Herausforderungen bei der Verwendung von Ansible ist die Verwaltung und das Erstellen von sogenannten "Execution Environments" (EE). Diese Umgebung sorgt dafür, dass alle notwendigen Module, Rollen und Abhängigkeiten für das Ausführen von Playbooks vorhanden sind und korrekt konfiguriert werden. In dieser Hinsicht bieten Ansible Execution Environments eine effektive Möglichkeit, die Konsistenz und Reproduzierbarkeit von Automatisierungsprozessen sicherzustellen.

Ein Execution Environment wird durch die Konfiguration eines Container-Images erstellt, in dem Ansible ausgeführt wird. Hierbei können benutzerdefinierte Module, Rollen und Abhängigkeiten in einer kontrollierten Umgebung gespeichert und verwendet werden. Dies verhindert Konflikte, die durch unterschiedliche Versionen von Softwarekomponenten oder Module auftreten können, und stellt sicher, dass die Automatisierung in jeder Umgebung zuverlässig und vorhersagbar abläuft.

Definition und Struktur eines Execution Environments

Ein Execution Environment besteht aus verschiedenen Komponenten, die alles Notwendige für das Ausführen von Automatisierungsaufgaben enthalten. Dies umfasst:

• Module und Rollen: Diese werden häufig in sogenannten Ansible Collections gebündelt. Eine Collection ist eine Sammlung von Ansible-Inhalten, die Module, Plugins, Rollen und Playbooks enthalten kann. Sie stellt sicher, dass alle notwendigen Elemente für eine bestimmte Aufgabe oder Gruppe von Aufgaben direkt verfügbar sind.

• Build-Kontext: Um ein Execution Environment zu erstellen, müssen die entsprechenden Build-Schritte definiert werden. Diese Schritte beinhalten die Angabe von Basis-Images, die Installation von Ansible und weiteren notwendigen Tools sowie die Bereitstellung von Abhängigkeiten, die im Container enthalten sein müssen.

• Images und Container: Ein wichtiges Element eines Execution Environments sind Container, die die gesamte Umgebung isoliert ausführen. Die Vorteile dieser Containerlösung liegen auf der Hand: Sie bieten eine vollständige Isolierung der Ausführungsumgebung und gewährleisten, dass die Automatisierung auf jeder Plattform gleich funktioniert. Dies ist besonders relevant in heterogenen Umgebungen, in denen verschiedene Betriebssysteme und Softwareversionen verwendet werden.

• Abhängigkeiten und Versionen: Beim Erstellen eines Execution Environments ist es wichtig, Abhängigkeiten korrekt zu definieren. In der Regel gibt es eine spezielle Sektion im Definition File, in der Abhängigkeiten zu anderen Collections oder Modulen spezifiziert werden können. Diese Abhängigkeiten sorgen dafür, dass das Execution Environment genau die Versionen von Tools und Modulen enthält, die benötigt werden.

Aufbau und Erstellung eines Execution Environments

Besonders wichtig bei der Erstellung eines Execution Environments ist die Konsistenz zwischen verschiedenen Build-Durchläufen. Änderungen, die in einem bestimmten Schritt vorgenommen werden, müssen im gesamten Prozess nachvollziehbar sein. Daher ist eine gute Fehlerbehandlung innerhalb des Build-Prozesses entscheidend. Auch die Einbindung von Tests, um sicherzustellen, dass das erstellte Execution Environment korrekt funktioniert, ist unerlässlich.

Ein weiterer wichtiger Punkt bei der Erstellung von Execution Environments ist die Handhabung von Zertifikaten und sicherheitsrelevanten Informationen. In einer Produktionsumgebung müssen Zertifikate für die sichere Kommunikation zwischen den verschiedenen Systemen korrekt eingerichtet und regelmäßig aktualisiert werden.

Fehlerbehandlung und Debugging

In Ansible können Fehler durch die Verwendung von sogenannten "Blocks" abgefangen werden. Ein Block ist eine Sammlung von Aufgaben, die zusammen ausgeführt werden. Sollte eine der Aufgaben im Block fehlschlagen, kann der gesamte Block abgebrochen und eine spezifische Fehlerbehandlung durchgeführt werden. Dies stellt sicher, dass keine unvorhergesehenen Fehler die gesamte Ausführung eines Playbooks beeinträchtigen.

Rolle der Automation und Containerisierung

Die Containerisierung von Ansible und seiner Umgebung hat sich als ein wichtiges Element der modernen IT-Infrastruktur etabliert. Durch die Nutzung von Docker und anderen Container-Technologien können Execution Environments isoliert und unabhängig voneinander ausgeführt werden. Dies führt zu einer verbesserten Skalierbarkeit und Flexibilität bei der Durchführung von Automatisierungsaufgaben.

Wichtiges für den Leser

Die Erstellung und Verwaltung von Execution Environments in Ansible ist ein komplexer Prozess, der eine präzise Planung und Durchführung erfordert. Es ist wichtig, sich mit den verschiedenen Komponenten und Tools auseinanderzusetzen, die für die Erstellung eines Execution Environments notwendig sind, und die Prinzipien der Fehlerbehandlung sowie des Debuggings zu verstehen. Auch die Containerisierung und die Nutzung von Ansible in einer Containerumgebung sollten stets in Betracht gezogen werden, da sie die Flexibilität und Skalierbarkeit der Automatisierung erheblich verbessern.

Zusätzlich sollte beachtet werden, dass bei der Arbeit mit Ansible nicht nur die Technik im Vordergrund steht, sondern auch eine klare Strukturierung der Automatisierungsaufgaben notwendig ist, um langfristig die Effizienz und Wartbarkeit des Systems zu gewährleisten.

Wie Ansible mit idempotenten Aufgaben umgeht und wie man die Ausführungsstrategie anpasst

Ansible ist ein mächtiges Automatisierungstool, das in der IT- und DevOps-Welt weit verbreitet ist. Eine der wichtigsten Eigenschaften von Ansible-Modulen ist ihre Idempotenz. Dies bedeutet, dass Ansible bei der Ausführung von Aufgaben prüft, ob der gewünschte Endzustand bereits erreicht wurde. Falls dies der Fall ist, wird die Aufgabe nicht erneut ausgeführt, was unnötige Wiederholungen verhindert und die Effizienz steigert. Dies ist besonders wichtig, wenn man mit Systemen arbeitet, bei denen der Zustand von Diensten, Paketen oder Verzeichnissen beibehalten oder angepasst werden muss.

Bei der Erstellung von Playbooks ist es entscheidend, zu verstehen, dass idempotente Module wie das state-Attribut im yum-Modul (z. B. für die Installation von Paketen) oder das service-Modul (z. B. zum Starten von Diensten) sicherstellen, dass der gewünschte Zustand erreicht wird, ohne unnötige Wiederholungen. Ein einfaches Beispiel für ein Playbook könnte darin bestehen, einen Webserver und eine Datenbank auf dem neuesten Stand zu halten, indem man sicherstellt, dass der Apache-Webserver und PostgreSQL in ihrer neuesten Version installiert und korrekt gestartet sind.

Das folgende Playbook zeigt, wie dies erreicht werden kann:

yaml
Copy code
---
- name: Web Servers
  hosts: webservers
  become: true
  tasks:
    - name: Ensure apache is at the latest version
      ansible.builtin.yum:
        name: httpd
        state: latest
- name: DB servers
  hosts: databases
  become: true
  tasks:
    - name: Ensure postgresql is at the latest version
      ansible.builtin.yum:
        name: postgresql
        state: latest
    - name: Ensure that postgresql is started
      ansible.builtin.service:
        name: postgresql
        state: started

Um das Playbook auszuführen, benötigt man eine Inventardatei, die die Hosts definiert, auf denen die Aufgaben ausgeführt werden sollen. Ein Beispiel für eine solche Datei könnte wie folgt aussehen:

ini
Copy code
[webservers]
web1.example.com
web2.example.com
[databases]
db1.example.com
db2.example.com

Das Playbook wird mit dem Befehl ansible-playbook ausgeführt:

bash
Copy code
ansible-playbook -i inventory playbook.yaml

Während die Ausführung des Playbooks an sich einfach ist, werden viele komplexe Operationen im Hintergrund durchgeführt. Ansible führt jede Aufgabe der Reihe nach aus, und zwar parallel auf allen Hosts, die durch das Hostmuster übereinstimmen. Nachdem eine Aufgabe abgeschlossen ist, geht Ansible zur nächsten über.

Ansible-Ausführungsstrategien

Ein wichtiger Aspekt der Nutzung von Ansible ist die Kontrolle über die Ausführungsstrategie von Aufgaben. Ansible bietet verschiedene Strategien, um das Verhalten der Task-Ausführung zu beeinflussen. Standardmäßig verwendet Ansible die "linear"-Strategie, bei der Aufgaben nacheinander und parallel auf den Hosts ausgeführt werden. Doch es gibt auch andere Optionen, wie etwa die "free"-Strategie, bei der Ansible die Ausführung der Aufgaben auf einem Host nicht blockiert, wenn andere Hosts bereits abgeschlossen haben.

Die Strategien lassen sich sowohl auf Playbook- als auch auf Play-Ebene festlegen. So kann man beispielsweise das Verhalten für eine bestimmte Gruppe von Hosts definieren:

yaml
Copy code
- name: Web Servers

  hosts: webservers
  strategy: free
  tasks:
    # Aufgaben

Parallele Ausführung und Forks

Ansible nutzt das Konzept von "Forks", um die Anzahl gleichzeitiger Verbindungen zu Hosts zu steuern. Standardmäßig verwendet Ansible fünf Forks, was bedeutet, dass bis zu fünf Hosts gleichzeitig bearbeitet werden können. Diese Zahl kann jedoch angepasst werden, um die Performance zu optimieren. Eine Erhöhung der Anzahl der Forks ermöglicht es, mehr Hosts parallel zu bearbeiten, was insbesondere bei größeren Umgebungen von Vorteil sein kann. Dies kann global in der ansible.cfg-Datei oder als Parameter im CLI-Befehl festgelegt werden:

ini
Copy code
[defaults]
forks = 50

Oder beim Ausführen des Playbooks über die Kommandozeile:

bash
Copy code
ansible-playbook playbook.yaml --forks 50

Batch-Größe und Serienausführung

Ein weiteres nützliches Feature in Ansible ist die Möglichkeit, die Anzahl der Hosts zu steuern, die gleichzeitig bearbeitet werden, indem man die serial-Eigenschaft verwendet. Dies ist besonders wichtig, wenn man Rolling Updates durchführt und sicherstellen möchte, dass nur eine bestimmte Anzahl von Hosts gleichzeitig bearbeitet wird, um Ausfallzeiten zu vermeiden. Man kann die Batch-Größe entweder als absolute Zahl oder als Prozentsatz der Hosts angeben.

Beispiel:

yaml
Copy code
- name: serial example play
  hosts: webservers
  serial: 4
  tasks:
    - name: first task
      ansible.builtin.command: hostname
    - name: second task
      ansible.builtin.command: hostname

In diesem Fall werden die Aufgaben zunächst auf vier Hosts ausgeführt. Sobald diese abgeschlossen sind, werden die nächsten vier Hosts bearbeitet.

Weiterführende Gedanken