Dies ist eine alte Version des Dokuments!
Vergleich zwischen ansible und puppet
Jeder Vergleich ist zu einem gewissen Teil subjektiv (Regen stört … außer den Bauer), dennoch lassen sich Fakten und Tendenzen gegenüberstellen. GGf. werden Chef und/oder Salt noch zum Vergleich hinzugefügt.
Das Ökosystem von ansible scheint jedenfalls dominant:
| Gründung / Eigentümer / Lizenz | 2005 (puppet inc.), opensource, enterprise version | 2012 (RedHat), Kern: nur opensource, Oberflächen:awx (OSS) oder enterprise (Ansible tower), alternative Oberflächen z.B. Rundeck oder foreman |
|---|---|---|
| Konzept | master/multi-master, deklarativ (Zustandsdefininition): Reihenfolge der Aufgabenausführung nicht sequentiell sondern Endzustand wird definiert | master/backup (oder Arbeitsrechner), imperativ (Taskdefinition): Reihenfolge der Aufgabenausführung vorhersagbar sequentiell (aber dynamisch steuerbar) |
| Zugangskontrolle | Repo-Rechte, Zugang zum puppet-master; secrets: Zugang zum puppet-master | Repo-Rechte, SSH-Zugang (pubkey) zum Zielsystem, secrets (vault; symmetrische Verschlüsselung): Zugang zum ansible-master oer GUI, vault-plugins (externer Vault) |
| Syntax (Basis) | hiera (yaml) + puppet DSL (Ruby basierende Beschreibungssprache), Module: Ruby | yaml (jinja2 für templates), module: Python |
| Begriffe | Manifeste / Module (Katalog, Ressourcen, …) | Playbooks / Rollen / Collections (weitere: Begriffe) |
| Komplexität | eher hoch | eher niedrig |
| Geschwindigkeit | Katalog kompilieren auf server, agent muss Cache bilden. Sollte gut skalieren solange der master genug Leistung hat. | skaliert grundsätzlich parallel auf die nodes (kein buildzeit), aber absolute Ausführungsgeschwindigkeit suboptimal, da pro tasks python-Code in eine Shell ausgeführt wird 1), die Ausführung kann extra mit „strategy_plugins“ beschleunigt werden 2) (was aber evtl. Kompatibilitätsprobleme mit sich bringt) oder simpel durch bessere task-management wie conditions und tags die Ausführung unnützer tasks reduzieren. |
| 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) | vorher (ansible-lint), logische Fehler zur Laufzeit (standardmäßg bricht ein run an der Fehlerstelle ab, jedenfalls für den host wo der Fehler auftritt, aber Fehlerbehandlung für fehlgeschlagene tasks möglich (bzw. Verhalten steuerbar) |
| Debugging (nach Syntaxprüfung) | puppet agent --disable && puppet agent --test --noop && puppet agent --enable | im Check-mode laufen lassen (-C), verbosity erhöhen (-v bis vvvvv) |
| Server/Agent? | Server (puppetDB, CA für server/client-trust, optional frontends: foreman), Client: agent und facter (Pakete auf Zielsystem), push/pull vom Server | agentless (kein agent), ansible „master“ (dort wo ansible ausgeführt wird) übernimmt parsing der yaml/jinja2-Anweisungen und überträgt Python-Code über SSH der auf das Zielsystem der dort ausgeführt wird. push vom server |
| push / pull | pull (push mit bolt möglich) | push |
| verwaltbare Systeme | alles worauf der puppet-agent installierbar ist (embedded Systeme wie switche daher nur indirekt verwaltbar) | alles was SSH und Python 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 |
| facts Datenbank | puppetdb | ad-hoc abfragbar, optionale/dauerhafte Aufbereitung über Zusatzprogramme wie ansible-cmdb |
| Stärken | gute Abstraktion, „sauberer“ Aufbau, Reporting (puppetDB) | sehr großes Ökosystem, wenig Komplexität, hohe Flexibilität bei Zielsystem (ad-hoc, dynamische Inventories, …), Initialaufwand niedrig (master aufsetzen), Zielmaschinen brauchen nur SSH-Erreichbarkeit, diese kann individuell mit VPNs und Pubkeys ermöglicht werden oder optional über eine Oberfläche mit SSH-deploykey |
| Schwächen | Initialaufwand hoch (master aufsetzen), upgradeaufwand (server+db, frontend, agents hochziehen), Anbindung von agents aufwendig: Installation des passenden agents (Version!) erfordert eine unterstütze Zielplattfrom + trust (cert req + sign), -/+ auch ohne Verfügbarkeit des masters wird die gecachte config config lokal enforct, Abhängigkeiten (z.B. zwischen Nodes) schwer definierbar, kein ad-hoc-Verwaltung 3) | -/+ ohne master wird lokal nichts enforct, die hohe Entwicklungsgeschwindigkeit von Ansible erfordert moderate Code/Syntax-Anpassungen |