A klaszter adminisztráció nem egyszerű feladat. Emlékszem, még az egyetem alatt az egyik tanár mesélte az új labor felállításáról, hogy a telepítést úgy oldották meg, hogy egy gépre elvégezték, majd a dd paranccsal a többi gép merevlemezére másolták azt. Nyilván, ha egyforma gépeink vannak, azokat ugyan olyan feladatot látnak el, ez működik is.
A mai klaszterek nem homogének. Változatos konfigurációban állnak rendelkezésre és van közöttük webszerver, tárolásra kialakított gép és számításokat végző egységek. A helyzetet bonyolítja, hogy ezek a szerepek az idő folyamán változhatnak.
Miként biztosítsuk a flexibilitást és a könnyű kezelhetőséget? A Sangernél az OpenStack használatával. Minden egységen egy virtuális gép fut, és ezen gépekre távolról rakják fel a képfájlokat. Ha valamelyik gépnek új funkció kell, csak a megfelelő képfájlt kell ráküldeni és már kész is. Gyakorlatilag ezt a módszert alkalmazzák az Amazonnál is. Csakhogy nekik nem kell törődni a szoftver környezettel, mert az a felhasználó dolga.
Itt viszont ha frissíteni kell egy programot, akkor új képfájlt kell létrehozni, ami lehetőleg hibamentes (tehát tesztelni kell), lehetőleg automatikusan készüljün el (ne kelljen a nulláról installálni mindent, csak mert megjelent egy új verzió az awk-ból) és az sem árt, ha a képfájl elkészítésének folyamatát egy verzió követő rendszerben megőrizzük.
Természetesen mindegyikre van megoldás. Jöhet a szakzsargon zsonglőrködés.
A verziókövető rendszer a Git, gondolom nem kell bemutatni. A stabil verzió a fő ágon van, minden újítást egy másik ágon kezdenek. Ha elkészültek a módosítással, letesztelték azt, mennek vissza a fő ágra. Akár csak egy szoftver fejlesztési projektnél. De a Git alapvetően kódot (szöveges állományt) tárol. Milyen kód kerüljön bele?
A virtuális képfájlokat a Packerrel készítik. Ez egy konfigurációs állományt állítja elő kódból. Támogat számtalan virtuális környezetet, tehát ha valami miatt az OpenStack nem válik be és egy másik technológiát kell követni, a Packer kód változatlan maradhat.
Az elkészült képfájl fordítását ellenőrizni kell, mert több száz program telepítése során igen sok hiba fordulhat elő. Erre a GitLab CI-t (continuous integration) használják. Ha a CI nem talál hibát, a képfájl elkészülhet.
Ezután a kész képfájlt kell ellenőrizni, hogy a számtalan szoftverkomponens nem ütközik-e. Itt bizony nincs mese, a képfájlt telepíteni kell egy tesztgépre és különböző tesztprogramokat kell futtatni. A Test Kitchen célja pontosan ez. Csupán egyetlen konfigurációs fájlt kell készíteni és a rendszer lefuttatja a benne definiált teszteket.
Magukat a teszteseteket nem a Kitchen definiálja, az csupán egy keretrendszer. A tényleges tesztek Bats-ban futnak. A szoftver komponenseken kívül a szerver állapotát is tesztelni kell (felcsatolta-e a meghajtókat, müködik-e a hálózati csatoló, stb.), amire ServerSpec-t használnak.
Tehát ha új szoftver kell a klaszterre, először frissítik a Packer képet, a régi, stabil verzió felépítése megtalálható a Git-en. Megírják a teszteket, lefuttatják azokat, majd küldik ki a képfájlokat a csomópontokra. Igen, kicsit összetettebb, mint a dd.
