WebSphere-alkalmazások migrálása az Azure Kubernetes Service-be

  • Cikk

Ez az útmutató azt ismerteti, hogy mire érdemes figyelnie, amikor meglévő WebSphere Application Server (WAS) számítási feladatokat szeretne migrálni az IBM WebSphere Libertybe vagy az Open Libertybe az Azure Kubernetes Service-ben (AKS).

A migrálás előtt

A sikeres migrálás biztosításához a kezdés előtt végezze el az alábbi szakaszokban leírt értékelési és leltározási lépéseket.

Győződjön meg arról, hogy a cél a megfelelő cél a migrálási munkához

A WAS-alkalmazások Azure-ba történő sikeres migrálásának első lépése a legmegfelelőbb migrálási cél kiválasztása.

A WAS hagyományosan jól működik az Azure-beli virtuális gépeken. A virtuális gép (VM) cél a legegyszerűbb választás, mivel a leginkább hasonlít egy helyszíni üzembe helyezésre. A virtuális gépek felügyeleti és üzembe helyezési élménye a helyszíni környezethez hasonló.

Egy másik lehetőség a tárolókba való migrálás a WAS hagyományos számítási feladatainak alkalmazástárolókká alakításával. A tárolócélt az Azure Kubernetes Service (AKS) és az Azure Red Hat OpenShift szolgáltatásban futtathatja. Ennek a könnyű kezelésnek a kompromisszumoje a gazdasági költség.

Általánosságban elmondható, hogy a virtuálisgép-alapú megoldások percenkénti költsége magasabb a tárolókhoz képest. Bár egy tárolóalapú megoldás futtatása kevesebbe kerül, korlátoznia kell az alkalmazást, hogy megfeleljen a tárolóvezénylési platform követelményeinek.

Ha a módosítás minimalizálása a migrálási munka legfontosabb tényezője, fontolja meg a virtuális gépalapú migrálást. Ebben az esetben lásd : WebSphere-alkalmazások migrálása azure-beli virtuális gépekre.

Ha el tudja viselni, hogy az alkalmazást tárolókon belüli futtatásra konvertálja a futtatókörnyezet költségeinek csökkentése érdekében, fontolja meg az AKS-alapú vagy az Azure Red Hat OpenShift-alapú migrálást.

Az AKS-alapú migráláshoz használhatja az ingyenes szintet. Ingyenes fürtkezelést kérhet, és csak a felhasznált virtuális gépekért, a társított tárterületért és a hálózati erőforrásokért kell fizetnie. Ebben az esetben lásd : WebSphere-alkalmazások migrálása az Azure Kubernetes Service-be.

Az Azure Red Hat OpenShift-alapú migrálás esetén az alkalmazáscsomópontok a számítási és infrastrukturális költségek mellett az OpenShift-licenc összetevőjének egy másik költségével is rendelkeznek. Ez a költség az alkalmazáscsomópontok száma és a példány típusa alapján kerül számlázásra. Igény szerinti díjszabást vagy fenntartott példányokat használhat, amelyik a legjobban megfelel a számítási feladat és az üzlet igényeinek. Ebben az esetben lásd : WebSphere-alkalmazások migrálása az Azure Red Hat OpenShiftbe.

Az Azure Red Hat OpenShift dokumentációjának útmutatói a migrálás szempontjából releváns szempontokat ismertetik. Az útmutatók teljes listáját az Azure Red Hat OpenShift dokumentációjában találja.

Annak meghatározása, hogy az előre összeállított Azure Marketplace-ajánlat jó kiindulópont-e

