| | |
| 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 |