Ansible für Einsteiger — RHEL und Ubuntu Server

Ein praxisorientiertes Tutorial für den Einstieg in die Automatisierung mit Ansible.

Über dieses Tutorial

Dieses Tutorial richtet sich an Administratoren, die Linux-Server bereits von der Kommandozeile aus bedienen, aber noch nie mit einem Konfigurationsmanagement-Werkzeug gearbeitet haben. Alle Beispiele sind so aufgebaut, dass sie gleichzeitig auf Red Hat Enterprise Linux 9 und Ubuntu Server 24.04 LTS funktionieren. Genau darin liegt der didaktische Kern: Wer von Anfang an mit zwei Distributionen arbeitet, lernt automatisch sauberer zu automatisieren.

Zeitbedarf: ca. 6–8 Stunden inklusive der Übungen.

Hinweis zur Wiki-Syntax

Dieses Dokument verwendet das Plugin wrap für die farbigen Hinweiskästen. Installation über Admin → Extension Manager → Suchen nach „wrap“. Ist das Plugin nicht vorhanden, erscheinen die Kästen als normaler Text — der Inhalt bleibt vollständig lesbar.

Verwendete Kastentypen:



'' — Erläuterung, Hintergrund


 

'' — Praxistipp, Empfehlung


 

'' — muss man wissen


 

'' — Warnung, Gefahr von Schaden





—-

===== 1. Einleitung =====

==== 1.1 Was ist Ansible und wofür wird es eingesetzt ====

Ansible ist ein Werkzeug zur Automatisierung von IT-Infrastruktur. Man beschreibt in Textdateien den gewünschten Zustand eines Systems — welche Pakete installiert, welche Dienste gestartet und welche Konfigurationsdateien vorhanden sein sollen — und Ansible sorgt dafür, dass die Zielsysteme diesen Zustand erreichen.

Der entscheidende Perspektivwechsel für Einsteiger:

^ Klassisches Shell-Skript ^ Ansible ^
| Beschreibt Schritte („installiere Paket X“) | Beschreibt Zustände („Paket X soll vorhanden sein“) |
| Zweiter Durchlauf kann Schaden anrichten | Zweiter Durchlauf ändert nichts |
| Distributionsspezifisch | Abstrahiert über Module |
| Fehlerbehandlung muss selbst gebaut werden | Bricht bei Fehlern kontrolliert ab |

Typische Einsatzgebiete sind die Grundkonfiguration frisch installierter Server, das Ausrollen von Anwendungen, Patch-Management, Compliance-Prüfungen und die Orchestrierung mehrstufiger Abläufe über mehrere Systeme hinweg.

==== 1.2 Agentless-Prinzip: Push statt Pull ====

Auf den verwalteten Systemen muss keine Ansible-Software installiert werden. Ansible meldet sich per SSH an, überträgt ein kleines Python-Programm (das Modul), führt es aus, holt das Ergebnis ab und löscht das Programm wieder.

<code>
   Control Node                        Managed Nodes
   ┌────────────────┐                  ┌──────────────────┐
   │  ansible-core  │  ── SSH ──────▶  │  RHEL 9          │
   │  Playbooks     │                  │  python3, sshd   │
   │  Inventory     │                  └──────────────────┘
   │                │                  ┌──────────────────┐
   │                │  ── SSH ──────▶  │  Ubuntu 24.04    │
   └────────────────┘                  │  python3, sshd   │
                                       └──────────────────┘
</code>

Daraus folgen zwei praktische Konsequenzen:

  * Die Zielsysteme brauchen nur SSH-Zugang und einen Python-3-Interpreter. Beides ist bei RHEL 9 und Ubuntu 24.04 standardmäßig vorhanden.
  * Der Control Node ist der einzige Ort, an dem Ansible installiert und gepflegt werden muss. Er läuft nicht unter Windows — WSL, eine VM oder ein Linux-Server sind erforderlich.

==== 1.3 Abgrenzung zu Puppet, Chef, Salt ====

^ Werkzeug ^ Modell ^ Agent nötig ^ Sprache der Definitionen ^
| Ansible | Push | nein | YAML |
| Puppet | Pull | ja | eigene DSL |
| Chef | Pull | ja | Ruby |
| Salt | beides | meist ja | YAML |

Ansible ist für den Einstieg deshalb attraktiv, weil die Einstiegshürde niedrig ist: kein Server, kein Agent, keine neue Programmiersprache. Der Preis dafür ist geringere Geschwindigkeit bei sehr großen Umgebungen und das Fehlen einer permanenten Zustandsüberwachung.

==== 1.4 Voraussetzungen für dieses Tutorial ====

Kenntnisse: Umgang mit der Bash, Grundverständnis von SSH, Paketverwaltung und systemd.

Technik: Drei Systeme — physisch, virtuell oder als Container. Für ein reines Lernsetup genügen jeweils 1 vCPU und 1 GB RAM. Alternativ funktioniert das gesamte Tutorial auch mit einer einzigen Maschine, auf der zwei VMs unter KVM, VirtualBox oder Vagrant laufen.



Verwende für die Übungen keine Produktivsysteme. Ansible führt Änderungen ohne Rückfrage aus, sobald ein Playbook startet.





—-

===== 2. Die Testumgebung aufbauen =====

==== 2.1 Aufbau: ein Control Node, zwei Managed Nodes ====

^ Rolle ^ Hostname ^ Betriebssystem ^ Beispiel-IP ^
| Control Node | ''ctrl | beliebig (hier: Ubuntu 24.04) | 192.168.56.10 |






| Managed Node 1 | rhel9 | RHEL 9 | 192.168.56.11 |


	
		 Managed Node 2  ubuntu24  Ubuntu Server 24.04  192.168.56.12 
	



Wer keine RHEL-Subskription hat: Die Red Hat Developer Subscription ist für Einzelpersonen kostenlos und umfasst bis zu 16 Systeme. Alternativ funktionieren AlmaLinux 9 oder Rocky Linux 9 in diesem Tutorial identisch — beide melden sich als os_family = RedHat.


2.2 Netzwerk, Hostnamen und /etc/hosts


Ohne funktionierende DNS-Auflösung trägt man die Namen auf dem Control Node in /etc/hosts ein:

sudo tee -a /etc/hosts <<'EOF'
192.168.56.11   rhel9
192.168.56.12   ubuntu24
EOF


Erreichbarkeit prüfen:

ping -c1 rhel9
ping -c1 ubuntu24

2.3 Benutzer und sudo-Rechte auf den Zielsystemen


Ansible sollte sich nicht als root anmelden. Stattdessen legt man auf jedem Managed Node einen Automatisierungsbenutzer an, der per sudo ohne Passwortabfrage eskalieren darf.



Auf RHEL 9:

sudo useradd -m -s /bin/bash ansible
sudo passwd ansible
echo 'ansible ALL=(ALL) NOPASSWD:ALL' | sudo tee /etc/sudoers.d/ansible
sudo chmod 0440 /etc/sudoers.d/ansible


Auf Ubuntu 24.04 identisch — Ubuntu verwendet ebenfalls /etc/sudoers.d/.



NOPASSWD:ALL ist für eine Lernumgebung vertretbar. In produktiven Umgebungen schränkt man die erlaubten Kommandos ein oder hinterlegt das sudo-Passwort per –ask-become-pass bzw. über Ansible Vault.


2.4 SSH-Schlüssel erzeugen und verteilen


Auf dem Control Node als der Benutzer, der später Ansible ausführt:

ssh-keygen -t ed25519 -C "ansible control node"
ssh-copy-id ansible@rhel9
ssh-copy-id ansible@ubuntu24


Test — die Anmeldung muss ohne Passwortabfrage gelingen:

ssh ansible@rhel9 'hostname; id'
ssh ansible@ubuntu24 'hostname; id'


Warum das wichtig ist: Ansible startet je Task eine SSH-Verbindung. Eine interaktive Passwortabfrage würde jeden Playbook-Lauf blockieren. Der Schlüsselaustausch ist die eigentliche Grundvoraussetzung — funktioniert er nicht, funktioniert nichts danach.



Übung 2.1: Melde dich einmal manuell per SSH an jedem Managed Node an und führe sudo whoami aus. Die Ausgabe muss root lauten, ohne dass ein Passwort abgefragt wird.



3. Installation von Ansible


Ansible wird ausschließlich auf dem Control Node installiert.


3.1 Installation auf RHEL


Seit RHEL 8 liegt ansible-core direkt im AppStream-Repository:

sudo dnf install -y ansible-core


Damit erhält man die Ansible-Engine plus die Collection ansible.builtin. Weitere Collections installiert man bei Bedarf über Galaxy (siehe Kapitel 12.5) oder über Pakete wie rhel-system-roles.



Wer stattdessen das große Community-Paket möchte, aktiviert EPEL:

