Számos alkalommal merül fel olyan probléma, hogy költséghatékonysági vagy szervezetfejlesztési szempontok miatt nincs lehetőség, vagy nem érdemes egy teljesen új konténer-orkesztrációs platform bevezetésén gondolkodni, hanem bizony „abból kell főzni, ami van”. A Kubernetes on Azure sorozatunk jelen részében ennek járunk utána, amiből megtudhatod, hogyan teremts az örökölt problémákból értéket és modernizáld ügyfeled/céged rendszerét a Kubernetes segítségével!

A cikk elkészítéséhez nélkülözhetetlen forrást nyújtott Kiss Olivér IT architect, az Alerant csapatának tagja, aki a „Konténerizált modern alkalmazásfejlesztés – Kubernetes on Azure” webinárunkon adott elő a témában. Hasznos prezentációja által a Legacy alkalmazás-migráció és modern alkalmazásfejlesztés témákban kaphattunk mélyebb betekintést.

A cikkben ugyancsak képet kaphatunk az AKS (Azure Kubernetes Service) best practice megoldásokról Farkas Lóránd, a Microsoft magyarországi partner-csapatának tagjától.

Egy új kihívás: a Legacy alkalmazások modernizációja “Kubernetes on Azure” alapú konténerizálással

Legacy alatt többnyire olyan információs rendszert értünk, amely bár elavult technológián alapul, ám fontos és kritikus szerepe van a vállalatok napi működésében. A Legacy alkalmazások, rendszerek kiváltása új, más technológiákon alapuló megoldással az egyike egy cég információs rendszereivel kapcsolatos legnagyobb kihívásainak.

Ha megnézzük a meglévő rendszereinket, azt tapasztalhatjuk, hogy a zöld mezős szisztémák mellett számos barna mezős rendszer is van egy-egy nagyvállalatnál. A barna mezősnél nem kell rosszra gondolni, csak arra vonatkozik, hogy ezek a rendszerek már itt-ott rozsdásodnak, kevesebben értenek hozzá. Nem is biztos, hogy van rá support és nem érkeznek rá security patch-ek. Emellett probléma lehet, hogy az infrastruktúra is igen heterogén. Egy részük fizikai gépen fut, míg egy másik részük pedig virtuális gépen. A modernebb alkalmazások pedig már valamilyen privát vagy publikus felhőben futnak.

Amiatt, hogy ennyire különbözőek az alkalmazások, nehéz egységes sztenderdeket és automatizmusokat bevezetni. Ha megnézzük, hogy hova szeretnénk eljutni, nem lehet rövid távú cél, hogy az összes barna mezős rendszerünket kidobjuk és az alapoktól újraírjuk az egészet. Ehelyett mindezt modernizálnunk kell. Ehhez egy olyan platform szükséges, amely a modernizált alkalmazásokat és a zöld mezős, új applikációkat is képes futtatni.

A 6R modell alkalmazása a Legacy rendszerek konténerizációs folyamatakor

Általában valamilyen konténer-technológiára – pl. Docker-re és Kubernetes-re – építhetünk egy rugalmas, agilis, modern és innovatív megoldást. Ha van egy Legacy rendszerünk, a 6R modell alapján végig gondolhatjuk, hogy mit lehet kezdeni az adott alkalmazással.

Dönthetünk úgy, hogy az alkalmazást érintetlenül hagyjuk. Ám határozhatunk úgy is, hogy pár éven belül kivezetjük azt vagy éppen lecseréljük egy másik megoldásra: pl. egy Azure Kubernetes Service-alapú megoldásra.

A Rehost, a Replatform és a Refactor mind-mind olyan megoldás, amellyel az alkalmazásunkat valamilyen szinten modernizálhatjuk és PaaS (Platform as a Service) megoldásba helyezzük. A Rehosting-nál nem szükséges kódmódosítás, hanem – egy lift and shift megoldással – megfogjuk az alkalmazást és valahogy importáljuk ebbe a modern platformba. Ez egy gyors, olcsó és kiváló megoldási lehetőség, ám nem minden esetben jövőálló. A Replatforming esetében már szükséges lehet valamilyen kódmódosítás, de nem kell újraírnunk az alkalmazást. Csupán annyi változtatást kell tennünk az alkalmazásban, hogy az új platform lehetőségeit minél jobban ki tudja használni. A Refactoring már jelenetheti azt, hogy micro service vagy serverless alapon történő újraírást végzünk. Ezen opciókat érdemes az előnyeikkel és hátrányaikkal együtt végiggondolnunk egy-egy alkalmazás esetében.

Weblogic és Windows nodes rehosting Microsoft Azure Kubernetes Service (AKS) megoldással

A Rehosting-ra egy jó példa az Oracle WebLogic futtatása Kubernetes-en. Számos nagyvállalati ügyfélnél vannak Enterprise Java-s alkalmazások, és sokan használnak Weblogic-ot ezeknek a futtatására. Az Oracle Weblogic futtatásának segítségével már lehetővé vált, hogy Kubernetes-en vagy AKS-en futtassuk ezeket a Weblogic szervereket. Itt többféle opció van, ezek közül az egyiknél gyakorlatilag nem is kell saját image-et buildelnünk, hanem az Oracle által biztosított Weblogic image-eket indítjuk el. Az alkalmazásokat és a konfigurációkat pedig már a Weblogic saját tool-jaiba juttatjuk be.

