Puppet vs Ansible: welke tool past bij jouw infrastructuur?

Kies Ansible als je snel wilt automatiseren zonder extra software op je servers: je schrijft leesbare YAML-playbooks en voert ze via SSH uit op het moment dat jij dat wilt. Kies Puppet als je een groot, langlevend serverpark hebt dat continu in een vastgelegde toestand moet blijven, met agents die zelf controleren en corrigeren. Beide tools doen configuratiebeheer, maar ze werken fundamenteel anders. Die werkwijze bepaalt welke tool bij jouw team en jouw omgeving past. Hieronder lees je de verschillen in architectuur, leercurve, schaal, compliance en licenties, plus een heldere keuzehulp.

Kort samengevat

• Ansible is agentloos, werkt via SSH en pusht wijzigingen wanneer jij een playbook start. Laagdrempelig, flexibel en sterk in deployments en ad-hoctaken.
• Puppet gebruikt meestal een agent op elke server die de gewenste toestand ophaalt bij een Puppet Server en die standaard elke 30 minuten afdwingt.
• Ansible schrijf je in YAML, procedureel. Puppet schrijf je in een eigen taal, declaratief. De leercurve van Puppet is steiler.
• Puppet blinkt uit in langdurige consistentie en compliance in grote, complexe omgevingen. Ansible past vaak beter bij kleine en middelgrote omgevingen en cloud-native werk.
• Let op de licenties: de leverancier verspreidt de open-source Puppet-pakketten niet meer publiek, de community ging verder met de fork OpenVox.

Inhoudsopgave

• Waarvoor gebruik je Puppet en Ansible?
• Het grootste verschil: agent en pull tegenover SSH en push
• Declaratief of procedureel: zo voelt de code
• Puppet en Ansible naast elkaar
• Installatie, leercurve en onderhoud
• Schaal, drift en compliance
• Licenties en edities in 2026
• Wanneer kies je Puppet en wanneer Ansible?
• En hoe zit het met Docker?
• Ons perspectief
• Serverbeheer zonder eigen automatiseringsstack
• Veelgestelde vragen
• Bronnen

Waarvoor gebruik je Puppet en Ansible?

Puppet en Ansible lossen hetzelfde probleem op: tientallen of honderden servers op dezelfde manier inrichten en houden, zonder dat iemand op elke machine handmatig inlogt. Volgens Red Hat gebruik je beide om systemen te configureren en te provisionen, software uit te rollen en updates te beheren op veel servers of endpoints. Ansible kan daarnaast complete workflows orkestreren, terwijl Puppet is ontworpen voor modelgedreven automatisering van hybride infrastructuur op grote schaal.

Concreet gaat het om werk als:

• de basisconfiguratie van een nieuwe server (gebruikers, SSH-instellingen, tijdsynchronisatie, firewall);
• webservers, databases en middleware installeren en configureren;
• patches en pakketten bijwerken;
• monitoring, containers en netwerkinstellingen beheren;
• wachtwoorden en andere geheimen veilig op de juiste plek krijgen.

De documentatie van open-source Puppet noemt precies dit soort toepassingen, van webservers en databases tot patches, containers, netwerken en secrets. Het verschil zit dus niet in wát je kunt automatiseren, maar in hóé de tool het doet.

Het grootste verschil: agent en pull tegenover SSH en push

Ansible: agentloos en op jouw initiatief

Ansible is een op Python gebaseerde commandlinetool. Je installeert het op één machine, bijvoorbeeld je laptop of een beheerserver, en vanaf daar maak je via SSH verbinding met de servers die je wilt beheren. Op die servers hoeft geen Ansible te staan. De MariaDB-documentatie beschrijft het helder: wijzigingen worden alleen toegepast wanneer je ansible-playbook uitvoert. Je hebt SSH-toegang nodig en doorgaans sudo-rechten op de doelserver.

Welke servers worden aangepast, bepaal je met een inventory: een lijst met hosts, ingedeeld in groepen. Daarop draai je plays en rollen die uit taken bestaan, aangevuld met variabelen en facts (gegevens die Ansible van de server zelf ophaalt).

Puppet: een agent die zelf de gewenste toestand bewaakt

Puppet werkt meestal met een primary server, de Puppet Server, en een agent op elke beheerde machine. De server bewaart de code die beschrijft hoe elke machine eruit hoort te zien. De agent stuurt facts over zijn eigen systeem naar de server, krijgt een gecompileerde catalogus terug en past lokaal alleen toe wat afwijkt. Puppet kan ook standalone draaien, zonder centrale server, maar de agent-serveropzet is het gebruikelijke model.

