itthon › Tanácsot › Master of puppets: A Puppet távoli konfigurációkezelő rendszer telepítése és konfigurálása. Master of puppets: A Puppet távoli konfigurációkezelő rendszer telepítése és konfigurálása Puppet telepítése

Master of puppets: A Puppet távoli konfigurációkezelő rendszer telepítése és konfigurálása. Master of puppets: A Puppet távoli konfigurációkezelő rendszer telepítése és konfigurálása Puppet telepítése

A Puppet hatékonyabb használatához meg kell értenie a modulok és jegyzékek felépítését. Ez az oktatóanyag végigvezeti Önt, hogyan működnek ezek a Puppet komponensek egy LAMP verem Ubuntu 14.04 szerveren történő beállításával.

Követelmények

Puppet telepítése (mester és ügynök). Erről bővebben -.
Lehetőség legalább egy Ubuntu 14.04 virtuális szerver létrehozására a Puppet ügynök csomópont kiszolgálására.

A bábkód alapjai

Erőforrások

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

user("mitchell":
biztosítsa => jelen,
uid => "1000",
gid => "1000",
shell => "/bin/bash",
home => "/home/mitchell"
}

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

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

Az összes Puppet erőforrástípus megtekintéséhez adja ki a következő parancsot:

báb erőforrás --típusok

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

Kiáltványok

A manifest egy hangszerelési szkript. A .pp kiterjesztésű bábprogramokat manifestnek nevezzük. Az alapértelmezett Puppet jegyzék az /etc/puppet/manifests/site.pp.

osztályok

Mint minden szokásos programozási nyelvben, az osztályok felelősek a hangszerelés egyes részeinek megszervezéséért és újrafelhasználásáért.

Az osztálydefiníción belül van egy kódblokk, amely leírja az osztály működését. Miután definiált egy osztályt, használhatja azt a jegyzékekben.

Az osztálydefiníció a következő formátumú:

class example_class(
...
kód
...
}

Ez a kód határozza meg az example_class osztályt. A Puppet kód kapcsos zárójelben lesz.

Az osztálydeklaráció az a hely a kódban, ahol egy adott osztály meghívásra kerül. Osztálydeklarációval a Puppet feldolgozza a kódját.

Az osztálydeklaráció lehet közönséges és erőforrástípus szerinti.

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

tartalmazza az example_class

Erőforrástípusként deklarálva az osztály erőforrás-formátumban lesz deklarálva:

class("example_class":)

Ez a deklaráció lehetővé teszi olyan osztályparaméterek hozzáadását a kódhoz, amelyek felülírják az osztályattribútumok alapértelmezett értékeit. Például:

csomópont "host2" (
class ("apache": ) # apache modul használata
apache::vhost ( "example.com": # definiálja a vhost erőforrást
port => "80",
docroot => "/var/www/html"
}
}

Modulok

A modul jegyzékek és egyéb fájlok előre meghatározott módon szervezett csoportja, amely megkönnyíti a hangszerelés egyes részeinek megosztását és újrafelhasználását. A modulok segítenek megszervezni a Puppet kódot, mert felhasználhatók a kód több jegyzékbe történő szétválasztására.

A Puppet modulok az /etc/puppet/modules könyvtárban vannak tárolva.

Kiáltvány írása

A Puppet-jegyzékek, modulok és osztályok írását gyakorolhatja a LAMP-verem Ubuntu-kiszolgálóra való telepítésének példájával (az eredmény: ).

Tehát egy Ubuntu 14.04-szerver megszervezéséhez és egy LAMP-verem telepítéséhez erőforrásokra van szüksége a következő műveletekhez:

az apache2 csomag telepítése.
az apache2 szolgáltatás elindítása.
csomag telepítése MySQL szerver, mysql-szerver.
a mysql szolgáltatás elindítása.
php5 csomag telepítése
PHP tesztszkript készítése, info.php.
az apt index frissítése az egyes csomagok telepítése előtt.

Az alábbiakban három példát talál a Puppet kódra, amellyel egy ilyen LAMP verem beállítást lehet elérni.

Az első példa megtanítja, hogyan írjon alapvető manifeszteket egy fájlba. A második példa segít összeállítani és használni egy osztályt és modult a korábban megírt jegyzékek alapján. A harmadik példa bemutatja, hogyan használhat előre elkészített nyilvános modulokat egy LAMP-verem telepítéséhez.

jegyzet: A teszteléshez jobb, ha friss virtuális szervert használunk.

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

A Puppet jegyzéket az ügynökcsomópontra lehet írni, majd a puppet apply paranccsal végrehajtani (ehhez nincs szükség mester- és ügynökbeállításra).

