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

  • Cikk

Ez az útmutató azt ismerteti, hogy mire érdemes figyelnie, ha egy meglévő WebLogic Server-(WLS-) alkalmazást szeretne migrálni az Azure Kubernetes Service (AKS) szolgáltatásban való futtatáshoz.

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 WLS-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 WLS jól működik Azure-beli virtuális gépeken (virtuális gépeken) vagy az Azure Kubernetes Service-en (AKS). A virtuálisgép-cél a legegyszerűbb választás, mivel leginkább egy helyszíni üzembe helyezéshez hasonlít. A virtuális gépek felügyeleti és üzembe helyezési élménye nagyon hasonló ahhoz, ami a helyszínen található. Ennek a könnyű kezelésnek a kompromisszumoje a gazdasági költség. Általánosságban elmondható, hogy egy virtuálisgép-alapú megoldás percenkénti költsége magasabb az AKS-hez képest. Bár az AKS-alapú megoldások futtatása kevesebbe kerül, korlátoznia kell az alkalmazást, hogy megfeleljen az AKS 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 : WebLogic-alkalmazások migrálása azure-beli virtuális gépekre. Ha el tudja viselni az alkalmazás Kubernetesen belüli futtatásra való konvertálását a futásidejű költségek csökkentése érdekében, fontolja meg az AKS-alapú migrálást. Ebben az esetben folytassa a WebLogic Server-alkalmazások migrálásával az Azure Kubernetes Service-be.

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

Miután eldöntötte, hogy az AKS a megfelelő üzembehelyezési cél, el kell fogadnia, hogy az Oracle WLS Kubernetes operátor (az operátor) az egyetlen módja a WLS kubernetes-alapú 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 Oracle és a Microsoft azért hozta létre ezt az ajánlatot, hogy lehetővé tegye a WLS gyors kiépítését az AKS-en a Modell képtartomány kezdőlapjának forrástípusával. Ezt a fogalmat a cikk későbbi részében részletesebben ismertetik.
  • Magas szinten az ajánlat automatizálja az alábbi lépéseket.
    • Szükség esetén készítsen egy meglévő WAR- vagy EAR-üzembe helyezést.
    • Csomagolja be egy tárolóba a WebLogic Image Tool (WIT) használatával. További információ: WebLogic Image Tool az Oracle dokumentációjában.
    • Telepítse és konfigurálja a WebLogic Kubernetes Operátort az AKS-en.
    • Az operátorral futtassa az egészet. Az operátor meghívja a WebLogic Deploy Toolinget (WDT) a WebLogic-környezetek felállítása és a tartományi életciklus-műveletek megismételhető módon, metaadatmodell alapján történő végrehajtásához. További információ: WebLogic Deploy Tooling az Oracle dokumentációjában.
  • Bár az előre összeállított ajánlat számos Azure-szolgáltatásintegrációt biztosít, például az App Gatewayt, a rugalmas naplózást, az adatbázis-integrációt és egyebeket, számos leegyszerűsítő feltételezést tesz lehetővé. Ezek a feltételezések nem teszik olyan rugalmassá az ajánlatot, mint az operátor elsajátítása és használata.

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. A WLS Kubernetes-operátor teljes dokumentációja elérhető az Oracle-nél.

A szakasz további része megfontolandó szempontokat tartalmaz az előre összeállított Azure Marketplace-ajánlat vagy az operátor közvetlen használata mellett.

Döntse el, hogy használja-e az előre összeállított Azure Marketplace-ajánlatot

Először is meg kell értenie a WLS "tartomány" fogalmát. A tartomány a WLS-erőforrások logikailag kapcsolódó csoportja. A WLS-tartomány canonical definícióját az Oracle dokumentációjában találja. A WLS AKS-en való futtatásához el kell döntenie, hogyan kezeli az AKS a tartományokat. A különböző lehetőségeket "tartomány kezdő forrástípusának" nevezzük. A WLS Kubernetes operátor háromféle tartomány kezdő forrástípusát támogatja. Az előre összeállított Azure Marketplace-ajánlat a táblázat első ajánlatát használja.

