Dlaczego warto używać Chef / Puppet zamiast skryptów powłoki?

Nowość w narzędziach Puppet i Chef. Wydaje się, że zadanie, które wykonują, można wykonać za pomocą skryptów powłoki. Być może było to zrobione w skryptach powłoki, dopóki się nie pojawiły.

Zgodziłbym się, że są bardziej czytelne. Ale czy są jakieś inne zalety w porównaniu ze skryptami powłoki poza tym, że są czytelne?

Język specyficzny dla domeny robi dużą różnicę w ilości pisanego kodu. Na przykład możesz argumentować, że nie ma dużej różnicy między:

chmod 640 /my/file

i

file { "/my/file":
    mode => 640,
}

ale między nimi jest duża różnica:

FILE=/my/file
chmod 640 $FILE
chown foo $FILE
chgrp bar $FILE
wget -O $FILE "http://my.puppet.server/dist/$FILE"
     # where the URL contains "Hello world"

i

file { "/my/file":
    mode => 640,
    owner => foo,
    group => bar,
    content => "Hello world",
}

Co się stanie, jeśli wget się nie powiedzie? Jak twój skrypt sobie z tym poradzi? A co się stanie, jeśli w twoim skrypcie jest coś, co wymaga $ FILE, aby był tam z poprawną zawartością?

Można argumentować, że można po prostu wstawić echo "Hello world" > $FILEskrypt, z wyjątkiem tego, że w pierwszym przykładzie skrypt musi zostać uruchomiony na kliencie, podczas gdy puppet kompiluje to wszystko na serwerze. Jeśli więc zmienisz zawartość, musisz ją tylko zmienić na serwerze i zmieni się ona na tyle systemów, ile chcesz ją zainstalować. A kukiełka automatycznie obsługuje zależności i przenosi problemy.

Po prostu nie ma porównania - odpowiednie narzędzia do zarządzania konfiguracją oszczędzają czas i złożoność. Im więcej próbujesz zrobić, tym więcej skryptów powłoki wydaje się niewystarczających i tym więcej wysiłku zaoszczędzisz, robiąc to z marionetką.

To będzie niepopularna opinia, ale systemy zarządzania konfiguracją niekoniecznie są lepsze. Czasami proste jest naprawdę najlepsze.

Istnieje pewna krzywa uczenia się i koszty administracyjne związane z wybranym systemem konfiguracji. W końcu wprowadzasz zależność. Podobnie jak w przypadku każdej automatyzacji, należy również zachować ostrożność, aby zachować bezpieczeństwo we wdrożonych konfiguracjach.

Miałem tylko kilka przypadków, w których wdrożyliśmy zarządzanie konfiguracją i utknęło. To było zawsze, gdy istniała duża liczba systemów z powtarzalną konfiguracją i potrzebą wykonania konfigurowalnych wdrożeń obcinarki plików cookie.

Odpowiedziałeś na swoje pytanie ...

Automatyzacja staje się coraz bardziej skalowalna i sformalizowana . Marionetka i szef kuchni są obecnie uważane za standardy (sprawdź ogłoszenia o pracę ).

Skrypty powłoki brukowane-razem mają swoje miejsce, ale oni nie skalowalne w kontekście ruchu devops. Czytelność jest tego częścią.

Chef znacznie ułatwia zarządzanie i wersjonowanie konfiguracji złożonej infrastruktury, szczególnie w każdym środowisku chmury, w porównaniu do konieczności ręcznego ftp lub scp kilka skryptów powłoki zorganizowanych w niestandardowy sposób. W zależności od liczby zależności, którymi musisz zarządzać, wielkość tej wygranej może się znacznie różnić, co sprawia, że ​​decyzja o przejściu na rozwiązanie CM jest dla wielu osób nieoczywista.

