WildFly-alkalmazások migrálása a WildFly-ba az Azure Kubernetes Service-en

  • Cikk

Ez az útmutató leírja, milyen szempontokat érdemes megfontolnia, amikor egy meglévő WildFly-alkalmazást egy Azure Kubernetes Service-beli tárolóban a WildFly-ba kíván migrálni.

Megjegyzés:

Ez a cikk csak általános tanácsokat nyújt. Sem a Microsoft, sem a Red Hat nem nyújt támogatást a WildFlyhez, de a WildFly közössége tud segítséget nyújtani. A Red Hat és a Microsoft által közösen támogatott ajánlatokról az Azure-beli Red Hat JBoss EAP-ban olvashat bővebben.

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.

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

Ellenőrizze az éles kiszolgáló(k) minden tulajdonságát és konfigurációs fájlját titkos kódokhoz és jelszavakhoz. Mindenképpen ellenőrizze a jboss-web.xml elemet a WAR-fájlokban. Az alkalmazásban jelszavakat vagy hitelesítő adatokat tartalmazó konfigurációs fájlok is szerepelhetnek.

Vegye fontolóra a titkos kulcsok Azure Key Vaultban való tárolását. 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>

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.

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

Leltározzon minden JNDI-erőforrást. Olykor, például JMS-üzenetközvetítők esetében, migrálásra vagy újrakonfigurálásra lehet szükség.

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, el kell távolítania ezt a függőséget az alkalmazásból.

Az alkalmazáson belül

Ellenőrizze a következő fájlokat: WEB-INF/jboss-web.xml és/vagy WEB-INF/web.xml.

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óért tekintse meg a WildFly dokumentációjának az adatforrások konfigurálását ismertető szakaszát.

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

Az alkalmazáskiszolgáló fájlrendszerének bármely használatához újrakonfigurálásra vagy bizonyos ritka esetekben architekturális módosításokra van szükség. A fájlrendszert használhatják a WildFly-modulok vagy az alkalmazás kódja is. Az alábbi szakaszokban leírt forgatókönyvek némelyikével vagy mindegyikével találkozhat.

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.

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

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

Annak megállapítása, hogy az alkalmazás használ-e JCA-összekötőket

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 a WildFly-hoz 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 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 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 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, mindenképpen ellenőrizze az application.xml fájlt, és rögzítse a konfigurációt.

Megjegyzés:

Ha azt szeretné, hogy az egyes webalkalmazások egymástól függetlenül skálázhatók legyenek az AKS-erőforrások jobb kihasználása érdekében, akkor az EAR-t külön webalkalmazásokra kell bontania.

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.

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. Ezután a következő javaslatokkal teheti natívabbá a felhőben az alkalmazását.

Javaslatok