Ich hab den Server für diesen Blog mit Ansible aufgesetzt

Du hast einen frischen Server und dir graut es davor wenn du ihn, warum auch immer, irgendwann neu aufsetzen musst? Du willst, dass das Setup dokumentiert ist, reproduzierbar ist, und nicht nur in deinem Kopf existiert?

Dann ist Ansible vielleicht interessant für dich.

Was ist Ansible?

Ansible ist ein Tool zur Automatisierung von Serverkonfiguration. Du beschreibst in YAML, wie dein Server aussehen soll, und Ansible sorgt dafür, dass er genau so aussieht.

Das Besondere: Ansible braucht keinen Agenten auf dem Zielserver. Es verbindet sich einfach per SSH, führt die Tasks aus und ist wieder weg. Voraussetzung auf dem Server: Python. Das ist es.

Ich beschreibe in einem sogenannten Playbook – einer YAML-Datei – wie der Server aussehen soll. Ansible verbindet sich per SSH, führt die Schritte aus und ist wieder weg. Secrets wie Passwörter und API-Keys landen verschlüsselt im Vault.

Das zentrale Prinzip: Idempotenz. Führe ich ein Playbook zweimal aus, passiert beim zweiten Mal nichts. Sofern der Server schon im gewünschten Zustand ist, werden die Schritte übersprungen. Das klingt trivial, ist aber extrem wertvoll in der Praxis. Wenn z.B. ein bestimmter Service laufen soll und dieser bereits läuft passiert einfach nichts und der Service läuft ungestört weiter.

Erster Durchlauf – zwei Tasks haben tatsächlich etwas verändert (changed=2):

Zweiter Durchlauf, direkt danach – der Server ist bereits im gewünschten Zustand, nichts passiert (changed=0):

Kurze Einordnung bevor wir weitermachen: Es gibt Alternativen. Terraform wird häufig zusammen mit Ansible genannt. Aber es löst ein anderes Problem. Terraform provisioniert Cloud-Infrastruktur – virtuelle Maschinen, Netzwerke, Datenbanken. Das ist nicht mein Problem. Ich habe einen VPS, den ich konfigurieren will, keine Cloud-Infrastruktur, die ich aufbauen will. Puppet und Chef können ähnliches wie Ansible, brauchen aber einen Agenten auf dem Zielserver. Für einen einzelnen Server ist das deutlich zu viel Overhead. Ansible ist agentenlos, schnell erlernbar, und ich hatte es vor über zehn Jahren schon mal im Einsatz. Es hat die Zeit gut überstanden.

Eine Sache noch zu den Voraussetzungen: Ansible läuft auf dem sogenannten Control Node, also dem Rechner von dem aus du die Playbooks ausführst. Dort braucht es Python und Ansible selbst. Unter Linux ist das kein großes Thema.

Unter Windows ist es etwas umständlicher. Ansible läuft nativ nicht auf Windows. Mein Setup: WSL 2 (Windows Subsystem for Linux) mit Debian. Ansible läuft im WSL, die SSH-Keys liegen dort, und alles funktioniert genau so wie auf einem nativen Linux-System.

Claude Code hat mir geholfen

Ich muss gestehen: Ich hab Ansible nicht alleine aufgesetzt. Claude Code hat mich unterstützt.

Für alle, die das nicht kennen: Claude Code ist ein KI-Assistent, der direkt im Terminal läuft und dabei Zugriff auf das lokale Dateisystem hat. Ich kann ihm Aufgaben geben, er kann Dateien lesen, schreiben, Befehle ausführen und mir erklären, was er tut.

Unsere Zusammenarbeit

Der Ablauf war ungefähr so: Ich habe beschrieben, was ich will. Claude hat eine erste Struktur vorgeschlagen. Ich hab nachgefragt, er hat angepasst. Irgendwann ist das Playbook durchgelaufen.

Konkret hat Claude die komplette Dateistruktur angelegt: bootstrap.yml, site.yml, die Rollen für common, docker und ghost, Templates für Konfigurationsdateien, die Vault-Einrichtung. Ich hätte das alles selbst bauen können, aber es hätte länger gedauert. Und ehrlich gesagt, ich hätte mir auch alles nur aus den Docs zusammenkopiert und angepasst. Selbst geschrieben hätte ich da wenig und Claude ist beim Copy-Paste einfach schneller.

Was sich dabei gut angefühlt hat: Claude hat nicht einfach irgendwas hingekleistert. Wenn ich nachgefragt habe warum etwas so gelöst wurde, kam eine vernünftige Erklärung. Meistens. Manchmal hat er auch Mist gebaut, und ich hab den Fehler erst beim nächsten Playbook-Run gefunden.

Stolpersteine auf dem Weg

Drei Probleme haben mich aufgehalten, alle auf Debian 13 „Trixie":

Doppelpunkt im Task-Namen. Der YAML-Parser mag das nicht. Jeder Task-Name mit Doppelpunkt muss in Anführungszeichen. Triviales Problem und die Fehlermeldung von Ansible war auch sehr sprechend. Dennoch hab ich, statt dem selbst nachzugehen, einfach Claude die Fehlermeldung gegeben und er hat das Playbook entsprechend angepasst.

