W jaki sposób maluchy mogą skutecznie uczyć się i używać Puppet? [Zamknięte]

Sześć miesięcy temu w naszym niedochodowym projekcie postanowiliśmy rozpocząć migrację zarządzania systemem do środowiska kontrolowanego przez Puppet, ponieważ spodziewamy się znacznego wzrostu liczby serwerów od teraz do roku.

Od czasu podjęcia decyzji nasi informatycy zbyt często denerwują się. Ich największe zastrzeżenia to:

• „Nie jesteśmy programistami, jesteśmy administratorami”;
• Moduły są dostępne online, ale wiele różni się od siebie; zbyt często wymyśla się koła, jak zdecydować, które pasuje do rachunku;
• Kod w naszym repozytorium nie jest wystarczająco przejrzysty, aby dowiedzieć się, jak coś działa, musi się powtarzać poprzez manifesty i moduły, które mogliby napisać sami jakiś czas temu;
• Jeden nowy demon wymaga napisania nowego modułu, konwencje muszą być podobne do innych modułów, trudny proces;
• „Po prostu uruchommy i zobaczmy, jak to działa”
• Mnóstwo mało znanych „rozszerzeń” w modułach społecznościowych: „trocla”, „augeas”, „hiera” ... jak nasi administratorzy mogą śledzić?

Rozumiem, dlaczego duża organizacja wysyła swoich sysadminów na kursy kukiełkowe, aby zostać mistrzami marionetkowymi. Ale w jaki sposób mniejsi gracze mogliby nauczyć się Puppet na profesjonalnym poziomie, gdyby nie chodzili na kursy i w zasadzie uczyli się go za pomocą przeglądarki i edytora?

Zacząłem używać Puppet przed wdrożeniem nowej infrastruktury i po prostu kupiłem ( uznaną ) książkę na ten temat. Nie sądzę, że większość ludzi faktycznie zdobywa profesjonalne szkolenie Marionetek. Pracowałem nad przykładami, dopóki nie mogłem dopasować tego procesu do mojego środowiska. To był grudzień 2011 roku, więc w ciągu kilku tygodni mogłem zrozumieć podstawy i wdrożyć ramy produkcyjne. Nie byłem nowy w zarządzaniu konfiguracją, mając doświadczenie w CFEngine , ale wiele obaw Twoich sysadminów rezonuje. Popełniłem błędy i kilkakrotnie musiałem dokonać refaktoryzacji, ale wszystko działało zadowalająco.

Kilka uwag na temat twoich punktów ...

• Zmienia się tradycyjna rola administrowania systemami. Dostosuj się lub zostań w tyle. Byłem odnoszącym sukcesy inżynierem systemowym, ale muszę także przeprowadzić zmianę narzędzia (na przykład ucząc się języka Python). Nacisk na poszczególne serwery zmniejsza się, gdy abstrakcja sprzętu poprzez wirtualizację oraz usługi chmur publicznych i prywatnych zyskują na znaczeniu. Oznacza to automatyzację zadań systemowych i wykorzystanie zarządzania konfiguracją do przejęcia kontroli nad większą liczbą serwerów. Dodaj koncepcje DevOps do mieszanki, a zobaczysz, że zmieniają się oczekiwania i wymagania klienta / użytkownika końcowego .

• Moduły kukiełkowe dostępne online różnią się stylem i strukturą i tak, widziałem wiele nakładających się, nadmiarowych i powielonych wysiłków. Jeden z programistów, z którym współpracowałem, powiedział: „mogłeś opracować własne narzędzia w czasie, gdy spędzałeś szukać w Internecie czegoś, co działa!” To mnie zatrzymało, gdy zdałem sobie sprawę, że Puppet wydaje się bardziej podoba się typom programistów niż administratorom szukającym najlepszych praktyk lub właściwego podejścia.

• Dokumentuj mocno, aby dowiedzieć się, jak rzeczy są połączone. Biorąc pod uwagę niepewne definicje i brak standardowego sposobu wykonywania zadań, struktura zarządzania konfiguracją jest naprawdę unikalna dla danego środowiska. Ta przejrzystość będzie musiała zostać rozwinięta.

• Twierdzę, że dość łatwo jest zduplikować moduł, aby pomieścić nowego demona lub dodać usługę do istniejącego manifestu, w zależności od tego, jak zorganizowałeś swoje serwery i role.

• Spędziłem dużo czasu na testowaniu pojedynczego celu, zanim wypchnąłem zmiany do większych grup serwerów. Ręczne uruchomienie puppetd na reprezentatywnym serwerze pozwoliło mi debugować zmiany i ocenić ich wpływ. Może to trochę konserwatywne, ale było konieczne.

