software:vergleich-zwischen-ansible-und-puppet

Vergleich zwischen ansible und puppet

Gründung / Eigentümer / Lizenz 2005 (puppet inc.), opensource, enterprise version 2012 (red hat), Kern: opensource, Oberfläche OSS oder enterprise (Ansible tower)
Konzept master/multi-master, deklarativ (Zustandsdefininition): Reihenfolge der Aufgabenausführung nicht sequentiell master/backup (oder Arbeitsrechner), imperativ (Taskdefinition): Reihenfolge der Aufgabenausführung sequentiell und vorhersagbar
Syntax hiera (yaml) + puppet DSL (Ruby basierende Beschreibungssprache), Module: Ruby yaml (jinja2 für templates), module: Python
Begriffe Manifeste / Module (Katalog, Ressourcen, …) Playbooks / Rollen (weitere: Ansible#Begriffe)
Komplexität eher hoch eher niedrig
Geschwindigkeit eher niedrig (Katalog kompilieren, agent muss Cache bilden) eher hoch
Sicherstellen des gewünschten Zustands lokal laufender agent (temporär auch ohne Server), lokale Eingriffe werden sofort rückgängig gemacht (Intervall puppet-run), debugging am offenen Herzen erfordert puppet-agent-stop (ist aber no-go) müssen über erneute (servergesteuerte) Durchläufe (cron, awx/tower) durchgesetzt werden, lokales debuggen möglich bis zum nächsten run (ist aber no-go)
Syntaxprüfung Prüfung „puppet parser validate“ für den ganzen Code auf einmal (Kompilierung des Katalogs) - trotzdem Fehler auf Client möglich: trust, caching issues (seltener) oder Duplicate declaration (bricht run früh ab, handling ggf. in aktuelleren Versionen besser) zur Laufzeit (auf Server), standardmäßg bricht ein run an der Fehlerstelle ab… aber Fehlerbehandlung für fehlgeschlagene tasks möglich
Server/Agent? Server (puppetDB, CA für server/client-trust, optional: foreman), Client: agent und facter (Pakete auf Zielsystem), push/pull vom Server agentless (kein agent), server übernimmt parsing und überträgt Code über SSH der auf dem Zielsystem ausgeführt wird. push vom server
verwaltbare Systeme alles worauf der puppet-agent installierbar ist (geschlossene Systeme fallen daher raus) alles was SSH unterstützt + CLI, Windows: WinRM bzw. PowerShell
Modul https://forge.puppet.com/ https://galaxy.ansible.com/home
Reporting automatisch: puppetDB (welcher client ist „out-of-sync“? facts) optional: über call-back-plugins oder logging auf master
Stärken gute Abstraktion, „sauberer“ Aufbau, Reporting (puppetDB) wenig Komplexität, hohe Flexibilität bei Zielsystem (ad-hoc, dynamische Inventories, …), Initialaufwand niedrig (master aufsetzen), Zielmaschinen brauchen nur SSH-Benutzer + Pubkey-Trust
Schwächen Initialaufwand hoch (master aufsetzen), Anbindung von agents aufwendig: Installation des passenden agents (Version!) + trust (cert req + sign), -/+ auch ohne Verfügbarkeit des masters wird lokal die config enforct, Abhängigkeiten (z.B. zwischen Nodes) schwer definierbar, kein ad-hoc-Verwaltung -/+ ohne master wird lokal nichts enforct, die hohe Entwicklungsgeschwindigkeit von Ansible erfordern Code/Syntax-Anpassungen