Articles

Chef vs Puppet: Differences, Similarities, and How to Choose

Vandaag zetten we twee populaire tools voor configuratiebeheer tegen elkaar af; Chef vs Puppet. Dit soort tools helpt engineers om een consistente configuratie in alle servers te handhaven. Bijvoorbeeld, alle servers moeten IIS hebben met een binding naar poort 443 voor HTTPS toegang en de respectievelijke firewall regel voor inkomend verkeer. Nog belangrijker, als iemand de firewall regel verwijdert, zullen dit soort tools de consistentie bewaren door de firewall regel opnieuw aan te maken.

Hoe zit het met database connection strings waar je een verschillende hebt voor dev, test, en prod?

Ja, Puppet of Chef kunnen deze ook aan.

De post van vandaag gaat over het vergelijken van Chef met Puppet. Dit zijn zeer vergelijkbare tools die hetzelfde doel bereiken: het handhaven van een consistente toestand. Maar ze verschillen ook in hoe ze gebruikers helpen om consistentie en herhaalbaarheid te behouden door de hele leveringspijplijn heen. Ten slotte zal ik het hebben over hoe je de ene tool boven de andere kunt verkiezen, afhankelijk van je behoeften en de behoeften van je team.

Dus laten we beginnen.

Tip: Vind onmiddellijk toepassingsfouten en prestatieproblemen met Stackify Retrace
Troubleshooting en optimalisatie van uw code is eenvoudig met geïntegreerde fouten, logboeken en inzichten in prestaties op codeniveau.
Try today for free

Gelijkenissen

Chef en Puppet vertonen overeenkomsten in de manier waarop ze configuraties in servers beheren. Hoewel beide tools intern op verschillende manieren werken, is het resultaat hetzelfde. Met beide tools, kun je de gewenste toestand definiëren door middel van code. Beide tools werken met een master-node architectuur waarbij de master verantwoordelijk is voor het opslaan van alle data, en de nodes ervoor moeten zorgen dat servers altijd de gewenste state configuratie hebben.

Een van de belangrijkste doelen van het gebruik van Chef of Puppet voor configuratie management is bijvoorbeeld dat je als code kunt definiëren wat de gewenste state van een groep servers moet zijn. Het zou niet uit moeten maken of je dezelfde configuratie op servers wilt toepassen, Chef en Puppet zullen ervoor zorgen dat elke verandering op een onafhankelijke manier wordt doorgevoerd. Op dezelfde manier drukken we allemaal meerdere keren op Ctrl + S om er zeker van te zijn dat we de wijzigingen opslaan. Maar waar dit soort tools uitblinken is dat als iemand handmatig de server binnenkomt, en de gewenste staat van de server verandert, deze tools de servers up-to-date zullen brengen door ze opnieuw te configureren.

Vanuit een architectuurperspectief lijken Chef en Puppet behoorlijk op elkaar omdat ze beide een master-agent architectuur gebruiken. Een master node is waar alle server configuraties worden opgeslagen. Masters voor beide tools zijn hoog beschikbaar (HA), maar met kleine verschillen-meer hierover later. Dan, voor iedere server die je wilt beheren, is er een agent geïnstalleerd die de configuratie in periodes automatisch binnenhaalt. Agents controleren altijd of de gewenste toestand wordt nageleefd, niet andersom. Beide tools kunnen Linux- en Windows-servers beheren.

Tot slot hebben beide tools een open-source versie en een betaalde versie met meer functies, zoals een betere HA-configuratie.

Verschillen

Ik zei al eerder dat de architectuur van Chef en Puppet vergelijkbaar zijn, maar ze verschillen enigszins in hoe ze omgaan met HA. In Puppet repliceert de master zijn gegevens naar een andere server, en ze werken op een actieve/passieve manier. Bij Chef wordt HA afgehandeld met drie servers in een actieve/actieve modus met een API front end die horizontaal kan schalen.

Een belangrijk verschil tussen Chef en Puppet is in hoe ze de gewenste toestandsconfiguratie voor servers definiëren. Elke tool heeft zijn eigen domeinspecifieke taal (DSL). Chef gebruikt Ruby voor DSL. Je hebt meer vrijheid om complexe configuraties te maken omdat je een programmeertaal gebruikt. Chef noemt deze gewenste status configuraties die je schrijft recepten. Alles wat je met Ruby kunt doen, kun je ook in Chef doen om recepten te maken, zoals if-condities of het aanroepen van andere bibliotheken. Het voordeel hiervan is dat ontwikkelaars zich wellicht meer op hun gemak voelen bij het schrijven van Chef recepten. Bovendien zullen ontwikkelaars zich niet beperkt voelen tot een DSL alleen, toe te voegen bij het definiëren van een configuratie.

Aan de andere kant, Puppet heeft zijn eigen DSL, “die is ontworpen om toegankelijk te zijn voor sysadmins.” En als je ervaring hebt met het werken met Nagios-configuratiebestanden, zal het schrijven van manifests (hun versie van Chef-recepten) geen probleem zijn. Je hebt hier niet al te veel vrijheid, maar dat is ook goed vanuit het perspectief van het hebben van een universele taal. Daarom hoef je geen ontwikkelaarsachtergrond te hebben om Puppet te gebruiken en te leren.

Ten slotte verschillen deze tools in de manier waarop je recepten of manifesten ontwikkelt en test. Chef heeft een werkstation inclusief de Chef SDK die u op uw lokale computer kunt installeren als een staging-omgeving. Je kunt de recepten lokaal testen, en ze dan uploaden naar de master node. Puppet heeft geen werkstation, maar wel een SDK waar je manifesten kunt testen terwijl je ze ontwikkelt. Bovendien kunt u manifesten lokaal toepassen met het commando puppet apply.

person wearing white apron walkin on stairs

Voorbeelden

Laten we eens kijken naar een codevoorbeeld van hoe ervoor te zorgen dat de Stackify-agent is geïnstalleerd.

Een recept in Chef ziet er als volgt uit (puur Ruby):

# ...# bunch of variables declared# ...# download and extract stackify agenttar_extract node do target_dir Chef::Config creates "#{Chef::Config}/#{stackify_agent_install_relative_path}/#{stackify_agent_install_script_name}" not_if { File.exist?(stackify_agent_jar_location) }endtemplate_file = "#{Chef::Config}/#{stackify_agent_install_relative_path}/stackify-agent.conf"template template_file do source "stackify-agent.conf.erb"end# run stackify agent install scriptbash 'agent_install' do user 'root' cwd "#{Chef::Config}/#{stackify_agent_install_relative_path}" code <<-EOH ./#{stackify_agent_install_script_name} #{stackify_agent_install_script_options} rm -rf #{Chef::Config}/Linux rm -rf #{Chef::Config}/#{stackify_agent_install_relative_path} EOH not_if { File.exist?(stackify_agent_jar_location) }end

Voor Puppet is er een module om de Stackify-agent te installeren, en het manifest ziet er als volgt uit:

 class { 'stackify': package_ensure => 'present', package_install_options_environment => 'development', package_install_options_activationkey => 'XXXXXXXXXXXXXXXXXXXXXXXXXX', file_download_directory => 'C:\Temp', service_manage => true, service_ensure => true, service_enable => true, }

Zoals je kunt zien, bevestigen de bovenstaande codevoorbeelden wat ik eerder heb gezegd. In Chef, heb je meer vrijheid. Maar in Puppet, kan de code er eenvoudiger uitzien als er een module is die je kunt gebruiken.

Premium Features

Laten we de vergelijking maken, inclusief de premium features, die andere dingen omvatten dan configuratie management.

Voor Puppet, hebben ze Puppet Enterprise die de volgende mogelijkheden bevat:

  • Rapporten die helpen bij compliance-beleid
  • Orchestratie van applicatie- en infrastructuurimplementaties
  • Automatisering van infrastructuurprovisionering met infrastructure as code
  • Code-beheer om infrastructuurwijzigingen automatisch te bevorderen
  • Node-beheer voor granulaire controle van servers
  • Role-gebaseerd toegangscontrolebeleid voor gebruikers
  • Support via e-mail of telefoon

Ze hebben ook Puppet Remediate, dat is een tool voor het beheer van kwetsbaarheden van uw servers. U kunt beter inzicht krijgen in welke kwetsbaarheden er in uw servers zijn, en op schaal patches toepassen op alle servers.