Ebben a részben megtudhatja, hogyan írjon olyan jegyzékeket, amelyek az alábbi 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.

# futtassa az "apt-get update" parancsot
exec("apt-update": # erőforrás exec "apt-update"
command => "/usr/bin/apt-get update" # parancs, amelyet ez az erőforrás futtatni fog
}
# telepítse az apache2 csomagot
package("apache2":
request => Exec["apt-update"], # kérje az "apt-update" parancsot a csomag telepítése előtt
biztosítsa => telepítve,
}
# az apache2 szolgáltatás indítása
service("apache2":
biztosítsd => futás,
}
# telepítse a mysql-servert
package ("mysql-szerver":
request => Exec["apt-update"], # újratelepítéssel kérje az "apt-update" parancsot
biztosítsa => telepítve,
}
# indítsa el a mysql szolgáltatást
service ("mysql":
biztosítsd => futás,
}
# php5 csomag telepítése
package ("php5":
request => Exec["apt-update"], # telepítés előtt kérje az "apt-update" parancsot
biztosítsa => telepítve,
}
# indítsa el az info.php szolgáltatást
file("/var/www/html/info.php":
biztosítsa => fájl,
tartalom => "", # phpinfo kód
request => Csomag ["apache2"], # kérés az "apache2" csomaghoz
}

Manifest alkalmazása

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

sudo puppet alkalmazni --teszt

Ez egy terjedelmes eredményt jelenít meg, amely megjeleníti a környezet állapotában bekövetkezett összes változást. Ha nincs hiba a kimenetben, meg kell tudnia nyitni a külső IP-címét vagy a domain nevét a böngészőben. Egy teszt teszt jelenik meg a képernyőn. PHP oldal a veremről szóló információkkal. Ez azt jelenti, hogy az Apache és a PHP működik.

Most a LAMP verem telepítve van a szerveren a Puppet segítségével.

Ez egy meglehetősen egyszerű manifest, mivel végrehajtható egy ügynökön. Ha nem rendelkezik Puppet mesterrel, más ügynökcsomópontok nem fogják tudni használni ezt a jegyzéket.

A Puppet master szerver 30 percenként ellenőrzi a kiszolgáló állapotának változásait.

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ő részben írt LAMP-jegyzék alapján.

Modul létrehozásához hozzon létre egy új könyvtárat a modules könyvtárban (a nevének meg kell egyeznie a modul nevével). Ennek a könyvtárnak tartalmaznia kell egy manifest könyvtárat és egy init.pp fájlt. Az init.pp fájl megadja a Puppet osztályt (a nevének meg kell egyeznie a modul nevével).

Modul létrehozása

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

cd /etc/puppet/modules
sudo mkdir -p lámpa/manifestek

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

sudo vi lamp/manifests/init.pp

Illessze be a lámpa osztályát 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 a lámpaosztály meghatározása. Más jegyzékek modulként is használhatják ezt az osztályt.

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

Egy modul használata a fő jegyzékben

Most konfigurálhatja a fő jegyzéket, és a lámpamodul segítségével telepítheti a LAMP-vermet a szerverre.

A Puppet master szerveren szerkessze a következő fájlt:

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

Nagy valószínűséggel bekapcsolva Ebben a pillanatban a fájl üres. Adja hozzá a következő sorokat:

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

jegyzet: Cserélje ki az 1-es lámpát annak a Puppet-ügynöknek a gazdagépnevére, amelyre a veret telepíti.

A csomópont blokk lehetővé teszi, hogy olyan bábkódot adjon meg, amely csak néhány csomópontra vonatkozik.

Az alapértelmezett blokk minden ügynökcsomópontra vonatkozik, amely nem rendelkezik egyedi blokkkal (hagyja üresen). A lámpa-1 blokk a lámpa-1 ügynök csomópontra kerül alkalmazásra.

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

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

Mostantól a Puppet ügynök csomópont képes lesz letölteni a beállításokat a főkiszolgálóról, és telepíteni a LAMP-vermet. Ha most szeretne változtatásokat végrehajtani, futtassa a parancsot az ügynökön:

sudo puppet agent -- teszt

A modulok a legkényelmesebb módja a Puppet kód újrafelhasználásának. Ezenkívül a modulok segítenek a kód logikus rendszerezésében.

3. példa: 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ópont blokkhoz:

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

A MySQL modul paramétereit is átadhatja.

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

file("info.php": # erőforrásfájl neve
path => "/var/www/html/info.php", # cél elérési út
biztosítsa => fájl,
request => Class["apache"], # használható apache osztály
source => "puppet:///modules/apache/info.php", # hely a fájl másolásához
}

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

