Alle Beiträge
AnsibleAutomatisierungLinuxDevOps

Ansible 2026: Server automatisieren – der Einstieg in 15 Minuten

Zehn Server von Hand einrichten? Muss nicht sein. Mit Ansible beschreibst du einmal, wie ein System aussehen soll, und Ansible sorgt überall dafür. Was das neue ansible-core 2.22 bringt und wie du in 15 Minuten dein erstes Playbook schreibst.

NAND
NAND

15. November 2026

Ein neuer Server soll laufen: Updates einspielen, Benutzer anlegen, Webserver installieren, Firewall konfigurieren. Beim ersten Mal dauert das eine Stunde. Beim zehnten Mal ist es langweilig. Und beim zwanzigsten Mal hast du garantiert einen Schritt vergessen.

Genau hier kommt Ansible ins Spiel.

Was ist Ansible?

Ansible ist ein Open-Source-Werkzeug zur Automatisierung von IT-Aufgaben. Statt Befehle von Hand einzutippen, beschreibst du in einer einfachen Textdatei (YAML), wie ein System aussehen soll. Ansible verbindet sich dann per SSH (bei Windows per WinRM oder SSH) mit deinen Servern und sorgt dafür, dass dieser Zustand erreicht wird.

Drei Dinge machen Ansible so beliebt:

  • Agentenlos: Auf den Zielsystemen muss nichts installiert werden. SSH und Python reichen.
  • Lesbar: Playbooks lesen sich fast wie eine Checkliste. Auch Kolleginnen und Kollegen ohne Programmiererfahrung verstehen, was passiert.
  • Idempotent: Du kannst ein Playbook beliebig oft ausführen. Ansible ändert nur, was noch nicht stimmt. Ist schon alles korrekt, passiert nichts.

Was ist neu?

Ganz frisch: ansible-core 2.22 (2. November 2026)
Die neue Version mit dem Spitznamen «Thank You» bringt vor allem mehr Sicherheit:

  • Geheimnisse werden automatisch maskiert. Bekannte geheime Werte erscheinen in der Ausgabe, in Logs und in Ergebnissen nur noch als $REDACTED$. Dazu gehören Vault-Passwörter, sudo-Passwörter, SSH- und WinRM-Zugangsdaten sowie Werte mit no_log. Die Tasks selbst arbeiten weiterhin mit den echten Werten.
  • Weniger Datenlecks bei der Fehlersuche: Auch bei hoher Ausführlichkeit (-vvv) zeigen SSH und WinRM keine rohe Befehlsausgabe mehr, sondern nur noch den Rückgabecode.
  • Python: Neu wird Python 3.15 unterstützt. Auf dem Steuerrechner braucht ansible-core 2.22 jetzt mindestens Python 3.13.

Achtung, Update-Pflicht: Mit dem Erscheinen von 2.22 endet der Support für ansible-core 2.19 am 30. November 2026. Wer noch 2.19 oder älter nutzt, sollte jetzt aktualisieren.

Ansible 14 und PowerShell 7
Das Community-Paket Ansible 14 (mit ansible-core 2.21, erschienen im Juni 2026) ist die aktuelle «Komplettversion» mit allen Collections. Seit 2.21 unterstützt Ansible auf Windows-Zielsystemen neben Windows PowerShell 5.1 auch das jeweils aktuelle PowerShell 7 LTS.

KI trifft Automatisierung
Red Hat baut Ansible gerade zur «Ausführungsschicht» für KI-Agenten um. In der kommerziellen Ansible Automation Platform 2.7 (Juni 2026) gibt es einen MCP-Server: KI-Werkzeuge wie Claude, Cursor oder ChatGPT können damit in natürlicher Sprache Jobs abfragen, Fakten sammeln oder Workflows starten. Der KI-Code-Assistent (früher «Ansible Lightspeed») unterstützt inzwischen auch weitere Modelle.

Die Idee dahinter: Die KI entscheidet, was getan werden soll. Ausgeführt wird es über geprüfte, vorhersehbare Playbooks. Genau deshalb lohnt es sich gerade jetzt, Ansible zu lernen.

Dein erstes Playbook in 15 Minuten

1. Ansible installieren

Ansible läuft auf Linux und macOS. Unter Windows nutzt du WSL (Windows Subsystem for Linux). Empfohlen ist die Installation mit pipx. Das Paket ansible enthält ansible-core plus viele fertige Collections:

# macOS
brew install pipx
pipx ensurepath

# Ubuntu / Debian
sudo apt install pipx
pipx ensurepath

# Ansible installieren (neues Terminal öffnen)
pipx install --include-deps ansible
ansible --version

2. Inventar anlegen: Welche Server gibt es?

Erstelle eine Datei inventory.ini:

