Chef vs Puppet:
Dnes proti sobě postavíme dva populární nástroje pro správu konfigurace: Chef vs. Puppet. Tyto typy nástrojů pomáhají inženýrům udržovat konzistentní konfiguraci na všech serverech. Například všechny servery mohou potřebovat službu IIS s vazbou na port 443 pro přístup HTTPS a příslušné pravidlo brány firewall pro příchozí provoz. Ještě důležitější je, že pokud někdo odstraní pravidlo brány firewall, nástroje tohoto typu zachovají konzistenci tím, že pravidlo brány firewall vytvoří znovu.
A co řetězce připojení k databázi, kde máte jiné pro dev, test a prod?
Ano, Puppet nebo Chef si poradí i s nimi.
Dnešní příspěvek je o porovnání Chefu s Puppetem. Jedná se o velmi podobné nástroje, které dosahují stejného cíle: udržování konzistentního stavu. Liší se však také v tom, jak pomáhají uživatelům udržovat konzistenci a opakovatelnost v celém dodavatelském potrubí. Nakonec se zmíním o tom, jak si vybrat jeden nástroj místo druhého v závislosti na vašich potřebách a potřebách vašeho týmu.
Takže pojďme na to.
Podobnosti
Chef a Puppet mají podobnosti ve způsobu správy konfigurací na serverech. I když oba nástroje interně pracují různými způsoby, výsledek je stejný. U obou nástrojů můžete definovat požadovaný stav prostřednictvím kódu. Oba nástroje pracují s architekturou master-node, kde master má na starosti ukládání všech dat a uzly se starají o to, aby servery měly vždy požadovanou konfiguraci stavu.
Jedním z hlavních cílů použití Chefu nebo Puppetu pro správu konfigurace je například to, že můžete jako kód definovat, jaký má být požadovaný stav skupiny serverů. Nemělo by záležet na tom, zda chcete na servery použít stejnou konfiguraci, Chef a Puppet se postarají o to, aby byla každá změna implementována nezávisle. Stejně tak všichni několikrát stiskneme Ctrl + S, abychom se ujistili, že změny ukládáme. V čem však nástroje tohoto typu vynikají, je to, že pokud někdo vstoupí do serveru ručně a změní požadovaný stav serveru, tyto nástroje aktualizují servery tím, že je znovu nakonfigurují.
Z hlediska architektury vypadají Chef a Puppet dost podobně, protože oba používají architekturu master-agent. V hlavním uzlu jsou uloženy všechny konfigurace serverů. Mastery obou nástrojů jsou vysoce dostupné (HA), ale s drobnými rozdíly – o tom později. Pak je pro každý server, který chcete spravovat, nainstalován agent, který automaticky stahuje konfiguraci v periodách. Agenti vždy kontrolují, zda je požadovaný stav v souladu, nikoli naopak. Oba nástroje mohou spravovat servery se systémem Linux i Windows.
Nakonec, oba nástroje mají verzi s otevřeným zdrojovým kódem a placenou verzi s dalšími funkcemi, jako je lepší konfigurace HA.
Rozdíly
Již dříve jsem řekl, že architektura Chefu a Puppetu je podobná, ale mírně se liší v tom, jak zpracovávají HA. V Puppetu master replikuje svá data na jiný server a pracují aktivním/pasivním způsobem. U Chefu se HA řeší pomocí tří serverů v režimu active/active s rozhraním API front end, které lze horizontálně škálovat.
Významný rozdíl mezi Chefem a Puppetem je v tom, jak definují požadovanou konfiguraci stavu serverů. Každý nástroj má svůj vlastní doménově specifický jazyk (DSL). Chef používá pro DSL jazyk Ruby. Máte větší volnost při vytváření složitých konfigurací, protože používáte programovací jazyk. Chef tyto požadované stavové konfigurace nazývá recepty, které píšete. Cokoli, co můžete udělat v jazyce Ruby, můžete udělat v Chefu při vytváření receptů, jako jsou if-podmínky nebo volání jiných knihoven. Výhodou je, že vývojáři se mohou cítit pohodlněji při psaní receptů Chef. Vývojáři se navíc nebudou cítit omezeni pouze na DSL, když přidají při definování konfigurace.
Na druhou stranu má Puppet vlastní DSL, „který byl navržen tak, aby byl přístupný pro sysadminy“. A pokud máte zkušenosti s prací s konfiguračními soubory Nagios, nebude pro vás psaní manifestů (jejich verze receptů Chef) problém. Příliš volnosti zde nemáte, ale to je z hlediska existence univerzálního jazyka také dobře. Proto nemusíte mít vývojářské vzdělání, abyste mohli používat a učit se Puppet.
Nakonec se tyto nástroje liší ve způsobu vývoje a testování receptů nebo manifestů. Chef má pracovní stanici včetně Chef SDK, kterou můžete nainstalovat do místního počítače jako stagingové prostředí. Recepty můžete testovat lokálně a poté je nahrát do hlavního uzlu. Puppet nemá pracovní stanici, ale má sadu SDK, kde můžete testovat manifesty během jejich vývoje. Kromě toho můžete manifesty aplikovat lokálně pomocí příkazu puppet apply.
Příklady
Podívejme se na příklad kódu, jak zajistit instalaci agenta Stackify.
Recept v Chefu bude vypadat takto (čistě 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
Pro Puppet existuje modul pro instalaci agenta Stackify a manifest bude vypadat takto:
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, }
Jak vidíte, výše uvedené příklady kódu potvrzují to, co jsem řekl dříve. V systému Chef máte větší volnost. Ale v Puppetu může kód vypadat jednodušeji, když existuje modul, který můžete použít.
Premium funkce
Podívejme se na srovnání, včetně prémiových funkcí, které zahrnují další věci kromě správy konfigurace.
Pro Puppet mají Puppet Enterprise, který zahrnuje následující funkce:
- Zprávy, které pomáhají se zásadami shody
- Orchestrace nasazení aplikací a infrastruktury
- Automatizace poskytování infrastruktury pomocí infrastruktury jako kódu
- Správa kódu pro automatickou podporu změn infrastruktury
- Správa uzlů pro granulární kontrolu serverů
- Role-založené na zásadách řízení přístupu pro uživatele
- Podpora prostřednictvím e-mailu nebo telefonu
Mají také Puppet Remediate, což je nástroj pro správu zranitelností vašich serverů. Můžete získat lepší přehled o tom, jaké zranitelnosti se na vašich serverech vyskytují, a aplikovat záplaty ve velkém měřítku na všechny servery.
U nástroje Chef obsahuje placená verze kromě správy konfigurace tyto funkce:
- Správa shody a zabezpečení
- Vytváření potrubí CI/CD a správa verzí pro všechny aplikace
- Přehled pomocí ovládacích panelů napříč celým stackem infrastruktury
Další podrobnosti získáte na stránkách jednotlivých dodavatelů, mají docela dobré zdroje, které vám pomohou rychle začít.
Jak si vybrat
Jak si vybrat mezi Chefem a Puppetem je těžká otázka a odpověď jako vždy zní … „záleží na tom.“
Ať už si vyberete jakýkoli nástroj, mělo by to být rozhodnutí týmu, zejména těch, kteří s ním budou nakonec pracovat. Dobrým přístupem by mohlo být zvážení zázemí týmu. Lidem se zkušenostmi sysadmina by mohlo více vyhovovat použití nástroje Puppet. I když se budou muset naučit DSL, nikdy to nebude jako učit se programovací jazyk. I když, pokud mají zázemí v oblasti vývoje, lidem by se mohl více líbit Chef (i když neznají Ruby).
Měli byste také zvážit prémiové funkce jednotlivých nástrojů. Které z těchto funkcí pomohou vaší organizaci omezit siláž a plýtvání? Opět záleží na vašich potřebách. Viděl jsem, že oba dodavatelé se budou vždy snažit vzájemně se vyrovnat funkcemi. Například v nástroji Puppet můžete vytvářet vlastní funkce pomocí jazyka Ruby.
A samozřejmě dalším podstatným aspektem je cena. Nechci zde uvádět ceny, protože hodně kolísají a liší se v závislosti na potřebách jednotlivých zákazníků. Dalším důvodem je, že v případě společnosti Puppet nemá jejich stránka s cenami veřejné číslo, ale tlačítko „Kontaktujte nás“. Naproti tomu společnost Chef na své cenové stránce čísla má, ale i tak je třeba ji kontaktovat. Doporučil bych vám kontaktovat je přímo a hledat výhodnou nabídku. V závislosti na počtu serverů, které potřebujete spravovat, by vám mohli nabídnout lepší cenu.“
Stříbrná kulka neexistuje
Přátelsky připomínám, že pro nástroj pro správu konfigurace neexistuje stříbrná kulka. Chef i Puppet jsou dnes velmi vyspělé a neustále své produkty vylepšují, investují do výzkumu, vytvářejí lepší způsoby, jak se lidé mohou jejich nástroj naučit, atd. Doufám, že vám toto srovnání pomohlo lépe pochopit, jak oba nástroje fungují. Možná se připravujete na pracovní pohovor nebo vás zajímají hlavní rozdíly a podobnosti.
Pokud se ale rozhodujete, který nástroj použít pro vaši společnost, ujistěte se, že máte jasnou představu o tom, jaké problémy máte a jak vám tento typ nástrojů může pomoci zátěž zmírnit. Vždy bude existovat křivka učení a bude záležet na zázemí týmu a na tom, který nástroj je pro něj vhodnější. Kromě toho se kromě správy konfigurace podívejte i na prémiové funkce a služby, protože vaše společnost může potřebovat více pomoci se zásadami shody.
- O autorovi
- Nejnovější příspěvky
O Christianu Melendezovi
Christian Meléndez je technolog, který začínal jako softwarový vývojář a v poslední době se stal cloudovým architektem zaměřeným na implementaci potrubí kontinuálního dodávání s aplikacemi v několika variantách, včetně .NET, Node.js a Java, často s využitím kontejnerů Docker.
- AWS Elastic Beanstalk .NET Core Getting Started – 17. ledna 2020
- AWS Batch: Podrobný průvodce zahájením první úlohy – 26. prosince 2019
- Azure Container Service (AKS) – podrobné seznámení – 18. prosince 2019
- Odesílání vlastních metrik CloudWatch z Lambda s příklady kódu – 14. listopadu 2019
- Chef vs Puppet: