WebLogic Server-alkalmazások migrálása a WildFlybe az Azure Kubernetes Service-ben

  • Cikk

Ez az útmutató azt ismerteti, hogy mire érdemes figyelnie, amikor egy meglévő WebLogic Server-alkalmazást szeretne migrálni, hogy a WildFlyen futjon egy Azure Kubernetes Service-tárolóban.

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.

Ha nem tudja teljesíteni a migrálás előtti követelményeket, tekintse meg a kísérő áttelepítési útmutatót:

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.

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>

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.

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 –, két lehetősége van:

  • 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.

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.

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?

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 (AMQP) 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.

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.

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.

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.

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.

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.

Megjegyzés:

Ha az Azure Kubernetes Service-erőforrások jobb kihasználása érdekében egymástól függetlenül szeretné méretezni az egyes webalkalmazásokat, akkor külön webalkalmazásokra kell bontania az EAR-t.

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 ellenőrzése, hogy a támogatott Java-verzió megfelelően működik-e

A WildFly az Azure Kubernetes Service-ben való 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.

Megjegyzé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

A WildFly futtatásához használandó verzióval kapcsolatos útmutatásért tekintse meg a Követelmények szakaszt.

Annak meghatározása, hogy az alkalmazás ütemezett feladatokra támaszkodik-e

Az ütemezett feladatokat, például a Quartz Scheduler-feladatokat vagy a Unix cron-feladatokat nem szabad használni az Azure Kubernetes Service-hez (AKS). Az Azure Kubernetes Service nem fogja megakadályozni, hogy belsőleg üzembe helyezzen ütemezett feladatokat tartalmazó alkalmazásokat. Ha azonban az alkalmazást horizontálisan felskálázza, ez az ütemezett feladat ütemezett időszakonként többször is lefuthat. Ez nem várt következményekkel járhat.

Ütemezett feladatok AKS-fürtön való végrehajtásához szükség szerint definiáljon Kubernetes cronfeladatokat. További információért tekintse meg az Automatizált feladatok cronfeladat használatával való futtatását ismertető részt.

Annak meghatározása, hogy a WebLogic-szkriptelési eszköz van-e használatban

Ha jelenleg a WebLogic Scripting Tool (WLST) használatával végzi el az üzembe helyezést, értékelnie kell, hogy mit csinál. Ha a WLST az üzembe helyezés részeként módosítja az alkalmazás bármely (futtatókörnyezeti) paraméterét, győződjön meg arról, hogy ezek a paraméterek megfelelnek az alábbi lehetőségek egyikének:

  • A paraméterek alkalmazásbeállításokként vannak külsővé.
  • A paraméterek be vannak ágyazva az alkalmazásba.
  • A paraméterek a JBoss PARANCSSOR-t használják az üzembe helyezés során.

Ha a WLST a fent említettnél többet tesz, a migrálás során további teendői lesznek.

Határozza meg, hogy az alkalmazás WebLogic-specifikus API-kat használ-e

Ha az alkalmazás WebLogic-specifikus API-kat használ, a szóban forgó függőségek eltávolításához újra kell bontania. Ha például az Oracle WebLogic Server Java API-referenciájában említett osztályt használt, akkor WebLogic-specifikus API-t használt az alkalmazásban. A hivatkozás eltávolításához újra kell újrabontást elvégeznie.

Annak meghatározása, hogy az alkalmazás használ-e entitásbeaneket vagy EJB 2.x típusú CMP-beaneket

Amennyiben az alkalmazása használ entitásbeaneket vagy EJB 2.x típusú CMP-beaneket, újra kell bontania az alkalmazást ezen függőségek eltávolításához.

Annak meghatározása, hogy az alkalmazás használja-e a Java EE Application Client szolgáltatást

Ha rendelkezik olyan ügyfélalkalmazásokkal, amelyek a Java EE Application Client szolgáltatással csatlakoznak a (kiszolgáló-) alkalmazáshoz, újra kell bontania az ügyfélalkalmazásokat és a (kiszolgáló-) alkalmazást is a HTTP API-k használatához.

Állapítsa meg, hogy használtak-e üzembehelyezési tervet

