Az alkalmazás életciklus-menedzsment jelentősége magánfelhőkben
Nem minden infrastruktúra-mint-szolgáltás (IaaS, Infrastructure-as-a-Service) jellegű felhő egyenrangú.
Néhány megoldás a rendszergazdáknak lehetővé teszi, hogy egy sablonból kiindulva építsenek rendszerképmásokat. Más megoldásoknál a rendszerképmásokat (virtuális gépeket) a terméken kívül kell létrehozni és onnan kell importálni.
Néhány megoldás olyan rendszerképmások létrehozására képes csupán, ami meghatározott tulajdonosi technológiájú szoftverkészleteket futtató platformokon és felhőkön alkalmazható és telepíthető. Megint más megoldások választékot és hordozhatóságot kínálnak.
Ennek az írásnak azonban nem az a célja, hogy a rendszerképmások meghatározásának, létrehozásának és telepítésének különbözőségeit tárgyaljuk. Ehelyett tekintsük inkább át a jelenlegi menedzsment-modelleket.
Alapvetően olyan menedzsment komponensre van szükség, ami visszacsatolja a futtatott alkalmazásokat az eredeti tartalomhoz. Tapasztalatunk szerint az infrastruktúra-mint-szolgáltatás (IaaS) vakon kilőtt nyílként működik miután a rendszerképmások elindításra kerültek a felhőben vagy felhőkben.
A konténert, vagyis a rendszerképmást vagy virtuális gépet számos infrastruktúra-mint-szolgáltatás (IaaS) megoldás kezeli kisebb vagy nagyobb mértékben. A megközelítésük lényege az, hogy ha egy futó képmásban valamilyen problémát fedezünk fel, akkor a képet kikapcsolhatjuk, és egy újat alkalmazhatunk. Ez a fajta gondolkodásmód azt tükrözi, hogy bizonyos fajta alkalmazások, főleg az újak, „állapotmentesek”– vagyis nem tárolnak kizárólag a futó példányra jellemző információt, és ezáltal kisméretű zavarral bár, de újraindíthatóak.
Míg bizonyos esetekben helytálló ez a megközelítés, vannak hátrányai is. Az elsőszámú ilyen hátrány az, hogy számos alkalmazás ténylegesen nem állapotmentes. A második hátulütő az, hogy a konténer tartalma valósidejű megfigyelésének képessége nélkül nehezen kimutatható, hogy igazából történt-e bármilyen jellegű eltérés.
A Red Hat CloudForms ezzel szemben nem csak a tartalmat kezeli, hanem a konténert is. Olyan módon van tervezve, hogy fizikai, virtuális és felhő környezetekben futó rendszerek működésének operatív kezelését végezze. Ezáltal folyamatos tartalmi és konfigurációs megfelelőséget nyújt (a Red Hat termékekhez való jogosultság mellett), ami konzisztens a képmást készítő definíciókkal.
A tartalom folyamatos menedzsmentje két fő esetben használatos.
Az első ilyen eset, amikor a rendszergazda az alkalmazás definícióját frissíti, és azt egy futó élesüzemű rendszerbe akarja kitolni. Míg a rendszergazda egyszerűen újraprovízionálhatja és újraindíthatja az erőforrást, a folyamatos tartalom-menedzsment segítségével olyan valósidejű frissítéseket eszközölhet, amikhez nem szükséges a futó példányt újraépíteni és újraindítani.
A második eset az, amikor egy fejlesztő egy függvénykönyvtár frissítésével módosít egy példányt és ezáltal megszűnik a példány megfelelősége az alkalmazás definícióhoz. Ez a változás észlelhető, a rendszergazda pedig riasztást kap róla. A rendszergazda ezután eldöntheti, hogy orvosolja-e az elcsúszást úgy, hogy a függvénykönyvtárat a támogatott változathoz frissíti.
A Cloudforms nagy előnye más kezdetleges felhő-menedzsment megoldásokkal szemben az a képessége, hogy tartalom-, konfiguráció- és megfelelőségi életciklus-menedzsmentet nyújt. Így a rendszergazdák a futó alkalmazásaik automatizált irányítása révén fokozottan biztosak lehetnek abban, hogy az infrastruktúrájuk nem csak az új képmás elindításának pillanatában, hanem folyamatosan saját irányításuk alatt áll. Még ha jelenleg csupán fizikai szerverek kezelésével foglalkozunk is, a Red Hat felettébb hatásos eszközt nyújt eddigi rendszereink kezelésére, mindaddig, amíg készen nem állunk arra, hogy alkalmazásainkat felhő környezetbe helyezzük át. Az alkalmazásokat egy operációs rendszer „konténeren” belül még felhő számítástechnika hiányában is komoly kihívás kezelni, sok infrastruktúra-mint-szolgáltatás megoldás mégsem szentel elég figyelmet ennek.
A futásidejű menedzsment az alkalmazások szintjén azt jelenti, hogy az „eltérések” az alkalmazások konfigurációjában felismerhetőek és gyorsabban orvosolhatóak az alkalmazás újraindítása nélkül, ami kulcsfontosságú elvárás számos kritikus üzleti alkalmazás részéről.