Prawdziwą (często nieoczekiwaną) korzyścią Szefa Kuchni jest idempotencja . Możliwość upewnienia się o stanie zasobu niezależnie od kombinacji receptur uruchamianych z nakładającymi się zainteresowaniami jest ogromną zaletą w porównaniu z konfiguracją skryptu powłoki. Jeśli masz teraz skrypty powłoki do konfiguracji, zadaj sobie pytanie, ile z nich można uruchomić wiele razy bez niezamierzonych / niepożądanych konsekwencji?

Odpowiednie rozwiązanie CM pomaga zapewnić sukces na dużą skalę, upraszczając automatyzację między platformami i współpracę zespołu. Chociaż można to wszystko osiągnąć za pomocą dobrze zorganizowanej, odpowiednio utrzymywanej, wersjonowanej grupy skryptów powłoki; musisz zadać sobie pytanie „dlaczego”. Szef kuchni / Puppet i podobne technologie powstały, ponieważ grupa utalentowanych SysOps była zmęczona ciągłym rozwiązywaniem tych samych problemów i postanowiła dać nam lepszą opcję.

Kluczowe elementy:

• Idempotencja
• Łatwość zarządzania zależnościami (wersja)
• Standaryzowana organizacja (akceptowana na poziomie branżowym)
• Abstrakcja w celu oddzielenia zadań konfiguracji serwera od szczegółów na poziomie systemu
• Zdolność do wykorzystania wiedzy społeczności (która gwarantuje przestrzeganie wszystkich powyższych zasad)

Nowoczesne narzędzia do zarządzania konfiguracją, takie jak Puppet i Chef, pozwalają określić stan systemu zamiast martwić się o działania niezbędne do uzyskania skonfigurowanego serwera.

Na przykład komenda chmod zakłada, że ​​plik istnieje, istnieje użytkownik będący jego właścicielem, że katalogi zostały utworzone itd. Dlatego twój skrypt musi uwzględniać wszystkie te warunki wstępne.

Stanowe narzędzia do zarządzania konfiguracją są prostsze: zależy Ci tylko na tym, aby plik miał odpowiednie uprawnienia. Problemem jest to, jak to osiągnąć.

Jeśli serwery są do dyspozycji lub masz powód, by stawać się więcej niż parą naraz, pełnowartościowy system CM znacznie lepiej zaspokoi twoje potrzeby niż seria skryptów powłoki.

Jeśli twoje potrzeby budowania są skromne (lub lubisz ręcznie wytwarzać organiczne serwery wolnego handlu z wolnego wybiegu), zachowaj prostotę.

Osobiście, intensywnie wykorzystując szefa kuchni na poprzednim koncercie, próbowałem „uprościć to” na tym koncercie, ale naprawdę brakowało mi prymitywów, abstrakcji i mocy, które zapewniał szef kuchni. Nawet jeśli dojdziesz do sytuacji, w której możesz uzyskać to, czego potrzebujesz, z kilku poleceń powłoki, możesz po prostu uruchomić te z blokiem „poleceń”, wprowadzając polecenia powłoki dokładnie tak, jak zapisujesz je w powłoce.

Powiedziawszy to, możesz uruchomić Chef bez serwera (szef kuchni solo), i jestem prawie pewien, że Puppet ma analog, w którym nadal możesz korzystać z książek kucharskich i przepisów innych bez uruchamiania centralnego serwera.

Kolejną korzyścią jest społeczność: jest wiele osób (z których wielu będzie mądrzejszych i / lub bardziej doświadczonych niż ty). Osobiście uwielbiam to, gdy ktoś inny wykonał dla mnie swoją pracę, często bardziej niż ja.

Stworzyłem strukturę automatyzacji serwera opartą na skryptach powłoki: https://github.com/myplaceonline/posixcube

Jestem pewien, że nie jestem pierwszym, który stworzył tego rodzaju projekt, ale nie mogłem znaleźć czegoś podobnego do moich potrzeb, więc pomyślałem, że inni mogą uznać to za przydatne. Miałem tylko doświadczenie z szefem kuchni, ale kiedy zacząłem rozglądać się za Ansible i innymi, chciałem spróbować skryptów powłoki i jak na razie podoba mi się wynik.