Tartomány kezdő forrástípusa Leírás Pozitív szempontok Negatív szempontok
Modell képben A WLS és az alkalmazások a tárolórendszerképben találhatók, és minden más a lemezképen kívül marad. Előre összeállított ajánlat támogatja. Hivatalos mintaként dokumentálva; lásd: Oracle. A legtöbben a WDT-t használják. A legtöbb "natív felhő" lehetőség. A legegyszerűbb CI/CD-integráció. A legnagyobb tanulási görbe.
Tartomány a PV-ben A tartomány egy Kubernetes-állandó köteten található. Elméletileg hasonló a virtuális gépeken való futtatáshoz. A WLS-konzollal módosításokat hajthat végre, és ezek a módosítások az AKS-pod újraindítása során is megmaradnak. Hivatalos mintaként dokumentálva; lásd: Oracle. Az NFS-sel kapcsolatos problémákat enyhíteni kell. További információ: Oracle. Ez a módszer a legkevésbé "natív felhőbeli" technika; az állapot teljes egészében az AKS-fürtön kívül található.
Tartomány a képben A tartomány egy tárolórendszerképben található. Az alkalmazások egy olyan tárolórendszerképben találhatók, amely túl van kapcsolva a tartomány lemezképén. Több "natív felhő", mint a tartomány a PV-ben. A CI/CD könnyebben használható. A WLS-konzol nem használható. Több tárolórendszerképet kell fenntartania.

Fontos

Ha a tartományt PV-forrástípusban választja, erősen javasoljuk az NFS használatát az SMB helyett. Az NFS a UNIX operációs rendszerből és más változatokból, például a GNU/Linuxból fejlődött ki. Ezért ha az NFS-t olyan tárolótechnológiákkal használja, mint a Docker, kevésbé valószínű, hogy egyidejű olvasási és fájlzárolási problémák merülnek fel.

Mindenképpen engedélyezze az NFS v4.1-et. A 4.1-nél kisebb verziók problémái lesznek.

Az operátor dokumentációja egy hasznos táblázatot is tartalmaz, amely összehasonlítja a különböző lehetőségeket. További információ: Tartomány kezdő forrástípusának kiválasztása.

Az előre összeállított Azure Marketplace-ajánlatról a következő rövid útmutatóban olvashat : WebLogic-kiszolgáló üzembe helyezése az Azure Kubernetes Service-ben az Azure Portal használatával. Az előre összeállított Azure Marketplace-ajánlat referenciadokumentációját az Oracle-ben találja.

Az operátor közvetlen használatához próbálja ki az operátor dokumentációjában található mintákat.

Most, hogy megismerkedett a WLS-tartományok 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.

Állapítsa meg, hogy a WebLogic-verzió kompatibilis-e

A meglévő WLS-verziónak az operátor által támogatott verziók egyikének kell lennie. Az Oracle ezeket a verziókat az Oracle Container Registryben (OCR) tartja fenn. A támogatott verziók listájának megtekintéséhez kövesse az alábbi lépéseket.

  1. Látogasson el az Oracle Container Registry webhelyére, és jelentkezzen be. További információ: https://container-registry.oracle.com/.
  2. Ha támogatási jogosultsága van, válassza a Köztes szoftver lehetőséget, majd keresse meg a weblogic_cpu. Válassza a weblogic_cpu.
  3. Ha nem rendelkezik az Oracle támogatási jogosultságával, válassza a Middleware lehetőséget, majd keresse meg a weblogicot. Válassza a weblogic lehetőséget.

Feljegyzés