Dat pull-model heeft een belangrijk gevolg. Volgens de Foreman-documentatie (versie 5.0) draait de Puppet-agent standaard iedere 30 minuten. Wijzigt iemand handmatig iets op een server, dan wordt dat bij de volgende run waarschijnlijk weer overschreven. Voor consistentie is dat precies wat je wilt. Voor een beheerder die even snel iets test, is het een verrassing als hij het niet weet.

Puppet is overigens niet meer uitsluitend agentgebaseerd. Puppet zelf wijst erop dat de kern draait om desired-state-automatisering met agents, terwijl Puppet Edge taakgerichte, agentloze automatisering ondersteunt.

Declaratief of procedureel: zo voelt de code

Het tweede grote verschil zit in de manier van denken. In Puppet beschrijf je het eindresultaat: dit pakket hoort geïnstalleerd te zijn, deze service hoort te draaien. Puppet zoekt zelf uit welke stappen daarvoor nodig zijn. In Ansible beschrijf je taken die in volgorde worden uitgevoerd. Veel Ansible-modules zijn wel idempotent, ze doen niets als de situatie al klopt, maar de playbook leest als een stappenplan.

Een eenvoudig voorbeeld: nginx installeren en laten draaien.

In Ansible (YAML):

- hosts: webservers
  become: true
  tasks:
    - name: nginx installeren
      ansible.builtin.package:
        name: nginx
        state: present
    - name: nginx starten
      ansible.builtin.service:
        name: nginx
        state: started
        enabled: true

In Puppet (eigen DSL):

package { 'nginx':
  ensure => installed,
}

service { 'nginx':
  ensure  => running,
  enable  => true,
  require => Package['nginx'],
}

Het resultaat is hetzelfde. Wie gewend is aan shellscripts, leest de Ansible-versie vaak meteen. De Puppet-versie vraagt dat je de taal en het resourcemodel leert, maar wordt krachtig zodra je configuraties in klassen, rollen en profielen gaat opbouwen. Gegevens per omgeving of per server houd je in Puppet bij in Hiera, gescheiden van de code.

Puppet en Ansible naast elkaar

Installatie, leercurve en onderhoud

Met Ansible ben je snel aan de slag. Een empirische studie in het tijdschrift ISI (2023) noemt als voordelen de leesbare YAML-syntaxis, het ontbreken van agents en extra beveiligingsinfrastructuur, de dry-run-modus (--check) waarmee je eerst ziet wat er zou veranderen, brede platformondersteuning en ad-hocautomatisering. Dezelfde studie noemt wel mogelijke prestatie- en runtimeproblemen bij grote deployments: elke run moet vanaf één punt alle servers langs.

Puppet vraagt meer voorbereiding. Je richt een Puppet Server in, installeert en onderhoudt agents, beheert certificaten tussen server en agents en leert de taal. De studie noemt die steilere leercurve en het extra agentbeheer als de prijs die je betaalt. Daar staat tegenover dat Puppet volgens dezelfde studie goed geschikt is voor grootschalige systemen, op zowel Linux- als Windowsservers.

In de praktijk betekent dit: een team met sterke systeembeheerders die een vaste omgeving jarenlang strak willen houden, haalt de investering in Puppet er ruim uit. Een klein team dat vooral snel wil uitrollen, haalt met Ansible binnen een middag resultaat.

NLXS

Bespreek je infrastructuur in Breda

Kom langs om te bespreken hoe NLXS hosting en infrastructuuroplossingen afstemt op de behoeften van jouw organisatie.

NLXS

Lage Mosten 51, 4822 NK Breda

Bekijk de route

© OpenStreetMap contributors

Schaal, drift en compliance

Configuratiedrift is het sluipende probleem van elk serverpark: kleine handmatige wijzigingen waardoor servers die identiek zouden moeten zijn, langzaam uit elkaar groeien. Hier laat Puppet zijn kracht zien. Omdat de agent periodiek de gewenste toestand afdwingt, herstelt de omgeving zichzelf. Ansible corrigeert drift ook, maar alleen wanneer jij of een geplande job het playbook opnieuw draait.

