Před nedávnem jsme se na stránkách časopisu podívali na systém dálkové ovládání konfigurace UNIXových strojů Cfengine, což značně zjednodušuje život správce systému automatizací kroků pro konfiguraci mnoha síťových uzlů. Ale bez ohledu na to, jak pohodlný je Cfengine, má mnoho nevýhod, které systém zvaný Puppet nemá.

Představte si sami sebe v roli systémového administrátora, zodpovědného za údržbu funkčnosti stovek strojů s operačními systémy typu UNIX. Každý z nich vyžaduje konfiguraci, pravidelnou aktualizaci a monitorování a předpokládá se, že mnoho z nich plní podobné funkce.

Dvě třetiny jsou pracovní stanice, několik dalších jsou routery a zbytek tvoří několik webových serverů a datových úložišť. Otázka: jak řídit celý tento obchod? Nejjednodušší odpovědí je jednoduše se připojit ke každému z nich pomocí SSH a provést potřebné změny. Tato metoda má však dva problémy. Za prvé je to velmi pracné. Za druhé, administrátor bude muset neustále provádět mnoho monotónních akcí (například pro aktualizaci OpenOffice.org na všech pracovních stanicích budete muset stejné příkazy provést několikrát). Tomuto problému se můžete pokusit vyhnout napsáním několika skriptů, které se samy připojí ke každému počítači a provedou předem napsané příkazy. Ale i zde na vás čekají problémy.

Skripty se budou muset neustále upravovat, aby se přizpůsobily každému úkolu; Skripty budou muset brát v úvahu rozdíly v operačních systémech a verzích a před aplikací na běžící stroje budou muset být dlouho laděny. Obecně, ne comme il faut. Správnou odpovědí je použití tzv. systémů pro správu vzdálené konfigurace, jejichž nejznámějšími zástupci jsou otevřené systémy Cfengine a loutka. Takové systémy přebírají veškerou odpovědnost za uvedení konfigurace stroje do správný typ, vyžadující od administrátora pouze popis konečného stavu systému ve speciálním jazyce (například popis toho, jaké balíčky by měly být nainstalovány v OS, jaké řádky by měly být přidány do konfiguračních souborů, jaké příkazy by se měly provádět atd. ). Poté všechny uzly samy obdrží informace o požadovaném stavu ze serveru a provedou automatickou konfiguraci systému. Díky tomuto mechanismu lze nové stroje plně konfigurovat bez lidského zásahu a stávající lze překonfigurovat přidáním pouhých několika řádků do popisu stavu.

Loutka?

Systému Cfengine jsme již věnovali celý článek, a tak se dnes zaměříme na systém Puppet, který lze klidně nazvat jeho ideovým nástupcem. Puppet byl vyvinut Lukem Kaniesem, kterého omrzela Cfenginova omezení a rozhodl se vytvořit lepší verzi od začátku. Pokud jste již Cfenfine používali, pravděpodobně zjistíte, že Puppet je pohodlnější a výkonnější systém. Státní jazyk Puppet je na vyšší úrovni a flexibilnější, což znamená, že se správce nemusí starat o věci, jako je psaní samostatných pravidel pro každý typ OS nebo podrobný popis provádění triviálních akcí. Puppet umožňuje svému pánovi soustředit se na to, co chce dělat, místo toho, jak to udělat (například pro instalaci konkrétního balíčku na některý z podporovaných operačních systémů systému stačí napsat doslova pár řádků „Nainstalujte tento program“ " místo popisu příkazů nezbytných pro jeho instalaci). Puppet je napsán v jednoduchém jazyce Ruby, což usnadňuje jeho přizpůsobení konkrétnímu úkolu a rozšíření jeho funkčnosti (je poskytován flexibilní systém pluginů).

Navíc, na rozdíl od vývojového modelu Cfengine, který se v podstatě točí kolem jedné osoby, má Puppet velkou komunitu nadšenců, kteří vylepšují kód, sdílejí příklady konfigurace a píší dokumentaci.

Celkově se Puppet zdá být modernějším a sofistikovanějším systémem dobrý design. Stejně jako Cfengine podporuje téměř všechny moderní operační systémy typu UNIX (včetně MacOS X) a může také běžet v prostředí Cygwin nad Windows. Jeho seznam závislostí obsahuje pouze interpret Ruby a nástroj Factor, takže by neměly být žádné problémy s instalací (abych byl spravedlivý, seznam závislostí Cfengine je ještě kratší).

Instalace

Stejně jako Cfengne, Puppet je systém klient-server, který se skládá z řídicího serveru a slave uzlů. Server ukládá popis konečných stavů uzlů (který se v podmínkách loutky nazývá manifest) a čeká, až se připojí. Klient se každou půlhodinu (standardně) připojí k serveru, obdrží od něj popis konečného stavu, porovná jej s aktuálním a v případě, že se změnil a/nebo popsaný stav, překonfiguruje systém a poté jde spát. Komunikace probíhá šifrovaným kanálem, takže jsou vyloučeny útoky založené na substituci popisu stavu (ale pokud útočník převezme server, pak budou všechny uzly pod jeho kontrolou).

Puppet je součástí repozitářů všech populárních distribucí, takže jeho instalace by neměla být obtížná. Například na Debian/Ubuntu lze klienta Puppet nainstalovat takto:

$ sudo apt-get install loutka

A server je takový:

$ sudo apt-get install puppet puppetmaster

Konfigurační soubory klienta a serveru jsou uloženy v adresáři /etc/puppet. Nejdůležitější z nich je soubor /etc/puppet/manifests/site.pp, který obsahuje manifest.

Ukládá popis stavů a ​​měl by existovat pouze na serveru. Pro usnadnění ladění do něj přidáme jednoduchou konfiguraci:

class passwd(
soubor("/etc/passwd":
vlastník => root,
skupina => kořen,
režim => 644,
}
}
výchozí uzel (
zahrnout heslo
}

Tyto řádky popisují stav, ve kterém musí být vlastník souboru /etc/passwd root a jeho oprávnění jsou nastavena na 644. V další části se podíváme blíže na formát souboru manifestu. Druhým nejdůležitějším souborem je /etc/puppet/puppet.conf. Nastavuje konfiguraci serveru a klientů, takže musí být přítomen na všech počítačích organizovaných v síti Puppet. V Ubuntu tento soubor obsahuje minimální nutné a ve většině případů dostačující nastavení. Níže jsou uvedeny s komentáři:

# vi /etc/puppet/puppet.conf
# Standardní cesty k adresářům
logdir=/var/log/puppet
vardir=/var/lib/puppet
ssldir=/var/lib/puppet/ssl
rundir=/var/run/puppet
# Umístění nástroje Factor,
# slouží k získání informací o OS
factpath=$vardir/lib/facter
# Synchronizujte pluginy
# (nainstalované pluginy na serveru - jsou zkopírovány do klientů)
pluginsync=true
# Katalog se šablonami (přečtěte si o nich níže)
templatedir=$confdir/templates
# Synchronizace s etckeeper
# (kdo ví, pochopí, ostatní to nepotřebují)
prerun_command=/etc/puppet/etckeeper-commitpre
postrun_command=/etc/puppet/etckeeper-commitpost

Konfigurační soubor může obsahovat velký počet různé možnosti, informace o nich lze získat vygenerováním výchozí konfigurace:

$ sudo puppetmasterd -genconfig > /etc/puppet/
puppetd.conf.default

Výchozí konfigurace klienta se generuje pomocí jiného příkazu:

$ sudo puppet -genconfig > /etc/puppet/puppetd.conf.default

Ke konfiguraci se používají soubory Fileserver.conf a auth.conf souborový server(přečtěte si o tom v části „Souborový server“) a ověřování. Zatím nemá smysl se jich dotýkat. Po dokončení konfigurace je nutné restartovat server Puppet:

$ sudo /etc/init.d/puppetmaster restart

Poté bude připraven přijímat požadavky zákazníků. Bez podepsaného certifikátu však žádný klient nebude moci přijmout manifest ze serveru a nakonfigurovat počítač.

Proto musíme klienty Puppet spustit v testovacím režimu, aby mohli odeslat své certifikáty serveru k podpisu (mimochodem, lze to provést na všech počítačích současně pomocí nástroje shmux):

$ sudo puppetd -server puppet-server.com -verbose -test

Vrátíme se na server a obdržíme seznam certifikátů připravených k podpisu:

$ sudo puppetca --list

Vyberte hostitele ze seznamu a podepište jeho certifikát:

$ sudo puppetca --sign nomad.grinder.com

Nebo podepíšeme vše najednou:

$ sudo puppetca --sign --all

Nyní můžete spustit klienty v bojovém režimu. Nejprve však musíte zadat název serveru Puppet do konfiguračního souboru (ve výchozím nastavení je jeho název jednoduše puppet):

$sudo su
# echo "" >> /etc/puppet/puppet.conf
# echo "server=puppet-server.com" >> /etc/puppet/puppet.conf
# východ

Spouštění klientů:

$ sudo /etc/init.d/puppet start

Jazyk popisu stavu

Jak již bylo zmíněno výše, Puppet používá svůj vlastní jazyk pro popis konečného stavu operační systém, s jehož pomocí správce systému udává, do jaké podoby mají být součásti OS uvedeny, aby dosáhl požadovaného stavu. Jedná se o poměrně složitý jazyk, který je však mnohem jednodušší než jakýkoli programovací jazyk. Pokud jste alespoň povrchně obeznámeni se skriptovacím jazykem bash, snadno porozumíte jazyku Puppet. Klíčovým prvkem jazyka jsou prostředky, které se používají k popisu toho, do jaké podoby by měla být jedna z komponent operačního systému převedena. Například následující jednoduchý zdroj popisuje požadovaný stav souboru /etc/passwd:

# vi /etc/puppet/manifests/site.pp
soubor("/etc/passwd":
vlastník => "root"
}

Zde je soubor typu prostředku. Celkem jich je několik desítek, od zdrojů, které spravují soubory, jako v tomto příkladu, až po balíčky a služby. Řádek /etc/passwd je název zdroje.

V případě typu souboru je název stejný jako cesta k souboru, ale u některých jiných typů může být název libovolný. Řádek vlastník => "root" popisuje nastavení atributu vlastníka na root, to znamená, že říká, že vlastník zadaný soubor musí existovat správce.

Každý typ zdroje má svou vlastní sadu atributů, které lze upravit, a navíc existují speciální meta atributy, které lze použít v libovolném zdroji. Jednou z důležitých vlastností zdrojů je schopnost na ně odkazovat. To lze použít k vytvoření řetězců závislostí. Následující záznam vytvoří prostředek /etc/group, který závisí na prostředku /etc/passwd (závislosti se zadávají pomocí atributu required meta):

# vi /etc/puppet/manifests/site.pp
soubor("/etc/group":
vyžadovat => Soubor["/etc/passwd"],
vlastník => "kořen",
}

To znamená, že prostředek /etc/group lze nakonfigurovat (přenést do popsaného formuláře) pouze tehdy, když je nakonfigurován prostředek /etc/passwd. Prostředky lze seskupit do kolekcí zdrojů nazývaných třídy. To je nezbytné pro spojení zdrojů, které mají podobný význam a typ prováděného úkolu, do jednoho abstraktního zdroje. Pro pohodlí bychom například mohli zkombinovat instalaci a spuštění webového serveru nginx do jednoho abstraktního zdroje se stejným názvem:

# vi /etc/puppet/manifests/site.pp
třída nginx(
balíček("nginx":
zajistit => nainstalováno
}
služba("nginx":
zajistit => běh,
vyžadovat => Balíček["nginx"],
}
}

Zde se typ prostředku balíčku používá k instalaci balíčku nginx do systému a služba se používá ke spuštění služby se stejným názvem. S požadavkem donutíme systém ke spuštění služby pouze v případě, že byl balíček úspěšně nainstalován. Výhodou tříd je, že mohou být také zahrnuty v závislosti na:

# vi /etc/puppet/manifests/site.pp
služba("chobotnice":
zajistit => běh,
vyžadovat => Třída["nginx"],
}

Stejně jako ve skutečných jazycích OOP mohou třídy od sebe dědit a přepisovat atributy:

# vi /etc/puppet/manifests/site.pp
class passwd(
soubor("/etc/passwd":
vlastník => "kořen",
skupina => "kořen",
}
}
class passwd-bsd zdědí passwd (
Soubor["/etc/passwd"] ( skupina => "kolečko" )
}

Zde třída passwd-bsd dědí z passwd, aby přepsala atribut group zdroje /etc/passwd (na systémech BSD patří /etc/passwd do skupiny wheel, takže jsme pro takové systémy vytvořili samostatnou třídu). Později se podíváme na správnější a zjevnější způsob výběru alternativních hodnot atributů pomocí podmínek.

Proměnné jsou jednou z nedílných součástí každého programovacího jazyka a má je také Puppet. Proměnné začínají znakem $ a mohou obsahovat libovolné číslo, řetězec nebo booleovská hodnota(pravda, nepravda):

$want_apache = true
$apache_version = "2.2.14"

Jednou z nejvýkonnějších funkcí aplikace Puppet související s proměnnými je její integrace s nástrojem facter machine information tool. Tento nástroj vrací všechny informace specifické pro počítač ve formě párů klíč-hodnota, které jsou v Puppet převedeny na proměnné stejného jména. Spolu s podmíněnými instrukcemi v jazyce Puppet je lze použít ke změně atributů prostředků v závislosti na vlastnostech stroje.

Například výše popsanou třídu passwd lze snadno přepsat tak, aby automaticky vybrala atribut v závislosti na typu operačního systému (aniž by byla potřeba samotná třída):

# vi /etc/puppet/manifests/site.pp
soubor("/etc/passwd":
vlastník => "kořen",
skupina => $kernel ? (
Linux => "root",
FreeBSD => "kolo",
},
}

V závislosti na operačním systému, na kterém bude tento fragment manifestu analyzován, bude hodnota atributu group buď root nebo wheel. Kromě podmíněný operátor, jazyk Puppet také podporuje operátor výběru případu, který lze použít k vytvoření konkrétního zdroje v závislosti na hodnotě proměnné:

# vi /etc/puppet/manifests/site.pp
případ $operační systém (
redhat: (služba("httpd": zajistit => běží))
debian: (service("apache": zajistit => běží))
výchozí: ( služba ( "apache2": zajistit =>
běh))
}

Tento kód definuje různé možnosti zdroj typu služby v závislosti na operačním systému (názvy služeb v různých distribucích Linuxu se mohou lišit, takže kterou službu má Puppet spouštět, je nutné specifikovat individuálně pro každou z nich).

Výchozí možnost se použije, pokud hodnota proměnné neodpovídá žádné z předchozích možností. Kromě dříve diskutovaných typů souborů, balíčků a služeb Puppet podporuje velké množství dalších typů zdrojů, včetně těch, které vytvořili vývojáři třetích stran. Jejich podrobný popis včetně příkladů, podporovaných atributů a funkcí naleznete v oficiální dokumentaci – http://docs.puppetlabs.com/references/stable/type.html. Níže je uveden seznam a stručný popis nejpoužívanější jsou:

Populární typy loutkových zdrojů

• cron - správa úloh cron
• exec - spouštění skriptů a příkazů
• soubor - správa souborů
• filebucket - zálohování soubory
• skupina - řízení skupiny
• hostitel - správa položek v souboru /etc/hosts
• interface - konfigurace síťových rozhraní
• mount - připojení souborových systémů
• notify - odeslání zprávy do souboru protokolu Puppet
• balíček - správa balíčků
• servis - správa služeb
• sshkey - správa klíčů SSH
• tidy - mazání souborů v závislosti na podmínkách
• uživatel - správa uživatelů
• zóny - správa zón Solaris

Druhým nejdůležitějším prvkem jazyka Puppet po zdrojích jsou uzly. S jejich pomocí může administrátor popsat, na které stroje by měly být použity určité prostředky a třídy. Jinými slovy, je to způsob, jak specifikovat individuální konfiguraci pro každý ze strojů účastnících se sítě Puppet. Nejjednodušší příklad uzlu je uveden na začátku článku v části „Instalace“:

# vi /etc/puppet/manifests/site.pp
výchozí uzel (
zahrnout heslo
}

Toto je definice výchozího uzlu, který zahrnuje prostředek/třídu passwd. Výchozí název znamená „všechny ostatní uzly“, takže prostředek/třída passwd definovaná někde výše bude nakonfigurována na každém z nich. Klíčové slovo include je zde použito pro usnadnění ve skutečnosti lze všechny třídy a prostředky popsat přímo v popisu uzlu, ale nedoporučuje se to. Kromě výchozího nastavení můžete v názvu uzlu zadat síťový název počítače (pak budou všechny prostředky popsané v uzlu konfigurovány pouze na tomto počítači) nebo libovolný název (tento uzel pak může zdědit jiný uzel) . Abychom pochopili, jak to všechno funguje společně s třídami a prostředky, podívejme se na příklad hotového manifestu Puppet používaného ke konfiguraci dvou síťových strojů (webového serveru a serveru NTP):

# vi /etc/puppet/manifests/site.pp
# Instalace a spuštění serveru SSH
třída sshd(
balíček ( openssh-server: zajistit => nainstalováno )
služba (sshd:
jméno => $operační systém ? (
fedora => "sshd",
debian => "ssh",
výchozí => "sshd",
},
povolit => pravda,
zajistit => běh,
}
}
# Nainstalujte a spusťte Apache
třída httpd(
balíček ( httpd: zajistit => nainstalováno )
služba (httpd:
povolit => pravda,
zajistit => běh,
}
}
# Instalace a spuštění serveru NTP
třída ntpd(
balíček ( ntp-server: zajistit => nainstalováno )
služba (
ntp server:
povolit => pravda,
zajistit => běh,
}
}
# Základní uzel používaný pouze jako rodič všech ostatních
základna uzlů (
zahrnout sshd
}
# Uzel, kde bude umístěn webový server
uzel web.server.com zdědí základ (
zahrnout httpd
}
# Uzel serveru NTP
uzel ntp.server.com dědí základ (
zahrnout ntpd
}

Tato zdánlivě jednoduchá konfigurace dělá docela hodně: nainstaluje a spustí Apache na stroji na web.server.com a na stroji nainstaluje a spustí NTP server. ntp.server.com. Oba počítače navíc nainstalují server SSH. Tato konfigurace pravděpodobně nebude vyhovovat ani jednomu správci; bude muset být vážně vylepšen, aby se naučil, jak správně konfigurovat servery, přijímat čerstvé konfigurace a další soubory z hlavního serveru Puppet.

Jasně však ukazuje sílu Puppet. Pomocí jednoduché konfigurace jsme donutili stroje, aby si samy nainstalovaly a spustily potřebný software a udržovaly jej v provozuschopném stavu (pokud se server zhroutí, Puppet se sám překonfiguruje, aby uvedl systémy do požadovaného stavu).

Souborový server

Mnoho úloh vzdálené správy nelze vyřešit bez kopírování do počítačů další soubory. Mohou to být předem připravené konfigurace, webové stránky pro Apache, balíčky, které nejsou v oficiálním úložišti, a mnoho dalšího. Pro usnadnění procesu přenosu těchto souborů na vzdálené hostitele obsahuje Puppet souborový server.

Nastavení souborového serveru jsou uložena v souboru /etc/puppet/fileserver.conf. Chcete-li přinutit Puppet poskytovat klientům obsah konkrétního adresáře, musíte do něj vložit několik řádků:

# vi /etc/puppet/fileserver.conf
cesta = /var/puppet/files
povolit *.server.com

Tyto dva řádky označují, že adresář /var/puppet/files by měl být přístupný všem hostitelům v doméně server.com. Kromě toho můžeme zadat celé doménové jméno povoleného stroje nebo jeho IP adresu a také odříznout nechtěné pomocí direktivy deny. Jakýkoli soubor v tomto adresáři lze poté přesunout do klienta pomocí prostředku souboru. Například:

# vi /etc/puppet/manifests/site.pp
soubor("/etc/httpd/conf/httpd.conf":
zdroj => "puppet://httpd/httpd.conf",
režim => 644,
}

Soubor httpd.conf, který se nachází na serveru v adresáři /var/puppet/files/httpd, bude zkopírován do cílového počítače cestou zadanou v názvu prostředku.

Závěry

V tomto článku jsme pokryli velmi malou část schopností Puppet. Ve skutečnosti je komplexní systém, kterou lze plně popsat pouze na stránkách knihy. Zároveň se Puppet velmi snadno konfiguruje a udržuje, zejména proto, že na internetu najdete spoustu příkladů jeho konfigurace.

Info

• Puppet používá protokol HTTP, takže jej lze spustit pod webovým serverem pro zlepšení výkonu.
• Puppet lze použít k automatické konfiguraci a údržbě jednoho místního počítače.
• Kombinací Puppet, síťové instalace operačního systému (pxe-install) a vlastních instalačních obrazů můžete vytvořit zcela samokonfigurující síť počítačů, kterou lze nasadit pouze jedním příkazem.
• Mnoho velkých společností používá při své práci Puppet, jako je Google, Fedora Project, Stanford University, Red Hat, Siemens IT Solution a SugarCRM.

Odkazy

• http://docs.puppetlabs.com - Dokumentace loutek
• http://docs.puppetlabs.com/guides/language_tutorial.html - Celý popis Jazyk loutky
• http://docs.puppetlabs.com/references/stable/type.html – Typy zdrojů

Když je počet serverů, které spravujete, menší než deset, málokdy někdo přemýšlí o jejich centralizované správě, nemusí to být nutné. Když existují desítky serverů, centralizovaná správa softwaru a konfigurace je nesmírně užitečná. Když existují stovky a tisíce serverů, je to životně důležité. Existuje mnoho programů tohoto druhu, například: Chef, CFEngine, Puppet... Právě o tom druhém se bude diskutovat v tomto příspěvku.

Loutka je právem považována za jednu z nejlepší řešení takhle. Používají jej společnosti jako Google, Citrix a Red Hat. Jedná se o klient-server aplikaci napsanou v programovacím jazyce Ruby, která je distribuována ve dvou verzích:

• Puppet Open Source - kompletně bezplatná verze
• Puppet Enterprise – zdarma až pro 10 serverů, poté jsou vyžadovány licence

Zvažme instalaci Puppet Open Source serveru a agenta, které jsou součástí balíčků většiny moderních distribucí. Dále budeme hovořit o Ubuntu 12.04 Precise Pangolin.

Zadní konec Puppet se nazývá loutkář, začněme instalaci odtud:

A nyní klient:

V konfiguračním souboru klienta /etc/puppet/puppet.conf musíte mluvit o serveru přidáním následující části:

Server=puppet.local report=true pluginsync=false

V počáteční fázi je lepší pluginsync vypnout.

Spusťte loutkového klienta tak, aby vytvořil požadavek na certifikát:

Na serveru musíte zkontrolovat, zda byla žádost o certifikát přijata, a pokud ano, vystavit certifikát:

Opakujte předchozí krok na klientovi:

Skvělé, vše funguje. Pojďme k vytvoření prvního manifestu. Manifesty nebo konfigurace jsou popsány speciálním deklarativním jazykem. Okamžitě si zvykneme na dobré věci, použijeme modulární strukturu a třídy. Pojďme si například napsat modul, který bude udržovat soubor aktuální /etc/hosts na všech našich serverech.

Podívejme se, kde loutka hledá moduly:

Vytvořte adresáře pro váš modul

Měl by se volat první manifest, také známý jako soubor hlavního modulu init.pp

Hostitelé třídy ( # puppet.local hostitel ( "puppet.local": secure => "prezent", target => "/etc/hosts", ip => "192.168.0.1", aliasy hostitele => "loutka", ) # hostitel linux.local ("linux.local": zajistit => "prezentovat", cíl => "/etc/hosts", ip => "192.168.0.2", aliasy hostitele => "linux", ) )

Ve výchozím nastavení loutka hledá soubor /etc/puppet/manifests/site.pp pro načtení konfigurace ji převeďte do následujícího tvaru:

Výchozí uzel (zahrnout hostitele)

Zkontrolujeme manifest na serveru:

Na klientovi:

Poté, co jsme si jisti, že vše funguje, umožníme spuštění služby, in /etc/default/puppet přeměna:

# Spustit loutku na botě? START=ano

Spuštění služby

Puppet bude každých 30 minut dotazovat server puppetmaster na změny konfigurace a v případě potřeby odpovídajícím způsobem upraví systém.

Před časem přesáhl seznam serverů v mých záložkách 200. S rostoucím počtem serverů zabírá nasazení jakékoli nové konfigurace nebo instalace nových balíčků obrovské množství času. Tak jsem se rozhodl použít loutku.
Loutka(anglicky puppet) je multiplatformní aplikace klient-server, která umožňuje centrálně spravovat konfiguraci operačních systémů a programů nainstalovaných na několika počítačích. Puppet je napsán v programovacím jazyce Ruby.

Říká se také, že puppet je systém pro správu vzdálené konfigurace, jehož nejznámějšími představiteli jsou otevřené systémy Cfengine a Puppet.

Po přečtení recenzí jsem se rozhodl použít loutku.

Instalace a konfigurace loutkového serveru:
Instalace loutkového serveru:
Nainstalujte puppet-server na OpenSuSE 11.4:

zip v loutkovém serveru

Změňme název serveru na loutkový:
/etc/HOSTNAME:

DNS záznam musí být přeložen na 127.0.0.2
cat /etc/hosts:

127.0.0.2 loutka.site loutka

Dejme uživatelská práva loutka:

Spustíme službu Puppet Master:

spuštění rcpuppetmasterd

Ke spuštění přidáme spuštění loutkového démona:

chkconfig -a puppetmasterd

Nastavení loutkového serveru:
Definujme adresář, kam se budou ukládat soubory, které bude loutkový server přenášet na klientské stroje v manifestech typu souboru.

vim /etc/puppet/fileserver

cesta /etc/puppet/files
povolit *

mkdir /etc/puppet/files

chown -R puppet:puppet /etc/puppet/files

Vytvoříme soubor libovolného obsahu pro nasazení a testování na klientech

dotkněte se /etc/puppet/files/puppettetesting

Restartujeme loutkový server:

restart rcpuppetmasterd

Loutka používá pro popis konečného stavu operačního systému svůj vlastní jazyk, pomocí kterého správce systému udává, do jaké podoby má uvést komponenty OS, aby dosáhl požadovaného stavu. Stav může znamenat přítomnost konkrétního souboru, složky, spuštěných služeb, nainstalovaných balíčků, aktualizací a dalších. Všechna nastavení stavu jsou popsána v souborech nebo manifestech, které jsou umístěny v adresáři: /etc/puppet/manifests. Tyto soubory mají názvy jako *.pp.

Pojďme vytvořit to nejjednodušší manifest:
/etc/puppet/manifests/1.file.pp:

soubor("/tmp/puppettetesting":
zdroj => "puppet:///files/puppettesting",
}

Chcete-li použít tento manifest:
loutka aplikovat 1.soubor.pp

Instalace a konfigurace loutkového klienta:

zip v loutce

Dejme uživateli práva loutky:

chown -R puppet.puppet /var/lib/puppet/

Pro navázání spojení s loutkovým serverem odešle loutkový klient požadavek na potvrzení certifikátu po potvrzení této žádosti na serveru začne loutkový klient používat pro něj určené manifesty. Zašleme žádost o potvrzení certifikátu:

Na serveru můžeme vidět, jaké požadavky na potvrzení čekají:

"loutka-klient.místní doména" (B5:12 :69 :63 :DE:19 :E9:75 :32 :2B:AA:74 :06:F6:8E:8A)

Potvrzujeme:

puppetca --sign "puppet-client.localdomain"

Je čas podívat se na nejjednodušší příklady vytváření manifestů:
vytvořte soubor /etc/puppet/manifests/site.pp:

výchozí uzel (
soubor("/tmp/puppettetesting":
zdroj => "puppet:///files/puppettesting",
}
služba("ntp":
zajistit => běh,
povolit => true ,
}
balíček("htop":
zajistit => nainstalováno,
}
}

výchozí - platí pro všechny klienty
soubor - tato sekce říká, že se má vytvořit nebo přepsat soubor /tmp/puppettetesting, který je umístěn na serveru v adresáři /etc/puppet/files
služba: zkontrolujte, zda je služba spuštěna, pokud neběží, spusťte ji a také ji přidejte do spuštění
balíček: zkontrolujte, zda je na klientovi nainstalován balíček htop, a pokud ne, nainstalujte jej.

Pro kontrolu spusťte na klientovi:

Jak můžete vidět, na klientovi byl přidán ntp do spuštění, byl spuštěn démon ntp, nainstalován balíček htop a soubor puppettetesting byl zkopírován do adresáře /tmp/

info: Caching katalog pro puppet-client.localdomain
info: Použití verze konfigurace "1370163660"
upozornění: / Stage[ main] // Node[ default] / Service[ ntp] / zajistit: zajistěte změnu "zastaveno" na "spuštěno"
upozornění: / Stage[ main] // Node[ default] / Package[ htop ] / secure: created
upozornění: / Stage[ main] // Node[ default] / File[ / tmp/ puppettesting] / zajistit: definovaný obsah jako "(md5)f2171ac69ba86781bea2b7c95d1c8e67"
upozornění: Dokončený běh katalogu za 3,95 sekundy

V příštím článku popíšu složitější příklady tvorby manifestů a webového rozhraní loutka-dashboard.

Populární typy loutkových zdrojů
cron- správa úloh cron
exec- spouštění skriptů a příkazů
soubor- správa souborů
filebucket- zálohování souborů
skupina- vedení skupiny
hostitel- správa záznamů v souboru /etc/hosts
rozhraní- konfigurace síťových rozhraní
namontovat- připojování souborových systémů
oznámit- odeslání zprávy do souboru protokolu Puppet
balík- správa balíků
servis- správa služeb
sshkey- Správa klíčů SSH
uklidit- mazání souborů v závislosti na podmínkách
uživatel- správa uživatelů
zóny- Správa zón Solaris

Něco málo o tom, jak Puppet funguje

Loutková abstrakce je něco takového ( porušování vzorů - zapomeňte na vše, co jste věděli o programovacích termínech!).

• Uzel je sada konfigurací pro konkrétní cílový systém. Ve skutečnosti se jedná o speciální případ třídy.
• Třída je sada deklarativní logiky, která je součástí konfigurace uzlu nebo jiných tříd. Třída nemá instance ani metody, ale má parametry a proměnné definované v rámci logiky. Ve skutečnosti je to spíše procedura, která může zdědit další proceduru pouhým přidáním kódu a ne tak banálním rozsahem proměnných.
• Typ- ale tohle vypadá spíš jako klasická třída - předpokládá instance s názvem a určitě zadanými parametry, ale nic víc. Konkrétní implementaci typu lze napsat jako skript Puppet pomocí define , který vytváří instance jiných typů, nebo jako rozšíření Ruby s nádechem fantazie.
• Zdroj- to jsou ve skutečnosti pojmenované instance Types. Každý název prostředku je jedinečný v rámci určitého typu v rámci konfigurace uzlu (adresáře).
• Proměnné- no, to jsou zkrátka konstanty... Před Puppet 4 to bylo s jejich rozsahem ještě horší. Nyní je to dostačující: pro použití mimo definiční umístění musí být specifikován plně kvalifikovaný identifikátor, s výjimkou případu dědičnosti třídy.

Ideologicky správným způsobem se infrastruktura Puppet skládá z agenta – privilegované služby na cílovém systému – a serveru, který na žádost agentů distribuuje cenné instrukce ve formě deklarativních adresářů zdrojů. Zabezpečení je implementováno na úrovni infrastruktury soukromých veřejných klíčů (X.509). Jednoduše řečeno, stejné mechanismy jako v HTTPS, ale s vlastní CA a povinným ověřením klientského certifikátu.

Ve zjednodušené podobě vypadá postup nasazení asi takto:

1. Zpracování přes TLS a X.509 (navázání spojení, aktualizace CRL, kontrola omezení certifikátů atd.)
2. Agent dostává ze serveru generátory faktů s cachováním a všemi věcmi (přesněji řečeno, vše se stahuje ze složek lib/ v modulech). Není těžké přidat svůj vlastní Ruby skript pro sběr informací, které vás zajímají.
3. Agent shromažďuje fakta o cílovém systému a posílá je na server. Všechna fakta lze snadno zobrazit ručně pomocí loutkového volání faktů. Tyto skutečnosti jsou dostupné jako globální proměnné.
4. Server sestaví katalog zdrojů a odešle jej agentovi. Pod tím se skrývá celá vrstva různých konceptů.
5. Agent stáhne vše potřebné ze serveru a přivede systém do zadané podoby. Agent sám neví, co dělat se zdroji, spoléhá na implementaci poskytovatelů (sémantický překlad bude „implementátor“, nikoli dodavatel) konkrétních typů zdrojů. Někteří poskytovatelé jsou standardní a jsou součástí balíčků Puppet zbytek je stažen z modulů.

• Modul- sbírka deklarativních skriptů Puppet, rozšíření Ruby pro Puppet, soubory, šablony souborů, data Hiera a mnoho dalšího. Správnější výraz by byl „balíček“.
• Prostředí- sada skriptů, modulů a dat Hiera. Jak se infrastruktura stávala složitější, bylo nevyhnutelně nutné rozdělit konfiguraci dále, než je standardní rozdělení podle uzlů. V zásadě je to vyžadováno pro pilotní inovace a banální řízení přístupu (kdy ne všichni správci mají přístup ke všem uzlům IT infrastruktury).
• Hiera- hierarchická databáze. Tato formulace může být velmi zastrašující. To je pravděpodobně důvod, proč byla změněna v dokumentaci pozdějších verzí. Ve skutečnosti se jedná o extrémně jednoduchý a pohodlný mechanismus pro stahování konfigurace ze souborů YAML nebo JSON. Hierarchie je možnost určit pořadí čtení více konfiguračních souborů – tzn. hierarchie/priorita těchto souborů.
  • Kromě stahování dat o volání funkcí Puppet stahuje výchozí parametry třídy, což je hlavní přednost.
  • Hiera samozřejmě podporuje interpolaci faktů a dokonce i volání speciálních funkcí.
  • V Puppet 4.3 implementovali stejnou funkcionalitu opět pro podporu nejen globální databáze, ale i lokální pro Environment a Modul, i když autor již našel několik problémů v jejich implementaci (PUP-5983, PUP-5952 a PUP-5899), které byly okamžitě opraveny společností Puppet Labs.
  • Pro extrahování hodnot ze všech souborů v hierarchii je podporováno několik strategií:
    • first - vrátí se první hodnota nalezená podle priority
    • jedinečný - shromažďuje všechny hodnoty do jednorozměrného pole a odstraňuje duplikáty
    • hash - kombinuje všechny nalezené YAML Hash. Duplicitní klíče jsou vybírány podle priority.
    • deep je v podstatě rekurzivní verze hashe
  • Krása je v tom, že strategii vzorkování lze nastavit buď voláním funkce lookup(), protože a v libovolném souboru hierarchie prostřednictvím speciálního klíče lookup_options, který se aktivně používá v modulu cfnetwork.
• PuppetDB- v podstatě vrstva obchodní logiky kolem relační databáze (PostgreSQL), která umožňuje ukládat zprávy o skutečnostech a provedených nasazeních a exportovat zdroje pro následný import do adresářů na jiných uzlech nebo výběr pomocí speciálních funkcí. Nechybí ani webové rozhraní v podobě Puppet Dashboard.
• X.509 PKI- již zmíněná infrastruktura certifikátů, kterou je mimořádně pohodlné používat pro další služby bez nutnosti správy samostatné infrastruktury.
• MCollective- zdá se užitečná věc pro spouštění úloh na serverové farmě založené na událostech, ale autor má určitou nedůvěru v bezpečnost konkrétního řešení.
• Puppet Forge- otevřená platforma pro publikování a stahování modulů.
• některé další funkce v podobě ovládacích prvků externí zařízení jako je zařízení Cisco a nasazení na holém kovu, ale to je jiný příběh

Poznámky k bezpečnosti a přístupnosti

Dostupnost Puppet Server určuje schopnost spravovat celou infrastrukturu. Má smysl hostovat loutkový server na virtuálním počítači ve spolehlivějším a rychleji obnovitelném cloudu třetí strany než vlastní schopnosti. Nebo byste měli nainstalovat několik serverů.

V žádném případě byste do systému, kde bude nasazen Puppet Server se zvonky a píšťalkami, neměli instalovat další služby. Virtualizace a kontejnerizace vám mohou pomoci.

Multi-master (několik samostatných loutkových serverů)

• V v tomto případě pouze jeden server funguje jako CA (Certificate Authority) - jeho nedostupnost znamená, že není možné přidávat nové uzly.
  • Puppet vám umožňuje používat infrastrukturu X.509 třetí strany, pokud ta vestavěná není uspokojivá.
• Celá konfigurace (prostředí) musí být uložena v systému správy verzí a nasazena na každý server současně.
• Společná je pouze databáze PostgreSQL, jejíž organizace vysoké dostupnosti je nad rámec tohoto článku.
• Modul cfpuppetserver podporuje instalace primárního (s CA) i sekundárního serveru.

Co podstatného se od starších verzí změnilo

• Všechny služby se přesunuly pod JVM, JRuby a Jetty. Navzdory zjevným výhodám integrace existují také nevýhody z hlediska spotřeby paměti.
• Byly přidány funkce lambda pro zpracování kolekcí - nyní není třeba ořezávat berličky v Ruby nebo perverzovat pomocí create_resources()
• Objevil se nástroj pro zpracování šablon EPP - v podstatě stejný ERB, ale s Puppet DSL místo Ruby,
• Výchozí adresářová struktura konfiguračních souborů se výrazně změnila
• Přidána podpora pro poskytovatele dat pro prostředí a moduly (hacky již nejsou vyžadovány).
• Zlehčování role globální Hiery. Nový a související příkaz je loutkové vyhledávání.

Instalace

Tři hlavní součásti serveru jsou samotný Puppet Server, PuppetDB a PostgreSQL. Všechny mohou být nacpané do jednoho uzlu nebo rozděleny do dvou nebo tří systémů. Puppet Server a Puppet DB lze spustit vícekrát, ale PostgeSQL je jediným bodem selhání. Existují různé přístupy k replikaci a shlukování PostgeSQL Vhodným přístupem v případě hlavního a sekundárního serveru by byl Master + Read-Only Slave, který je podporován v samotném PuppetDB jako hlavní a pouze pro čtení databázový uzel, ale automatizuje. nastavení nějakou dobu trvá, a proto ještě není k dispozici jako součást modulu cfpuppetserver.

Samotnou konfiguraci lze jednoduše uložit alespoň na souborový systém spolu s Puppet Serverem, ale je to jako psaní skriptů na produkčním webovém serveru. Nejvhodnějším řešením je git repozitář. Nástroj r10k může stáhnout všechny větve úložiště a nasadit je na Puppet Server jako samostatná prostředí. r10k je dost špatný v stahování závislostí, takže nahoře je použit librarian-puppet. Okamžitě stojí za zmínku, že hlavním kanonickým prostředím Puppet je „produkce“. Proto by úložiště konfigurace mělo používat větev nazvanou "výroba" spíše než "master".

Systémové požadavky

Konfigurace v Gitu

1. Klonování úložiště: git clone https://github.com/codingfuture/puppet-exampleenv my-puppet-conf && cd my-puppet-conf
2. Obecná nastavení pro přístup správce jsme nastavili pomocí tipů v komentářích:
   • $EDITOR data/common.yaml
3. Vytvořme konfiguraci uzlu:
   • $MY_DOMAIN – kořenový adresář název domény(např. example.org)
   • $HOST_NAME - název hostitele klienta bez domény
   • mkdir data/$MY_DOMAIN
   • cp data/example.com/puppet.yaml data/$(MY_DOMAIN)/puppet.yaml
   • $EDITOR nano -w data/$(MY_DOMAIN)/puppet.yaml - nastavení uzlu s Puppet Server podle návrhů v komentářích
   • cp data/example.com/host.yaml data/$(MY_DOMAIN)/$(HOST_NAME).yaml
   • $EDITOR nano -w data/$(MY_DOMAIN)/$(HOST_NAME).yaml – nastavení libovolného uzlu na základě návrhů v komentářích
4. Publikujeme na náš vlastní Git server nebo jej zpřístupníme lokálně na uzlu s Puppet Serverem přes rsync nebo scp. Místní úložiště je vhodné jako mezikrok, dokud není server Git nasazen ze samotného Puppet. V jistém smyslu to připomíná sestavení kompilátoru v několika fázích.

Instalace od začátku na čistý systém

V cílovém systému:

1. Stáhněte si instalační skript: wget https://raw.githubusercontent.com/codingfuture/puppet-cfpuppetserver/master/setup_puppetserver.sh
2. Prohlížíme si skript a mračíme se: méně setup_puppetserver.sh
3. Spusťte: bash setup_puppetserver.sh loutka.$(MOJE_DOMÉNA) .
   • Příklad se vzdáleným úložištěm: bash setup_puppetserver.sh ssh:// [e-mail chráněný]/puppet-conf
   • Příklad s local: bash setup_puppetserver.sh file:///root/puppetconf/
4. Vidíme, jak se systém nafukuje a nenainstaluje vše velmi rychle.
5. Pokud je úložiště vzdálené:
   • Vytvořte klíč SSH pro root: ssh-keygen -t rsa -b 2048
   • Registrujeme veřejný klíč /root/.ssh/id_rsa.pub na vzdáleném serveru Git...
   • ... a tam jsme nastavili hák Git voláním následujícího příkazu: /usr/bin/ssh -T deploypuppet@puppet.$(MY_DOMAIN) ./puppetdeploy.sh
6. Začneme nasazovat konfiguraci ručně: /etc/puppetlabs/deploy.sh
7. Vyzkoušíme, jak to funguje na samotném serveru: /opt/puppetlabs/bin/puppet agent --test
8. Zkontrolujte síť, síťový filtr a nastavení přístupu SSH

Přidávání spravovaných uzlů

1. Plně kvalifikovaný název loutkového serveru musí být dostupný prostřednictvím DNS na spravovaném hostiteli nebo pevně zakódován do /etc/hosts.
   • Příklad: echo "128.1.1.1 puppet.example.com" >> /etc/hosts
2. V uzlu s Puppet Server spusťte následující skript /root/genclientinit.sh $(HOST_NAME).$(MY_DOMAIN) .
3. Zkopírujte celý výsledek a vložte jej do příkazového řádku v cílovém systému.
4. Počkáme na konec provádění a spustíme /opt/puppetlabs/bin/puppet agent --test . Při prvním spuštění se vygeneruje žádost o podpis certifikátu.
5. Jdeme do uzlu Puppet Server a podepíšeme certifikát.
   • loutkový cert list - kontrolujeme podpis certifikátu na extra paranoiu.
   • loutkový certifikační znak $(HOST_NAME).$(MY_DOMAIN) - ve skutečnosti podepisujeme certifikát.
6. Vrátíme se do spravovaného uzlu a znovu spustíme: /opt/puppetlabs/bin/puppet agent --test`. To vynutí zahájení postupu nasazení.
7. Čekáme na dokončení nasazení přes Puppet Agent.
8. To je vše, máte připravenou minimální infrastrukturu Puppet!

Příklad výstupu z /root/genclientinit.sh

bash</etc/cflocation fi if test! -z ""; potom echo -n >/etc/cflocationpool fi if test ! -z "\$http_proxy"; pak export http_proxy export https_proxy="\$http_proxy" export HTTP_PROXY="\$http_proxy" export HTTPS_PROXY="\$http_proxy" fi echo host.example.com > /etc/hostname hostname host.example.com if ! které lsb-release | číst; potom apt-get install lsb-release fi codename=\$(lsb_release -cs) if test -z "\$codename"; pak echo "Nepodařilo se detekovat správné kódové jméno" exit 1 fi wget https://apt.puppetlabs.com/puppetlabs-release-pc1-\$(kódové jméno).deb dpkg -i puppetlabs-release-pc1-\$(kódové jméno) .deb mkdir -p /etc/puppetlabs/puppet cat > /etc/puppetlabs/puppet/puppet.conf<loutkový certifikační znak host.example.com" echo "K zastavení cyklu použijte CTRL+C, pokud selže z různých důvodů" spánek 5 hotovo EOT

Popis modulu

Kompletní seznam parametrů Bash pro skript počáteční instalace