Éles környezetbe való kezdés előtt szerezze be a támogatási jogosultságot az Oracle-től. Ennek elmulasztása nem biztonságos képek futtatását eredményezi, amelyek nincsenek javítva a kritikus biztonsági hibák miatt. Az Oracle kritikus javításfrissítéseiről további információt a Kritikus javítások Frissítések, a biztonsági riasztások és a közlemények című témakörben talál.

Az előre összeállított Azure Marketplace-ajánlat lehetővé teszi a WLS-rendszerképek kiválasztását az OCR-ből és az Azure Container Registryből (ACR), így implicit módon támogatja az OCR-ből elérhető összes verziót. Ha az ajánlatot arra utasítja, hogy lekérjen egy képet az ACR-ből, győződjön meg arról, hogy a rendszerkép az OCR-ben felsorolt támogatott verziók egyikéből származik.

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 alkalmazáskiszolgálóknak (például a WebLogic-kiszolgálónak) köszönhetően ezek a titkos kódok számos eltérő konfigurációs fájlban é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. Ellenőrizze a WAR-fájlok weblogic.xml fájlját is. Az alkalmazásban jelszavakat vagy hitelesítő adatokat tartalmazó konfigurációs fájlok is szerepelhetnek. További információ: Azure Key Vault – alapvető fogalmak.

Miután szilárd készlettel rendelkezik a titkos kódokról, tekintse meg az operátor titkos kulcsokkal kapcsolatos dokumentációját. További információ: Titkos kódok.

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 rendelkezik a tanúsítványok szilárd készletével, közvetlenül telepítheti őket az előre összeállított Azure Marketplace-ajánlattal. További információ: TLS/SSL-konfiguráció. Ha közvetlenül használja az operátort, olvassa el az operátor külső tanúsítványainak frissítése című témakört.

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

A WebLogic Azure-ba történő migrálásának minden adott útvonalához egy másik Java-verzió szükséges. Ellenőriznie kell, hogy az alkalmazása megfelelően működhet-e az adott támogatott verzió használatával.

Feljegyzés

Ez az ellenőrzés különösen fontos, ha az aktuális kiszolgáló egy nem támogatott JDK-n fut (például az Oracle JDK-n vagy az IBM OpenJ9 rendszeren).

A jelenlegi Java-verzió beszerzéséhez jelentkezzen be az éles kiszolgálóra, és futtassa a következő parancsot:

java -version

Feljegyzés

Az Azure-beli virtuális gépeken futó WLS-re való migráláskor az adott Java-verziókra vonatkozó követelményeket az előre telepített Java határozza meg a virtuális gépeken. Az AKS-en futó WLS-re való migráláskor az adott Java-verziót a kiválasztott tárolórendszerkép határozza meg. Számos lehetőség közül választhat, de mindegyik az Oracle JDK-t használja.

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ót a JNDI-erőforrásokról és -adatbázisokról az Oracle-dokumentáció A WebLogic-kiszolgáló adatforrásai című témakörében találhat. 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: Oracle WebLogic Server 12.2.1.4.0.

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. Keresse meg a JNDI-t az ajánlat dokumentációjában. Ha közvetlenül használja az operátort, a JDNI-erőforrások a választott tartomány kezdő forrástípusától függően határozhatók meg. A PV-ben lévő tartomány esetében a szokásos módon állíthatja be őket a WLST-vel vagy a felügyeleti konzollal. A Rendszerkép tartománya vagy a Kép modellje esetében lásd a Tipikus felülbírálások című témakört.

A tartomány konfigurációjának vizsgálata

A WebLogic-kiszolgáló fő konfigurációs egysége a tartomány. Ennek megfelelően a config.xml fájl olyan konfigurációkat tartalmaz, amelyeket figyelembe kell vennie a migrálás során. A fájl az alkönyvtárakban tárolt további XML-fájlokra mutató hivatkozásokat tartalmaz. Az Oracle azt javasolja, hogy a felügyeleti konzollal konfigurálja a WebLogic-kiszolgáló felügyelhető objektumait és szolgáltatásait, és engedélyezze a WebLogic-kiszolgáló számára a config.xml fájl karbantartását. További információ: Tartománykonfigurációs fájlok.