Voor compliance werken beide tools goed samen met beheerplatforms. De Foreman-documentatie beschrijft hoe je compliancebeleid uitrolt via een Ansible-rol of via een Puppet-klasse met een OpenVox-agent. Met Ansible voer je dat handmatig of via terugkerende remote-executionjobs uit, met Puppet wordt het bij de volgende reguliere agent-run toegepast. Een belangrijke les uit de Foreman-handleiding (versie 3.19): test automatische remediatie altijd eerst in een niet-productieomgeving, omdat een te strenge hardening een systeem onbruikbaar kan maken.

Let ook op geheimen. Beide tools kunnen koppelen met een externe secret store. Ansible kan wachtwoorden versleutelen met ansible-vault, maar volgens de MariaDB-documentatie is dat niet de veiligste opslagmethode en is een versleuteld bestand gevoelig voor brute-forceaanvallen als het in verkeerde handen valt. Werk je met klantgegevens of toegang tot productieomgevingen, laat dan je beveiligingsverantwoordelijke meekijken naar waar sleutels en wachtwoorden staan.

Wil je weten hoe je de toegang tot servers zelf goed regelt, ongeacht de tool? Lees dan onze checklist voor veilig remote serverbeheer.

Licenties en edities in 2026

Bij een keuze voor de komende jaren tellen ook de licentievoorwaarden mee, en daar is bij Puppet veel veranderd.

Puppet. Eigenaar Perforce verplaatste de open-source builds van Puppet naar een eigen repository. Als reactie ontstond een community-fork, OpenVox, die de open-source lijn voortzet. Van Perforce zelf is er nu Puppet Core: gratis als developer edition tot 25 nodes, daarboven met een commerciële licentie per node. Puppet Enterprise is het volledige platform met een abonnement per node. Voor bestaande Puppet-gebruikers betekent dit een bewuste keuze: overstappen op OpenVox, een licentie nemen of de omgeving anders inrichten.

Ansible. De commandlinetool zelf is open source. Voor een webinterface, planning, rechtenbeheer en een API is er AWX, het open-source upstreamproject van Red Hat Ansible Automation Platform. De commerciële variant met ondersteuning is Ansible Automation Platform zelf. De oude naam Ansible Tower bestaat niet meer: Red Hat heeft die naam met versie 2 van het platform opgeheven, het onderdeel heet nu automation controller.

Kies je een commerciële editie, reken de licentiekosten dan per node mee in je totale kosten, naast de uren die je team aan inrichting en onderhoud besteedt.

Wanneer kies je Puppet en wanneer Ansible?

Gebruik deze criteria als keuzehulp.

Kies Ansible als:

1. je geen agents wilt installeren of dat op sommige systemen niet kan;
2. je team vooral deployments, updates en eenmalige wijzigingen automatiseert;
3. je werkt met tijdelijke, cloud-native omgevingen die je vaak opbouwt en weer afbreekt;
4. je snel resultaat wilt zonder een nieuwe programmeertaal te leren;
5. je omgeving klein tot middelgroot is.

Kies Puppet als:

1. je een groot, complex serverpark hebt dat jarenlang meegaat;
2. servers continu in een vastgelegde toestand moeten blijven, ook als iemand handmatig iets wijzigt;
3. compliance en auditbaarheid zwaar wegen, bijvoorbeeld in gereguleerde sectoren;
4. je team sterker is in systeembeheer dan in programmeren en een model met rollen en profielen wil;
5. je al een Puppet-omgeving hebt die goed werkt.

Dit sluit aan bij hoe de leveranciers het zelf zien. Puppet positioneert zichzelf voor grotere organisaties met complexe, langdurige deployments en Ansible voor kleinere teams die flexibiliteit en kortlevende cloud-native omgevingen nodig hebben. Red Hat legt de nadruk op gebruiksgemak en agentloosheid. Veel organisaties combineren ze ook: Puppet voor de basisconfiguratie van alle servers, Ansible voor deployments en orkestratie bovenop.

En hoe zit het met Docker?

Een veelgehoorde vraag is of containers configuratiebeheer overbodig maken. Dat doen ze niet. TechTarget legt uit dat Ansible processen automatiseert om een applicatie op te zetten, uit te rollen en te onderhouden, terwijl Docker applicaties draait als afgesloten containers. Een Ansible-playbook kan Docker op een host installeren en configureren, een image binnenhalen en die als service starten. Puppet kan hetzelfde: Docker installeren en containers beheren.

De taakverdeling is dus: Docker regelt wat ín de container zit, Puppet of Ansible regelt de server eromheen. Draai je veel containers over meerdere hosts, dan komt er een orchestrator bij. Lees daarvoor ook onze vergelijking Kubernetes vs Nomad.

Ons perspectief

Puppet of Ansible, het is een goede vraag, maar voor veel mkb-bedrijven en webshops niet de belangrijkste. De echte vraag is: wie schrijft de playbooks of manifests, wie houdt ze bij en wie neemt de telefoon op als een update op vrijdagmiddag iets omgooit?

Beide tools zijn krachtig. Maar automatisering is nooit af. Er komen nieuwe serverversies, beveiligingsrichtlijnen veranderen en licentievoorwaarden schuiven, zoals de recente ontwikkelingen rond Puppet laten zien. Dat vraagt kennis en tijd die een klein team liever in zijn eigen klanten en producten steekt.

Daarom geloven wij in volledige ontzorging. Wij nemen het serverbeheer van je over, voor een vast maandbedrag zonder verrassingen, en je belt ons gewoon direct als er iets is. Problemen lossen we binnen één dag op. Twijfel je wat het slimst is voor jouw situatie, dan brengen we dat eerst in kaart met een ICT-scan. Zo kies je niet voor een tool, maar voor een omgeving die gewoon werkt.

Ken

Serverbeheer zonder eigen automatiseringsstack

Wil je de voordelen van strak beheerde, consistente servers zonder zelf een Puppet Server te onderhouden of playbooks te schrijven? Met hosted serverbeheer van NLXS besteed je dat werk uit aan een team dat persoonlijk bereikbaar is en snel schakelt.

Je betaalt een transparant maandbedrag en weet precies waar je aan toe bent. Wil je eerst de afweging maken tussen zelf doen en uitbesteden, lees dan managed ICT versus eigen beheer of bekijk al onze ICT-diensten.

Veelgestelde vragen

Wat heeft Ansible Tower vervangen?

Ansible Tower heet nu automation controller en is onderdeel van Red Hat Ansible Automation Platform. De gratis open-source tegenhanger is AWX, het upstreamproject waarop het commerciële product is gebaseerd. Beide geven je een webinterface, planning van jobs en rechtenbeheer bovenop de gewone Ansible-commandline.

Kun je Puppet en Ansible samen gebruiken?

Ja, en dat gebeurt vaak. Puppet bewaakt dan de basisconfiguratie van alle servers, terwijl Ansible deployments, eenmalige wijzigingen en orkestratie over meerdere systemen verzorgt. Spreek wel duidelijk af welke tool welke instellingen beheert, anders zet de Puppet-agent een wijziging van Ansible bij de volgende run weer terug.

Is Ansible makkelijker dan Puppet?

Voor de meeste beginners wel. Ansible werkt zonder agents, met YAML die je snel leest en schrijft, en je hoeft geen centrale server in te richten. Puppet heeft een steilere leercurve door de eigen taal en de agent-serverarchitectuur, maar biedt daarvoor continue handhaving van de gewenste toestand.

Wat is het verschil tussen Ansible en Docker?

Ansible automatiseert het inrichten en onderhouden van servers en applicaties, Docker verpakt en draait applicaties in containers. Ze vullen elkaar aan: met Ansible installeer je bijvoorbeeld Docker op een server en start je de juiste containers.

Is Puppet nog gratis te gebruiken?

De oorspronkelijke open-source pakketten worden niet meer publiek door de leverancier verspreid. Je kunt Puppet Core gratis gebruiken als developer edition tot 25 nodes, daarboven is een licentie per node nodig. Wie volledig open source wil blijven, kan overstappen op de community-fork OpenVox.

Bronnen

• Red Hat: Ansible vs. Puppet
• Puppet: Ansible vs. Puppet
• Open source Puppet 6.28.0 documentatie
• MariaDB: Comparison Between Automation Systems
• IIETA: An Empirical Evaluation of Automated Configuration Tools
• Foreman 5.0: Managing Security Compliance
• Foreman 3.19: Managing Security Compliance
• The New Stack: OpenVox, de community-fork van Puppet
• Puppet: vergelijking van edities
• Spacelift: alternatieven voor Ansible Tower en AWX
• Spacelift: Ansible vs. Ansible Tower
• TechTarget: Ansible vs. Docker

Aanbevelingen

• Kubernetes versus Nomad: welke orchestrator past bij jouw team?
• Git deploy op server: welke methode past bij jouw project