Puppet - pomůcka administrátora

13.6.2014 13:56 | Přečteno: 1984× | Za vším hledej Linux |

Je tomu něco přes rok, co jsem tady publikoval blogpost na téma Puppet a konfigurační nástroj Augeas. Čas trhnul oponou, a já během toho roku začal používat další vymoženosti Puppetu o kterých vám chci, prostřednictvím tohoto čtení na neděli, potlachat. Chronologicky shrnuto budu psát o:

• využití Puppetu k replikaci skriptů
• grafech závislostí
• bonzování změn
• využití Puppetu k dokumentaci prostředí
• distribuovaných modulech

Puppet a git

Pupet je výborná pomůcka při údržbě systému počítače. Hrabe jen na to, na co hrabat má a díky tomu lze přes něj uspokojivě udržovat i stroje, na kterých hospodaří více administrátorů, aniž by tím někomu hatil jeho práci.

Pěkná je jeho symbióza s utilitou etckeeper. V diskuzi - která proběhla před nějakými dvěma měsíci pod blogpostem Franty Kučery, který tam uvádí prakticky téměř vše proč jsem vlastně začal před dvěma lety Pupet používat já - o něm napsal Pavel Píša. K tomu lze jen dodat, že Puppet tuto utilitu v žádném případě nenahradil.

Součástí standardní instalace Puppetu jsou "háčky", které se starají o to, aby agent - pokud udělá v konfiguraci nějakou změnu, uložil přes etckeeper změny do gitu. Díky tomu lze v případě potřeby na produkčních strojích zpětně vysledovat kdo, kdy, za jakých okolností a jakou změnu udělal.

I na modelových strojích, kde tato utilita není, ale využívám možností gitu při psaní manifestů. Na stroji master je git pro zachování historie změn v konfiguraci puppetu a jeho modulů přímo ideální.

Využití Puppetu k replikaci skriptů

Původně jsem Puppet využíval pouze k popisu cílové konfigurace systému, aby bylo možné - v případě potřeby - s jeho pomocí rychle a od nuly nainstalovat nový stroj, tak aby měl stejnou konfigurací jako ten původní. Proto jsem nepovažoval za nutné, aby běžel agent trvale jako démon.

Situace se ale změnila zhruba před půl rokem, když jsem upravoval agenta pro Pacemaker. To se náramně hodilo, že jsou všechny nody clusteru spravované přes Puppet. Stačilo spustit agenta, dopsat do manifestu zdroj, kterým se na ty nody distribuoval agent pro Pacemaker a interval spouštění agenta zkrátit zhruba na dvě minuty.

Pak už jsem mohl pohodlně upravovat kód agenta na stroji kde běží master a jenom po očku sledovat kontrolní výpisy v logu nodu, který měl zdroj Pacemakeru, pro který jsem psal toho agenta, aktivní.

Grafy v Puppetu

Generování grafů jsem "objevil" relativně nedávno. Je to v podstatě úplně triviální věc, kterou uměla už starší verze Puppetu, než je aktuální 3.6.2

Grafy se generují v DOT formátu na straně agenta, ale lze je bez problémů překonvertovat do SVG nástroji z balíku graphviz. Hodí se to, především u komplexnějších manifestů, ke zmapování deklarovaných zdrojů a jejich závislostí.

Využití Puppetu při hlídání změn v konfiguraci

Co mne dřív nenapadlo využívat a dnes považuji za naprosto skvělou funkcionalitu, je posílání reportů prostřednictvím e-mailu. O rozesílání reportů se stará master a to pouze tehdy, pokud agent na klientském nodu realizoval, nebo se chystá realizovat, nějakou změnu. Výhoda je především v tom, že pro klientskou stanici nemusí být vůbec povoleno odesílání e-mailů, protože je na základě hlášení agenta sestavuje master. V subjektu hlášení je identifikace klientské stanice a v obsahu zpráva od agenta. Komu a jakou zprávy odesílat lze filtrovat pomocí konfiguračního souboru tagmail.conf

Velice elegantně a přitom způsobem který neotravuje, tak lze registrovat nežádoucí zásahy do konfigurace, co by jinak mohly uniknout pozornosti.

Dokumentace

Údržba dokumentace je achilovou patou většiny administrátorů. Není problém stroje spravovat, ale dokumentovat co, jak a kde má být. Je naprosto fuk, je-li stroj jeden, nebo jich je stovka. Řekl bych, že nejvíc se na dokumentaci kašle tam, kde je těch strojů málo.

Údržba dokumentace je téma, při kterém se u nás v práci prakticky vždy poštěkáme. Pro Petra je totiž velice těžko zkousnutelný fakt, že dokumentace a její údržba zabírá většinu mého pracovního času.

