Konfiguráció menedzsment eszközök
Előre felhívom a figyelmet, hogy ez a szócikk arra nem elegendő, hogy meg lehessen belőle tanulni a konfiguráció menedzsment eszközök használatát. Arra viszont remélem, elegendő lesz, hogy kiinduló pontot nyújtson az ezek használatáról való döntéshez.
Tartalomjegyzék |
1 A probléma
Van n db. számítógép, amik nagyon hasonló feladatot látnak el, így nagyon hasonlóan is kellene őket adminisztrálni. Külön adminisztrálni mindegyiket kényelmetlen, és meglehetősen nagy káoszhoz vezetne.
2 A naív hozzáállás
Az ötlet hihetetlenül egyszerű. Összeállítunk egy shellscriptet, ami elvégzi a gépen a szükséges módosításokat, összecsomagoljuk a számára szükséges file-okkal, majd az adminisztrálni kívánt gépekre valahogyan eljuttatjuk a csomagot, és lefuttatjuk rajtuk a shellscriptet. Ezt pl. egy cron job segítségével automatizálni is lehet valamennyire. Az ötlettel azonban van néhány probléma. Mi van pl., ha néhány gépen sikeresen lefut az így összeállított shell script, néhányon pedig nem? A központilag adminisztrálni próbált gépek konfigurációja ez által el fog térni egymástól, és így megnehezítettük a saját dolgunkat. Arról nem is beszélve, hogy az ilyen céllal összedobott shellscriptek könnyen elérhetik az átláthatatlanság, és ez által a karbantarthatatlanság határát.
3 cfengine
3.1 Mi az a cfengine?
A problémára kitalált első "komoly" megoldás. Sok, különböző, Unix-szerű platformon képes működni. Az alapvető elv az, hogy nem ugyanazt az egy rendszert akarjuk sok példányban replikálni, és nem ugyanazokat a parancsokat akarjuk minden gépnek kiadni, csupán azt akarjuk, hogy teljesítsék ugyanazokat az elvárásokat. Szabályokat lehet benne definiálni, mely szabályoknak megfelelő állapotba hozza a menedzselt gépeket. Ezek a szabályok nem azt írják elő, milyen lépéseket kell tennie a cfengine-nek, csupán azt, milyen állapotban kell lenniük a menedzselt hosztoknak. Arra nincs garancia, hogy tényleg az előírt állapotban lesznek a hosztok, azonban biztosan tartani fognak az előírt állapot felé.
3.2 Komponensek
- cf-promises - Ellenőrzi, hogy a rendszer megfelel -e a szabályoknak.
- cf-agent - Módosításokat végez a rendszeren.
- cf-serverd - Kéréseket fogad létező szabályok alkalmazására.
- cf-execd - Ütemező.
- cf-runagent - Kéréseket lehet vele küldeni a cf-serverd-nek.
- cf-report - Jelentést készít.
- cf-know - Dokumentációt generál a szabályokról.
3.3 Szabályok felépítése
A szabályok ú.n. ígéretekből állnak. Az ígéreteket fel lehet bontani egy objektumra, melynek teljesítenie kell az ígéretet, opcionálisan egy objektumra, melynek érdeke ez az ígéret (dokumentációs szempontból), valamint a testre. A test balérték => jobbérték (ahol balérték egy foglalt szava a nyelvnek) kijelentések sorozata. Ezen kijelentések sablonokra is hivatkozhatnak, melyek az alábbi formájúak:
body bal jobb
{
bal1 => jobb1;
bal2 => jobb2;
}
Egy ígéret pedig az alábbi formájú:
"ígéretet tevő objektum" bal => jobb;
Az ágenseknek van egy speciális, control nevű sablonuk, amin át a viselkedésük befolyásolható. Az ígéretek kötegekbe gyűjthetők. A kötegek ahoz az ágenshez tartoznak, mely a benne foglalt ígéretek betartásával foglalkozik. A sablonok képesek paramétereket fogadni, melyeket a sablonon belül aztán változóként lehet használni. A paramétereket a sablon neve után zárójelek között kell megadni. A változónevek formája $(változónév). Valójában a változók is ígéretek: arra vonatkozó ígéretek, hogy az lesz az értékük, ami meg van adva.
3.4 Döntések
Az ágens az indulásakor meghatározza, milyen paraméterekkel rendelkezik a host, amin fut. Ennek alapján osztályokba sorolja a gépet. Emellett saját osztályozási elvek is definiálhatóak kötegek segítségével. Erre egy példa:
bundle agent osztaly
{
classes:
"dhcp_szerver" or => {fileexist("/etc/dhcp/dhcpd.conf"), fileexist("/etc/dhcp/dhcpd6.conf")};
dhcp_szerver::
#ide jönnek azok az ígéretek, amik teljesülését akkor szeretnénk, ha a gép egy dhcp szerver
}
Ebben a példában annak alapján döntöttük el (nem igazán helyes módon, de most jobb ötletem nem volt), hogy dhcp szerver -e a gép, hogy van -e /etc/dhcp/dhcpd.conf, vagy /etc/dhcp/dhcpd6.conf nevű fájl. Ha igen, akkor a dhcp_szerver osztályba tartozó gépekre vonatkozó szabályok végrehajtódnak. A :: operátor előtt több osztály nevét is fel lehet sorolni köztük logikai operátorokkal, így a gépek egy tetszőlegesen bonyolult módon meghatározott halmazára vonatkozó szabály alkotható.
3.5 Ígéretek típusai
- vars - változó, mely adott értéket fog felvenni
- classes - a rendszer jellemzőire és állapotára vonatkozó kijelentés. Ezek alapján lehet döntéseket hozni.
- reports - Üzenetek jelentésbe írása.
- commands - utasítás végrehajtása.
- databases - adatbázisokra vonatkozó ígéretek.
- files - fájlra vonatkozó ígéretek. Vonatkozhatnak a létezésére, attributumaira, és tartalmára.
- interfaces - hálózati interfészek konfigurációjára vonatkozó ígéretek.
- methods - további ígéretek kötegeire vonatkozó ígéret.
- packages - csomag telepítettségére vonatkozó ígéret.
- storage - csatolt tárolókra vonatkozó ígéretek.