sudo dnf install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-9.noarch.rpm
sudo dnf install -y ansible

3.2 Installation auf Ubuntu


Aus den Ubuntu-Repositories:

sudo apt update
sudo apt install -y ansible


Das Paket ansible entspricht hier dem Community-Bundle inklusive vieler Collections. Wer nur die Engine will, installiert ansible-core.



Ubuntu-Pakete hinken der aktuellen Version oft hinterher. Für eine neuere Version bietet das Ansible-Projekt eine PPA an:

sudo apt install -y software-properties-common
sudo add-apt-repository --yes --update ppa:ansible/ansible
sudo apt install -y ansible

3.3 Installation via pip in einer venv


Die flexibelste Variante, besonders wenn mehrere Ansible-Versionen parallel benötigt werden:

python3 -m venv ~/ansible-venv
source ~/ansible-venv/bin/activate
pip install --upgrade pip
pip install ansible ansible-lint


Deaktivieren mit deactivate. Die venv muss vor jeder Nutzung wieder aktiviert werden.


	
	
		 Methode  Vorteil  Nachteil 
	
	
	
		 Distributionspaket  integriert, gepatcht  oft ältere Version 
	
	
		 PPA / EPEL  aktueller  zusätzliche Fremdquelle 
	
	
		 pip in venv  volle Versionskontrolle  Pflege liegt beim Benutzer 
	


3.4 Versionen prüfen und verstehen
ansible --version


Beispielausgabe:

ansible [core 2.16.3]
  config file = /home/andre/ansible/ansible.cfg
  configured module search path = ['/home/andre/.ansible/plugins/modules', ...]
  ansible python module location = /usr/lib/python3/dist-packages/ansible
  executable location = /usr/bin/ansible
  python version = 3.12.3
  jinja version = 3.1.2


Drei Zeilen sind für Einsteiger wichtig:


 core-Version — bestimmt, welche Module und Syntax verfügbar sind.

 config file — zeigt, welche ansible.cfg tatsächlich greift. Steht hier None, wurde keine gefunden.

 python version — der Interpreter auf dem Control Node, nicht auf den Zielen.




Begriffsklärung: ansible-core ist die Engine. ansible ist ein Bundle aus der Engine plus rund 85 Collections. Beide melden dieselbe core-Version. Prüfen lässt sich das Bundle mit ansible-community –version.



4. Grundkonfiguration

4.1 Die Datei ansible.cfg und ihre Suchreihenfolge


Ansible sucht seine Konfiguration in dieser Reihenfolge und nimmt die erste gefundene Datei — es wird nicht zusammengeführt:


 Umgebungsvariable ANSIBLE_CONFIG

 ./ansible.cfg im aktuellen Arbeitsverzeichnis

 ~/.ansible.cfg

 /etc/ansible/ansible.cfg




Für dieses Tutorial legen wir ein Projektverzeichnis an:

mkdir -p ~/ansible-tutorial
cd ~/ansible-tutorial

ansible.cfg
[defaults]
inventory        = ./inventory.yml
remote_user      = ansible
host_key_checking = False
interpreter_python = auto_silent
stdout_callback  = yaml
retry_files_enabled = False
 
[privilege_escalation]
become        = False
become_method = sudo
become_user   = root



Bedeutung der Einträge:


	
	
		 Option  Wirkung 
	
	
	
		 inventory  Standard-Inventory, spart -i bei jedem Aufruf 
	
	
		 remote_user  Benutzer für die SSH-Anmeldung 
	
	
		 host_key_checking  False vermeidet Rückfragen bei neuen Hosts — nur in Testumgebungen! 
	
	
		 interpreter_python  unterdrückt Warnungen zur Interpreter-Erkennung 
	
	
		 stdout_callback = yaml  macht die Ausgabe deutlich besser lesbar 
	



Ansible ignoriert eine ansible.cfg im aktuellen Verzeichnis, wenn dieses für alle schreibbar ist (chmod 777). Das ist eine Sicherheitsmaßnahme und eine häufige Ursache für „meine Konfiguration wird nicht gelesen“.


4.2 Das Inventory: INI- und YAML-Format


Das Inventory beantwortet die Frage: Welche Systeme gibt es und wie sind sie gruppiert?



INI-Format (kompakt, gut für kleine Umgebungen):


inventory.ini
[rhel]
rhel9 ansible_host=192.168.56.11
 
[ubuntu]
ubuntu24 ansible_host=192.168.56.12
 
[webserver:children]
rhel
ubuntu



YAML-Format (strukturierter, für alles ab mittlerer Größe empfohlen):


inventory.yml
---
all:
  children:
    webserver:
      children:
        rhel:
          hosts:
            rhel9:
              ansible_host: 192.168.56.11
        ubuntu:
          hosts:
            ubuntu24:
              ansible_host: 192.168.56.12



Das Ergebnis prüfen — dieser Befehl ist bei Inventory-Problemen das wichtigste Diagnosewerkzeug:

ansible-inventory --list -y
ansible-inventory --graph

4.3 Gruppen, Kindgruppen und die Gruppe all

 Jeder Host gehört automatisch zur Gruppe all.

 Ein Host darf in beliebig vielen Gruppen sein.

 Gruppen dürfen über children verschachtelt werden.

 Die Gruppe ungrouped enthält Hosts ohne eigene Gruppe.




Eine bewährte Konvention: Gruppen nach Funktion (webserver, datenbank) und zusätzlich nach Umgebung (prod, test) bilden. Ein Host ist dann in beiden.


4.4 Erste Verbindung testen
ansible all -m ansible.builtin.ping


Erwartete Ausgabe:

rhel9 | SUCCESS => {
    "changed": false,
    "ping": "pong"
}
ubuntu24 | SUCCESS => {
    "changed": false,
    "ping": "pong"
}


ping hat nichts mit ICMP zu tun. Das Modul meldet sich per SSH an, startet Python auf dem Ziel und lässt sich pong zurückgeben. Es testet also die komplette Kette: SSH, Authentifizierung und Python — genau das, was Ansible braucht.



Typische Fehler an dieser Stelle:


	
	
		 Meldung  Ursache 
	
	
	
		 Permission denied (publickey,password)  SSH-Schlüssel nicht verteilt oder falscher remote_user 
	
	
		 Failed to connect … No route to host  Netzwerk/Firewall 
	
	
		 /usr/bin/python3: not found  kein Python auf dem Ziel 
	
	
		 Missing sudo password  become ohne NOPASSWD-Regel 
	


4.5 Privilege Escalation mit become


Ohne Eskalation:

ansible all -m ansible.builtin.command -a "id -un"
# -> ansible


Mit Eskalation:

ansible all -m ansible.builtin.command -a "id -un" --become
# -> root


become lässt sich global in ansible.cfg, pro Play oder pro einzelnem Task setzen. Empfehlung für Einsteiger: global auf False lassen und dort aktivieren, wo es gebraucht wird. Das macht sichtbar, welche Tasks tatsächlich Root-Rechte benötigen.



Übung 4.1: Erweitere das Inventory um eine Gruppe test, die beide Hosts enthält, und prüfe das Ergebnis mit ansible-inventory –graph.



5. Ad-hoc-Befehle

5.1 Aufbau eines Ad-hoc-Kommandos
ansible <muster> -m <modul> -a "<argumente>" [optionen]

	
	
		 Bestandteil  Bedeutung 
	
	
	
		 <muster>  Host, Gruppe oder Muster (all, rhel, web*, rhel:!rhel9) 
	
	
		 -m  Modul (Standard ist command) 
	
	
		 -a  Argumente für das Modul 
	
	
		 -b  Kurzform für –become 
	


5.2 Nützliche Module für den Einstieg
# Uptime aller Hosts
ansible all -m ansible.builtin.command -a "uptime"
 
# Freier Speicherplatz
ansible all -m ansible.builtin.shell -a "df -h / | tail -1"
 
# Datei verteilen
ansible all -m ansible.builtin.copy \
  -a "src=/etc/motd dest=/tmp/motd.kopie mode=0644"
 
# Dienststatus abfragen
ansible all -m ansible.builtin.service_facts
 
# Alle Fakten eines Hosts anzeigen
ansible rhel9 -m ansible.builtin.setup


**command oder shell?** command führt das Programm direkt aus — ohne Shell, also ohne Pipes, Umleitungen und Variablenexpansion. shell startet eine Shell und kann all das. Faustregel: **immer command, außer man braucht wirklich Shell-Funktionen.** command ist sicherer, weil keine Sonderzeichen interpretiert werden.


5.3 Paketverwaltung: dnf, apt und package
# Nur RHEL
ansible rhel -m ansible.builtin.dnf -a "name=tree state=present" -b
 
# Nur Ubuntu
ansible ubuntu -m ansible.builtin.apt -a "name=tree state=present update_cache=yes" -b
 