• Nie jestem pewien, jak bardzo zależałbym od modułów społeczności. Musiałem zacząć używać Augeasa do niektórych prac i ubolewałem nad faktem, że była to funkcja, którą uznałem za pewnik w CFEngine.

W sumie wydaje mi się, że nie ma ściśle określonego standardu, jeśli chodzi o Puppet. Miałem problem z ustaleniem, jak zorganizować strukturę katalogów na moim Puppetmaster, zrozumieniem, jak zarządzać podpisywaniem certyfikatów, uzyskaniem właściwego odwrotnego DNS na miejscu, przekonaniem Puppet do odpowiedniego skalowania dla środowiska i zrozumieniem, kiedy wykorzystać moduły społecznościowe zamiast budować własne. To zmiana myślenia i widzę, jak spowodowałoby to panikę sysadmin. Jednak było to również rozwiązanie zbudowane od podstaw, więc miałem luksus oceny narzędzi. Decyzja, aby pójść tą drogą, była oparta na współudziale umysłu i rozmachu za Puppet. Warto było nauczyć się czegoś nowego.

Pamiętaj, że ta strona jest również dobrym zasobem.

W poprzedniej pracy przydzielono mi zadanie pilotażowego wdrożenia Puppet. Teraz mam doświadczenie w programowaniu, choć nie Ruby, więc nie mam większego problemu niż inni.

Warto jednak zauważyć, że programiści bez doświadczenia z nietradycyjnymi paradygmatami mają również problem z Puppet, ponieważ Puppet jest deklaratywny , a nie konieczny. W tym sensie Puppet działa prawie jak każdy plik konfiguracyjny: mówisz, jak powinno być, a Puppet zajmuje się resztą.

Po pilotażu miałem okazję przeszkolić kilkunastu innych administratorów z Puppet, a także wygłaszać prezentacje na ten temat w dwóch wydarzeniach. Z moich doświadczeń wynika, że ​​niektórzy administratorzy się tym zajęli, a niektórzy nie. Byli to wszyscy tradycyjni administratorzy, bez umiejętności programowania i różnego poziomu wiedzy.

Zauważyłem, że Puppet wymaga ciągłej praktyki. Ludzie, którzy zostali przeszkoleni, napisali moduły, a następnie spędzili cały miesiąc lub dwa, robiąc coś innego, wrócili do Puppet z niewielkimi przydatnymi umiejętnościami. Ludzie, którzy co tydzień robili w nim małe rzeczy, nigdy nie stracili umiejętności.

Opierając się na tych dwóch spostrzeżeniach, zalecam upewnienie się, że każdy co tydzień dodaje jakieś klasy, definicje lub moduły Marionetek (najlepiej co najmniej dwa lub trzy razy). Ci, którzy nadal nie mogą się do tego przyzwyczaić, mogą naprawdę nie mieć umiejętności, aby to zrobić.

Z drugiej strony, gdyby Puppet został im narzucony z góry, mogliby po prostu zareagować na to, co postrzegają jako zarząd, wtrącając się w to, jak wykonują swoją pracę - co w rzeczywistości byłoby wystarczające. To może być tak, że pozwalając im wybrać , który system zarządzania konfiguracją użyć by poprawić rzeczy. Oto kilka alternatyw:

• ANSIBLE : Jest to nowy, ale opiera się na poleceniach powłoki i ssh, które mogą zachęcić go do tradycyjnych sysadminów.
• Szef kuchni : Może ich problemem jest deklaratywny styl, w takim przypadku szef kuchni byłby lepszy, gdyby miał doświadczenie w Ruby.
• SaltStack : oparty na Pythonie i open-source
• CFEngine : stary, szybki, tradycyjny - może ich przekonać na tej podstawie.

Używam Puppet nieco ponad dwa lata w małych sklepach, w których byłem jedynym administratorem. Największą przeszkodą, jaką miałem, było nauczenie się, jak prawidłowo tworzyć oprogramowanie. Nie minął tydzień, w którym nie spieprzyłem czegoś, co powiedziałem programistom, aby nie robili tego kilkanaście razy. Sprawdziłem za dużo kodu, nie rozbijałem checkinów, nie tagowałem, nie rozgałęziałem się, nie uruchomiłem sprawdzania składni, nie używałem standardu itp. Jeśli dopiero zaczynasz obecnie polecam niektóre z poniższych.