A Puppet átmásolja a puppet:///modules/apache/info.php fájlt a /etc/puppet/modules/apache/files/info.php mappába.

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

Hozzon létre egy info.php fájlt.

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

Mostantól a Puppet ügynök csomópont képes lesz letölteni a beállításokat a főkiszolgálóról, és telepíteni a LAMP-vermet. Ha most szeretné módosítani az ügynökkörnyezetet, futtassa a parancsot ezen a csomóponton:

sudo puppet agent -- teszt

Ez a parancs letölti az aktuális csomópont összes frissítését, és telepíti rá a veremet. 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://lámpa_1_nyilvános_IP/info.php

Következtetés

Most már rendelkezik alapvető ismeretekkel a Puppet modulokkal és manifestekkel való munkavégzésről. Próbáljon meg saját maga létrehozni egy egyszerű manifestet és modult.

A Puppet kiválóan alkalmas az alkalmazások konfigurációs fájlok kezelésére.

Címkék: ,
Egy kis költészet.Úgy tűnik, ez a cikk kell, hogy legyen a teljes sorozat kiindulópontja, de a célközönség továbbra is az Open Source Puppet Labs termékeinek tapasztaltabb felhasználói, akik nincsenek megelégedve az egyedi, a Puppet Forge-ba rosszul integrált modulokkal. Mint minden „könyvtár kontra keretrendszer” esetnél, itt is az árat kell fizetni az integrált megoldás szerzőjének világnézetének követése.

Egy kicsit a Puppet működéséről

A báb elsősorban egy sajátos nyelv a rendszer végső állapotának deklaratív meghatározására. Összehasonlításképpen rendkívül alkalmas a GNU Makefile, ahol a függőségek közvetlen leírása mellett a legteljesebb mértékben meg lehet furikázni.

A báb absztrakciója valami ilyesmi ( minták feltörése – felejtsen el mindent, amit a programozási kifejezésekről tudott!).

Csomópont egy adott célrendszer konfigurációinak halmaza. Valójában ez egy osztály speciális esete.
Osztály egy deklaratív logika halmaza, amely a csomópont konfigurációjában vagy más osztályokban szerepel. Az osztálynak nincsenek sem példányai, sem metódusai, de vannak a logikán belül meghatározott paraméterei és változói. Valójában ez egy olyan eljárás, amely egy másik eljárást örökölhet egyszerűen kód hozzáadásával, és a változók nem túl banális hatókörével.
típus- de ez inkább klasszikus osztálynak tűnik - névvel rendelkező példányokat feltételez és határozottan adott paramétereket, de semmi több. Egy típus konkrét megvalósítása írható Puppet szkriptként a define segítségével, amely más típusú példányokat hoz létre, vagy Ruby kiterjesztésként.
Forrás- ezek valójában a típusok elnevezett példányai. Minden erőforrásnév egyedi egy adott típuson belül a csomópont (könyvtár) konfiguráción belül.
Változók- Nos, röviden, ezek állandók... A Puppet 4 előtt még rosszabb volt a helyzet a hatókörükkel. Most már megfelelő: a definíciós helyen kívülről történő használathoz egy teljesen minősített azonosítót kell megadni, kivéve az osztályöröklődés esetét.

A Puppet helyi telepítésre használható hálózat vagy kapcsolódó infrastruktúra nélkül. Ez használható konténerképek létrehozására. Még egy egész mozgalom is támogatja a központosított szerver elhagyását.

Ideológiailag helyes módon a Puppet infrastruktúra egy ügynökből - a célrendszer kiemelt szolgáltatásából - és egy szerverből áll, amely az ügynökök kérésére értékes utasításokat oszt ki deklaratív erőforrás-könyvtárak formájában. A biztonságot a privát nyilvános kulcsú infrastruktúra (X.509) szintjén valósítják meg. Egyszerűen fogalmazva, ugyanazok a mechanizmusok, mint a HTTPS-ben, de saját CA-val és kötelező ellenőrzéssel ügyféltanúsítvány.

Egyszerűsített formában a telepítési eljárás valahogy így néz ki:

Feldolgozás TLS-en és X.509-en keresztül (kapcsolat létrehozása, CRL frissítése, tanúsítványkorlátozások ellenőrzése stb.)
Az ügynök ténygenerátorokat kap a szervertől gyorsítótárazással és mindennel (pontosabban a modulok lib/ mappáiból van kihúzva minden). Nem nehéz saját Ruby-szkriptet hozzáadni az érdekes információk összegyűjtéséhez.
Az ügynök adatokat gyűjt a célrendszerről, és elküldi a szervernek. Minden tény egyszerűen megtekinthető manuálisan a báb tények felhívásán keresztül. Ezek a tények globális változókként állnak rendelkezésre.
A szerver összeállítja az erőforrások katalógusát, és elküldi az ügynöknek. Ez alatt különböző fogalmak egész rétege lapul.
Az ügynök mindent lekér a szerverről, és a rendszert a megadott űrlapra hozza. Az ügynök maga nem tud mit kezdeni az erőforrásokkal, bizonyos típusú erőforrások szolgáltatóinak megvalósítására támaszkodik (a szemantikai fordítás „végrehajtó lesz, nem szállító”). Egyes szolgáltatók szabványosak, és a Puppet csomagokban is szerepelnek, míg a többi modulokból van kihúzva.

