Új időknek programozható infrastruktúrái

IT-infrastruktúrát létrehozni és üzemeltetni ezeregy okból problémás. Mit tehetünk, ha nem szeretnénk rendszerünk stabilitását és reprodukálható, megbízható működését egy „pótolhatatlan” rendszergazdára bízni? Nyugalom, van megoldás. Igaz, programozni tudni kell hozzá, de ebben a szakmában ez nem irreális elvárás.

Egyáltalán mit nevezünk informatikai infrastruktúrának? A Wikipédia szerint IT-komponensek összességét, amelyek egy IT-szolgáltatás alapját képezik. Persze itt tovább kérdezhetnénk, hogy mi az IT-szolgáltatás definíciója… Ennek az írásnak azonban nem ez a fajta boncolgatás a célja, hanem a címben szereplő kifejezés körbejárása. Mindenesetre jelen cikk erejéig fogadjuk el, hogy az infrastruktúra minden, ami“alatta” van, illetve “szolgálatában áll” a tekintett rendszernek. Hagyományos értelemben itt hardver, szoftver, hálózati és egyéb eszközökről van szó, melyek egy szolgáltatás kifejlesztéséhez és üzemeltetéséhez szükségesek.

Azért fontos ezt tisztáznunk, mert a vizsgálatunk tárgyát képező “programozható infrastruktúra” kifejezésből az infrastruktúra szót nehezebb megragadni, mint a programozhatóságot. Mindazonáltal, most már, hogy tudjuk, mi az infrastruktúra, megbeszélhetjük, mit jelent az, ha valami programozható. Na már most egy program, az adatok és utasítások olyan összessége, amelyet egy számítógép végre tud hajtani egy adott probléma megoldására. Ha valami programozható, akkor az azt jelenti, hogy tudunk, de legalábbis lehetőségünk van olyan programot létrehozni, amely megoldja az adott problémát. Ez az okfejtés már sugallja, hogy az infrastruktúra problémás. Aki valaha foglalkozott már számítógépes rendszer telepítésével vagy üzemeltetésével, az tudja ezt. Infrastruktúrát létrehozni és működtetni mindig kihívásos. Ezen feladat megkönnyítésére hivatott életre az írásunk névadójának szánt technika. 

Hagyományos megközelítésben az ember fog egy számítógépet, rátelepít különböző alapszoftvereket, mintegy előkészítés gyanánt, majd végül az így megágyazott fészekbe helyezi (telepíti) a kérdéses rendszert. Mi ezzel a baj? Látszólag semmi, ámbátor, ha jobban belegondolunk, elég sok sebből vérzik ez az eljárás.Eleve kell hozzá egy ember, aki érti, amit csinál. Viszont az ember drága, főleg, ha értő. Továbbá egy nem is elég, mert mi van, ha az egy emberünk beteglesz, avagy – bárakármiért is – elmúlik a dolgozhatnékja. Tehát ott tartunk, hogy kell több ember, akinek a tudásán múlik a rendszerünk életképessége. A tudásán, vagyis a fejében van…

Dokumentáció!– kiáltja ekkor a gyakorlott IT-menedzser, mindazonáltal mindannyian tudjuk,hogy a dokumentáció karbantartásának a projekt lendületének apadásávalegyenesen arányos. És csökken. Az elején minden nagyon szép és jó, disszertációnak is beillő doksik születnek, aztán el-elmarad a frissítés, míg végül a feledés homályába vész az egész, és már csak az egyetlen rendszergazda tudja, hogy melyik szerver melyik könyvtárában megbúvó melyik konfig fájlba kell beírni a bűvszavakat, hogy a rendszer újra elinduljon. Arról nem is beszélve, hogy rendszereket identikus módon replikálni is szükséges néhanap, hogy adott esetben tesztelni tudjunk, avagy netán hibát keresni, ne adj isten géphiba esetén újratelepíteni, esetleg új felhasználókat oktatni az élestől különböző környezeten, hogy az éles üzemet ne zavarjuk. Ilyenkor megint csak a kétes tartalmú dokumentációra és a pótolhatatlan rendszergazdára vagyunk utalva, hogy mennyire tudnak, fejből (doksiból) az éles környezethez kellően jól közelítő replikát készíteni.