Ha az alkalmazást üzembe helyezték egy üzembe helyezési tervvel, értékelje az üzembe helyezési tervet. Ha az üzembehelyezési terv egyszerű üzembe helyezés, módosítás nélkül üzembe helyezheti a webalkalmazást is. Ha az üzembehelyezési terv részletesebb, határozza meg, hogy a JBoss parancssori felülettel megfelelően konfigurálhatja-e az alkalmazást az üzembe helyezés részeként. Ha nem lehet használni a JBoss parancssori felületet, az alkalmazást úgy kell újrabontással átformázni, hogy már nincs szükség üzembehelyezési tervre.

Annak megállapítása, hogy az alkalmazás használ-e EJB időzítőket

Ha az alkalmazás EJB-időzítőket használ, ellenőrizze, hogy az EJB-időzítő kódját aktiválhatják-e az egyes WildFly-példányok. Erre az ellenőrzésre azért van szükség, mert az Azure Kubernetes Service üzembehelyezési forgatókönyvében minden EJB-időzítő aktiválása külön WildFly-példányon történik.

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

Az alkalmazáskiszolgáló fájlrendszerének bármilyen használata újrakonfigurálást vagy ritkán architektúramódosítást igényel. A fájlrendszert a WebLogic megosztott moduljai vagy az alkalmazás kódja használhatja. A következő szakaszokban ismertetett forgatókönyvek némelyikét vagy mindegyikét azonosíthatja.

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.

Dinamikus vagy belső tartalom

Az alkalmazás által gyakran írt és olvasott fájlok (például az ideiglenes adatfájlok) vagy a kizárólag az alkalmazás számára látható statikus fájlok esetében állandó kötetként csatlakoztathatók Azure Storage-megosztások. További információért lásd: Tartós kötet dinamikus létrehozása és használata Azure-fájlokkal az Azure Kubernetes Service-ben.

JCA-összekötők használatának meghatározása

Ha az alkalmazás JCA-összekötőket használ, ellenőrizze, hogy a JCA-összekötő használható-e a WildFly-on. Ha a JCA implementációja WebLogichoz kötődik, újra kell bontania az alkalmazást a szóban forgó függőség eltávolításához. Ha használható, akkor adja hozzá a JAR-okat a kiszolgáló osztályútvonalához, és a szükséges konfigurációs fájlokat helyezze el a megfelelő helyen a WildFly-kiszolgáló könyvtáraiban, hogy elérhetők legyenek.

Annak meghatározása, hogy az alkalmazás használ-e erőforrás-adaptert

Ha az alkalmazásnak szüksége van erőforrás-adapterre, annak kompatibilisnek kell lennie a WildFly-jal. Állapítsa meg, hogy az erőforrás-adapter jól működik-e a WildFly különálló példányán azáltal, hogy üzembe helyezi a kiszolgálón és megfelelően konfigurálja. Ha az erőforrás-adapter megfelelően működik, akkor hozzá kell adnia a JAR-fájlokat a Docker-rendszerkép kiszolgáló-osztályútvonalához, és a szükséges konfigurációs fájlokat a megfelelő helyen kell elhelyeznie a WildFly-kiszolgáló könyvtáraiban, hogy elérhetők legyenek.

Annak megállapítása, hogy az alkalmazás használja-e a JAAS-t

Ha az alkalmazás használja a JAAS-t, rögzítenie kell a JAAS konfigurációját. Ha használ adatbázist, konvertálhatja egy JAAS-tartományba a WildFly-on. Amennyiben ez egy egyéni implementálás, ellenőriznie kell, hogy használható-e a WildFly-on.

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

Az alkalmazást valószínűleg több WebLogic-kiszolgálón is üzembe helyezte a magas rendelkezésre állás érdekében. Az Azure Kubernetes Service képes a skálázásra, de ha a WebLogic Cluster API-t használta, újra kell átépítenie a kódot az API használatának megszüntetéséhez.

Helyszíni tesztelés végrehajtása

A tárolórendszerképek létrehozása előtt migrálja az alkalmazást az AKS-en használni kívánt JDK- és WildFly-verziókra. Tesztelje alaposan az alkalmazást kompatibilitásának és teljesítményének biztosítása érdekében.

