Puppet szerver telepítés és konfigurálás. Telepítse a puppetet, és hozza létre az első jegyzéket. A Bash-paraméterek teljes listája a Puppet-kliens inicializálási parancsfájljához

Nem sokkal ezelőtt a magazin oldalain megnéztük a rendszert távirányító Cfengine UNIX gépkonfiguráció, ami sokkal könnyebbé teszi az életet rendszergazda több hálózati csomópont konfigurálásához szükséges lépések automatizálásával. De bármennyire is kényelmes a Cfengine, számos hátránya van, amivel a Puppet nevű rendszer nem rendelkezik.

Képzelje el magát a rendszergazda szerepében, aki több száz UNIX típusú operációs rendszert futtató gép funkcionalitásának karbantartásáért felelős. Mindegyikük konfigurációt, időszakos frissítést és felügyeletet igényel, és feltételezhető, hogy sok közülük hasonló funkciókat lát el.

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

A szkripteket folyamatosan módosítani kell, 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 hibakeresni kell őket, mielőtt futó gépekre alkalmaznák őket. Általában véve nem comme il faut. A helyes válasz az úgynevezett távoli konfigurációkezelő rendszerek használata, amelyek leghíresebb képviselői nyílt rendszerek Cfengine és Báb. Az ilyen rendszerek minden felelősséget magukra vállalnak azért, hogy a gép konfigurációját a kívánt formára hozzák, így az adminisztrátornak csak egy speciális nyelven kell leírnia a rendszer végső állapotát (például, hogy milyen csomagokat kell telepíteni az operációs rendszerbe, sorokat kell hozzáadni a konfigurációs fájlokhoz, mely parancsokat kell végrehajtani stb.). Ezt követően az összes csomópont információt kap 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 konfigurálhatók, a meglévők pedig újrakonfigurálhatók, ha az állapotleíráshoz csak néhány sort kell hozzáadni.

Báb?

Már egy egész cikket szenteltünk a Cfengine-rendszernek, így ma a Puppet-rendszerre fogunk összpontosítani, amelyet nyugodtan nevezhetünk ideológiai utódjának. A Puppet Luke Kanies fejlesztette ki, aki belefáradt Cfengine korlátaiba, és úgy döntött, hogy a semmiből készít egy jobb verziót. Ha már használta a Cfenfine-t, a Puppet valószínűleg kényelmesebb és erősebb rendszernek fogja találni. A Puppet államnyelve magasabb szintű és rugalmasabb, ami azt jelenti, hogy a rendszergazdának nem kell aggódnia olyan dolgok miatt, mint például az egyes operációs rendszer típusokhoz külön szabályok írása vagy Részletes leírás triviális cselekvések végrehajtása. A Puppet lehetővé teszi, hogy a mestere arra összpontosítson, hogy mit szeretne csinálni, ahelyett, hogy hogyan tegye (például egy adott csomag telepítéséhez a rendszer által támogatott operációs rendszerek bármelyikére, csak szó szerint kell írnia néhány sort a következővel: "Telepítse ezt a programot " a telepítéshez szükséges parancsok leírása helyett). Puppet be van írva egyszerű nyelven Ruby, ami megkönnyíti az adott feladathoz való igazítását és funkcionalitásának bővítését (rugalmas plugin-rendszer biztosított).

Ezenkívül a Cfengine fejlesztési modelljével ellentétben, amely lényegében egy személy körül forog, a Puppet rajongók nagy közösségével rendelkezik, akik fejlesztéseket hajtanak végre a kódon, megosztanak konfigurációs példákat, és dokumentumokat írnak.

Összességében a Puppet modernebb és kifinomultabb rendszernek tűnik jó design. A Cfengine-hez hasonlóan szinte az összes modern UNIX-szerű operációs rendszert támogatja (beleértve a MacOS X-et is), és a Windows tetején a Cygwin környezetben is futhat. A függőségi listája csak a Ruby interpretert és a Factor eszközt tartalmazza, így nem lehet gond a telepítéssel (az igazság kedvéért a Cfengine függőségi listája még rövidebb).

Telepítés

A Cfengne-hez hasonlóan a Puppet is egy kliens-szerver rendszer, amely vezérlőszerverből és szolga csomópontokból áll. A kiszolgáló eltárolja a csomópontok végső állapotának leírását (amit bábnyelven manifestnek neveznek), és várja, hogy csatlakozzanak. A kliens félóránként (alapértelmezés szerint) csatlakozik a szerverhez, megkapja onnan a végleges állapot leírását, összehasonlítja a jelenlegivel és ha az és/vagy a leírt állapot megváltozott, újrakonfigurálja a rendszert, majd elmegy aludni. A kommunikáció titkosított csatornán keresztül történik, így az állapotleírás helyettesítésén alapuló támadások kizártak (de ha egy támadó átveszi a szervert, akkor minden csomópont az ő irányítása alá kerül).

A Puppet az összes népszerű disztribúció tárházában megtalálható, így a telepítése nem lehet nehéz. Például Debian/Ubuntu alatt a Puppet kliens a következőképpen telepíthető:

$ sudo apt-get install puppet

A szerver pedig ilyen:

$ sudo apt-get install puppet puppetmaster

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

Az állapotok leírását tárolja, és csak a szerveren kell léteznie. A hibakeresés megkönnyítése érdekében adjunk hozzá egy egyszerű konfigurációt:

class passwd(
file("/etc/passwd":
tulajdonos => root,
csoport => gyökér,
mód => 644,
}
}
csomópont alapértelmezett (
tartalmazza a passwd
}

Ezek a sorok azt az állapotot írják le, amelyben az /etc/passwd fájl tulajdonosának root-nak kell lennie, és az engedélyei 644-re vannak beállítva. A következő részben részletesebben megvizsgáljuk a manifest fájlformátumot. A második legfontosabb fájl az /etc/puppet/puppet.conf. Beállítja a szerver és a kliensek konfigurációját, így minden, a Puppet hálózatban szervezett gépen jelen kell lennie. Az Ubuntuban ez a fájl tartalmazza a minimálisan szükséges és a legtöbb esetben elegendő beállításokat. Az alábbiakban megjegyzésekkel együtt közöljük őket:

# vi /etc/puppet/puppet.conf
# Szabványos könyvtár elérési utak
logdir=/var/log/puppet
vardir=/var/lib/puppet
ssldir=/var/lib/puppet/ssl
rundir=/var/run/puppet
# Tényező szerszám helye,
# az operációs rendszerrel kapcsolatos információk beszerzésére szolgál
factpath=$vardir/lib/facter
# Beépülő modulok szinkronizálása
# (telepített beépülő modulok a kiszolgálón – átmásolódnak a kliensekre)
pluginsync=true
# Katalógus sablonokkal (alább olvashat róluk)
templatedir=$confdir/templates
# Szinkronizálás az etckeeper-vel
# (aki tudja, megérti, másoknak nem kell)
prerun_command=/etc/puppet/etckeeper-commitpre
postrun_command=/etc/puppet/etckeeper-commitpost

