Ansible im produktiven Einsatz – Erfahrungsbericht

Wir haben in den letzten Wochen begonnen, Teile unserer Infrastruktur von Fabric-Skripten auf Ansible umzustellen.

Umgebung: ~200 Debian-8-Hosts (Web, Worker, kleinere DB-Server).

Spoiler: Das wird kein Kein Hype-Artikel – sondern spiegelt Praxiserfahrung.

Warum wir Fabric ersetzt haben

Fabric hat uns jahrelang gute Dienste geleistet. Aber:

  • Keine echte Idempotenz
  • State-Handling selbst gebaut
  • Fehlerbehandlung uneinheitlich
  • Deployments nicht deklarativ

Mit zunehmender Host-Anzahl wird das unübersichtlich.

Ansible bringt hier zwei entscheidende Punkte:

  1. Deklarativer Ansatz
  2. Idempotenz ohne Eigenbau

Technische Realität

Ansible ist agentless – aber:

  • SSH muss laufen
  • Python 2.x muss auf dem Zielsystem installiert sein
  • Minimal-Images ohne Python machen Probleme

Das sollte man nicht verschweigen.

Beispiel: Nginx-Rollout auf 200 Hosts

Playbook stark vereinfacht:

- hosts: web
  become: yes
  tasks:
    - name: Nginx installieren
      apt:
        name: nginx
        state: present
        update_cache: yes

    - name: vHost deployen
      template:
        src: vhost.j2
        dest: /etc/nginx/sites-available/app.conf
      notify: reload nginx

  handlers:
    - name: reload nginx
      service:
        name: nginx
        state: reloaded

Rollout mit:

ansible-playbook -f 30 web.yml

Mit 30 Forks dauert das in unserer Umgebung ca. 10–15 Minuten.

Wichtig:
Wir fahren Updates in Gruppen (Batching via serial:), nicht alles auf einmal.

Vergleich zu Puppet / Chef / Salt (realistisch betrachtet)

ToolAgentModellBemerkung
AnsibleNeinPushEinfacher Einstieg
PuppetJaPullStabil bei großen Umgebungen
ChefJaPullDev-nah
SaltStackMeistPush/PullSehr schnell

Ansible ist nicht „besser“.
Es ist:

  • schneller einzuführen
  • für klassische Sysadmins zugänglicher
  • für 100–500 Hosts sehr angenehm

Für mehrere tausend Systeme kann man sich noch Salt oder Puppet genauer ansehen.

Was noch nervt

  • Python-Abhängigkeit
  • Fehlermeldungen manchmal unklar
  • Debugging bei komplexen Roles nicht trivial
  • Galaxy-Roles qualitativ sehr unterschiedlich

Man muss saubere eigene Standards definieren.

Best Practices, die sich (aktuell) bewährt haben

  • Keine Monster-Playbooks
  • Eigene Rollen-Struktur
  • --check vor produktiven Runs (JA Immer )
  • serial: für Rolling-Deployments
  • Secrets ausschließlich via ansible-vault
  • Keine Business-Logik in Templates verstecken (Kann nach hinten losgehen!)

Fazit nach 3 Monaten

Ansible ersetzt bei uns:

  • Fabric
  • 70 % der Bash-Deploy-Skripte
  • diverse Cron-Update-Jobs

Nicht ersetzt:

  • Monitoring
  • Orchestrierung komplexer Cluster
  • DB-Migrations-Logik

Für 2017 ist Ansible ein sehr pragmatisches Werkzeug.
Nicht magisch. Aber solide.