Tip: Znajdź błędy aplikacji i problemy z wydajnością natychmiast dzięki Stackify Retrace

Troubleshooting i optymalizacja kodu jest łatwa dzięki zintegrowanym błędom, logom i wglądom w wydajność na poziomie kodu.

Podobieństwa

Chef i Puppet mają podobieństwa w sposobie zarządzania konfiguracjami w serwerach. Nawet jeśli oba narzędzia działają wewnętrznie w różny sposób, rezultat jest taki sam. W obu narzędziach można zdefiniować pożądany stan za pomocą kodu. Oba narzędzia działają w architekturze master-węzeł, gdzie master odpowiada za przechowywanie wszystkich danych, a węzły są odpowiedzialne za upewnienie się, że serwery zawsze mają pożądaną konfigurację stanu na miejscu.

Na przykład, jednym z głównych celów używania Chef lub Puppet do zarządzania konfiguracją jest to, że można zdefiniować jako kod, co powinno być pożądanym stanem grupy serwerów. Nie powinno mieć znaczenia, czy chcesz zastosować tę samą konfigurację na serwerach, Chef i Puppet zadbają o to, aby wdrożyć każdą zmianę w sposób niezależny. W ten sam sposób, wszyscy uderzamy Ctrl + S kilka razy, aby upewnić się, że zapisujemy zmiany. Ale gdzie tego typu narzędzia błyszczą jest to, że jeśli ktoś wejdzie na serwer ręcznie, i zmieni pożądany stan serwera, narzędzia te uaktualnią serwery poprzez ich ponowną konfigurację.

Z perspektywy architektury, Chef i Puppet wyglądają dość podobnie, ponieważ oba używają architektury master-agent. Węzeł główny to miejsce, w którym przechowywane są wszystkie konfiguracje serwerów. Węzły główne dla obu narzędzi są wysoce dostępne (HA), ale z niewielkimi różnicami – więcej na ten temat później. Następnie, dla każdego serwera, którym chcesz zarządzać, zainstalowany jest agent, który automatycznie pobiera konfigurację w okresach. Agenci zawsze sprawdzają, czy pożądany stan jest zgodny z wymaganiami, a nie na odwrót. Oba narzędzia mogą zarządzać serwerami Linux i Windows.

Na koniec, oba narzędzia mają wersję open-source i wersję płatną z większą ilością funkcji, takich jak lepsza konfiguracja HA.

Różnice

Powiedziałem wcześniej, że architektura Chefa i Puppeta jest podobna, ale różnią się one nieznacznie tym, jak obsługują HA. W Puppet, master replikuje swoje dane na inny serwer i działają one w sposób aktywny/pasywny. W przypadku Chefa HA jest obsługiwany przez trzy serwery w trybie aktywnym/aktywnym z interfejsem API, który może skalować się horyzontalnie.

Znacząca różnica między Chefem i Puppetem polega na tym, jak definiują one pożądaną konfigurację stanu serwerów. Każde narzędzie ma swój własny język specyficzny dla domeny (DSL). Chef używa Ruby jako DSL. Masz więcej swobody w tworzeniu złożonych konfiguracji, ponieważ używasz języka programowania. Chef nazywa te pożądane konfiguracje stanów recepturami, które piszesz. Wszystko, co możesz zrobić z Ruby, możesz zrobić w Chefie, aby stworzyć receptury, takie jak warunki if lub wywoływanie innych bibliotek. Korzyścią z tego jest to, że programiści mogą czuć się bardziej komfortowo pisząc receptury Chefa. Ponadto deweloperzy nie będą czuli się ograniczeni tylko do DSL, dodając podczas definiowania konfiguracji.

Z drugiej strony, Puppet ma swój własny DSL, „który został zaprojektowany tak, aby był dostępny dla sysadminów.” A jeśli masz doświadczenie w pracy z plikami konfiguracyjnymi Nagios, pisanie manifestów (ich wersja receptur Chef) nie będzie problemem. Nie masz tu zbyt dużej swobody, ale to też jest dobre z perspektywy posiadania uniwersalnego języka. Dlatego nie musisz mieć doświadczenia deweloperskiego, aby używać i uczyć się Puppet.

Na koniec, narzędzia te różnią się sposobem tworzenia i testowania receptur lub manifestów. Chef posiada stację roboczą zawierającą Chef SDK, którą możesz zainstalować na swoim lokalnym komputerze jako środowisko inscenizacyjne. Możesz testować receptury lokalnie, a następnie przesłać je do węzła głównego. Puppet nie ma stacji roboczej, ale ma SDK, w którym można testować manifesty podczas ich tworzenia. Co więcej, możesz zastosować manifesty lokalnie za pomocą polecenia puppet apply.

Przykłady

Przyjrzyjrzyjmy się przykładowi kodu, jak upewnić się, że agent Stackify jest zainstalowany.

