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

Planujemy używać instancji AMI EC2, które nie są wstępnie przygotowane. To znaczy, kiedy są uruchamiane, są to gołe instalacje AWS linux. Nasz proces ładowania początkowego pobierze różne instalacje, których potrzebujemy, np. Python, tomcat. Będziemy mieć minimum 3 instancje i maksymalnie 8.

Biorąc pod uwagę te wymagania, czy używanie Puppet / Chef byłoby przydatne zamiast korzystania z Amazon Cloud Formation (CloudInit)?

Najlepsze, co widzę, to to, że jeśli użyliśmy Puppet, mielibyśmy programowanie deklaratywne, które jest łatwiejsze do audytu, aby zobaczyć, co się dzieje, w porównaniu ze skryptem. Ponadto CloudInit ma limit rozmiaru skryptu 16k, na który możemy napotkać lub nie.

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

Czy jest przewaga nad CloudInit? Tak, oczywiście, wielu z nich!

Jasne, możesz pisać od góry do dołu, gdy skrypty CloudInit do obsługi administracyjnej serwera. Ale co się dzieje, gdy trzeba zmienić plik konfiguracyjny, dodać użytkownika, zaktualizować pakiet lub zainstalować nowy pakiet? Skończysz się logowaniem na serwerach lub pisaniem skryptów, aby to zrobić, i nieuchronnie niespójnym stanem serwerów.

CloudInit to nie zarządzanie konfiguracją. Jeśli zdecydujesz się rozpocząć korzystanie z oprogramowania do zarządzania konfiguracją, użyj Cloud init tylko do jednego zadania: do bootrapowania Puppet / Chef / innego agenta.

Puppet nie tylko pomaga zautomatyzować instalowanie pakietów, konfigurować klucze ssh lub dostrajać stertę Tomcat. Zapewnia stan rzeczy. Gdy programista rozwiązuje problem z aplikacją Java o 3 nad ranem i zmieni konfigurację Tomcata, Puppet przywróci ją. 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.

Gdy stos aplikacji się zmieni i zaczniesz używać, powiedzmy RabbitMQ, Jetty lub nowego RDBMS, możesz łatwo przetestować i wdrożyć zmiany na dziesiątkach lub tysiącach serwerów.

Istnieje wiele innych powodów, dla których warto używać oprogramowania do zarządzania konfiguracją, takich jak raportowanie zaplecza, inspekcja i zgodność z zabezpieczeniami.

Celem zarządzania konfiguracją jest przewidywalne i konsekwentne uruchamianie maszyn. CloudFormation i cloudinit są świetne, gdy ograniczasz się wyłącznie do AWS (chociaż debugowanie szablonów CloudFormation jest marnym doświadczeniem ), ale co z aplikacjami, które wykorzystują zarówno zasoby centrum danych, jak i AWS, lokalne środowiska testowe lub maszyny programistyczne?

Jeśli istniejesz wyłącznie w AWS, przypuszczam, że możesz uciec od cloudinit i nic więcej, ale nie jestem przekonany, że jest to realistyczne dla aplikacji dowolnej skali (na przykład Netflix wstępnie piecze AMI przy użyciu technologii OSS, które napisali i udostępniony światu; obejrzyj ten film, aby uzyskać szczegółowe informacje). Wysoko dostępne aplikacje są ponadregionalne, często oparte na VPC, mają tendencję do tworzenia kopii zapasowych w centrach danych w sieciach VPN, a to nie dotyczy nawet środowisk demonstracyjnych, testowych, testowych ani programistycznych. Jako osoba odpowiedzialna za udostępnianie maszyn ostatnią rzeczą, jaką chcę robić, jest powtarzanie pracy lub utknięcie w debugowaniu wielu metod obsługi administracyjnej.

Stąd szef kuchni lub marionetka. Działają tak samo dobrze dla AWS, jak dla mojego centrum danych, a także dla mojej maszyny deweloperskiej z systemem Vagrant , tak samo dobrze, jak w środowiskach demonstracyjnych, których czasami potrzebuję w locie. Wolałbym uruchomić Chef lub Puppet z cloudinit niż utrzymywać zarówno cloudinit, jak i Chef lub Puppet.

W przypadku serwerów wyrzuconych, powiedzmy, że działa za grupą autoskalowania, powiedziałbym, że prawdopodobnie wystarczy cloudinit. Skrypty powłoki Linux lub skrypty Windows PowerShell powinny załatwić sprawę.

Jeśli jest to serwer działający od dawna, planujesz zarządzać, być może szefem kuchni, marionetką lub dokerem, może dać ci przewagę, jak wspomniano w zaakceptowanej odpowiedzi. Jeśli nie widzisz korzyści po ich użyciu, prawdopodobnie nie potrzebujesz tego narzędzia.

Z mojego doświadczenia wynika, że ​​są proste rzeczy, które można łatwo zrobić za pomocą gotowych do użycia narzędzi GUI dostarczanych przez AWS, ale gdy wchodzisz w bardziej złożone rzeczy, zaczynasz odkrywać, że istnieją ograniczenia w tym, co możesz zrobić ich narzędzia.

W tym momencie możesz zatrzymać się lub 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.