Jakie są ograniczenia Puppet w porównaniu do Ansible?


17

Chciałbym zrozumieć różnice między Puppet i Ansible, zwłaszcza jakie ograniczenia ma Puppet w porównaniu z Ansible.

Czy są jakieś rzeczy, których nie możesz zrobić w Puppet, ale w Ansible? Innymi słowy, dlaczego niektórzy ludzie odchodzą od Puppet do Ansible?


Trzymałem swoją odpowiedź dobrze od siebie oddzieloną, jednym z powodów mogą być wszystkie pieniądze, które inwestuje w nią.
— ᴳᵁᴵᴰᴼ

Odpowiedzi:


20

Istnieje oczywiście kilka zalet i wad każdego z Puppet, Ansible, Chef i dodaj tutaj swoje ulubione narzędzie . Spróbuję więc trzymać się z dala od opinii i dzielić się tym, co jest świetne w Ansible.

Główną funkcją, która stawia Ansible nad innymi, nie jest konieczne poleganie na jakimś niestandardowym / dodatkowym agencie działającym na węzłach docelowych, zamiast tego opartym tylko na połączeniach ssh. Tak, nadal wymaga serwera ssh, Pythona i kilku bibliotek Pythona w węzłach, a jeśli twoja dystrybucja (lub, na szczęście, są pewne węzły systemu Windows) nie zostanie dostarczona z nimi, będzie trochę bolesne do bootstrap. Ale to mało prawdopodobne, a może nawet sprawić, że pomyślisz o swojej dystrybucji.

Uprości to monitorowanie, nie zje dodatkowych zasobów, nie zmusi systemu do ciągłego uruchamiania demona jako root, i ogólnie lepiej czuje się w filozofii UNIX. Szef kuchni chef-solo, Puppet można uruchomić bez opanowania, ale oba działają w „innym kierunku”, odpowiednio poprzez klonowanie i przechwytywanie. W przypadku Ansible scalenie w repozytorium źródłowym może spowodować wdrożenie w sposób, w którym wszyscy czujemy się komfortowo, czy to w Jenkins, w git master, czy w innym narzędziu, takim jak na przykład Rundeck.


Warto zauważyć, że jeśli pomieszałeś konfigurację ssh z ansible, jesteś zablokowany z komputera, to wada modelu push. Marionetka lub szef kuchni mogą pracować w trybie crontab, aby nie
— wpłynęli

1
Uwaga na temat agentów: Zostałem zatwierdzony na pokładzie Ansible w HSE (środowisko wysokiego bezpieczeństwa) przez zespół bezpieczeństwa, który odrzucił szefa kuchni i Marionetkę, nawet w konfiguracji bez mistrza. W niektórych przypadkach czynnik bezagentowy jest czynnikiem wygrywającym.
— Woodland Hunter

2
Jeśli przerwiesz konfigurację SSH, w każdym przypadku masz problemy wykraczające poza Ansible. Dobrą praktyką DevOps jest testowanie takich zmian, jak zmiany SSH w różnych środowiskach przed wejściem do produkcji, a także możliwe jest sprawdzenie poprawności konfiguracji SSH w ramach jej pisania - templatemoduł Ansible czyni to bardzo łatwym.
— RichVel,

Słyszałem, jak ludzie argumentowali, że architektura bez agenta Ansible czyni ją bardziej odpowiednią do zarządzania np. Routerami, w których nie można zainstalować agenta Puppet. Ale czy takie urządzenia są wyposażone w interpretery języka Python? Być może nie, więc czy Python jest naprawdę silnym wymaganiem dla każdego komponentu zarządzanego przez Ansible?
— Drux,

10

Nie, ludzie odchodzący od Puppet do Ansible (lub vice versa) nie mają nic wspólnego z tym, co można, lub czego nie można osiągnąć za pomocą żadnego z narzędzi. Puppet / Chef / Ansible - to głównie kwestia gustu.

Na przykład Ansible jest oparty na języku Python, a programiści języka Python zwykle czują się z nim lepiej (nie trzeba uczyć się DSL) lub Ruby (dla szefa kuchni). Łatwiej jest także programistom Python rozszerzyć Ansible.

Ale w gruncie rzeczy wszystkie są bardzo podobne pod względem tego, co można osiągnąć. Niektóre mają względne mocne strony w niektórych obszarach, a słabości w innych, ale zazwyczaj wybór między nimi zależy od stylu / kultury / preferencji zespołu.


8

Do czasu Puppet 4.0 nie było łatwego sposobu na zorganizowanie aplikacji rozproszonej na wielu serwerach lub usługach, ponieważ trudno było specjalnie zamówić akcje w Puppet, co było wyborem projektowym . Ansible był lepszy w organizowaniu i porządkowaniu kroków, szczególnie na wielu serwerach. Było to szczególnie istotne w aplikacjach, w których niewłaściwa kolejność kroków może prowadzić do błędów niewykrywalnych poprzez powtarzanie tych kroków, aż do osiągnięcia ostatecznej spójności.

To już nie jest problem, więc rozróżnienia są w dużej mierze oparte na preferencjach.


2
Wybór projektowej marionetki był jednym z powodów, dla których Chef zaczął, a główną rolę przeniosłem do Chef dla naszej infrastruktury i systemu CD kilka lat temu.
— Tensibai,

2
Orkiestracja marionetek jest tylko funkcją Puppet Enterprise (komercyjną), podczas gdy orkiestracja w Ansible jest w wersji open source. Ogólnie rzecz biorąc, Ansible jest o wiele łatwiejszy do zainstalowania i nauki niż Puppet - po dokonaniu oceny obu, teraz używam Ansible. Istnieją również inne różnice, więc nie jest to tylko kwestia osobistych preferencji.
— RichVel,

1
Korzystam z Ansible zarówno w mojej poprzedniej, jak i obecnej pracy, ale ma ona swoje własne problemy. Im więcej używam Ansible, tym bardziej jestem zainteresowany poznaniem innej alternatywy. Wolę tę alternatywę, aby nie używać Pythona do programowania modułów i mieć aktywną, ważną społeczność typu open source. Nasze prośby o wycofanie się z Ansible zajmują nawet prawie rok, aby je przejrzeć. W tym tempie może być równie zastrzeżone.
— Jiri Klouda

1
Wiele osób skarży się na agenta marionetek, ale kiedy jesteś w chmurze i masz grupę do automatycznego skalowania i nie chcesz odbudować obrazu swojej VM, dobrze jest, że VM łączy się z Master Puppet, nie widzę problemu z mieć małego agenta.
— c4f4t0r,
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.