Puppet en Ansible: complementair of concurrent?

Sinds jaren ligt onze focus op de bouw, de installatie en het beheer van IT-infrastructuur. Daarbij staan we los van leveranciers of tooling. Maar in ons werkveld duiken wel steevast twee namen op van tools voor IT-automatisering. Puppet en Ansible: complementair of concurrent?

Ja, we bouwden intussen zeker een sterke expertise rond Puppet op. Maar tegelijk houden we ook vast aan de grondslag van ons bedrijf. Want we stellen ons steeds agnostisch op. En we zijn vast van plan om dat te blijven doen. Wat ons betreft zijn Puppet en Ansible twee heel verschillende oplossingen. Ieder gericht op een ander type use case.

Push versus pull

Puppet ging als eerste in 2005 van start als een platform voor automatisering van infrastructuur. Het werd gebouwd in Ruby en had een duidelijke, platform onafhankelijke insteek. Ansible is van recentere datum. Zij startten in 2012 en profileren zich als een task orchestrator. Ansible is gebouwd in Python en richtte zich bij de start duidelijk op Linux. En dan met name Red Hat. Intussen is ook Windows aan de scope toegevoegd.

Algemeen mogen we stellen dat Ansible zich eerder leent voor kleine, snelle deployments van een dag. Terwijl Puppet zich meer richt op complexe omgevingen en deployments die meer tijd vergen. Ansible is agentless en steunt op een push model. Hierbij bepaalt de systeembeheerder wat er moet gebeuren en duwt die instructies naar de nodes. Puppet daarentegen werkt met een master/agent model, hoewel er intussen ook een agentless versie bestaat. Het hanteert duidelijk een pull model. Daarbij kloppen de nodes aan bij de master en trekken de juiste richtlijnen naar zich toe. De systeembeheerder omschrijft in Puppet wat hij wil. Daarna wordt die descriptieve taal omgezet in een reeks commando’s. Ansible van z’n kant richt zich meteen op de concrete taken via een opeenvolging van commando’s.

Meer verschillen dan gelijkenissen

De verschillen tussen Puppet en Ansible komen naar voren als we een paar concrete cases tegen het licht houden. Configuration drift, bijvoorbeeld. Waarbij een configuratie na verloop van tijd almaar verder afwijkt van de oorspronkelijke opzet. Puppet voorziet standaard in functionaliteit voor configuration drift remediation. Ook Ansible laat maatregelen toe. Alleen moet de systeembeheerder die zelf instellen. Dat kost wel tijd en geld, en doet voor een stuk de anders snelle opstart van Ansible teniet.

Puppet ziet nuances in de aangebrachte aanpassingen aan een configuratie. Soms gaat het om corrective change. Om de beoogde configuratie in stand te houden en onder meer configuration drift weg te werken. Soms gaat het om intentional change. Daarbij brengt de systeembeheerder heel bewust een verandering in de configuratie aan. Ansible maakt dat onderscheid niet.

Nog een verschil is approach van het concept van CI/CD-ready and testable code. Voor de systeembeheerder een server live zet, voert hij via een abstractielaag in Puppet een soort dry-run uit. Zo test hij de code en ziet hij hoe de node zal reageren. Ansible biedt die optie niet, wat het risico op een mislukte go-live van een server vergroot.

Complementaire oplossingen

Moeten we Puppet en Ansible als concurrenten zien? Zeker niet! De kunst bestaat er net in om de sterke kanten van beide tools in te zetten. Heel vaak zien we dat teams Ansible in het leven roepen om heel snel een configuratie up en running te hebben. En daarna Puppet gebruiken om de configuratie op lange termijn te beheren en onder controle te houden.

Trouwens, beide tools groeien meer en meer naar elkaar toe. Puppet Bolt hanteert dezelfde task based benadering als Ansible. Terwijl Ansible Tower zich posteert als alternatief voor Puppet Enterprise. Dat beide tools hun bestaansrecht hebben, bewijst alvast het feit dat teams vaak Ansible inzetten voor een snelle uitrol van Puppet.

Meer weten over Puppet en Ansible? Contacteer ons!

Wil je hulp met de bouw van je IT-infrastructuur? Bekijk dan ons aanbod!