Receptura w Chefie będzie wyglądała tak (czysty 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

Dla Puppeta istnieje moduł do zainstalowania agenta Stackify, a manifest będzie wyglądał tak:

 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 widać, powyższe przykłady kodu potwierdzają to, co powiedziałem wcześniej. W Chefie masz więcej swobody. Ale w Puppet, kod może wyglądać prościej, gdy istnieje moduł, którego możesz użyć.

Funkcje premium

Zróbmy porównanie, w tym funkcje premium, które obejmują inne rzeczy oprócz zarządzania konfiguracją.

Dla Puppet, mają Puppet Enterprise, który zawiera następujące możliwości:

• Raporty, które pomagają w realizacji polityk zgodności
• Orchestracja wdrożeń aplikacji i infrastruktury
• Automatyzacja dostarczania infrastruktury dzięki infrastrukturze jako kod
• Zarządzanie kodami w celu automatycznego promowania zmian w infrastrukturze
• Zarządzanie węzłami dla granularnej kontroli serwerów
• Role-based access control policies for users
• Support via email or phone

Posiadają również Puppet Remediate, który jest narzędziem do zarządzania podatnościami w serwerach. Możesz uzyskać lepszy wgląd w to, jakie podatności występują w Twoich serwerach, i zastosować poprawki na skalę do wszystkich serwerów.

W Chefie, oprócz zarządzania konfiguracją, płatna wersja zawiera następujące możliwości:

• Zarządzanie zgodnością i bezpieczeństwem
• Tworzenie potoków CI/CD i zarządzanie wydaniami dla wszystkich aplikacji
• Widoczność z pulpitami nawigacyjnymi w całym stosie infrastruktury

Więcej szczegółów można uzyskać na stronie każdego dostawcy, mają one całkiem dobre zasoby, aby pomóc Ci szybko zacząć.

Jak wybrać

Jak wybrać pomiędzy Chefem a Puppetem to trudne pytanie, a odpowiedź, jak zawsze, brzmi … „to zależy.”

Którekolwiek narzędzie wybierzesz, powinna to być decyzja zespołowa, szczególnie tych, którzy będą kończyć pracę z narzędziem. Dobrym podejściem może być rozważenie tła zespołu. Osoby z wykształceniem sysadminowskim mogą uznać, że bardziej odpowiednie będzie użycie Puppet. Nawet jeśli będą musieli nauczyć się DSL, to nigdy nie będzie to jak nauka języka programowania. Chociaż, jeśli mają doświadczenie w rozwoju, ludzie mogą polubić Chef’a bardziej (nawet jeśli nie znają Ruby).

Ale powinieneś również rozważyć funkcje premium z każdego narzędzia. Które z tych funkcji pomogą Twojej organizacji zredukować silosy i marnotrawstwo? Ponownie, wszystko zależy od Twoich potrzeb. Widziałem, że obaj dostawcy zawsze będą próbować wyrównać poziom między sobą za pomocą funkcji. Na przykład w Puppet, można tworzyć niestandardowe funkcje z Ruby.

I oczywiście, innym istotnym aspektem jest cena. Nie chcę tutaj podawać cen, ponieważ są one bardzo zmienne i zależą od potrzeb każdego klienta. Innym powodem jest to, że w przypadku Puppet, ich strona z cenami nie ma publicznego numeru, ale przycisk „Skontaktuj się z nami”. Chef, z drugiej strony, jego strona z cenami ma numery, ale nadal musisz się z nimi skontaktować. Radziłbym Ci skontaktować się z nimi bezpośrednio i poszukać dobrej oferty. W zależności od liczby serwerów, którymi musisz zarządzać, mogą zaoferować ci lepszą cenę.

There’s No Silver Bullet

Jako przyjazne przypomnienie, nie ma srebrnej kuli dla narzędzia do zarządzania konfiguracją. Zarówno Chef jak i Puppet są obecnie bardzo dojrzałe i ciągle ulepszają swoje produkty, dokonują inwestycji w badania, tworzą lepsze sposoby na naukę swoich narzędzi, itp. Mam nadzieję, że to porównanie pomogło Ci lepiej zrozumieć jak działają oba narzędzia. Może przygotowujesz się do rozmowy kwalifikacyjnej, lub jesteś ciekawy głównych różnic i podobieństw.

Jeśli jednak decydujesz, którego narzędzia użyć dla swojej firmy, upewnij się, że masz jasne pojęcie o tym, jakie problemy masz i jak tego typu narzędzia mogą pomóc Ci zmniejszyć obciążenie. Zawsze będzie krzywa uczenia się, a to będzie zależeć od tła zespołu i które narzędzie jest bardziej odpowiednie dla nich. Ponadto, spójrz na funkcje premium i usługi oprócz zarządzania konfiguracją, ponieważ Twoja firma może potrzebować więcej pomocy w zakresie polityki zgodności.

• O autorze
• Latest Posts

About Christian Melendez

Christian Meléndez jest technologiem, który rozpoczął pracę jako programista, a ostatnio stał się architektem chmury skoncentrowanym na wdrażaniu rurociągów ciągłego dostarczania z aplikacjami w kilku smakach, w tym .NET, Node.js i Java, często przy użyciu kontenerów Docker.

• AWS Elastic Beanstalk .NET Core Getting Started – January 17, 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
• Sending CloudWatch Custom Metrics From Lambda With Code Examples – November 14, 2019
• Chef vs Puppet: