Astăzi punem față în față două instrumente populare pentru managementul configurației; Chef vs Puppet. Aceste tipuri de instrumente îi ajută pe ingineri să mențină o configurație consistentă în toate serverele. De exemplu, toate serverele ar putea avea nevoie să aibă IIS cu o legătură la portul 443 pentru accesul HTTPS și regula de firewall respectivă pentru traficul de intrare. Mai important, dacă cineva elimină regula de firewall, aceste tipuri de instrumente vor menține consecvența prin crearea din nou a regulii de firewall.

Cum rămâne cu șirurile de conexiune la baza de date, unde aveți unul diferit pentru dev, test și prod?

Da, Puppet sau Chef se pot ocupa și de acestea.

Postul de astăzi este despre compararea lui Chef cu Puppet. Acestea sunt instrumente foarte asemănătoare care îndeplinesc același scop: menținerea unei stări consistente. Dar, ele diferă, de asemenea, în modul în care îi ajută pe utilizatori să mențină consistența și repetabilitatea în toată conducta de livrare. În cele din urmă, voi vorbi despre cum să alegeți un instrument în detrimentul celuilalt, în funcție de nevoile dumneavoastră și ale echipei dumneavoastră.

Așa că haideți să trecem la treabă.

Tip: Găsiți instantaneu erorile și problemele de performanță ale aplicațiilor cu Stackify Retrace

Descoperirea problemelor și optimizarea codului dvs. este ușoară cu ajutorul erorilor integrate, a jurnalelor și a informațiilor despre performanță la nivel de cod.

Similitudini

Chef și Puppet au asemănări în modul în care gestionează configurațiile în servere. Chiar dacă ambele instrumente lucrează în moduri diferite la nivel intern, rezultatul este același. Cu ambele instrumente, puteți defini starea dorită prin cod. Ambele instrumente funcționează cu o arhitectură maestru-nod în care maestrul se ocupă de stocarea tuturor datelor, iar nodurile se ocupă de a se asigura că serverele au întotdeauna configurația de stare dorită.

De exemplu, unul dintre principalele obiective ale utilizării Chef sau Puppet pentru gestionarea configurației este acela că puteți defini prin cod care ar trebui să fie starea dorită a unui grup de servere. Nu ar trebui să conteze dacă doriți să aplicați aceeași configurație serverelor, Chef și Puppet vor avea grijă să implementeze orice schimbare într-un mod independent. În același mod, cu toții apăsăm de mai multe ori pe Ctrl + S pentru a ne asigura că salvăm modificările. Dar acolo unde aceste tipuri de instrumente strălucesc este faptul că, dacă cineva intră manual în server și schimbă starea dorită a serverului, aceste instrumente vor aduce serverele la zi, reconfigurându-le.

Din punct de vedere al arhitecturii, Chef și Puppet arată destul de asemănător, deoarece ambele folosesc o arhitectură master-agent. Un nod master este locul unde sunt stocate toate configurațiile de server. Maeștrii pentru ambele instrumente sunt de înaltă disponibilitate (HA), dar cu mici diferențe – mai multe despre acest lucru mai târziu. Apoi, pentru fiecare server pe care doriți să îl gestionați, există un agent instalat care extrage automat configurația în perioade. Agenții verifică întotdeauna dacă starea dorită este conformă, nu invers. Ambele instrumente pot gestiona servere Linux și Windows.

În cele din urmă, ambele instrumente au o versiune open-source și o versiune cu plată cu mai multe caracteristici, cum ar fi o configurație HA mai bună.

Diferențe

Am mai spus înainte că arhitectura lui Chef și Puppet sunt similare, dar diferă ușor în ceea ce privește modul în care gestionează HA. În Puppet, masterul își replică datele pe un alt server și lucrează într-un mod activ/pasiv. În cazul lui Chef, HA este gestionat cu trei servere într-un mod activ/activ cu un front-end API care poate fi scalat pe orizontală.

O diferență semnificativă între Chef și Puppet este în modul în care definesc configurația de stare dorită pentru servere. Fiecare instrument are propriul său limbaj specific domeniului (DSL). Chef folosește Ruby pentru DSL. Aveți mai multă libertate pentru a crea configurații complexe, deoarece folosiți un limbaj de programare. Chef numește aceste configurații de stare dorită pe care le scrieți rețete. Tot ceea ce puteți face cu Ruby, puteți face în Chef pentru a crea rețete, cum ar fi if-conditions sau apelarea altor biblioteci. Beneficiul acestui lucru este că dezvoltatorii s-ar putea simți mai confortabil să scrie rețete Chef. Mai mult, dezvoltatorii nu se vor simți restricționați doar la un DSL, adăugând atunci când definesc o configurație.

Pe de altă parte, Puppet are propriul DSL, „care a fost conceput pentru a fi accesibil pentru administratorii de sistem”. Iar dacă aveți experiență în lucrul cu fișierele de configurare Nagios, scrierea manifestărilor (versiunea lor de rețete Chef) nu va fi o problemă. Nu aveți prea multă libertate aici, dar acest lucru este bun și din perspectiva de a avea un limbaj universal. Prin urmare, nu este nevoie să aveți un trecut de dezvoltator pentru a utiliza și a învăța Puppet.

În sfârșit, aceste instrumente diferă în ceea ce privește modul în care dezvoltați și testați rețetele sau manifestele. Chef are o stație de lucru care include Chef SDK pe care o puteți instala în computerul dvs. local ca mediu de pregătire. Puteți testa rețetele la nivel local, apoi le puteți încărca pe nodul principal. Puppet nu are o stație de lucru, dar are un SDK unde puteți testa manifestele în timp ce le dezvoltați. Mai mult decât atât, puteți aplica manifestările la nivel local cu comanda puppet apply.