Aby totiž bylo možné něco kvalitně popsat, je třeba spoustu věcí teprve zjistit a otestovat. U začínajících administrátorů, co se s problematikou teprve seznamují sežere hodně času učení a samotná práce. Na dokumentaci jim pak už moc času nezbývá.

Prakticky všude kam jsem přišel, jsem tedy začínal tím, že jsem si musel sám zmapovat prostředí, abych věděl co kde je. Pokud možno takovým způsobem, aby jednou - až natáhnu brka, nebo zblbnu - na tom nebyl můj nástupce jako já, když jsem nastoupil na katedře. Jako v té pohádce o kohoutkovi a slepičce jsem před těmi šesti lety sbíral informace co kde vlastně běží. Proto vůbec první věc, kterou jsem na katedře rozjel, byla naše wiki, u které jsem si obhájil, aby byla veřejně přístupná všem bez rozdílu a její použití nebylo nijak omezováno. Původně na mne totiž tlačili, aby byla přístupná pouze lidem z naší katedry. Dnes ji využívají k k interní dokumentaci IT infrastruktury našeho baráku i kolegové z jiných kateder a já doufám, že i mé manuály občas někomu pomohly.

Nevím, jestli uvažujete někdy nad tím, v jakém stavu je práce kterou opouštíte. Může se kdykoliv stát, že vás ráno cestou do práce skolí auto. Bude vědět, ten co vás nahradí, co kde běží, jak se to má nastavit, rozšířit, opravit nebo změnit? Mě trvalo skoro rok, než jsem se vůbec dozvěděl (a to ještě náhodou) administrátorské heslo stroje, kde běžel web katedry, který jsem měl spravovat! Nikdo ani pořádně nevěděl, na kterém fyzickém stroji vlastně běží a co tam kromě toho webu je. Můj předchůdce mi věnoval asi zhruba deset minut svého času, aby mi ukázal jak vypadá konzole xenu, který jsem nikdy předtím nepoužíval, a zmizel.

Trvalo skoro pět let, než se mi, později již ve spolupráci s kolegy, podařilo opravdu dobře zmapovat a především konsolidovat naše IT prostředí - z hlediska síťařiny není zcela triviální a pokud jde o stroje a jejich instalace, tak zde před mým příchodem panovala naprostá anarchie. Ovšem před těmi šesti lety to byla ještě sranda, protože se spoustou věcí se teprve začínalo. Dnes si všichni na vysoký komfort služeb, které jim moje infrastruktura poskytuje, zvykli do té míry, že jim vůbec nedochází cena obdobných služeb v komerční sféře, kde za nimi stojí celé týmy administrátorů, kterým se platí velké peníze.

To však ale nebyl můj problém. Mě trápilo to, jak zdokumentovat tuto infrastrukturu - která je čistě mojí doménou - tak aby se můj případný nástupce byl schopen zorientovat co nejrychleji, neboť je z ní zajišťována především výuka. Wiki je fajn věc, ale pro popis instalace konkrétních strojů se zrovna moc nehodí - obzvláště, když se situace průběžně mění a je třeba dělat i jiné věci, než psát dokumentaci. A tak mě napadlo využít možností formátování dokumentace v rámci Puppetu.

Využití Puppetu k dokumentaci prostředí

Puppet umožňuje psát dokumentaci ke kódu manifestů rovnou do nich a text formátovat pomocí textových značek, podobně jako se to dělá u wiki. Z takto dokumentovaného kódu pak lze velice jednoduše vygenerovat statické webové stránky, které lze zkopírovat třebas na flashku.

Součástí vygenerovaného kódu ale nejsou žádné citlivé informace, které by mohly nějakým způsobem ohrožovat bezpečnost spravovaných klientských stanic, takže jej lze bez problémů veřejně publikovat prostřednictvím webu. Tak jako to do dělám já pro svůj testovací master.

Osoba s administrátorským přístupem, případně s přístupem ke sdílenému git repozitáři, kde se změny archivují má ale přístup i k poznámkám přímo v kódu, které nejsou součástí vygenerovaného html kódu. A stejně tak i k dalším nastavením, které jsou klíčové z hlediska bezpečnosti. V případě nutnosti tak mému potencionálnímu nástupci stačí získat přístup k tomuto kódu, aby získal všechny informace potřebné k seznámení s celou infrastrukturou. Výchozím předpokladem ovšem je, že nemá v hlavě piliny a je alespoň v základu seznámen s tím, jak se píšou manifesty puppetu. Proto ostatně také sepisuji ten svůj manuál k Puppetu - aby se jednou, až mě to už fakt přestane bavit, vůbec našel někdo, kdo místo mne nastoupil a táhnul tu káru dál.

Opět zde píšu z vlastní zkušenosti. Všichni měli pocit, když jsem končil na úřadě, že budou zájemců o místo celé davy. Jaksi pozapoměli, že za těch pět let co jsem tam byl už ani zdaleka nešlo jen o správu webu. Nakonec byli rádi, že to za mě vzal můj kámoš, se kterým jsme na něm spolupracovali.

Když toho máš víc..

Tenhle poslední odstavec už se pokusím vzít velice stručně.

Původně jsem měl na starosti pouze jeden master. Postupem času se ale ukázalo, že pro věci, které nesouvisí až tak s katedrou bude lepší mít ještě jiný. Některé moduly však byly napsané tak, že se na něm nedaly univerzálně použít. Začal jsem je proto postupně přepisovat.

Cílem je mít sadu univerzálních modulů, které by bylo možné veřejně sdílet přes Puppet Forge a data specifická pro určitá konkrétní prostředí mít udržovaná v privátních modulech.

Všechny svoje git repozitáře i textové poznámky jsem soustředil do jednoho superprojektu, aby mě nevykousla ztráta notebooku a konečně se začal blížit ideálnímu stavu klidu a míru duše

Závěrem doufám, že vám tento blogpost přišel dostatečně výživný a neotrávil v půli čtení. Pokud jste dočetli až sem, tak díky za vaši pozornost a pěkný víkend.

       

Anketa

Komentáře

[xxxs]

pekne. a chceme checkboxy.

[David Indra]

Příloha:

• wtf.png (172417 bytů)

Viz příloha. No tak nevím, ale když to upravím na checkboxy a oba zaškrtnu, tak se ten form v pohodě odešle a vypíše to "Vaše odpověď byla zaznamenána" nebo co.. Hlas se přičte, procenta změní.. Bug?

[pepa]

Nefrflej Indro. Tohle mělo vyjít jako článek. Moc pěkné čtení. Vysoce překonává běžné články tady na abc. Díky, Aleš.

[David Indra]

Já vím. Taky jsem si dobře početl. Jen mi přišlo divný, že na ABC se dají u rádia v anketách obě možnosti..

[SPM]

To je ale divný distro... :)

[Odin]

Prijde vam spravne blogovat v pracovni dobe?

[marek]

Nech prosím zbytečného trollování.

[Odin]

Rikejte si tomu, jak chcete. Ale podle mne neni spravne, ze zamestnanci organizaci zijicich ze statniho rozpoctu v pracovni dobe bloguji. Nemam nic proti prispevku jako takovemu, naopak se mi libi.

[xxxs]

mozno mas pravdu. mozno bol na prestavke a mozno pouzil taku fintu: Datum zveřejnění

mozno mu to zadal zamestnavatel. mozno je plateny za to, aby veci fungovali a moze sa vzdelavat a pohybovat na internete, lebo to vedie k tomu, aby veci lepsie fungovali.

[Václav "Darm" Novák]

Pokud je zaměstnancem žijícím ze státního rozpočtu (mimochodem, on to žádný zázrak není, tabulkové platy jsou silně podhodnocené), není celkem fajn že, pokud na to má čas, za ty peníze lidem co platí daně poskytne i svoje znalosti? Mohl se ve svém volném čase věnovat třeba pařbě nějaké hry, nebo sledování porna a nikdo by o tom nevěděl, aby si mohl stěžovat.

[pavlix]

+1

[Aleš Kapica]

Jinak je vám po tom s odpuštěním houby. Vy mě neplatíte a já pro vás nepracuji. Píchačky nemáme, přesčasy mi nikdo neproplácí a na mé volno se mě také nikdo neptá když je třeba něco řešit.

[marek]

+ 1

[victor8]

Niektorym ludom (smutne je, ze aj v IT) je zatazko vysvetlit, ze su prace platene od hodiny a prace platene od vysledkov. Robotnik, ktory bol 20 rokov za pasom buzerovany kvoli kazdej minute, proste nepochopi ze dobry admin je ten, ktory nezvykne mat vela veci na praci (kedze mu to tak akosi vsetko funguje samo) a ma cas na sebavzdelavanie, popr. vzdelavanie komunity svojich kolegov.

Druhou moznostou je ze clovek je proste zavistlivy hlupak, ktory sa v robote namaka ako vol kvoli vlastnej neschopnosti naucit sa pracovat efektivne.

Otazkou je, ktora varianta sedi na Odina.

Ja za tento blog dakujem, som rad, ze nie som sam kto chape potrebu zdokumentovaneho prostredia, no zaroven sa mu tu dokumentaciu rucne pisat nechce a tak hlada moznosti, ako tento proces zautomatizovat :)

[pavlix]

Podle mě se tu spíš Odin projevil jako užitečný idiot.