Puppet vs Chef, pro i contra od użytkowników i przypadków użycia [zamknięte]

Już googlowałem i czytałem artykuł „to-marionetka lub szef kuchni-to-pytanie” .

Interesują mnie przypadki użycia, implementacje w świecie rzeczywistym, w których ludzie wybrali jedną lub drugą na podstawie rzeczywistych problemów.

Szczególnie interesuje mnie integracja z zagadnieniami szewca (wiem, że marionetka jest w tym kierunku standardowym podejściem); jak ktoś ma jakieś doświadczenie w integracji szewca-szefa kuchni ?

Z góry dziękuję

Szczerze mówiąc, myślę, że sprowadza się to do prostego punktu widzenia: szef kuchni wydaje się bardziej imperatywnym, programowym rozwiązaniem, użycie ruby ​​jako języka natychmiast sprawia, że ​​mam nadzieję, że ktoś przeniósł go na python, podobnie jak świat z całym pomysły Ruby.

Jednak nie tego chcesz. Chcesz porozmawiać z pustką, gdzie będzie system i zadeklarować:

„Przywołując port 80 z północy demon o imieniu nginx. Jego zadaniem jest służyć”.

„Użytkownik powinien istnieć, jego imię powinno być chiggsy i powinien być jednym z potężnych w grupie kół”

„Podnieś cienką ścianę ognia w miejscach 80,443,8080”

I tak dalej, chociaż być może w języku mniej kwiecistym.

Puppet wspiera ten paradygmat lepiej IMO. Użyłbym jednego z nich, nie miałem preferencji, ale jeśli chodzi o to, deklaracja bardziej mi odpowiadała.

Marionetka.

Napisałem szczegółowe porównanie Chef vs Puppet tutaj: Puppet vs Chef: 10 powodów, dla których Puppet wygrywa . Chociaż nie obejmuje przypadków użycia, mam nadzieję, że zapewnia kilka użytecznych punktów wyjścia dla osób zastanawiających się, które narzędzie wybrać do automatyzacji infrastruktury.

Przepraszam za gadatliwość. Skorzystaj z narzędzia, które ułatwia wykonanie pracy. To jest punkt automatyzacji, prawda?

Historia: Używałem marionetki na poprzednich koncertach, aw zeszłym miesiącu spędziłem około tygodnia próbując przyzwyczaić się do szefa kuchni, aby sprawdzić, czy dokonam zmiany na moim nowym koncercie.

Nie skoczyłem.

Żargon: Jednym z niefortunnych problemów w obu systemach jest przeciążenie żargonem. (przepisy, szablony, węzły, role, atrybuty, dostawcy) To trwa. Przekonałem się, że szef kuchni zrobił krok dalej. (Nóż, shef itp.)

Dojrzałość kodu: Wystarczy powiedzieć, że uważam szefa kuchni za trochę zbyt surowego. Czuje się bardzo podobnie do tego, jak czuła się marionetka w przedziale czasowym .21 / .22 3-4 lata temu. Dużo się dzieje.

Nie mówiąc już, że nie zdarzyło się to również w marionetce. (Odkryłem wiele wspaniałych cech kukiełki, które pojawiły się dopiero w ciągu ostatnich kilku lat. - dopasowywanie wyrażeń regularnych!)

Ruby: Nie podobało mi się to całe przeciążenie rubinem w Chef. (potrzebujesz klejnotu i prowizji, zanim będziesz mógł zacząć) Możesz użyć rubinu, aby rozwiązać złożone problemy w lalkowym a'la facterze, ale nie musisz tego robić, jeśli nie chcesz.

Złożoność: Nie podobało mi się skupienie GUI na szefie kuchni. Zdaję sobie sprawę, że jest ładna, a kukiełka ma interfejs pracujący jako dodatek, ale uważam, że powinna być bardziej oddzielona.

Szef kuchni ma znacznie bardziej złożoną architekturę. Może lepiej skalować, ale istnieje wiele potencjalnych punktów awarii.
http://wiki.opscode.com/display/chef/Architecture

Oprócz serwera API i interfejsu sieciowego szef kuchni potrzebuje couchdb, rabbitmq i solr.

Chcę tylko prostego interfejsu klient / serwer, który nie wymaga na nim frameworka MVC i złożonego magazynu danych.

Marionetka jest o wiele prostsza w tym dziale. (nie wspominając o tym, że nie ma wielu dodatków, które sprawią, że będzie bałagan)

Wykonanie pracy: w końcu poszedłem z tym, co wiedziałem. Po tygodniu spędzonym na hakowaniu bocznym i ledwie w stanie opanować podstawy pracy z szefem kuchni, mogłem wrócić do marionetki i w kilka godzin zaspokoić swoje podstawowe potrzeby. (zarządzanie pakietami, zarządzanie użytkownikami, szablony plików konfiguracyjnych)

Zastrzeżenie dotyczące modułów: Puppet ostatnio przeszedł na używanie „modułów”, które są udostępniane przez osoby trzecie. Nie wykorzystałem ich i znalazłem szeroki zakres pod względem jakości. Pamiętaj, aby zajrzeć pod kołdrę i zobaczyć, co i jak działają, zanim się do nich zagłębisz.

Oto opinia: Wypróbowaliśmy je wszystkie w naszej firmie i preferujemy marionetkę. Po prostu dlatego, że jest łatwy w użyciu.

Sam widziałem przypadki, w których zarządzanie 1000 hostami z różnymi konfiguracjami jest znacznie łatwiejsze dzięki marionetce. Faktyczne firmy, takie jak Google, używają marionetki do wdrażania.

Główna architektura projektowa marionetki jest taka, że ​​działa znacznie lepiej niż inne, jeśli odpowiednio ją skonfigurujesz. Na przykład dodając własne fakty do niestandardowych konfiguracji itp. Poniższe linki mogą dostarczyć informacji http://slashroot.in/puppet-tutorial-installing-puppet-master-and-puppet-agent

http://slashroot.in/puppet-tutorial-how-does-puppet-work

Mogło się to zmienić od czasu, gdy ostatnio go wypróbowałem, ale kiedy próbowałem szefa kuchni na RHEL, nie było jasnego sposobu, aby go zainstalować. Ktoś stworzył repozytorium mniam, które wymagało wszystkich pakietów, ale ostatecznie zainstalował 200 pakietów nieparzystych. Z drugiej strony, Puppet ma jedno obroty na minutę (i kilka zależności).