Báb telepítése és konfigurálása. Bábkiszolgáló telepítése és konfigurálása. A Bash kezdeti telepítési szkript paramétereinek teljes listája

A Puppet hatékonyabb használatához meg kell értenie, hogyan épülnek fel a modulok és a jegyzékek. Ez az oktatóanyag bemutatja, hogyan működnek ezek a bábkomponensek, egy LAMP-verem beállításával az Ubuntu 14.04 szerveren.

Követelmények

A Báb (mester és ügynök) telepítése. Bővebben róla -.
Legalább egy virtuális Ubuntu 14.04 kiszolgáló létrehozása a bábügynök csomópont kiszolgálására.

Bábkód alapjai

Erőforrások

A bábkód többnyire erőforrásokból áll. Az erőforrás olyan kódrészlet, amely leírja a rendszer állapotát és meghatározza a szükséges változtatásokat. Például:

felhasználó ("mitchell":
= = jelen van,
uid => "1000",
gid => "1000",
shell => "/ bin / bash",
home => "/ home / mitchell"
}

Az erőforrás-deklaráció formátuma a következő:

erőforrástípus ("erőforrás_neve"
attribútum => érték
...
}

Az összes típusú bábforrás megtekintéséhez írja be a következő parancsot:

bábforrás - típusok

Ebben az útmutatóban többet megtudhat az erőforrások típusairól.

Kiáltványok

A jegyzék egy hangszerelési forgatókönyv. A .pp kiterjesztésű bábprogramokat manifeszteknek nevezzük. Az alapértelmezett bábjegyzék a /etc/puppet/manifests/site.pp.

Osztályok

Mint minden hagyományos programozási nyelv esetében, az osztályok felelősek a hangszerelés egyes részeinek megszervezéséért és újrafelhasználásáért.

Az osztálydefiníció egy kódblokkot tartalmaz, amely leírja az osztály működését. Ha meghatároztál egy osztályt, használhatod azt a manifesztumokban.

Az osztály definíciója a következő formátumú:

osztály példa_osztály (
...
kód
...
}

Ez a kód meghatározza az example_class osztályt. A báb kód göndör zárójelben lesz.

Osztálydeklaráció az, ahol egy adott osztályt hívnak meg a kódodban. Osztály deklarálásával a Bábu feldolgozza a kódját.

Az osztálydeklaráció lehet rendes és az erőforrás típusa szerint.

Rendszeres osztálydeklarációt adunk a kódhoz az include kulcsszó használatával.

tartalmazza a példa_osztályt

Erőforrás típus szerint deklarálva az osztály erőforrás formátumban kerül deklarálásra:

osztály ("példa_osztály" :)

Ez a deklaráció lehetővé teszi, hogy osztályparamétereket adjon a kódjához, amelyek felülírják a szabványos osztályattribútum-értékeket. Például:

"host2" csomópont (
class ("apache" :) # használja az apache modult
apache :: vhost ("example.com": # define vhost erőforrás
port => "80",
docroot => "/ var / www / html"
}
}

Modulok

A modul egy előre meghatározott módon szervezett manifesztek és más fájlok csoportja, amely megkönnyíti a hangszerelés egyes részeinek megosztását és újrafelhasználását. A modulok segítenek a bábu kód rendezésében, mivel ezek segítségével feloszthatja a kódot több jegyzékre.

A bábmodulok az / etc / puppet / modules könyvtárban vannak tárolva.

Kiáltvány megírása

Gyakorolhatja a jegyzékek, modulok és bábosztályok írását a LAMP-verem Ubuntu szerverre történő telepítésének példájával (ennek eredményeként).

Tehát a hangszerelés elvégzéséhez Ubuntu szerver 14.04 és telepítse rá a LAMP-veremet, erőforrásokra van szüksége az ilyen műveletekhez:

az apache2 csomag telepítése.
az apache2 szolgáltatás elindítása.
csomag telepítése MySQL szerver, mysql-server.
a mysql szolgáltatás elindítása.
php5 csomag telepítése
PHP tesztszkript létrehozása, info.php.
frissítse az apt indexet minden csomag telepítése előtt.

Az alábbiakban három Puppet kód példát talál, amelyekkel megszerezheti egy ilyen LAMP verem beállítását.

Az első példa megtanítja, hogyan kell az alapvető manifesztumokat egyetlen fájlba írni. A második példa segít egy osztály és modul felépítésében és használatában, a korábban megírt manifesztumok alapján. A harmadik példában megtanulhatja, hogyan kell előre beépített nyilvános modulokat használni egy LAMP-verem telepítéséhez.

jegyzet: Jobb, ha friss virtuális szervert használunk a teszteléshez.

1. példa: A LAMP telepítése egyetlen manifeszttel

A bábjegyzéket fel lehet írni az ügynök csomópontjára, majd végrehajtani a báb alkalmazása paranccsal (ehhez nem szükséges mester és ügynök telepítés).

Ebben a szakaszban megtanulhatja, hogyan kell olyan manifeszteket írni, amelyek az ilyen típusú erőforrás-deklarációkat használják:

exec: Parancsok végrehajtása.
csomag: csomagok telepítése.
szolgáltatás: szolgáltatásmenedzsment.
fájl: fájlkezelés.

Manifest létrehozása

Hozzon létre egy új jegyzéket:

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

Adja hozzá a következő kódot a szükséges erőforrások deklarálásához.

# az "apt-get update" parancs futtatása
exec ("apt-update": # exec erőforrás "apt-update"
command => "/ usr / bin / apt-get update" # parancs, amely futtatja ezt az erőforrást
}
# az apache2 csomag telepítése
package ("apache2":
A csomag telepítése előtt = = Exec ["apt-update"], # kérjen "apt-update"
= = telepítve,
}
# indítsa el az apache2 szolgáltatást
szolgáltatás ("apache2":
= = futás,
}
# a mysql-server telepítése
package ("mysql-server":
need = = Exec ["apt-update"], # kérés "apt-update" telepítés előtt
= = telepítve,
}
# indítsa el a mysql szolgáltatást
szolgáltatás ("mysql":
= = futás,
}
# php5 csomag telepítése
csomag ("php5":
need = = Exec ["apt-update"], # kérés "apt-update" telepítés előtt
= = telepítve,
}
# start szolgáltatás info.php
fájl ("/var/www/html/info.php":
= = fájl biztosítása,
tartalom => "", # phpinfo kód
Require => Csomag ["apache2"], # kérés az "apache2" csomaghoz
}

Jegyzék alkalmazása

Az új jegyzék használatához írja be a következő parancsot:

sudo báb alkalmaz - teszt

Ez egy olyan volumetrikus eredményt ad ki, amely megjeleníti a környezet állapotának minden változását. Ha a kimenetben nincs hiba, akkor képesnek kell lennie arra, hogy a böngészőben megnyissa a külső IP-címet vagy tartománynevet. A képernyőn megjelenik egy PHP tesztoldal vereminformációkkal. Ez azt jelenti, hogy az Apache és a PHP működik.

A LAMP-verem mostantól a Puppet segítségével telepítve van a szerverre.

Ez egy meglehetősen egyszerű manifeszt, mivel kivitelezhető az ügynökön. Ha nincs bábfőnöke, más ügynöki csomópontok nem fogják tudni használni ezt a jegyzéket.

A Puppet master szerver 30 percenként ellenőrzi a szerver állapotának változását.

2. példa: LAMP-verem telepítése modul segítségével

Most próbáljon meg létrehozni egy egyszerű modult az előző szakaszban írt LAMP-jegyzék alapján.

Modul létrehozásához hozzon létre egy új könyvtárat a modulok könyvtárában (annak nevének meg kell egyeznie a modul nevével). Ennek a könyvtárnak tartalmaznia kell a manifeszt könyvtárat és az init.pp fájlt. Az init.pp fájl meghatározza a Báb osztályt (a nevének meg kell egyeznie a modul nevével is).

Modul létrehozása

Lépjen a Puppet master szerverre, és hozzon létre egy könyvtárstruktúrát a modulhoz:

cd / etc / báb / modulok
sudo mkdir -p lamp / manifests

Hozza létre és nyissa meg az init.pp fájlt a szerkesztőben:

sudo vi lamp / manifests / init.pp

Helyezze be a lámpaosztályt a fájlba:

osztályú lámpa (
}

Másolja ki a jegyzék tartalmát az 1. szakaszból, és illessze be a lámpaosztály blokkjába. Most megvan az osztálylámpa meghatározása. Más manifesztek képesek lesznek ezt az osztályt modulként használni.

Mentse és zárja be a fájlt.

Modul használata a fő jegyzékben

Mostantól beállíthatja a fő jegyzéket, és a lámpa modul segítségével telepítheti a LAMP-verem a szerverre.

A Puppet master kiszolgálón szerkessze a következő fájlt:

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

Valószínűleg tovább Ebben a pillanatban a fájl üres. Adja hozzá a következő sorokat:

csomópont alapértelmezett ()
"lámpa-1" csomópont (
}

jegyzet: Cserélje le az 1-es lámpát annak a bábügynöknek a gépnevére, ahová a veremet telepíteni szeretné.

A csomópontblokk lehetővé teszi olyan bábu kód megadását, amely csak néhány csomópontra vonatkozik.

Az alapértelmezett blokk minden ügynök csomópontra vonatkozik, amelyeknek nincs külön blokkja (hagyja üresen). A lámpa-1 blokkot a lámpa-1 ügynök csomópontra alkalmazzák.

Adja hozzá a következő sort ehhez a blokkhoz, amely a lámpa modult használja:

Mentse és zárja be a fájlt.

A Bábügynök csomópont mostantól képes lesz letölteni a beállításokat a fő szerverről, és telepíteni a LAMP verem. Ha most szeretne változtatásokat végrehajtani, futtassa a parancsot az ügynökön:

