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 (pull mit ansible-pull möglich)
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
1)
Beispiel: Ausgabe von w
/bin/sh -c /usr/bin/python3 /root/.ansible/tmp/ansible-tmp-1669886879.4313855-3125691-172004554453070/AnsiballZ_openssl_dhparam.py
2)
Mitogen was reines Python mit ssh-pipelining hat, Ferm+Tcpwrapper, …
3)
außer mit bolt