Tehát gyakorlatilag perzisztens volume-okra tároljuk el ezeket. Azzal, hogy nem kell saját image-eket buildelnünk és alkalmazáskódot módosítanunk, ez egy nagyon jó példája a Rehosting-nak. Ennek ellenére mégis megkapjuk a teljes Azure infrastruktúrának az előnyeit általa. Egy másik módon is használhatjuk, ez az operátor. Ilyenkor már saját image-eket bulidelünk és a domain konfigurációkat yaml formátumban írjuk le. Ez már egy kicsit jobban hasonlít egy cloud native megoldáshoz. Ezt már inkább Replatforming-nak hívhatjuk, amelyet szintén támogat az operátor.

Mire figyeljünk a Rehosting-nál?

Egy példa a Rehostingra, hogy az ügyfeleknél gyakran előjön az a kérdés, hogy noha a Linux és konténer-alkalmazásokat tudjuk használni, de vajon mi van a Windows .NET Framework-kel? Jó hír, hogy a Managed Kubernetes megoldások mind támogatják, hogy Windows node-okat is bevonjunk a klaszterünkbe. Windows 2019 Data Center node-ok lehetnek ezek, és itt fontos arra is figyelni, hogy maga a konténer-befogadó operációs rendszernek meg kell egyeznie a host operációs rendszerével. A patch-verziók szintjére is figyelni kell, ez már a Windows node-ok jellegzetessége. Ám, tekintve, hogy a technológia folyamatosan fejlődik, érdemes figyelemmel kísérni az újabb és újabb megoldásokat. Még azt is tanácsos meggondolni, hogy a .NET Framework-ös base image-ek nagyméretűek is lehetnek, akár 8-10 gigabájtos image-ek is előfordulhatnak. Egy másik opció lehet a .NET Core. Van olyan ügyfél, aki úgy dönt, hogy a NET Core-os alkalmazásokat konténerizálja.

Egy példa a Replatformingra, amikor 50-nél is több Legacy alkalmazást (Java, Enterprise Java, C++-os alkalmazások) konténerizáltunk. Itt Docker és Docker Compose volt a runtime, és 2 év alatt, gyakorlatilag anélkül, hogy az alkalmazásokat újra kellett volna írni, kisebb változtatásokkal, CI/CD-láncba illesztve, teljesen egységes platformot sikerült felépítenünk a Legacy alkalmazások számára.

Amikor sok alkalmazást kell rendszerezni a Legacy konténerizációs Scorecardra számíthatsz

Amennyiben sok Legacy alkalmazásunk van, érdemes valamiféle objektív mérőszámot meghatározni arra, hogy melyik lehet jó ezeknek a konténerizálására. Felállíthatunk akár egy prioritási listát is. Az Alerant-nak van erre egy Scorecard megoldása, amelyben nagyjából 40 szempont alapján súlyozzuk a Legacy alkalmazásokat.

Egyrészt érdemes csinálnunk egy összesített score-t, amely alapján sorrendbe tesszük az alkalmazásokat. Másrészt érdemes külön is készíteni egy úgynevezett konténerizációs score-t. Ennek alapján is felállíthatunk egy rangsort az alkalmazások között.

Hol van az Azure hozzáadott értéke?

A konténerek építése és telepítése automatizálható, a base image szabványosítható. A konténerek biztosítják a hordozhatóságot, akár az OpenShift platformra, akár publikus felhőbe. A konténerek garantálják, hogy minden egyes környezetben ugyanaz fut az operációs rendszertől az alkalmazásig az összes rétegen át. A szállító felelőssége egyértelműbbé válik, és lehetőséget ad működő alkalmazás futtató környezet előállítására. A konténerek által használt erőforrások így egységesen hangolhatóak, akár dinamikusan is. Ezáltal egyszerűbbé válik a konténerek és alkalmazások építése, valamint telepítése is.

A Legacy konténerizáció főbb előnyei:

  • Egységesség
  • Hordozhatóság
  • Konzisztencia
  • Egyértelmű szállítói felelősség
  • Erőforrás finomhangolás

Mi az, amit nem konténerizálunk az On-premise és felhőben?

Hogy mit tud adni a Microsoft Azure egy Legacy alkalmazás konténerizációjához? Gyakorlatilag egy end-to-end megoldást kapunk. Automatizált telepítés, menedzsment, monitorozás és biztonsági felület egyszerre. Egy teljes platformot kaphatunk a Legacy alkalmazásaink köré. Használhatjuk az Azure DevOps megoldást, az image-ünket az Azure Container Registry-be tudjuk tenni, futtathatjuk AKS-en vagy Azure Container Web App-ként. A rendszert tudjuk monitorozni, és számos eszközt kapunk a biztonsági felügyelethez egy Legacy alkalmazásnál is.

Ezekre a buktatókra figyeljünk AKS konténerizációkor!