sudo bábügynök - teszt

A modulok a legkényelmesebb mód újrafelhasználás Bábkód. Ezenkívül a modulok segítenek a kód logikai rendezésében.

3. példa: A LAMP telepítése nyilvános modulok használatával

A MySQL modult hasonló módon használják. Adja hozzá a következő sorokat a csomópontblokkhoz:

class ("mysql :: server":
root_password => "jelszó",
}

A paramétereket átadhatja egy MySQL modulnak is.

Adjon hozzá egy erőforrást, amely az info.php fájlt átmásolja a kívánt helyre. Használja a forrás paramétert. Adja hozzá a következő sorokat a csomópontblokkhoz:

fájl ("info.php": # erőforrás fájl neve
elérési út => "/var/www/html/info.php", # cél elérési útja
= = fájl biztosítása,
megkövetelik => Class ["apache"], # a használni kívánt apache osztályt
source => "báb: ///modules/apache/info.php", # ahová a fájlt át akarja másolni
}

Ez az osztálydeklaráció a forrás paramétert használja a tartalom paraméter helyett. Ez az opció nem csak a fájl tartalmát használja, hanem másolja is.

Bábfájl: ///modules/apache/info.php A báb a /etc/puppet/modules/apache/files/info.php fájlba másol.

Mentse és zárja be a fájlt.

Hozzon létre info.php fájlt.

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

A Bábügynök csomópont mostantól képes lesz letölteni a beállításokat a fő szerverről, és telepíteni a LAMP verem. Ha most módosítani szeretné az ügynökkörnyezetet, futtassa a parancsot ezen a csomóponton:

sudo bábügynök - teszt

Ez a parancs letölti az aktuális csomópont összes frissítését, és telepíti a veremre. Az Apache és a PHP működésének ellenőrzéséhez nyissa meg a csomópont IP-címét vagy tartományát egy böngészőben:

http: //lamp_1_public_IP/info.php

Következtetés

Most már rendelkezik alapvető ismeretekkel a Báb modulokról és manifesztumokról. Próbáljon maga létrehozni egy egyszerű jegyzéket és modult.

A báb kiválóan alkalmas az alkalmazás konfigurációs fájljainak kezelésére.

Címkék :,

Számos Unix rendszer kezelése nem kényelmes. Egy paraméter megváltoztatásához az adminisztrátornak kapcsolatba kell lépnie az egyes gépekkel, a parancsfájlok csak részben segíthetnek, és nem minden helyzetben.

Ezt el kell ismerni Windows rendszergazdák hálózatok még mindig jobb helyzetben vannak. Elég megváltoztatni a beállításokat csoportházirendekés egy idő után a hálózat összes számítógépe, beleértve a nemrégiben telepített operációs rendszerrel rendelkező számítógépeket is, „megismeri” az újítást, ha természetesen őket érintik. Visszatekintve a Unix hosszú múltjára, észreveheti, hogy semmi ilyesmi nem fogott meg. A kezdeti telepítéshez vannak olyan megoldások, mint a kickstart. operációs rendszer, de a további finomítás jelentős erőfeszítéseket igényel. Olyan kereskedelmi megoldások, mint a BladeLogic és az OpsWare, a beállítások automatizálásának problémája csak részben oldódik meg, fő előnyük a jelenlét grafikus felület, és csak nagy szervezeteknél engedélyezhető a megvásárlásuk. Vannak természetesen ingyenes megoldásokat kínáló projektek, de fennállásuk teljes ideje alatt nem tudtak nagy közösséget létrehozni. Például a Cfengine nem túl népszerű az adminisztrátorok körében, bár a Linux mellett * BSD, Windows és Mac OS X rendszerekben is használható. Talán ennek oka a konfigurációk létrehozásának viszonylagos bonyolultsága. A feladatok leírásakor figyelembe kell venni az egyes jellemzőket specifikus rendszer, és manuálisan vezérelheti a műveletek sorrendjét parancsok végrehajtásakor. Vagyis az adminisztrátornak emlékeznie kell arra, hogy egyes rendszereknél írjon adduser másoknak useradd, vegye figyelembe a fájlok helyét a különböző rendszerekben stb. Ez nagyságrenddel bonyolítja a parancsok írásának folyamatát, menet közben nagyon nehéz létrehozni a megfelelő konfigurációt, és gyakorlatilag lehetetlen egy idő után elolvasni a létrehozott konfigurációkat. A GPL licenc ellenére a Cfengine valójában egyszemélyes projekt, amely felügyeli az összes változást, és nem nagyon érdekli a nyitott társadalom felépítése. Ennek eredményeként a cfengine képességei elég kielégítőek a fejlesztő számára, de más rendszergazdák számára ez inkább fejfájás. A cfengine javítására harmadik fél fejlesztői különféle kiegészítések jöttek létre, amelyek gyakran csak tovább rontották a helyzetet. A cfengine több ilyen moduljának szerzője, Luke Kanies végül egy hasonló eszköz kifejlesztése mellett döntött, de a cfengine sok hiányossága nélkül.

Báb jellemzői

A báb, a cfengine-hez hasonlóan, egy kliens-szerver rendszer, amely deklaratív, azaz kötelező nyelvet használ a feladatok leírásához, és könyvtárat a megvalósításhoz. Az ügyfelek rendszeresen (alapértelmezés szerint 30 perc) csatlakoznak a központi szerverhez, és megkapják a legfrissebb konfigurációt. Ha a kapott beállítások nem egyeznek a rendszer állapotával, akkor végrehajtásra kerülnek, ha szükséges, a szervernek jelentést küld az elvégzett műveletekről. A szerver mentheti az üzeneteket a syslogba vagy egy fájlba, létrehozhat egy RRD ütemezést és elküldheti azokat a megadott e-mailbe. A Transactionional és az Resource absztrakció további rétegei maximális kompatibilitást nyújtanak a meglévő beállításokkal és alkalmazásokkal, lehetővé téve a koncentrálást rendszer objektumok a részletes parancsok és fájlformátumok megvalósításának különbségei és leírása nélkül. Az adminisztrátor csak az objektum típusával működik, a többivel a Báb gondoskodik. Tehát a csomagok típusa körülbelül 17 csomagrendszert ismer, a szükségeset automatikusan felismeri a terjesztési készletről vagy a rendszer verziójáról szóló információk alapján, bár szükség esetén a csomagkezelő kényszeresen beállítható.