# Beide gleichzeitig - das generische Modul wählt selbst
ansible all -m ansible.builtin.package -a "name=tree state=present" -b


Das package-Modul ist bequem, hat aber eine Grenze: Es abstrahiert nur den Paketmanager, nicht die Paketnamen. httpd heißt unter Ubuntu apache2, und daran ändert package nichts. Wie man das löst, zeigt Kapitel 11.


5.4 Grenzen von Ad-hoc-Befehlen


Ad-hoc-Befehle sind ideal für einmalige Abfragen und schnelle Eingriffe. Sie stoßen dort an ihre Grenzen, wo:


 mehrere Schritte in fester Reihenfolge nötig sind,

 Bedingungen oder Schleifen gebraucht werden,

 das Ergebnis reproduzierbar und versionierbar sein soll,

 jemand anders nachvollziehen können muss, was passiert ist.




Für all das gibt es Playbooks.



Übung 5.1: Ermittle mit einem einzigen Ad-hoc-Befehl die Kernel-Version aller Hosts. Übung 5.2: Installiere das Paket htop auf beiden Systemen und deinstalliere es anschließend wieder (state=absent).



6. YAML-Grundlagen

6.1 Einrückung, Listen, Dictionaries


YAML kennt drei Bausteine: Skalare (einzelne Werte), Listen und Dictionaries (Schlüssel-Wert-Paare).


beispiel.yml
---
# Skalar
name: webserver
 
# Liste
pakete:
  - httpd
  - mod_ssl
  - php
 
# Dictionary
benutzer:
  name: andre
  shell: /bin/bash
  uid: 1001
 
# Liste von Dictionaries - die häufigste Struktur in Ansible
benutzerliste:
  - name: andre
    uid: 1001
  - name: martina
    uid: 1002



Die drei eisernen Regeln:


 Eingerückt wird ausschließlich mit Leerzeichen, niemals mit Tabulatoren.

 Die Einrückungstiefe muss innerhalb einer Ebene konsistent sein (üblich: 2 Leerzeichen).

 Nach einem Doppelpunkt folgt ein Leerzeichen: name: wert, nicht name:wert.



6.2 Strings, Booleans und typische Stolperfallen
# Booleans - YAML kennt viele Schreibweisen
aktiv: true          # empfohlen
aktiv: yes           # gleichbedeutend, aber uneinheitlich
 
# Norwegen-Problem: NO wird als Boolean false gelesen!
land: NO             # -> false
land: "NO"           # -> Zeichenkette "NO"
 
# Doppelpunkt im Wert erzwingt Anführungszeichen
meldung: "Fehler: Datei nicht gefunden"
 
# Führende Null bleibt nur als String erhalten
modus: 0644          # kann als Zahl interpretiert werden
modus: "0644"        # sicher
 
# Mehrzeilig
skript: |            # Zeilenumbrüche bleiben erhalten
  #!/bin/bash
  echo "Hallo"

beschreibung: >      # Zeilenumbrüche werden zu Leerzeichen
  Dieser Text wird
  zu einer Zeile.


Der Dateimodus in Ansible sollte immer in Anführungszeichen stehen: mode: „0644“. Ohne Anführungszeichen kann YAML den Wert als Dezimalzahl lesen, was zu falschen Berechtigungen führt.


6.3 Editor-Unterstützung und Linting
pip install ansible-lint yamllint
 
yamllint playbook.yml
ansible-lint playbook.yml


Zusätzlich prüft Ansible selbst die Syntax, ohne etwas auszuführen:

ansible-playbook playbook.yml --syntax-check


Für vim empfiehlt sich set expandtab shiftwidth=2 softtabstop=2 in der ~/.vimrc, für VS Code die Erweiterung Ansible von Red Hat.



7. Das erste Playbook

7.1 Aufbau: Plays, Tasks, Module


Ein Playbook ist eine Liste von Plays. Jedes Play ordnet einer Hostgruppe eine Liste von Tasks zu. Jeder Task ruft genau ein Modul auf.

Playbook
 └─ Play        (welche Hosts?)
     └─ Task    (was soll passieren?)
         └─ Modul  (womit?)

7.2 Ein Paket installieren und einen Dienst starten

01-erstes-playbook.yml
---
- name: Grundkonfiguration der Testsysteme
  hosts: all
  become: true

  tasks:
    - name: Paket chrony installieren
      ansible.builtin.package:
        name: chrony
        state: present

    - name: Dienst chronyd starten und aktivieren
      ansible.builtin.service:
        name: "{{ 'chronyd' if ansible_facts['os_family'] == 'RedHat' else 'chrony' }}"
        state: started
        enabled: true



Schon im ersten Playbook zeigt sich der Distributionsunterschied: Der Dienst heißt unter RHEL chronyd, unter Ubuntu schlicht chrony. Kapitel 8 zeigt, wie man das sauberer löst als mit einem Inline-Ausdruck.


7.3 Playbook ausführen, --check und --diff
# Syntax prüfen
ansible-playbook 01-erstes-playbook.yml --syntax-check
 
# Probelauf ohne Änderungen (Dry Run)
ansible-playbook 01-erstes-playbook.yml --check --diff
 
# Tatsächlich ausführen
ansible-playbook 01-erstes-playbook.yml


–check ist die wichtigste Sicherheitsleine für Einsteiger. Ansible meldet, was es ändern würde, ohne es zu tun. Einschränkung: Die Module command und shell werden im Check-Modus standardmäßig übersprungen, und Tasks, die auf dem Ergebnis eines übersprungenen Tasks aufbauen, können dann fehlschlagen. Ein sauberer –check-Lauf ist also ein gutes Zeichen, aber keine Garantie.


7.4 Ausgabe lesen
PLAY [Grundkonfiguration der Testsysteme] **************************

TASK [Gathering Facts] ********************************************
ok: [rhel9]
ok: [ubuntu24]

TASK [Paket chrony installieren] **********************************
changed: [ubuntu24]
ok: [rhel9]

PLAY RECAP ********************************************************
rhel9      : ok=3  changed=0  unreachable=0  failed=0  skipped=0
ubuntu24   : ok=3  changed=1  unreachable=0  failed=0  skipped=0

	
	
		 Status  Bedeutung  Farbe 
	
	
	
		 ok  Zustand war bereits korrekt  grün 
	
	
		 changed  Ansible hat etwas verändert  gelb 
	
	
		 failed  Task fehlgeschlagen, Host scheidet aus  rot 
	
	
		 skipped  Bedingung nicht erfüllt  blau 
	
	
		 unreachable  Host nicht erreichbar  rot 
	


7.5 Idempotenz — das zentrale Konzept


Führe das Playbook ein zweites Mal aus. Das Ergebnis muss lauten:

rhel9      : ok=3  changed=0
ubuntu24   : ok=3  changed=0


Genau das ist Idempotenz: Ein Playbook beschreibt einen Zielzustand. Ist dieser erreicht, ändert ein erneuter Lauf nichts.



Merksatz: Ein Playbook, das bei jedem Lauf changed meldet, ist mit hoher Wahrscheinlichkeit fehlerhaft. Häufigste Ursache sind command- oder shell-Tasks, die keine Zustandsprüfung durchführen. Wie man das repariert, zeigt Kapitel 9.4 mit changed_when und creates.



Übung 7.1: Schreibe ein Playbook, das die Pakete vim, curl und git installiert. Führe es zweimal aus und prüfe, dass der zweite Lauf changed=0 meldet.



8. Variablen und Fakten

8.1 Variablen definieren
---
- name: Variablen-Demonstration
  hosts: all
  vars:
    paketname: tree
    zielverzeichnis: /opt/daten

  vars_files:
    - vars/allgemein.yml

  tasks:
    - name: Variable ausgeben
      ansible.builtin.debug:
        msg: "Paket {{ paketname }} nach {{ zielverzeichnis }}"


Von der Kommandozeile:

ansible-playbook playbook.yml -e "paketname=htop"
ansible-playbook playbook.yml -e "@vars/extra.yml"


Variablen werden in doppelten geschweiften Klammern referenziert. Steht eine Variable am Anfang eines Wertes, sind Anführungszeichen zwingend, sonst hält YAML die Klammer für den Beginn eines Dictionaries:



name: „paketname“ — richtig
name: paketname — Syntaxfehler


8.2 group_vars und host_vars


Die sauberste Methode: Variablen werden nach Gruppe bzw. Host in eigene Dateien ausgelagert. Ansible lädt diese Verzeichnisse automatisch, ohne dass man sie einbinden muss.

~/ansible-tutorial/
├── ansible.cfg
├── inventory.yml
├── group_vars/
│   ├── all.yml
│   ├── rhel.yml
│   └── ubuntu.yml
└── host_vars/
    └── rhel9.yml

