Puppet a konfigurační nástroj Augeas (diskuse)

[ET]

imho celkem hruza - muzu se zeptat, kolik stroju tim obsluhujes?

tedka zkousim cfengine a neco prisernyho, kdyz nic tak to aspon neni v ruby...

[Aleš Kapica]

Na jedné lokalitě se přes Puppet spravuje asi pět strojů a já si přes to spravuji strojů asi pět. Ovšem počet spravovaných strojů je pro mne nepodstatný argument.

Původním zadáním bylo vytvořit "popis" stroje, tak aby jej bylo možné automaticky nainstalovat "jedním tahem" od nuly do plné konfigurace, bez manuálního zásahu. A ten teď průběžně přepisuji. Jak dělat některé věci lépe totiž člověk pozná až když s nimi aktivně pracuje.

Jak už jsem napsal. Zaobírám se Puppetem průběžně asi rok a není to jediná ani prioritní náplň mé práce. Postupně jsem aplikoval správu přes Puppet na virtualizační stroje, které vyžadují kvůli vzájemné zastupitelnosti identickou konfiguraci. Výhodou Puppetu je, že si hlídá jen to co má v popisu. Do ostatních věcí nevrtá.

Jak jsem zmínil. Momentálně předělávám "popis", který jsem vytvořil a připravuji nový pro nový virtuál, který by měl nahradit jiný starší stroj. Pro tyto účely mám speciální diskless stroj a využívám přitom možností, které poskytuje overlay.

Pokud jde o ruby. Také jsem z toho nebyl nadšen, ale ono je to nakonec jedno. Dřív nebo později si ho stejně nějaká aplikace do systému zavleče. Podstatný je výsledek a ten splňuje mé požadavky.

[ET]

oki, dik za info - tak at slouzi ;)

[.]

btw. http://www.linux-mag.com/id/7841/ je celkem hezky zbezny srovnani nekolika nastroju (po)hromadne spravy.

[Heron]

já si přes to spravuji strojů asi pět

aby jej bylo možné automaticky nainstalovat "jedním tahem"

Zaobírám se Puppetem průběžně asi rok

Mno.

My těch strojů máme asi tak pár desítek krát víc a udržujeme je ručně (ano ručně, ssh a příkazy na řádce). Je to nejefektivnější. Puppet, Chef a Foreman a co ja vím co ještě mi mnoho lidí mnohokrát nabízelo jako "nejlepší řešení" problému, který ani nemáme. Proč? 5 strojů a rok (neprioritní průběžné práce?). To si děláš srandu? Tím neříkám, že tyhle nástroje jsou k ničemu. Vůbec ne. Pokud má někdo (deseti)tisíce serverů, tak je ruční práce už mimo reálné možnosti, ale na malé počty je to (podle mě) značně neefektivní.

[Aleš Kapica]

Nic proti, ale nevíš o čem mluvíš. To jak dlouho se tím zaobírám jsem uvedl především proto, aby bylo jasné, že blogpost nevznikl na základě prvotního nadšení, ale po určité zkušenosti. Pro mne je Puppet především doplněk.

Vtip je v tom, že u něj vůbec nezáleží na tom, jestli spravuješ stroj jeden, nebo tisíce. Podle toho co píšeš mám pocit, že vůbec neuvažuješ o budoucnosti. Kdybych nebyl přesvědčen že se mi ten investovaný rok bohatě vrací, tak bych se tím vůbec nezaobíral a tenhle blogpost by ani nevzniknul.

[Aleš Kapica]

Pokud jde o počet spravovaných strojů, tak většinou málokdo spravuje těch strojů víc jak deset. Sám bych mezi známými spočítal na prstech jedné ruky lidi co jich spravují víc. Mnohem častější je situace, kdy někdo po někom převezme stroj a absolutně netuší co vlastně na tom stroji všechno běží. To byla kupř. situace, v níž jsem se sám ocitnul před pěti lety. Puppet je nástroj, který umožňuje konfiguraci takového stroje srozumitelným způsobem postupně popsat a v případě potřeby ji buďto v identické podobě rekonstruovat, nebo nově nainstalovat do prostředí aktualizovaného systému.

Když už pro nic jiného, tak je výhodné Puppet použít pro správu přístupu. Nevím, jak by se taková situace řešila u vás, ale pro puppetizované stroje stačí pouze přidat, nebo změnit autorizační klíč v centrálním úložišti. O zbytek se už postará na klientském nodu spuštěný agent. Také je mnohem větší pravděpodobnost odhalení neoprávněného zásahu do konfigurace puppetizovaného stroje - jednak se o tom objeví záznam v logu, že bylo třeba něco přenastavit, ale zároveň - v případě pozměněné konfigurace - dojde k přenastavení na původní hodnoty.