Az alkalmazáson belül

Tekintse meg a WEB-INF/weblogic.xml ás/vagy a WEB-INF/web.xml fájlt.

Az előre összeállított Azure Marketplace-ajánlat automatikusan létrehoz egy tartományi erőforrást. Ha közvetlenül használja az operátort, teljesen testre szabhatja a tartomány ábrázolása módját. További információ: Tartományerőforrás.

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

Ha az alkalmazás munkamenet-replikációt használ – Oracle Coherence*Web segítségével vagy anélkül –, három lehetősége van:

  • A Coherence*Web az Azure-beli virtuális gépeken a WebLogic-kiszolgálóval együtt is futhat, azonban Önnek manuálisan konfigurálnia kell ezt a beállítást az ajánlat kiépítése után. Ha különálló Coherence-et használ, ezt egy Azure-beli virtuális gépen is futtathatja, azonban ehhez manuálisan konfigurálnia kell ezt a beállítást az ajánlat kiépítése után.
  • Bontsa újra az alkalmazást munkamenet-kezeléshez szükséges adatbázis használatához.
  • Bontsa újra az alkalmazást az Azure Redis Service-ben való külső elérhetővé tételéhez. További információ: Azure Cache for Redis.

Az összes opció esetében érdemes elsajátítani, hogy a WebLogic hogyan végzi el a HTTP-munkamenetek állapotának replikálását. További információt az Oracle-dokumentáció HTTP-munkamenetek állapotának replikációja című témakörében találhat.

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. Keresse meg a cookie-alapú affinitást az ajánlat dokumentációjában.

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?

További információ a WebLogic JDBC-illesztőprogramjairól: JDBC-illesztőprogramok használata a WebLogic-kiszolgálóval.

Az előre összeállított Azure Marketplace-ajánlat támogatja a legnépszerűbb adatbázisok használatát. További információ: Adatbázis. A PV-ben lévő tartomány esetében a szokásos módon állíthatja be őket a WLST-vel vagy a felügyeleti konzollal. A Rendszerkép tartománya vagy a Kép modellje esetében lásd a Tipikus felülbírálások című témakört.

Annak megállapítása, hogy a WebLogic testre van-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 szkript például a setDomainEnv, commEnv, startWebLogic, és stopWebLogic.
  • Küld adott paramétereket a JVM-nek az alkalmazás?
  • Tartalmaz JAR-fájlokat a kiszolgáló osztályútvonala?

Ezeket a testreszabásokat az AKS által futtatott tárolórendszerképben kell rögzítenie. Az előre összeállított Azure Marketplace-ajánlat esetében az ilyen testreszabásokat egy egyéni tárolórendszerkép létrehozásával és az Azure Container Registryben való elérhetővé tételével érdemes kezelni, majd az üzembe helyezéskor erre a beállításjegyzékre mutatni. További információ: Képkijelölés. Ha közvetlenül használja az operátort, tekintse meg a JVM memória- és Java-beállítás környezeti változóit.

Annak meghatározása, hogy használatban van-e a Management over REST

Ha az alkalmazás életciklusa Management over REST-et tartalmaz, rögzítenie kell, hogy mely portokat használja a rendszer a REST API eléréséhez, valamint meg kell határoznia ezek hitelesítési és közzétételi módját. A migrálás után meg kell győződnie arról, hogy ezek a portok és hitelesítési mechanizmusok közzé vannak téve, hogy az alkalmazás életciklusa a migrálási előtti módon működhessen. További információ: Az Oracle WebLogic-kiszolgáló felügyelete a RESTful Management Services segítségével.