Áttelepítés

Az Azure Container Registry és az Azure Kubernetes Service üzembe helyezése

Használja a következő parancsokat egy tárolóregisztrációs adatbázis és egy szolgáltatásnévvel rendelkező Azure Kubernetes-fürt létrehozásához, amely olvasó szerepkörrel rendelkezik a regisztrációs adatbázison. Ügyeljen arra, hogy megfelelő hálózati modellt válasszon a fürt hálózati követelményeihez.

az group create \
    --resource-group $resourceGroup \
    --location eastus
az acr create \
    --resource-group $resourceGroup \
    --name $acrName \
    --sku Standard
az aks create \
    --resource-group $resourceGroup \
    --name $aksName \
    --attach-acr $acrName \
    --network-plugin azure

Docker-rendszerkép létrehozása a WildFly-hoz

Egy Docker-fájl létrehozásához a következő előfeltételeknek kell teljesülniük:

  • Támogatott JDK.
  • A WildFly telepítése.
  • a JVM futtatókörnyezeti beállításai;
  • a környezeti változók megadásának módja (ha lehetséges).

Ezután elvégezheti az alábbi szakaszokban leírt lépéseket, ahol alkalmazhatók. A WildFly-tároló gyorsútmutató-adattára használható a Docker-fájl és a webalkalmazás kiindulási pontjaként.

  1. A KeyVault FlexVolume-kötet konfigurálása
  2. Adatforrások beállítása
  3. JNDI-erőforrások beállítása
  4. WildFly-konfiguráció áttekintése

A KeyVault FlexVolume-kötet konfigurálása

Hozzon létre egy Azure KeyVault-kulcstartót, és töltse fel az összes szükséges titkos kulcsot. További információ : Rövid útmutató: Titkos kód beállítása és lekérése az Azure Key Vaultból az Azure CLI használatával. Ezután konfiguráljon egy KeyVault FlexVolume-kötetet, hogy ezek a titkos kódok elérhetők legyenek a podok számára.

a WildFly rendszerindításához használt indítási szkript frissítését is el kell végeznie. A szkriptnek importálnia kell a tanúsítványokat a WildFly által használt kulcstárba a kiszolgáló elindítása előtt.

Adatforrások beállítása

Ha a WildFly-t egy adatforrás elérésére szeretné konfigurálni, hozzá kell adnia a JDBC-illesztőhöz tartozó JAR-fájlt a Docker-rendszerképhez, majd végre kell hajtania a megfelelő JBoss CLI-parancsokat. Ezek a parancsok beállítják adatforrásokat a Docker-rendszerkép összeállításakor.

A következő lépések a PostgreSQL-re, a MySQL-re és az SQL Serverre vonatkozó útmutatást tartalmaznak.

  1. Töltse le a PostgreSQL-hez, a MySQL-hez vagy az SQL Serverhez tartozó JDBC-illesztőt.

    Bontsa ki a letöltött archívum tartalmát az illesztő .jar-fájljának eléréséhez.

  2. Hozzon létre egy module.xml, vagy hasonló nevű fájlt, és adja hozzá az alábbi kódot. Cserélje le a <module name> helyőrzőt (a csúcsos zárójeleket is) a következőre: PostgreSQL esetén org.postgres, MySQL esetén com.mysql, illetve SQL Server esetén com.microsoft. A <JDBC .jar file path> helyére írja be a .jar-fájl nevét az előző lépésből, beleértve a hely teljes elérési útját, ahová a fájlt helyezi a Docker-rendszerképben, például: /opt/database.

    <?xml version="1.0" ?>
<module xmlns="urn:jboss:module:1.1" name="<module name>">
    <resources>
       <resource-root path="<JDBC .jar file path>" />
    </resources>
    <dependencies>
        <module name="javax.api"/>
        <module name="javax.transaction.api"/>
    </dependencies>
</module>

  3. Hozzon létre egy datasource-commands.cli, vagy hasonló nevű fájlt, és adja hozzá a következő kódot. A <JDBC .jar file path> helyére írja be az előző lépésben használt értéket. A <module file path> helyére írja be az előző lépésben használt fájlnevet és elérési utat, például: /opt/database/module.xml.

    PostgreSQL

    batch
