Puppet (instalace)
Většinou je u linuxových distribucí Puppet k dispozici v jejich repozitářích a jeho instalaci tak lze provést přes standardní balíčkovací systém. Výchozí konfigurace však nemusí být všude stejná. Může být jiné nastavení cest k adresářům, moduly manifestu, a bůhví co ještě. Postupy a příklady s nimiž se lze tady setkat sice byly zpracované pro Debian, měly by však být použitelné univerzálně i přes to, že se u novějších verzí mohou v něčem lišit, neboť Puppet se stále vyvíjí.[1]
/etc/puppet
udržovat samostatný repozitář, a do něj po každé úpravě provádět uložení aktuálních změn, včetně komentářů. Mně osobně se osvědčilo přidat do tohoto adresáře i úložiště ssl certifikátů.
Jak už bylo zmíněno úvodem, Puppet je aplikace typu server/klient. Do verze 2.6 se používaly samostatné skripty, ale od verze 2.6 se používá jak pro server, tak klienta jeden a ten samý skript, psaný v Ruby, který může běžet v různých režimech, v závislosti na tom, jaký je předán první argument.
Pre-2.6 | Post-2.6 | Popis |
---|---|---|
puppetmasterd | puppet master | Serverový režim pro centralizovanou správu manifestů (server) |
puppetd | puppet agent | Režim agent pracující s centrálně udržovaným manifestem (klient) |
puppet | puppet apply | Režim agent, pracující s lokálním manifestem (klient bez síťové konektivity) |
puppetca | puppet cert | Režim pro práci s certifikáty (server) |
ralsh | puppet resource | Interaktivní agent (klient) |
puppetrun | puppet kick | Režim při kterém bylo možné vyvolat z jiného stroje vyvolat nějakou akci na straně agenta. V současné době je nahrazen samostatným řešením MCollective |
puppetqd | puppet queue | Režim který odesílal provedené změny do centrální databáze. V současné době je nahrazen aplikací PuppetDB |
filebucket | puppet filebucket | Klient pro práci se soubory v centralizovaném, resp. lokálním úložišti Puppetu (klient) |
puppetdoc | puppet doc | Ze souborů manifestu umí vytáhnout vložené dokumentační řetězce (server), jinak funguje jako aktuální dokumentace k Puppetu. |
pi | puppet describe | Pomůcka pro výpis dokumentace typů a metaparametrů na příkazové řádce (server/klient) |
Instalace a konfigurace prostředí stroje master
Chceme-li využívat Puppet pro centralizovanou správu, musíme nejprve nainstalovat stroj co bude fungovat jako server - master, se kterým pak budou komunikovat agenti z klientských nodů. Je dobré od samého počátku počítat s tím, že i tento stroj bude spravován sám sebou a pro tento účel odpovídajícím způsobem pozměnit výchozí konfiguraci.
Pro instalaci serverové části Puppetu je v Debianu balík, který se jmenuje puppetmaster. Od instalačního balíku puppet, který je určen pro klientské nody, se liší především v tom, že obsahuje navíc soubory, které by byly na klientském nodu zbytečné.
Instalace přes standardní balíčkovací systém (APT) je nejrozumnější, neboť se postará o splnění potřebných závislostí:
root@master~# apt-get install puppetmaster
|
Instalace z repozitářů puppetlabs
U Puppetu platí, že master by měl být vždy novější verze než agent. Je-li na stroji master nainstalován a průběžně aktualizován Debian unstable, tak by neměl vzniknout problém. Pro stable verze Debianu je však lepší nainstalovat master ze zdrojů, které udržuje přímo Puppet Labs, Inc.
Instalaci je třeba začít stažením příslušného .deb balíčku z https://apt.puppetlabs.com/ a jeho "manuální instalací". Viz následující příklad demonstruje stažení balíčku a instalaci pro Debian wheezy
Instalační balíček puppetlabs-release-wheezy.deb nainstaluje soubor /etc/apt/sources.list.d/puppetlabs.list který obsahuje záznam pro APT k repozitáři Puppet Labs, Inc., a jejich GPG klíč.
Chcete-li používat stejnou vývojovou verzi Puppetu jako je v unstable, tak před spuštěním aktualizace repozitářů odkomentujte řádky označené jako devel |
Výchozí konfigurace
Ve výchozí konfiguraci Debianu se používá pro všechny režimy stejné úložiště SSL certifikátů, které je v adresáři /var/lib/puppet/ssl
. Výchozí konfigurace Puppet však používá - není-li uvedeno jinak - jako výchozí adresář /etc/puppet/ssl
.
Je-li obsah /etc
udržován přes git(resp. etckeeper), je výhodnější používat výchozí nastavení Puppetu. Navíc se tím vyhnete problémům s certifikáty je-li master spravován přes agenta.
Stačí před spuštěním démona v režimu master zakomentovat řádek s nastavením proměnné $ssldir v hlavním konfiguračním souboru /etc/puppet/puppet.conf
a přesunou adresář s ssl certifikáty z /var/lib/puppet
do /etc/puppet
.
/etc/puppet/puppet.conf
lze změnit výchozí hodnoty proměnných i za běhu démona a dynamicky ovlivňovat prostředí Puppetu. Jinak lze měnit hodnoty výchozích proměnných:
- nastavením na příkazovém řádku při spuštění démona (prostřednictvím úprav konfiguračních souborů v
/etc/default
) - jednorázově, formou předaných argumentů při akcích na příkazové řádce
- nebo nastavením proměnných v konfiguračních souborech
Spouštění démonů
master
Nahození démona v režimu master lze provést buď přes výchozí init skript..
root@master~# /etc/init.d/puppetmaster start
|
Nebo spuštěním na příkazovém řádku v režimu master
root@master~# puppet master
|
Před nahozením však není od věci přesvědčit se, zdali démon v režimu master již neběží. To lze provést buď přímo dotazem přes init skript..
root@master~# /etc/init.d/puppetmaster status
[ ok ] master is running.
|
..nebo přímo kontrolou spuštěných procesů..
root@master~# ps -ef | grep master
puppet 1849 1 0 srp02 ? 00:16:28 /usr/bin/ruby1.8 /usr/bin/puppet master
|
Přímé spouštění přes příkazovou řádku má tu výhodu, že můžeme jeho prostřednictvím změnit výchozí konfigurační volby démona. Viz následující příklad pro spuštění démona v ukecaném režimu:
root@master~# puppet master --verbose --debug
|
Není-li konfigurací určeno jinak, zapisuje démon veškeré zprávy do souboru /var/log/daemons
agent
Pokud chcete stroj, na kterém máte nainstalován Puppet a démona spuštěného v režimu master spravovat přes agenta, tak u Debianu nejspíš narazíte na to, že vám bude chybět init skript pro jeho spouštění. Nezbyde, než ho vytáhnout z instalačního balíku puppet, který je určen pro klienty. Balík lze stáhnout přes APT a pak z něj init skript vytáhnout pomocí dpkg-deb a umístit do adresáře /etc/init.d
V každém případě však potom bude nutné upravit spouštění init skriptů tak, aby byl nejprve spuštěn démon v režimu master a až pak v dalším procesu další instance v režimu agent
Puppetizace stroje
U Puppetu platí, že co není specifikováno v manifestem, na to agent nehrabe, ovšem bez specifikace nodu by agent skončil chybou, takže proces puppetizace započneme vždy tím, že na stroji, který slouží jako master, vytvoříme v souboru /etc/puppet/manifests/site.pp
, který je výchozím bodem při sestavení manifestu, prázdný záznam:
node 'puppet' {
}
|
Až pak bychom měli pokračovat vygenerováním SSL certifikátu a jeho podepsáním. Také je žádoucí, aby před vystavením a podepsáním certifikátu agent neběžel jako démon. Mohlo by se totiž stát, že by se po podepsání certifikátu agent "chytnul" na manifest náležející jinému stroji a na jeho základě provedl nežádoucí změny.
Certifikát
Ověřený SSL certifikát Puppet používá k šifrování síťové komunikace serverem, který poskytuje manifesty a klientem, který vygenerovaný manifest zpracovává.
Žádost klienta o certifikát
Vystavení žádosti o podepsání certifikátu provedeme jednoduše tím, že spustíme na příkazové řádce agenta.
root@stroj:/etc# puppet agent --noop --test --verbose --server master.felk.cvut.cz
|
Pokud si necháváme vystavit certifikát z jiného stroje, než kde běží master a v DNS, ani v /etc/hosts
, ani v hlavním konfiguračním souboru /etc/puppet/puppet.conf
v proměnné $server pro něj není záznam, můžeme uvést IP adresu serveru jako hodnotu atributu přímo na příkazové řádce. Stejným způsobem můžeme "předhodit" prostřednictvím parametru atributu --fqdn jméno, pod kterým se má agent hlásit při generování manifestu.
root@stroj:/etc# puppet agent --noop --test --verbose --server master.felk.cvut.cz --fqdn puppet.example.net
|
Vystavenný SSL certifikát se pak musí na stroji master podepsat. Pak se jím bude šifrovat vzájemná komunikace.
root@stroj:/# cat /etc/hostname
stroj-v-chroot
root@stroj:/# hostname
stroj
root@stroj:/# hostname $(cat /etc/hostname)
root@stroj:/# hostname
stroj-v-chroot
Podepsání certifikátu na straně serveru
Výpis seznamu žádostí, čekajících na podepsání na stroji master:
master (KVM) :~# puppet cert list
"stroj.felk.cvut.cz" (93:44:BC:C1:9F:1D:7E:6D:83:BD:24:E7:9A:0A:B3:82)
|
Podepsání čekající žádosti na stroji master:
Není-li v tomto okamžiku ještě nod nakonfigurován v manifestu, skončí vzájemná komunikace chybou.
Pokud se v síti může objevit více nodů se stejným hostname, které se liší pouze doménou, je třeba k tomu aby se manifest neaplikoval na všechny, uvést jméno nodu plným doménovým jménem. |
Ověření zda agent komunikuje se strojem master
Je-li u stroje, na kterém běží server pro Puppet v souboru /etc/hosts
uveden alias puppet
, nebo je-li tento server nastaven v konfiguraci agenta, pak na příkazové řádce nemusí být uváděn parametr --server
.
root@stroj:/etc# puppet agent --noop --test --verbose --server master.felk.cvut.cz
info: Caching catalog for stroj.felk.cvut.cz
info: Applying configuration version '1353687981'
|
Pokud proběhlo podepsání certifikátu v pořádku, tak proběhne komunikace bez chybových zpráv.
Ve výchozí konfiguraci je automatické spouštění agenta v souboru /etc/default/puppet zakázáno (v proměnné START). Povolte ho, až když budete mít připravený použitelný manifest.
|
Zavržení (revokace) certifikátu
Se aplikuje tehdy, pokud chceme zcela zamezit agentu ze stroje pro který byl certifikát původně vydán přístup ke stroji master.
Při revokaci totiž zůstává informace o původním certifikátu zachována a master případnou novou žádost ze stroje se stejným jménem na jejím základě odmítne přijmout.
Při revokaci nestačí uvést pouze jméno nodu, jak ho vrací operace list, ale musí být uvedeno i pořadové číslo certifikátu který chceme odvolat. To však lze zjistit pouze přes operaci print
U zavrženého certifikátu se pak bude při výpisu místo znaménka plus zobrazovat mínus.
Pro to, aby master přestal se zavrženým strojem komunikovat, se musí démon restartovat. |
Pokud by se vám omylem povedlo revokovat (tak jako mě) všechny certifikáty, tak pokud máte udržován přes git také adresář s Puppetími SSL certifikáty, tak si vytáhněte původní obsah souboru /etc/puppet/ssl/ca/ca_crl.pem a nahraďte stávající obsah tím původním.
|
Odstranění certifikátu
Odstranění certifikátu je operace, která používá pro..
- Odstranění čekajících a dosud nepodepsaných žádostí strojů, které nechceme spravovat přes Puppet.
- Zneplatnění a zrušení již podepsaných certifikátů strojů, které prošly reinstalací, nebo byly zrušeny. Podepsaný certifikát se nejprve zneplatní a následně se neplatný klíč odstraní z úložiště.
Vydání nového certifikátu
Pokud chceme z nějakého důvodu vydat certifikát nový - kupř. když u stávajícímu certifikátu vypršela platnost, nebo došlo k diskreditaci klienta, musí se nejprve na stroji master odstranit původní podepsaný certifikát a pak, na klientském stroji kde běží agent odstranit z úložiště SSL certifikátů původní podepsaná žádost o certifikát, která se nalézá v adresáři ./puppet/ssl/certificate_requests
i vydaný klíč (v adresáři ./puppet/ssl/certs
)
Teprve poté je možné vygenerovat novou žádost o certifikát, kterou bude možné na stroji master podepsat.
Než spustíme démona...
Je vhodné nejprve vyzkoušet zpracování manifestu "nasucho", spuštěním v testovacím módu[2] s atributem --noop, který zabrání tomu aby došlo k jeho realizaci:
root@client~# puppet agent --noop --test --verbose
...
|
Z výpisu tak budeme moci zjistit jaké změny se budou realizovat a především odhalit ještě před spuštěním démona chyby, na kterých by selhalo zpracování manifestu. A ty ošetřit buď na straně manifestu (na stroji master), nebo v systému klienta, tak aby zpracování manifestu démonem proběhlo bez problémů.
Prostředí a jejich kontext
Puppet umožňuje v rámci jednoho stroje master vytvářet vzájemně nezávislá prostředí (environment).
Každé z nich může mít svůj vlastní manifest i sadu modulů, takže lze udržovat paralelně vedle sebe moduly určené k nasazení v produkčním prostředí s moduly v testovacím prostředí, které se připravují pro budoucí produkční nasazení.
Výchozí prostředí, se jmenuje production a tento název je i výchozí hodnotou proměnné $enviroments , kterou používá agent na klientském nodu, pokud se mu nenastaví žádné jiné prostředí.
|
Vytvoření testovacího prostředí na stroji master
Do verze 3.6 Puppet akceptoval jako nové prostředí každý blok v konfiguračním souboru /etc/puppet.conf
na stroji master, který nepatřil mezi systémové konfigurační bloky (main, master, agent, user).
[jmeno_prostredi]
manifest = $confdir/$environment/manifests/site.pp
modulepath = $confdir/$environment/modules
|
Názvem prostředí, uloženým do proměnné $environment
, bylo jméno tohoto bloku. A tuto proměnnou bylo možné využít v nastavení cest k výchozímu manifestu a modulům. Pro toto prostředí ale musel existovat odpovídající adresář s obdobnou stromovou strukturou manifestu, jako u produkčního prostředí.
Od verze 3.6 však jsou akceptovány v konfiguračním souboru pouze systémové konfigurační bloky a jiné prostředí než je výchozí produkční lze vytvořit mnohem jednodušeji tak, že se v bloku main, nebo master uvede do proměnné $enviromentpath
cesta k adresáři v němž je podadresář s konfiguračním manifestem prostředí. Jeho název je automaticky názvem proměnné $environment
se kterou pracuje klient.
environmentpath = $confdir/environment
|
Cest k prostředí lze nastavit i více. V takovém případě musí být odděleny dvojtečkou.
Každý adresář s vytvořeným prostředím může obsahovat kromě podadresářů manifests
a modules
také konfigurační soubor enviroment.conf
, ve kterém lze změnit výchozí proměnné specifické pro toto prostředí:
- modulepath
- Cestu k modulům
- manifest
- Cestu k výchozímu manifestu
- config_version
- Číslo verze
- environment_timeout
- Časový interval po který mají být uchovávány dočasné soubory prostředí
Aplikace testovacího prostředí na straně agenta
Pokud se spouští na straně klienta agent jako démon a chceme aby používal místo produkčního prostředí moduly z testovacího prostředí s názvem jmeno_prostredi
, pak je třeba do konfigračního souboru /etc/puppet.conf
na straně klienta nastavit v sekci agent
jako hodnotu proměnné environment jeho jméno.
[agent]
environment = jmeno_prostredi
|
Automatické spouštění agenta
Pokud nechceme aby se změny realizovaly automaticky, můžeme init skript, přes který se agent spouští jako démon deaktivovat a pak agenta spouštět na příkazové řádce ručně. Jméno testovacího prostředí mu pak lze předávat jako hodnotu parametru --environment
:
root@stroj~# puppet agent --environment jmeno_prostredi
|
Při použití testovacího prostředí Puppet využívá již existujícího SSL certifikátu, tudíž není nutné proces s vydáním certifikátu opakovat. |
/var/log/daemon.log
Změna intervalu
Výchozí půlhodinový interval pro běžnou správu bohatě stačí, pokud však ladíme nastavení manifestu a potřebujeme aby agent kontroloval master v kratším intervalu, pak jej lze zkrátit nastavením číselné hodnoty proměnné runinterval v sekci [main]
konfiguračního soubor /etc/puppet/puppet.conf
. Ta má ve výchozím stavu hodnotu 1800 (sekund).
Je-li hodnota 0
, tak bude agent kontaktovat master ihned jakmile skončí ověření staženého manifestu, které se pohybuje v řádech sekund.
Prodleva