Miután úgy döntött, hogy az AKS a megfelelő üzembehelyezési cél, el kell fogadnia, hogy az IBM WebSphere Liberty operátor vagy az Open Liberty Operátor (az operátor) az egyetlen módja a Liberty kubernetesen való futtatásának. Miután elfogadta ezt a tényt, el kell döntenie, hogy az előre összeállított Azure Marketplace-ajánlat jó kiindulópont-e. Íme néhány megfontolandó szempont az előre összeállított Azure Marketplace-ajánlattal kapcsolatban:

  • Az IBM és a Microsoft azért hozta létre ezt az ajánlatot, hogy lehetővé tegye a Liberty gyors kiépítését az AKS-en. Ezt a fogalmat részletesebben az alábbi tartalom ismerteti.
  • Magas szinten az ajánlat automatizálja az alábbi lépéseket.
    • Szükség esetén készítsen egy meglévő alkalmazásképet.
    • Szükség esetén kiépül egy AKS-fürt és egy Azure Container Registry-példány (ACR).
    • Telepítse és konfigurálja az IBM WebSphere Liberty operátort vagy az Open Liberty operátort az AKS-en.
    • Az operátorral futtassa az egészet. Az operátor tárolóalapú Liberty-alkalmazásokat helyez üzembe és kezel az AKS-ben. A referenciadokumentációt az IBM WebSphere Liberty operátor és az Open Liberty operátorban találja.

Ha nem használja az előre összeállított Azure Marketplace-ajánlatot, meg kell tanulnia, hogyan használhatja közvetlenül az operátort. Az operátor elsajátítása meghaladja a jelen cikk hatókörét. Az operátor teljes dokumentációja elérhető az IBM WebSphere Liberty operátornál és az Open Liberty operátornál.

Most, hogy megismerkedett a Liberty AKS-en való kezelésének különböző módjaival, jobban eldöntheti, hogy az előre összeállított Azure Marketplace-ajánlatot használja-e, vagy közvetlenül az operátort használja.

Annak meghatározása, hogy a Liberty-verzió kompatibilis-e

Az alkalmazások Kubernetes-alapú fürtökön való üzembe helyezéséhez és kezeléséhez az Open Liberty operátorra vagy a WebSphere Liberty operátorra van szükség. Győződjön meg arról, hogy a meglévő Liberty-verzió az operátor által támogatott verziók egyike. Az Open Liberty verziói a GitHub OpenLiberty/open-liberty szolgáltatásban maradnak fenn. Az IBM fenntartja az IBM WebSphere Application Server Liberty verzióit. További információ: WebSphere Application Server Liberty.

Az előre összeállított Azure Marketplace-ajánlat lehetővé teszi az alkalmazásképek nyilvános beállításjegyzékből való kiválasztását, így implicit módon támogatja az összes verziót.

Annak meghatározása, hogy szükség van-e licencre

Az IBM WebSphere Liberty esetében el kell fogadnia az alkalmazástárolóban az IBM Program verziójának megfelelő licencszerződés feltételeit. A jelen IBM Programra vonatkozó licencszerződéssel kapcsolatban lásd a WebSphere Liberty operátor licencadatainak megtekintését. További információ: A WebSphere Liberty futtatása a Microsoft Azure-ban.

Ha a termékkiadás nem az alapértelmezett IBM WebSphere Application Server (alap), akkor meg .spec.license.edition value kell adnia a termék kiadását. További elérhető értékek az IBM WebSphere Application Server Liberty Core és az IBM WebSphere Application Server Network Deployment. Az előre összeállított Azure Marketplace-ajánlat lehetővé teszi a támogatott termékverzió kiválasztását.

Leltáreltérés az IBM migrálási eszközeivel

Ha az alkalmazásokat a Liberty vagy az Open Liberty WebSphere alkalmazáskiszolgálóra szeretné áthelyezni, terveznie kell a migrálást, elemeznie kell az alkalmazásait, és frissítenie kell a forráskódot. Az IBM migrálási eszközöket biztosít a jelenlegi környezet és az új Liberty-környezet technológiái közötti különbségek azonosításához, például a Java Enterprise kiadás 7 vagy a Java Enterprise kiadás 8, valamint a Java Standard kiadás 8 vagy a Java Standard kiadás 11 között. További információ: Alkalmazások migrálása a Libertybe.

A leltárkiszolgáló kapacitása

Dokumentálja az aktuális üzemi kiszolgáló(ok) hardverét (memóriáját, processzorát, lemezét), valamint az átlagos és csúcsidőszaki kérelmek számát és az erőforrás-kihasználtságot. Ezekre az információkra szüksége lesz a választott migrálási útvonaltól függetlenül. Hasznos lehet például a csomópontkészletben lévő virtuális gépek méretének, a tároló által használandó memória mennyiségének és a tároló által igényelt processzormegosztások számának kiválasztásában.

