Puppetize wszystko czy nie?

Uwaga: jest wiele pytań teoretycznych.

Ostatnio czytam o Puppet (i podobnych systemach), które - jak wierzę - mogą znacznie ułatwić mi pracę. Ale staram się - i niestety nie mogę - zrozumieć, co mogę „marionetkować”. Mogę sobie wyobrazić „chmury” lub klastry HA, gdzie jest taka sama konfiguracja na większej liczbie serwerów. Ale co ze stacjami roboczymi? Mam jeden komputer (centos z KVM), jeden notebook (fedora) i osobisty serwer, czy (lub powinien) być lalkowany? Jakie są (nie) zalety? Lub w naszej firmie mamy setki serwerów (głównie centos), ale każdy z nich jest nieco inny. Nie mogę się zdecydować, czy lepiej jest mieć wiele konfiguracji w jednym miejscu .. (Dis) zalety? Będę szczęśliwy dla wszystkich twoich opinii lub linków do tego tematu.

Stopień marionetkowania całego środowiska zależy od kilku zmiennych:

• Gotowość personelu automatyki do napisania automatyki dla każdego. mało. rzecz.
• Uwarunkowania kulturowe, które pozwalają „Po prostu zmienię tę jedną rzecz, to i tak jest jednorazowe”, aby zmienić się w „Po prostu zmienię tę jedną rzecz w tym manifestie marionetkowym i zastosuję ją teraz; to tylko jednorazowa . ”
• Stopień heterogeniczności w środowisku.

Zdecydowanie można marionetkować każdą ********** rzecz, którą można marionetkować, ale dotarcie tam wymaga odpowiedniej kultury i wpisowego od każdego, kto może dotknąć urządzenia zdolnego do marionetek. Niektóre urządzenia są zasadniczo trudne w zarządzaniu w ten sposób, takie jak stacje robocze, a marionetka jest lepszym narzędziem do przemieszczania niż silnik zarządzania konfiguracją.

Puppet jest niesamowity, gdy zarządzasz flotą maszyn wirtualnych, które w zasadzie robią to samo. Całkowita wygrana i niewiele wysiłku, aby się tam dostać.

Na drugim końcu spektrum masz to, co miałem podczas mojej ostatniej pracy, którą było ponad 200 serwerów świadczących 130 usług i tylko niewielka ich grupa na więcej niż jednej maszynie. Są absolutnie firmy (i uniwersytety), które zrobiły tego rodzaju marionetkę, ale jest to duży wysiłek i wymaga dużego wkładu. Wymaga to, aby pierwszym krokiem procesu wdrażania na nowej maszynie nie była „Zainstaluj system operacyjny”, ale „utwórz manifesty”.

Ostatecznie jest to problem kulturalny związany z wydajnością i wydajnością, który będziesz musiał rozwiązać wśród wszystkich swoich pracowników IT.

Wszystko, co jest dość podobne we wszystkich systemach (lub ich podzbiorze), lub że możesz oprzeć szablon na fakcie, z którego możesz wyjść, facterjest uczciwą grą.

Rzeczy, które są naprawdę wyjątkowe, prawdopodobnie nie powinieneś się tym przejmować i powinieneś po prostu wysyłać konfiguracje z bufora plików.

Obie kategorie należą do decyzji, których nie możemy podjąć bez dogłębnej znajomości środowiska, więc to musisz zrozumieć.

Myślę, że inni opisali powód, dlatego spróbuję tego. Wydaje mi się, że dzięki zrozumieniu, w jaki sposób ktoś może wykorzystać Puppet do robienia tego, co chcesz, decyzja stanie się bardziej zrozumiała.

Najpierw wykonaj podstawową sprawę

Twój moduł Puppet dla Apache'a domyślnie nie powinien wiele robić. Zainstaluj Apache, skonfiguruj go do minimalnego standardu i uruchom usługę. Spraw, by działało to na wszystkich dystrybucjach, które potrzebujesz obsługiwać.

Po drugie dodaj elastyczność

Musimy dodać vhosty. Skończysz z systemem, który może upuszczać pliki lub usuwać je z zestawu katalogów conf.d lub vhosts.d / zgodnie z potrzebami. To samo dotyczy włączania lub konfigurowania modułów.