group_vars/rhel.yml
---
webserver_paket:  httpd
webserver_dienst: httpd
webserver_konfig: /etc/httpd/conf.d/tutorial.conf
firewall_werkzeug: firewalld


group_vars/ubuntu.yml
---
webserver_paket:  apache2
webserver_dienst: apache2
webserver_konfig: /etc/apache2/conf-available/tutorial.conf
firewall_werkzeug: ufw



Damit wird aus dem unübersichtlichen Inline-Ausdruck aus Kapitel 7.2 ein lesbarer Task:

- name: Webserver installieren
  ansible.builtin.package:
    name: "{{ webserver_paket }}"
    state: present


Das ist das didaktische Herzstück dieses Tutorials. Nicht der Task kennt den Unterschied zwischen RHEL und Ubuntu, sondern die Variablendatei. Der Task selbst bleibt distributionsneutral und damit lesbar. Diese Trennung von Logik und Daten ist der wichtigste Qualitätssprung beim Übergang vom Skript zur Automatisierung.


8.3 Fakten sammeln und auswerten


Zu Beginn jedes Plays sammelt Ansible automatisch Informationen über die Zielsysteme — die Fakten.

ansible rhel9 -m ansible.builtin.setup
ansible rhel9 -m ansible.builtin.setup -a "filter=ansible_distribution*"