In Chef bevat de betaalde versie, naast configuratiebeheer, de volgende mogelijkheden:

  • Compliance en beveiligingsbeheer
  • Creëer CI/CD-pijplijnen en beheer releases voor alle applicaties
  • Zichtbaarheid met dashboards over uw hele infrastructuurstack

Je krijgt meer details op de site van elke leverancier, ze hebben behoorlijk goede bronnen om je te helpen snel aan de slag te gaan.

person playing puppet dog

Hoe te kiezen

Hoe te kiezen tussen Chef en Puppet is een moeilijke vraag, en het antwoord is, zoals altijd, … “het hangt ervan af.”

Welke tool je ook kiest, het zou een teambeslissing moeten zijn, vooral van degenen die uiteindelijk met de tool zullen gaan werken. Een goede benadering zou kunnen zijn om de achtergrond van het team in ogenschouw te nemen. Mensen met een systeembeheer achtergrond zouden het geschikter kunnen vinden om Puppet te gebruiken. Ook al zullen ze de DSL moeten leren, het zal nooit zijn zoals het leren van een programmeertaal. Hoewel, als ze een achtergrond in ontwikkeling hebben, vinden mensen Chef misschien leuker (zelfs als ze geen Ruby kennen).

Maar je zou ook de premium features van elke tool moeten overwegen. Welke van deze functies zal uw organisatie helpen om silo’s en verspilling te verminderen? Nogmaals, het hangt allemaal af van uw behoeften. Ik heb gezien dat beide leveranciers altijd zullen proberen om elkaar te overtreffen met de features. Bijvoorbeeld, in Puppet, kunt u aangepaste functies maken met Ruby.

En natuurlijk, een ander essentieel aspect is de prijs. Ik wil de prijzen hier niet noemen, omdat die nogal fluctueren, en afhankelijk zijn van de behoeften van elke klant. Een andere reden is dat in het geval van Puppet, hun prijzen pagina geen publiek nummer heeft, maar een “Contact Us” knop. Chef, aan de andere kant, heeft zijn prijzen pagina met nummers, maar u moet nog steeds contact met hen opnemen. Ik zou u aanraden rechtstreeks contact met hen op te nemen en te zoeken naar een goede aanbieding. Afhankelijk van het aantal servers dat u wilt beheren, kunnen ze u een betere prijs bieden.

Er is geen zilveren kogel

Een vriendelijke herinnering: er is geen zilveren kogel voor een configuratie management tool. Zowel Chef als Puppet zijn tegenwoordig zeer volwassen, en ze zijn voortdurend bezig met het verbeteren van hun product, het doen van investeringen in onderzoek, het creëren van betere manieren voor mensen om hun tool te leren, enz. Ik hoop dat deze vergelijking je heeft geholpen om een beter begrip te krijgen van hoe beide tools werken. Misschien bereid je je voor op een sollicitatiegesprek, of ben je nieuwsgierig naar de belangrijkste verschillen en overeenkomsten.

Maar als je beslist welke tool je voor je bedrijf gaat gebruiken, zorg er dan voor dat je een duidelijk beeld hebt van de problemen die je hebt en hoe dit soort tools je kunnen helpen om de last te verlichten. Er zal altijd een leercurve zijn, en het zal afhangen van de achtergrond van het team en welke tool meer geschikt is voor hen. Kijk bovendien naar de premiumfuncties en -services naast configuratiebeheer, omdat uw bedrijf misschien meer hulp nodig heeft bij het nalevingsbeleid.

  • Over de auteur
  • Laatste berichten

Over Christian Melendez

Christian Meléndez is een technoloog die is begonnen als softwareontwikkelaar en zich meer recent heeft ontwikkeld tot cloudarchitect die zich richt op het implementeren van continuous delivery pipelines met applicaties in verschillende smaken, waaronder .NET, Node.js, en Java, vaak met behulp van Docker containers.

  • AWS Elastic Beanstalk .NET Core Getting Started – 17 januari 2020
  • AWS Batch: A Detailed Guide to Kicking Off Your First Job – December 26, 2019
  • Azure Container Service (AKS) – A Detailed Intro – December 18, 2019
  • Het versturen van CloudWatch Custom Metrics From Lambda With Code Examples – November 14, 2019
  • Chef vs Puppet: Verschillen, overeenkomsten en hoe te kiezen – 24 september 2019