Die erste Ansible-Bereitstellung war elegant: eine „Webstack“-Rolle, drei Gruppen „Staging“, „Prod“ und „Bastion“. Ein Jahr später enthält das Inventar „prod-legacy“, zwölf „temporäre“ „host_vars/prod-03.yml“-Blöcke und ein „when: inventory_hostname == ‚prod-03‘“ in der Nginx-Rolle. Das Playbook besteht – aber niemand weiß mehr, welche Konfiguration der Standard und welche Konfiguration der Patch ist.
Ansible lässt sich schlecht skalieren, wenn jede Ausnahme lokal bleibt, anstatt als Variable oder dokumentierte optionale Rolle aufzutauchen. Die klassische Falle: ein Playbook, das CI besteht, aber zwölf „host_vars“-Patches dokumentiert. Ein neuer Ingenieur weiß nicht mehr, welche Konfiguration Standard ist. Das Ziel ist kein grüner Lauf – es geht darum, dass ein zweites „Ansible-Playbook“ nichts ändert, wenn die Maschine nicht abgedriftet ist. Ohne diese Disziplin automatisieren Sie eher Verwirrung als gewünschte Konfiguration – und jede Bereitstellung fügt einen weiteren Patch hinzu.
Inventar, Gruppenvariablen und klare Hierarchie
Empfohlene Struktur: Inventare pro Umgebung, „group_vars/all.yml“, „group_vars/web.yml“, entkoppelte Rollen. group_vars für alles, was eine Gruppe teilt. host_vars reserviert für echte Ausnahmen (dedizierte IP-Adresse, Client-Zertifikat) – mit Kommentar und Ticket. Nein, wenn auf Hostname in Rollen – bevorzugen Sie „nginx_extra_vhosts“ als Variable.
Jedes „when:inventory_hostname ==“ ist eine schreiende Schuld.
Rollen, Tags und Oberfläche ändern
Aufschlüsselung nach Verantwortlichkeiten: „common“, „web“, „db_client“. Tags begrenzen den Wirkungsradius in der Produktion. Dokumentstandards in „roles/x/defaults/main.yml“ – Überschreibungen nur in group_vars. Eine Rolle, die Nginx, PHP und Firewall kombiniert, kann nicht mehr isoliert getestet werden.
Vault-, SSH- und Bastion-Zugriff
Verschlüsseln Sie Geheimnisse mit „ansible-vault encrypt“. SSH-Schlüssel über Agent – kein gemeinsamer Root-Schlüssel. Einzelne Bastion, „ProxyJump“, begrenztes Sudo. Richten Sie sich nach den Möglichkeiten Ihres VPS-Hosts – einige blockieren den direkten Root-Zugriff, andere erzwingen einen Schlüssel pro Umgebung.
Gebrochene Idempotenz: Symptome
Shell: Curl ... | bash bei jedem Lauf. „kopieren“ ohne Prüfsumme. service: state=restarted systematisch. Korrekt in deklarativen Modulen. Manuelle Drift → in Code importieren oder direktes SSH blockieren. Eine von Hand modifizierte Maschine widerspricht der Automatisierung – und niemand weiß, welche Quelle maßgeblich ist.
CI, Molekül- und Paritäts-Staging
Pipeline: „ansible-lint“, „yamllint“, Molecule konvergiert zweimal – der zweite Lauf sollte 0 geändert melden. Die Inszenierung sollte wie eine Produktion aussehen (gleiche Rollen, unterschiedliche Rollen). Ohne Parität testen Sie eine Konfiguration, die in der Produktion nicht vorhanden ist. Versionieren Sie das Inventar im selben Repository wie die Rollen – unversioniertes lokales Inventar ist die häufigste Quelle für „Es hat auf meinem Computer funktioniert“ in Produkten.
Refactoring, ohne das Team zu lähmen
Zählen Sie die Hostnamen „host_vars“ und „when:“ – wenn es zu einem Anstieg kommt, planen Sie eine Umgestaltungspause ein. Melden Sie Ausnahmen in dokumentierten gruppierten Variablen, eine pro Sprint. Ansible führt schnell eine Sammlung von Ausnahmen aus – es behebt sie nicht.
Auf einem VPS oder Bare-Metal weicht die Konfiguration auch aufgrund manueller Drift ab: ein vergessener SSH-Patch, ein von Hand installiertes Paket. Das Blockieren des direkten Zugriffs auf die Produktion – es sei denn, es liegt ein dokumentierter Notfall vor – erzwingt eine Rückkehr zum Code. Querverweis mit TLS und Härtung: Die gleichen Prinzipien der deklarativen Konfiguration gelten auch über Ansible hinaus.
Der Gipfel: Automatisierung, die Inkonsistenzen verbirgt
Entscheide dich und gehe ohne blinden Fleck voran
Refactorisez les exceptions en variables groupées documentées, une par une, avec ticket de suivi. Ajoutez Molecule en intégration continue et exigez zéro changement au second run. Chiffrez tous les secrets avec ansible-vault et révoquez tout secret déjà commité en clair. Documentez le bastion et les clés SSH par environnement — qui a accès, quelle clé, quelle rotation. Comptez les host_vars et les when: hostname : si ça monte, pause refactor. Comparez les VPS adaptés à Ansible via l'Verzeichnis et le Vergleich.
Questions fréquentes
Rôles ou playbook monolithique ?
Rôles réutilisables plus group_vars ; éviter le playbook fourre-tout. Un playbook monolithique devient une collection d'exceptions non testées dès qu'il dépasse quelques rôles.
Comment tester Ansible avant prod ?
Molecule avec second run à zéro changement, staging paritaire, lint en CI. --check seul ne suffit pas — il ignore certains effets de bord.
Ansible gère-t-il bien le secret ?
ansible-vault obligatoire ; pas de secrets clairs dans git. Révoquez tout secret déjà exposé dans l'historique — le chiffrement ultérieur n'efface pas le passé.
Pourquoi mon playbook n'est-il pas idempotent ?
Modules shell/command non déclaratifs, redémarrages forcés, exceptions par hôte. Chaque when: inventory_hostname == dans un rôle est un signal d'alarme.
Un inventaire sain se lit en groupes — pas en anecdotes par serveur.