Użyj klas ról lub grup hostów, aby związać swoje bloki konstrukcyjne

Myślę, że najlepszym sposobem na użycie Puppet jest upewnienie się, że jest addytywny. Korzystając z powyższych przykładów, powinniśmy mieć moduł, który to robi

1. Zainstaluj Apache
2. Ustaw podstawowe konfiguracje
3. Dodaj vhosty do apache
4. Skonfiguruj dodatkowe ustawienia
5. Uruchom Apache

Zamiast przeciążać nasz domyślny moduł Apache, aby robić dokładnie to, czego potrzebujemy dla konkretnego hosta lub grupy, powinniśmy sobie z tym poradzić, to rola lub klasa grupy hostów.

class role::web_cust1 {
  include apache
  apache::vhost {'www.domain.com': }
  apache::vhost {'www.domain2.com': priority => '99', }
  include php
  include php-fpm
  include mysql
}

Znowu dodatek.

Umieść specjalne przypadki w Hiera

Jestem wielkim fanem wynajmu Puppet's Hiera, pomyśl o tym jako o bazie danych Puppet, przechowującej specjalne bity. Jeśli określony host lub grupa hostów potrzebuje specjalnego ustawienia, najpierw umieść w module rozsądne ustawienie domyślne, aby zwykli użytkownicy nie musieli o tym wiedzieć. Następnie wstaw dane dla tych specjalnych hostów lub grup hostów, aby Hiera mogła je wykorzystać, przekazując je w razie potrzeby Puppet.

Mój przypadek użycia to Listen port. Niektóre serwery mają przed sobą Lakier lub haproxy. Domyślnie moduł Puppet używa portu 80 w Apache, ale jeśli Hiera znajdzie dane, zastąpi to ustawienie domyślne.

Obecnie przechodzę między Puppetize dość podobnymi systemami do Puppetize wszystkiego i jestem przekonany, że długoterminowe, Puppetize wszystko jest lepszym podejściem.

Jeśli kontrolujesz wersję manifestów Puppet (wszyscy to robimy, prawda) zyskujesz wszystkie korzyści kontroli wersji dla swojej infrastruktury. Twój zespół staje się inżynierem operacyjnym. Jest to równie ważne w przypadku specjalnych, jednorazowych systemów, jak jednorodne hodowle bydła. Otrzymasz dziennik, kto coś zmienił, kiedy to zmienili, jaka była dokładna zmiana oraz możliwość wycofania zmiany.

Osobiście uważam również, że zmuszanie się do dokonywania każdej zmiany poprzez Puppet powoduje, że bardziej uważnie myślę o tej zmianie. Kiedy piszę manifesty, jestem bardziej uważny na każdą zmianę niż zwykle rąbię w linii poleceń.

Twoje moduły kukiełkowe również staną się lepsze. Czy masz więcej niż jeden moduł Nginx? Może to oznacza, że ​​twój moduł Nginx nie jest taki świetny i musisz uczynić go wystarczająco elastycznym, aby obsłużyć wszystkie twoje specjalne potrzeby. Przynajmniej abstrakcyjne podobieństwa do podstawowego modułu Nginx, który rozszerzasz dla modułów „niestandardowych”.

Co więcej, czy jesteś pewien, że możesz przywrócić wszystkie serwery o specjalnych potrzebach do ich obecnego stanu (w odniesieniu do konfiguracji), gdy nastąpi katastrofa? Jeśli każda zmiana potrzebna do przeniesienia fabrycznego serwera Ubuntu na wewnętrzną wiki jest Puppetized, możesz łatwo odbudować aktualny stan swojej wiki, włączając w to wczorajsze ulepszenie pamięci Tomcat autorstwa Boba.

Wreszcie może to być naprawdę trudne. Zarządzanie wieloma bardzo różnymi serwerami może prowadzić do hacktastycznego kodu Puppet, jeśli nie poświęcisz czasu, aby zrobić to dobrze. Jeśli nie korzystasz ze Puppet Enterprise, rozważ hiera i / lub ENC, takie jak Foreman, aby pomóc oddzielić dane od manifestów. Codziennie Puppetize coś innego. Poproś współpracownika, aby wyjaśnił ci, jak to działa w Puppet. Każda zmiana będzie łatwiejsza.