A csomópontkészletek átméretezhetők az AKS-ben. További információ: Csomópontkészletek átméretezése az Azure Kubernetes Service-ben (AKS).

Az összes titkos kód leltározása

A szolgáltatásként nyújtott konfigurációs technológiák (például az Azure Key Vault) elterjedése előtt a titkos kódok fogalma kissé homályos volt. Ehelyett olyan eltérő konfigurációs beállítások közül választhatott, amelyek tulajdonképpen a mai titkos kódoknak feleltek meg. Az olyan alkalmazáskiszolgálók esetében, mint a WAS, ezek a titkos kódok számos különböző konfigurációs fájlban és konfigurációs tárolóban találhatók. Ellenőrizze az éles kiszolgáló(k) minden tulajdonságát és konfigurációs fájlját titkos kódokhoz és jelszavakhoz. Az alkalmazásban jelszavakat vagy hitelesítő adatokat tartalmazó konfigurációs fájlok is szerepelhetnek. A WAS több dokumentumban tárolja a konfigurációs adatokat a címtárak kaszkádolt hierarchiájában. A legtöbb konfigurációs dokumentum XML-tartalommal rendelkezik. További információkért tekintse meg a konfigurációs dokumentumokat és az Azure Key Vault alapfogalmait.

Miután szilárd leltárt végzett a titkos kódokról, tekintse meg az operátor titkos kulcsokkal kapcsolatos dokumentációját. További információért tekintse át az alábbi cikkeket:

Az összes tanúsítvány leltározása

Dokumentáljon minden, nyilvános SSL-végponthoz használt tanúsítványt. A következő parancs futtatásával megtekintheti az éles kiszolgáló(ko)n található összes tanúsítványt:

keytool -list -v -keystore <path to keystore>

Miután szilárd leltárt készített a tanúsítványokról, konfigurálja őket az alábbi cikkek használatával:

Annak ellenőrzése, hogy a támogatott Java-verzió megfelelően működik-e

A Liberty használatához a Java egy adott verziója szükséges, ezért ellenőriznie kell, hogy az alkalmazás megfelelően fut-e a támogatott verzióval.

A WebSphere Application Server Liberty futtatókörnyezetének meghatározott követelményei vannak a Java Futtatókörnyezet (JRE) minimális szintjére vonatkozóan. További információt a Funkciók Java-verziófüggőségeit ismertető cikkben talál.

Az Open Liberty használatához Java-Standard kiadás futtatókörnyezetre van szükség. Futtatható Java Runtime Environment (JRE) vagy Java Standard kiadás Development Kit (JDK) disztribúcióval. További információ: Támogatott Java-Standard kiadás kiadások.

JNDI-erőforrások leltározása

Leltározzon minden JNDI-erőforrást. Előfordulhat például, hogy az adatforrások (például az adatbázisok) olyan JNDI-névvel rendelkeznek, amely lehetővé teszi, hogy a JPA helyesen kössön EntityManager-példányokat egy adott adatbázishoz. További információ a JNDI-erőforrásokról és -adatbázisokról: WebSphere Data Sources in the IBM documentation. Egyéb JNDI-erőforrások (például a JMS-üzenetközvetítők) migrálást vagy újrakonfigurálást igényelhetnek. A JMS-konfigurációval kapcsolatos további információkért lásd : JMS-erőforrások használata.

Ha az előre összeállított Azure Marketplace-ajánlatot használja, az üzembe helyezéskor testre szabható JNDI-erőforrások készlete az ajánlat által támogatottakra korlátozódik. Az AKS-en futó WebSphere Liberty esetében elérhetővé tehet egy objektumot az alapértelmezett Java Naming and Directory Interface (JNDI) névtérben. További információ: Fejlesztés a JNDI alapértelmezett névterével a Liberty szolgáltatásban. Az Open Liberty esetében lásd a Java elnevezését és a címtár-kezelőfelületet.

Profilkonfiguráció vizsgálata