A konfigurációs fájl nagyszámú különböző beállítást tartalmazhat, amelyekről információkat kaphat egy alapértelmezett konfiguráció létrehozásával:

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

Az alapértelmezett ügyfélkonfiguráció egy másik paranccsal jön létre:

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

A konfigurációhoz Fileserver.conf és auth.conf fájlokat használnak fájlszerver(erről a „Fájlkiszolgáló” részben olvashat) és a hitelesítés. Még nincs értelme hozzájuk nyúlni. A konfiguráció befejezése után a Puppet szervert újra kell indítani:

$ sudo /etc/init.d/puppetmaster újraindítás

Ezt követően készen áll az ügyfelek kérésének fogadására. Aláírt tanúsítvány nélkül azonban egyetlen ügyfél sem tudja fogadni a jegyzéket a kiszolgálótól és konfigurálni a gépet.

Ezért a Puppet klienseket teszt módban kell futtatnunk, hogy el tudják küldeni a tanúsítványaikat a szervernek aláírásra (ez egyébként az shmux eszközzel minden gépen megtehető egyszerre):

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

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 ki egy gazdagépet a listából, és írja alá a tanúsítványát:

$ sudo puppetca --sign nomad.grinder.com

Vagy írunk alá mindent egyszerre:

$ sudo puppetca --sign --all

Most már elindíthatja az ügyfeleket harci módban. De először meg kell adnia a Puppet szerver nevét a konfigurációs fájlban (alapértelmezés szerint a neve egyszerűen puppet):

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

Ügyfelek elindítása:

$ sudo /etc/init.d/puppet start

Állítsa le a leírás nyelvét

Ahogy fentebb említettük, a Puppet a saját nyelvét használja a végső állapot leírására operációs rendszer, melynek segítségével a rendszergazda jelzi, hogy az operációs rendszer komponenseit milyen formába kell vinni, hogy az elérje a kívánt állapotot. Ez egy meglehetősen összetett nyelv, amely azonban sokkal egyszerűbb, mint bármely programozási nyelv. Ha legalább felületesen ismeri a bash szkriptnyelvet, könnyen megérti a Puppet nyelvet. A nyelv kulcsfontosságú eleme az erőforrások, amelyek segítségével leírják, hogy az operációs rendszer egyik összetevőjét milyen formára kell konvertálni. Például a következőket legegyszerűbb erőforrás leírja az /etc/passwd fájl kívánt állapotát:

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

Itt a fájl az erőforrás típusa. Összesen több tucat van belőlük, kezdve a fájlokat kezelő erőforrásoktól, mint ebben a példában, a csomagokig és szolgáltatásokig. 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, de néhány más típusnál a név tetszőleges lehet. A tulajdonos => "root" sor leírja, hogy a tulajdonos attribútumot root-ra kell állítani, vagyis azt mondja, hogy a tulajdonos megadott fájl kell lennie egy rendszergazdának.

Minden erőforrástípusnak megvan a saját attribútumkészlete, amely módosítható, valamint vannak speciális metaattribútumok, amelyek bármely erőforrásban használhatók. Az erőforrások egyik fontos tulajdonsága a hozzájuk való kapcsolódás képessége. Ez felhasználható függőségi láncok kialakítására. A következő bejegyzés létrehozza az /etc/group erőforrást, amely az /etc/passwd erőforrástól függ (a függőségek a request meta attribútum használatával vannak megadva):

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

Ez azt jelenti, hogy az /etc/group erőforrás csak az /etc/passwd erőforrás konfigurálásával állítható be (a leírt formába hozható). Az erőforrások osztályoknak nevezett erőforrás-gyűjteményekbe csoportosíthatók. Erre azért van szükség, hogy egy absztrakt erőforrásba egyesítsék a jelentésükben és az elvégzett feladattípusban hasonló erőforrásokat. Például a kényelem kedvéért kombinálhatjuk az nginx webszerver telepítését és elindítását egyetlen, azonos nevű absztrakt erőforrásba:

# vi /etc/puppet/manifests/site.pp
osztály nginx(
csomag ("nginx":
biztosítsa => telepítve
}
service ("nginx":
biztosítsd => futás,
igényel => Package["nginx"],
}
}

Itt a csomag erőforrás típusa az nginx csomag telepítésére szolgál a rendszerre, a szolgáltatás pedig az azonos nevű szolgáltatás elindítására. A követelménynél csak a csomag sikeres telepítése esetén kényszerítjük a rendszert a szolgáltatás elindítására. Az osztályok kényelme az, hogy a következőktől függően is szerepelhetnek:

# vi /etc/puppet/manifests/site.pp
service ("tintahal":
biztosítsd => futás,
igényel => Class ["nginx"],
}

A valódi OOP nyelvekhez hasonlóan az osztályok örökölhetik egymást, és felülírhatják az attribútumokat:

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

Itt a passwd-bsd osztály a passwd-ből örökölve felülírja az /etc/passwd erőforrás group attribútumait (BSD rendszereken az /etc/passwd a kerékcsoporthoz tartozik, ezért az ilyen rendszerek számára külön osztályt hoztunk létre). Később megvizsgáljuk az alternatív attribútumértékek feltételekkel történő kiválasztásának pontosabb és kézenfekvőbb módját.

A változók bármely programozási nyelv szerves részét képezik, és a Puppet is rendelkezik velük. A változók $ jellel kezdődnek, és bármilyen számot, karakterláncot vagy logikai értéket tartalmazhatnak (igaz, hamis):

$want_apache = igaz
$apache_version = "2.2.14"

A Puppet egyik legerősebb, változókkal kapcsolatos funkciója a Faktorgép-információs eszközzel való integráció. Ez a segédprogram az összes gépspecifikus információt kulcs-érték párok formájában adja vissza, amelyeket a Puppetben azonos nevű változókká alakítanak. A Puppet nyelv feltételes utasításaival 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 az operációs rendszer típusától függően automatikusan válasszon egy attribútumot (anélkül, hogy magára az osztályra lenne szükség):

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

Attól függően, hogy a jegyzék ezen töredéke melyik operációs rendszeren kerül elemzésre, a group attribútum értéke root vagy wheel lesz. A feltételes operátoron kívül a Puppet nyelv támogatja az esetkiválasztó operátort is, amellyel egy változó értékétől függően egy adott erőforrást lehet létrehozni:

# vi /etc/puppet/manifests/site.pp
eset $operációs rendszer (
redhat: (service("httpd": biztosítsa => futás))
debian: (service("apache": biztosítsa => futás))
default: ( service ( "apache2": biztosítsa =>
futás))
}

