Pytanie Dlaczego ludzie używają Puppet / Chef z Amazon Cloud Formation zamiast używać tylko CloudInit?


Planujemy użyć instancji AMI EC2, które nie są "wstępnie upieczone". To znaczy. kiedy są spun-up, są to nieosłonięte instalacje systemu AWS Linux. Nasz proces ładowania pobiera różne instalacje, które są nam potrzebne, np. python, tomcat. Będziemy mieć minimum 3 wystąpienia i maksymalnie 8.

Biorąc pod uwagę te wymagania, czy korzystanie z Puppet / Chef byłoby bardziej przydatne niż korzystanie z Cloud Cloud Formation (CloudInit)?

Najlepszym, co mogę zobaczyć jest to, że jeśli użyjemy Puppet, będziemy mieli programowanie deklaratywne, które łatwiej poddać audytowi, aby zobaczyć, co się dzieje w porównaniu ze scenariuszem. Również CloudInit ma limit rozmiaru skryptu 16k, na który możemy lub nie możemy się natknąć.

Czy ktoś przeniósł się z CloudInit do Puppet lub Chef z konkretnego powodu, który mogą podać tutaj w odpowiedzi na moje pytanie?


76
2017-08-16 20:55


pochodzenie


Niektórzy ludzie (jak ja) używają prostych skryptów danych użytkownika (obsługiwanych przez chmurę-init) z CloudFormation. Dłuższe skrypty można pobrać z S3 i uruchomić za pomocą początkowego skryptu danych użytkownika. - Eric Hammond
cloud-init jest agnostyczny i korzysta z niego wielu dostawców usług w chmurze. Może działać na AWS, Google Cloud Platform i Microsoft Azure. (cloud-init.io) Natomiast AWS :: CloudFormation :: Init nie jest agnostyczny. Jest to specyficzne dla Amazona. - Jordan Stewart


Odpowiedzi:


Czy istnieje przewaga nad CloudInit? Tak, absolutnie, wielu z nich!

Oczywiście, możesz pisać od góry do dołu, gdy skrypty CloudInit dostarczą serwer. Ale co się dzieje, gdy trzeba zmienić plik konfiguracyjny, dodać użytkownika, zaktualizować pakiet lub zainstalować nowy pakiet? Kończy się logowanie do serwerów lub pisanie skryptów, aby to zrobić, i nieuchronnie niepoprawny stan serwerów.

CloudInit nie jest zarządzaniem konfiguracją. Jeśli zdecydujesz się rozpocząć korzystanie z oprogramowania do zarządzania konfiguracją, skorzystaj z Cloud init dla jednego zadania: aby sprowokować Puppet / Chef / innego agenta.

Puppet nie tylko pomaga w automatyzacji instalowania pakietów, ustawianiu kluczy ssh lub dostrajaniu sterty Tomcat. Zapewnia stan rzeczy. Gdy programista rozwiązuje problem z aplikacją Java o 3 rano i zmieni konfigurację Tomcat, Puppet zmieni ją z powrotem. Możesz szybko zmienić wersję Pythona dla wszystkich lub grup węzłów, a jeśli ktoś zainstaluje inną wersję, Puppet zmieni ją z powrotem.

Kiedy stos aplikacji zmienia się i zaczynasz używać, powiedzmy RabbitMQ lub Jetty, lub nowy RDBMS, możesz łatwo testować i wdrażać zmiany na dziesiątkach lub tysiącach serwerów.

Istnieje wiele innych powodów korzystania z oprogramowania do zarządzania konfiguracją, takiego jak raportowanie, raportowanie i zgodność z przepisami.


75
2017-08-17 00:50



To zależy. W przypadku długotrwałych usług (zazwyczaj AD, DB) może być potrzebne zarządzanie konfiguracją. Ale na inne wymienne serwery do rzucania, nie do końca; serwery sieciowe zarządzane w ASG, węzły klastra w trybie hadoop lub elasticsearch. Gdybym miał zmienić konfigurację, po prostu wyrzuciłbym serwer i uruchomiłbym nowy. - Sleeper Smith


Cały punkt zarządzania konfiguracją polega na przewidywalnym i konsekwentnym uruchamianiu maszyn. CloudFormation i cloudinit są świetne, gdy jesteś ograniczony wyłącznie do AWS (chociaż debugowanie szablonów CloudFormation to nędzne doświadczenie), ale co z aplikacjami, które korzystają z zasobów centrum danych i AWS, lokalnych środowisk testowych lub maszyn programistycznych?

Jeśli istniejesz tylko w AWS, to prawdopodobnie możesz uciec z cloudinitem i niczym więcej, ale nie jestem przekonany, że jest to realistyczne dla aplikacji o dowolnej skali (na przykład Netflix, wcześniej piecze ich AMI za pomocą technologii OSS, które napisali i wypuszczony na świat, rozważ ten film dla szczegółów). Wysoce dostępne aplikacje są transregionalne, często oparte na VPC, mają tendencję do tworzenia kopii zapasowych w centrach danych w sieciach VPN, a to nawet nie dotyczy środowisk demonstracyjnych, testowych i programistycznych. Jako osoba, która jest obciążona kosztami obsługi urządzeń ostatni, ubiegły, zeszły rzeczy, które chcę zrobić, to powtórzyć pracę lub utknąć przy debugowaniu wielu metod udostępniania.

Stąd szef kuchni lub marionetka. Działają równie dobrze dla AWS, jak dla mojego centrum danych, i równie dobrze dla mojej maszyny programistycznej Włóczęga tak jak w przypadku środowisk demonstracyjnych, które czasami potrzebuję w locie. Wolałbym uruchomić Chef'a lub Puppeta z Cloudinit niż utrzymać zarówno chmurę, jak i Chef lub Puppet.


61
2017-08-17 12:08



@ U0001: poprawiono link do wideo - Christopher


Jeśli chodzi o wyrzucanie serwerów, powiedzmy, że działasz za grupą autoskalowania, powiedziałbym, że cloudinit prawdopodobnie wystarczy. skrypty powłoki linux lub skrypty powłoki systemu Windows powinny załatwić sprawę.

Jeśli długo działający serwer, który planujesz zarządzać kucharzem, marionetką lub dokiem, może dać ci przewagę, o której mowa w zaakceptowanej odpowiedzi. Jeśli nie widzisz przewagi po ich użyciu, prawdopodobnie nie potrzebujesz tego narzędzia.


5
2018-02-04 20:09



Całkowicie się zgadzam. Marionetka i szef kuchni są skomplikowane i jeśli możesz wymienić serwer po prostu usuwając i wywołując nowy - to faktycznie zniechęciłbym ich do używania. Istnieją pewne scenariusze, że lalka / szef kuchni są świetne, ale musisz zważać na dodatkową złożoność używania w każdym scenariuszu. - bobmarksie


Z mojego doświadczenia wynika, że ​​są proste rzeczy, które można łatwo wykonać za pomocą gotowych narzędzi GUI, które oferuje AWS, ale gdy wchodzisz w bardziej skomplikowane rzeczy, zaczynasz odkrywać, że istnieją ograniczenia co do tego, co możesz zrobić po prostu ich narzędzia.

W tym momencie możesz przestać lub możesz znaleźć inne narzędzia (takie jak Chef lub Puppet), które pomogą ci osiągnąć te bardziej złożone cele, a także zrobić prostsze rzeczy.

Twój wybór.


0
2018-04-22 22:45