Wichtige Fakten für den Einstieg:


	
	
		 Faktum  RHEL 9  Ubuntu 24.04 
	
	
	
		 ansible_facts['os_family']  RedHat  Debian 
	
	
		 ansible_facts['distribution']  RedHat  Ubuntu 
	
	
		 ansible_facts['distribution_major_version']  9  24 
	
	
		 ansible_facts['pkg_mgr']  dnf  apt 
	
	
		 ansible_facts['service_mgr']  systemd  systemd 
	
	
		 ansible_facts['hostname]''  rhel9  ubuntu24 
	
	
		 ansible_facts['default_ipv4']['address']  192.168.56.11  192.168.56.12 
	



Das Sammeln kostet Zeit. Bei Plays, die keine Fakten brauchen, lässt es sich abschalten:

- name: Schnelles Play ohne Fakten
  hosts: all
  gather_facts: false

8.4 Distributionsunterschiede über Fakten abfangen
- name: Nur auf RHEL-Systemen
  ansible.builtin.dnf:
    name: policycoreutils-python-utils
    state: present
  when: ansible_facts['os_family'] == 'RedHat'

- name: Nur auf Debian-Systemen
  ansible.builtin.apt:
    name: ufw
    state: present
    update_cache: true
  when: ansible_facts['os_family'] == 'Debian'


**os_family statt distribution verwenden.** os_family liefert RedHat für RHEL, CentOS Stream, Rocky, AlmaLinux und Fedora — das Playbook funktioniert damit auf allen. distribution unterscheidet diese Systeme und macht die Bedingung unnötig eng.


8.5 Vorrangregeln der Variablen


Ist dieselbe Variable an mehreren Stellen definiert, gewinnt die speziellere. Ansible kennt 22 Ebenen; für den Einstieg genügt diese Reihenfolge von schwach nach stark:


 Rollen-Defaults (roles/x/defaults/main.yml)

 Inventory-Variablen

 group_vars/all

 group_vars/<gruppe>

 host_vars/<host>

 Play-Variablen (vars:)

 Task-Variablen

 –extra-vars auf der Kommandozeile — gewinnt immer




Praxisregel: Werte, die überschreibbar sein sollen, gehören in defaults. Werte, die nicht überschrieben werden dürfen, gehören in vars. Und wenn eine Variable sich unerklärlich verhält, hilft ansible-playbook playbook.yml -e „…“ -vvv oder ein debug-Task an der richtigen Stelle.



Übung 8.1: Lege group_vars/all.yml mit einer Variablen projekt_name an und gib sie in einem Playbook per debug aus. Überschreibe sie anschließend per -e und beobachte das Ergebnis.



9. Bedingungen, Schleifen und Handler

9.1 when — Tasks bedingt ausführen
# Einfache Bedingung
- name: EPEL nur auf RHEL
  ansible.builtin.dnf:
    name: epel-release
    state: present
  when: ansible_facts['os_family'] == 'RedHat'
 
# UND-Verknüpfung: Liste bedeutet AND
- name: Nur auf RHEL 9
  ansible.builtin.debug:
    msg: "RHEL 9 erkannt"
  when:
    - ansible_facts['os_family'] == 'RedHat'
    - ansible_facts['distribution_major_version'] == '9'
 
# ODER-Verknüpfung
  when: ansible_facts['os_family'] == 'RedHat' or ansible_facts['os_family'] == 'Debian'
 
# Variable prüfen
  when: webserver_paket is defined
  when: meine_liste | length > 0


In when stehen Variablen ohne geschweifte Klammern: when: os_family == „RedHat“, nicht when: „os_family == …“. Der Ausdruck wird bereits als Jinja2-Bedingung ausgewertet.


9.2 loop — Wiederholungen
# Einfache Liste
- name: Mehrere Pakete installieren
  ansible.builtin.package:
    name: "{{ item }}"
    state: present
  loop:
    - vim
    - curl
    - git
 
# Besser: das Modul kann die Liste selbst verarbeiten
- name: Mehrere Pakete in einer Transaktion
  ansible.builtin.package:
    name:
      - vim
      - curl
      - git
    state: present
 
# Liste von Dictionaries
- name: Benutzer anlegen
  ansible.builtin.user:
    name: "{{ item.name }}"
    groups: "{{ item.gruppe }}"
    state: present
  loop:
    - { name: andre,   gruppe: wheel }
    - { name: martina, gruppe: users }
  loop_control:
    label: "{{ item.name }}"


Bei Paketmodulen ist die zweite Variante deutlich schneller: Statt zehn einzelner dnf-Aufrufe gibt es eine einzige Transaktion. loop_control.label sorgt dafür, dass die Ausgabe nicht das ganze Dictionary zeigt, sondern nur den Namen.


9.3 Handler und notify


Ein Handler ist ein Task, der nur ausgeführt wird, wenn ein anderer Task etwas geändert hat — und zwar erst am Ende des Plays, und selbst dann nur einmal.

---
- name: Webserver konfigurieren
  hosts: webserver
  become: true

  tasks:
    - name: Konfigurationsdatei ausbringen
      ansible.builtin.template:
        src: tutorial.conf.j2
        dest: "{{ webserver_konfig }}"
        owner: root
        group: root
        mode: "0644"
      notify: Webserver neu laden

  handlers:
    - name: Webserver neu laden
      ansible.builtin.service:
        name: "{{ webserver_dienst }}"
        state: reloaded

 Der Name unter notify muss exakt dem Handler-Namen entsprechen.

 Ändern drei Tasks dieselbe Konfiguration, läuft der Handler trotzdem nur einmal.

 Handler laufen erst nach allen Tasks des Plays. Wird der Neustart früher gebraucht, erzwingt man ihn mit - ansible.builtin.meta: flush_handlers.

 Scheitert ein späterer Task, laufen die Handler standardmäßig nicht — –force-handlers ändert das.



9.4 Fehlerbehandlung
# Fehler ignorieren
- name: Optionaler Dienst
  ansible.builtin.service:
    name: irgendwas
    state: started
  ignore_errors: true
 
# Eigene Fehlerdefinition
- name: Prüfung ausführen
  ansible.builtin.command: /usr/local/bin/pruefung.sh
  register: ergebnis
  failed_when: "'FEHLER' in ergebnis.stdout"
 
# Idempotenz für command herstellen
- name: Reine Abfrage - meldet nie "changed"
  ansible.builtin.command: systemctl is-enabled sshd
  register: ssh_status
  changed_when: false
  failed_when: false
 
# Nur ausführen, wenn die Zieldatei fehlt
- name: Archiv einmalig entpacken
  ansible.builtin.command: tar xzf /tmp/app.tar.gz -C /opt
  args:
    creates: /opt/app/bin/start.sh
 
# Block mit Fehlerbehandlung
- name: Installation mit Aufräumen
  block:
    - name: Anwendung installieren
      ansible.builtin.package:
        name: meine-app
        state: present
  rescue:
    - name: Fehlerbehandlung
      ansible.builtin.debug:
        msg: "Installation fehlgeschlagen"
  always:
    - name: Temporäre Dateien entfernen
      ansible.builtin.file:
        path: /tmp/installation
        state: absent


changed_when: false bei reinen Abfragen ist die häufigste Korrektur, die Einsteiger-Playbooks brauchen. Ohne sie meldet jeder command-Task bei jedem Lauf changed — und die Idempotenz-Prüfung aus Kapitel 7.5 wird wertlos.


9.5 Tags zur selektiven Ausführung
tasks:
  - name: Pakete installieren
    ansible.builtin.package:
      name: "{{ webserver_paket }}"
      state: present
    tags:
      - installation
      - pakete

  - name: Konfiguration ausbringen
    ansible.builtin.template:
      src: tutorial.conf.j2
      dest: "{{ webserver_konfig }}"
      mode: "0644"
    tags:
      - konfiguration
ansible-playbook site.yml --tags konfiguration
ansible-playbook site.yml --skip-tags installation
ansible-playbook site.yml --list-tags


Übung 9.1: Erweitere das Playbook aus Übung 7.1 so, dass vim nur auf RHEL und neovim nur auf Ubuntu installiert wird.



10. Templates mit Jinja2

10.1 Das template-Modul im Vergleich zu copy

	
	
		 Modul  Einsatz 
	
	
	
		 copy  Datei wird unverändert übertragen 
	
	
		 template  Datei wird vor der Übertragung durch Jinja2 verarbeitet 
	



Templates liegen konventionell im Verzeichnis templates/ und tragen die Endung .j2.


10.2 Variablen, Bedingungen und Schleifen im Template

templates/tutorial.conf.j2
# {{ ansible_managed }}
# Erzeugt fuer {{ inventory_hostname }} am {{ ansible_date_time.date }}

ServerName {{ ansible_facts['fqdn'] }}
DocumentRoot {{ webserver_docroot | default('/var/www/html') }}

{% if ansible_facts['os_family'] == 'RedHat' %}
# RHEL: Module werden ueber conf.modules.d geladen
ErrorLog logs/tutorial_error.log
{% else %}
# Debian/Ubuntu: absolute Pfade
ErrorLog ${APACHE_LOG_DIR}/tutorial_error.log
{% endif %}

{% for netz in erlaubte_netze %}
# Freigabe fuer {{ netz }}
Require ip {{ netz }}
{% endfor %}



Zugehöriger Task:

- name: Konfiguration aus Template erzeugen
  ansible.builtin.template:
    src: tutorial.conf.j2
    dest: "{{ webserver_konfig }}"
    owner: root
    group: root
    mode: "0644"
    validate: "apachectl -t -f %s"
  notify: Webserver neu laden


ansible_managed erzeugt einen Kommentarhinweis, dass die Datei von Ansible verwaltet wird. Das erspart Kollegen die Frage, warum ihre manuelle Änderung beim nächsten Lauf verschwunden ist. validate prüft die erzeugte Datei, bevor sie an ihren Platz kopiert wird — eine fehlerhafte Konfiguration erreicht den Server damit gar nicht erst.


10.3 Kontrollstrukturen im Überblick

	
	
		 Syntax  Bedeutung 
	
	
	
		 ansible  Ausdruck wird ausgegeben 
	
	
		 {% … %}  Anweisung (if, for, set) — keine Ausgabe 
	
	
		 {# … #}  Kommentar, erscheint nicht in der Ausgabe 
	
	
		 {%- … -%}  Anweisung, entfernt umgebende Leerzeilen 
	


10.4 Filter und Defaults
{{ name | upper }}                      # Großbuchstaben
{{ pfad | basename }}                   # Dateiname aus Pfad
{{ wert | default('Standardwert') }}    # Ersatzwert
{{ wert | default('x', true) }}         # auch bei leerem String
{{ liste | join(', ') }}                # Liste zu Zeichenkette
{{ liste | length }}                    # Anzahl Elemente
{{ zahl | int }}                        # Typumwandlung
{{ daten | to_nice_json }}              # formatiertes JSON
{{ text | regex_replace('^a', 'b') }}   # Ersetzung
{{ pfad | dirname }}                    # Verzeichnisanteil


Der Filter default() ist das wichtigste Werkzeug für robuste Templates. Er verhindert, dass ein Playbook mit undefined variable abbricht, nur weil eine optionale Variable nicht gesetzt wurde.



Übung 10.1: Erstelle ein Template für /etc/motd, das Hostname, IP-Adresse, Distribution und Anzahl der CPU-Kerne ausgibt, und bringe es auf beiden Systemen aus.



11. Praxisbeispiel: Webserver auf RHEL und Ubuntu


Dieses Kapitel führt alles Bisherige zusammen. Ziel ist ein einziges Playbook, das auf beiden Distributionen einen funktionierenden Apache-Webserver mit geöffneter Firewall hinterlässt.


11.1 Die Unterschiede im Überblick

	
	
		 Aspekt  RHEL 9  Ubuntu 24.04 
	
	
	
		 Paket  httpd  apache2 
	
	
		 Dienst  httpd  apache2 
	
	
		 Konfigurationsverzeichnis  /etc/httpd/conf.d/  /etc/apache2/conf-available/ 
	
	
		 Hauptkonfiguration  /etc/httpd/conf/httpd.conf  /etc/apache2/apache2.conf 
	
	
		 DocumentRoot  /var/www/html  /var/www/html 
	
	
		 Benutzer des Dienstes  apache  www-data 
	
	
		 Firewall  firewalld  ufw 
	
	
		 Aktivierung von Konfigurationen  automatisch per conf.d  a2enconf nötig 
	
	
		 SELinux  aktiv (enforcing)  AppArmor, für Apache unkritisch 
	


11.2 Variablendateien

group_vars/all.yml
---
webserver_docroot: /var/www/html
webserver_port: 80
erlaubte_netze:
  - 192.168.56.0/24


group_vars/rhel.yml
---
webserver_paket:   httpd
webserver_dienst:  httpd
webserver_konfig:  /etc/httpd/conf.d/tutorial.conf
webserver_benutzer: apache


group_vars/ubuntu.yml
---
webserver_paket:   apache2
webserver_dienst:  apache2
webserver_konfig:  /etc/apache2/conf-available/tutorial.conf
webserver_benutzer: www-data


11.3 Das vollständige Playbook

11-webserver.yml
---
- name: Apache-Webserver auf RHEL und Ubuntu bereitstellen
  hosts: webserver
  become: true

  tasks:

    # ---------- Installation ----------

    - name: Paketcache unter Debian aktualisieren
      ansible.builtin.apt:
        update_cache: true
        cache_valid_time: 3600
      when: ansible_facts['os_family'] == 'Debian'

    - name: Webserver-Paket installieren
      ansible.builtin.package:
        name: "{{ webserver_paket }}"
        state: present
 
    # ---------- Inhalt und Konfiguration ----------

    - name: Startseite erzeugen
      ansible.builtin.template:
        src: index.html.j2
        dest: "{{ webserver_docroot }}/index.html"
        owner: root
        group: root
        mode: "0644"

    - name: Konfigurationsdatei ausbringen
      ansible.builtin.template:
        src: tutorial.conf.j2
        dest: "{{ webserver_konfig }}"
        owner: root
        group: root
        mode: "0644"
      notify: Webserver neu laden

    - name: Konfiguration unter Ubuntu aktivieren
      ansible.builtin.command: a2enconf tutorial
      args:
        creates: /etc/apache2/conf-enabled/tutorial.conf
      when: ansible_facts['os_family'] == 'Debian'
      notify: Webserver neu laden
 
    # ---------- SELinux (nur RHEL) ----------

    - name: SELinux-Werkzeuge installieren
      ansible.builtin.dnf:
        name: policycoreutils-python-utils
        state: present
      when: ansible_facts['os_family'] == 'RedHat'

    - name: SELinux-Kontext des DocumentRoot sicherstellen
      community.general.sefcontext:
        target: "{{ webserver_docroot }}(/.*)?"
        setype: httpd_sys_content_t
        state: present
      when:
        - ansible_facts['os_family'] == 'RedHat'
        - ansible_facts['selinux']['status'] == 'enabled'
      notify: SELinux-Kontext anwenden
 
    # ---------- Firewall ----------

    - name: Firewalld installieren und starten
      when: ansible_facts['os_family'] == 'RedHat'
      block:
        - name: firewalld sicherstellen
          ansible.builtin.dnf:
            name: firewalld
            state: present

        - name: firewalld starten
          ansible.builtin.service:
            name: firewalld
            state: started
            enabled: true

        - name: HTTP in firewalld freigeben
          ansible.posix.firewalld:
            service: http
            permanent: true
            immediate: true
            state: enabled

    - name: HTTP in ufw freigeben
      community.general.ufw:
        rule: allow
        port: "{{ webserver_port }}"
        proto: tcp
      when: ansible_facts['os_family'] == 'Debian'
 
    # ---------- Dienst ----------

    - name: Webserver starten und aktivieren
      ansible.builtin.service:
        name: "{{ webserver_dienst }}"
        state: started
        enabled: true
 
    # ---------- Verifikation ----------

    - name: Erreichbarkeit pruefen
      ansible.builtin.uri:
        url: "http://{{ ansible_facts['default_ipv4']['address'] }}/"
        status_code: 200
        return_content: true
      register: pruefung
      delegate_to: localhost
      become: false

    - name: Ergebnis anzeigen
      ansible.builtin.debug:
        msg: "{{ inventory_hostname }} antwortet mit Status {{ pruefung.status }}"

  handlers:

    - name: Webserver neu laden
      ansible.builtin.service:
        name: "{{ webserver_dienst }}"
        state: reloaded

    - name: SELinux-Kontext anwenden
      ansible.builtin.command: "restorecon -Rv {{ webserver_docroot }}"


templates/index.html.j2
<!DOCTYPE html>
<html lang="de">
<head><meta charset="utf-8"><title>{{ inventory_hostname }}</title></head>
<body>
  <h1>Willkommen auf {{ inventory_hostname }}</h1>
  <ul>
    <li>Distribution: {{ ansible_facts['distribution'] }}
        {{ ansible_facts['distribution_version'] }}</li>
    <li>Kernel: {{ ansible_facts['kernel'] }}</li>
    <li>CPU-Kerne: {{ ansible_facts['processor_vcpus'] }}</li>
    <li>Bereitgestellt am: {{ ansible_date_time.iso8601 }}</li>
  </ul>
</body>
</html>


11.4 Benötigte Collections


Die Module ansible.posix.firewalld, community.general.ufw und community.general.sefcontext sind nicht in ansible-core enthalten:

ansible-galaxy collection install ansible.posix community.general

11.5 Ausführen und prüfen
ansible-playbook 11-webserver.yml --check --diff
ansible-playbook 11-webserver.yml
ansible-playbook 11-webserver.yml      # zweiter Lauf: changed=0


Anschließend im Browser http://192.168.56.11/ und http://192.168.56.12/ aufrufen.



Wenn die Seite unter RHEL nicht erscheint, ist fast immer eine von drei Ursachen schuld: firewalld blockiert Port 80, SELinux verweigert den Zugriff auf den DocumentRoot, oder der Dienst läuft nicht. Diagnose auf dem Zielsystem:

sudo systemctl status httpd
sudo firewall-cmd --list-services
sudo ausearch -m AVC -ts recent


12. Rollen — Playbooks strukturieren

12.1 Wozu Rollen


Das Playbook aus Kapitel 11 ist bereits an der Grenze der Übersichtlichkeit. Rollen lösen drei Probleme: Wiederverwendbarkeit, Lesbarkeit und Teilbarkeit im Team.


12.2 Verzeichnisstruktur einer Rolle
ansible-galaxy init roles/webserver
roles/webserver/
├── defaults/main.yml    # Standardwerte, niedrigste Priorität
├── vars/main.yml        # feste Werte, hohe Priorität
├── tasks/main.yml       # Einstiegspunkt der Rolle
├── handlers/main.yml    # Handler
├── templates/           # Jinja2-Vorlagen
├── files/               # statische Dateien für copy
├── meta/main.yml        # Metadaten und Abhängigkeiten
└── README.md

	
	
		 Verzeichnis  Wird geladen  Priorität 
	
	
	
		 defaults/  automatisch  niedrig — zum Überschreiben gedacht 
	
	
		 vars/  automatisch  hoch — nicht zum Überschreiben gedacht 
	
	
		 tasks/  automatisch (main.yml)  — 
	
	
		 templates/  über template-Modul, ohne Pfadangabe  — 
	
	
		 files/  über copy-Modul, ohne Pfadangabe  — 
	


12.3 Distributionsabhängige Variablen in Rollen


Der elegante Standardweg, um in einer Rolle zwischen RHEL und Ubuntu zu unterscheiden:

roles/webserver/vars/
├── RedHat.yml
└── Debian.yml

roles/webserver/tasks/main.yml
---
- name: Distributionsspezifische Variablen laden
  ansible.builtin.include_vars: "{{ ansible_facts['os_family'] }}.yml"

- name: Webserver-Paket installieren
  ansible.builtin.package:
    name: "{{ webserver_paket }}"
    state: present

- name: Konfiguration ausbringen
  ansible.builtin.template:
    src: tutorial.conf.j2
    dest: "{{ webserver_konfig }}"
    mode: "0644"
  notify: Webserver neu laden

- name: Firewall konfigurieren
  ansible.builtin.include_tasks: "firewall-{{ ansible_facts['os_family'] }}.yml"

- name: Dienst sicherstellen
  ansible.builtin.service:
    name: "{{ webserver_dienst }}"
    state: started
    enabled: true



include_vars mit ansible_facts_os_family.yml ist ein Muster, das in praktisch jeder professionellen Rolle vorkommt. Neue Distributionen werden unterstützt, indem eine weitere Variablendatei hinzukommt — der Task-Code bleibt unverändert.


12.4 Rollen einbinden

site.yml
---
- name: Webserver bereitstellen
  hosts: webserver
  become: true
  roles:
    - role: basis
    - role: webserver
      vars:
        webserver_port: 8080



Alternativ dynamisch innerhalb der Task-Liste:

tasks:
  - name: Webserver-Rolle bedingt einbinden
    ansible.builtin.include_role:
      name: webserver
    when: inventory_hostname in groups['webserver']

	
	
		 Variante  Zeitpunkt  Besonderheit 
	
	
	
		 roles:  statisch, vor allen Tasks  Tags vererben sich auf alle Tasks 
	
	
		 import_role  statisch, an der Stelle  zur Übersetzungszeit aufgelöst 
	
	
		 include_role  dynamisch, zur Laufzeit  when wirkt auf die ganze Rolle 
	


12.5 Ansible Galaxy und Collections
# Suchen und installieren
ansible-galaxy collection install community.general
ansible-galaxy role install geerlingguy.apache
 
# Installiertes anzeigen
ansible-galaxy collection list
 
# Abhängigkeiten deklarieren
ansible-galaxy collection install -r requirements.yml

requirements.yml
---
collections:
  - name: ansible.posix
  - name: community.general

roles:
  - name: geerlingguy.apache
    version: "3.2.0"



Vollqualifizierte Modulnamen (FQCN) wie ansible.builtin.package statt nur package sind seit Ansible 2.10 die empfohlene Schreibweise. Sie machen eindeutig, aus welcher Collection ein Modul stammt — wichtig, seit mehrere Collections gleichnamige Module enthalten können.



Übung 12.1: Überführe das Playbook aus Kapitel 11 in eine Rolle webserver mit vars/RedHat.yml und vars/Debian.yml. Das aufrufende site.yml sollte danach nur noch wenige Zeilen umfassen.



13. Geheimnisse schützen mit Ansible Vault

13.1 Verschlüsselte Dateien und Variablen anlegen
# Neue verschlüsselte Datei anlegen
ansible-vault create group_vars/all/vault.yml
 
# Bestehende Datei verschlüsseln
ansible-vault encrypt secrets.yml
 
# Bearbeiten (entschlüsselt nur im Editor)
ansible-vault edit group_vars/all/vault.yml
 
# Anzeigen
ansible-vault view group_vars/all/vault.yml
 
# Passwort ändern
ansible-vault rekey group_vars/all/vault.yml


Einzelne Werte lassen sich auch inline verschlüsseln:

ansible-vault encrypt_string 'GeheimesPasswort' --name 'db_passwort'


Das Ergebnis wird direkt in eine normale YAML-Datei eingefügt:

---
db_benutzer: app
db_passwort: !vault |
          $ANSIBLE_VAULT;1.1;AES256
          38396437653...

13.2 Passwortdateien und Vault-IDs
echo "MeinVaultPasswort" > ~/.vault_pass
chmod 600 ~/.vault_pass

ansible.cfg
[defaults]
vault_password_file = ~/.vault_pass



Mehrere Vaults für verschiedene Umgebungen:

ansible-vault encrypt --vault-id prod@~/.vault_prod secrets_prod.yml
ansible-playbook site.yml --vault-id prod@~/.vault_prod

13.3 Playbooks mit Vault ausführen
ansible-playbook site.yml --ask-vault-pass
ansible-playbook site.yml --vault-password-file ~/.vault_pass


Die Passwortdatei gehört niemals ins Git-Repository. Ein passender .gitignore-Eintrag:

.vault_pass
*.retry


Eine bewährte Konvention ist die Trennung in eine unverschlüsselte vars.yml mit sprechenden Variablennamen und eine verschlüsselte vault.yml, die die eigentlichen Werte unter dem Präfix vault_ enthält. So bleibt im Klartext sichtbar, welche Geheimnisse existieren, ohne ihren Inhalt preiszugeben.



14. Gute Praxis für den Einstieg

14.1 Verzeichnisstruktur eines Projekts
ansible-projekt/
├── ansible.cfg
├── requirements.yml
├── .gitignore
├── inventories/
│   ├── test/
│   │   ├── hosts.yml
│   │   ├── group_vars/
│   │   └── host_vars/
│   └── prod/
│       ├── hosts.yml
│       └── group_vars/
├── roles/
│   ├── basis/
│   └── webserver/
├── playbooks/
│   ├── site.yml
│   └── webserver.yml
└── templates/
ansible-playbook -i inventories/test playbooks/site.yml

14.2 Versionierung mit Git


Ansible-Code ist Code und gehört in ein Repository. Der praktische Nutzen:


 Jede Konfigurationsänderung ist nachvollziehbar — inklusive Autor und Begründung.

 Ein fehlerhaftes Playbook lässt sich zurückrollen.

 Für regulierte Umgebungen liefert die Historie einen belastbaren Änderungsnachweis.



14.3 Namenskonventionen und Lesbarkeit

 **Jeder Task bekommt ein name:** — es erscheint in der Ausgabe und ist die Dokumentation zur Laufzeit.

 Namen beschreiben das Ziel, nicht das Modul: „Webserver-Paket installieren“, nicht „dnf ausführen“.

 Variablennamen in Kleinbuchstaben mit Unterstrich, mit Rollenpräfix: webserver_port statt port.

 FQCN verwenden: ansible.builtin.copy statt copy.

 Booleans einheitlich als true/false.



14.4 Häufige Anfängerfehler

	
	
		 Fehler  Symptom  Lösung 
	
	
	
		 Tabulatoren in YAML  found character \t  nur Leerzeichen verwenden 
	
	
		 Fehlende Anführungszeichen bei  am Zeilenanfang  Syntaxfehler  name: „var“ 
	
	
		  in when  Warnung, unerwartetes Verhalten  Klammern weglassen 
	
	
		 shell statt command  unnötiges Sicherheitsrisiko  command bevorzugen 
	
	
		 command ohne changed_when  immer changed  changed_when: false 
	
	
		 mode: 0644 ohne Anführungszeichen  falsche Berechtigungen  mode: „0644“ 
	
	
		 become vergessen  Permission denied  become: true im Play 
	
	
		 Handler-Name stimmt nicht  Handler läuft nie  Namen exakt abgleichen 
	
	
		 Produktivsystem ohne –check  ungewollte Änderungen  erst Dry Run 
	
	
		 Passwörter im Klartext  Sicherheitsvorfall  Ansible Vault 
	


14.5 Fehlersuche
# Ausgabestufen: mehr v = mehr Details
ansible-playbook site.yml -v      # Ergebnisse der Tasks
ansible-playbook site.yml -vvv    # inkl. SSH-Kommandos
ansible-playbook site.yml -vvvv   # inkl. Verbindungsdebug
 
# Nur bestimmte Hosts
ansible-playbook site.yml --limit rhel9
 
# Ab einem bestimmten Task starten
ansible-playbook site.yml --start-at-task "Konfiguration ausbringen"
 
# Schrittweise mit Bestätigung
ansible-playbook site.yml --step
 
# Was wird ausgeführt?
ansible-playbook site.yml --list-tasks
ansible-playbook site.yml --list-hosts


Das nützlichste Diagnosewerkzeug im Playbook selbst:

- name: Zwischenergebnis anzeigen
  ansible.builtin.debug:
    var: ergebnis

- name: Alle Fakten eines Hosts anzeigen
  ansible.builtin.debug:
    var: ansible_facts


15. Ausblick

15.1 Ansible Automation Platform / AWX


Sobald mehrere Personen automatisieren, reicht die Kommandozeile nicht mehr. AWX (Open Source) bzw. die Red Hat Ansible Automation Platform (unterstützt) ergänzen:


 Weboberfläche und REST-API

 rollenbasierte Rechtevergabe

 zentrale Verwaltung von Zugangsdaten

 Zeitpläne und Job-Historie

 revisionssichere Protokollierung — in regulierten Umgebungen oft der ausschlaggebende Punkt



15.2 Dynamische Inventories


Statische Inventory-Dateien werden in Cloud-Umgebungen schnell unbrauchbar. Dynamische Inventory-Plugins fragen die Quelle direkt ab:


inventory_azure.yml
---
plugin: azure.azcollection.azure_rm
include_vm_resource_groups:
  - produktion
keyed_groups:
  - key: tags.rolle
    prefix: rolle



Verfügbar unter anderem für Azure, AWS EC2, VMware, OpenStack, Proxmox und Red Hat Satellite.


15.3 Weiterführende Themen

 Testen: Molecule für automatisierte Rollentests

 CI/CD: ansible-lint und Playbook-Läufe in GitLab CI oder GitHub Actions

 Sicherheit: die rhel-system-roles bzw. linux-system-roles, unter anderem für SSH-Härtung, Zeitsynchronisation und Firewall

 Zertifizierung: Red Hat EX294 (RHCE) prüft genau die hier behandelten Themen

 Dokumentation: ansible-doc <modul> liefert offline eine vollständige Modulbeschreibung mit Beispielen — oft schneller als die Websuche




Anhang

A. Modul-Übersicht für den Einstieg

	
	
		 Modul  Zweck 
	
	
	
		 ansible.builtin.package  Pakete distributionsneutral verwalten 
	
	
		 ansible.builtin.dnf / .apt  Pakete distributionsspezifisch verwalten 
	
	
		 ansible.builtin.service / .systemd  Dienste steuern 
	
	
		 ansible.builtin.copy  Datei unverändert übertragen 
	
	
		 ansible.builtin.template  Datei aus Jinja2-Vorlage erzeugen 
	
	
		 ansible.builtin.file  Dateien, Verzeichnisse, Links, Rechte 
	
	
		 ansible.builtin.lineinfile  einzelne Zeile in Datei sicherstellen 
	
	
		 ansible.builtin.blockinfile  Textblock in Datei verwalten 
	
	
		 ansible.builtin.user / .group  Benutzer und Gruppen 
	
	
		 ansible.builtin.command / .shell  Befehle ausführen 
	
	
		 ansible.builtin.debug  Werte ausgeben 
	
	
		 ansible.builtin.setup  Fakten sammeln 
	
	
		 ansible.builtin.uri  HTTP-Aufrufe und Prüfungen 
	
	
		 ansible.builtin.git  Repositories auschecken 
	
	
		 ansible.builtin.cron  Cronjobs verwalten 
	
	
		 ansible.builtin.mount  Dateisysteme einhängen 
	
	
		 ansible.posix.firewalld  firewalld (RHEL) 
	
	
		 community.general.ufw  ufw (Ubuntu) 
	
	
		 ansible.posix.seboolean  SELinux-Booleans 
	


B. Befehls-Spickzettel
# --- Prüfen ---
ansible --version
ansible-inventory --graph
ansible all -m ansible.builtin.ping
ansible-playbook site.yml --syntax-check
ansible-playbook site.yml --list-tasks
 
# --- Ausführen ---
ansible-playbook site.yml
ansible-playbook site.yml --check --diff
ansible-playbook site.yml --limit rhel9
ansible-playbook site.yml --tags konfiguration
ansible-playbook site.yml -e "variable=wert"
ansible-playbook site.yml --start-at-task "Name"
ansible-playbook site.yml -b -K          # sudo mit Passwortabfrage
 
# --- Ad-hoc ---
ansible all -m ansible.builtin.command -a "uptime"
ansible all -m ansible.builtin.setup -a "filter=ansible_distribution*"
 
# --- Dokumentation ---
ansible-doc -l
ansible-doc ansible.builtin.package
ansible-doc -s ansible.builtin.service   # nur Beispiel-Snippet
 
# --- Vault ---
ansible-vault create   secrets.yml
ansible-vault edit     secrets.yml
ansible-vault encrypt_string 'wert' --name 'variable'
 
# --- Galaxy ---
ansible-galaxy collection install community.general
ansible-galaxy init roles/meine-rolle
ansible-galaxy collection list

C. Gegenüberstellung RHEL ↔ Ubuntu

	
	
		 Bereich  RHEL 9  Ubuntu 24.04 
	
	
	
		 Paketmanager  dnf  apt 
	
	
		 Ansible-Faktum os_family  RedHat  Debian 
	
	
		 Webserver-Paket  httpd  apache2 
	
	
		 Webserver-Dienst  httpd  apache2 
	
	
		 Webserver-Benutzer  apache  www-data 
	
	
		 Webserver-Konfiguration  /etc/httpd/  /etc/apache2/ 
	
	
		 NTP-Dienst  chronyd  chrony 
	
	
		 SSH-Dienst  sshd  ssh 
	
	
		 MariaDB-Paket  mariadb-server  mariadb-server 
	
	
		 Firewall  firewalld  ufw 
	
	
		 Mandatory Access Control  SELinux  AppArmor 
	
	
		 Repositorydefinition  /etc/yum.repos.d/  /etc/apt/sources.list.d/ 
	
	
		 Netzwerkkonfiguration  NetworkManager  netplan 
	
	
		 Paketcache aktualisieren  automatisch  update_cache: true nötig 
	
	
		 Logdateien Apache  /var/log/httpd/  /var/log/apache2/ 
	


D. Lösungshinweise zu den Übungen


Übung 5.1 — Kernel-Version aller Hosts:

ansible all -m ansible.builtin.setup -a "filter=ansible_kernel"


Übung 7.1 — Idempotente Paketinstallation:

---
- name: Werkzeuge installieren
  hosts: all
  become: true
  tasks:
    - name: Basiswerkzeuge sicherstellen
      ansible.builtin.package:
        name:
          - vim
          - curl
          - git
        state: present


Übung 9.1 — Distributionsabhängiger Editor:

- name: vim auf RHEL
  ansible.builtin.dnf:
    name: vim-enhanced
    state: present
  when: ansible_facts['os_family'] == 'RedHat'

- name: neovim auf Ubuntu
  ansible.builtin.apt:
    name: neovim
    state: present
    update_cache: true
  when: ansible_facts['os_family'] == 'Debian'


Übung 10.1 — motd-Template:


templates/motd.j2
{{ ansible_managed }}
------------------------------------------------------------
 Host        : {{ ansible_facts['fqdn'] }}
 IP-Adresse  : {{ ansible_facts['default_ipv4']['address'] }}
 System      : {{ ansible_facts['distribution'] }} {{ ansible_facts['distribution_version'] }}
 Kernel      : {{ ansible_facts['kernel'] }}
 CPU-Kerne   : {{ ansible_facts['processor_vcpus'] }}
 Speicher    : {{ ansible_facts['memtotal_mb'] }} MB
------------------------------------------------------------




Ende des Tutorials.

Option	Wirkung
`inventory`	Standard-Inventory, spart `-i` bei jedem Aufruf
`remote_user`	Benutzer für die SSH-Anmeldung
`host_key_checking`	`False` vermeidet Rückfragen bei neuen Hosts — nur in Testumgebungen!
`interpreter_python`	unterdrückt Warnungen zur Interpreter-Erkennung
`stdout_callback = yaml`	macht die Ausgabe deutlich besser lesbar

Meldung	Ursache
`Permission denied (publickey,password)`	SSH-Schlüssel nicht verteilt oder falscher `remote_user`
`Failed to connect … No route to host`	Netzwerk/Firewall
`/usr/bin/python3: not found`	kein Python auf dem Ziel
`Missing sudo password`	`become` ohne NOPASSWD-Regel

Bestandteil	Bedeutung
`<muster>`	Host, Gruppe oder Muster (`all`, `rhel`, `web*`, `rhel:!rhel9`)
`-m`	Modul (Standard ist `command`)
`-a`	Argumente für das Modul
`-b`	Kurzform für `–become`

Modul	Einsatz
`copy`	Datei wird unverändert übertragen
`template`	Datei wird vor der Übertragung durch Jinja2 verarbeitet

Aspekt	RHEL 9	Ubuntu 24.04
Paket	`httpd`	`apache2`
Dienst	`httpd`	`apache2`
Konfigurationsverzeichnis	`/etc/httpd/conf.d/`	`/etc/apache2/conf-available/`
Hauptkonfiguration	`/etc/httpd/conf/httpd.conf`	`/etc/apache2/apache2.conf`
DocumentRoot	`/var/www/html`	`/var/www/html`
Benutzer des Dienstes	`apache`	`www-data`
Firewall	`firewalld`	`ufw`
Aktivierung von Konfigurationen	automatisch per `conf.d`	`a2enconf` nötig
SELinux	aktiv (enforcing)	AppArmor, für Apache unkritisch

Methode	Vorteil	Nachteil
Distributionspaket	integriert, gepatcht	oft ältere Version
PPA / EPEL	aktueller	zusätzliche Fremdquelle
pip in venv	volle Versionskontrolle	Pflege liegt beim Benutzer

Status	Bedeutung	Farbe
`ok`	Zustand war bereits korrekt	grün
`changed`	Ansible hat etwas verändert	gelb
`failed`	Task fehlgeschlagen, Host scheidet aus	rot
`skipped`	Bedingung nicht erfüllt	blau
`unreachable`	Host nicht erreichbar	rot

Faktum	RHEL 9	Ubuntu 24.04
`ansible_facts['os_family']`	RedHat	Debian
`ansible_facts['distribution']`	RedHat	Ubuntu
`ansible_facts['distribution_major_version']`	9	24
`ansible_facts['pkg_mgr']`	dnf	apt
`ansible_facts['service_mgr']`	systemd	systemd
`ansible_facts['hostname`]''	rhel9	ubuntu24
`ansible_facts['default_ipv4']['address']`	192.168.56.11	192.168.56.12

Syntax	Bedeutung
`ansible`	Ausdruck wird ausgegeben
`{% … %}`	Anweisung (if, for, set) — keine Ausgabe
`{# … #}`	Kommentar, erscheint nicht in der Ausgabe
`{%- … -%}`	Anweisung, entfernt umgebende Leerzeilen

Verzeichnis	Wird geladen	Priorität
`defaults/`	automatisch	niedrig — zum Überschreiben gedacht
`vars/`	automatisch	hoch — nicht zum Überschreiben gedacht
`tasks/`	automatisch (`main.yml`)	—
`templates/`	über `template`-Modul, ohne Pfadangabe	—
`files/`	über `copy`-Modul, ohne Pfadangabe	—

Variante	Zeitpunkt	Besonderheit
`roles:`	statisch, vor allen Tasks	Tags vererben sich auf alle Tasks
`import_role`	statisch, an der Stelle	zur Übersetzungszeit aufgelöst
`include_role`	dynamisch, zur Laufzeit	`when` wirkt auf die ganze Rolle

Fehler	Symptom	Lösung
Tabulatoren in YAML	`found character \t`	nur Leerzeichen verwenden
Fehlende Anführungszeichen bei am Zeilenanfang	Syntaxfehler	`name: „var“`
in `when`	Warnung, unerwartetes Verhalten	Klammern weglassen
`shell` statt `command`	unnötiges Sicherheitsrisiko	`command` bevorzugen
`command` ohne `changed_when`	immer `changed`	`changed_when: false`
`mode: 0644` ohne Anführungszeichen	falsche Berechtigungen	`mode: „0644“`
`become` vergessen	`Permission denied`	`become: true` im Play
Handler-Name stimmt nicht	Handler läuft nie	Namen exakt abgleichen
Produktivsystem ohne `–check`	ungewollte Änderungen	erst Dry Run
Passwörter im Klartext	Sicherheitsvorfall	Ansible Vault

Modul	Zweck
`ansible.builtin.package`	Pakete distributionsneutral verwalten
`ansible.builtin.dnf` / `.apt`	Pakete distributionsspezifisch verwalten
`ansible.builtin.service` / `.systemd`	Dienste steuern
`ansible.builtin.copy`	Datei unverändert übertragen
`ansible.builtin.template`	Datei aus Jinja2-Vorlage erzeugen
`ansible.builtin.file`	Dateien, Verzeichnisse, Links, Rechte
`ansible.builtin.lineinfile`	einzelne Zeile in Datei sicherstellen
`ansible.builtin.blockinfile`	Textblock in Datei verwalten
`ansible.builtin.user` / `.group`	Benutzer und Gruppen
`ansible.builtin.command` / `.shell`	Befehle ausführen
`ansible.builtin.debug`	Werte ausgeben
`ansible.builtin.setup`	Fakten sammeln
`ansible.builtin.uri`	HTTP-Aufrufe und Prüfungen
`ansible.builtin.git`	Repositories auschecken
`ansible.builtin.cron`	Cronjobs verwalten
`ansible.builtin.mount`	Dateisysteme einhängen
`ansible.posix.firewalld`	firewalld (RHEL)
`community.general.ufw`	ufw (Ubuntu)
`ansible.posix.seboolean`	SELinux-Booleans

Bereich	RHEL 9	Ubuntu 24.04
Paketmanager	dnf	apt
Ansible-Faktum `os_family`	RedHat	Debian
Webserver-Paket	httpd	apache2
Webserver-Dienst	httpd	apache2
Webserver-Benutzer	apache	www-data
Webserver-Konfiguration	/etc/httpd/	/etc/apache2/
NTP-Dienst	chronyd	chrony
SSH-Dienst	sshd	ssh
MariaDB-Paket	mariadb-server	mariadb-server
Firewall	firewalld	ufw
Mandatory Access Control	SELinux	AppArmor
Repositorydefinition	/etc/yum.repos.d/	/etc/apt/sources.list.d/
Netzwerkkonfiguration	NetworkManager	netplan
Paketcache aktualisieren	automatisch	`update_cache: true` nötig
Logdateien Apache	/var/log/httpd/	/var/log/apache2/