module add --name=org.postgres --resources=<JDBC .jar file path> --module-xml=<module file path>
/subsystem=datasources/jdbc-driver=postgres:add(driver-name=postgres,driver-module-name=org.postgres,driver-class-name=org.postgresql.Driver,driver-xa-datasource-class-name=org.postgresql.xa.PGXADataSource)
data-source add --name=postgresDS --driver-name=postgres --jndi-name=java:jboss/datasources/postgresDS --connection-url=$DATABASE_CONNECTION_URL --user-name=$DATABASE_SERVER_ADMIN_FULL_NAME --password=$DATABASE_SERVER_ADMIN_PASSWORD --use-ccm=true --max-pool-size=5 --blocking-timeout-wait-millis=5000 --enabled=true --driver-class=org.postgresql.Driver --exception-sorter-class-name=org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLExceptionSorter --jta=true --use-java-context=true --valid-connection-checker-class-name=org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker
reload
run batch
shutdown

    MySQL

    batch
module add --name=com.mysql --resources=<JDBC .jar file path> --module-xml=<module file path>
/subsystem=datasources/jdbc-driver=mysql:add(driver-name=mysql,driver-module-name=com.mysql,driver-class-name=com.mysql.cj.jdbc.Driver)
data-source add --name=mysqlDS --jndi-name=java:jboss/datasources/mysqlDS --connection-url=$DATABASE_CONNECTION_URL --driver-name=mysql --user-name=$DATABASE_SERVER_ADMIN_FULL_NAME --password=$DATABASE_SERVER_ADMIN_PASSWORD --use-ccm=true --max-pool-size=5 --blocking-timeout-wait-millis=5000 --enabled=true --driver-class=com.mysql.cj.jdbc.Driver --jta=true --use-java-context=true --exception-sorter-class-name=com.mysql.cj.jdbc.integration.jboss.ExtendedMysqlExceptionSorter
reload
run batch
shutdown

    SQL Server

    batch
module add --name=com.microsoft --resources=<JDBC .jar file path> --module-xml=<module file path>
/subsystem=datasources/jdbc-driver=sqlserver:add(driver-name=sqlserver,driver-module-name=com.microsoft,driver-class-name=com.microsoft.sqlserver.jdbc.SQLServerDriver,driver-datasource-class-name=com.microsoft.sqlserver.jdbc.SQLServerDataSource)
data-source add --name=sqlDS --jndi-name=java:jboss/datasources/sqlDS --driver-name=sqlserver --connection-url=$DATABASE_CONNECTION_URL --validate-on-match=true --background-validation=false --valid-connection-checker-class-name=org.jboss.jca.adapters.jdbc.extensions.mssql.MSSQLValidConnectionChecker --exception-sorter-class-name=org.jboss.jca.adapters.jdbc.extensions.mssql.MSSQLExceptionSorter
reload
run batch
shutdown

  4. Frissítse az alkalmazás JTA-adatforrásának konfigurációját:

    Nyissa meg az alkalmazáshoz tartozó src/main/resources/META-INF/persistence.xml fájlt, és keresse meg a <jta-data-source> elemet. Cserélje le a tartalmát az alábbi módon:

    PostgreSQL

    <jta-data-source>java:jboss/datasources/postgresDS</jta-data-source>

    MySQL

    <jta-data-source>java:jboss/datasources/mysqlDS</jta-data-source>

    SQL Server

    <jta-data-source>java:jboss/datasources/postgresDS</jta-data-source>

  5. Egyszerűen adja hozzá a következőket a Dockerfile-hoz, így létrejön az adatforrás a Docker-rendszerkép összeállításakor.

    RUN /bin/bash -c '<WILDFLY_INSTALL_PATH>/bin/standalone.sh --start-mode admin-only &' && \
