Kiedy należy użyć menedżera konfiguracji (np. Puppet / Chef / Ansible)?

W moim obecnym miejscu pracy opiekuję się dwiema hostami VMware, fizyczną maszyną OpenBSD, trzema maszynami wirtualnymi Debiana i sześcioma maszynami wirtualnymi z systemem Windows Server (2008/2012).

Zastanawiam się nad wdrożeniem narzędzia do zarządzania konfiguracją, takiego jak Puppet lub Chef. Czy jest to uzasadnione, czy też narzut związany z nauką tego narzędzia przewyższy korzyści? Gdzie jest punkt zwrotny między zarządzaniem a kosztami wdrożenia?

IMHO warto się nauczyć, nawet jeśli zarządzasz tylko jednym serwerem,

Tak, pojawi się krzywa uczenia się. Tak, będziesz sfrustrowany. Jednak za te koszty otrzymasz wielokrotność poprzez niezawodne, spójne wdrożenia jednym kliknięciem, konfigurację serwera z kontrolą wersji, łatwość konfiguracji środowisk testowych / programistycznych itp.

Oprócz korzyści płynących z bieżącej pracy, możliwość dodania systemu CM do CV jest dużą wygraną. Oczekuje się, że współcześni sysadmini będą mieli przynajmniej kontakt z systemem zarządzania konfiguracją, jeśli nie biegłością.

(Sidenote: rozważ także Ansible. To mój ulubiony CM i bardzo łatwo go uruchomić - znacznie łatwiej niż w Puppet lub Chef. Dodatkowo obsługa okien w Ansible jest ładna.)

Zastanawiam się nad wdrożeniem narzędzia do zarządzania konfiguracją, takiego jak Puppet lub Chef. Czy jest to uzasadnione, czy też narzut związany z nauką tego narzędzia przewyższy korzyści?

Jest to uzasadnione w zależności od tego, ile czasu i pieniędzy musisz spalić, oraz od tego, czy to pieniądze, które spalasz, czy nie.

Narzędzie do zarządzania konfiguracją (dowolne z nich) staje się cenną umiejętnością na dzisiejszym rynku.

Poświęcenie czasu na naukę i wdrażanie narzędzia CM może nie być najbardziej wydajną rzeczą z punktu widzenia Twojej firmy lub środowiska, ale z twojego zestawu umiejętności może być opłacalne.

Gdzie jest punkt zwrotny między zarządzaniem a kosztami wdrożenia?

Większość narzędzi do zarządzania konfiguracją jest dostępna za darmo, z zastrzeżeniem, że trudniej je zainstalować i rozpocząć.

Na to pytanie trudno jest odpowiedzieć, ponieważ naprawdę zależy od tego, co robisz na co dzień, aby zarządzać tymi serwerami. Jeśli nie musisz wcale robić wiele, narzędzie do zarządzania konfiguracją może być całkowicie przesadzone.

Jeśli naprawdę potrzebujesz tylko zmusić infrastrukturę do przewidywalnego i podstawowego stanu, to może nie zaszkodzić wyłapać podstaw czegoś takiego jak SaltStack lub Ansible.

Z mojego osobistego doświadczenia, Salt jest bardzo łatwy do uruchomienia i ładowania na serwery, i może być używany do bardzo podstawowego zdalnego wykonywania i raportowania, co może się przydać, jeśli nie masz go już zaimplementowane w twoim środowisku.

Pamiętaj, że jestem stronniczy. Każde narzędzie CM należy ocenić samodzielnie.

Tak jak powiedział @EEAA - liczba serwerów nie ma znaczenia. Możesz czerpać korzyści z zarządzania konfiguracją na jednym komputerze:

• udokumentowana konfiguracja (udokumentowana za pomocą skryptów CM)
• niezawodne wdrożenie (możesz [ponownie] wdrożyć swoją konfigurację w kółko
• odporność konfiguracji (bieżące wykrzykiwania serwera - uruchom nowy)
• ponowne użycie (gdy dojdziesz do momentu posiadania drugiego serwera - masz już skrypty CM, które możesz przetworzyć z pierwszego)
• aktualizacje (to trochę jak nowa konfiguracja, tylko na innej platformie)

Mogę powiedzieć, że musiałem wdrażać CM dla wszystkich moich osobistych serwerów, ponieważ pracuję tam rzadko i zapominam o wszystkich drobnych szczegółach. Posiadanie skryptów CM może wydawać się czasochłonne (tak jest), a zwrot z inwestycji jest tego wart. W dłuższej perspektywie zaoszczędzisz znacznie więcej czasu, który poświęcisz na konfigurację.

Mam doświadczenie z Puppet and Ansible. Ansible jest IMO prostsze, ponieważ jest proceduralne, podczas gdy Puppet jest deklaratywny. Oba są wady i zalety, ale wyciągnąłem wystarczająco dużo włosów z powodu tajemniczych błędów Puppet.

Oba wymagają dużo pracy, jeśli chcesz stworzyć czystą konfigurację wielokrotnego użytku. Koszty zaczynają się naprawdę opłacać, jeśli masz co najmniej dwa bardzo podobne serwery, np. Chmury lub klastry.

Ma jednak pewne zastosowanie nawet w przypadku autonomicznych serwerów - możesz skonfigurować użytkowników administracyjnych, standardowe (z lokalnymi odmianami) konfiguracje sshd, postfix lub snmpd, a także używać ich do prostego zbierania informacji, takich jak przestrzeganie zasad lub testowanie podatności na shellshock.

Ponadto, jak wspomniano w EEAA, ma on wartość do udokumentowania instalacji, jeśli potwierdzisz, że naprawdę przenosi serwer ze stanu podstawowego do stanu działania. Dobrze jest połączyć go z systemem kontroli wersji (git), aby wprowadzone zmiany były wersjonowane i dokumentowane. Jest to bardzo cenne, jeśli masz zespół administratorów.

Puppet lub jakikolwiek inny system zarządzania przynosi ogromne korzyści, które zostały tutaj podkreślone przez inne odpowiedzi, ale nie ma srebrnej kuli, jeśli chodzi o zarządzanie.

Na przykład tworzenie klas marionetek dla złożonych systemów kosztuje dużo czasu i wysiłku, a czasem łez, ponieważ istnieje wiele pułapek, a komunikaty o błędach nie zawsze są w 100% wyraźne, a gdy aktualizujesz oprogramowanie, musisz poświęcić czas na dostosowanie klas marionetek do nowej specyfikacji lub procedurę i dowiedz się, które podejście najlepiej do tego nadaje (marionetka, na przykład deklaratywna, a ulepszenie jest zwykle proceduralne)

Musisz także dowiedzieć się, w jaki sposób planujesz wprowadzać zmiany wprowadzone w swoich klasach w kontrolowany sposób i jak zachować różne wersje manifestów.

Zastanów się również, jak przejść na aktualizację rozwiązania do zarządzania, gdy nadejdzie odpowiedni czas.

Jeśli poświęcasz znaczną ilość czasu na pisanie na przykład klas marionetek, musisz wykonać wiele instalacji jednym kliknięciem, aby czerpać rzeczywiste korzyści.

Polecam eksplorację nadal i tam, gdzie to właściwe, tj. Dystrybucja plików konfiguracyjnych może być dobrym miejscem do rozpoczęcia i zabrania go stamtąd.