[webserver]
web1 ansible_host=192.168.1.20
web2 ansible_host=192.168.1.21

[webserver:vars]
ansible_user=admin

Teste die Verbindung (dein SSH-Schlüssel muss auf den Servern hinterlegt sein):

ansible webserver -i inventory.ini -m ansible.builtin.ping

Antworten beide Server mit "ping": "pong", kann es losgehen.

3. Das Playbook: Was soll passieren?

Erstelle webserver.yml. Dieses Playbook installiert nginx, legt eine Startseite ab und sorgt dafür, dass der Dienst läuft:

- name: Webserver einrichten
  hosts: webserver
  become: true

  tasks:
    - name: Nginx installieren
      ansible.builtin.apt:
        name: nginx
        state: present
        update_cache: true
        cache_valid_time: 3600

    - name: Startseite ablegen
      ansible.builtin.copy:
        content: "<h1>Hallo von {{ inventory_hostname }}</h1>\n"
        dest: /var/www/html/index.html
        mode: "0644"
      notify: Nginx neu laden

    - name: Nginx läuft und startet beim Booten
      ansible.builtin.service:
        name: nginx
        state: started
        enabled: true

  handlers:
    - name: Nginx neu laden
      ansible.builtin.service:
        name: nginx
        state: reloaded

Kurz erklärt:

Begriff Bedeutung
hosts Auf welche Gruppe aus dem Inventar das Playbook wirkt
become: true Aufgaben mit Admin-Rechten (sudo) ausführen
tasks Die einzelnen Schritte, von oben nach unten
state: present «Paket soll installiert sein», nicht «installiere jetzt»
notify / handlers Wird nur ausgelöst, wenn sich etwas geändert hat
{{ inventory_hostname }} Variable: der Name des jeweiligen Servers

4. Erst testen, dann ausführen

# Trockenlauf: zeigt, was sich ändern WÜRDE
ansible-playbook -i inventory.ini webserver.yml --check --diff

# Jetzt wirklich ausführen
ansible-playbook -i inventory.ini webserver.yml

Am Ende siehst du die Zusammenfassung PLAY RECAP. Beim ersten Lauf steht bei changed eine Zahl grösser als 0, denn Ansible hat etwas verändert. Führe das Playbook gleich nochmals aus: Jetzt steht changed=0. Das ist Idempotenz in Aktion. Ansible hat geprüft, alles stimmt bereits, und nichts angefasst.

5 Profi-Tipps für den Alltag

  1. Immer den vollen Modulnamen verwenden, also ansible.builtin.copy statt nur copy. Das ist eindeutig und zukunftssicher.
  2. Geheimnisse nie im Klartext speichern. Passwörter und API-Schlüssel gehören in eine verschlüsselte Datei:
    ansible-vault create secrets.yml
    ansible-playbook webserver.yml --ask-vault-pass
    
  3. Vor jedem Lauf --check --diff – vor allem auf Produktivsystemen.
  4. Code prüfen lassen mit ansible-lint (pipx install ansible-lint). Das Werkzeug findet Fehler und schlechte Gewohnheiten, bevor sie Probleme machen.
  5. Alles in Git. Playbooks sind Code. Versionierung macht Änderungen nachvollziehbar und rückgängig machbar.

Sicherheitstipp: Gerade weil KI-Agenten bald Playbooks auslösen können, gilt: Gib Automatisierungs-Konten nur die Rechte, die sie wirklich brauchen, und protokolliere jede Ausführung.

Wie geht es weiter?

Wenn dein erstes Playbook läuft, sind das die nächsten Schritte:

  • Rollen: Playbooks in wiederverwendbare Bausteine aufteilen (ansible-galaxy role init)
  • Templates (Jinja2): Konfigurationsdateien mit Variablen erzeugen
  • Collections: fertige Module für Windows, Cisco, Fortinet, AWS, Azure und vieles mehr
  • Windows automatisieren: Benutzer, Updates und Dienste per Playbook verwalten

Fazit

Ansible ist 2026 aktueller denn je: Es ist der einfachste Einstieg in Infrastructure as Code, und mit dem Trend zu KI-gesteuerten IT-Abläufen wird es zur Brücke zwischen «die KI schlägt etwas vor» und «es passiert sicher und nachvollziehbar». Wer heute Server, Netzwerke oder Cloud betreut, spart mit Ansible jede Woche Stunden.

Du willst tiefer einsteigen? Bei Knowledge Forge sind Kurse zu Ansible, Linux und Automatisierung in Vorbereitung. Bis dahin legst du mit Netzwerke für Einsteiger das Fundament, denn ohne Netzwerkwissen keine Automatisierung.


Quellen

Stand: 15. November 2026.