sleep 30 && \
<WILDFLY_INSTALL_PATH>/bin/jboss-cli.sh -c --file=/opt/database/datasource-commands.cli && \
sleep 30

  6. Határozza meg a használni kívánt DATABASE_CONNECTION_URL-t, mivel az minden egyes adatbázis-kiszolgáló esetén más, és eltér az Azure Portalon található értékektől. Az itt látható URL-formátumok szükségesek a WildFly használatához:

    PostgreSQL

    jdbc:postgresql://<database server name>:5432/<database name>?ssl=true

    MySQL

    jdbc:mysql://<database server name>:3306/<database name>?ssl=true\&useLegacyDatetimeCode=false\&serverTimezone=GMT

    SQL Server

    jdbc:sqlserver://<database server name>:1433;database=<database name>;user=<admin name>;password=<admin password>;encrypt=true;trustServerCertificate=false;hostNameInCertificate=*.database.windows.net;loginTimeout=30;

  7. Az üzembehelyezési YAML-fájl későbbi létrehozásának során át kell adnia a DATABASE_CONNECTION_URL, DATABASE_SERVER_ADMIN_FULL_NAME és DATABASE_SERVER_ADMIN_PASSWORD környezeti változókat a megfelelő értékekkel.

További információt az adatbázis-kapcsolat WildFly használatával történő konfigurálásához itt talál: PostgreSQL, MySQL vagy SQL Server.

JNDI-erőforrások beállítása

A WildFly-on konfigurálandó egyes JNDI-erőforrások beállításához általában a következő lépéseket kell elvégezni:

  1. Töltse le a szükséges JAR-fájlokat, és másolja őket a Docker-rendszerképbe.
  2. Hozzon létre egy WildFly module.xml fájlt, amely a JAR-fájlokra hivatkozik.
  3. Hozza létre az adott JNDI-erőforráshoz szükséges konfigurációkat.
  4. Hozzon létre egy JBoss CLI-szkriptet, amelyet a Docker összeállításakor, a JNDI-erőforrás regisztrálásához használ.
  5. Adjon hozzá mindent a Docker-fájlhoz.
  6. Adja meg a megfelelő környezeti változókat az üzembehelyezési YAML-fájlban.

Az alábbi példán az Azure Service Busszal való JMS-kapcsolat JNDI-erőforrásának létrehozásához szükséges lépéseket láthatja.

  1. Az Apache Qpid JMS-szolgáltató letöltése

    Bontsa ki a letöltött archívumot a .jar-fájlok eléréséhez.

  2. Hozzon létre egy module.xml, vagy hasonló nevű fájlt, és adja hozzá az alábbi kódot ehhez: /opt/servicebus. Győződjön meg arról, hogy a JAR-fájlok verziószáma megfelel az előző lépésben kibontott JAR-fájlok nevének.

    <?xml version="1.0" ?>
<module xmlns="urn:jboss:module:1.1" name="org.jboss.genericjms.provider">
 <resources>
  <resource-root path="proton-j-0.31.0.jar"/>
  <resource-root path="qpid-jms-client-0.40.0.jar"/>
  <resource-root path="slf4j-log4j12-1.7.25.jar"/>
  <resource-root path="slf4j-api-1.7.25.jar"/>
  <resource-root path="log4j-1.2.17.jar"/>
  <resource-root path="netty-buffer-4.1.32.Final.jar" />
  <resource-root path="netty-codec-4.1.32.Final.jar" />
  <resource-root path="netty-codec-http-4.1.32.Final.jar" />
  <resource-root path="netty-common-4.1.32.Final.jar" />
  <resource-root path="netty-handler-4.1.32.Final.jar" />
  <resource-root path="netty-resolver-4.1.32.Final.jar" />
  <resource-root path="netty-transport-4.1.32.Final.jar" />
  <resource-root path="netty-transport-native-epoll-4.1.32.Final-linux-x86_64.jar" />
  <resource-root path="netty-transport-native-kqueue-4.1.32.Final-osx-x86_64.jar" />
  <resource-root path="netty-transport-native-unix-common-4.1.32.Final.jar" />
  <resource-root path="qpid-jms-discovery-0.40.0.jar" />
 </resources>
 <dependencies>
  <module name="javax.api"/>
  <module name="javax.jms.api"/>
 </dependencies>