Pro sledování změn v konfiguraci na jednom stroji využíváme etckeeper. Augeas zase pro změnu umožňuje rychlé srovnání vzájemné konfigrace dvou strojů, takže lze poměrně rychle zjistit kde co chybí, resp. co je - u strojů s identickou instalací - nastaveno jinak.

[Heron]

Ad první odstavec. Já sám jsem vytvořil a spravuji cca 45 serverů (poslední dneska). To nepočítám ještě dva své soukromé a další jeden u kámoše. Ty produkční pochopitelně nespravuji sám, celkově těch serverů máme ale mnohem víc. Co se týče toho Puppet. Já mám trochu strach, aby to neskončilo stejně jako jako všechny ostatní pokusy o například ispcp apod. Vždy se tam našlo něco, co to neumožňuje. Což v důsledku znamenalo dělat věci dvojitě (chápeš, co jde tak v nějaké takové automatické konfiguraci a co nejde, tak ručně). To je opravdu lepší to dělat rovnou ručně.

Nevím, jak by se taková situace řešila u vás, ale pro puppetizované stroje stačí pouze přidat, nebo změnit autorizační klíč v centrálním úložišti.

Úplně jednoduše. useradd a authorized keys. Případně s další pomocí standardních nástrojů GNU.

dojde k přenastavení na původní hodnoty

To jako že něco nastavím na serveru (protože to tak má být nastavené) a puppet mi to za odměnu potom změní pod rukama? To by byla poslední minuta jeho života. Tohle svého času dělaly nějaký "taky security" skripty na mandrivě, nastavil jsem si co jsem potřeboval a za 10minut (nebo jak často se ta mrdka z cronu spouštěla), jsem se na ten server už nedostal (pro rejpaly, samozřejmně dostal, člověk si vždycky poradí).

[Aleš Kapica]

To jako že něco nastavím na serveru (protože to tak má být nastavené) a puppet mi to za odměnu potom změní pod rukama?

Puppet je nástroj pro centralizovanou správu, takže pokud takovým způsobem nějaké zdroje spravuješ, tak ano. Logika věci je totiž taková, že takové věci řešíš nastavením na stroji master, nikoliv na jednotlivých klientech.

Ovšem jak už jsem zmínil - Puppet se stará jen o to co má v popisu práce. Pokud se má starat pouze o uživatele A, tak si ostatních uživatelů nevšímá. Pokud mu ale předepíšeš, že uživatel, nebo skupina na klientovi existovat nemá, tak se o to prostě postará. To je snad žádoucí, ne?

A pokud nechceš aby se to dělo automaticky, pak není nic snazšího, než pouštět agenta ručně. Já to tak dělám u testovacího prostředí (viz odkazovaný manuál)

[Heron]

Puppet je nástroj pro centralizovanou správu, takže pokud takovým způsobem nějaké zdroje spravuješ, tak ano. Logika věci je totiž taková, že takové věci řešíš nastavením na stroji master, nikoliv na jednotlivých klientech.

Jenže to ale vede právě k té duplicitě, kterou jsem zmínil. Co jde řešit přes Puppet, řešilo by se přes Puppet. Ale co nejde, tak by se řešilo ručně -- jinými slovy, musel by ses stejně učit jak ruční konfiguraci, tak i Puppet. To jsem sám, komu tahle duplicita práce vadí?

[Miška]

Dohodnes se na policy, ze rucne se delat nic nebude a pak hlavni vyhoda je, ze vsechna konfigurace je centralizovana a klidne v gitu. Nemusis hledat co kolega udelal vcera rucne a co ti rozbilo tvoje nastaveni. A kdyz jeden server odchazi a je treba sluzby z nej premigrovat jinam, jen se prida novemu stroji trida a zmigruji se data.

Ja pouzivam puppet na svych par strojich, protoze sou veci co sem se naucil a nastudoval jednou a pak misto abych si napsal poznamky do bloku a delal to rucne a az budu neco potrebovat zmenit, tak studoval znova, tak sem si napsal modul do puppetu.

btw. Puppet pouziva Gentoo na spravu svoji infrastruktury, to obecne k vetsim nasazenim

[Aleš Kapica]

Jaká duplicita?! Spravovat více strojů přes Puppet sice může i cvičená opice, ale na to, aby byly moduly a třídy pro tento účel správně vytvořeny musí ten, kdo je dělá, tyhle věci tak jako tak znát. Bylo by chybou vnímat Puppet jako alternativu standardních utilit.