A WAS fő konfigurációs egysége a profil. Ezért a resources.xml fájl számos konfigurációt tartalmaz, amelyeket alaposan meg kell fontolnia a migráláshoz. A fájl más, alkönyvtárakban tárolt XML-fájlokra mutató hivatkozásokat tartalmaz. További információ: Profilok kezelése elosztott és IBM i operációs rendszereken.

Az alkalmazáson belül

Vizsgálja meg a deployment.xml fájlt és/vagy a WEB-INF/web.xml fájlt.

Ezeket a testreszabásokat az AKS által futtatott tárolórendszerképben kell rögzítenie. Ha az előre összeállított Azure Marketplace-ajánlatot használja, az ilyen testreszabásokat a legjobban úgy lehet kezelni, hogy létrehoz egy egyéni tárolórendszerképet, és elérhetővé teszi azt egy nyilvános beállításjegyzékben, majd az üzembe helyezéskor erre a beállításjegyzékre mutat.

Ha WebSphere Application Server hálózati üzembehelyezési cellát használ, minden fürttag a hagyományos WAS telepítésében fut. A Liberty a WebSphere Application Server egyszerűsített profilja. Ez a WAS rugalmas és dinamikus profilja, amely lehetővé teszi, hogy a WAS-kiszolgáló csak a szükséges egyéni funkciókat helyezze üzembe ahelyett, hogy nagy számú rendelkezésre álló Java-Enterprise kiadás-összetevőt helyez üzembe.

Annak meghatározása, hogy az alkalmazás munkamenet-replikációt használ-e

Ha az alkalmazás munkamenet-replikációra támaszkodik, a következő lehetőségek közül választhat:

  • HTTP-munkamenetek esetén a munkamenet-kezelés szintjének megfelelően gyorsítótárral vagy adatbázissal gyűjtheti a munkamenet-adatokat.
  • Elosztott munkamenetek esetén adatbázis-munkamenetek megőrzésével mentheti a munkameneteket az adatbázisban.
  • Dinamikus gyorsítótár esetén kezelheti a munkamenet-adatokat a gyorsítótárban vagy az adatbázisban.
  • Az alkalmazás újrabontásával adatbázist használhat a munkamenet-kezeléshez.
  • Az alkalmazás újrabontásával külsőssé teheti a munkamenetet az Azure Redis Service-ben. További információ: Azure Cache for Redis.

Mindezekhez a lehetőségekhez érdemes elsajátítani, hogyan végzi el a Liberty a HTTP-munkamenetállapot-replikációt. Az alábbi dokumentumok segítenek megérteni, hogyan kezelheti a HTTP-munkameneteket a Libertyben:

Az előre összeállított Azure Marketplace-ajánlat támogatja a munkamenet-affinitást az Application Gateway bejövőforgalom-vezérlőn keresztül. Az ajánlat üzembe helyezésekor válassza a Cookie-alapú affinitás engedélyezése lehetőséget.

Dokumentum-adatforrások

Ha az alkalmazása adatbázisokat használ, Önnek rögzítenie kell az alábbi adatokat:

  • Mi az adatforrás neve?
  • Milyen a kapcsolatkészlet konfigurációja?
  • Hol található a JDBC-illesztőprogram JAR-fájlja?

A WAS JDBC-illesztőprogramjaival kapcsolatos további információkért lásd : JDBC-illesztőprogramok használata a WebSphere Alkalmazáskiszolgálóval.

A JDBC-konfiguráció a Liberty egyik alapvető kiszolgálókonfigurációja. További információ: JDBC-illesztőprogram.

Az előre összeállított Azure Marketplace-ajánlat korlátozott mértékben támogatja az adatbázisokat. Az ajánlat üzembe helyezésekor kezelheti az alkalmazás lemezképeiben található konfigurációt, és használhatja a rendszerképet.

Annak meghatározása, hogy a WAS testre lett-e szabva