apt-key existiert nicht mehr. Das alte Ansible-Modul apt_key schlägt auf Debian 13 fehl, weil der zugrundeliegende apt-key-Befehl entfernt wurde. Lösung: GPG-Key als Datei ablegen und in der Repository-Definition mit signed-by referenzieren. Das ist der moderne Weg, aber nicht alle Tutorials zeigen das.
Hier könnte der sogenannte Knowledge-Cutoff hineinspielen. Claude wurde mit Daten trainiert, die bis zu einem bestimmten Zeitpunkt reichen. Debian 13 ist relativ neu. Der apt-key-Wegfall war also vermutlich nicht mehr im Trainings-Datensatz, oder zumindest nicht prominent genug. Die KI hat den veralteten Ansatz gezeigt, weil sie den neueren schlicht nicht kannte. Sowas merkt man erst, wenn es knallt.
Ehrlich gesagt hätte ich diese Änderung auch nicht auf dem Schirm gehabt und wäre auch in die Falle getappt. Ich hätte also auch erst einmal online suchen müssen was Sache ist. Und genau das hat Claude dann übernommen und der Fehler war in wenigen Minuten behoben. Websuche ist übrigens der typische Weg mit dem sich die KIs bei Themen behelfen, die neuer sind als ihre Trainingsdaten.

Traefik und der Netzwerk-Prefix. Docker Compose benennt Netzwerke automatisch mit dem Projektnamen als Prefix, sofern man keinen Namen explizit setzt oder das Netzwerk als extern kennzeichnet. Ein Netzwerk namens web heißt dann in Wirklichkeit ghost_web, wenn das Compose-Projekt ghost heißt. Traefik weiß davon nichts und sucht nach dem falschen Namen. Symptom: 504 Gateway Timeout. Hier haben wir uns ein paar mal im Kreis gedreht. Diagnose: 45 Minuten. Fix: eine Zeile.

Warum nicht einfach die KI das Setup durchführen lassen?

Das ist eine naheliegende Frage. Claude Code kann SSH-Verbindungen aufbauen, Befehle ausführen und Dateien schreiben. Natürlich hätte ich sagen können "Hier ist der SSH-Key, das ist die URL, tob' dich aus." Wahrscheinlich wäre es gut gegangen. Vielleicht sogar schneller als mit dem Umweg das Playbook zu erstellen, das Playbook ausführen, etwaige Fehler im Playbook fixen, das Playbook noch einmal ausführen...

Aber ich möchte die Kontrolle über das haben was die KI abliefert. Und dann hätte ich jeden einzelnen Befehl, den Claude absetzen möchte, reviewen und bestätigen müssen. Das Playbook kann ich am Stück lesen und als Ganzes absegnen. Bei Fixes muss ich mir, wie bei einem Code-Review, nur den Diff anschauen.

Reproduzierbarkeit

Wenn die KI meinen Server einrichtet, entsteht kein Artefakt, das ich wiederverwenden kann. Es gibt kein Playbook, das ich in zwei Monaten auf einem neuen Server ausführen kann. Es gibt keine Dokumentation dessen, was auf dem Server läuft. Es gibt nur einen Server, der irgendwie konfiguriert ist.

Mit Ansible ist das Playbook das Artefakt. Es liegt in einem Git-Repository. Ich kann es auf jedem beliebigen Server ausführen. Ich kann nachvollziehen, was passiert. Ich kann Änderungen versionieren.

Ich habe jetzt einmal den Reviewprozess für das Playbook zusammen mit Claude Code durchlaufen. Solange sich am Playbook nichts ändert muss ich auch nichts mehr reviewen und kann das Playbook auf weitere Server anwenden. Wenn ich die Durchführung direkt der KI überlassen hätte müsste ich beim nächsten mal wieder die einzelnen Schritte mitlesen um sicher zu sein, dass da wirklich das passiert, was ich möchte.

Determinismus

KI ist nicht deterministisch. Wenn ich Claude in sechs Monaten bitte, denselben Server nochmal einzurichten, bekomme ich ein anderes Ergebnis. Vielleicht besser, vielleicht schlechter, aber ganz sicher anders. Anweisungen, die heute als feste Regel interpretiert werden, kann Claude beim nächsten mal als unverbindliche Empfehlung auffassen.

Ansible ist deterministisch. Dasselbe Playbook ergibt die selbe Serverkonfiguration. Immer.

Das ist der eigentliche Grund. Nicht weil die KI schlechter ist, sondern weil ein Playbook ein Versprechen ist, das eine KI nicht geben kann.

Fazit

Das Playbook liegt im Repo. Ich verstehe jeden Task darin. Wenn der Server morgen abraucht, bin ich in zehn Minuten wieder online.

Das war's, was ich wollte. Ansible hat es geliefert – mit etwas KI-Unterstützung und einem 45-Minuten-Debug für eine Zeile.