====== 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:
  * [[http://sotagtrends.com/?tags=%5Bsalt-stack,ansible,chef,puppet%5D|Trend bei stackoverflow]]

^ Feature / Architekturvergleich
^ 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, [[netzwerke:ssh#public-key-authentifizierung|SSH-Zugang (pubkey)]] zum Zielsystem, secrets (vault; symmetrische Verschlüsselung): Zugang zum ansible-master oer GUI, vault-plugins (externer Vault)  |
^ Syntax (Basis) | [[https://dev.to/betadots/puppet-is-yaml-2e32|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: [[software:ansible#Begriffe]]) |
^ Komplexität | eher hoch | eher niedrig |
^ Geschwindigkeit | [[https://puppet.com/docs/puppet/7/server/tuning_guide.html|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 ((Beispiel: Ausgabe von ''w'' <code bash>/bin/sh -c /usr/bin/python3 /root/.ansible/tmp/ansible-tmp-1669886879.4313855-3125691-172004554453070/AnsiballZ_openssl_dhparam.py</code> )), die Ausführung kann extra mit "strategy_plugins" beschleunigt werden (( Mitogen was reines Python mit ssh-pipelining hat, Ferm+Tcpwrapper, ...)) (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) | <code bash>puppet agent --disable && puppet agent --test --noop && puppet agent --enable</code> | 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 [[https://docs.ansible.com/ansible/latest/cli/ansible-pull.html|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 [[https://github.com/fboender/ansible-cmdb|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 ((außer mit bolt)) | -/+ ohne master wird lokal nichts enforct, die hohe Entwicklungsgeschwindigkeit von Ansible erfordert moderate Code/Syntax-Anpassungen |