Abych byl konkrétní. Většina mých strojů je virtualizovaných a ukládá své soubory přes NFS do centrálního úložiště. Aby nevznikal binec v UID a GID, mám vytvořený definovaný typ s názvem personality, který mi pořeší na každém klientovi všechno co potřebuji. Viz kupř. vytvoření uživatele moula:

personality { 'moula':
        uid => 1023,
        gid => 100,
        managehome => true,
        home => '/home/moula',
        shell => '/bin/bash',
        }

Pokud budu chtít tohoto uživatele zrušit, tak mu jenom přidám parametr absent a při dalším průchodu bude ze všech klientů, kterých se to týká odstraněn. Totéž platí pro změnu kteréhokoliv jiného parametru tohoto uživatele.

Nemusím tedy řešit jednotlivé příkazy na každém stroji zvlášť, byť i s využitím paralelního ssh přístupu. V rámci personality se totiž v případě změny UID či GID provede změna také u všech souborů uživatele, kterých se to týká.

Ano. Mohl bych totéž udělat i pomocí standardních nástrojů, ale musel bych řešit jednotlivé příkazy a především si pohlídat, abych někde na něco nezapoměl.

Takhle má ten uživatel existující záznam a nikdo nezaloží jiného uživatele se stejným UID, i kdyby byl deaktivován, protože by Puppet ihned oznámil chybu.

Konfigurace Puppetu na stroji master je udržována v gitu, takže lze zpětně zjistit, kdo a kdy kterého uživatele přidal, ev. kdy jej odstranil. Z hlediska přehlednosti a srozumitelnosti mi přijde zápis v manifestu jasnější, už jen proto že každý argumet v personality je popsaný a má svůj komentář. Což mi přijde lepší než nějaké extra poznámky, uložené bůhví kde.

[Aleš Kapica]

Životnost jakéhokoliv projektu je závislá na jeho rozšíření, nejenom kvalitě. Pokud jde o Puppet, sázím na kolegovu intuici. Žijeme v relativně malém, rybníčku. Ovšem pokud bychom brali jako měřítko velikosti státu počet osob aktivních ve vývoji IT v poměru na hlavu, tak myslím, že se nemáme zač stydět. Soudím tedy, že popularizace takových věcí v tomto prostředí dává záruku, že jen tak nezaniknou.

Než jsem sepsal svůj blogpost, tak tady padla zmínka o Puppetu pouze v souvislosti s vydáním jeho nové verze a zhruba před dvěma lety v rámci blogpostu věnovanému konkurečnímu systému Chef. O použití Augeasu se tady zmínil v diskuzi zhruba před měsícem Pavlix, jinak ticho po pěšině. Nebudeme-li se však o takových věcech bavit, pak o nich nebudou vědět ani ti, co by je mohli s úspěchem využívat.

[podlesh]

cfengine je rozhodně řádově větší hrůza než puppet

[retroslava]

K popisu stavu operačního systému používá Puppet specifický programovací jazyk.

spíš bych to nazval DSL

Ale jinak zkoušel jsi i Chef?

[Aleš Kapica]

Nezkoušel, protože jsem nastoupil už do rozjetého vlaku. To je vlastně i důvod proč vzniknul ten můj manuál - jsou to moje poznámky. Proč si je smolit někde sám pro sebe, když z toho může mít prospěch i někdo jiný, ne?

Taky jsem se teprve teď dostal do stádia, kdy si troufám říct, že už se v tom už trochu orientuji. Pokud jde o Chef, tak když jsme to tehdy s kolegou probírali, sdělil mi i své důvody proč upřednostnil Puppet.

[Max]

Koukám, že taktéž nějakým způsobem podporuje nejen linux, ale i windows ... Hmm ...
Zdar Max

[Kozzi]

Skoda ze jsem si tento zapisek necetl hned jak vysel, zrovna nekolik par minut po jeho vydani, se me na pohovoru ptali jestli vim co je to Augeas :D. Jinak je zajimave ze o puppet jsem poprve slysel 17.4.2013 v souvislosti s foremanem na dnu otevrenych dveri v red hatu, hned na to jsem v patek po telefonickem pohovoru dostal za ukol vytvorit jednoduchy puppet manifest, chvili na to jsem potreboval pridat epel repositar a nestastnou nahodou jsem proklikl odkaz na seznam aktualnich baliku, kde zrovna na prvnim miste jako posledni aktualizovany byl opet puppet. A ted si ctu tento blogpost :D. To uz nemuze byt nahoda

[Karlos]

Pokud byste chtěli slyšet něco o Puppetu a Puppet Labs přímo od zakladatele Luka Kaniese, případně se ho na něco zeptat, můžete se zastavit v Plzni na semináři ZČU - Seminář Puppet Labs na ZČU.