</module>

  3. Hozzon létre egy jndi.properties fájlt a /opt/servicebus helyen.

    connectionfactory.${MDB_CONNECTION_FACTORY}=amqps://${DEFAULT_SBNAMESPACE}.servicebus.windows.net?amqp.idleTimeout=120000&jms.username=${SB_SAS_POLICY}&jms.password=${SB_SAS_KEY}
queue.${MDB_QUEUE}=${SB_QUEUE}
topic.${MDB_TOPIC}=${SB_TOPIC}

  4. Hozzon létre egy servicebus-commands.cli, vagy hasonló nevű fájlt, és adja hozzá a következő kódot.

    batch
/subsystem=ee:write-attribute(name=annotation-property-replacement,value=true)
/system-property=property.mymdb.queue:add(value=myqueue)
/system-property=property.connection.factory:add(value=java:global/remoteJMS/SBF)
/subsystem=ee:list-add(name=global-modules, value={"name" => "org.jboss.genericjms.provider", "slot" =>"main"}
/subsystem=naming/binding="java:global/remoteJMS":add(binding-type=external-context,module=org.jboss.genericjms.provider,class=javax.naming.InitialContext,environment=[java.naming.factory.initial=org.apache.qpid.jms.jndi.JmsInitialContextFactory,org.jboss.as.naming.lookup.by.string=true,java.naming.provider.url=/opt/servicebus/jndi.properties])
/subsystem=resource-adapters/resource-adapter=generic-ra:add(module=org.jboss.genericjms,transaction-support=XATransaction)
/subsystem=resource-adapters/resource-adapter=generic-ra/connection-definitions=sbf-cd:add(class-name=org.jboss.resource.adapter.jms.JmsManagedConnectionFactory, jndi-name=java:/jms/${MDB_CONNECTION_FACTORY})
/subsystem=resource-adapters/resource-adapter=generic-ra/connection-definitions=sbf-cd/config-properties=ConnectionFactory:add(value=${MDB_CONNECTION_FACTORY})
/subsystem=resource-adapters/resource-adapter=generic-ra/connection-definitions=sbf-cd/config-properties=JndiParameters:add(value="java.naming.factory.initial=org.apache.qpid.jms.jndi.JmsInitialContextFactory;java.naming.provider.url=/opt/servicebus/jndi.properties")
/subsystem=resource-adapters/resource-adapter=generic-ra/connection-definitions=sbf-cd:write-attribute(name=security-application,value=true)
/subsystem=ejb3:write-attribute(name=default-resource-adapter-name, value=generic-ra)
run-batch
reload
shutdown

  5. Egyszerűen adja hozzá a következőket a Dockerfile-hoz, így létrejön a JNDI-erőforrás a Docker-rendszerkép összeállításakor.

    RUN /bin/bash -c '<WILDFLY_INSTALL_PATH>/bin/standalone.sh --start-mode admin-only &' && \
sleep 30 && \
<WILDFLY_INSTALL_PATH>/bin/jboss-cli.sh -c --file=/opt/servicebus/servicebus-commands.cli && \
sleep 30

  6. Az üzembehelyezési YAML-fájl későbbi létrehozásának során át kell adnia az MDB_CONNECTION_FACTORY, DEFAULT_SBNAMESPACE és SB_SAS_POLICY, SB_SAS_KEY, MDB_QUEUE, SB_QUEUE, MDB_TOPIC és SB_TOPIC környezeti változókat a megfelelő értékekkel.

WildFly-konfiguráció áttekintése

Tekintse át a WildFly rendszergazdai útmutatóját az előző útmutatóban nem tárgyalt, további migrálási előtti lépésekért.

A Docker-rendszerkép összeállítása és leküldése az Azure Container Registry-be

Docker-fájl létrehozása után össze kell állítania a Docker-rendszerképet, és közzé kell tennie az Azure Container Registry-ben.

Ha a WildFly-tárolóhoz készült gyorsindítási GitHub-adattárunkat használta, akkor a rendszerkép összeállításához és az Azure Container Registry-be történő leküldéséhez az alábbi három parancsot kell végrehajtania.

Ezekben a példákban a MY_ACR környezeti változó az Azure Container Registry nevét tartalmazza, a MY_APP_NAME változó pedig annak a webalkalmazásnak a nevét, amelyet az Azure Container Registry-n szeretne használni.

WAR-fájl összeállítása:

mvn package

Jelentkezzen be az Azure Container Registry-be:

az acr login --name ${MY_ACR}

A rendszerkép összeállítása és leküldése:

az acr build --image ${MY_ACR}.azurecr.io/${MY_APP_NAME} --file src/main/docker/Dockerfile .

A Docker CLI-t is használhatja, ha először helyileg szeretné összeállítani és tesztelni a rendszerképet – erre az alábbiakban láthat példát. Ez a megközelítés leegyszerűsítheti a lemezképek tesztelését és finomítását az ACR-ben való kezdeti üzembe helyezés előtt. Azonban szükséges hozzá a Docker CLI telepítése, és a Docker-démonnak is futnia kell.

Rendszerkép összeállítása:

docker build -t ${MY_ACR}.azurecr.io/${MY_APP_NAME}

A rendszerkép helyi futtatása:

docker run -it -p 8080:8080 ${MY_ACR}.azurecr.io/${MY_APP_NAME}

Az alkalmazás most már elérhető a következőt helyen: http://localhost:8080.

Jelentkezzen be az Azure Container Registry-be:

az acr login --name ${MY_ACR}

Küldje le a rendszerképet az Azure Container Registry-be:

docker push ${MY_ACR}.azurecr.io/${MY_APP_NAME}

A tárolórendszerképek Azure-ban történő összeállításával és tárolásával kapcsolatos részletesebb információkért tekintse meg a Tárolórendszerképek összeállítása és tárolása az Azure Container Registry használatával című tanulási modult.

Nyilvános IP-cím kiosztása

Ha az alkalmazásnak elérhetőnek kell lennie a belső vagy a virtuális hálózat(ok)on kívülről, szüksége lesz egy nyilvános statikus IP-címre. Ezt az IP-címet a fürt csomópontjának erőforráscsoportján belül javasolt kiépíteni, a következő példában látható módon:

export nodeResourceGroup=$(az aks show \
    --resource-group $resourceGroup \
    --name $aksName \
    --query 'nodeResourceGroup' \
    --output tsv)
export publicIp=$(az network public-ip create \
    --resource-group $nodeResourceGroup \
    --name applicationIp \
    --sku Standard \
    --allocation-method Static \
    --query 'publicIp.ipAddress' \
    --output tsv)
echo "Your public IP address is ${publicIp}."

Üzembe helyezés az AKS-ben

Hozza létre és alkalmazza a Kubernetes YAML-fájlt vagy -fájlokat. További információ : Rövid útmutató: Azure Kubernetes Service-fürt üzembe helyezése az Azure CLI használatával. Ha külső terheléselosztót hoz létre (akár az alkalmazáshoz, akár egy bejövőforgalom-vezérlőhöz), mindenképpen az előző szakaszban kiépített IP-címet adja meg a LoadBalancerIP értékeként.

A külső paramétereket környezeti változókként adja meg. További információt a környezeti változók tárolóhoz való meghatározását ismertető cikkben talál. Ne adjon meg titkos kódokat (például jelszavakat, API-kulcsokat és JDBC-kapcsolati sztringeket). Ezeket a következő szakasz tárgyalja.

Ügyeljen arra, hogy az üzembehelyezési YAML létrehozásakor a memória-és a processzorbeállításokat is megadja, hogy a tárolók mérete megfelelő legyen.

Állandó tároló konfigurálása

Ha az alkalmazás permanens tárolót igényel, állítson be egy vagy több tartós kötetet.

Ütemezett feladatok migrálása

Ütemezett feladatok AKS-fürtön való végrehajtásához szükség szerint definiáljon Kubernetes cronfeladatokat. További információért tekintse meg az Automatizált feladatok cronfeladat használatával való futtatását ismertető részt.

A migrálás után

Most, hogy migrálta az alkalmazást az Azure Kubernetes Service-be, ellenőrizze, hogy a várt módon működik-e. Ezt követően tekintse meg az alábbi javaslatokat az alkalmazás felhőbeli natívabbá tétele érdekében.

Javaslatok