Minden esetben érdemes azt figyelembe venni, hogy ha szétszedjük konténerekre az alkalmazást, akkor várhatóan valamekkora CPU- és memória növekedésre mindenképpen számítanunk kell. A Java-ban futó alkalmazások esetében volt divat nagyvállalatoknál, hogy gyűjtő domain-eket hoztak létre. Ha ezeket külön választjuk és külön-külön konténerenként futtatjuk, akkor nyilván a memóriaigény nagyobb lesz, ahogy a CPU igénye is. Ha a CPU és a memóriaigény nő, akkor a költség is növekszik. Minden egyes példánynak saját neve van, ezért ezeket pet-ként kezeljük. Ha egy példány elromlik, azt megpróbáljuk helyreállítani.

A Kubernetesben futó pod-ok cow jelleggel működnek alapértelmezésben. Ezeknek nincs neve, csak instance ID-ja. De a Kubernetes-ben is van lehetőség arra, hogy a Legacy alkalmazásokat pet-jelleggel működtessük. A release management kapcsán azt érdemes megfontolni, hogy a Legacy alkalmazások kiadása általában könyvtár struktúrában történt, például egy artifact-átadással. A Docker image-eknél többnyire egy artifact repository-t szoktunk használni, tehát szükséges lehet a release management folyamatok és eszközök részleges módosítása. Arra is érdemes figyelni, hogy nem olyan jó, ha a Legacy alkalmazásunk környezet-specifikus binárisokat használt. A Docker image-eknek általában környezetfüggetlennek kell lenniük, és a környezet-specifikus konfigurációkat verziókezelten egy repository-ba érdemes kiemelni.

A prod-os adabázisokkal vigyázni!

A prod-os adatbázisainkat nem javasolt konténerizálni. Ha ezeket modernizálni akarjuk, akkor általában a platform által nyújtott valamilyen menedzselt adatbázis megoldás lehet a jó irány. A Legacy integrációs komponenseket sem konténerizáljuk. Azokat az alkalmazásokat sem érdemes konténerizálni, amelyeket kevesen használnak.

Költségcsökkentés vagy jogszabályi megfelelés miatt előjöhet az is, hogy az alkalmazásainknak bizonyos komponenseit, egyes prod környezeteket nem lehet publikus felhőbe tenni. Itt az egyik lehetőség az Azure ExpressRoute használata, amely gyakorlatilag egy bérelt vonalnak felel meg. Ez nagyobb sávszélességet tud biztosítani, mint egy hagyományos site-to-site VPN-megoldás. Biztonságosabb is, hiszen itt a csomagok nem interneten „utaznak”, és a késleltetés is kisebb, mint a hagyományos site-to-site VPN-nél. Ugyanakkor fontos, hogy kisebb legyen a késleltetés, de nem nulla.

Hiszen, ha az optikai kábelen például Budapestről Nyugat-Európába – vagy oda-vissza – kell eljuttatni egy csomagot, akkor annak mindenképpen lesz valamennyi késleltetése. Ha az alkalmazásunk a publikus felhőben fut, ám jogi okokból on-premise marad, bizonyos alkalmazásoknál a késleltetés elfogadható, míg másoknál nem.

A másik opció, hogy egy hibrid platformot alkalmazunk. Az Azure Stack megoldásokat is használhatjuk itt. Az Azure Stack HCI-nél nemrég lett globálisan elérhető a Managed Kubernetes megoldás.

Ugyancsak fontos, hogy az alkalmazás konfigurációt kiemeljük, és ne a gépen szétszórva használjuk a konfigurációs fájlokat, mint például egy hagyományos Legacy alkalmazásnál.  Tanácsos kiemelni ezeket, és egy modern verzió kezelő rendszerben tárolni egy egységes struktúrában.

Egy jól konfigurált alkalmazás előnyei:

  • Visszanézhető, hogy ki mit mikor változtatott
  • Könnyű új környezetet létrehozni, ha minden környezet specifikus konfiguráció
  • egy helyen van
  • Könnyű CI/CD láncból deploy-olni
  • Könnyű két környezetet összehasonlítani, pl. hibakereséskor

 

Többet tudnál meg a Kubernetesről?
A második részben konkrét példákon keresztül mutatjuk be, hogyan tud értéket teremteni ez a technológia!

A teljes webinár itt érhető el. A több órás videókonferencia első témájáról – Kubernetes fejlesztés Microsoft Azure felhőtechnológiára alapozva – korábbi írásunkból tájékozódhattok.

A 2009-ben alapított, 100%-ban magyar tulajdonú, budapesti vállalkozásunk, a Kvazar.cloud több száz viszonteladó partnerrel dolgozik együtt. Mi vagyunk az egyik legnagyobb Microsoft felhőszolgáltatás-közvetítő partner Magyarországon. Hogy mi köze van egy Microsoft disztribútor cégnek a cloud native technológiához? Elsősorban az, hogy a hagyományos disztribúciós szerepkörből felhőszolgáltatás-közvetítővé (közvetett CSP disztribútor) léptünk elő.

Lépj kapcsolatba velünk!