1. Zdaj sobie sprawę, że tworzysz oprogramowanie, którego albo nie wiesz, albo źle sobie radzisz. Jest to oczekiwane, ponieważ jest nowe.
2. Infrastruktura jako kod jest rzeczywistością, a kiedy przejdziesz przez garb, jest dość potężna. Zapraszam niektórych programistów, pokażę im twój obecny proces rozwoju (lub jego brak), nie obrażaj się, gdy podnoszą brwi, i poważnie traktuj ich sugestie. Polecam korzystanie z dowolnego systemu i przetwarzania, z którego korzystają programiści, chyba że jest to całkowicie nieodpowiednie.
3. Zewnętrzne moduły kukiełkowe zasysają 90% czasu. Przeczytałbym je. Kradłbym od nich pomysły. Nie wciągnąłem ich do mojego systemu bez większych zmian. Chciałbym jednak pobrać stdlib marionetek, który dodaje fajną funkcjonalność.
4. Augeas i Hiera. Naucz się tych dwóch. Pierwszy umożliwia kompleksową edycję istniejących plików. Drugi to zewnętrzny magazyn danych.
5. Oddziel kod od danych. Jest to jedna z trudniejszych koncepcji do nauczenia się. Wartości na stałe, takie jak monitorowanie hostów w kodzie modułu, są złe. Umieszczenie ich w magazynie danych (db, yaml (Hiera używa tego domyślnie), csv, cokolwiek), które moduły mogą zużywać, jest dobre. Przykładem jest aplikacja internetowa korzystająca z MySQL. Pozwala to na oddzielne przesyłanie kodu i danych. Ułatwia to proces programowania.
6. sprawdzanie poprawności przez parser lalek i marionetkę w ramach procesu sprawdzania kodu pocztowego lub kodu pocztowego. Również testy rspec mogą być dobrym pomysłem, gdy jesteś na bieżąco.
7. napisz przewodnik po stylu / kod i użyj go. „gdzie jest kod instalujący Apache” jest częstym problemem. Jeśli twoje moduły są w większości takie same, powinno to być łatwe.

Podsumowując, napotkałem wszystkie te problemy i tak mam większość moich przyjaciół sysadmin. Zajmie trochę czasu, aby dobrze korzystać z systemu zarządzania konfiguracją. Gdy to zrobisz, będziesz się zastanawiać, jak żyłeś bez niego. „Zaloguj się do serwera i wprowadź zmiany ręcznie? Ick.”

Sześć miesięcy temu w naszym niedochodowym projekcie postanowiliśmy rozpocząć migrację zarządzania systemem do środowiska kontrolowanego przez Puppet, ponieważ spodziewamy się znacznego wzrostu liczby serwerów od teraz do roku.

Brzmi jak dobry pomysł, aby zacząć wcześnie - Puppet to coś więcej niż zarządzanie konfiguracją, to forma dokumentacji.

Od czasu podjęcia decyzji nasi informatycy zbyt często denerwują się.

Potrzebują korekty nastawienia.

"We're not programmers, we're sysadmins";

Znowu postawa. Możesz zrobić plik conf dla serwera, prawda? W miarę ewolucji potrzeb i złożoności możesz swobodnie korzystać z szablonów / programów .

Moduły są dostępne online, ale wiele różni się od siebie; zbyt często wymyśla się koła, jak zdecydować, które pasuje do rachunku;

Trudny do odpowiedzi - zawsze wolę moduły puppetlabs od większości - i nawet przy tym nie używam zbyt wielu. Zadzwoń do sądu na pewno. Moim zdaniem niektóre moduły są „zbyt plisowane”.

Kod w naszym repozytorium nie jest wystarczająco przejrzysty, aby dowiedzieć się, jak coś działa, musi się powtarzać poprzez manifesty i moduły, które mogliby napisać sami jakiś czas temu;

To nie brzmi jak problem marionetek, ale bardziej problem organizacyjny lub dokumentacyjny?

Jeden nowy demon wymaga napisania nowego modułu, konwencje muszą być podobne do innych modułów, trudny proces;

Ten demon może być klasą, jeśli jest wystarczająco prosty w zarządzaniu. Nie jestem pewien, co rozumiesz przez konwencje, kukiełka egzekwuje konwencje całkiem dobrze, prawda? A może mówimy o formatowaniu kodu?

"Let's just run it and see how it works"

Niezły pomysł, jeśli podejmiesz go powoli i bezpiecznie. Nadal zacznę od maszyny wirtualnej, aby uzyskać sedno rzeczy.