Az egyetlen tartomány kezdő forrástípusa, ahol érdemes a REST-en keresztül továbbra is használni a felügyeletet, az a tartomány a PV-ben. Használhatja a többi tartomány otthoni forrástípusával is, de a módosítások rövid élettartamúak, és nem maradnak meg a pod újraindításai között.

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ása JMS-üzenetsorokat vagy -témákat használ, azokat egy külsőleg üzemeltetett JMS-kiszolgálóra kell migrálnia. Az Azure Service Bus és az Advanced Message Queueing Protocol remek migrálási stratégia lehet a JMS-t használóknak. További információkért lásd: A JMS használata az Azure Service Busszal és az AMQP 1.0-val.

Ha a JMS állandó tárolói konfigurálva vannak, Önnek rögzítenie kell azok konfigurációját, majd alkalmaznia a migrálás után.

Ha az Oracle Message Brokert használja, a szoftvert migrálhatja az Azure-beli virtuális gépekre, és ott módosítás nélkül használhatja.

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.

Ezek a kódtárak a WebLogic testreszabásának meghatározásában ismertetett technikákkal kezelhetők.

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

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

Felveheti őket az előre összeállított Azure Marketplace-ajánlathoz megadott WAR vagy EAR szolgáltatásba, vagy közvetlenül az operátor használatával.

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.

Az AKS-en futó WLS Oracle Linuxon fut. Minden operációsrendszer-specifikus kódnak kompatibilisnek kell lennie az Oracle Linuxdal. Ha tudni szeretné, hogyan deríthet fel konkrét operációsrendszer-információkat, kövesse a WebLogic-verzió kompatibilitásának megállapítására vonatkozó lépéseket.

Annak megállapítása, hogy az Oracle Service Bus használatban van-e

Ha az alkalmazása Oracle Service Bust (OSB) használ, rögzítenie kell annak konfigurációját. További információ: Az Oracle Service Bus telepítése.

Az ELŐRE összeállított Azure Marketplace-ajánlat nem támogatja közvetlenül az OSB-t. Ha OSB-t kell használnia, közvetlenül az operátort kell használnia.

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ása EAR-fájlként van csomagolva, tekintse meg az application.xml és a weblogic-application.xml fájlt, és rögzítse a konfigurációjukat.

Az előre összeállított Azure Marketplace-ajánlat támogatja a WARS-eket és az EAR-ket. Az operátor közvetlen használata a WAR-eket és az EAR-ket is támogatja.

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.

Annak megállapítása, hogy az alkalmazás WebLogic Scripting Toolt (WLST) használ-e

Ha az üzembe helyezéshez jelenleg a WLST-t használja, ki kell értékelnie annak működését. Ha a WLST az üzembe helyezés részeként módosítja az alkalmazás bármely (futtatókörnyezeti) paraméterét, meg kell győződnie arról, hogy ez a viselkedés továbbra is működik, amikor az alkalmazást a migrálást követően teszteli.

A WLST használatával kompatibilis egyetlen tartomány kezdő forrástípusa a tartomány a PV-ben. További információ: Tartomány kezdőlapja egy PV-n.

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 állandó kötetek csatlakoztatása támogatott az előre összeállított Azure Marketplace-ajánlatban, valamint az operátor közvetlen használata esetén. Ha tartományt használ a PV-ben, a fájlrendszer a konfiguráció központi eleme.

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 vonatkozik az Ön architektúrájának azon aspektusaira, amelyeket migrálni szeretne, rögzítenie kell a meglévő üzem hálózati topológiáját, majd reprodukálnia az Azure-ban, akkor is, ha az alapszintű ajánlatot az egyik megoldássablonnal építette ki.

Ez egy rendkívül kiterjedt témakör, az alábbi hivatkozások azonban útmutatást nyújthatnak a migráláshoz:

A JCA-adapterek és erőforrás-adapterek használatának figyelembe vétele