Ez a kód határozza meg különféle lehetőségeket erőforrás típusú szolgáltatás az operációs rendszertől függően (a szolgáltatások neve a különböző Linux disztribúciókban eltérhet, ezért mindegyiknél külön kell megadni, hogy a Puppet melyik szolgáltatást futtassa).

Az alapértelmezett beállítást akkor használjuk, ha a változó értéke nem egyezik az előző opciók egyikével sem. A korábban tárgyalt fájl-, csomag- és szolgáltatás-erőforrás-típusokon kívül a Puppet számos egyéb erőforrástípust is támogat, beleértve a külső fejlesztők által létrehozottakat is. Részletes leírásuk, beleértve a példákat, a támogatott attribútumokat és funkciókat, megtalálható a hivatalos dokumentációban - http://docs.puppetlabs.com/references/stable/type.html. Az alábbiakban egy lista és Rövid leírás a leggyakrabban használtak a következők:

Népszerű Puppet erőforrástípusok

• cron - cron feladatok kezelése
• exec - szkriptek és parancsok futtatása
• fájl - fájlkezelés
• filebucket - biztonsági mentés fájlokat
• csoport - csoportkezelés
• host - az /etc/hosts fájl bejegyzéseinek kezelése
• interfész - hálózati interfészek konfigurálása
• mount - fájlrendszerek csatlakoztatása
• értesíteni - üzenet küldése a Puppet naplófájlba
• csomag – csomagkezelés
• szolgáltatás – szolgáltatásmenedzsment
• sshkey - SSH kulcsok kezelése
• tidy - fájlok törlése a feltételektől függően
• felhasználó - felhasználó kezelés
• zónák - Solaris zónakezelés

A Puppet nyelv második legfontosabb eleme az erőforrások után a csomópontok. Segítségükkel az adminisztrátor le tudja írni, hogy bizonyos erőforrásokat, osztályokat mely gépekre kell alkalmazni. Más szóval, ez egy módja annak, hogy egyedi konfigurációt adjunk meg a Puppet hálózatban részt vevő minden egyes géphez. A csomópont legegyszerűbb példája a cikk elején található, a „Telepítés” részben:

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

Ez az alapértelmezett csomópont meghatározása, amely tartalmazza a passwd erőforrást/osztályt. Az alapértelmezett név "minden többi csomópontot" jelent, így a valahol fent meghatározott passwd erőforrás/osztály mindegyiken be lesz állítva. Itt az include kulcsszót használjuk a kényelem érdekében; valójában 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értelmezetten kívül a csomópontnévben is megadható hálózat neve gép (akkor a csomópontban leírt összes erőforrás csak ezen a gépen lesz konfigurálva), vagy tetszőleges név (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 osztályokkal és erőforrásokkal, nézzünk meg egy példát egy kész Puppet jegyzékre, amelyet két hálózati gép (egy webszerver és egy NTP-szerver) konfigurálására használnak:

# vi /etc/puppet/manifests/site.pp
# SSH-kiszolgáló telepítése és futtatása
osztály sshd(
csomag (openssh-server: biztosítsa => telepítve)
szolgáltatás (sshd:
név => $operációs rendszer ? (
fedora => "sshd",
debian => "ssh",
alapértelmezett => "sshd",
},
engedélyezés => igaz,
biztosítsd => futás,
}
}
# Telepítse és futtassa az Apache-t
osztály httpd(
csomag ( httpd: biztos => telepítve)
szolgáltatás (httpd:
engedélyezés => igaz,
biztosítsd => futás,
}
}
# NTP szerver telepítése és indítása
class ntpd(
csomag (ntp-szerver: biztosítsa => telepítve)
szolgáltatás (
ntp-szerver:
engedélyezés => igaz,
biztosítsd => futás,
}
}
# Az alapcsomópont, csak az összes többi szülőjeként használható
csomópont alap (
tartalmazza az sshd-t
}
# A csomópont, ahol a webszerver található
csomópont web.server.com örökli az alap (
tartalmazza a httpd
}
# NTP szerver csomópont
node ntp.server.com örökli az alap (
tartalmazza az ntpd
}

Ez az egyszerűnek tűnő konfiguráció elég sok mindent megtesz: telepíti és futtatja az Apache-t a gépen a web.server.com címen, és egy NTP-kiszolgálót telepít és fut a gépen. ntp.server.com. Ezenkívül mindkét gép SSH-kiszolgálót telepít. Ez a konfiguráció valószínűleg még egy rendszergazdának sem felel meg; komoly fejlesztésre szorul, hogy megtanítsuk megfelelően konfigurálni a szervereket, kapni friss konfigurációkat és egyéb fájlokat a fő Puppet szerverről.

Viszont jól mutatja a Báb erejét. Egy egyszerű konfig segítségével a gépeket maguktól telepítettük és futtattuk a szükséges szoftvereket, és karbantartottuk azt (ha a szerver összeomlik, a Puppet maga konfigurálja át a rendszereket a kívánt állapotba).

Fájlszerver

Sok távoli adminisztrációs feladat nem oldható meg gépekre másolás nélkül további fájlok. Ezek lehetnek előre elkészített konfigurációk, Apache weboldalak, a hivatalos tárolóban nem szereplő csomagok és még sok más. A fájlok távoli gépekre való átvitelének megkönnyítése érdekében a Puppet tartalmaz egy fájlszervert.

A fájlszerver beállításai az /etc/puppet/fileserver.conf fájlban tárolódnak. Ha arra kényszeríti a Puppet-ot, hogy egy adott könyvtár tartalmát kiszolgálja az ügyfeleknek, néhány sort kell beleírnia:

# vi /etc/puppet/fileserver.conf
elérési út = /var/puppet/files
*.server.com engedélyezése

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 gépe számára. Ezen kívül jelezhetjük a teljes Domain név engedélyezett gépet vagy annak IP-címét, valamint levágja a nem kívántakat a deny direktíva segítségével. A könyvtárban lévő bármely fájl áthelyezhető a kliensre a fájlerőforrás használatával. Például:

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

A kiszolgálón a /var/puppet/files/httpd könyvtárban található httpd.conf fájl a célgépre másolódik az erőforrás nevében megadott útvonalon.

következtetéseket

Ebben a cikkben a Puppet képességeinek egy nagyon kis részét ismertetjük. Valójában ez egy összetett rendszer, amelyet csak egy könyv lapjain lehet teljes mértékben leírni. Ugyanakkor a Puppet nagyon könnyen konfigurálható és karbantartható, különösen azért, mert számos példát találhatunk a konfigurációjára a weben.

Info

• A Puppet HTTP protokollt használ, így a teljesítmény javítása érdekében webszerver alatt is futtatható.
• A Puppet egyetlen helyi gép automatikus konfigurálására és karbantartására használható.
• A Puppet kombinálásával, hálózati telepítés Az operációs rendszer (pxe-install) és az önállóan összeállított telepítőkészletek segítségével egy teljesen önkonfiguráló géphálózatot hozhat létre, amely egyetlen paranccsal telepíthető.
• Sokan használják a Puppet-ot munkájuk során. nagy cégek, mint például a Google, a Fedora Project, a Stanford 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

Szergej Jaremcsuk

UNIX rendszerek központi konfigurálása Puppet segítségével

Ellenőrzés nagy mennyiség A UNIX rendszerek nem nevezhetők kényelmesnek. Egy paraméter megváltoztatásához az adminisztrátornak fel kell vennie a kapcsolatot minden géppel, a szkriptek csak részben tudnak segíteni, és nem minden helyzetben.

Ezt el kell ismerni Windows rendszergazdák-a hálózatok még mindig előnyösebb helyzetben vannak. Csak módosítsa a beállításokat csoportszabályzat, é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 rendszert is, „megtanulja” az újítást, természetesen, ha az őket érinti. Ha visszatekintünk a UNIX fejlesztés hosszú időszakára, láthatjuk, hogy soha semmi ilyesmi 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 fejlesztés jelentős erőfeszítést igényel. A kereskedelmi megoldások, mint 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, fő előnyük a grafikus felület jelenléte, amelyek megvásárlását csak a nagy szervezetek engedhetik meg maguknak. Vannak persze ingyenes megoldásokat kínáló projektek, de fennállásuk során nem tudtak nagy közösséget létrehozni. Például a Cfengine nem túl népszerű a rendszergazdák körében, bár a Linuxon kívül *BSD, Windows és Mac OS X alatt is használható. Ennek oka lehet a konfigurációk létrehozásának viszonylagos bonyolultsága. A feladatok leírásánál figyelembe kell venni az egyes konkrét rendszerek jellemzőit, és a parancsok végrehajtása során kézzel kell vezérelni a műveletek sorrendjét. Vagyis az adminisztrátornak emlékeznie kell arra, hogy egyes rendszerek esetében adduser-t kell írnia, másoknak pedig - useradd, vegye figyelembe a fájlok helyét a különböző rendszerek stb. Ez nagyságrenddel megnehezíti a parancsok írását, nagyon nehéz menet közben elkészíteni a megfelelő konfigurációt, és szinte lehetetlen egy idő után elolvasni a létrehozott konfigurációkat. A GPL licenc ellenére a Cfengine lényegében egy egyszemélyes projekt, aki minden változást irányít, és nem nagyon érdekli a nyitott társadalom építése. Ennek eredményeként a Cfengine képességei eléggé kielégítőek a fejlesztő számára, de a többi rendszergazdának ez inkább plusz fejfájást jelent. A Cfengine fejlesztésére különféle kiegészítőket készítettek külső fejlesztők, amelyek gyakran csak rontottak a helyzeten. A Cfengine több ilyen moduljának szerzője, Luke Kanies végül úgy döntött, hogy kifejleszt egy hasonló eszközt, de a Cfengine számos hiányossága nélkül.

A báb jellemzői

A Puppet, a Cfengine-hez hasonlóan, egy kliens-szerver rendszer, amely deklaratív nyelvet használ a feladatok leírására és a megvalósításukhoz szükséges könyvtárakat. Az ügyfelek rendszeresen (alapértelmezés szerint 30 percenként) csatlakoznak a központi szerverhez, és megkapják a legújabb konfigurációt. Ha a kapott beállítások nem egyeznek a rendszer állapotával, akkor azok végrehajtásra kerülnek, és szükség esetén jelentést küldenek a szervernek az elvégzett műveletekről. Az üzenetszerver elmentheti syslogba vagy fájlba, létrehozhat RRD gráfot, elküldheti a címre megadott e-mail címre. A további tranzakciós és erőforrás-absztrakciós rétegek maximális kompatibilitást biztosítanak a meglévő beállításokkal és alkalmazásokkal, lehetővé téve, hogy a rendszerobjektumokra összpontosítson anélkül, hogy aggódnia kellene a megvalósítási és leírási különbségek miatt. részletes parancsokatés fájlformátumok. Az adminisztrátor csak az objektumtípussal dolgozik, a többiről a Puppet gondoskodik. Így a csomagtípus 17 csomagrendszert tud, a szükséges automatikusan felismerésre kerül a disztribúció vagy a rendszer verziójára vonatkozó információk alapján, bár szükség esetén a csomagkezelőt is be lehet állítani kényszerből.

Ellentétben a szkriptekkel, amelyek gyakran nem használhatók más rendszereken, a külső rendszergazdák által írt Puppet konfigurációk többnyire probléma nélkül működnek bármely más hálózaton. A Puppet CookBook már három tucat kész recepttel rendelkezik. 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 értened a nyelv alapvető elemeit és képességeit. A nyelv az egyik erősségeit Báb. Leírja azokat az erőforrásokat, amelyeket az adminisztrátor kezelni kíván, és az általuk végrehajtott műveleteket. A legtöbbtől eltérően hasonló döntéseket, A Puppet nyelve megkönnyíti az összes hasonló erőforrás elérését bármely rendszeren heterogén környezetben. Az erőforrás leírása általában egy névből, típusból és attribútumokból áll. Például mutassunk az /etc/passwd fájlra, és állítsuk be az attribútumait:

file("/etc/passwd":

Tulajdonos => gyökér,

Csoport => gyökér,

Mód => 644,

Most a szerverhez csatlakozó kliensek átmásolják az /etc/passwd fájlt, és beállítják a megadott attribútumokat. Egy szabályban több erőforrást is megadhat, pontosvesszővel elválasztva őket. De mi van akkor, ha a szerveren használt konfigurációs fájl eltér a klienstől, vagy egyáltalán nem használják? Például ez a helyzet akkor állhat elő, ha VPN beállítások- kapcsolatok. Ebben az esetben a forrás direktívával kell a fájlra mutatni. Itt két lehetőség van: szokás szerint megadhatja egy másik fájl elérési útját, és a két támogatott URI protokollt is használhatja: a fájlt és a bábot. Az első esetben egy külső NFS-kiszolgálóra mutató hivatkozást használnak, a második lehetőségnél pedig egy NFS-szerű szolgáltatás indul a Puppet szerveren, amely erőforrásokat exportál. Az utóbbi esetben az alapértelmezett elérési út a báb gyökérkönyvtárához – /etc/puppet – relatív. Vagyis a puppet://server.domain.com/config/sshd_config hivatkozás az /etc/puppet/config/sshd_config fájlnak felel meg. 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 korlátozhatja. Például írjuk le a konfigurációs részt:

Elérési út /var/puppet/config

*.domain.com engedélyezése

127.0.0.1 engedélyezése

192.168.0.* engedélyezése

192.168.1.0/24 engedélyezése

Megtagadás *.wireless.domain.com

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

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

A kettőspont előtt az erőforrás neve. A legegyszerűbb esetekben egyszerűen megadhatja névként a fájl teljes elérési útját. Bonyolultabb konfigurációkban jobb álnevet vagy változókat használni. Az alias az alias direktívával van beállítva:

file("/etc/passwd":

Alias ​​=> passwd

Egy másik lehetőség az álnév létrehozására akkor jó, ha különböző operációs rendszerekkel kell foglalkoznia. Például hozzunk létre 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ájlt külön kell megadni, az összes többi esetében az /etc/ssh/sshd_config fájl kerül kiválasztásra. Ez az erőforrás most sshdconfig néven érhető el, attól függően, hogy melyik operációs rendszer kerül kiválasztásra a helyes utat. Például vegyük észre, hogy ha az sshd démon fut és fogad új fájl, újra kell indítania a szolgáltatást:

szolgáltatás (sshd:

Biztosítsd, hogy => igaz,

Feliratkozás => Fájl

A változókat gyakran használjuk a felhasználói adatokkal való munka során. Például leírjuk a felhasználói kezdőkönyvtárak helyét:

$homeroot = "/home"

Most pedig a fájlokhoz konkrét felhasználó címezhető:

$(homeroot)/$név

A $name paraméter a felhasználói fiók nevével lesz kitöltve. Egyes esetekben célszerű alapértelmezett értéket megadni bizonyos típusokhoz. Például az exec típusnál nagyon gyakori, hogy megadják azokat a könyvtárakat, amelyekben a végrehajtható fájlt keresni kell:

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

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

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

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

Recurse => "igaz"

Több erőforrás kombinálható osztályokká vagy definíciókká. Az osztályok egy rendszer vagy szolgáltatás teljes leírását jelentik, és külön használatosak:

osztályú linux (

Fájl (

"/etc/passwd": tulajdonos => root, group => root, mode => 644;

"/etc/shadow": tulajdonos => root, group => root, mode => 440

Az objektum-orientált nyelvekhez hasonlóan az osztályok felülbírálhatók. Például a FreeBSD-n ezen fájlok csoporttulajdonosa a wheel. Ezért, hogy ne írjuk át teljesen az erőforrást, hozzunk létre új osztály freebsd, amely örökli a linux osztályt:

osztály freebsd örökli a linuxot (

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

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

A kényelem kedvéért minden osztály behelyezhető külön fájl, amelyet az include direktívának kell tartalmaznia. A definíciók több paramétert is használhatnak argumentumként, de nem támogatják az öröklődést, és akkor használatosak, ha újrafelhasználható objektumokat kell leírni. Például határozzuk meg a felhasználó kezdőkönyvtárát és az új fiók létrehozásához szükséges parancsokat:

definiálja a user_homedir ($csoport, $teljesnév, $csoportok) (

User("$name":

Biztosítsa => jelen,

Megjegyzés => "$teljes név",

Gid => "$csoport",

Csoportok => $ingroups,

Tagság => minimum,

Shell => "/bin/bash",

Home => "/home/$name",

Require => Group[$group],

Exec("$name homedir":

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

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

Require => User[$name],

Most újat kell létrehozni fiókot, lépjen kapcsolatba a user_homedirrel:

user_homedir("szergej":

Csoport => "szergej",

Teljes név => "Sergej Jaremchuk",

Ingroups => ["media", " admin]

Külön leírások vannak az öröklődést támogató csomópontokról, valamint az osztályokról. Amikor egy kliens csatlakozik a Puppet szerverhez, a rendszer megkeresi a megfelelő csomóponti részt, és csak erre a számítógépre vonatkozó beállításokat biztosítja. Az összes többi rendszer leírásához használhatja az alapértelmezett csomópontot. Minden típus leírása megtalálható a „Típushivatkozás” dokumentumban, amelyet minden esetben el kell olvasni, legalább a Puppet nyelv minden képességének megértéséhez. Különféle típusok lehetővé teszi meghatározott parancsok végrehajtását, beleértve bizonyos feltételek teljesülését (például konfigurációs fájl módosítása), cron, felhasználói hitelesítő adatok és csoportok, számítógépek, erőforrások csatlakoztatása, szolgáltatások elindítása és leállítása, csomagok telepítése, frissítése és eltávolítása, munkavégzés SSH-kulcsokkal, Solaris-zónákkal stb. Így kényszerítheted ki az apt segítségével, hogy a disztribúciókban lévő csomagok listája naponta 2 és 4 óra között frissüljön:

menetrend (napi:

Időszak => naponta,

Tartomány =>

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

Menetrend => naponta

Az adott időszakra vonatkozó frissítést minden rendszer csak egyszer hajtja végre, ezután a feladat befejezettnek minősül, és törlődik az ügyfélszámítógépről. A Puppet nyelv más ismert struktúrákat is támogat: feltételeket, függvényeket, tömböket, megjegyzéseket és hasonlókat.

A Puppet telepítése

A Puppet alkalmazáshoz Ruby (1.8.1 és újabb verzió) szükséges OpenSSL támogatással és XMLRPC könyvtárakkal, valamint a Faster könyvtárral. A teszttelepítéshez használt Ubuntu 7.04 adattár már tartalmazza a puppy csomagot:

$ sudo apt-cache kereső báb

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

Ha nem érkezik hiba, akkor már mindent tartalmaz, amire szüksége van. A rendszer kívánt konfigurációját leíró fájlokat a Puppet terminológiában manifeszteknek nevezzük. Indításkor a démon megpróbálja beolvasni az /etc/puppet/manifests/site.pp fájlt; ha hiányzik, figyelmeztető üzenetet jelenít meg. Teszteléskor megmondhatja a démonnak, hogy önálló módban fusson, amely nem igényel manifestet:

$ sudo /usr/bin/puppetmasterd --nonodes

Ha szükséges, más fájlokat is csatlakoztathat a site.pp-hez, például osztályleírásokkal. Próbaüzemhez megadhatja a legegyszerűbb utasításokat ebbe a fájlba.

osztály sudo(

Fájl("/etc/sudoers":

Tulajdonos => gyökér,

Csoport => gyökér,

Mód => 440,

csomópont alapértelmezett (

Tartalmazza a sudo-t

Minden konfigurációs fájl, a szerver és a kliens is, az /etc/puppet könyvtárban található. A fileserver.conf fájl, amelyről már beszéltünk, nem kötelező, és csak akkor használható, ha a Puppet fájlszerverként is működik. Ubuntun ez a fájl az /etc/puppet/files alkönyvtárat exportálja. Az ssl alkönyvtár olyan tanúsítványokat és kulcsokat tartalmaz, amelyeket a titkosításhoz használunk az ügyfelek csatlakoztatásakor. A kulcsok automatikusan jönnek létre a puppetmasterd első indításakor; manuálisan is létrehozhatja őket a következő paranccsal:

$ sudo /usr/bin/puppetmasterd --mkusers

A puppetd.conf és a puppetmasterd.conf fájlok hasonlóak. Megjelölnek néhány paramétert a démonok működéséhez a kliens rendszeren és a szerveren. Az ügyfélfájl csak a jelenlétében különbözik szerver paraméter, a puppetmasterd programot futtató számítógépre mutatva:

szerver = grinder.com

logdir = /var/log/puppet

vardir = /var/lib/puppet

rundir = /var/run

# küldjön jelentést a szervernek

jelentés = igaz

Annak elkerülése érdekében, hogy mindent kézzel gépeljen 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 tagmail.conf fájl lehetővé teszi a megadását postacímek, amelyre a jelentéseket küldjük. A legegyszerűbb esetben egy sort használhat:

minden: [e-mail védett]

A konfigurációs fájlok nem elegendőek ahhoz, hogy az ügyfél csatlakozzon a szerverhez. Ehhez a tanúsítványokat is alá kell írni.

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

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

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

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

$ sudo puppetca –list

És írja alá az ügyféltanúsítványt:

$ sudo puppetca –sign nomad.grinder.com

Mostantól a kliens szabadon csatlakozhat a szerverhez és fogadhatja a beállításokat.

Sajnos a cikkben lehetetlen bemutatni a Puppet összes képessé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ával kapcsolatos problémák megoldását. És ami a legfontosabb, a projektnek sikerült egy kicsi, de folyamatosan növekvő közösséget összegyűjtenie. Ezért reménykedjünk abban, hogy egy jó ötlet nem hal el vagy félremegy.

Sok szerencsét!

1. BladeLogic projekt weboldala – http://www.bladelogic.com.
2. Az OpsWare projekt webhelye: http://www.opsware.com.
3. A Cfengine projekt honlapja: http://www.cfengine.org.
4. A Puppet projekt weboldala: http://reductivelabs.com/projects/puppet.
5. Puppet CookBook – http://www.reductivelabs.com/trac/puppet/tagspuppet%2Crecipe.
6. Gyorsabb könyvtár –

A nagyszámú Unix rendszer kezelése nem nevezhető kényelmesnek. Egy paraméter megváltoztatásához az adminisztrátornak fel kell vennie a kapcsolatot minden géppel, a szkriptek csak részben tudnak segíteni, és nem minden helyzetben.

Fel kell ismerni, hogy az adminisztrátorok Windows hálózatok még mindig előnyösebb helyzetben vannak. Elég megváltoztatni a csoportházirend beállításait, é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 rendszert is, „megtanulja” az újítást, természetesen, ha az őket érinti. Visszatekintve a Unix fejlesztés hosszú időszakára, észre fogod venni, hogy soha semmi ilyesmi 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 fejlesztés jelentős erőfeszítést igényel. Az olyan kereskedelmi megoldások, mint a BladeLogic és az OpsWare, csak részben oldják meg a beállítások automatizálásának problémáját, fő előnyük a grafikus felület megléte, és csak nagy szervezetekben vásárolhatók meg. Természetesen vannak ingyenes megoldásokat kínáló projektek, de fennállásuk során soha nem tudtak nagy közösséget létrehozni. Például a Cfengine nem túl népszerű a rendszergazdák körében, bár a Linuxon kívül *BSD, Windows és Mac OS X alatt is használható. Ennek oka lehet a konfigurációk létrehozásának viszonylagos bonyolultsága. A feladatok leírásánál figyelembe kell venni az egyes rendszerek sajátosságait, és a parancsok végrehajtása során kézzel kell vezérelni a műveletek sorrendjét. Vagyis az adminisztrátornak emlékeznie kell arra, hogy egyes rendszerek esetében az adduser-t kell írnia másoknak, a useradd-t, figyelembe kell venni a fájlok helyét a különböző rendszereken stb. Ez nagyságrenddel megnehezíti a parancsok írását, nagyon nehéz menet közben elkészíteni a megfelelő konfigurációt, és szinte lehetetlen egy idő után elolvasni a létrehozott konfigurációkat. A GPL licenc ellenére a Cfengine valójában egy egyszemélyes projekt, aki minden változást irányít, és nem nagyon érdekli a nyitott társadalom építése. Ebből kifolyólag a cfengine képességei eléggé kielégítőek a fejlesztő számára, de a többi rendszergazdának inkább plusz fejfájást jelent. A cfengine fejlesztésére különféle kiegészítőket készítettek külső fejlesztők, amelyek gyakran csak rontottak a helyzeten. Számos ilyen cfengine-modul szerzője, Luke Kanies végül úgy döntött, hogy kifejleszt egy hasonló eszközt, de a cfengine számos hiányossága nélkül.

A báb jellemzői

A Puppet a cfengine-hez hasonlóan egy kliens-szerver rendszer, amely deklaratív, azaz kötelező nyelvet használ a feladatok és a megvalósításukhoz szükséges könyvtárak leírására. Az ügyfelek rendszeres időközönként (alapértelmezés szerint 30 perc) csatlakoznak a központi szerverhez, és megkapják a legújabb konfigurációt. Ha a kapott beállítások nem egyeznek a rendszer állapotával, akkor azok végrehajtásra kerülnek, és szükség esetén jelentést küldenek a szervernek az elvégzett műveletekről. A szerver elmentheti az üzeneteket a rendszernaplóba vagy egy fájlba, létrehozhat egy RRD-gráfot, és elküldheti őket egy megadott e-mailre. A további Tranzakciós és Erőforrás-absztrakciós rétegek maximális kompatibilitást biztosítanak a meglévő beállításokkal és alkalmazásokkal, lehetővé téve, hogy a rendszerobjektumokra összpontosítson anélkül, hogy aggódnia kellene a részletes parancsok és fájlformátumok megvalósításában és leírásában mutatkozó különbségek miatt. Az adminisztrátor csak az objektumtípussal dolgozik, a többiről a Puppet gondoskodik. Így a csomagtípus 17 csomagrendszert tud, a szükséges automatikusan felismerésre kerül a disztribúció vagy a rendszer verziószámára vonatkozó információk alapján, bár szükség esetén a csomagkezelő kényszeríthető.

Ellentétben a szkriptekkel, amelyek gyakran nem használhatók más rendszereken, a külső rendszergazdák által írt Puppet konfigurációk többnyire probléma nélkül működnek bármely más hálózaton. In Puppet CookBook [ http://www.reductivelabs.com/trac/puppet/tags/puppet%2Crecipe] már három tucat készrecept létezik. 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 értened a nyelv alapvető elemeit és képességeit. A nyelv a Puppet egyik erőssége. Segítségével leírják az adminisztrátor által kezelni kívánt erőforrásokat és műveleteket. A legtöbb hasonló megoldástól eltérően a Puppet lehetővé teszi a nyelv számára, hogy leegyszerűsítse a hozzáférést az összes hasonló erőforráshoz bármely rendszeren heterogén környezetben. Az erőforrás leírása általában egy névből, típusból és attribútumokból áll. Például mutassunk az /etc/passwd fájlra, és állítsuk be az attribútumait:

file("/etc/passwd":

tulajdonos => root,

csoport => gyökér,

Most a kliensek, miután csatlakoztak a szerverhez, átmásolják az /etc/passwd fájlt, és telepítik a megadott attribútumokat. Egy szabályban több erőforrást is megadhat, pontosvesszővel elválasztva őket. Mi a teendő, ha a szerveren használt konfigurációs fájl eltér a klienstől, vagy egyáltalán nincs használatban? Ez a helyzet például a beállításkor fordulhat elő VPN kapcsolatok. Ebben az esetben a fájl a forrás direktíva használatával mutatható. Itt szokás szerint két lehetőség van egy másik fájl elérési útjának megadására; két URI protokoll is támogatott: a fájl és a báb. Az első esetben egy külső NFS-kiszolgálóra mutató hivatkozást használnak, a második lehetőségnél pedig egy NFS-szerű szolgáltatás indul a Puppet szerveren, amely erőforrásokat exportál. Az utóbbi esetben az alapértelmezett elérési út a báb gyökérkönyvtárához - /etc/puppet - relatív. Vagyis a puppet://server.domain.com/config/sshd_config hivatkozás az /etc/puppet/config/sshd_config fájlnak felel meg. 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 csak bizonyos címekről korlátozhatja a szolgáltatáshoz való hozzáférést. Például írjuk le a konfigurációs részt.

elérési út /var/puppet/config

*.domain.com engedélyezése

192.168.0.*

megenged 192.168.1.0/24

deny *.wireless.domain.com

Ezután az erőforrás leírásakor térjünk rá erre a szakaszra.

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

A kettőspont előtt az erőforrás neve. A legegyszerűbb esetekben egyszerűen megadhat egy álnevet vagy változókat névként. Az alias beállítása az alias direktívával történik. a fájl teljes elérési útja. Bonyolultabb konfigurációkban

file("/etc/passwd":

alias => passwd

Egy másik lehetőség az álnév létrehozására akkor jó, ha különböző operációs rendszerekkel kell foglalkoznia. Például hozzunk létre 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ájlt külön kell megadni, az összes többi esetében az /etc/ssh/sshd_config fájl kerül kiválasztásra. Most ez az erőforrás sshdconfig néven érhető el, az operációs rendszertől függően a kívánt elérési út kerül kiválasztásra. 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.

biztos => igaz,

feliratkozás => Fájl

A változókat gyakran használjuk a felhasználói adatokkal való munka során. Például leírjuk a felhasználói kezdőkönyvtárak helyét:

$homeroot = "/home"

Mostantól egy adott felhasználó fájljai a következő néven érhetők el

$(homeroot)/$név

A $name paraméter a felhasználói fiók nevével lesz kitöltve. Egyes esetekben célszerű alapértelmezett értéket megadni bizonyos típusokhoz. Például az exec típusnál gyakran jelzik azokat a könyvtárakat, amelyekben a végrehajtható fájlt keresni kell:

Exec (útvonal => "/usr/bin:/bin:/usr/sbin:/sbin")

Ha több beágyazott fájlra és könyvtárra kell mutatnia, használhatja a recurse paramétert.

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

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

recurse => "igaz"

Több erőforrás kombinálható osztályokká vagy definíciókká. Az osztályok egy rendszer vagy szolgáltatás teljes leírása, és külön használatosak.

"/etc/passwd": tulajdonos => root, group => root, mode => 644;

"/etc/shadow": tulajdonos => root, group => root, mode => 440

Az objektum-orientált nyelvekhez hasonlóan az osztályok felülbírálhatók. Például a FreeBSD-n ezen fájlok csoporttulajdonosa a wheel. Ezért, hogy ne írjuk át teljesen az erőforrást, hozzunk létre egy új freebsd osztályt, amely örökli a linux osztályt:

osztály freebsd örökli a linuxot (

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

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

A kényelem kedvéért minden osztály elhelyezhető egy külön fájlban, amely az include direktívával kapcsolható össze. A definíciók több paramétert is használhatnak argumentumként, de nem támogatják az öröklődést, és akkor használatosak, ha újrafelhasználható objektumokat kell leírni. Például határozzuk meg a felhasználók kezdőkönyvtárát és az új fiók létrehozásához szükséges parancsokat.

definiálja a user_homedir ($csoport, $teljesnév, $csoportok) (

user("$name":

biztosítsa => jelen,

megjegyzés => "$teljes név",

gid => "$csoport",

csoportok => $ingroups,

tagság => minimum,

shell => "/bin/bash",

home => "/home/$name",

igény => Group[$group],

exec("$name homedir":

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

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

igényel => User[$name],

Most egy új fiók létrehozásához lépjen kapcsolatba a user_homedirrel.

user_homedir("szergej":

csoport => "szergej",

teljes név => „Sergej Jaremchuk”,

ingroups => ["media", "admin]

Külön leírások vannak az öröklődést támogató csomópontokról, például az osztályokról. Amikor egy kliens csatlakozik a Puppet szerverhez, a rendszer megkeresi a megfelelő csomóponti részt, és csak erre a számítógépre vonatkozó beállításokat biztosítja. Az összes többi rendszer leírásához használhatja az alapértelmezett csomópontot. Minden típus leírása megtalálható a „Típushivatkozás” dokumentumban, amelyet minden esetben el kell olvasni, legalább a Puppet nyelv minden képességének megértéséhez. A különféle típusok lehetővé teszik meghatározott parancsok végrehajtását, beleértve bizonyos feltételek teljesülését (például konfigurációs fájl módosítása), cron-nal való munkát, felhasználói hitelesítő adatokat és csoportokat, számítógépeket, erőforrások csatlakoztatását, szolgáltatások indítását és leállítását, csomagok telepítését, frissítését és eltávolítását. , SSH-kulcsokkal, Solaris-zónákkal és így tovább. Ilyen egyszerű az apt segítségével a disztribúciókban lévő csomagok listáját 2 és 4 óra között naponta frissíteni.

menetrend (napi:

időszak => naponta,

tartomány =>

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

menetrend => naponta

Az adott időszakra vonatkozó frissítést minden rendszer csak egyszer hajtja végre, ezután a feladat befejezettnek minősül, és törlődik az ügyfélszámítógépről. A Puppet nyelv más ismert struktúrákat is támogat: feltételeket, függvényeket, tömböket, megjegyzéseket és hasonlókat.

A Puppet telepítése

A Puppethez Ruby (>= 1.8.1) szükséges OpenSSL támogatással és XMLRPC könyvtárakkal, valamint a Faster könyvtár [ http://reductivelabs.com/projects/facter]. A teszttelepítéshez használt Ubuntu 7.04 adattár már tartalmazta a puppy csomagot.

$ sudo apt-cache kereső báb

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

puppetmaster - központosított konfigurációkezelés vezérlő démon

A telepítés során az összes szükséges függőségi csomag telepítésre kerül: facter libopenssl-ruby libxmlrpc-ruby.

$ sudo apt-get install puppet puppetmaster

A Ruby könyvtárak elérhetőségét a paranccsal ellenőrizheti.

$ ruby ​​​​-ropenssl -e "puts:yep"

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

Ha nem érkezik hiba, akkor már mindent tartalmaz, amire szüksége van. A rendszer kívánt konfigurációját leíró fájlokat a Puppet terminológiában manifeszteknek nevezzük. Indításkor a démon megpróbálja beolvasni az /etc/puppet/manifests/site.pp fájlt; ha hiányzik, figyelmeztető üzenetet jelenít meg. Teszteléskor megmondhatja a démonnak, hogy offline módban működjön, ebben az esetben a jegyzék nem szükséges

$ sudo /usr/bin/puppetmasterd --nonodes

Ha szükséges, más fájlokat is csatlakoztathat a site.pp-hez, például osztályleírásokkal. Próbaüzemhez megadhatja a legegyszerűbb utasításokat ebbe a fájlba.

file("/etc/sudoers":

tulajdonos => root,

csoport => gyökér,

A szerver és az ügyfelek összes konfigurációs fájlja az /etc/puppet könyvtárban található. A fileserver.conf fájl, amelyről fentebb beszéltünk, nem kötelező, és csak akkor használható, ha a Puppet fájlkiszolgálóként is működik. Ubuntun ez a fájl az /etc/puppet/files alkönyvtárat exportálja. Az ssl alkönyvtár olyan tanúsítványokat és kulcsokat tartalmaz, amelyeket a titkosításhoz használunk az ügyfelek csatlakoztatásakor. A kulcsok automatikusan jönnek létre a puppetmasterd első indításakor; manuálisan is létrehozhatja őket a paranccsal.

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

A puppetd.conf és a puppetmasterd.conf fájlok hasonlóak. Megjelölnek néhány paramétert a démonok működéséhez a kliens rendszeren és a szerveren. Az ügyfélfájl csak a szerver paraméter jelenlétében különbözik, amely arra a számítógépre mutat, amelyen a puppetmasterd fut.

szerver = grinder.com

logdir = /var/log/puppet

vardir = /var/lib/puppet

rundir = /var/run

# küldjön jelentést a szervernek

Annak elkerülése érdekében, hogy mindent kézzel gépeljen 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 azoknak az e-mail címeknek a megadását, amelyekre a jelentéseket küldeni kell. A legegyszerűbb esetben egy sort használhat.

minden: [e-mail védett]

A konfigurációs fájlok nem elegendőek ahhoz, hogy az ügyfél csatlakozzon a szerverhez. Ehhez a tanúsítványokat is alá kell írni. Először is, hogy tájékoztassa a szervert 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

info: Igazolvány kérése

figyelmeztetés: a peer-tanúsítvány nem kerül ellenőrzésre ebben az SSL-munkamenetben

megjegyzés: Nem kapott igazolást

Ha egy másik sort 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/puppetmasterd

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

A szerveren megkapjuk az aláírandó tanúsítványok listáját.

$ sudo puppetca --list

nomad.grinder.com

És aláírjuk az ügyféltanúsítványt.

$ sudo puppetca –sign nomad.grinder.com

Mostantól a kliens szabadon csatlakozhat a szerverhez és fogadhatja a beállításokat.

Sajnos a cikkben egyszerűen nem lehet bemutatni a Puppet összes képességét. De amint látja, ez egy funkcionális és rugalmas eszköz, amely lehetővé teszi a legtöbb rendszer egyidejű adminisztrációjával kapcsolatos problémák megoldását. Ha a munkája több rendszer beállítását igényli. És ami a legfontosabb, a projektnek sikerült egy kicsi, de folyamatosan növekvő közösséget összegyűjtenie. Ezért reménykedjünk abban, hogy egy jó ötlet nem hal el vagy félremegy.

Ha az Ön által kezelt szerverek száma tíznél kevesebb, ritkán gondol valaki a központosított felügyeletére, erre nincs is szükség. Ha több tucat szerverről van szó, a központosított szoftver- és konfigurációkezelés rendkívül hasznos. Ha több száz és ezer szerver van, ez létfontosságú. Sok ilyen program létezik, például: Chef, CFEngine, Puppet... Ez utóbbiról lesz szó ebben a bejegyzésben.

A bábot méltán tartják az egyiknek legjobb megoldások mint az. Olyan cégek használják, mint a Google, a Citrix és a Red Hat. Ez egy Ruby programozási nyelven írt kliens-szerver alkalmazás, amely két változatban kerül forgalomba:

• Puppet Open Source – teljesen ingyenes verzió
• Puppet Enterprise – ingyenes legfeljebb 10 szerverhez, majd licenc szükséges

Fontolja meg a Puppet nyílt forráskódú kiszolgáló és ügynök telepítését, amelyek a legtöbb modern disztribúció csomagjában megtalálhatók. Ezután az Ubuntu 12.04 Precise Pangolinról fogunk beszélni.

A Puppet hátsó végét hívják bábjátékos, kezdjük onnan a telepítést:

És most az ügyfél:

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

Server=puppet.local report=true pluginsync=false

A kezdeti szakaszban jobb, ha kikapcsolja a pluginsync-et.

Futtassuk a bábklienst úgy, hogy létrehozzon egy tanúsítványkérelmet:

A szerveren ellenőriznie kell, hogy a tanúsítványkérés megérkezett-e, és ha igen, akkor tanúsítványt kell kiállítania:

Ismételje meg az előző lépést az ügyfélen:

Szuper, minden működik. Térjünk át az első kiáltvány elkészítésére. A megnyilvánulásokat vagy konfigurációkat egy speciális deklaratív nyelven írják le. Azonnal megszokjuk a jó dolgokat, moduláris felépítést és órákat használunk. Például írjunk egy modult, amely naprakészen tartja a fájlt /etc/hosts minden szerverünkön.

Nézzük meg, hol keres a báb modulokat:

Hozzon létre könyvtárakat a modulhoz

Az első jegyzéket, más néven fő modulfájlt, meg kell hívni init.pp

Osztály gazdagépei ( # puppet.local host ( "puppet.local": biztosítsa => "present", target => "/etc/hosts", ip => "192.168.0.1", host_aliases => "puppet", ) # linux.local host ("linux.local": biztosítsa => "jelen", target => "/etc/hosts", ip => "192.168.0.2", host_aliases => "linux", ) )

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

Alapértelmezett csomópont (beleértve a gazdagépeket is)

Ellenőrizzük a jegyzéket a szerveren:

Az ügyfélen:

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

# Start puppet on boot? START=igen

A szolgáltatás elindítása

A Puppet 30 percenként lekérdezi a puppetmaster szervert a konfigurációs változtatásokról, és ha szükséges, ennek megfelelően módosítja a rendszert.