Az összes élvezet élvezetéhez további zsemlékek állnak rendelkezésre a következő formában:

Modul- deklaratív Puppet szkriptek, Ruby kiterjesztések a Puppethez, fájlok, fájlsablonok, Hiera adatok és még sok más gyűjteménye. Helyesebb kifejezés lenne a "csomag".
Környezet- szkriptek, modulok és Hiera adatok halmaza. Az infrastruktúra bonyolultabbá válásával elkerülhetetlenül szükségessé vált a konfiguráció további felosztása, mint a szabványos csomóponti felosztás. Ez alapvetően a kísérleti innovációkhoz és a banális hozzáférés-szabályozáshoz szükséges (amikor nem minden rendszergazda fér hozzá az IT infrastruktúra összes csomópontjához).
Hiera- hierarchikus adatbázis. Ez a megfogalmazás nagyon megfélemlítő tud lenni. Valószínűleg ezért változtatták meg a későbbi verziók dokumentációjában. Valójában ez egy rendkívül egyszerű és kényelmes mechanizmus a YAML- vagy JSON-fájlokból történő konfiguráció kinyerésére. A hierarchia több konfigurációs fájl olvasási sorrendjének megadása – pl. fájlok hierarchiája/prioritása.
- Az adatok függvényhívással történő lekérése mellett a Puppet az alapértelmezett osztályparamétereket is lekéri, ami a fő kiemelés.
- Természetesen a Hiera támogatja a tényinterpolációt, sőt a speciális függvények hívását is.
- A Puppet 4.3-ban újra megvalósítottuk ugyanazt a funkcionalitást, hogy ne csak a globális adatbázist támogassuk, hanem a Környezet és Modul lokálisát is, bár a szerző már több problémát is talált ezek megvalósításában (PUP-5983, PUP-5952 és PUP -5899), amelyeket a Puppet Labs azonnal kijavított.
- Számos stratégia támogatott az értékek kinyerésére a hierarchia összes fájljából:
  - first - a prioritás alapján talált első érték kerül visszaadásra
  - egyedi - az összes értéket egydimenziós tömbbe gyűjti, és eltávolítja a duplikációkat
  - hash – az összes talált YAML hash-t egyesíti. A duplikált kulcsok prioritás szerint kerülnek kiválasztásra.
  - A deep lényegében a hash rekurzív változata
- A szépség az, hogy a mintavételi stratégia megadható mind a lookup() függvény meghívásakor, mert és bármely hierarchiafájlban a speciális lookup_options kulcson keresztül, amelyet a cfnetwork modul aktívan használ.
PuppetDB- lényegében egy üzleti logikai réteg egy relációs adatbázis (PostgreSQL) körül, amely lehetővé teszi a tényekről és az elvégzett telepítésekről szóló jelentések mentését, valamint az erőforrások exportálását a későbbi importáláshoz más csomópontok vagy kijelölések könyvtáraiba. speciális funkciók. Van egy webes felület is, Puppet Dashboard formájában.
X.509 PKI- a már említett tanúsítvány infrastruktúra, amely rendkívül kényelmesen használható más szolgáltatásokhoz anélkül, hogy külön infrastruktúrát kellene kezelni.
Mkollektív- hasznos dolognak tűnik a szerverfarmon lévő feladatok esemény alapú indításához, de a szerzőben van némi bizalmatlanság egy adott megoldás biztonságában.
Bábkovács- nyílt platform a modulok közzétételére és letöltésére.
néhány egyéb funkció vezérlők formájában külső eszközök típusú Cisco berendezések és telepítés csupasz fémen, de ez egy másik történet

Megjegyzések a biztonságról és a hozzáférhetőségről

Meg kell értenie, hogy a Puppet Server a teljes IT-infrastruktúra sebezhető pontjává válik, mert... meghatározza az összes rendszer végső konfigurációját. Speciális esetekben célszerű szétválasztást csinálni - külön szervert a kritikus infrastruktúra elemeihez rendkívül korlátozott hozzáférésés kézi frissítés, a második pedig minden máshoz.