Sajnos az ember gyenge és hibázik, nem emlékszünk mindig mindenre, nem egyforma módon hajtjuk végre kétszer ugyanazt a feladatot, a dokumentáció az esetek túlnyomó többségében nem teljes (mert az ember gyenge és hibázik), így a rendszerünk replikálására vonatkozó törekvéseink legtöbbször korlátozott sikerrel járnak csupán. Nem lesz két egyforma rendszerünk – bármennyire is jó lenne. Újratelepítés után az új szerver nem lesz ugyanolyan, mint a régi. Ezen aztán a szoftverünk, aminek az infrastruktúrájáról beszélünk, joggal megsértődik, nem hozza az elvárt működést, és senki nem fogja tudni megmondani, pontosan miért. Napokig, rossz esetben hetekig keressük az okát, rengeteg időt (pénzt)égetünk el hibakeresésre, és még ha meg is lesz a probléma oka, és kijavításra is kerül, még akkor sem alszunk nyugodtan, hiszen semmi nem garantálja, hogy legközelebb nem járunk ugyanígy pórul. Nyugtalanító…

Mentés!– folytathatná a kajabálást gyakorlottnak hitt, bónuszában töretlenül bízó IT-menedzserünk. Miszerint készítsünk mentést, majd ennek másik környezetbe való visszaállításával reprodukáljuk a meghibásodott, tesztelendő, oktatandó, bármilyen okból reprodukálandó rendszert. Szép gondolat, mondhatni romantikus, ámbátor kevéssé célravezető. A mentés és a visszaállítás is rendszerint idő- és erőforrásigényes folyamat, és mint ilyen, jellemzően katasztrófahelyzetből való helyreállításra hivatott, nem pedig arra, hogy napjában akár többször is, az új fejlesztések helyességét ellenőrző automatikus tesztek futtatásának alapjául szolgáljanak. Hogy csak egy példát említsünk: A terhelésfüggő skálázás és erőforrás-optimalizáció kérdésköreit szándékosan nem is fűztem a történetbe, pedig a téma érinti őket is.

Mit lehet hát tenni? 

Napjainkban, az agilis felhőkorban már egészen sok mindent. Mennyivel szebb lenne az élet, ha rendszereinket és azok infrastruktúráját nem kézimunkával, hanem dokumentációként is felhasználható, verziókezelőben tárolható, auditálható, újrafelhasználható, automatizálható, deklaratív programok alkalmazásával hoznánk létre és tartanánk karban. Sokkal! Viszlát Pótolhatatlan Rendszergazda, helló Programozó DevOps Infrastruktúra! A szektor már rég felismerte az ebben rejlő lehetőségeket, és a felhőszolgáltatások térnyerésével mára a legtöbb infrastruktúra-szolgáltatás elérhető programozható felületeken is. Sőt mi több, ez nem csak a nagy (AWS, Azure, GCP, ...) felhőszolgáltatók kínálatában szokásos, hanem a házon belüli virtualizációs megoldások (OpenStack, VMWare,...) esetében is.

Hogyne, programozni tudni kell hozzá, de az informatikában ez nem egy szokásostól eltérő elvárás. 

Továbbra is rendszereket kell létrehozni, csak programok megírásával és végrehajtásával. Mintha a kőműves feladatait 3D nyomtatóra bíznánk, melyet a tervrajz, mint utasítás vezérel. A kőmíves innentől pedig már nem téglát rak, hanem 3D nyomtatót kezel, az építész pedig nem tussal rajzol papírra, hanem ArchiCAD-ben dolgozik. A szép új világ...