Határozza meg, hogy a következő testreszabások közül melyik lett végrehajtva, és rögzítse, mi történt.

  • Módosultak az indítási szkriptek? Ilyen szkriptek például a wsadmin, Rendszergazda Control, Rendszergazda Config, Rendszergazda App és Rendszergazda Task.
  • Küld adott paramétereket a JVM-nek az alkalmazás?
  • Tartalmaz JAR-fájlokat a kiszolgáló osztályútvonala?
  • Használták-e az operációsrendszer-szintű létesítményeket, például systemd arra, hogy a WAS-összetevők automatikusan elinduljanak a kiszolgáló újraindítása után?

A migrálással kapcsolatos szempontokat figyelembe kell vennie a kérdésekre adott válaszoktól függően.

Ezeket a testreszabásokat az AKS által futtatott tárolórendszerképben kell rögzítenie. Ha az előre összeállított Azure Marketplace-ajánlatot használja, az ilyen testreszabásokat a legjobban úgy lehet kezelni, hogy létrehoz egy egyéni tárolórendszerképet, és elérhetővé teszi azt egy nyilvános beállításjegyzékben, majd az üzembe helyezéskor erre a beállításjegyzékre mutat.

Annak megállapítása, hogy szükséges-e helyszíni kapcsolat

Ha az alkalmazásnak hozzá kell férnie helyszíni szolgáltatásokhoz, ki kel építenie egy Azure-beli kapcsolati szolgáltatást. További információ: Megoldás választása a helyszíni hálózat Azure-hoz való csatlakoztatásához. Másik megoldásként újrabonthatja az alkalmazást, hogy az nyilvánosan elérhető, a helyszíni erőforrások által közzétett API-kat használjon.

Állapítsa meg, hogy használ-e Java Message Service- (JMS-) üzenetsorokat és -témákat

Ha az alkalmazás JMS-üzenetsorokat vagy témaköröket használ, át kell telepítenie őket egy külsőleg üzemeltetett JMS-kiszolgálóra. A JMS-t használó felhasználók egyik stratégiája az Azure Service Bus és az Advanced Message Queuing Protocol használata. További információkért lásd: A JMS használata az Azure Service Busszal és az AMQP 1.0-val.

Ha konfigurálta a JMS állandó tárolóit, rögzítenie kell a konfigurációjukat, és alkalmaznia kell azt az áttelepítés után.

Ha IBM MQ-t használ, migrálhatja ezt a szoftvert az Azure Virtual Machinesbe, és használhatja is.

A Microsoft megoldást kínál az IBM MQ és a Logic Apps integrálására. További információ: Csatlakozás egy IBM MQ-kiszolgálóra az Azure Logic Apps munkafolyamatából.

Annak meghatározása, hogy saját, egyénileg létrehozott megosztott Java EE-könyvtárakat használ-e

Ha a megosztott Java EE-könyvtár funkciót használja, két lehetősége van:

  • Bontsa újra az alkalmazás kódját a könyvtárak minden függőségének eltávolításához, majd foglalja közvetlenül az alkalmazásba a funkciókat.
  • Adja hozzá a könyvtárakat a kiszolgáló osztályútvonalához.

Ezeket a kódtárakat ugyanazokkal a technikákkal kezelheti, mint a Külső API-k elérése Java-Enterprise kiadás-alkalmazásokból.

Annak meghatározása, hogy a kiszolgáló OSGi-csomagokat használ-e

Ha a WAS-hoz hozzáadott OSGi-csomagokat használta, az egyenértékű JAR-fájlokat közvetlenül a webalkalmazáshoz kell hozzáadnia.

A csomagokat belefoglalhatja az előre összeállított Azure Marketplace-ajánlathoz megadott képbe. További információ: Kódtárak konfigurálása OSGi-alkalmazásokhoz.

Annak meghatározása, hogy az alkalmazás tartalmaz-e az operációs rendszerre vonatkozó kódot

Ha az alkalmazás tartalmaz a gazdagép operációs rendszeréhez tartozó függőségekkel rendelkező kódot, azt Önnek újra kell bontania a függőségek eltávolításához. Előfordulhat például, hogy a File.Separator vagy Paths.get fájlrendszerbeli útvonalakkal rendelkező /- vagy \-előfordulásokat cserélnie kell.

A Liberty az AKS-en Linux x86_64 fut. Minden operációsrendszer-specifikus kódnak kompatibilisnek kell lennie a Linuxdal. Ha meg szeretné tudni, hogyan deríthet fel konkrét operációsrendszer-információkat, kövesse a Liberty-verzió kompatibilisségének megállapítására vonatkozó szakasz lépéseit.

Annak meghatározása, hogy az IBM Integration Bus használatban van-e

Ha az alkalmazás IBM Integration Bust használ, rögzítenie kell az IBM Integration Bus konfigurálását. További információkért lásd az IBM Integration Bus dokumentációját.

Az ELŐRE összeállított Azure Marketplace-ajánlat nem támogatja közvetlenül az IBM Integration Bust. A funkció engedélyezéséhez kövesse az IBM dokumentációjában található JMS-alkalmazásNak a Liberty szolgáltatásintegrációs buszhoz való csatlakozásának engedélyezésére vonatkozó utasításait.

Annak meghatározása, hogy az alkalmazás több WAR-fájlból áll-e

Ha az alkalmazása több WAR-fájlból áll, ezeket különálló alkalmazásként kell kezelnie, és az útmutató lépéseit egyenként elvégeznie mindegyikhez.

Annak megállapítása, hogy az alkalmazás EAR-ként van-e csomagolva

Ha az alkalmazás EAR-fájlként van csomagolva, mindenképpen vizsgálja meg a application.xml, az ibm-application-bnd.xmi és az ibm-application-ext.xmi fájlokat, és rögzítse a konfigurációikat. További információ: A vállalati archívum (EAR) csomag létrehozása a WebSphere-en.

Az előre összeállított Azure Marketplace-ajánlat lehetővé teszi egy meglévő tárolórendszerkép használatát. Az alkalmazást az üzleti követelményeknek megfelelően készítheti elő.

Az éles kiszolgálókon futó összes külső folyamat és démon azonosítása

Ha rendelkezik az alkalmazáskiszolgálón kívül futó folyamatokkal, például figyelési démonokkal, ezeket el kell távolítania, vagy máshová kell migrálnia.

Határozza meg, használják-e a fájlrendszert, és ha igen, hogyan

A Kubernetes állandó kötetekkel (PV) rendelkező fájlrendszerekkel foglalkozik. Az előre összeállított Azure Marketplace-ajánlat nem támogatja az állandó kötetek csatlakoztatását. A különböző tárolási lehetőségek engedélyezéséhez kövesse az Azure Kubernetes Service-alkalmazások tárolási beállításainak utasításait.

Csak olvasható statikus tartalom

Ha az alkalmazás jelenleg statikus tartalmat szolgáltat, szüksége lesz egy másik helyre hozzá. A statikus tartalmat célszerű az Azure Blob Storage-ba helyezni és az Azure CDN hozzáadásával biztosítani a villámgyors globális letöltést. További információ: Statikus webhely üzemeltetése az Azure Storage-ban és rövid útmutató: Azure Storage-fiók integrálása az Azure CDN-nel. A statikus tartalmat közvetlenül is üzembe helyezheti egy alkalmazáson az Azure Spring Apps Enterprise-csomagban. További információ: Webes statikus fájlok üzembe helyezése.

Dinamikusan közzétett statikus tartalom

Ha az alkalmazás engedélyezi az alkalmazás által feltöltött/előállított statikus tartalmakat, azonban a létrehozás után nem módosítható, az Azure Blob Storage és az Azure CDN fent ismertetett módon történő, egy Azure-függvénnyel közös használatával kezelheti a feltöltéseket és a CDN-frissítést. A Statikus tartalom feltöltése és CDN-előtöltése az Azure Functions szolgáltatással című témakörben megadtunk egy szabadon használható mintaimplementációt. A statikus tartalmat közvetlenül is üzembe helyezheti egy alkalmazáson az Azure Spring Apps Enterprise-csomagban. További információ: Webes statikus fájlok üzembe helyezése.

A hálózati topológia meghatározása

Az Azure Marketplace-ajánlatok jelenlegi készlete a migrálás kiindulópontja. Ha az ajánlat nem fedi le az áttelepítendő architektúra aspektusait, rögzítenie kell a meglévő üzembe helyezés hálózati topológiáját. Ezután reprodukálnia kell ezt a topológiát az Azure-ban, még akkor is, ha az alapajánlatot az egyik megoldássablonnal kiállta.