A Puppet Server elérhetősége meghatározza a teljes infrastruktúra kezelésének képességét. Érdemes a Puppet Servert egy virtuális gépen tárolni egy megbízhatóbb és gyorsabban helyreállítható harmadik féltől származó felhőben, mint amennyire saját lehetőségei vannak. Vagy több szervert kell telepítenie.

Mindenesetre ne telepítsen más szolgáltatásokat a rendszerre, ahol a Puppet Server csengőkkel és sípokkal lesz telepítve. A virtualizáció és a konténerezés segíthet.

Multi-master (több különálló Puppet szerver)

Ebben az esetben csak egy kiszolgáló működik CA-ként (hitelesítés-szolgáltató) – az elérhetetlensége azt jelenti, hogy nem lehet új csomópontokat hozzáadni.
- A Puppet lehetővé teszi harmadik féltől származó X.509 infrastruktúra használatát, ha a beépített infrastruktúra nem kielégítő.
A teljes konfigurációt (környezetet) egy verziókezelő rendszerben kell tárolni, és egyszerre kell telepíteni minden kiszolgálóra.
Az egyetlen közös a PostgreSQL adatbázis, amelynek magas rendelkezésre állásának megszervezése túlmutat jelen cikk keretein.
A cfpuppetserver modul támogatja a telepítést elsődleges (CA-val) és másodlagos szerverként.

Ami lényegesen megváltozott a régebbi verziók óta

A gyártó rendelkezik teljes leírással.

Minden szolgáltatás átkerült a JVM-hez, a JRuby-hoz és a Jetty-hez. Az integráció nyilvánvaló előnyei ellenére a memóriafelhasználás terén vannak hátrányai is.
Lambda funkciókat adtunk hozzá a gyűjtemények feldolgozásához – most már nem kell mankókat vágni Rubyban vagy pervertálni a create_resources() segítségével
Megjelent egy eszköz az EPP-sablonok feldolgozására - lényegében ugyanaz az ERB, de Ruby helyett Puppet DSL-lel,
A konfigurációs fájlok alapértelmezett könyvtárstruktúrája jelentősen megváltozott
Támogatás hozzáadva a környezetek és modulok adatszolgáltatóihoz (hackekre már nincs szükség).
A globális Hiera szerepének kicsinyítése. Az új és kapcsolódó parancs a bábkeresés.

Telepítés

Ez a folyamat meglehetősen primitív, de bizonyos lépések sorozatát követeli meg. Mivel ennek manuális elvégzése hálátlan feladat, a szerző megtanít valami rosszra, nevezetesen az érthetetlen szkriptek letöltésére az internetről, és rootként futtatva a rendszeren.

A három fő szerverkomponens maga a Puppet Server, a PuppetDB és a PostgreSQL. Mindegyik egy csomópontba zsúfolható, vagy két vagy három rendszerre osztható. A Puppet Server és a Puppet DB többször is futtatható, de a PostgeSQL egyetlen hibapont. A PostgeSQL replikációjának és fürtözésének többféle megközelítése létezik, a fő és másodlagos szerverek esetében kényelmes megoldás a Master + Read-Only Slave, amely magában a PuppetDB-ben is támogatott fő és csak olvasható adatbázis-csomópontként, de az ilyenek automatizálása. a telepítés időt vesz igénybe, ezért még nem érhető el a cfpuppetserver modulban.

Maga a konfiguráció egyszerűen legalább tárolható fájlrendszer a Puppet Serverrel együtt, de ez olyan, mintha szkripteket írnánk egy éles webszerveren. A legmegfelelőbb megoldás egy git repository. Az r10k segédprogram a lerakat összes ágát lehívhatja, és külön környezetként telepítheti a Puppet Serverre. Az r10k elég rossz a függőségek kihúzásában, ezért a könyvtáros-bábot használják felül. Azonnal érdemes megjegyezni, hogy a fő kanonikus Puppet Environment a "gyártás". Ezért a konfigurációs adattárnak a "gyártás" nevű ágat kell használnia a "mester" helyett.

Rendszerkövetelmények

A hardvert maga a gyártó írja le. A cfpuppetserver modul jelenleg csak a Debian Jessie+-t és az Ubuntu Trusty+-t támogatja.

Konfiguráció a Gitben

Magának az r10k-nek a tároló helye nem sokat számít - a legfontosabb az elérhetősége. Például tesztelési célból a tárat ugyanazon a rendszeren lehet tárolni, és a file:// fájlon keresztül lehet elérni. Jó kiindulópont a codingfuture/puppet-exampleenv konfigurációs példa.

