Claude Code Ansible: Playbooks, Rollen und Vault mit KI-Unterstützung

Ansible ist eines der mächtigsten Werkzeuge in der IT-Automatisierung — und gleichzeitig eines, bei dem die Lernkurve steiler ist als sie wirkt. YAML liest sich schnell, aber idempotente Playbooks schreiben, Rollen sauber strukturieren, Vault-Geheimnisse sicher verwalten: das kostet Zeit. Claude Code Ansible schließt diese Lücke: nicht durch Abstraktion, sondern durch direkten Support beim Schreiben, Prüfen und Refactoring von Ansible-Code.

Dieser Artikel zeigt, wie das konkret aussieht — von der ersten Inventardatei bis zur produktionsreifen Rolle mit Vault-Integration.

1. Was ist Ansible — und warum Idempotenz entscheidend ist

Ansible ist ein agentless IT-Automatisierungs-Tool: kein Daemon auf den Zielrechnern, keine permanente Verbindung, kein Client-Install. Der Control Node verbindet sich per SSH, führt die definierten Tasks aus und trennt die Verbindung wieder. Die Konfiguration liegt in YAML-Playbooks — menschenlesbar, versionierbar, reproduzierbar.

Das zentrale Konzept ist Idempotenz: ein Playbook kann beliebig oft ausgeführt werden und produziert immer denselben Endzustand. Ist ein Paket bereits installiert, installiert Ansible es nicht nochmal — es prüft, stellt fest, dass der gewünschte Zustand bereits erreicht ist, und überspringt den Task. Das ist der Unterschied zu einem Shell-Skript, das bei jedem Lauf blind ausführt.

2. Inventar: Hosts, Gruppen und Variablen organisieren

Das Inventar ist die Karte deiner Infrastruktur. Die einfachste Form ist eine INI-Datei, produktionsreif ist aber ein Verzeichnis mit klaren Gruppen:

# inventory/hosts
[webserver]
web1.example.com
web2.example.com

[database]
db1.example.com

[production:children]
webserver
database

Variablen gehören nicht direkt in die Hosts-Datei, sondern in dedizierte Verzeichnisse: host_vars/web1.example.com/main.yml für hostspezifische Werte, group_vars/webserver/main.yml für alle Hosts einer Gruppe. Diese Trennung hält das Inventar lesbar — auch wenn die Infrastruktur wächst.

Claude Code hilft dabei, ein bestehendes flaches Inventar in diese Struktur zu migrieren:

claude "Refaktoriere dieses Ansible-Inventar in eine host_vars/group_vars-Struktur.
Hier ist die aktuelle hosts-Datei: [Inhalt einfügen]"

3. Playbooks: Struktur, Tasks, Handlers und Loops

Ein Playbook besteht aus einem oder mehreren Plays. Jedes Play definiert, auf welchen Hosts es läuft, und listet Tasks sequenziell auf:

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

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

    - name: Nginx-Konfiguration deployen
      ansible.builtin.template:
        src: nginx.conf.j2
        dest: /etc/nginx/nginx.conf
      notify: Nginx neu starten

  handlers:
    - name: Nginx neu starten
      ansible.builtin.service:
        name: nginx
        state: restarted

Handlers laufen erst am Ende des Plays und nur, wenn sie über notify ausgelöst wurden — und das nur einmal, egal wie viele Tasks sie notifizieren. Das verhindert unnötige Service-Neustarts.

Loops iterieren über Listen:

- name: Mehrere Pakete installieren
  ansible.builtin.apt:
    name: "{{ item }}"
    state: present
  loop:
    - git
    - curl
    - unzip

Conditionals mit when erlauben plattformspezifische Tasks:

- name: Paket auf Debian-Systemen installieren
  ansible.builtin.apt:
    name: nginx
    state: present
  when: ansible_os_family == "Debian"

4. Die wichtigsten Module im Überblick

Ansible liefert hunderte Module mit. Die am häufigsten genutzten:

• ansible.builtin.apt / ansible.builtin.yum — Pakete auf Debian- bzw. RHEL-Systemen verwalten
• ansible.builtin.copy — Dateien vom Control Node auf Remote-Hosts kopieren
• ansible.builtin.template — Jinja2-Templates rendern und deployen
• ansible.builtin.service — Systemd-Dienste starten, stoppen, aktivieren
• ansible.builtin.file — Dateien, Verzeichnisse und Symlinks verwalten
• ansible.builtin.shell / ansible.builtin.command — Befehle ausführen (nicht idempotent, nur wenn kein passendes Modul existiert)