Exemple

Să ne uităm la un exemplu de cod despre cum să ne asigurăm că agentul Stackify este instalat.

O rețetă în Chef va arăta astfel (pur 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

Pentru Puppet, există un modul pentru a instala agentul Stackify, iar manifestul va arăta astfel:

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

Cum puteți vedea, exemplele de cod de mai sus confirmă ceea ce am spus mai devreme. În Chef, aveți mai multă libertate. Dar în Puppet, codul ar putea părea mai simplu atunci când există un modul pe care îl puteți folosi.

Caracteristici premium

Să facem o comparație, inclusiv cu caracteristicile premium, care includ și alte lucruri în afară de gestionarea configurației.

Pentru Puppet, au Puppet Enterprise, care include următoarele capabilități:

• Raporturi care ajută cu politicile de conformitate
• Orchestrarea implementărilor de aplicații și infrastructură
• Automatizarea aprovizionării infrastructurii cu infrastructura ca și cod
• Gestiunea codului pentru a promova automat schimbările de infrastructură
• Gestiunea nodurilor pentru un control granular al serverelor
• Rolele-politici de control al accesului bazate pe roluri pentru utilizatori
• Suport prin e-mail sau telefonic

De asemenea, au Puppet Remediate, care este un instrument pentru gestionarea vulnerabilităților serverelor dvs. Puteți obține informații mai bune despre ce vulnerabilități există în serverele dvs. și puteți aplica patch-uri la scară la toate serverele.

La Chef, în afară de gestionarea configurației, versiunea cu plată include următoarele capabilități:

• Gestionarea conformității și a securității
• Creați conducte CI/CD și gestionați versiunile pentru toate aplicațiile
• Vizibilitate cu tablouri de bord în toată stiva dvs. de infrastructură

Obțineți mai multe detalii pe site-ul fiecărui furnizor, au resurse destul de bune pentru a vă ajuta să începeți rapid.

Cum să alegi

Cum să alegi între Chef și Puppet este o întrebare dificilă, iar răspunsul, ca întotdeauna, este … „depinde.”

Care instrument alegeți, ar trebui să fie o decizie de echipă, în special din partea celor care vor ajunge să lucreze cu instrumentul. O abordare bună ar putea fi luarea în considerare a trecutului echipei. Persoanele cu un background de sysadmin ar putea găsi mai potrivită utilizarea Puppet. Chiar dacă vor trebui să învețe DSL-ul, nu va fi niciodată ca și cum ar învăța un limbaj de programare. Deși, dacă au un background în dezvoltare, oamenilor le-ar putea plăcea mai mult Chef (chiar dacă nu cunosc Ruby).

Dar ar trebui să luați în considerare și caracteristicile premium de la fiecare instrument. Care dintre aceste caracteristici vor ajuta organizația dvs. să reducă silozurile și risipa? Din nou, totul depinde de nevoile dumneavoastră. Am văzut că ambii furnizori vor încerca întotdeauna să se ridice la același nivel cu celălalt în ceea ce privește caracteristicile. De exemplu, în Puppet, puteți crea funcții personalizate cu Ruby.

Și, desigur, un alt aspect esențial este prețul. Nu vreau să includ aici prețurile, deoarece acestea fluctuează foarte mult și variază în funcție de nevoile fiecărui client. Un alt motiv este că, în cazul Puppet, pagina lor de prețuri nu are un număr public, ci un buton „Contactați-ne”. Chef, pe de altă parte, pagina sa de prețuri are numere, dar tot trebuie să îi contactați. Te-aș sfătui să îi contactezi direct și să cauți o ofertă bună. În funcție de numărul de servere pe care trebuie să le gestionați, ei v-ar putea oferi un preț mai bun.

There’s No Silver Bullet

Ca un memento prietenos, nu există un glonț de argint pentru un instrument de gestionare a configurației. Atât Chef cât și Puppet sunt foarte mature în zilele noastre și își îmbunătățesc în mod constant produsul, fac investiții în cercetare, creează modalități mai bune pentru ca oamenii să învețe instrumentul lor, etc. Sper că această comparație v-a ajutat să înțelegeți mai bine cum funcționează ambele instrumente. Poate că vă pregătiți pentru un interviu de angajare sau sunteți curioși să aflați care sunt principalele diferențe și asemănări.

Dar dacă vă decideți ce instrument să folosiți pentru compania dvs., asigurați-vă că aveți o idee clară despre problemele pe care le aveți și despre modul în care acest tip de instrumente vă poate ajuta să ușurați sarcina. Întotdeauna va exista o curbă de învățare și va depinde de pregătirea echipei și de ce instrument este mai potrivit pentru ea. În plus, analizați caracteristicile și serviciile premium în afară de gestionarea configurației, deoarece compania dvs. ar putea avea nevoie de mai mult ajutor în ceea ce privește politicile de conformitate.

• Despre autor
• Ultimele postări

Despre Christian Melendez

Christian Meléndez este un tehnolog care a început ca dezvoltator de software și a devenit mai recent un arhitect cloud axat pe implementarea conductelor de livrare continuă cu aplicații în mai multe arome, inclusiv .NET, Node.js și Java, folosind adesea containere Docker.

• AWS Elastic Beanstalk .NET Core Getting Started – 17 ianuarie 2020
• AWS Batch: A Detailed Guide to Kicking Off Your First Job – 26 decembrie 2019
• Azure Container Service (AKS) – A Detailed Intro – 18 decembrie 2019
• Sending CloudWatch Custom Metrics From Lambda With Code Examples – 14 noiembrie 2019
• Chef vs Puppet: Diferențe, asemănări și cum să alegeți – 24 septembrie 2019

.