Ha az üzembe helyezés erőforrás-adapterekre támaszkodik, a leginkább támogatott lehetőség a Tartomány otthon egy PV-n.

Egyéni biztonsági szolgáltatók és JAAS használatára vonatkozó fiók

Ha az alkalmazása JAAS-t használ, meg kell győződnie arról, hogy a biztonsági szolgáltatók konfigurációjának migrálása megfelelően történik. További információt az Oracle dokumentációjának A WebLogic biztonsági szolgáltatói című témakörében találhat.

Ha az üzembe helyezés biztonsági szolgáltatókra támaszkodik, a leginkább támogatott lehetőség a Tartomány otthona a PV-n.

Annak meghatározása, hogy az alkalmazás használ-e WebLogic-fürtözést

Az operátor kezeli a fürtözést a WLS 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 EJB-t használ, át kell telepítenie őket a fürtözött EJB-be. További információ: Fürtözött és helyi EJB.

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. További információ: Oktatóanyag: WebLogic-kiszolgálófürt migrálása az Azure-ba Azure-alkalmazás Átjáróval terheléselosztóként.

Annak meghatározása, hogy az alkalmazás használja-e a Java EE Application Client funkciót

Ha az üzembe helyezés Java Enterprise kiadás alkalmazás-ügyfelekre támaszkodik, a legjobb, ha közvetlenül használja az operátort. További információ: Külső ügyfelek.

Annak meghatározása, hogy több tárolólemezképre van-e szükség

A WebLogic Server-tartományok több fürtöt is tartalmazhatnak. Egy többrétegű alkalmazás például egyetlen tartományban jeleníthető meg, de két fürttel rendelkezik, például "előtérben" és "háttérrendszerrel". Hasznos lehet frissíteni az előtérrendszert a háttérrendszer frissítése nélkül, és fordítva. A Modell képtartomány kezdőlapjának forrástípusa esetén azonban a teljes tartomány egyetlen tárolórendszerképben jelenik meg. A használati eset kezeléséhez külön kell elválasztania a fürtöket a saját tartományaiktól, és mindegyiknek saját tárolólemezképe van. Az operátor több tartományt is kezelhet több névtérben. További információ: Tartománynévtér-kiválasztási stratégia kiválasztása

Több tartomány bevezetése T3 hozzáférési problémákat okozhat a tartományok között. A problémák megoldásához engedélyezzen egy egyéni csatornát az ismeretlen gazdagéphozzáférés engedélyezésének meghatározásában leírtak szerint.

Annak meghatározása, hogy szükség van-e ismeretlen gazdagép-hozzáférés engedélyezésére

Előfordulhat, hogy engedélyeznie kell az ismeretlen gazdagéphozzáférést, ha javítást alkalmaz a WebLogicra az alábbi esetekben:

  • A T3 hozzáférésének engedélyezése az AKS-en kívüli külső ügyfelekről az AKS-ben lévő WLS-fürtökhöz egyéni csatornán keresztül.
  • T3-hozzáférés engedélyezése a különböző WLS-tartományok között az AKS-ben egy egyéni csatornán keresztül.

A javítás részleteiért kövesse a Javításkeresés használata az Oracle-támogatásban (MOS) című témakörben található útmutatást, és keresse meg a javítást30656708.

A javítás alkalmazása után lásd : Ismeretlen gazdagéphozzáférés engedélyezése.

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 lásd https://aka.ms/wlsaks: . Válassza a Létrehozás lehetőséget, majd kövesse az ajánlat dokumentációjában szereplő utasításokat. Használja az előző lépésekben összegyűjtött információkat az ajánlat mezőinek kitöltéséhez.

A tartományok migrálása

Az ajánlat kiépítése után adja ki a tartományt az alábbi lépések végrehajtásával.