Claude Code kennt alle gängigen Module und wählt bei einer Aufgabenbeschreibung automatisch das passende aus — inklusive Hinweis, wenn shell: durch ein idempotentes Modul ersetzt werden kann.

5. Rollen: Wiederverwendbare Ansible-Bausteine

Rollen sind das Mittel der Wahl, sobald ein Playbook mehr als eine Handvoll Tasks hat. Sie teilen Automatisierungslogik in wiederverwendbare Einheiten auf. Die Verzeichnisstruktur einer Rolle:

roles/nginx/
  defaults/
    main.yml        # Standardwerte für Variablen
  tasks/
    main.yml        # Hauptlogik der Rolle
  handlers/
    main.yml        # Handler dieser Rolle
  templates/
    nginx.conf.j2   # Jinja2-Templates
  files/
    index.html      # Statische Dateien
  vars/
    main.yml        # Nicht überschreibbare Variablen
  meta/
    main.yml        # Metadaten, Abhängigkeiten

Rollen aus der Community bezieht man über Ansible Galaxy:

ansible-galaxy role install geerlingguy.nginx

Claude Code kann eine vollständige Rollenstruktur für eine beschriebene Anforderung generieren:

claude "Erstelle eine Ansible-Rolle 'postgresql' die PostgreSQL 16 installiert,
einen Datenbankbenutzer anlegt und pg_hba.conf für lokale Verbindungen konfiguriert.
Nutze ansible.builtin.* Module und achte auf Idempotenz."

6. Ansible Vault: Geheimnisse sicher verwalten

Ansible Vault verschlüsselt sensible Daten direkt in der Versionskontrolle. Passwörter, API-Keys, Zertifikate — verschlüsselt als YAML, entschlüsselt zur Laufzeit:

# Neue verschlüsselte Datei erstellen
ansible-vault create group_vars/all/vault.yml

# Bestehende Datei verschlüsseln
ansible-vault encrypt group_vars/production/secrets.yml

# Playbook mit Vault-Passwort ausführen
ansible-playbook site.yml --ask-vault-pass

In der Praxis empfiehlt sich die Trennung: öffentliche Variablen in group_vars/production/main.yml, Geheimnisse in group_vars/production/vault.yml. Die öffentliche Datei referenziert Vault-Variablen über Konventionen wie db_password: "{{ vault_db_password }}" — so bleibt der Überblick erhalten, ohne Geheimnisse im Klartext zu speichern.

7. Claude Code Ansible: Praktische Tipps

Der größte Hebel von Claude Code Ansible liegt nicht im Generieren von Boilerplate — sondern im Prüfen auf typische Fehler, die beim Lesen schwer zu sehen sind:

Idempotenz-Check

claude "Prüfe dieses Playbook auf Idempotenz-Probleme. Markiere alle Tasks
die bei mehrfacher Ausführung einen anderen Zustand hinterlassen könnten." < deploy.yml

Claude Code erkennt dabei shell:-Tasks ohne creates: oder changed_when: Guard, nicht-idempotente command:-Aufrufe und fehlende state: present-Angaben bei Dateisystem-Tasks.

Rolle aus Anforderung generieren

Beschreibe die Anforderung, Claude Code liefert die Rollenstruktur — inklusive defaults/main.yml mit sinnvollen Standardwerten, Templates und einem vollständigen tasks/main.yml. Das spart nicht die Konfigurationsarbeit, aber die Recherche nach der richtigen Moduloption und YAML-Syntax.

Vault-Integration prüfen

claude "Analysiere dieses Playbook: Welche Werte sollten in Ansible Vault ausgelagert werden?
Erstelle die passende vault.yml-Struktur mit Platzhalterwerten." < site.yml

Fehler aus ansible-playbook direkt übergeben

ansible-playbook site.yml 2>&1 | claude "Was ist der Fehler und was muss ich ändern?"

Ansible-Fehlermeldungen sind oft lang und enthalten viel Kontext. Claude Code findet den relevanten Teil, erklärt die Ursache und liefert den konkreten Fix — statt einer Liste von Möglichkeiten.

"Das Problem liegt in Zeile 14 deines Templates: die Variable db_host ist in group_vars/all/main.yml nicht definiert. Füge sie dort hinzu oder setze einen Default in roles/app/defaults/main.yml."

Das ist der Unterschied zwischen einer Suche in der Dokumentation und einer direkten Antwort mit Kontext.

Zwei verwandte Artikel die auf diesem Thema aufbauen:

• Claude Code GitHub Actions — CI/CD-Pipelines mit KI-Unterstützung aufsetzen und debuggen
• Claude Code Debugging — Fehler systematisch finden statt Trial-and-Error