A hálózati topológia széles körű témakör, de az alábbi hivatkozások segíthetnek a migrálási erőfeszítésekben:

JCA-adapterek és erőforrás-adapterek használatának fiókja

Ha a meglévő alkalmazás JCA-adaptereket vagy erőforrás-adaptereket használ más vállalati rendszerekhez való csatlakozáshoz, győződjön meg arról, hogy az összetevők konfigurációját az AKS-en futó Liberty-kiszolgálóra alkalmazza. További információ: A JCA konfigurációs elemeinek és a Java Csatlakozás or architektúrájának áttekintése.

Annak meghatározása, hogy a fürtözést használják-e

Az operátor kezeli a fürtözést a WAS számítási feladatok AKS-en való futtatásának minden lehetséges módjához.

Az EJB-fürtözés vizsgálata

Ha az alkalmazás helyi Enterprise Java Babot (EJB) használ, előfordulhat, hogy át kell telepítenie őket egy fürtözött EJB-be. További információ: EJB-alkalmazások fejlesztése a Liberty szolgáltatásban.

Terheléselosztási követelmények figyelembe vétele

A terheléselosztást a legjobban úgy lehet figyelembe venni, ha a beépített Azure Marketplace-ajánlat által biztosított App Gateway-integrációt használja.

Migrálás

Az ebben a szakaszban ismertetett lépések feltételezik, hogy az elemzés arra késztette, hogy az előre összeállított Azure Marketplace-ajánlat használata mellett döntsön.

Az ajánlat kiépítése

Az ajánlat az Azure Portalon való megnyitásához tekintse meg az IBM WebSphere Liberty és az Open Liberty szolgáltatást az Azure Kubernetes Service-ben. Válassza a Létrehozás lehetőséget, majd használja az előző lépésekben összegyűjtött információkat az ajánlat mezőinek kitöltéséhez.

A kulcstárak számba vétele

Figyelembe kell vennie az alkalmazás által használt SSL/TLS keyStore-k migrálását. További információ: Kulcstárak konfigurálása.

A JMS-erőforrások összekötése

Miután csatlakoztatta az adatbázisokat, konfigurálhatja a JMS-t az IBM dokumentációjának JCA-konfigurációs elemeinek áttekintésével.

A naplózás számba vétele

A naplózás elsajátítása nélkül nem végezhet felhőt. Az operátor különböző megközelítéseket biztosít a monitorozáshoz. További információ: A Liberty-kiszolgáló futtatókörnyezetének figyelése. Ha az Elastic Stacket szeretné használni, az Azure nagy támogatást nyújt az Elastic számára. További részletekért lásd : Mi az Azure rugalmas integrációja? A két erőforrás ismeretét kombinálva azure-ra optimalizált naplózási megoldást érhet el a Libertyhez az AKS-en.

Alkalmazások áttelepítése

Függetlenül attól, hogy az üzembe helyezéskor az alkalmazás lemezképét adja-e meg, frissítenie kell az alkalmazást CI/CD-n keresztül. Az IBM dokumentációjában található egy minta, amely bemutatja, hogyan kell elvégezni ezt a frissítést. További információ: Alkalmazások üzembe helyezése a Libertyben.

Tesztek konfigurálása

Konfigurálnia kell a tárolón belüli teszteket az alkalmazásokon, hogy hozzáférjenek az Azure-ban futó új kiszolgálókhoz. A CI/CD-vel kapcsolatos aggodalmakhoz hasonlóan gondoskodnia kell arról, hogy a szükséges hálózati biztonsági szabályok lehetővé tegyék a tesztek számára az Azure-ban üzembe helyezett alkalmazások elérését. További információ: Hálózati biztonsági csoportok.

A migrálás után

A migrálást megelőző folyamatok lépésben meghatározott célok elérése után teljes körű elfogadási tesztelést végezhet, hogy ellenőrizze, hogy minden a várt módon működik. Az alábbi cikkek a migrálás utáni fejlesztésekről nyújtanak tájékoztatást: