Articles

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

Ma két népszerű konfigurációkezelő eszközt állítunk szembe egymással: Chef vs Puppet. Az ilyen típusú eszközök segítenek a mérnököknek abban, hogy konzisztens konfigurációt tartsanak fenn minden szerveren. Például minden szerveren szükség lehet az IIS-re a 443-as porthoz való kötéssel a HTTPS-hozzáféréshez és a megfelelő tűzfalszabállyal a bejövő forgalomhoz. Ami még fontosabb, ha valaki eltávolítja a tűzfalszabályt, az ilyen típusú eszközök fenntartják a konzisztenciát azáltal, hogy újra létrehozzák a tűzfalszabályt.

Mi a helyzet az adatbázis-kapcsolati karakterláncokkal, ahol a dev, a test és a prod számára más és más van?

Igen, a Puppet vagy a Chef ezeket is tudja kezelni.

A mai bejegyzés a Chef és a Puppet összehasonlításáról szól. Ezek nagyon hasonló eszközök, amelyek ugyanazt a célt érik el: a konzisztens állapot fenntartását. De abban is különböznek, hogy hogyan segítik a felhasználókat a konzisztencia és az ismételhetőség fenntartásában az egész szállítási csővezetékben. Végül pedig arról fogok beszélni, hogyan választhatjuk az egyik eszközt a másik helyett, attól függően, hogy milyen igényeink és csapatunk igényei vannak.

Vágjunk bele.

Tipp: Az alkalmazás hibáinak és teljesítményproblémáinak azonnali megtalálása a Stackify Retrace segítségével
A kód hibaelhárítása és optimalizálása egyszerű az integrált hibák, naplók és kódszintű teljesítménybecslések segítségével.
Try today for free

Hasonlóságok

A Chef és a Puppet hasonlóságokat mutat abban, ahogyan a szerverek konfigurációit kezelik. Bár mindkét eszköz belsőleg másképp működik, az eredmény ugyanaz. Mindkét eszközzel kódon keresztül definiálhatjuk a kívánt állapotot. Mindkét eszköz master-csomópont architektúrával dolgozik, ahol a master felelős az összes adat tárolásáért, a csomópontok pedig azért, hogy a szerverek mindig a kívánt állapotú konfigurációval rendelkezzenek.

A Chef vagy a Puppet konfigurációkezelésre való használatának egyik fő célja például az, hogy kódként definiálhatjuk, hogy mi legyen egy szervercsoport kívánt állapota. Nem szabad, hogy baj legyen, ha ugyanazt a konfigurációt szeretné alkalmazni a szervereken, a Chef és a Puppet gondoskodik arról, hogy minden változtatást független módon hajtson végre. Ugyanígy mindannyian többször lenyomjuk a Ctrl + S billentyűkombinációt, hogy biztosan elmentsük a változtatásokat. De amiben az ilyen típusú eszközök ragyognak, az az, hogy ha valaki kézzel belép a szerverre, és megváltoztatja a szerver kívánt állapotát, ezek az eszközök a szerverek újrakonfigurálásával naprakésszé teszik a szervereket.

A felépítés szempontjából a Chef és a Puppet nagyon hasonlónak tűnik, mivel mindkettő master-agent architektúrát használ. Egy master csomóponton tárolják az összes szerverkonfigurációt. A masterek mindkét eszköz esetében magas rendelkezésre állásúak (HA), de némi különbséggel – erről később bővebben. Ezután minden egyes szerverre, amelyet kezelni akarsz, van egy telepített ügynök, amely automatikusan behúzza a konfigurációt az időszakokban. Az ügynökök mindig ellenőrzik, hogy a kívánt állapot megfelel-e, nem pedig fordítva. Mindkét eszköz képes Linux és Windows szerverek kezelésére.

Végül mindkét eszköznek van egy nyílt forráskódú és egy fizetős változata, amely több funkcióval rendelkezik, például jobb HA konfigurációval.

Különbségek

Már említettem, hogy a Chef és a Puppet felépítése hasonló, de a HA kezelésében kissé eltérnek. A Puppetben a master replikálja az adatait egy másik szerverre, és aktív/passzív módon működnek. A Chef esetében a HA-t három szerverrel kezelik aktív/aktív módban, egy API frontenddel, amely horizontálisan skálázható.

A Chef és a Puppet közötti jelentős különbség abban van, hogy hogyan határozzák meg a szerverek kívánt állapotkonfigurációját. Mindegyik eszköznek saját tartományspecifikus nyelve (DSL) van. A Chef a Ruby nyelvet használja a DSL-hez. Nagyobb szabadsága van az összetett konfigurációk létrehozásában, mivel programozási nyelvet használ. A Chef ezeket a kívánt állapotkonfigurációkat recepteknek nevezi, amelyeket írsz. Bármit, amit a Rubyval megtehetsz, a Chefben is megteheted, hogy recepteket hozz létre, például if-feltételeket vagy más könyvtárak hívását. Ennek az az előnye, hogy a fejlesztők talán kényelmesebben érzik magukat a Chef receptek írásában. Ráadásul a fejlesztők nem fogják úgy érezni, hogy csak egy DSL-re korlátozódnak, hozzáadva egy konfiguráció definiálásakor.”

A Puppetnek viszont van egy saját DSL-je, “amelyet úgy terveztek, hogy a rendszergazdák számára is elérhető legyen”. És ha van tapasztalatod a Nagios konfigurációs fájlokkal való munkában, akkor a manifesztek (a Chef receptjeinek a verziója) megírása nem lesz probléma. Itt nincs túl nagy szabadságod, de ez is jó abból a szempontból, hogy van egy univerzális nyelv. Ezért a Puppet használatához és megtanulásához nem kell fejlesztői háttérrel rendelkeznie.

Végül ezek az eszközök abban is különböznek, hogy hogyan fejleszti és teszteli a recepteket vagy a manifeszteket. A Chef rendelkezik egy, a Chef SDK-t tartalmazó munkaállomással, amelyet telepíthet a helyi számítógépére staging-környezetként. A recepteket helyben tesztelheti, majd feltöltheti a master csomópontra. A Puppetnek nincs munkaállomása, de van SDK-ja, ahol a manifesztek fejlesztése közben tesztelheti azokat. Ráadásul a manifeszteket helyben is alkalmazhatja a puppet apply paranccsal.

person wearing white apron walkin on stairs

Példák

Nézzünk egy kódpéldát arra, hogyan győződhetünk meg arról, hogy a Stackify ügynök telepítve van.