Az adattár klónozása: git clone https://github.com/codingfuture/puppet-exampleenv my-puppet-conf && cd my-puppet-conf
Telepítés Általános beállítások rendszergazdai hozzáférés a megjegyzésekben található tippekkel:
- $EDITOR data/common.yaml
Hozzon létre egy csomópont konfigurációt:
- $MY_DOMAIN – gyökérdomainnév (például example.org)
- $HOST_NAME – az ügyfél gazdagépneve domain nélkül
- mkdir adatok/$MY_DOMAIN
- cp data/example.com/puppet.yaml data/$(MY_DOMAIN)/puppet.yaml
- $EDITOR nano -w data/$(MY_DOMAIN)/puppet.yaml - csomópont beállítása Puppet Serverrel a megjegyzésekben szereplő javaslatok szerint
- cp data/example.com/host.yaml data/$(MY_DOMAIN)/$(HOST_NAME).yaml
- $EDITOR nano -w data/$(MY_DOMAIN)/$(HOST_NAME).yaml - tetszőleges csomópont beállítása a megjegyzésekben szereplő javaslatok alapján
A saját Git szerverünkre küldjük, vagy elérhetővé tesszük helyileg egy Puppet Serverrel rendelkező csomóponton rsync vagy scp segítségével. Egy helyi adattár kényelmes köztes lépésként, amíg a Git-kiszolgálót magáról a Puppetről telepítik. Bizonyos értelemben ez egy fordítóprogram több lépésben történő összeállítására emlékeztet.

Telepítés a semmiből tiszta rendszerre

A cfpuppetserver modul lehetővé teszi, hogy mindent magával a Puppet-tel telepítsen, de a kezdeti telepítéshez az alapvető műveleteket egy Bash-szkript duplikálja.

A célrendszeren:

Töltse le a telepítő szkriptet: wget https://raw.githubusercontent.com/codingfuture/puppet-cfpuppetserver/master/setup_puppetserver.sh
Végignézzük a szkriptet, és összeráncoljuk a homlokunkat: less setup_puppetserver.sh
Futtassa: bash setup_puppetserver.sh
báb.$(MY_DOMAIN) .
- Példa távoli adattárral: bash setup_puppetserver.sh ssh:// [e-mail védett]/puppet-conf
- Példa helyivel: bash setup_puppetserver.sh file:///root/puppetconf/
Látjuk, hogy a rendszer felpuffad, és nem telepít mindent túl gyorsan.
Ha a tárhely távoli:
- Hozzon létre egy SSH-kulcsot a root számára: ssh-keygen -t rsa -b 2048
- Regisztráljuk a /root/.ssh/id_rsa.pub nyilvános kulcsot a távoli Git szerveren...
- ... és ott beállítunk egy Git hookot a következő parancs meghívásával: /usr/bin/ssh -T deploypuppet@puppet.$(MY_DOMAIN) ./puppetdeploy.sh
Elkezdjük manuálisan telepíteni a konfigurációt: /etc/puppetlabs/deploy.sh
Próbáljuk meg, hogyan működik magán a szerveren: /opt/puppetlabs/bin/puppet agent --test
Ellenőrizze a hálózati beállításokat, túlfeszültség védőés SSH hozzáférést

Felügyelt csomópontok hozzáadása

A Puppet Server teljes képzésű nevének elérhetőnek kell lennie a DNS-en keresztül a felügyelt gazdagépen, vagy be kell kódolni az /etc/hosts fájlba.
- Példa: echo "128.1.1.1 puppet.example.com" >> /etc/hosts
A Puppet Serverrel rendelkező csomóponton futtassa a következő szkriptet /root/genclientinit.sh $(HOST_NAME).$(MY_DOMAIN) .
Másolja ki a teljes eredményt, és illessze be parancs sor a célrendszeren.
Megvárjuk a végrehajtás végét, és futtatjuk az /opt/puppetlabs/bin/puppet agent --test parancsot. Az első indításkor tanúsítvány-aláírási kérés jön létre.
A Puppet Server csomóponthoz megyünk, hogy aláírjuk a tanúsítványt.
- bábtanúsítványok listája – ellenőrizzük a tanúsítvány aláírását az extra paranoia miatt.
- báb tanúsítvány aláírása $(HOST_NAME).$(MY_DOMAIN) - valójában mi írjuk alá a tanúsítványt.
Visszatérünk a felügyelt csomóponthoz, és újra futtatjuk: /opt/puppetlabs/bin/puppet agent --test`. Ez kényszeríti a telepítési eljárás elindítását.
Várjuk a telepítés befejezését a Puppet Agenten keresztül.
Ennyi, készen áll egy minimális Puppet infrastruktúra!

Példa kimenet a /root/genclientinit.sh fájlból

bash</etc/cflocation fi if teszt ! -z ""; akkor echo -n >/etc/cflocationpool fi if teszt ! -z "\$http_proxy"; majd exportálás http_proxy export https_proxy="\$http_proxy" export HTTP_PROXY="\$http_proxy" export HTTPS_PROXY="\$http_proxy" fi echo host.example.com > /etc/hostname hostname host.example.com if ! amely lsb-release | olvas; majd apt-get install lsb-release fi kódnév=\$(lsb_release -cs) if test -z "\$kódnév"; majd echo "A helyes kódnév észlelése sikertelen" kilépés 1 fi wget https://apt.puppetlabs.com/puppetlabs-release-pc1-\$(codename).deb dpkg -i puppetlabs-release-pc1-\$(kódnév) .deb mkdir -p /etc/puppetlabs/puppet cat > /etc/puppetlabs/puppet/puppet.conf<puppet cert sign host.example.com" echo "Használja a CTRL+C billentyűkombinációt a ciklus leállításához, ha különböző okok miatt meghiúsul" alvás 5 kész EOT

Modul leírása

A kezdeti telepítési parancsfájl Bash-paramétereinek teljes listája

~# ./setup_puppetserver.sh Használat: ./setup_puppetserver.sh [ [ [ [] ] ] ]

r10k_repo_url – a Git-tárhely URI-je
certname – a gazdagép teljes képzésű tartományneve
cflocation - a cf_location tény inicializálása
cflocationpool – a tény cf_location_pool inicializálása
http_proxy – proxy szerver HTTP és HTTPS kérésekhez

A Puppet kliens inicializálási parancsfájl Bash paramétereinek teljes listája

~# /root/genclientinit.sh Használat: ./genclientinit.sh [ [ []]]
A paraméterek jelentése ugyanaz, mint az előző szkriptben.

cfpuppetserver osztály

deployuser = "deploypuppet" – felhasználónév a konfigurációs frissítések automatikus telepítéséhez
deployuser_auth_keys = undef - a $deployuser kulcsainak listája
repo_url = undef - tárhely URI (például: ssh://user@host/repo vagy file:///some/path)
puppetserver = true – telepíteni kell-e a Puppet Server összetevőt erre a csomópontra
puppetdb = true – telepíteni kell-e a PuppetDB összetevőt erre a csomópontra
puppetdb_port = 8081 – a PuppetDB portja
setup_postgresql = true – telepíteni kell-e a PostgreSQL összetevőt erre a csomópontra (csak ha a PuppetDB telepítés engedélyezve van)
service_face = "bármilyen" - a cfnetwork::iface erőforrás neve a bejövő kapcsolatok fogadására
puppetserver_mem = automatikus – RAM a Puppet szerverhez megabájtban (legalább 192 MB)
puppetdb_mem = automatikus – RAM a PuppetDB-hez megabájtban (legalább 192 MB)
postgresql_mem = automatikus – RAM a PostgreSQL-hez megabájtban (legalább 128 MB)

osztály cfpuppetserver::puppetdb

postgresql_host = "localhost" - adatbázis címe
postgresql_listen = $postgresql_host - az érték közvetlenül a listen_addresses PostgreSQL direktívához kerül
postgresql_port = 5432 - adatbázis-port
postgresql_user = "puppetdb" - PuppetDB felhasználó az adatbázisban
postgresql_pass = "puppetdb" - a PuppetDB felhasználó jelszava az adatbázisban
postgresql_ssl = false - kapcsolattitkosítás engedélyezése Puppet PKI tanúsítványok alapján

osztály cfpuppetserver::puppetserver

autosign = false – NEM KELL használni harci környezetben, kivéve talán a DMZ-ben. Kizárólag tesztautomatizáláshoz létezik.
global_hiera_config = "cfpuppetserver/hiera.yaml" - az alapértelmezett Hiera konfigurációs fájl elérési útja a Puppet canons szerint (az első komponens a modul neve, a többi a modulban lévő fájlok/mappa alatti elérési út)

Segíthetsz és utalhatsz át pénzt az oldal fejlesztésére

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 a Windows hálózati rendszergazdái 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 a kezdeti telepítésben operációs rendszer, de a további finomítá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 rendelkezésre állás GUI, és csak nagy szervezetektől 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. A cfengine számos 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, 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 az egyik erősségeit Báb. 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? Például ez a helyzet akkor állhat elő, ha VPN beállítások kapcsolatokat. 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ő hivatkozásra mutató hivatkozás NFS szerver, a második lehetőségnél 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 fogad új fájl, újra kell indítania a szolgáltatást.

biztosítsd => 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 újat kell létrehozni fiókot csak 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 adja meg. 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 összes 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-nal, felhasználói hitelesítő adatokkal és csoportokkal, számítógépekkel, erőforrások csatlakoztatásával, szolgáltatások indításával és leállításával, csomagok telepítésével, frissítésével és eltávolításával, munkavégzéssel val vel SSH kulcsok, Solaris zónák é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á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. 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.

Báb egy többplatformos struktúra, amely lehetővé teszi rendszergazdák Gyakori feladatok végrehajtása kóddal. A kód segítségével különféle feladatokat hajthat végre az új programok telepítésétől a fájlengedélyek ellenőrzéséig vagy a felhasználói fiókok frissítéséig. Báb nemcsak a rendszer kezdeti telepítése során, hanem a rendszer teljes életciklusa során is kiváló. A legtöbb esetben báb kliens/szerver konfigurációban használatos.

Ez a rész a telepítést és a konfigurációt mutatja be Báb kliens/szerver konfigurációban. Ez az egyszerű példa bemutatja a telepítést Apache segítségével Báb.

Telepítés

A telepítéshez Bábírja be a terminálba:

Sudo apt-get install puppetmaster

Az ügyfélgép(ek)en írja be:

Sudo apt-get install puppet

Beállítások

A báb beállítása előtt érdemes lehet hozzáadni egy bejegyzést DNS CNAME Mert puppet.example.com, Ahol example.com- ez a te domained. Alapértelmezett ügyfelek Báb ellenőrizze a DNS-t a puppet.example.com címen a puppet szerver neveként ( Bábjátékos). A DNS használatával kapcsolatos további részletekért lásd: Domain Name Service.

Ha nem kívánja használni a DNS-t, akkor a kiszolgálón és a kliensen lévő /etc/hosts fájlhoz is hozzáadhat bejegyzéseket. Például az /etc/hosts fájlban Báb szerver hozzáadása:

127.0.0.1 localhost.localdomain localhost puppet 192.168.1.17 meercat02.example.com meercat02

Mindegyiken Báb A kliensben adjon hozzá egy bejegyzést a szerverhez:

192.168.1.16 meercat.example.com meercat puppet

Cserélje ki az IP-címeket és domain nevek a példától kezdve az aktuális címeiig és a szerver és az ügyfelek neveiig.

Most állítsunk be néhány forrást ehhez apache2. Hozzon létre egy fájlt /etc/puppet/manifests/site.pp a következőket tartalmazza:

Package ( "apache2": biztosítsa => telepítve) szolgáltatás ( "apache2": biztosítsa => true, enable => true, request => Package["apache2"] )

"meercat02.example.com" csomópont (beleértve az apache2-t is)

Cserélje ki meercat02.example.com jelenlegi nevedre Bábügyfél.

Az utolsó lépés ennek az egyszerűnek Báb a szervernek újra kell indítania a szolgáltatást:

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

Mostantól Báb minden be van állítva a szerveren, és itt az ideje a kliens konfigurálásának.

Először is konfiguráljuk a szolgáltatást Bábügynök indítani. Szerkessze az /etc/default/puppet fájlt, lecserélve az értéket RAJT tovább Igen:

Sudo /etc/init.d/puppet start

Térjünk vissza Báb szerver aláírja az ügyféltanúsítványt a következő paranccsal:

Sudo puppetca --sign meercat02.example.com

Jelölje be /var/log/syslog az esetleges konfigurációs hibákért. Ha minden jól ment, a csomag apache2és a függőségei telepítésre kerülnek Bábügyfél.

Ez a példa nagyon egyszerű, és nem mutat be sok funkciót és előnyt. Báb. Mert további információ néz

Szergej Jaremcsuk

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

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 a Windows hálózati rendszergazdái 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ég telepített operációs rendszerrel rendelkezőket is, „megtanulja” az újítást, persze 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, másoknak - useradd-t kell írnia, figyelembe kell vennie a fájlok helyét a különböző rendszereken és így tovább. 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 a rendszernaplóba vagy egy fájlba, létrehozhat egy RRD-gráfot, és elküldheti a 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 végrehajtásban és a részletes parancsok és fájlformátumok 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ó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 a Puppet egyik erőssége. Leírja azokat az erőforrásokat, amelyeket az adminisztrátor kezelni kíván, és az általuk végrehajtott 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 => 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? Ez a helyzet előfordulhat például VPN-kapcsolatok beállításakor. 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

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:

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"

Mostantól egy adott felhasználó fájljai a következőképpen é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 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

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, amelyet az include direktíva segítségével 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],

Ú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, 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 adja meg. 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 összes 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 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

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"

Igen

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 működjön, 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 szerver paraméter jelenlétében tér el, 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

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 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, í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

nomad.grinder.com

É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!