Mnóstwo mało znanych „rozszerzeń” w modułach społecznościowych: „trocla”, „augeas”, „hiera” ... jak nasi administratorzy mogą śledzić?

moduły postfix, exim, sendmail, mysql, postgresql, iftop, iptraf, perl, perl .. Wybierz, co chcesz i użyj? Wydaje mi się, że to znów bardziej przypomina podejście ...

Rozumiem, dlaczego duża organizacja wysyła swoich sysadminów na kursy kukiełkowe, aby zostać mistrzami marionetkowymi. Ale w jaki sposób mniejsi gracze mogliby nauczyć się Puppet na profesjonalnym poziomie, gdyby nie chodzili na kursy i w zasadzie uczyli się go za pomocą przeglądarki i edytora?

Nie uczęszczałem na żadne kursy - chociaż jestem programistą bardziej niż sysadminem, zauważyłem, że nie trzeba było dużo umiejętności programowania, aby cokolwiek osiągnąć.

Dokumentacja Marionetki, jeśli jest stosowana, jest dość dokładna. Zwróć uwagę na wbudowane typy i poświęć trochę czasu na sprawdzenie, w jaki sposób zestawiane są inne moduły. Nie powiedziałbym, że jest to super łatwe, ale też nie jest trudne. Przygotowanie infrastruktury na marionetkę jest trochę czasochłonne, ale zainwestowany czas jest pewny, że dobrze ją wykorzystasz podczas rozbudowy.

KISS (Mów to głupio) - Nie używaj nowych technologii tylko dlatego, że są tam raczej dlatego, że masz do nich wymagania, używaj absolutnego minimum wymaganego przez twoje wdrożenie, aktualizuj zgodnie z wymaganiami, nie próbuj nadążać za krwawieniem Brzeg. Jeśli zaczniesz od podstawowej konfiguracji i będziesz na niej opierać, łatwiej jest podnosić ją w trakcie podróży i nie powinni oni potrzebować kursu (czy są nawet dostępne?).

Innym obszarem, na który możesz spojrzeć, są twoi administratorzy. Jeśli nie potrafią również programować, to czy są wystarczająco zaawansowane, aby przeprowadzić duże wdrożenie, gdzie większość pracy wymaga skryptowania za pomocą wszelkich używanych narzędzi?

Pracuję również dla organizacji non-profit i byłem odpowiedzialny za początkowe wprowadzenie Linux-a do domu, a wkrótce potem Puppet za zarządzanie nimi. Zrobiliśmy kilka konkretnych rzeczy, które naprawdę pomogły w rozwoju.

Przede wszystkim starałem się trzymać z dala od modułów innych firm. Wbudowane narzędzia obsługują 90% naszego zarządzania. Największym narzędziem innej firmy, którego używam, jest moduł zapory ogniowej. Wszelkie niestandardowe fakty itp. Są opracowywane z udziałem całego zespołu. Opracowaliśmy moduł szablonów i utrzymujemy standaryzację zarządzania plikami, pakietami, usługami itp. Poza tym szablonem.

Po drugie, po standaryzacji korzystania z wbudowanych modułów zaczęliśmy używać Git i Atlassian's Crucible - przy okazji - darmowych dla organizacji non-profit - do przeprowadzania przeglądów wszystkich zmian konfiguracji. Zapewnia to pożądaną przezroczystość.

Po trzecie, zautomatyzowałem konfigurację Puppet, aby nowe hosty mogły być dodawane automatycznie z domyślnym zestawem opcji. Istnieje kilka sposobów rozwiązania tego problemu. Ponieważ miałem już kompletne środowisko Kickstart, zdecydowałem się dodać tam skrypt.

„Nie jesteśmy programistami, jesteśmy administratorami”

My, jak czasy się zmieniły na gorsze: a starzec jak ja było oczekiwać, aby być lepszym programistą niż profesjonalnych programistów, albo nigdy nie byłby w stanie przejść przez administratora systemu .

Teraz mamy „administratorów systemu”, którzy są w zasadzie użytkownikami komputerów z systemem Windows, którzy w pewnym momencie przekonwertowali się na Linuksa i nie mogą programować, i nie znajduje w tym nic złego.

Słoń w pokoju jest powodem, dla którego kierownictwo toleruje takie destrukcyjne podejście. Niszczycielskie dla kogo lub co? Do biznesu i infrastruktury.