A szkriptekkel ellentétben, amelyeket más rendszereken gyakran nem lehet használni, a harmadik fél adminisztrátorai által írt bábkonfigurációk többnyire problémamentesen működnek bármely más hálózaton. Báb-szakácskönyvben [ http://www.reductivelabs.com/trac/puppet/tags/puppet%2Crecipe] már három tucat kész recept van. A Puppet jelenleg hivatalosan a következő operációs rendszereket és szolgáltatásokat támogatja: Debian, RedHat / Fedora, Solaris, SUSE, CentOS, Mac OS X, OpenBSD, Gentoo és MySQL, LDAP.

Bábnyelv

A továbblépéshez először meg kell értenie a nyelv alapvető elemeit és képességeit. A nyelv a báb egyik erőssége. Leírja azokat az erőforrásokat, amelyeket a rendszergazda tervez kezelni, és a műveleteket. A többséggel ellentétben hasonló döntéseket, a Bábban a nyelv megkönnyíti az összes hasonló erőforráshoz való hozzáférést bármely rendszeren, heterogén környezetben. Az erőforrás leírása általában névből, típusból és attribútumokból áll. Mutassunk például az / etc / passwd fájlra, és állítsuk be annak attribútumait:

fájl ("/ etc / passwd":

tulajdonos => gyökér,

csoport => gyökér,

Most a kiszolgálóhoz csatlakozó kliensek lemásolják az / etc / passwd fájlt, és beállítják a megadott attribútumokat. Több erőforrás definiálható egyetlen szabályban, pontosvesszőkkel elválasztva őket. De mi a teendő, ha a szerveren használt konfigurációs fájl eltér az ügyfélétől, vagy egyáltalán nem használjuk? Például ez a helyzet állhat fel a beállításkor VPN-kapcsolatok... Ebben az esetben a fájl megadható a forrás direktívával. Két lehetőség van, a szokásos módon egy másik fájl elérési útjának megadásához, két protokoll URI is támogatott: fájl és báb. Az első esetben egy külső NFS-kiszolgálóra mutató hivatkozást használnak, a második változatban egy NFS-szerű szolgáltatást indítanak a bábkiszolgálón, amely erőforrásokat exportál. Ez utóbbi esetben alapértelmezés szerint az útvonal a bábgyökérkönyvtárhoz viszonyítva van megadva - / etc / puppet. Vagyis a báb: //server.domain.com/config/sshd_config hivatkozás megfelel az / etc / puppet / config / sshd_config fájlnak. Ezt a könyvtárat felülírhatja a filebucket direktívával, bár helyesebb az /etc/puppet/fileserver.conf fájl azonos nevű szakaszát használni. Ebben az esetben a szolgáltatáshoz való hozzáférést csak bizonyos címekről korlátozhatja. Írjuk le például a config szakaszt.

path / var / báb / config

engedélyezze a * .domain.com címet

engedélyezze a 192.168.0. *

engedélyezze a 192.168.1.0/24

tagadja * .wireless.domain.com

Ezután az erőforrás leírásakor olvassa el ezt a szakaszt.

forrás => "báb: //szerver.domain.com/config/sshd_config"

Az erőforrás neve a kettőspont előtt jelenik meg. A legegyszerűbb esetekben egyszerűen megadhatja névként, jobb, ha álnevet vagy változókat használ. Az álnevet az álnév irányelv segítségével állíthatjuk be. a fájl teljes elérési útja. Bonyolultabb konfigurációkban

fájl ("/ etc / passwd":

álnév => passwd

Az álnév létrehozásának másik lehetősége alkalmas arra az esetre, amikor különböző operációs rendszerekkel kell megküzdenie. Hozzunk létre például egy erőforrást, amely leírja az sshd_config fájlt:

fájl (sshdconfig:

név => $ operációs rendszer? (

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

alapértelmezett => "/ etc / ssh / sshd_config"

Ebben a példában választás előtt állunk. A Solaris fájlja külön meg van adva, az összes többi esetén az / etc / ssh / sshd_config fájl lesz kiválasztva. Ez az erőforrás az sshdconfig néven érhető el, az operációs rendszertől függően a helyes elérési utat választja ki. Például jelezzük, hogy ha az sshd démon fut, és új fájl érkezik, akkor a szolgáltatást újra kell indítani.

= = igaz,

feliratkozás => Fájl

A változókat gyakran használják, amikor felhasználói adatokkal dolgoznak. Például leírjuk a felhasználó otthoni könyvtárainak helyét:

$ homeroot = "/ home"

Most egy adott felhasználó fájljaihoz hozzáférhet

$ (homeroot) / $ név

A $ name paraméter kitöltésre kerül a felhasználó fióknevével. Bizonyos esetekben célszerű alapértelmezett értéket meghatározni egy bizonyos típushoz. Például az exec típushoz gyakran megadják a könyvtárakat, amelyekben futtatható fájlt kell keresnie:

Exec (elérési út => "/ usr / bin: / bin: / usr / sbin: / sbin")

Ebben az esetben, ha több csatolt fájlra és könyvtárra kell mutatnia, használhatja a recurse paramétert.

fájl ("/etc/apache2/conf.d":

forrás => "báb: // báb: //szerver.domain.com/config/apache/conf.d",

recurse => "igaz"

Több erőforrás kombinálható osztályokba vagy definíciókba. Az osztályok egy rendszer vagy szolgáltatás teljes leírását tartalmazzák, és elkülönítve használják őket.

"/ Etc / passwd": tulajdonos => gyökér, csoport => gyökér, mód => 644;

"/ Etc / shadow": tulajdonos => gyökér, csoport => gyökér, mód => 440

Az objektumorientált nyelvekhez hasonlóan az osztályok is felülírhatók. Például a FreeBSD-n az a csoport, amelyik birtokolja ezeket a fájlokat, kerék. Ezért annak érdekében, hogy ne írjuk át teljesen az erőforrást, létrehozunk egy új freebsd osztályt, amely öröklődik a linux osztályból:

class freebsd örökli a linuxot (

Fájl ["/ etc / passwd"] (csoport => kerék);

Fájl ["/ etc / shadow"] (csoport => kerék)

A kényelem érdekében minden osztály áthelyezhető külön fájl, amelyet az include irányelv tartalmazhat. A definíciók több paramétert is vehetnek argumentumként, de nem támogatják az öröklést, és akkor használják őket, amikor újrafelhasználható objektumokat kell leírni. Például definiáljuk a felhasználó saját könyvtárát és az új fiók létrehozásához szükséges parancsokat.

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

felhasználó ("$ name":

= = jelen van,

comment => "$ teljes név",

gid => "$ group",

csoportok => $ csoportok,

tagság => minimum,

shell => "/ bin / bash",

home => "/ home / $ name",

megköveteli => Csoport [$ group],

exec ("$ name homedir":

parancs => “/ bin / cp -R / etc / skel / home / $ név; / bin / chown -R $ név: $ group / home / $ name ",

létrehoz => "/ home / $ name",

megköveteli => [$ name] felhasználó,

Most egy új létrehozásához számla csak utaljon a user_homedir címre.

user_homedir ("sergej":

csoport => "sergej",

teljes név => "Sergej Jaremchuk",

ingroups => ["média", "admin]

Külön-külön vannak leírva a csomópontok (csomópontok), amelyek támogatják az öröklést, valamint az osztályokat. Amikor az ügyfél csatlakozik a bábkiszolgálóhoz, a megfelelő csomópont szakasz keresésre kerül, és megjelennek a számítógép speciális beállításai. Az alapértelmezett csomópont segítségével leírhatja az összes többi rendszert. Az összes típus leírása a "Típus hivatkozás" dokumentumban található, amelyet mindenképpen meg kell ismernie, legalábbis a bábnyelv összes jellemzőjének megértése érdekében. különböző típusok lehetővé teszi a megadott parancsok végrehajtását, többek között bizonyos feltételek teljesülése esetén (például a konfigurációs fájl megváltoztatása), a cronnal, a hitelesítő adatokkal és a felhasználói csoportokkal, a számítógépekkel, az erőforrások csatlakoztatásával, a szolgáltatások indításával és leállításával, a csomagok telepítésével, frissítésével és eltávolításával, SSH kulcsokkal, Solaris zónákkal stb. Ilyen egyszerű a csomaglista frissítése az apt használatával az elosztókon minden nap 2 és 4 óra között.

menetrend (naponta:

időszak => naponta,

tartomány =>

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

menetrend => napi

Az adott rendszer időszakának frissítését minden rendszer csak egyszer hajtja végre, amely után a feladat befejezettnek tekinthető, és törlődik innen kliens számítógép... A bábnyelv más ismert struktúrákat támogat: feltételeket, függvényeket, tömböket, megjegyzéseket és hasonlókat.

A Báb telepítése

A bábhoz Ruby (> = 1.8.1) szükséges OpenSSL támogatással és XMLRPC könyvtárakkal, valamint a Gyorsabb könyvtárral [ http://reductivelabs.com/projects/facter]. A teszt telepítéséhez használt Ubuntu 7.04 adattár már tartalmazza a kiskutya csomagot.

$ sudo apt-cache kereső báb

báb - központosított konfigurációkezelés a hálózatokhoz

bábmester - központosított konfigurációkezelési vezérlő démon

A telepítés telepíti az összes szükséges csomagfüggőséget: facter libopenssl-ruby libxmlrpc-ruby.

$ sudo apt-get install báb bábmester

A paranccsal ellenőrizheti, hogy vannak-e Ruby könyvtárak.

$ ruby -ropenssl -e "szó: igen"

~ $ ruby -rxmlrpc / client -e "put: yep"

Ha nem érkezik hiba, akkor minden szükséges már benne van. Azokat a fájlokat, amelyek a kívánt rendszerkonfigurációt írják le a báb terminológiájában, manifesztumoknak nevezzük. Indításkor a démon megpróbálja elolvasni az /etc/puppet/manifests/site.pp fájlt; ha hiányzik, figyelmeztető üzenetet ad ki. Teszteléskor elmondhatja a démonnak, hogy olyan autonóm módban működjön, amelyben a manifesztre nincs szükség

$ sudo / usr / bin / puppetmasterd —nonódok

Ha szükséges, más fájlokat is csatlakoztathat a site.pp oldalhoz, például osztályleírásokkal. Tesztfuttatáshoz a legegyszerűbb utasítást adhatja meg ebben a fájlban.

fájl ("/ etc / sudoers":

tulajdonos => gyökér,

csoport => gyökér,

A kiszolgáló és az ügyfelek összes konfigurációs fájlja az / etc / puppet könyvtárban található. A fent említett fájlkiszolgáló.conf fájl opcionális, és csak akkor használható, ha a Báb fájlszerverként is működik. Ubuntuban ez a fájl az / etc / puppet / files alkönyvtárat exportálja. Az ssl alkönyvtár tanúsítványokat és kulcsokat tartalmaz, amelyeket az ügyfélkapcsolatok során a titkosításhoz használnak. A gombok automatikusan létrejönnek, amikor először elindítja a puppetmasterd programot, ezeket manuálisan létrehozhatja a paranccsal.

$ sudo / usr / bin / puppetmasterd --mkusers.

A puppetd.conf és a puppetmasterd.conf fájlok hasonlóak. Megadják a démonok működésének néhány paraméterét az ügyfélrendszeren és a kiszolgálón. Az ügyfélfájl csak a jelenlétében különbözik szerver paraméter rámutatva a számítógépre, amelyen a puppetmasterd fut.

szerver = daráló.com

logdir = / var / log / báb

vardir = / var / lib / báb

rundir = / var / run

# jelentést küld a szervernek

Annak elkerülése érdekében, hogy mindent kézzel gépeljen be, létrehozhat egy sablont maga a puppetd segítségével.

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

Hasonlóképpen létrehozhatja a site.pp fájlt a szerveren.

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

Egy másik tagmail.conf fájl segítségével megadhatja azokat az e-mail címeket, amelyekre a jelentéseket elküldik. A legegyszerűbb esetben egy sort használhat.

minden: [e-mail védett]

Nincs elég konfigurációs fájl az ügyfél számára a szerverhez való csatlakozáshoz. Ehhez igazolásokat is alá kell írnia. Először is, hogy a szerver értesüljön az ügyfélszámítógép új számítógépéről, írja be a következő parancsot:

$ sudo puppetd - szerver daráló.com - várjon 60-os tesztet

info: Tanúsítvány kérése

figyelmeztetés: a társ tanúsítványt nem ellenőrizzük ebben az SSL munkamenetben

értesítés: Nem kapta meg az igazolást

Ha egy másik karakterláncot ad vissza, ellenőrizze a szerver működését.

$ ps aux | grep báb

báb 5779 0,0 1,4 27764 15404? Ssl 21:49 0:00 ruby / usr / sbin / bábmesterd

A tűzfalnak engedélyeznie kell a kapcsolatot a 8140-es porton.

A szerveren kapunk egy listát az aláírandó tanúsítványokról.

$ sudo puppetca --list

nomad.grinder.com

És aláírjuk az ügyféligazolást.

$ sudo puppetca –sign nomad.grinder.com

Most az ügyfél szabadon csatlakozhat a szerverhez és megkapja a beállításokat.

Sajnos egyszerűen nem lehet a Buppet összes képességét megmutatni a cikk keretein belül. De amint láthatja, ez egy funkcionális és rugalmas eszköz, amely lehetővé teszi a feladatok nagy részének megoldását nagyszámú rendszer egyidejű adminisztrációjához. Ha a munka jellege miatt több rendszert kell konfigurálnia. És ami a legfontosabb: a projektnek sikerült egy kicsi, de folyamatosan növekvő közösséget összegyűjteni. Reméljük tehát, hogy egy jó ötletnek nem szabad meghalnia vagy elsodródnia.

Nem is olyan régen a magazin oldalain fontolgattuk a rendszert távirányító a UNIX gépek Cfengine konfigurációja, ami sokkal könnyebbé teszi az életet rendszergazda a több hálózati csomópont konfigurálásához szükséges műveletek automatizálásával. De bármennyire is kényelmes a Cfengine, sok hátránya van, amelyből hiányzik a Báb nevű rendszer.

Képzelje el magát egy rendszergazda szerepében, aki több száz más operációs rendszert futtató gép egészségének fenntartásáért felelős, mint például a UNIX. Mindegyik konfigurációt, időszakos frissítést és felügyeletet igényel, és feltételezzük, hogy sokan hasonló funkciókat látnak el.

Kétharmada munkaállomás, még néhány útválasztó, a többi pedig több webszerver és adattárház. A kérdés az: hogyan lehet kezelni ezt az egész gazdaságot? A legegyszerűbb válasz az, ha egyszerűen csatlakozik mindegyikhez az SSH használatával, és elvégzi a szükséges módosításokat. Ennek a módszernek azonban két problémája van. Először is, ez nagyon időigényes. Másodszor, az adminisztrátornak folyamatosan sok monoton műveletet kell végrehajtania (például az OpenOffice.org frissítéséhez minden munkaállomáson ugyanazokat a parancsokat kell több tucatszor végrehajtania). Megpróbálhatja elkerülni ezt a problémát több olyan szkript megírásával, amelyek maguk csatlakoznak az egyes gépekhez, és végrehajtanak előre megírt parancsokat. De itt is problémák várnak rád.

A parancsfájlokat folyamatosan módosítani kell annak érdekében, hogy az egyes feladatokhoz igazodjanak; a szkripteknek figyelembe kell venniük az operációs rendszerek és verziók közötti különbségeket, és hosszú ideig hibakeresést kell végezniük, mielőtt alkalmazzák őket futó gépekre. Általában nem comme il faut. A helyes válasz az úgynevezett távoli konfigurációkezelő rendszerek használata, amelyek közül a legismertebbek nyitott rendszerek Cfengine és Báb. Az ilyen rendszerek minden felelősséget vállalnak a gép konfigurációjának megvalósításáért a megfelelő fajta, a rendszergazdától csak a rendszer végső állapotának leírását követeli meg egy speciális nyelven (például annak leírása, hogy mely csomagokat kell telepíteni az operációs rendszerbe, mely sorokat kell hozzáadni a konfigurációs fájlokhoz, mely parancsokat kell végrehajtani stb.). Ezt követően minden csomópont maga kap információt a szükséges állapotról a szervertől, és automatikusan konfigurálja a rendszert. Ennek a mechanizmusnak köszönhetően az új gépek emberi beavatkozás nélkül teljesen hangolhatók, a meglévők pedig csak néhány soros állapotleírással újrakonfigurálhatók.

Báb?

Már egy teljes cikket szenteltünk a Cfengine rendszernek, ezért ma a Báb rendszerre koncentrálunk, amelyet egészen ideológiai követőjének nevezhetünk. A bábot Luke Kanies fejlesztette ki, aki belefáradt a Cfengine korlátaiba, és úgy döntött, hogy a semmiből egy jobb verziót készít. Ha korábban használta a Cfenfine-t, akkor valószínűleg a Puppet egy kényelmesebb és hatékonyabb rendszert talál. A Puppet állapotleíró nyelve magasabb szintű és rugalmasabb, így az adminisztrátornak nem kell aggódnia olyan dolgok miatt, mint külön szabályok írása az operációs rendszer minden típusához vagy Részletes leírás triviális cselekedetek végrehajtása. A báb lehetővé teszi, hogy a gazdája arra koncentráljon, amit szeretne, ahelyett, hogy ezt csinálja (például egy bizonyos csomag telepítéséhez a rendszer által támogatott bármely operációs rendszerre elegendő, ha szó szerint néhány sort ír "Install a program telepítéséhez szükséges parancsok leírása helyett). Báb van írva egyszerű nyelv Ruby, amely megkönnyíti az alkalmazkodást konkrét feladatés bővítse a funkcionalitást (rugalmas plugin rendszert biztosítanak).

Ezen túlmenően, a Cfengine fejlesztési modellel ellentétben, amely valójában egy ember körül forog, a Báb körül nagy rajongók közössége alakult ki, akik kódjavítással járulnak hozzá, konfigurációs példákat osztanak meg és dokumentációt írnak.

Általában úgy tűnik, hogy a Báb modernebb és jobban megtervezett rendszer. A Cfengine-hez hasonlóan szinte minden modern UNIX-szerű operációs rendszert támogat (beleértve a MacOS X-et is), és a Windows tetején Cygwin-ben is futtatható. Függőségeinek listája csak a Ruby tolmácsot és a Factor eszközt tartalmazza, ezért a telepítéssel nem lehet probléma (méltányos azt mondani, hogy a Cfengine függőségek listája még rövidebb).

Telepítés

A Cfengne-hez hasonlóan a Puppet is egy kliens-szerver rendszer, amely egy vezérlő szerverből és egy slave csomópontból áll. A szerver tárolja a csomópontok végső állapotainak leírását (amelyet bábtáblázatban manifesztnek neveznek), és várja, hogy csatlakozzanak. Félóránként (alapértelmezés szerint) az ügyfél csatlakozik a kiszolgálóhoz, megkapja tőle a végleges állapot leírását, ellenőrzi azt a jelenlegi állapotával, és ha ez és / vagy a leírt állapot megváltozott, újrakonfigurálja a rendszert, majd elmegy aludni. A kommunikáció titkosított csatornán keresztül zajlik, így az állapotleírás hamisításán alapuló támadások kizárásra kerülnek (de ha egy támadó átveszi a szervert, akkor minden csomópont az ő irányítása alatt áll).

A báb minden népszerű disztribúció tárházában megtalálható, ezért a telepítésnek egyszerűnek kell lennie. Például a Debian / Ubuntuban a Puppet kliens így telepíthető:

$ sudo apt-get install báb

A szerver pedig ilyen:

$ sudo apt-get install báb bábmester

A kliens és szerver konfigurációs fájljai az / etc / báb könyvtárban vannak tárolva. Ezek közül a legfontosabb az /etc/puppet/manifests/site.pp fájl, amely a jegyzéket tartalmazza.

Tárolja az állapotok leírását, és csak a szerveren létezhet. A hibakeresés megkönnyítése érdekében adjon hozzá legegyszerűbb konfiguráció:

osztály passwd (
fájl ("/ etc / passwd":
tulajdonos => gyökér,
csoport => gyökér,
mód => 644,
}
}
csomópont alapértelmezett (
tartalmazza passwd
}

Ezek a sorok azt az állapotot írják le, ahol az / etc / passwd fájlnak a root tulajdonosának kell lennie, és 644-es jogosultságokkal kell rendelkeznie. A következő részben közelebbről megvizsgáljuk a jegyzékfájl formátumát. A második legfontosabb fájl az /etc/puppet/puppet.conf. Beállítja a kiszolgáló és az ügyfelek konfigurációját, ezért jelen kell lennie a Bábhálózat összes szervezett gépén. Az Ubuntuban ez a fájl tartalmazza a minimálisan szükséges és a legtöbb esetben elégséges beállításokat. Az alábbiakban megjegyzések vannak:

# vi /etc/puppet/puppet.conf
# Normál utak a könyvtárakhoz
logdir = / var / log / báb
vardir = / var / lib / báb
ssldir = / var / lib / báb / ssl
rundir = / var / run / báb
# A karakter eszköz helye,
# az operációs rendszerről szerzett információkat
tényút = $ vardir / lib / facter
# Szinkronizálja a bővítményeket
# (telepített beépülő modulok a szerverre - másolva vannak az ügyfelekhez)
pluginsync = true
# Katalógus sablonokkal (alább olvashat róluk)
templatedir = $ confdir / templates
# Szinkronizálás az etckeeperrel
# (ki tudja - meg fogja érteni, a többinek nincs szüksége)
prerun_command = / etc / báb / etckeeper-pühendpre
postrun_command = / etc / báb / etckeeper-activpost

A konfigurációs fájl tartalmazhat nagyszámú különféle opciók, amelyekről információkat az alapértelmezett konfiguráció létrehozásával lehet beszerezni:

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

Az alapértelmezett ügyfél-konfigurációt egy másik parancs segítségével állítják elő:

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

A konfiguráláshoz a fileserver.conf és az auth.conf fájlokat használják fájlszerver(erről a "Fájlszerver" részben olvashat) és a hitelesítésről. Még nincs értelme hozzájuk nyúlni. A konfiguráció befejezése után a bábkiszolgálót újra kell indítani:

$ sudo /etc/init.d/puppetmaster restart

Akkor készen áll az ügyfél kéréseinek elfogadására. Aláírt tanúsítvány nélkül azonban egyetlen ügyfél sem tudja megszerezni a jegyzéket a szervertől és konfigurálni a gépet.

Ezért teszt üzemmódban kell futtatnunk a Puppet klienseket, hogy tanúsítványaikat átadhassák aláírásra a szerverre (ezt egyébként az összes gépen egyidejűleg megtehetjük a shmux eszközzel):

$ sudo puppetd -server báb-server.com -verbose -teszt

Visszatérünk a szerverre, és megkapjuk az aláírásra kész tanúsítványok listáját:

$ sudo puppetca --list

Válasszon gazdát a listából, és írja alá a tanúsítványát:

$ sudo puppetca - jel nomad.grinder.com

Vagy mindent egyszerre írunk alá:

$ sudo puppetca --jel - minden

Az ügyfelek most már harc módban is elindíthatók. De először regisztrálnia kell a bábkiszolgáló nevét a konfigurációs fájlban (alapértelmezés szerint a neve csak báb):

$ sudo su
# echo "" >> /etc/puppet/puppet.conf
# echo "server = báb-szerver.com" >> /etc/puppet/puppet.conf
# kilépés

Elindítjuk ügyfeleinket:

$ sudo /etc/init.d/puppet start

Állami leírás nyelve

Mint fentebb említettük, a Puppet a saját nyelvét használja az operációs rendszer végső állapotának leírásához, amellyel a sysadmin meghatározza, hogy milyen operációs rendszer-összetevőket kell hozni ahhoz, hogy elérje a kívánt állapotot. Ez egy meglehetősen összetett nyelv, amely ennek ellenére sokkal egyszerűbb, mint bármely programozási nyelv. Ha legalább felületesen ismeri a bash szkript nyelvét, akkor könnyen megértheti a báb nyelvét. A nyelv legfontosabb eleme az erőforrások, amelyek segítségével megtalálható az űrlap leírása, amelyre az operációs rendszer egyik összetevőjét le kell redukálni. Például a következő egyszerű erőforrás leírja az / etc / passwd fájl kívánt állapotát:

# vi /etc/puppet/manifests/site.pp
fájl ("/ etc / passwd":
tulajdonos => "gyökér"
}

Itt a fájl az erőforrás típusa. Több tucat van belőlük, a fájlokat kezelő erőforrásoktól kezdve, mint ebben a példában, és a csomagokkal és szolgáltatásokkal végződik. Az / etc / passwd sor az erőforrás neve.

A fájltípus esetében a név megegyezik a fájl elérési útjával, azonban néhány más típusban a név tetszőleges lehet. A sortulajdonos => "root" a tulajdonos attribútum rootra állítását írja le, vagyis azt mondja, hogy a tulajdonos a megadott fájlt rendszergazdának kell lennie.

Minden erőforrástípusnak megvan a saját módosítható attribútumkészlete, ráadásul vannak speciális metaattribútumok, amelyek bármely erőforrásban felhasználhatók. Az erőforrások egyik fontos tulajdonsága a kapcsolattartás képessége. Ez felhasználható függőségi láncok kialakítására. A következő bejegyzés létrehoz egy / etc / group erőforrást, amely az / etc / passwd erőforrástól függ (a függőségeket a szükséges meta attribútummal adjuk meg):

# vi /etc/puppet/manifests/site.pp
fájl ("/ etc / group":
megköveteli => Fájl ["/ etc / passwd"],
tulajdonos => "gyökér",
}

Ez azt jelenti, hogy az / etc / group erőforrás csak akkor konfigurálható (az ismertetett formára redukálva), ha az / etc / passwd erőforrás be van állítva. Az erőforrásokat osztályok nevű erőforrásgyűjteményekbe csoportosíthatjuk. Erre azért van szükség, hogy az értelemben és a végrehajtott feladat típusában hasonló erőforrásokat egyetlen absztrakt erőforrásba egyesítsük. Például a kényelem érdekében egyesíthetjük az nginx webkiszolgáló telepítését és elindítását egy azonos nevű absztrakt erőforrássá:

# vi /etc/puppet/manifests/site.pp
osztály nginx (
csomag ("nginx":
= = telepítve
}
szolgáltatás ("nginx":
= = futás,
Require => csomag ["nginx"],
}
}

Itt a csomagerőforrás-típust használják az nginx csomag telepítésére a rendszerbe, a szolgáltatás pedig az azonos nevű szolgáltatás elindítására szolgál. A Request használatával csak akkor kényszerítjük a rendszert a szolgáltatás elindítására, ha a csomagot sikeresen telepítettük. Az osztályok kényelme az, hogy az alábbiaktól függően is felvehetők:

# vi /etc/puppet/manifests/site.pp
szolgáltatás ("tintahal":
= = futás,
megköveteli => Osztály ["nginx"],
}

Akárcsak a valódi OOP nyelvekben, az osztályok örökölhetnek egymástól és felülírhatják az attribútumokat:

# vi /etc/puppet/manifests/site.pp
osztály passwd (
fájl ("/ etc / passwd":
tulajdonos => "gyökér",
csoport => "gyökér",
}
}
osztály passwd-bsd örökli a passwd-t (
Fájl ["/ etc / passwd"] (csoport => "kerék")
}

Itt a passwd-bsd osztály a passwd-től örököl, hogy felülbírálja az / etc / passwd erőforrás csoportattribútumát (BSD rendszereken az / etc / passwd a kerékcsoporthoz tartozik, ezért létrehoztuk külön osztály az ilyen rendszerek számára). Később megvizsgáljuk az alternatív attribútumértékek feltételekkel történő kiválasztásának helyesebb és kézenfekvőbb módját.

A változók minden programozási nyelv egyik alapvető eleme, és a Bábnak is vannak ilyenek. A változók $ jellel kezdődnek, és tetszőleges számot, karakterláncot vagy logikai értéket tartalmazhatnak (igaz, hamis):

$ want_apache = true
$ apache_version = "2.2.14"

A Puppet változókkal kapcsolatos egyik legerősebb tulajdonsága, hogy integrálódik a facter gépi információs eszközzel. Ez a segédprogram minden gépspecifikus információt kulcs-érték párok formájában ad vissza, amelyeket a Bábban azonos nevű változókká alakítanak át. A Puppet feltételes utasításokkal együtt felhasználhatók az erőforrás-attribútumok megváltoztatására a gép tulajdonságaitól függően.

Például a fent leírt passwd osztály könnyen átírható, hogy automatikusan kiválasszon egy attribútumot az operációs rendszer típusától függően (és magára az osztályra már nincs szükség):

# vi /etc/puppet/manifests/site.pp
fájl ("/ etc / passwd":
tulajdonos => "gyökér",
csoport => $ kernel? (
Linux => "root",
FreeBSD => "kerék",
},
}

Attól függően, hogy melyik operációs rendszeren lesz elemezve a manifeszt adott töredéke, a group attribútum értéke root vagy wheel lesz. A feltételes operátor mellett a bábnyelv támogatja az esetválasztó operátort is, amellyel egy változó értékétől függően létrehozhat egy adott erőforrást:

# vi /etc/puppet/manifests/site.pp
case $ operatystemystem (
redhat: (szolgáltatás ("httpd": biztosít = = fut))
debian: (szolgáltatás ("apache": biztosít = = fut))
alapértelmezett: (service ("apache2": užtikrinti =>
futás))
}

Ez a kód az operációs rendszertől függően különböző lehetőségeket határoz meg a típusú szolgáltatás erőforrásaihoz (a különböző Linux disztribúciókban a szolgáltatások neve eltérhet, ezért melyik szolgáltatásnak kell elindítania a Puppet szolgáltatást, mindegyikhez külön-külön kell megadnia).

Az alapértelmezett beállítást akkor használjuk, ha a változó értéke nem egyezik meg az előző opciók egyikével sem. A korábban tárgyalt fájl-, csomag- és szolgáltatási erőforrástípusok mellett a Puppet sok mást támogat, ideértve a harmadik féltől származó erőforrástípusokat is. Részletes leírásuk, beleértve a példákat, a támogatott attribútumokat és szolgáltatásokat, a hivatalos dokumentációban található - http://docs.puppetlabs.com/references/stable/type.html. Az alábbiakban a leggyakrabban használtak listája és rövid leírása található:

Népszerű bábforrás-típusok

cron - cron munkák kezelése
exec - parancsfájlok és parancsok futtatása
fájl - fájlkezelés
filebucket - fájlmentés
csoport - csoportvezetés
host - az / etc / hosts fájl bejegyzéseinek kezelése
interfész - hálózati interfészek konfigurálása
mount - mount fájlrendszerek
értesítés - üzenet küldése a Bábnapló fájlba
csomag - csomagkezelés
szolgáltatás - szolgáltatásmenedzsment
sshkey - SSH kulcskezelés
rendezett - fájlok törlése a körülményektől függően
felhasználó - felhasználó kezelése
zónák - a Solaris zónák kezelése

A bábnyelv második legfontosabb eleme az erőforrások után a csomópontok. Segítségükkel az adminisztrátor leírhatja, hogy mely gépekre kell bizonyos erőforrásokat és osztályokat alkalmazni. Más szavakkal, ez egy módja annak, hogy megadjon egy egyedi konfigurációt a Báb hálózatban résztvevő gépek mindegyikéhez. A csomópont legegyszerűbb példája a cikk elején, a "Telepítés" részben található:

# vi /etc/puppet/manifests/site.pp
csomópont alapértelmezett (
tartalmazza passwd
}

Ez az alapértelmezett csomópont meghatározása, amely tartalmazza a passwd erőforrást / osztályt. Az alapértelmezett név azt jelenti, hogy "az összes többi csomópont", így a fentebb meghatározott valódi passwd erőforrás / osztály mindegyiken konfigurálásra kerül. Kulcsszó include itt a kényelem érdekében használatos, sőt, minden osztály és erőforrás közvetlenül leírható a csomópont leírásában, de ez nem ajánlott. Az alapértelmezés mellett a gazdagépnév tartalmazhatja a gép hálózati nevét (akkor a csomópontban leírt összes erőforrást csak ezen a gépen konfigurálja), vagy tetszőleges nevet (akkor ezt a csomópontot egy másik csomópont örökölheti). Annak megértéséhez, hogy mindez hogyan működik együtt az osztályokkal és az erőforrásokkal, vegye figyelembe egy kész bábu jegyzék példáját, amelyet két hálózatba kötött gép (webkiszolgáló és NTP-kiszolgáló) konfigurálásához használnak:

# vi /etc/puppet/manifests/site.pp
# Telepítse és futtassa az SSH szervert
osztály sshd (
csomag (openssh-server: užtikrinti => telepítve)
szolgáltatás (sshd:
név => $ operációs rendszer? (
fedora => "sshd",
debian => "ssh",
alapértelmezett => "sshd",
},
enable => true,
= = futás,
}
}
# Az Apache telepítése és futtatása
osztály httpd (
csomag (httpd: užtikrinti => telepítve)
szolgáltatás (httpd:
enable => true,
= = futás,
}
}
# Az NTP szerver telepítése és futtatása
osztály ntpd (
csomag (ntp-server: užtikrinti => telepítve)
szolgáltatás (
ntp-szerver:
enable => true,
= = futás,
}
}
# Alapcsomópont, csak az összes többi szülőjeként használható
csomópont alapja (
tartalmazza az sshd-t
}
# Az a gazdagép, ahol a webszerver található
a web.server.com csomópont örökli az alapot (
beilleszteni a httpd-t
}
# NTP szerver gazdagép
az ntp.server.com csomópont örökli a bázist (
tartalmazza az ntpd-t
}

Ez a látszólag egyszerű konfiguráció meglehetősen sokat tesz: telepíti és elindítja az Apache-ot a gépen a web.server.com címmel, és telepíti és elindítja az NTP szervert a gépen. ntp.server.com... Ezenkívül mindkét gép SSH szervert telepít. Ez a konfiguráció valószínűleg még egy rendszergazdának sem felel meg; komolyan módosítani kell, hogy megtanítsuk a szerverek megfelelő konfigurálását, a friss konfigurációk és egyéb fájlok fogadását a fő bábkiszolgálótól.

Ez azonban egyértelműen megmutatja a Báb erejét. Egy egyszerű konfiguráció segítségével úgy készítettük el, hogy a gépek maguk telepítsék és futtassák a szükséges szoftvert, és működőképes állapotban tartják (ha a szerver összeomlik, a Puppet átkonfigurálja magát, hogy a rendszereket a kívánt állapotba hozza).

File Server

Sok feladat távoli adminisztráció nem oldható meg további fájlok másolása a gépekre. Ezek lehetnek előre elkészített konfigurációk, az Apache weboldalai, olyan csomagok, amelyek nincsenek a hivatalos adattárban, és még sok más. A fájlok ide történő továbbításának megkönnyítése érdekében távoli csomópontok A báb fájlszervert tartalmaz.

A fájlkiszolgáló beállításait az /etc/puppet/fileserver.conf fájl tárolja. Ahhoz, hogy a Puppet egy adott könyvtár tartalmát kiszolgálja az ügyfelek számára, több sort kell beírnia:

# vi /etc/puppet/fileserver.conf
elérési út = / var / báb / fájlok
engedélyezze a * .server.com webhelyet

Ez a két sor azt jelzi, hogy a / var / puppet / files könyvtárnak elérhetőnek kell lennie a server.com tartomány összes gazdagépének. Ezenkívül megadhatjuk az engedélyezett gép teljesen minősített tartománynevét vagy annak IP-címét, valamint leválaszthatjuk a nemkívánatosakat a megtagadási irányelv segítségével. Ezt követően ebben a könyvtárban bármely fájl áthelyezhető az ügyfélbe a fájlerőforrás segítségével. Például:

# vi /etc/puppet/manifests/site.pp
fájl ("/etc/httpd/conf/httpd.conf":
forrás => "báb: //httpd/httpd.conf",
mód => 644,
}

A kiszolgálón a / var / puppet / files / httpd könyvtárban található httpd.conf fájl átmásolásra kerül a célgépre az erőforrás nevében megadott útvonal használatával.

következtetések

Ebben a cikkben a Báb képességeinek nagyon kis részét ismertettük. Valójában ez egy összetett rendszer, amelyet teljes egészében csak egy könyv oldalán lehet leírni. Ugyanakkor a Puppet nagyon könnyen konfigurálható és karbantartható, különösen azért, mert sok példát találhat a konfigurációjára az interneten.

Info

A báb a HTTP protokollt használja, így webkiszolgáló irányítása alatt futtatható a teljesítmény javítása érdekében.
A bábu felhasználható egyetlen helyi gép automatikus konfigurálására és karbantartására.
A Báb ötvözésével hálózati telepítés OS (pxe-install) és önállóan összeállítva installációs képek, létrehozhat egy teljesen önkonfiguráló géphálózatot, amely csak egy paranccsal telepíthető.
A Bábut számos nagyvállalat használja, például a Google, a Fedora Project, a Stanfordi Egyetem, a Red Hat, a Siemens IT Solution és a SugarCRM.

Linkek

http://docs.puppetlabs.com - Bábdokumentáció
http://docs.puppetlabs.com/guides/language_tutorial.html - Teljes leírás Bábnyelv
http://docs.puppetlabs.com/references/stable/type.html - Erőforrástípusok

Ha az Ön által kezelt kiszolgálók száma kevesebb, mint tíz - ritkán gondolkodik bárki a központosított felügyeletén, erre lehet, hogy nincs szükség. Ha több tucat szerver van, a szoftverek és konfigurációk központosított kezelése rendkívül hasznos. Ha több száz és ezer szerver van, akkor létfontosságú. Sok ilyen program létezik, például: Szakács, CFEngine, Báb ... Ez az utolsó, amelyről ebben a bejegyzésben lesz szó.

A bábot méltán tartják az egyik jobb megoldások mint az. Olyan cégek használják, mint a Google, a Citrix és a Red Hat. Ez az kliens-szerver alkalmazás a Ruby programozási nyelven íródott, amelyet két ízben osztottak el:

Báb nyílt forráskódú - teljesen ingyenes verzió
Puppet Enterprise - legfeljebb 10 szerver konfigurációjában ingyenes, további licencek vásárlását igényli

Fontolja meg a Puppet Open Source szerver és az ügynök telepítését, amelyek a legtöbb modern disztribúció csomagjában találhatók. Ezután az Ubuntu 12.04 Precise Pangolin-ra fogunk koncentrálni.

Szerver rész A bábot hívják bábjátékos, kezdjük belőle a telepítést:

: ~ # apt-get install puppetmaster

És most az ügyfél:

: ~ # apt-get install báb

Az ügyfél konfigurációs fájljában /etc/puppet/puppet.conf a következő szakasz hozzáadásával el kell mondania a szerverről:

Szerver = bábu.helyi jelentés = true pluginsync = hamis

Jobb, ha a kezdeti szakaszban kikapcsolja a pluginsync alkalmazást.

Indítsuk el a báb klienst egy tanúsítványkérés létrehozásához:

: ~ # puppetd --verbose --test info: Új SSL kulcs létrehozása a linux.local információkhoz: Cache tanúsítvány a ca info számára: Új SSL tanúsítványkérelem létrehozása a linux.local információkhoz: Certificate Request ujjlenyomat (md5): E5: EA: AC: 5B: 22: 9A: BA: 42: B8: A1: 63: 9E: 1F: 1F: 23: 51 Kilépés; nem található tanúsítvány, és a waitforcert le van tiltva

A szerveren ellenőriznie kell, hogy megkapta-e a tanúsítványkérést, és ha igen, ki kell írnia a tanúsítványt:

: ~ # puppetca --list "linux.local" (E5: EA: AC: 5B: 22: 9A: BA: 42: B8: A1: 63: 9E: 1F: 1F: 23: 51): ~ # puppetca - -sign linux.local értesítés: Aláírt tanúsítványkérés a linux.local értesítéshez: Bábu fájl eltávolítása :: SSL :: CertificateRequest linux.local itt: "/var/lib/puppet/ssl/ca/requests/linux.local.pem"

Megismételjük az előző lépést az ügyfélen:

: ~ # puppetd --verbose --test info: Cache tanúsítvány a linux.local információhoz: Bővítményinformációk lekérése: Caching certificate_revocation_list for ca info: Caching catalog for linux.local info: A "1356278451" konfigurációs verziójának alkalmazása info: Állapotfájl létrehozása / var / lib / puppet / state / state.yaml értesítés: A kész katalógus 0,02 másodperc alatt lefut

Remek, minden működik. Térjünk át az első manifeszt létrehozására. A megnyilvánulásokat vagy konfigurációkat egy speciális deklaratív nyelven írják le. Rögtön szokjuk meg a jót, használjunk moduláris felépítést és osztályokat. Írjunk például egy modult, amely naprakészen tartja a fájlt / etc / hosts minden szerverünkön.

Ellenőrizzük, hogy a báb hol keres modulokat:

: ~ # báb alkalmazza --configprint modulepath / etc / báb / modulok: / usr / share / báb / modulok

Készítsen könyvtárakat a modulhoz

: ~ # cd / etc / báb / modulok: ~ # mkdir hosts; cd gazdagépek; mkdir megnyilvánul; cd nyilvánul meg

Meg kell hívni az első manifesztet, más néven fő modul fájlt init.pp

Osztálygazdák (# bábu.lokális hoszt ("bábu.lokális": biztosít = = "jelen", cél => "/ stb / hosztok", ip => "192.168.0.1", hoszt_aliasek => "báb",) # linux.local gazdagép ("linux.local": gondoskodjon => "jelen", target => "/ etc / hosts", ip => "192.168.0.2", host_aliases => "linux",))

Alapértelmezés szerint a báb fájlokat keres /etc/puppet/manifests/site.pp a konfiguráció betöltéséhez konvertáljuk a következő formára:

Csomópont alapértelmezett (tartalmazza a gazdagépeket)

A kiszolgálón lévő jegyzék ellenőrzése:

: ~ # báb alkalmazza --verbose /etc/puppet/manifests/site.pp info: A "1356281036" konfigurációs verzió alkalmazása: / Stage // Host / užtikrinti: létrehozott információ: FileBucket hozzáadása (md5): / Stage // Host / biztosít: létrehozott értesítés: A kész katalógus 0,03 másodperc alatt lefut

Az ügyfélnél:

: ~ # ll / etc / hosts rw-r - r-- 1 gyökérgyökér 290. december 16., 19:10 / etc / hosts: ~ # puppetd --verbose --teszt info: Katalógus gyorsítótárazás a linuxhoz. helyi információk: Konfiguráció alkalmazása "1356283380" verzió információ: FileBucket hozzáadás (md5) értesítés: / Stage / Hosts / Host / užtikrinti: létrehozott értesítés: / Stage / Hosts / Host / užtikrinti: létrehozott értesítés: A kész katalógus 0,04 másodperc alatt lefut: ~ # ll / etc / hosztok -rw-r - r-- 1 gyökérgyökér 551. december 23. 20:43 / etc / hosts

Miután megbizonyosodtunk arról, hogy minden működik, engedélyezzük a szolgáltatás beindítását / etc / default / báb változás:

# Indítani a bábut a csomagtartón? START = igen

Elindítjuk a szolgáltatást

: ~ # szolgálati bábkezdés

A báb 30 percenként lekérdezi a bábmester kiszolgálót a konfiguráció megváltoztatása érdekében, és ha szükséges, ennek megfelelően állítja be a rendszert.

Szergej Jaremcsuk

Központosított UNIX konfiguráció a bábdal

Számos UNIX rendszer kezelése nem kényelmes. Egy paraméter megváltoztatásához az adminisztrátornak kapcsolatba kell lépnie az egyes gépekkel, a parancsfájlok csak részben segíthetnek, és nem minden helyzetben.

Igaz, a Windows hálózati rendszergazdái jobb helyzetben vannak. Elég megváltoztatni a csoportházirendek beállításait, és egy idő után a hálózat összes számítógépe, beleértve azokat is, amelyek nemrégiben telepített operációs rendszerrel rendelkeznek, "megismerik" az újítást, ha természetesen őket érintik. Visszatekintve a UNIX hosszú múltjára, láthatja, hogy semmi hasonló nem fogott meg. Vannak olyan megoldások, mint a kickstart, amelyek segítenek az operációs rendszer kezdeti telepítésében, de a további csípés sok erőfeszítést igényel. A kereskedelmi megoldások, például a BladeLogic és az OpsWare, csak részben oldják meg a beállítások automatizálásának problémáját, legfőbb előnyük a grafikus felület jelenléte, és csak nagy szervezetek engedhetik meg maguknak. Természetesen vannak olyan projektek, amelyek ingyenes megoldásokat kínálnak, de fennállásuk teljes ideje alatt nem tudtak nagy közösséget létrehozni. Például a Cfengine nem túl népszerű az adminisztrátorok körében, bár a Linux mellett * BSD, Windows és Mac OS X rendszerekben is használható. Talán ennek oka a konfigurációk létrehozásának viszonylagos bonyolultsága. A feladatok leírásakor figyelembe kell vennie az egyes rendszerek sajátosságait, és manuálisan kell vezérelnie a műveletek sorrendjét a parancsok végrehajtásakor. Vagyis az adminisztrátornak emlékeznie kell arra, hogy egyes rendszereknél írjon adduser másoknak - useradd, vegye figyelembe a fájlok helyét a különböző rendszerekben stb. Ez nagyságrenddel bonyolítja a parancsok írásának folyamatát, menet közben nagyon nehéz létrehozni a megfelelő konfigurációt, és szinte lehetetlen egy idő után elolvasni a létrehozott konfigurációkat. A Cfengine GPL licenc ellenére ez egy egyszemélyes projekt, amely felügyeli az összes változást, és nem nagyon érdekli a nyitott társadalom kiépítése. Ennek eredményeként a Cfengine képességei elég kielégítőek a fejlesztő számára, de a többi rendszergazda számára ez inkább felesleges fejfájás. A Cfengine fejlesztése érdekében külső fejlesztők hoztak létre különféle kiegészítőket, amelyek gyakran rontottak a helyzeten. A Cfengine több ilyen moduljának szerzője, Luke Kanies egy hasonló eszköz kifejlesztése mellett döntött, de a Cfengine sok hiányossága nélkül.

Báb jellemzői

A Báb, a Cfengine-hez hasonlóan, egy kliens-szerver rendszer, amely deklaratív, azaz kötelező nyelvet használ a feladatok leírására, és könyvtárat a megvalósításukra. Az ügyfelek rendszeresen (alapértelmezés szerint 30 percenként) csatlakoznak a központi szerverhez, és megkapják a legfrissebb konfigurációt. Ha a kapott beállítások nem egyeznek a rendszer állapotával, akkor végrehajtásra kerülnek, ha szükséges, a szervernek jelentést küld az elvégzett műveletekről. Az üzenetkiszolgáló menthet egy syslogba vagy fájlba, létrehozhat egy RRD grafikont, és elküldheti a megadott e-mailbe. Az Absztrakció és az Erőforrás további rétegek maximális kompatibilitást biztosítanak a meglévő beállításokkal és alkalmazásokkal, lehetővé téve a rendszerobjektumok összpontosítását anélkül, hogy aggódnia kellene a részletes parancsok és fájlformátumok megvalósításának és leírásának különbségei miatt. Az adminisztrátor csak az objektum típusával működik, a többivel a Báb gondoskodik. Tehát a csomagok típusa körülbelül 17 csomagrendszert ismer, a szükségeset automatikusan felismeri a terjesztési készlet vagy rendszer verziójára vonatkozó információk alapján, bár szükség esetén a csomagkezelő kényszeresen beállítható.

A szkriptekkel ellentétben, amelyeket más rendszereken gyakran lehetetlen használni, a harmadik fél adminisztrátorai által írt bábkonfigurációk a legkönnyebben működnek bármely más hálózaton. A Báb-CookBook-nak már három tucat kész receptje van. A Puppet jelenleg hivatalosan a következő operációs rendszereket és szolgáltatásokat támogatja: Debian, RedHat / Fedora, Solaris, SUSE, CentOS, Mac OS X, OpenBSD, Gentoo és MySQL, LDAP.

Bábnyelv

A továbblépéshez először meg kell értenie a nyelv alapvető elemeit és képességeit. A nyelv a báb egyik erőssége. Leírja azokat az erőforrásokat, amelyeket a rendszergazda tervez kezelni, és a műveleteket. A legtöbb hasonló megoldástól eltérően a Puppet programban a nyelv lehetővé teszi a heterogén környezetben lévő bármely rendszer összes hasonló erőforrásához való hozzáférés egyszerűsítését. Az erőforrás leírása általában névből, típusból és attribútumokból áll. Mutassunk például az / etc / passwd fájlra, és állítsuk be annak attribútumait:

fájl ("/ etc / passwd":

Tulajdonos => gyökér,

Csoport => gyökér,

Mód => 644,

Az ügyfelek most csatlakoznak a szerverhez, lemásolják az / etc / passwd fájlt, és beállítják a megadott attribútumokat. Több erőforrás definiálható egyetlen szabályban, pontosvesszőkkel elválasztva őket. De mi van akkor, ha a szerveren használt konfigurációs fájl eltér az ügyfélétől, vagy egyáltalán nem használja? Ilyen helyzet állhat elő például amikor VPN-beállítások-csatlakozások. Ebben az esetben a fájlra kell mutatnia a forrás irányelv használatával. Két lehetőség van itt: a szokásos módon megadhatja egy másik fájl elérési útját, valamint a két támogatott URI protokollt: fájl és báb. Az első esetben egy külső NFS-kiszolgálóra mutató hivatkozást használunk, a második lehetőségnél egy NFS-szerű szolgáltatás indul el a bábkiszolgálón, amely erőforrásokat exportál. Ez utóbbi esetben alapértelmezés szerint az útvonal a bábgyökérkönyvtárhoz viszonyítva - / etc / puppet. Vagyis a báb: //server.domain.com/config/sshd_config hivatkozás megfelel az / etc / puppet / config / sshd_config fájlnak. Ezt a könyvtárat felülírhatja a filebucket direktívával, bár helyesebb az /etc/puppet/fileserver.conf fájl azonos nevű szakaszát használni. Ebben az esetben a szolgáltatáshoz való hozzáférést csak bizonyos címekre lehet korlátozni. Írjuk le például a config szakaszt:

Path / var / báb / config

Engedélyezze a * .domain.com webhelyet

Engedélyezze a 127.0.0.1

Engedélyezze a 192.168.0. *

Engedélyezze a 192.168.1.0/24 verziót

Deny * .wireless.domain.com

Ezután erre a szakaszra hivatkozunk az erőforrás leírásakor:

forrás => "báb: //szerver.domain.com/config/sshd_config"

Az erőforrás neve a kettőspont előtt jelenik meg. A legegyszerűbb esetekben egyszerűen megadhatja a fájl teljes elérési útját névként. Bonyolultabb konfigurációknál jobb, ha álnevet vagy változókat használunk. Az álnév az álnév irányelv segítségével állítható be:

fájl ("/ etc / passwd":

Álnév => passwd

Az álnév létrehozásának egy másik lehetősége megfelelő, ha különböző operációs rendszerekkel kell megküzdenie. Hozzunk létre például egy erőforrást, amely leírja az sshd_config fájlt:

fájl (sshdconfig:

Név => $ operációs rendszer? (

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

Alapértelmezett => "/ etc / ssh / sshd_config"

Ebben a példában választás előtt állunk. A Solaris fájlja külön meg van adva, az összes többi esetén az / etc / ssh / sshd_config fájl lesz kiválasztva. Ez az erőforrás az sshdconfig néven érhető el, az operációs rendszertől függően a helyes elérési utat választja ki. Jelezzük például, hogy ha az sshd démon fut, és új fájl érkezik, akkor a szolgáltatást újra kell indítani:

szolgáltatás (sshd:

=> Igaz,

Feliratkozás => Fájl

A változókat gyakran használják, amikor felhasználói adatokkal dolgoznak. Például leírjuk a felhasználó otthoni könyvtárainak helyét:

$ homeroot = "/ home"

Most egy adott felhasználó fájljaihoz a következőképpen lehet hozzáférni:

$ (homeroot) / $ név

Exec (elérési út => "/ usr / bin: / bin: / usr / sbin: / sbin")

Abban az esetben, ha több beágyazott fájlra és könyvtárra kell mutatnia, használhatja a recurse paramétert:

fájl ("/etc/apache2/conf.d":

Forrás => "báb: // báb: //szerver.domain.com/config/apache/conf.d",

Recurse => "igaz"

Több erőforrás kombinálható osztályokba vagy definíciókba. Az osztályok egy rendszer vagy szolgáltatás teljes leírását tartalmazzák, és elkülönítve használják őket:

osztály linux (

File (

"/ etc / passwd": tulajdonos => gyökér, csoport => gyökér, mód => 644;

"/ etc / shadow": tulajdonos => gyökér, csoport => gyökér, mód => 440

class freebsd örökli a linuxot (

Fájl ["/ etc / passwd"] (csoport => kerék);

Fájl ["/ etc / shadow"] (csoport => kerék)

A kényelem érdekében minden osztály külön fájlba helyezhető, amelyet az include irányelvnek tartalmaznia kell. A definíciók több paramétert is vehetnek argumentumként, de nem támogatják az öröklést, és akkor használják őket, amikor újrafelhasználható objektumokat kell leírni. Például definiáljuk a felhasználó saját könyvtárát és az új fiók létrehozásához szükséges parancsokat:

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

Felhasználó ("$ name":

= = Jelen van,

Comment => "$ teljes név",

Gid => "$ group",

Csoportok => $ csoportok,

Tagság => minimum,

Héj => "/ bin / bash",

Főoldal => "/ home / $ név",

Require => Csoport [$ group],

Exec ("$ name homedir":

Parancs => "/ bin / cp -R / etc / skel / home / $ name; / bin / chown -R $ name: $ group / home / $ name",

Létrehoz = = "/ home / $ name",

Require => [$ name] felhasználó,

Most egy új fiók létrehozásához csak a user_homedir webhelyre kell hivatkozni:

user_homedir ("sergej":

Csoport => "sergej",

Teljes név => "Sergej Jaremchuk",

Csoportok => ["média", "admin]

Az öröklődést támogató csomópontok (csomópontok) külön leírása létezik, például az osztályok. Amikor az ügyfél csatlakozik a bábkiszolgálóhoz, megkeresi a megfelelő csomópontszakaszt, és csak a számítógépre vonatkozó beállításokat jeleníti meg. Az alapértelmezett csomópont segítségével leírhatja az összes többi rendszert. Az összes típus leírása megtalálható a "Típus hivatkozás" dokumentumban, amelyet mindenképpen meg kell ismernie, legalábbis a bábnyelv összes jellemzőjének megértése érdekében. Különböző típusok lehetővé teszik a megadott parancsok végrehajtását, többek között bizonyos feltételek teljesülése esetén (például a konfigurációs fájl megváltoztatása), a cronnal, a hitelesítő adatokkal és a felhasználói csoportokkal, a számítógépekkel, az erőforrások csatlakoztatásával, a szolgáltatások indításával és leállításával, a telepítéssel, frissítéssel és eltávolítással. csomagok, SSH kulcsokkal, Solaris zónákkal stb. Így könnyű elérni a csomagok listájának frissítését azokon a disztribúciókon, amelyek mindennap apt-t használnak 2 és 4 óra között:

menetrend (naponta:

Időszak => napi,

Tartomány =>

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

Ütemezés => naponta

Ebben az időszakban minden rendszer csak egyszer frissül, ezt követően a feladat befejezettnek tekinthető, és törlődik az ügyfélszámítógépről. A bábnyelv más ismert struktúrákat támogat: feltételeket, függvényeket, tömböket, megjegyzéseket és hasonlókat.

A Báb telepítése

A bábhoz Ruby szükséges (az 1.8.1-es és újabb verziótól) OpenSSL támogatással és XMLRPC könyvtárakkal, valamint a Gyorsabb könyvtárral. A teszt telepítéséhez használt Ubuntu 7.04 adattár már tartalmazza a kiskutya csomagot:

$ sudo apt-cache kereső báb

~ $ ruby -rxmlrpc / client -e "put: yep"

Igen

Ha nem érkezik hiba, akkor minden szükséges már benne van. A kívánt rendszerkonfigurációt leíró fájlokat báb terminológiában manifesztumoknak nevezzük. Indításkor a démon megpróbálja elolvasni az /etc/puppet/manifests/site.pp fájlt; ha hiányzik, figyelmeztető üzenetet ad ki. Teszteléskor elmondhatja a démonnak, hogy működjön benne offline ha a manifesztre nincs szükség:

$ sudo / usr / bin / puppetmasterd --nonodes

Ha szükséges, más fájlokat is csatlakoztathat a site.pp oldalhoz, például osztályleírásokkal. Tesztfuttatáshoz a legegyszerűbb utasítást adhatja meg ebben a fájlban.

osztály sudo (

Fájl ("/ etc / sudoers":

Tulajdonos => gyökér,

Csoport => gyökér,

Mód => 440,

csomópont alapértelmezett (

Tartalmazza a sudót

Az összes konfigurációs fájl, a kiszolgáló és az ügyfél is, az / etc / puppet könyvtárban található. A fileserver.conf fájl, amelyről már beszéltünk, opcionális, és csak akkor használható, ha a Puppet fájlszerverként is működik. Ubuntuban ez a fájl az / etc / puppet / files alkönyvtárat exportálja. Az ssl alkönyvtár tanúsítványokat és kulcsokat tartalmaz, amelyeket az ügyfélkapcsolatok során a titkosításhoz használnak. A gombok automatikusan létrejönnek, amikor először elindítja a puppetmasterd programot, ezeket manuálisan létrehozhatja a következő paranccsal:

$ sudo / usr / bin / puppetmasterd --mkusers

A puppetd.conf és a puppetmasterd.conf fájlok hasonlóak. Megadják a démonok működésének néhány paraméterét az ügyfélrendszeren és a kiszolgálón. Az ügyfélfájl csak a kiszolgálóparaméter jelenlétében különbözik, amely arra a számítógépre mutat, amelyen a puppetmasterd fut:

szerver = daráló.com

logdir = / var / log / báb

vardir = / var / lib / báb

rundir = / var / run

# jelentést küld a szervernek

jelentés = igaz

Annak elkerülése érdekében, hogy mindent kézzel írja be, létrehozhat egy sablont a puppetd használatával:

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

Hasonlóképpen létrehozhatja a site.pp fájlt a szerveren:

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

Egy másik fájl, a tagmail.conf lehetővé teszi, hogy meghatározza azokat az e-mail címeket, amelyekre a jelentéseket elküldjük. A legegyszerűbb esetben egy sort használhat:

minden: [e-mail védett]

Nincs elég konfigurációs fájl az ügyfél számára a szerverhez való csatlakozáshoz. Ehhez igazolásokat is alá kell írnia.

Először is, hogy a kiszolgáló tudjon az új számítógépről, az ügyfélrendszeren írja be a következő parancsot:

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

A tűzfalnak engedélyeznie kell a kapcsolatot a 8140-es porton.

A szerveren kapunk egy listát az aláírandó tanúsítványokról:

$ sudo puppetca –lista

nomad.grinder.com

És aláírjuk az ügyfél tanúsítványát:

$ sudo puppetca –sign nomad.grinder.com

Most az ügyfél szabadon csatlakozhat a szerverhez és megkapja a beállításokat.

Sajnos a cikk határain belül lehetetlen megmutatni a Báb minden tulajdonságát. De amint láthatja, ez egy funkcionális és rugalmas eszköz, amely lehetővé teszi a legtöbb rendszer egyidejű adminisztrációjának legtöbb feladatát. És ami a legfontosabb: a projektnek sikerült egy kicsi, de folyamatosan növekvő közösséget összegyűjteni. Reméljük tehát, hogy egy jó ötletnek nem szabad meghalnia vagy elsodródnia.

Sok szerencsét!

A BladeLogic projekt webhelye: http://www.bladelogic.com.
Az OpsWare projekt webhelye: http://www.opsware.com.
A Cfengine projekt honlapja: http://www.cfengine.org.
A Báb projekt webhelye: http://reductivelabs.com/projects/puppet.
Bábos szakácskönyv - http://www.reductivelabs.com/trac/puppet/tagspuppet%2Crecipe.
Gyorsabb könyvtár -