Egy recept a Chefben így fog kinézni (tiszta 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

A Puppetben van egy modul a Stackify ügynök telepítéséhez, és a manifeszt így fog kinézni:

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

Amint láthatjuk, a fenti kódpéldák megerősítik az előbb elmondottakat. A Chefben nagyobb szabadságod van. De a Puppetben egyszerűbbnek tűnhet a kód, ha van egy modul, amit használhatsz.

Premium funkciók

Vessük az összehasonlítást, beleértve a prémium funkciókat, amelyek a konfigurációkezelésen kívül más dolgokat is tartalmaznak.

A Puppet esetében van a Puppet Enterprise, amely a következő képességeket tartalmazza:

  • Reportok, amelyek segítenek a megfelelőségi irányelvek betartásában
  • Az alkalmazások és az infrastruktúra telepítésének archiválása
  • Automatizált infrastruktúra-ellátás az infrastruktúra mint kóddal
  • Kódkezelés az infrastrukturális változások automatikus előmozdításához
  • Kódkezelés a szerverek granuláris vezérléséhez
  • Role-alapú hozzáférés-szabályozás a felhasználók számára
  • Támogatás e-mailben vagy telefonon

A Puppet Remediate is rendelkezésükre áll, ami egy eszköz a szerverek sebezhetőségének kezelésére. Jobb betekintést nyerhetsz abba, hogy milyen sebezhetőségek vannak a szervereidben, és méretarányosan alkalmazhatsz javításokat az összes szerverre.

A Chefben a konfigurációkezelés mellett a fizetős verzió a következő képességeket tartalmazza:

  • Compliance és biztonsági menedzsment
  • CI/CD pipelines létrehozása és az összes alkalmazás kiadásainak kezelése
  • Láthatóság dashboardokkal az egész infrastruktúra stackre

Az egyes gyártók oldalán további részleteket kaphat, elég jó forrásaik vannak a gyors elinduláshoz.

person playing puppet dog

Hogyan válasszon

Hogyan válasszon a Chef és a Puppet között, az egy nehéz kérdés, és a válasz, mint mindig, … “attól függ.”

Bármelyik eszközt is választja, a döntésnek egy csapatban kell születnie, különösen azoktól, akik végül az eszközzel fognak dolgozni. Jó megközelítés lehet a csapat hátterének figyelembevétele. A sysadmin háttérrel rendelkező emberek talán alkalmasabbnak találják a Puppet használatát. Még ha meg is kell tanulniuk a DSL-t, ez sosem lesz olyan, mintha egy programozási nyelvet tanulnának. Bár, ha fejlesztői háttérrel rendelkeznek, az emberek talán jobban kedvelik a Chefet (még akkor is, ha nem ismerik a Ruby-t).

De figyelembe kell venni az egyes eszközök prémium funkcióit is. Melyik funkció segít a szervezetének a silók és a pazarlás csökkentésében? Ismétlem, minden az Ön igényeitől függ. Azt láttam, hogy mindkét gyártó mindig megpróbál kiegyenlítődni egymáshoz a funkciókkal. A Puppetben például Rubyval hozhat létre egyéni függvényeket.

És természetesen egy másik lényeges szempont az árképzés. Az árakat nem akarom ide sorolni, mert az nagyon ingadozik, és az egyes ügyfelek igényeitől függően változik. A másik ok, hogy a Puppet esetében az árazási oldalukon nincs nyilvános szám, csak egy “Kapcsolatfelvétel” gomb. A Chef viszont az árképzési oldalán van szám, de akkor is kapcsolatba kell lépni velük. Azt tanácsolnám, hogy vedd fel velük közvetlenül a kapcsolatot, és keress egy jó ajánlatot. Attól függően, hogy hány szervert kell kezelned, jobb árat tudnak ajánlani neked.

Nincs ezüstgolyó

Egy baráti emlékeztető, nincs ezüstgolyó egy konfigurációkezelő eszköz esetében. Mind a Chef, mind a Puppet nagyon érett manapság, és folyamatosan fejlesztik a terméküket, kutatási beruházásokat hajtanak végre, jobb módszereket hoznak létre, hogy az emberek megtanulják az eszközüket, stb. Remélem, hogy ez az összehasonlítás segített abban, hogy jobban megértse a két eszköz működését. Talán éppen egy állásinterjúra készülsz, vagy kíváncsi vagy a főbb különbségekre és hasonlóságokra.

De ha eldöntöd, hogy melyik eszközt használd a céged számára, győződj meg róla, hogy világos elképzelésed van arról, hogy milyen problémáid vannak, és hogy az ilyen típusú eszközök hogyan tudnak segíteni a teher enyhítésében. Mindig lesz egy tanulási folyamat, és a csapat hátterétől függ, hogy melyik eszköz a legmegfelelőbb számukra. Ezenkívül a konfigurációkezelésen kívül nézze meg a prémium funkciókat és szolgáltatásokat is, mivel lehet, hogy a vállalatának több segítségre van szüksége a megfelelőségi irányelvek tekintetében.

  • A szerzőről
  • Legutóbbi bejegyzések

Christian Melendezről

Christian Meléndez technológus, aki szoftverfejlesztőként kezdte, majd az utóbbi időben felhőarchitekt lett, aki folyamatos szállítási pipelinek megvalósítására összpontosít, többféle ízű alkalmazásokkal, köztük .NET, Node.js és Java, gyakran Docker konténerek használatával.

  • AWS Elastic Beanstalk .NET Core Getting Started – January 17, 2020
  • AWS Batch: Részletes útmutató az első munka elindításához – 2019. december 26.
  • Azure Container Service (AKS) – Részletes bevezetés – 2019. december 18.
  • CloudWatch Custom Metrics küldése Lambdából kódpéldákkal – 2019. november 14.
  • Chef vs Puppet: Különbségek, hasonlóságok és hogyan válasszunk – szeptember 24, 2019