Powrót do tematu Puppet [, CFEngine, Chef]: jak tylko ustali się takie rozwiązanie, przegrywa. Wszyscy przegrywają. Dlaczego? Ponieważ ktokolwiek wpadnie na ten pomysł, nie jest w stanie zaprojektować zamkniętego zarządzania konfiguracją w postaci ładnych, czystych pakietów systemu operacyjnego Kickstart [, JumpStart, Automated Installer, AutoYaST, Ignite-UX, NIM]. Kiedy musisz użyć zautomatyzowanego narzędzia hakerskiego, takiego jak Puppet (lub Chef, lub CFEngine), oznacza to, że brakuje ci środków na zaprojektowanie i wdrożenie procesu, który dzięki temu samemu projektowi wymusiłby całkowicie nieskazitelne i całkowicie oświetla zarządzane systemy, w pełni zautomatyzowane i całkowicie nieinteraktywne.

Innym ważnym punktem jest to, czy trzeba mieć Marionetka czy coś takiego rozwiązania do poprawiania kogoś hacking system lub konfiguracji aplikacji ręcznie, które również sięga nie mając doświadczenia zaprojektowanie procesu, aw tym procesie ramy gdzie konfiguracja jest pakowany na dyskretne elementy. W efekcie, ktokolwiek wdraża Puppet i tym podobne, nie ma pojęcia właścicieli komponentów, wydań, zarządzania konfiguracją, modelu dojrzałości zdolności. Szybko staje się to bardzo poważnym problemem w branży.

Praca z Puppet pomogła mi również nauczyć się Ruby, który zastąpił Bash jako mój domyślny język narzędzi systemowych. ”

Dlaczego Ruby jest potrzebny, gdy kompleksowe, kompleksowe zarządzanie konfiguracją może być zawarte w sekcjach preinstalacji, postinstalacji, preremove i postremove pakietów systemów operacyjnych, tylko przy użyciu programów powłoki Bourne, AWK i sed? Że ktoś dołoży wszelkich starań, aby nauczyć się ezoterycznego języka Ruby i jego dialektu w kontekście Marionetki, jest zupełnie niepotrzebny. Problem zarządzania konfiguracją można łatwo rozwiązać (a mianowicie został rozwiązany) za pomocą programów powłoki i AWK oraz trochę sed (1) tu i tam jako kleju.

Fajnie jest widzieć, jak manifest Puppet konfiguruje od nowa całą maszynę lub nową usługę.

Jeszcze fajniejszą rzeczą jest obserwowanie, jak robi to Kickstart, AutoYaST lub JumpStart, bez jednego wiersza kodu , i możliwość zapytania systemu operacyjnego za pomocą wbudowanych narzędzi, bez potrzeby używania ezoterycznego lub dodatkowego oprogramowania , bez klienta-serwera wymagana architektura (SSH jest więcej niż w porządku, znacznie więcej niż w porządku), a twój system operacyjny jest świadomy każdej wprowadzonej zmiany.

5.Oddziel kod od danych. Jest to jedna z trudniejszych koncepcji do nauczenia się. Wartości na stałe, takie jak monitorowanie hostów w kodzie modułu, są złe. Umieszczenie ich w magazynie danych (db, yaml (Hiera używa tego domyślnie), csv, cokolwiek), które moduły mogą zużywać, jest dobre. Przykładem jest aplikacja internetowa korzystająca z MySQL. Pozwala to na oddzielne przesyłanie kodu i danych. Ułatwia to proces programowania.

... Lub możesz po prostu utworzyć szablon plików konfiguracyjnych ze zmiennymi powłoki, nawet cudzysłowami (na przykład ls -1 ...) i napisać skrypt powłoki, który używa AWK do wywołania eval (1) i rozwinąć wszystkie zmienne w szablonie, wykorzystując w ten sposób dokładnie taką samą moc analizator składni, który mają wbudowane powłoki. Po co to komplikować, skoro może być naprawdę, bardzo proste? Gdzie będziesz przechowywać wartości konfiguracji? Dlaczego, gdziekolwiek zechcesz, na przykład pliki pkginfo (4), baza danych taka jak Oracle, czy prawie wszędzie . Nie ma potrzeby stosowania ultrakompleksowych rozwiązań. Biblioteka wspominam powyżej może być po prostu pochodzić z sekcji preinstalacji lub postinstall w pakietach systemu operacyjnego, usuwając w ten sposób powielania i wykorzystując środkową część kodu ...

Ale przede wszystkim uważam, że powyższy cytat jest przykładem nowej generacji administratorów systemu, którzy potrzebują korepetycji nie przez administratorów systemu, ale przez inżynierów systemowych . Znajdź siwobrodego i zarejestruj się jako uczeń.