Ha az Üzembe helyezés folyamatban van lapról navigált, az alábbi lépések bemutatják, hogyan léphet vissza az adott lapra. Ha továbbra is azon a lapon van, amelyen az üzembe helyezés befejeződött, ugorjon az 5. lépésre.

  1. Bármelyik portáloldal bal felső sarkában válassza a hamburger menüt, és válassza az Erőforráscsoportok lehetőséget.

  2. Írja be a korábban létrehozott erőforráscsoport első néhány karakterét a szövegszűrővel ellátott mezőbe. Ha követte az ajánlott konvenciót, írja be a monogramját, majd válassza ki a megfelelő erőforráscsoportot.

  3. A bal oldali navigációs panel Gépház szakaszában válassza a Központi telepítések lehetőséget az erőforráscsoportba tartozó központi telepítések rendezett listájának megtekintéséhez, a legutóbbival.

  4. Görgessen a lista legrégebbi bejegyzéséhez. Ez a bejegyzés az előző szakaszban elindított üzembe helyezésnek felel meg. Válassza ki a legrégebbi üzembe helyezést az alábbi képernyőképen látható módon.

    Képernyőkép az Azure Portalról az erőforráscsoport üzembe helyezési listájával.

  5. A bal oldali panelen válassza a Kimenetek lehetőséget. Ez a lista az üzembe helyezés kimeneti értékeit jeleníti meg. A kimenetek hasznos információkat tartalmaznak. Minket érdekelnek azok a kimenetek, amelyek lehetővé teszik a tartomány vizsgálatát és az operátorral való interakciót. A kimenetekben szereplő többi érték részletes ismertetését a WebLogic on AKS felhasználói útmutatója ismerteti.

  6. Keresse meg az elnevezett shellCmdtoConnectAkskimenetet. Illessze be a kimenet értékét egy Bash-rendszerhéjba, és futtassa a parancsot. Ez a parancs lehetővé teszi, hogy az Csatlakozás leírtak szerint használja kubectl a fürtöt.

  7. Keresse meg az elnevezett shellCmdtoOutputWlsDomainYamlkimenetet. Illessze be a kimenet értékét egy Bash-rendszerhéjba, és futtassa a parancsot. Ez a parancs YAML-fájlként adja ki a tartományi erőforrást.

  8. Most, hogy már rendelkezik az aktuális üzembe helyezés YAML tartományával, alkalmazhatja a tartományerőforrás YAML-fájljainak üzembe helyezésére vonatkozó ismereteket, és további útmutatást talál a tartományok migrálásával kapcsolatban. Ez az útmutató a Kubernetes-módszerhez való alkalmazkodást igényli, de még mindig hasznos tudni.

A kulcstárak számba vétele

Számolnia kell az alkalmazás által használt SSL-kulcstárak migrálásával is. További információ: Kulcstárak konfigurálása.

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

Az adatbázisok összekötése után konfigurálhatja a JMS-t a WebLogic-dokumentáció Fusion Middleware Administering JMS Resources for Oracle WebLogic Server című szakaszának útmutatása szerint.

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 mintákat biztosít az Elasticsearch és a Kibana használatához. További információkért tekintse meg az operátor dokumentációját. 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?. Az ebben a két erőforrásban található tudást kombinálva azure-ra optimalizált naplózási megoldást érhet el a WLS-hez az AKS-en.

Alkalmazások migrálása

Függetlenül attól, hogy az üzembe helyezéskor WAR- vagy EAR-fájlt ad-e meg, frissítenie kell az alkalmazást CI/CD-n keresztül. Az operátor dokumentációja egy minta, amely bemutatja, hogyan kell elvégezni ezt a frissítést. További információ: 3. frissítés. A többi frissítési minta a migrálás szempontjából releváns, és érdemes megvizsgálni.

Tesztelés

Az alkalmazások tárolón belüli tesztjeit úgy kell konfigurálni, 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. A migrálást követő néhány lehetséges fejlesztéssel kapcsolatos útmutatásért tekintse meg az alábbi ajánlásokat: