Instalace a konfigurace loutkového serveru. Centralizovaná konfigurace UNIX s jazykem popisu stavu loutky

Sergej Jaremčuk

Centralizovaná konfigurace UNIX s Puppet

Správa velkého počtu systémů UNIX není pohodlná. Pro změnu jednoho parametru musí administrátor kontaktovat každý stroj, skripty mohou pomoci jen částečně a ne ve všech situacích.

Je pravda, že správci sítě Windows jsou na tom lépe. Stačí změnit nastavení skupinové zásady, a po chvíli se o novince „dozvědí“ všechny počítače v síti, včetně těch s nedávno nainstalovaným operačním systémem, pokud se jich samozřejmě týkají. Když se podíváte zpět na dlouhou historii UNIXu, můžete vidět, že nic takového se neuchytilo. Existují řešení jako kickstart, která vám pomohou s počáteční instalací. operační systém, ale další vylepšení bude vyžadovat značné úsilí. Komerční řešení, jako je BladeLogic a OpsWare, řeší problém automatizace nastavení jen částečně, jejich hlavní výhodou je přítomnost grafické rozhraní a pouze velké organizace si je mohou dovolit koupit. Existují samozřejmě projekty, které nabízejí řešení zdarma, ale za celou dobu své existence nedokázaly vytvořit velkou komunitu. Například Cfengine není u administrátorů příliš oblíbený, i když kromě Linuxu jej lze použít v * BSD, Windows a Mac OS X. Možná je to způsobeno relativní složitostí vytváření konfigurací. Při popisu úloh musíte vzít v úvahu zvláštnosti každého konkrétního systému a manuálně řídit sled akcí při provádění příkazů. To znamená, že administrátor si musí pamatovat, že pro některé systémy byste měli napsat adduser pro jiné - useradd, vzít v úvahu umístění souborů v různé systémy atd. To řádově komplikuje proces zápisu příkazů, je velmi obtížné vytvořit správnou konfiguraci za běhu a po chvíli je téměř nemožné vytvořené konfigurace přečíst. I přes licenci Cfengine GPL jde vlastně o projekt jednoho člověka, který dohlíží na všechny změny a o budování otevřené společnosti se moc nezajímá. Ve výsledku jsou možnosti Cfengine pro vývojáře celkem uspokojivé, ale pro zbytek administrátorů je to spíše zbytečná bolest hlavy. Pro vylepšení Cfengine byly vývojáři třetích stran vytvořeny různé doplňky, které často věci zhoršovaly. Autor několika takových modulů pro Cfengine, Luke Kanies, se rozhodl vyvinout podobný nástroj, ale bez mnoha nedostatků Cfengine.

Vlastnosti loutky

Puppet, stejně jako Cfengine, je systém klient-server, který používá deklarativní, tedy povinný jazyk pro popis úkolů a knihovnu pro jejich implementaci. Klienti se pravidelně (ve výchozím nastavení každých 30 minut) připojují k centrálnímu serveru a obdrží nejnovější konfiguraci. Pokud přijatá nastavení neodpovídají stavu systému, budou provedena, v případě potřeby je na server odeslána zpráva o provedených operacích. Server zpráv může uložit do syslogu nebo souboru, vytvořit graf RRD a odeslat jej na zadaný e-mail. Další vrstvy abstrakce Transakční a Resource poskytují maximální kompatibilitu se stávajícími nastaveními a aplikacemi, což vám umožňuje soustředit se na systémové objekty bez obav z rozdílů v implementaci a popisu podrobných příkazů a formátů souborů. Správce operuje pouze s typem objektu, o zbytek se postará Puppet. Typ balíčků tedy zná asi 17 balíčkových systémů, požadovaný bude automaticky rozpoznán na základě informace o verzi distribučního kitu nebo systému, i když v případě potřeby lze správce balíčků nastavit násilně.

Na rozdíl od skriptů, které je často nemožné použít na jiných systémech, budou konfigurace loutek napsané správci třetích stran fungovat bez problémů v jakékoli jiné síti. Kuchařka loutek má již tři desítky hotových receptů. Puppet v současné době oficiálně podporuje následující operační systémy a služby: Debian, RedHat / Fedora, Solaris, SUSE, CentOS, Mac OS X, OpenBSD, Gentoo a MySQL, LDAP.

Jazyk loutky

Chcete-li jít dále, musíte nejprve pochopit základní prvky a možnosti jazyka. Jazyk je jedním z silné stránky Loutka. Popisuje zdroje, které správce plánuje spravovat, a akce. Na rozdíl od většiny podobných řešení vám v Puppet jazyk umožňuje zjednodušit přístup ke všem podobným zdrojům na jakémkoli systému v heterogenním prostředí. Popis zdroje se obvykle skládá z názvu, typu a atributů. Ukažme například na soubor / etc / passwd a nastavte jeho atributy:

soubor ("/ etc / passwd":

Vlastník => root,

Skupina => kořen,

Režim => 644,

Klienti se nyní připojí k serveru, zkopírují soubor / etc / passwd a nastaví zadané atributy. V jednom pravidle lze definovat více zdrojů tak, že je oddělíte středníky. Ale co když se konfigurační soubor použitý na serveru liší od souboru klienta nebo se nepoužívá vůbec? Tato situace může nastat například při konfiguraci připojení VPN. V tomto případě byste měli ukázat na soubor pomocí zdrojové direktivy. Zde jsou dvě možnosti, můžete jako obvykle zadat cestu k jinému souboru a také pomocí dvou podporovaných protokolů URI: file a puppet. V prvním případě se používá odkaz na externí NFS server, ve druhé možnosti je spuštěna služba podobná NFS na serveru Puppet, která exportuje zdroje. V druhém případě je ve výchozím nastavení cesta relativní ke kořenovému adresáři loutky - / etc / puppet. To znamená, že odkaz loutka: //server.domain.com/config/sshd_config bude odpovídat souboru / etc / puppet / config / sshd_config. Tento adresář můžete přepsat pomocí direktivy filebucket, i když správnější je použít stejnojmennou sekci v souboru /etc/puppet/fileserver.conf. V tomto případě je možné omezit přístup ke službě pouze na určité adresy. Pojďme si například popsat konfigurační sekci:

Cesta / var / loutka / config

Povolit * .domain.com

Povolit 127.0.0.1

Povolit 192.168.0. *

Povolit 192.168.1.0/24

Odepřít * .wireless.domain.com

A pak při popisu zdroje odkazujeme na tuto část:

source => "loutka: //server.domain.com/config/sshd_config"

Název zdroje se objeví před dvojtečkou. V nejjednodušších případech můžete jednoduše zadat jako název celá cesta do souboru. Ve složitějších konfiguracích je lepší použít alias nebo proměnné. Alias ​​se nastavuje pomocí direktivy alias:

soubor ("/ etc / passwd":

Alias ​​​​=> passwd

Další možnost vytvoření aliasu se dobře hodí, když se musíte vypořádat s různými operačními systémy. Vytvořme například prostředek popisující soubor sshd_config:

soubor (sshdconfig:

Jméno => $ operační systém? (

Solaris => "/ usr / local / etc / ssh / sshd_config",

Výchozí => "/ etc / ssh / sshd_config"

V tomto příkladu stojíme před volbou. Soubor pro Solaris je specifikován samostatně, pro všechny ostatní bude vybrán soubor / etc / ssh / sshd_config. Nyní lze k tomuto prostředku přistupovat jako sshdconfig, v závislosti na operačním systému bude vybrána správná cesta. Uveďme například, že pokud je spuštěn a přijat démon sshd nový soubor, služba by měla být restartována:

služba (sshd:

Ujistěte se, že => pravda,

Odebírat => Soubor

Proměnné se často používají při práci s uživatelskými daty. Popíšeme například umístění domovských adresářů uživatele:

$ homeroot = "/ home"

Nyní lze k souborům konkrétního uživatele přistupovat jako:

$ (homeroot) / $ jméno

Parametr $ name bude vyplněn jménem uživatelského účtu. V některých případech je vhodné definovat výchozí hodnotu pro určitý typ. Například pro typ exec jsou často specifikovány adresáře, ve kterých by měl hledat spustitelný soubor:

Exec (cesta => "/ usr / bin: / bin: / usr / sbin: / sbin")

V případě, že potřebujete ukázat na více připojených souborů a adresářů, můžete použít parametr recurse:

soubor ("/etc/apache2/conf.d":

Zdroj => "loutka: // loutka: //server.domain.com/config/apache/conf.d",

Rekurze => "pravda"

Několik zdrojů lze kombinovat do tříd nebo definic. Třídy jsou úplnými popisy systému nebo služby a používají se samostatně:

třída linux (

Soubor (

"/ etc / passwd": vlastník => root, skupina => root, režim => 644;

"/ etc / shadow": vlastník => root, skupina => root, režim => 440

Stejně jako u objektově orientovaných jazyků lze třídy přepsat. Například na FreeBSD je skupina, která vlastní tyto soubory, wheel. Proto, aby nedošlo k úplnému přepsání zdroje, vytvoříme novou třídu freebsd, která bude dědit od třídy linux:

třída freebsd zdědí linux (

Soubor ["/ etc / passwd"] (skupina => kolo);

Soubor ["/ etc / shadow"] (skupina => kolo)

Pro větší pohodlí lze všechny třídy přesunout samostatný soubor, který musí být součástí směrnice include. Definice mohou mít více parametrů jako argumenty, ale nepodporují dědičnost a používají se, když potřebujete popsat opakovaně použitelné objekty. Definujme například domovský adresář uživatele a příkazy potřebné k vytvoření nového účtu:

define user_homedir ($ group, $ fullname, $ ingroups) (

Uživatel ("$ name":

Zajistit => přítomen,

Komentář => "$ celé jméno",

Gid => "$ skupina",

Skupiny => $ ingroups,

Členství => minimum,

Shell => "/ bin / bash",

Home => "/ home / $ name",

Vyžadovat => Skupina [$ skupina],

Exec ("$ name homedir":

Příkaz => "/ bin / cp -R / etc / skel / home / $ name; / bin / chown -R $ name: $ group / home / $ name",

Vytvoří => "/ home / $ name",

Vyžadovat => Uživatel [$ name],

Nyní k vytvoření nového účet, stačí se podívat na user_homedir:

user_homedir ("sergej":

Skupina => "sergej",

Celé jméno => "Sergej Jaremchuk",

Ingroups => ["media", "admin]

Existují samostatné popisy uzlů (uzlů), které podporují dědičnost, jako jsou třídy. Když se klient připojí k serveru Puppet, vyhledá odpovídající sekci uzlu a zobrazí nastavení specifická pouze pro tento počítač. K popisu všech ostatních systémů můžete použít výchozí uzel. Popis všech typů je uveden v dokumentu "Type Reference", se kterým se musíte v každém případě seznámit, alespoň abyste porozuměli všem vlastnostem jazyka Puppet. odlišné typy umožňují spouštět určené příkazy, včetně případů, kdy jsou splněny určité podmínky (například změna konfiguračního souboru), práce s cron, pověřeními a skupinami uživatelů, počítači, připojováním zdrojů, spouštěním a zastavováním služeb, instalací, aktualizací a odebíráním balíčků, práce s klíči SSH, zónami Solaris a tak dále. Takto snadné je vynutit aktualizaci seznamu balíčků v distribucích pomocí apt každý den mezi 2 a 4 hodinou ranní.

rozvrh (denně:

Období => denně,

Rozsah =>

exec ("/ usr / bin / apt-get update":

Rozvrh => denně

Během této doby se každý systém aktualizuje pouze jednou, poté je úloha považována za dokončenou a bude smazána z klientského počítače. Jazyk loutek podporuje další známé struktury: podmínky, funkce, pole, komentáře a podobně.

Instalace loutky

Puppet vyžaduje Ruby (od verze 1.8.1 a vyšší) s podporou OpenSSL a knihovnami XMLRPC a také knihovnu Faster. Úložiště Ubuntu 7.04 použité v testovací instalaci již obsahuje balíček pro štěně:

$ sudo vyhledávací loutka apt-cache

~ $ ruby ​​​​-rxmlrpc / client -e "ukládá: ano"

ano

Pokud se neobjeví žádné chyby, vše, co potřebujete, je již zahrnuto. Soubory, které popisují požadovanou konfiguraci systému, se v terminologii Puppet nazývají manifesty. Při spuštění se démon pokouší přečíst soubor /etc/puppet/manifests/site.pp, pokud chybí, vydá varovnou zprávu. Při testování můžete dát démonovi pokyn, aby pracoval offline, ve kterém se manifest nevyžaduje:

$ sudo / usr / bin / puppetmasterd --nonodes

V případě potřeby můžete k site.pp připojit další soubory, například s popisy tříd. Pro zkušební provoz můžete do tohoto souboru zadat nejjednodušší pokyn.

třída sudo (

Soubor ("/ etc / sudoers":

Vlastník => root,

Skupina => kořen,

Režim => 440,

výchozí uzel (

Zahrnout sudo

Všechny konfigurační soubory, server i klient, jsou umístěny v / etc / puppet. Soubor fileserver.conf, o kterém jsme již hovořili, je volitelný a používá se pouze v případě, že Puppet bude fungovat také jako souborový server. Na Ubuntu tento soubor exportuje podadresář / etc / puppet / files. Podadresář ssl obsahuje certifikáty a klíče, které budou použity pro šifrování během připojení klientů. Klíče se vytvoří automaticky při prvním spuštění puppetmasterd, můžete je vytvořit ručně pomocí příkazu:

$ sudo / usr / bin / puppetmasterd --mkusers

Soubory puppetd.conf a puppetmasterd.conf jsou podobné. Určují některé parametry provozu démonů na klientském systému a serveru. Soubor klienta se liší pouze přítomností parametru serveru, který ukazuje na počítač, na kterém běží puppetmasterd:

server = grinder.com

logdir = / var / log / loutka

vardir = / var / lib / loutka

rundir = / var / spustit

# odeslat zprávu na server

zpráva = pravda

Abyste nemuseli psát vše ručně, můžete vytvořit šablonu pomocí samotného puppetd:

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

Podobně můžete vytvořit site.pp na serveru:

$ puppetd --genmanifest> /etc/puppet/manifests/site.pp

Další soubor, tagmail.conf, vám umožňuje určit e-mailové adresy, na které se budou zprávy zasílat. V nejjednodušším případě můžete použít jeden řádek:

Všechno: [e-mail chráněný]

Není dostatek konfiguračních souborů, aby se klient mohl připojit k serveru. Chcete-li to provést, musíte také podepsat certifikáty.

Nejprve, aby se server dozvěděl o novém počítači, zadejte v klientském systému příkaz:

$ sudo puppetd --server grinder.com --waitforcert 60 –test

Firewall musí umožňovat připojení na portu 8140.

Na serveru získáme seznam certifikátů, které je třeba podepsat:

$ sudo puppetca –list

nomad.grinder.com

A podepíšeme klientský certifikát:

$ sudo puppetca –sign nomad.grinder.com

Nyní se klient může volně připojit k serveru a přijímat nastavení.

Bohužel je nemožné ukázat všechny vlastnosti Puppet v mezích článku. Ale jak vidíte, jedná se o funkční a flexibilní nástroj, který vám umožní vyřešit většinu úkolů souběžné správy. velký počet systémy. A co je nejdůležitější, projektu se podařilo shromáždit malou, ale neustále rostoucí komunitu. Doufejme tedy, že dobrý nápad nenechá zemřít nebo odplout.

Hodně štěstí!

  1. Stránka projektu BladeLogic je http://www.bladelogic.com.
  2. Stránka projektu OpsWare je http://www.opsware.com.
  3. Webová stránka projektu Cfengine je http://www.cfengine.org.
  4. Stránka projektu Puppet je http://reductivelabs.com/projects/puppet.
  5. Kuchařka loutek - http://www.reductivelabs.com/trac/puppet/tagspuppet%2Crecipe.
  6. Knihovna rychleji -

Když je počet serverů, které spravujete, menší než deset – zřídkakdy někdo přemýšlí o jejich centralizované správě, nemusí to být nutné. Pokud existují desítky serverů, centralizovaná správa softwaru a konfigurací je mimořádně 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 ... Toto je poslední, o kterém bude řeč v tomto příspěvku.

Loutka je právem považována za jednu z lepší ř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:

  • Loutkový Open Source - Kompletně bezplatná verze
  • Puppet Enterprise - zdarma v konfiguraci až 10 serverů, dále vyžaduje zakoupení licencí

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

Zadní konec Puppet se nazývá loutkař, spustíme instalaci z něj:

: ~ # apt-get install puppetmaster

A nyní klient:

: ~ # apt-get install loutka

V konfiguračním souboru klienta /etc/puppet/puppet.conf je nutné říci o serveru přidáním následující části:

Server = puppet.local report = true pluginsync = false

Je lepší vypnout pluginsync v počáteční fázi.

Spusťte loutkového klienta pro vytvoření žádosti o certifikát:

: ~ # puppetd --verbose --test info: Vytvoření nového klíče SSL pro info linux.local: Uložení certifikátu do mezipaměti pro info ca: Vytvoření nového požadavku na certifikát SSL pro info linux.local: Otisk žádosti o certifikát (md5): E5: EA: AC: 5B: 22: 9A: BA: 42: B8: A1: 63: 9E: 1F: 1F: 23: 51 Výstup; nebyl nalezen žádný certifikát a waitforcert je zakázán

Na serveru je třeba zkontrolovat, zda byla žádost o certifikát přijata, a pokud ano, certifikát zapsat:

: ~ # puppetca --list "linux.local" (E5: EA: AC: 5B: 22: 9A: BA: 42: B8: A1: 63: 9E: 1F: 1F: 23: 51): ~ # puppetca - -sign linux.local upozornění: Podepsaný požadavek na certifikát pro linux.local upozornění: Odebírání souboru Puppet :: SSL :: CertificateRequest linux.local na "/var/lib/puppet/ssl/ca/requests/linux.local.pem"

Opakujeme předchozí krok na klientovi:

: ~ # puppetd --verbose --test info: Ukládání certifikátu do mezipaměti pro linux.local info: Načítání informací o pluginu: Ukládání seznamu certifikátů_zrušení pro ca info: Ukládání katalogu pro linux.local info: Použití konfigurační verze "1356278451" info: Vytváření stavového souboru / var / lib / puppet / state / state.yaml upozornění: Dokončený běh katalogu za 0,02 sekund

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

Pojďme se podívat, kde loutka hledá moduly:

: ~ # puppet apply --configprint modulepath / etc / puppet / modules: / usr / share / puppet / modules

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

: ~ # cd / etc / loutka / moduly: ~ # mkdir hosts; cd hostitelé; mkdir se projevuje; cd manifesty

Je třeba zavolat první manifest, také známý jako soubor hlavního modulu init.pp

Hostitelé třídy (# puppet.local hostitel ("puppet.local": zajistit => "prezentovat", target => "/ etc / hosts", ip => "192.168.0.1", host_aliases => "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řevedeme do následující podoby:

Výchozí uzel (zahrnout hostitele)

Kontrola manifestu na serveru:

: ~ # puppet apply --verbose /etc/puppet/manifests/site.pp info: Aplikování konfigurační verze "1356281036" upozornění: / Stage // Host / zajistit: vytvořeno info: FileBucket přidání (md5) upozornění: / Stage // Host / zajistit: vytvořeno upozornění: Dokončený běh katalogu za 0,03 sekundy

Na klientovi:

: ~ # ll / etc / hosts rw-r - r-- 1 root root 290 Dec 16 19:10 / etc / hosts: ~ # puppetd --verbose --test info: Ukládání katalogu pro linux.local info: Používání konfigurace informace o verzi "1356283380": Oznámení o přidání souboru FileBucket (md5): / Stage / Hosts / Host / Zajištění: vytvořeno oznámení: / Stage / Hosts / Host / Zajištění: vytvořeno oznámení: Dokončený katalog běží za 0,04 sekund: ~ # ll / etc / hostitelé -rw-r - r-- 1 root root 551 23. prosince 20:43 / etc / hosts

Poté, co jsme se ujistili, že vše funguje, povolíme spuštění služby, v / etc / default / loutka změna:

# Spustit loutku na botě? START = ano

Spouštíme službu

: ~ # spuštění loutky služby

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


Trochu textů. Zdálo by se, že celý cyklus by měl začít tímto článkem, ale přesto jsou cílovou skupinou zkušenější uživatelé produktů Open Source Puppet Labs, kteří se nespokojí s jednotlivými málo integrovanými moduly s Puppet Forge. Jako u každého případu „knihovna vs. framework“ se návratnost řídí světonázorem autora integrovaného řešení.

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

Puppet je především specifický jazyk pro deklarativní definování konečného stavu systému. Pro srovnání se mimořádně hodí GNU Makefile, kde se dá kromě přímého popisu závislostí do sytosti cheatovat.

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

  • Uzel je kolekce 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 uzlů nebo jiných tříd. Třída nemá žádné instance ani metody, ale má parametry a proměnné definované uvnitř logiky. Ve skutečnosti jde spíše o proceduru, která může zdědit další proceduru s triviálním sestavováním kódu a ne zcela triviálním rozsahem proměnných.
  • Typ (typ)- ale tohle už vypadá spíš jako klasická třída - má mít instance s názvem a určitě danými parametry, ale nic víc. Konkrétní implementaci typu lze napsat jako Puppet script přes define, který vytváří instance jiných typů, nebo jako Ruby extension s letem fantazie.
  • Zdroj- ve skutečnosti se jedná o pojmenované instance typů. Název každého prostředku je jedinečný v rámci specifického typu v rámci konfigurace uzlu (adresáře).
  • Proměnné- no, zkrátka, to jsou konstanty... Před Puppet 4 byly jejich záběry ještě horší. Nyní je to dostačující: pro použití mimo místo definice musí být specifikován plně kvalifikovaný identifikátor, s výjimkou případu dědičnosti třídy.
Puppet lze použít pro místní nasazení bez sítě a související infrastruktury. To lze použít k vytvoření obrázků kontejnerů. Existuje dokonce celá řada zastánců opuštění centralizovaného serveru.

V ideologicky správném duchu se infrastruktura Puppet skládá z agenta - privilegované služby na cílovém systému a serveru, který na žádost agentů vydává 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í takto:

  1. Zpracování TLS a X.509 (navázání připojení, 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 vytahuje vše z lib / složek 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 zkontrolovat ručně prostřednictvím výzvy loutkových faktů. Tyto skutečnosti jsou dostupné jako globální proměnné.
  4. Server zkompiluje zdrojový adresář 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řevede systém do zadané podoby. Agent sám přitom neví, jak se zdroji zacházet, spoléhá na implementaci poskytovatele "s (sémantický překlad bude" překladatel ", nikoli poskytovatel) konkrétních typů zdrojů. Někteří poskytovatelé jsou standardní a jsou součástí balíčků Puppet a zbytek je stažen z modulů.
Abyste si užili všechny lahůdky, jsou zde další buchty v podobě:
  • Modul- sbírka deklarativních skriptů Puppet, rozšíření Ruby pro Puppet, soubory, šablony souborů, data Hiera a další. Správnější výraz by byl „balíček“.
  • životní prostředí- sbírka skriptů, modulů a dat Hiera. Vzhledem ke složitosti infrastruktury bylo nevyhnutelně nutné rozdělit konfiguraci dále, než je standardní rozdělení na uzly. V zásadě je to vyžadováno pro pilotní inovace a banální řízení přístupu (kdy nemají všichni správci přístup ke všem uzlům IT infrastruktury).
  • Hiera- hierarchická databáze. Tato formulace může být velmi děsivá. 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 spočívá v možnosti určit pořadí, ve kterém se načítá více konfiguračních souborů – tzn. hierarchii / prioritu těchto souborů.
    • Kromě stahování dat voláním funkce stahuje Puppet 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í.
    • Puppet 4.3 opět implementoval stejnou funkcionalitu pro podporu nejen globální databáze, ale také 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 získávání hodnot ze všech souborů v hierarchii je podporováno několik strategií:
      • first - je vrácena první hodnota, která má prioritu
      • jedinečný - shromažďuje všechny hodnoty do jednorozměrného pole a odstraňuje duplikáty
      • hash – zřetězí všechny nalezené YAML hash. Duplicitní klíče jsou vybírány podle priority.
      • deep - v podstatě rekurzivní varianta hashe
    • Krása je v tom, že strategii načítání lze specifikovat jako při volání funkce vyhledávání () od 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- ve skutečnosti vrstva obchodní logiky kolem relační databáze (PostgreSQL), která umožňuje ukládat zprávy o faktech 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ý náhubek v podobě Puppet Dashboard.
  • X.509 PKI- již zmíněná infrastruktura certifikátů, kterou je mimořádně vhodné využít pro další služby bez nutnosti správy samostatné infrastruktury.
  • MCollective- zdánlivě užitečná věc pro spouštění úloh řízených událostmi na serverové farmě, ale autor má určitou nedůvěru v bezpečnost konkrétního řešení.
  • Loutková kovárna- otevřená oblast pro publikování a stahování modulů.
  • některé další funkce v podobě ovládání externích 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

Je nutné pochopit, že loutkový server se stává zranitelnost celou IT infrastrukturu, protože určuje konečnou konfiguraci všech systémů. Ve zvláštních případech má smysl udělat oddělení - samostatný server pro prvky kritické infrastruktury s extrémně omezený přístup a ruční aktualizace a druhý za všechno ostatní.

Dostupnost Puppet Server určuje schopnost spravovat celou infrastrukturu. Má smysl hostovat Puppet Server na virtuálním počítači ve spolehlivějším a rychleji obnovitelném cloudu třetí strany, než jsou vaše vlastní možnosti. Případně by mělo být nainstalováno více serverů.

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

Multi-master (více samostatných loutkových serverů)

  • PROTI v tomto případě pouze jeden server funguje jako CA (Certificate Authority) - jeho nepřístupnost znamená, že není možné přidávat nové uzly.
    • Puppet umožňuje použití rámců X.509 třetích stran, pokud vestavěný nefunguje.
  • Veškerá konfigurace (prostředí) musí být udržována pod kontrolou zdroje a nasazena na každém serveru ve stejnou dobu.
  • Společná je pouze databáze PostgreSQL, jejíž organizace vysoké dostupnosti je nad rámec tohoto článku.
  • Modul cfpuppetserver podporuje primární (s CA) i sekundární instalace serveru.

Jaká významná změna oproti starším verzím

Výrobce má úplný popis.
  • Všechny služby se přesunuly pod JVM, JRuby a Jetty. Za zjevnými výhodami integrace se skrývají i 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 kroutit se create_resources ()
  • Objevil se nástroj pro vytváření šablon EPP – v podstatě stejný ERB, ale s Puppet DSL namísto Ruby,
  • Výchozí struktura adresářů konfiguračního souboru se hodně změnila
  • Přidána podpora pro poskytovatele dat pro prostředí a moduly (žádné další hacky).
  • Snižování role globální Hiery. Nové vyhledávání souvisejících příkazových loutek.

Instalace

Tento proces je poměrně primitivní, ale vyžaduje dodržení určité posloupnosti kroků. Vzhledem k tomu, že dělat to ručně je nevděčný úkol, autor vás naučí špatnou věc, totiž stahování nesrozumitelných skriptů z internetu a spouštění jako root na vašem systému.

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 mnohokrát, ale PostgeSQL je jediný uzel selhání. Existují různé přístupy k replikaci a shlukování PostgeSQL. Pohodlný přístup v případě primárních a sekundárních serverů by byl Master + Read-Only Slave, který je podporován v samotném PuppetDB jako primární a pouze pro čtení databázový uzel, ale automatizace tohoto nastavení vyžaduje čas, a proto ještě není k dispozici. je 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 repository. Nástroj r10k je schopen 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. Hned je třeba poznamenat, že hlavním kanonickým Puppet Environment je „produkce“. Proto byste v konfiguračním úložišti měli používat větev s názvem „výroba“, nikoli „master“.

Požadavky na systém

Hardware popisuje sám výrobce. Modul cfpuppetserver aktuálně podporuje pouze Debian Jessie + a Ubuntu Trusty +.

Konfigurace v Gitu

U samotného r10k na umístění úložiště až tak nezáleží – hlavní je jeho dostupnost. Například pro účely testování může být úložiště hostováno na stejném systému se souborem: // access. Dobrým začátkem je příklad konfigurace codingfuture / puppet-exampleenv.
  1. Naklonujte úložiště: git clone https://github.com/codingfuture/puppet-exampleenv my-puppet-conf && cd my-puppet-conf
  2. Nainstalujte Obecné nastavení přístup správce pomocí tipů v komentářích:
    • $ EDITOR data / common.yaml
  3. Vytvořme konfiguraci uzlu:
    • $ MY_DOMAIN – název kořenové domény (například example.org)
    • $ HOST_NAME – název hostitele klienta bez domény
    • mkdir data / $ MY_DOMAIN
    • cp data / example.com / data puppet.yaml / $ (MY_DOMAIN) /puppet.yaml
    • $ EDITOR nano -w data / $ (MY_DOMAIN) /puppet.yaml - konfigurace uzlu s Puppet Server podle pokynů v komentářích
    • cp data / example.com / data host.yaml / $ (MY_DOMAIN) / $ (HOST_NAME) .yaml
    • $ EDITOR nano -w data / $ (MY_DOMAIN) / $ (HOST_NAME) .yaml - nastavení libovolného uzlu podle tipů v komentářích
  4. Publikujeme na náš vlastní Git server nebo jej zpřístupníme lokálně na uzlu pomocí Puppet Server 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 je to podobné jako sestavení kompilátoru v několika fázích.

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

Modul cfpuppetserver umožňuje nainstalovat vše pomocí samotného Puppet, ale pro počáteční instalaci jsou základní operace duplikovány skriptem Bash.

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 na okraj: méně setup_puppetserver.sh
  3. Spusťte: bash setup_puppetserver.sh loutka. $ (MY_DOMAIN).
    • Příklad se vzdáleným úložištěm: bash setup_puppetserver.sh ssh: // [e-mail chráněný]/ loutka-konf
    • Místní příklad: soubor bash setup_puppetserver.sh: /// root / puppetconf /
  4. Podíváme se, jak se systém nadýmá a nenainstaluje vše moc rychle.
  5. Pokud vzdálené úložiště:
    • tvoříme SSH klíč v kořenovém adresáři "a: ssh-keygen -t rsa -b 2048
    • Registrujeme veřejný klíč /root/.ssh/id_rsa.pub na vzdáleném serveru Git ...
    • ... a nastavte tam háček Git pomocí následujícího příkazu: / usr / bin / ssh -T [e-mail chráněný]$ (MY_DOMAIN) ./puppetdeploy.sh
  6. Nasazení konfigurace spustíme ručně: /etc/puppetlabs/deploy.sh
  7. Vyzkoušejte, jak to funguje na samotném serveru: / opt / puppetlabs / bin / puppet agent --test
  8. Zkontrolujte nastavení sítě, linkový filtr a SSH přístup

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

  1. Úplný název loutkového serveru musí být dostupný prostřednictvím DNS na spravovaném hostiteli nebo musí být pevně zakódován do / etc / hosts.
    • Příklad: echo "128.1.1.1 puppet.example.com" >> / etc / hosts
  2. V uzlu 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ý řádek na cílovém systému.
  4. Čekáme na dokončení provedení a spusťte / opt / puppetlabs / bin / puppet agent --test. Při prvním spuštění se vygeneruje žádost o podpis certifikátu.
  5. Přejděte do uzlu Puppet Server a podepište certifikát.
    • loutkový cert list - zkontrolujte podpis certifikátu pro přidanou paranoiu.
    • loutkový certifikační znak $ (HOST_NAME) $ (MY_DOMAIN) - ve skutečnosti certifikát podepisujeme.
  6. Vrátíme se do spravovaného uzlu a znovu spustíme: / opt / puppetlabs / bin / puppet agent --test`. To vynutí postup nasazení.
  7. Čekáme na dokončení nasazení prostřednictvím Puppet Agenta.
  8. To je vše, máte připravenou minimální infrastrukturu Puppet!

Ukázkový výstup /root/genclientinit.sh

bash</ etc / cflocation fi if test! -z ""; pak 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 / název hostitele hostname host.example.com if! které lsb-release | číst; potom apt-get install lsb-release fi kódové jméno = \ $ (lsb_release -cs) if test -z "\ $ kódové jméno"; 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" Použijte CTRL + C k zastavení cyklu, pokud selže z různých důvodů "spánek 5 hotovo EOT

Popis modulu

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

~ # ./setup_puppetserver.sh Použití: ./setup_puppetserver.sh [ [ [ [] ] ] ]
  • r10k_repo_url – URI úložiště Git
  • certname - full Doménové jméno uzel
  • cflocation - inicializace faktu cf_location
  • cflocationpool - inicializace faktu cf_location_pool
  • http_proxy - proxy server pro HTTP a HTTPS požadavky

Kompletní seznam parametrů Bash pro inicializační skript klienta Puppet

~ # /root/genclientinit.sh Použití: ./genclientinit.sh [ [ []]]
Význam parametrů je stejný jako v předchozím skriptu.

třída cfpuppetserver

  • deployuser = "deploypuppet" - uživatelské jméno pro automatické nasazení aktualizací konfigurace
  • deployuser_auth_keys = undef - seznam klíčů pro $ deployuser
  • repo_url = undef - URI úložiště (příklad: ssh: // [e-mail chráněný]/ repo nebo soubor: /// nějaké / cesta)
  • puppetserver = true - zda nainstalovat komponentu Puppet Server na tento uzel
  • puppetdb = true - zda nainstalovat komponentu PuppetDB na tento uzel
  • puppetdb_port = 8081 - port pro PuppetDB
  • setup_postgresql = true - zda nainstalovat komponentu PostgreSQL na tento uzel (pouze pokud je povolena instalace PuppetDB)
  • service_face = "any" - cfnetwork :: název zdroje iface pro příjem příchozích připojení
  • puppetserver_mem = auto - RAM pro Puppet Server v megabajtech (minimálně 192 MB)
  • puppetdb_mem = auto - RAM pro PuppetDB v megabajtech (minimálně 192 MB)
  • postgresql_mem = auto - RAM pro PostgreSQL v megabajtech (minimálně 128 MB)

cfpuppetserver :: třída puppetdb

  • postgresql_host = "localhost" - adresa databáze
  • postgresql_listen = $ postgresql_host – hodnota jde přímo do direktivy PostgreSQL listen_addresses
  • postgresql_port = 5432 - port databáze
  • postgresql_user = "puppetdb" - uživatel PuppetDB v databázi
  • postgresql_pass = "puppetdb" - heslo uživatele PuppetDB v databázi
  • postgresql_ssl = false - povolit šifrování připojení na základě certifikátů Puppet PKI

cfpuppetserver :: třída puppetserver

  • autosign = false - NEMĚLO by se používat v produkčním prostředí, s výjimkou DMZ. Existuje pouze pro automatizaci testování.
  • global_hiera_config = "cfpuppetserver / hiera.yaml" - cesta k výchozímu konfiguračnímu souboru Hiera podle kánonů Puppet (první komponenta je název modulu, zbytek je cesta pod soubory / složkou v modulu)

Můžete pomoci a převést nějaké prostředky na rozvoj webu



Chcete-li používat Puppet efektivněji, musíte pochopit, jak jsou moduly a manifesty sestavovány. Tento tutoriál vás provede tím, jak tyto komponenty Puppet fungují, nastavením zásobníku LAMP na serveru Ubuntu 14.04.

Požadavky

  • Instalace Puppet (master a agent). Více o tom -.
  • Schopnost vytvořit alespoň jeden virtuální server Ubuntu 14.04 pro obsluhu uzlu Puppet agent.

Základy loutkového kódu

Zdroje

Loutkový kód se většinou skládá ze zdrojů. Zdroj je část kódu, která popisuje stav systému a určuje změny, které potřebuje. Například:

uživatel ("mitchell":
zajistit => přítomen,
uid => "1000",
gid => "1000",
shell => "/ bin / bash",
home => "/ home / mitchell"
}

Deklarace zdroje má následující formát:

typ_zdroje ("název_zdroje"
atribut => hodnota
...
}

Chcete-li zobrazit všechny typy zdrojů loutky, zadejte příkaz:

loutkový zdroj --typy

Více o typech zdrojů se dozvíte v této příručce.

Manifesty

Manifest je orchestrační skript. Loutkové programy s příponou .pp se nazývají manifesty. Výchozí manifest Puppet je /etc/puppet/manifests/site.pp.

Třídy

Stejně jako u jakéhokoli konvenčního programovacího jazyka jsou třídy zodpovědné za organizaci a opětovné použití částí orchestrace.

Definice třídy obsahuje blok kódu, který popisuje, jak třída funguje. Jakmile definujete třídu, můžete ji použít ve svých manifestech.

Definice třídy má následující formát:

třída příklad_třída (
...
kód
...
}

Tento kód definuje třídu example_class. Kód loutky bude ve složených závorkách.

Deklarace třídy je místo, kde je ve vašem kódu volána konkrétní třída. Deklarováním třídy Puppet zpracuje její kód.

Deklarace třídy může být běžná a podle typu zdroje.

Běžná deklarace třídy je přidána do kódu pomocí klíčové slovo zahrnout.

zahrnout example_class

Při deklaraci typem zdroje je třída deklarována ve formátu zdroje:

třída ("example_class" :)

Tato deklarace vám umožňuje přidat do kódu parametry třídy, které přepíší standardní hodnoty atributů třídy. Například:

uzel "host2" (
class ("apache":) # použijte modul apache
apache :: vhost ("example.com": # definovat zdroj vhost
port => "80",
docroot => "/ var / www / html"
}
}

Moduly

Modul je skupina manifestů a dalších souborů organizovaných předdefinovaným způsobem, který usnadňuje sdílení a opětovné použití samostatných částí orchestrace. Moduly vám pomohou uspořádat kód Puppet, protože je můžete použít k rozdělení kódu do více manifestů.

Moduly loutek jsou uloženy v adresáři / etc / puppet / modules.

Psaní manifestu

Můžete si procvičit psaní manifestů, modulů a tříd Puppet na příkladu instalace zásobníku LAMP na server Ubuntu (jako výsledek).

Takže udělat orchestraci Server Ubuntu 14.04 a nainstalujte na něj zásobník LAMP, potřebujete prostředky pro tyto akce:

  • instalace balíčku apache2.
  • spuštění služby apache2.
  • instalace balíčku MySQL server, mysql-server.
  • spuštění služby mysql.
  • instalace balíčku php5
  • vytvoření testovacího skriptu PHP, info.php.
  • aktualizujte index apt před instalací každého balíčku.

Níže najdete tři příklady kódu Puppet, se kterými můžete takové nastavení zásobníku LAMP získat.

První příklad vás naučí, jak psát základní manifesty do jednoho souboru. Druhý příklad vám pomůže vytvořit a používat třídu a modul na základě dříve napsaných manifestů. Ve třetím příkladu se naučíte, jak používat předpřipravené veřejné moduly k instalaci zásobníku LAMP.

Poznámka: Pro testování je lepší použít nový virtuální server.

Příklad 1: Instalace LAMP s jediným manifestem

Manifest Puppet lze zapsat na uzel agenta a poté jej spustit pomocí příkazu puppet apply (nepotřebujete k tomu průvodce a instalaci agenta).

V této části se naučíte, jak psát manifesty, které používají tyto typy deklarací zdrojů:

  • exec: Provádění příkazů.
  • balíček: instalace balíčků.
  • služba: správa služeb.
  • soubor: správa souborů.

Vytvoření manifestu

Vytvořte nový manifest:

sudo vi /etc/puppet/manifests/lamp.pp

Přidejte do něj následující kód, abyste deklarovali požadované prostředky.

# spuštění příkazu "apt-get update"
exec ("apt-update": # zdroj exec "apt-update"
příkaz => "/ usr / bin / apt-get update" # příkaz, který spustí tento prostředek
}
# instalace balíčku apache2
balíček ("apache2":
vyžadovat => Exec ["apt-update"], # před instalací balíčku požadovat "apt-update"
zajistit => nainstalováno,
}
# spusťte službu apache2
služba ("apache2":
zajistit => běh,
}
# instalace mysql-serveru
balíček ("mysql-server":
vyžadovat => Exec ["apt-update"], # před instalací požadovat "apt-update".
zajistit => nainstalováno,
}
# spusťte službu mysql
služba ("mysql":
zajistit => běh,
}
# instalace balíčku php5
balíček ("php5":
vyžadovat => Exec ["apt-update"], # před instalací požadovat "apt-update".
zajistit => nainstalováno,
}
# spustit službu info.php
soubor ("/var/www/html/info.php":
zajistit => soubor,
obsah => "“, # phpinfo kód
vyžadovat => Balíček ["apache2"], # požadavek na balíček "apache2"
}

Použití manifestu

Chcete-li použít nový manifest, zadejte příkaz:

sudo loutka aplikovat --test

Výstupem bude objemový výsledek, který zobrazí všechny změny stavu prostředí. Pokud ve výstupu nejsou žádné chyby, měli byste být schopni otevřít svou externí IP adresu nebo název domény v prohlížeči. Na obrazovce se objeví testovací stránka PHP s informacemi o zásobníku. To znamená, že Apache a PHP fungují.

Zásobník LAMP je nyní nainstalován na serveru pomocí Puppet.

Toto je poměrně jednoduchý manifest, protože jej lze spustit na agentovi. Pokud nemáte předlohu loutek, ostatní uzly agentů nebudou moci tento manifest používat.

Hlavní server loutek kontroluje změny stavu serveru každých 30 minut.

Příklad 2: Instalace sady LAMP pomocí modulu

Nyní zkuste vytvořit jednoduchý modul založený na manifestu LAMP, který jste napsali v předchozí části.

Chcete-li vytvořit modul, vytvořte nový adresář v adresáři modulů (jeho název se musí shodovat s názvem modulu). Tento adresář by měl obsahovat adresář manifests a soubor init.pp. Soubor init.pp specifikuje třídu Puppet (její název se také musí shodovat s názvem modulu).

Vytvoření modulu

Přejděte na server Puppet master a vytvořte adresářovou strukturu pro modul:

cd / etc / loutka / moduly
sudo mkdir -p lampa / manifest

Vytvořte a otevřete soubor init.pp v editoru:

sudo vi lampa / manifesty / init.pp

Vložte třídu lampy do souboru:

lampa třídy (
}

Zkopírujte obsah manifestu ze sekce 1 a vložte jej do bloku třídy lamp. Nyní máte definici lampy třídy. Jiné manifesty budou moci používat tuto třídu jako modul.

Uložte a zavřete soubor.

Použití modulu v hlavním manifestu

Nyní můžete nastavit hlavní manifest a použít modul lampy k instalaci zásobníku LAMP na server.

Na serveru Puppet master upravte následující soubor:

sudo vi /etc/puppet/manifests/site.pp

S největší pravděpodobností na tento moment soubor je prázdný. Přidejte k tomu následující řádky:

výchozí uzel ()
uzel "lamp-1" (
}

Poznámka: Nahraďte lampu-1 názvem hostitele vašeho agenta Puppet, kam chcete zásobník nainstalovat.

Blok uzlů umožňuje zadat kód loutky, který se bude vztahovat pouze na některé uzly.

Výchozí blok se vztahuje na všechny uzly agentů, které nemají samostatný blok (nechte jej prázdné). Blok lampy 1 bude aplikován na uzel agenta lampy 1.

Do tohoto bloku, který používá modul lampy, přidejte následující řádek:

Uložte a zavřete soubor.

Uzel Puppet agent si nyní bude moci stáhnout nastavení z hlavního serveru a nainstalovat zásobník LAMP. Pokud chcete provést změny hned teď, spusťte příkaz na agentovi:

sudo loutkový agent --test

Moduly jsou nejpohodlnějším způsobem znovu použít Loutkový kód. Kromě toho vám moduly pomáhají logicky organizovat váš kód.

Příklad 3: Instalace LAMP pomocí veřejně dostupných modulů

Podobným způsobem se používá modul MySQL. Přidejte do bloku uzlů následující řádky:

třída ("mysql :: server":
root_password => "heslo",
}

Parametry můžete také předat modulu MySQL.

Přidejte zdroj, který zkopíruje info.php do správného umístění. Použijte parametr source. Přidejte do bloku uzlů následující řádky:

soubor ("info.php": # název souboru prostředku
cesta => "/var/www/html/info.php", # cílová cesta
zajistit => soubor,
vyžadovat => Třída ["apache"], # třída Apache k použití
source => "puppet: ///modules/apache/info.php", # kam chcete soubor zkopírovat
}

Tato deklarace třídy používá parametr source namísto parametru obsahu. Tato možnost nejen využívá obsah souboru, ale také jej zkopíruje.

Soubor loutky: ///modules/apache/info.php Puppet se zkopíruje do /etc/puppet/modules/apache/files/info.php.

Uložte a zavřete soubor.

Vytvořte soubor info.php.

sudo sh -c "echo""> /etc/puppet/modules/apache/files/info.php"

Uzel Puppet agent si nyní bude moci stáhnout nastavení z hlavního serveru a nainstalovat zásobník LAMP. Pokud chcete provést změny v prostředí agenta právě teď, spusťte příkaz na tomto uzlu:

sudo loutkový agent --test

Tento příkaz stáhne všechny aktualizace pro aktuální uzel a nainstaluje na něj zásobník. Chcete-li ověřit, že Apache a PHP fungují, otevřete IP adresu nebo doménu uzlu v prohlížeči:

http: //lamp_1_public_IP/info.php

Závěr

Nyní máte základní znalosti o modulech a manifestech Puppet. Zkuste si sami vytvořit jednoduchý manifest a modul.

Puppet je skvělý pro správu konfiguračních souborů aplikací.

Štítky:,