Migrace aplikací WebSphere do WildFly ve službě Azure Kubernetes Service

  • Článek

Tato příručka popisuje, co byste měli vědět, když chcete migrovat existující aplikaci WebSphere tak, aby běžela ve WildFly v kontejneru služby Azure Kubernetes Service.

Před migrací

Pokud chcete zajistit úspěšnou migraci, dokončete kroky posouzení a inventáře popsané v následujících částech.

Inventarizace kapacity serverů

Zdokumentujte hardware (paměť, procesor, disk) aktuálních produkčních serverů a průměrný počet požadavků a využití prostředků ve špičce. Tyto informace budete potřebovat bez ohledu na zvolenou cestu migrace. Užitečné je například pomoct při výběru velikosti virtuálních počítačů ve fondu uzlů, množství paměti, které kontejner používá, a počet sdílených procesorů, které kontejner potřebuje.

Ve službě AKS je možné změnit velikost fondů uzlů. Postup najdete v tématu Změna velikosti fondů uzlů ve službě Azure Kubernetes Service (AKS).

Inventarizace všech tajných kódů

Ve všech vlastnostech a konfiguračních souborech na produkčních serverech vyhledejte tajné kódy a hesla. Nezapomeňte zkontrolovat soubor ibm-web-bnd.xml v souborech WAR. Konfigurační soubory obsahující hesla nebo přihlašovací údaje se mohou nacházet také ve vaší aplikaci.

Inventarizace všech certifikátů

Zdokumentujte všechny certifikáty používané pro veřejné koncové body SSL. Všechny certifikáty na produkčních serverech zobrazíte spuštěním následujícího příkazu:

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

Ověření správné funkce podporované verze jazyka Java

Použití WildFly ve službě Azure Kubernetes Service vyžaduje konkrétní verzi Javy, takže budete muset ověřit, že vaše aplikace funguje správně pomocí této podporované verze.

Poznámka:

Toto ověření je obzvláště důležité, pokud se váš aktuální server provozuje na nepodporované sadě JDK (například Oracle JDK nebo IBM OpenJ9).

Aktuální verzi jazyka Java získáte tak, že se přihlásíte k produkčnímu serveru a spustíte následující příkaz:

java -version

Podrobné informace k tomu, která verze se má použít ke spuštění WildFly, najdete v požadavcích.

Inventarizace prostředků JNDI

Proveďte inventarizaci všech prostředků JNDI. Některé z nich, například zprostředkovatelé zpráv JMS, mohou vyžadovat migraci nebo změnu konfigurace.

Ve vaší aplikaci

Zkontrolujte soubor WEB-INF/ibm-web-bnd.xml nebo WEB-INF/web.xml.

Dokumentování zdrojů dat

Pokud vaše aplikace používá nějaké databáze, potřebujete shromáždit následující informace:

  • Jaký je název zdroje dat?
  • Jaká je konfigurace fondu připojení?
  • Kde najdu soubor JAR ovladače JDBC?

Další informace najdete v tématu věnovaném konfiguraci možností připojení databází v dokumentaci k WebSphere.

Určení, jestli a jak se používá systém souborů

Jakékoli používání systému souborů na aplikačním serveru bude vyžadovat změnu konfigurace nebo ve vzácných případech změnu architektury. Systém souborů mohou využívat moduly WebSphere nebo kód vaší aplikace. Můžete zjistit některé nebo všechny z následujících situací popsaných v následujících oddílech.

Statický obsah jen pro čtení

Pokud vaše aplikace aktuálně poskytuje statický obsah, budete pro ni potřebovat alternativní umístění. Možná budete chtít statický obsah přesunout do Azure Blob Storage a přidat Azure CDN, abyste umožnili bleskově rychlé globální stahování. Další informace najdete v tématu Hostování statického webu ve službě Azure Storage a rychlém startu: Integrace účtu úložiště Azure s Azure CDN. Statický obsah můžete také přímo nasadit do aplikace v plánu Azure Spring Apps Enterprise. Další informace naleznete v tématu Nasazení webových statických souborů.

Dynamicky publikovaný statický obsah

Pokud vaše aplikace umožňuje nahrávání nebo vytváření statického obsahu, který je ale po vytvoření neměnný, můžete použít Azure Blob Storage a Azure CDN, jak je popsáno výše, s funkcí Azure Functions, která zpracovává nahrávání a aktualizace CDN. Pro vaše použití jsme poskytli ukázkovou implementaci na GitHubu – Uploading and CDN-preloading static content with Azure Functions. Statický obsah můžete také přímo nasadit do aplikace v plánu Azure Spring Apps Enterprise. Další informace naleznete v tématu Nasazení webových statických souborů.

Dynamický nebo interní obsah

Pro soubory, které vaše aplikace často zapisuje a čte (například dočasné datové soubory) nebo statické soubory, které jsou viditelné jen vaší aplikaci, můžete připojit sdílené složky Azure Storage jako trvalé svazky. Další informace najdete v článku Dynamické vytváření a používání trvalého svazku s Azure Files ve službě Azure Kubernetes Service.

Určení, jestli aplikace využívá naplánované úlohy

Naplánované úlohy, jako jsou úlohy plánovače Quartz nebo úlohy Unix cron, by se neměly používat se službou Azure Kubernetes Service (AKS). Azure Kubernetes Service vám nezabrání nasadit aplikaci, která interně obsahuje naplánované úlohy. Pokud ale u aplikace dojde k horizontálnímu rozšíření kapacity, může se stejná naplánovaná úloha spustit v průběhu naplánovaného období více než jednou. Tato situace může vést k nezamýšleným důsledkům.

Pro spouštění naplánovaných úloh v clusteru AKS definujte podle potřeby úlohy Cron pro Kubernetes. Další informace najdete v tématu Spouštění automatizovaných úkolů s využitím úloh Cron.

Určení, jestli je potřeba připojení k místnímu prostředí

Pokud vaše aplikace potřebuje přístup k některým místním službám, budete muset zřídit jednu ze služeb připojení Azure. Další informace najdete v článku Volba řešení pro připojení místní sítě k Azure. Alternativně budete muset aplikaci refaktorovat tak, aby používala veřejně přístupná rozhraní API, která nabízejí vaše místní prostředky.

Určení, jestli se používají fronty nebo témata JMS (Java Message Service)

Pokud vaše aplikace používá fronty nebo témata JMS, budete je muset migrovat na externě hostovaný server JMS. Pro aplikace používající JMS může skvělou migrační strategii představovat Azure Service Bus a rozšířený protokol řízení front zpráv (AMQP). Další informace najdete v tématu, které se věnuje použití JMS se službou Azure Service Bus a protokolem AMQP 1.0.

Pokud jste nakonfigurovali trvalá úložiště JMS, musíte zachytit jejich konfiguraci a po migraci ji použít.

Určení, jestli aplikace využívá rozhraní API specifická pro WebSphere

Pokud vaše aplikace využívá rozhraní API specifická pro WebSphere, musíte je refaktorovat, aby se tyto závislosti odstranili. Pokud jste například použili třídu uvedenou ve specifikaci rozhraní API pro IBM WebSphere Application Server verze 9.0, znamená to, že jste ve vaší aplikaci použili rozhraní API specifické pro WebSphere.

Určení, jestli aplikace používá objekty Entity bean nebo objekty CMP bean ve stylu EJB 2.x

Pokud vaše aplikace používá objekty Entity bean nebo objekty CMP bean ve stylu EJB 2.x, budete muset aplikaci refaktorovat a odebrat tyto závislosti.

Určení, jestli se používá funkce klienta aplikace Java EE

Pokud máte klientské aplikace, které se připojují k vaší (serverové) aplikaci pomocí funkce klienta aplikace Java EE, budete muset klientské aplikace i (serverovou) aplikaci refaktorovat tak, aby používaly rozhraní HTTP API.

Určení, jestli aplikace obsahuje kód specifický pro operační systém

Pokud vaše aplikace obsahuje jakýkoli kód se závislostmi na hostitelském operačním systému, budete muset refaktorováním tyto závislosti odebrat. Pomocí File.Separator nebo Paths.get budete například muset nahradit použití znaků / nebo \ v cestách systému souborů.

Určení, jestli se používají časovače EJB

Pokud vaše aplikace používá časovače EJB, budete muset ověřit, jestli jednotlivé instance WildFly můžou nezávisle na sobě aktivovat kód časovačů EJB. Toto ověření je potřeba, protože ve scénáři nasazení Azure Kubernetes Service se každý časovač EJB bude aktivovat ve vlastní instanci WildFly.

Určení, jestli se používají konektory JCA

Pokud vaše aplikace používá konektory JCA, budete muset ověřit, že se tento konektor JCA dá použít ve WildFly. Pokud je implementace JCA navázaná na WebSphere, musíte refaktorovat vaši aplikaci a odstranit tak tuto závislost. Pokud se dá použít, musíte přidat soubory JAR do cesty ke třídám serveru a umístit nezbytné konfigurační soubory do správných umístění v adresářích serveru WildFly, aby byl k dispozici.

Určení, jestli se používá JAAS

Pokud vaše aplikace používá JAAS, budete muset zjistit konfiguraci JAAS. Pokud používá databázi, můžete ji převést na doménu JAAS ve WildFly. Pokud se jedná o vlastní implementaci, budete muset ověřit, že je možné ji použít ve WildFly.

Určení, jestli aplikace využívá adaptér prostředků

Pokud vaše aplikace potřebuje adaptér prostředků, musí být kompatibilní s WildFly. Zjistěte, jestli adaptér prostředků funguje bez problémů v samostatné instanci WildFly tím, že ji nasadíte na server a správně nakonfigurujete. Pokud adaptér prostředků funguje správně, musíte přidat příslušné soubory JAR do cesty ke třídám serveru image Dockeru a umístit nezbytné konfigurační soubory do správných umístění v adresářích serveru WildFly, aby byl k dispozici.

Určení, jestli se aplikace skládá z několika souborů WAR

Pokud se vaše aplikace skládá z několika souborů WAR, měli byste s těmito soubory WAR zacházet jako se samostatnými aplikacemi a projít tuto příručku pro každý z nich.

Určení, jestli je aplikace zabalená jako soubor EAR

Pokud je vaše aplikace zabalená jako soubor EAR, prověřte soubory application.xml a application-bnd.xm a poznačte si jejich konfiguraci.

Poznámka:

Pokud chcete mít možnost škálovat jednotlivé webové aplikace nezávisle z důvodu lepšího využití prostředků AKS, měli byste EAR rozdělit na samostatné webové aplikace.

Zjištění všech vnějších procesů a démonů běžících na produkčních serverech

Pokud používáte nějaké procesy, které běží mimo aplikační server, například monitorovací démony, budete je muset eliminovat nebo migrovat jinam.

Místní testování

Před vytvořením imagí kontejneru migrujte aplikaci na verze JDK a WildFly, které máte v plánu používat v AKS. Pečlivě otestujte kompatibilitu a výkon aplikace.

Migrace

Zřízení služeb Azure Container Registry a Azure Kubernetes Service

Pomocí následujících příkazů vytvořte registr kontejnerů a cluster Azure Kubernetes s instančním objektem, který má v registru roli Čtenář. Nezapomeňte zvolit vhodný model sítě pro požadavky na síť vašeho clusteru.

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

Vytvoření image Dockeru pro WildFly

K vytvoření souboru Dockerfile budete potřebovat následující:

  • Podporovaná sada JDK.
  • Instalace WildFly.
  • Parametry modulu runtime JVM
  • Způsob předání proměnných prostředí (pokud je používáte)

Pak můžete v případě potřeby provést kroky popsané v následujících částech. Jako výchozí bod pro soubor Dockerfile a webovou aplikaci můžete použít úložiště Rychlého startu pro kontejner WildFly.

  1. Konfigurace svazku FlexVolume služby Key Vault
  2. Nastavení zdrojů dat
  3. Nastavení prostředků JNDI
  4. Kontrola konfigurace WildFly

Konfigurace svazku FlexVolume služby Key Vault

Vytvořte službu Azure Key Vault a zadejte všechny potřebné tajné klíče. Další informace najdete v tématu Rychlý start: Nastavení a načtení tajného kódu ze služby Azure Key Vault pomocí Azure CLI. Pak nakonfigurujte svazek FlexVolume služby KeyVault tak, aby tyto tajné kódy byly přístupné podům.

Budete také muset aktualizovat spouštěcí skript, který spouští WildFly. Tento skript musí přes spuštěním serveru importovat certifikáty do úložiště klíčů, které používá WildFly.

Nastavení zdrojů dat

Pokud chcete nakonfigurovat WildFly pro přístup ke zdroji dat, musíte do vaší image Dockeru přidat soubor JAR ovladače JDBC a pak spustit odpovídající příkazy rozhraní příkazového řádku JBoss. Tyto příkazy musí nastavit zdroj dat při sestavování image Dockeru.

Následující kroky obsahují pokyny pro PostgreSQL, MySQL a SQL Server.

  1. Stáhněte ovladač JDBC pro PostgreSQL, MySQL nebo SQL Server.

    Rozbalte stažený archiv, abyste získali soubor JAR ovladače.

  2. Vytvořte soubor s podobným názvem jako module.xml a přidejte do něj následující kód. Nahraďte zástupnou hodnotu <module name> (včetně ostrých závorek) za org.postgres (PostgreSQL), com.mysql (MySQL) nebo com.microsoft (SQL Server). Nahraďte zástupnou hodnotu <JDBC .jar file path> za název souboru JAR z předchozího kroku, včetně úplné cesty k umístění, do kterého soubor umístíte ve vaší imagi Dockeru, například /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. Vytvořte soubor s podobným názvem jako datasource-commands.cli a přidejte do něj následující kód. Nahraďte zástupnou hodnotu <JDBC .jar file path> za hodnotu, kterou jste použili v předchozím kroku. Nahraďte zástupnou hodnotu <module file path> za název souboru a cestu z předchozího kroku, například /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. Aktualizujte pro svou aplikaci konfiguraci zdroje dat JTA:

    Otevřete soubor src/main/resources/META-INF/persistence.xml vaší aplikace a vyhledejte element <jta-data-source>. Následujícím způsobem nahraďte jeho obsah:

    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. Do souboru Dockerfile přidejte následující kód, který zajistí vytvoření zdroje dat při sestavování image Dockeru.

    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. Určete adresu DATABASE_CONNECTION_URL, která se má použít, protože je u každého databázového serveru jiná a liší se od hodnot na webu Azure Portal. WildFly vyžaduje použití následujících formátů adresy URL:

    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. Při vytváření souboru YAML nasazení v pozdější fázi budete muset předat proměnné prostředí DATABASE_CONNECTION_URL, DATABASE_SERVER_ADMIN_FULL_NAME a DATABASE_SERVER_ADMIN_PASSWORD s odpovídajícími hodnotami.

Další informace o konfiguraci připojení k databázi pomocí WildFly najdete v pokynech pro PostgreSQL, MySQL nebo SQL Server.

Nastavení prostředků JNDI

K nastavení jednotlivých prostředků JNDI, které potřebujete ve WildFly nakonfigurovat, obvykle použijete následující postup:

  1. Stáhněte potřebné soubory JAR a zkopírujte je do image Dockeru.
  2. Vytvořte soubor WildFly module.xml s odkazy na tyto soubory JAR.
  3. Vytvořte konfiguraci pro konkrétní prostředek JNDI.
  4. Vytvořte skript rozhraní příkazového řádku JBoss, který se při sestavování Dockeru použije k registraci prostředku JNDI.
  5. Přidejte vše do souboru Dockerfile.
  6. V souboru YAML nasazení předejte odpovídající proměnné prostředí.

Následující příklad ukazuje kroky potřebné k vytvoření prostředku JNDI umožňujícího připojení JMS ke službě Azure Service Bus.

  1. Stáhněte poskytovatele Apache Qpid JMS.

    Rozbalte stažený archiv, abyste získali soubory JAR.

  2. Ve složce /opt/servicebus vytvořte soubor s podobným názvem jako module.xml a přidejte do něj následující kód. Ujistěte se, že čísla verzí souborů JAR odpovídají názvům souborů JAR z předchozího kroku.

    <?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. Ve složce /opt/servicebus vytvořte soubor jndi.properties.

    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. Vytvořte soubor s podobným názvem jako servicebus-commands.cli a přidejte do něj následující kód.

    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. Do souboru Dockerfile přidejte následující kód, který zajistí vytvoření prostředku JNDI při sestavování image Dockeru.

    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. Při vytváření souboru YAML nasazení v pozdější fázi budete muset předat proměnné prostředí MDB_CONNECTION_FACTORY, DEFAULT_SBNAMESPACE a SB_SAS_POLICY, SB_SAS_KEY, MDB_QUEUE, SB_QUEUE, MDB_TOPIC a SB_TOPIC s odpovídajícími hodnotami.

Kontrola konfigurace WildFly

Projděte si příručku pro správce WildFly, která se věnuje všem dalším krokům před migrací, kterými se předchozí pokyny nezabývají.

Sestavení image Dockeru a její odeslání do služby Azure Container Registry

Po vytvoření souboru Dockerfile budete muset sestavit image Dockeru a publikovat ji ve službě Azure Container Registry.

Pokud jste použili naše úložiště Rychlého startu pro kontejner WildFly na GitHubu, proces sestavení image a jejího odeslání do služby Azure Container Registry bude spočívat v zavolání následujících tří příkazů.

V těchto příkladech proměnná prostředí MY_ACR obsahuje název vaší služby Azure Container Registry a proměnná MY_APP_NAME obsahuje název webové aplikace, kterou chcete ve službě Azure Container Registry použít.

Sestavení souboru WAR:

mvn package

Přihlášení ke službě Azure Container Registry:

az acr login --name ${MY_ACR}

Sestavení a odeslání image:

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

Případně můžete pomocí rozhraní příkazového řádku Dockeru image nejprve sestavit a otestovat místně, jak je znázorněno v následujících příkazech. Tento přístup může zjednodušit testování a doladění image před počátečním nasazením v ACR. Musíte však nainstalovat rozhraní příkazového řádku Dockeru a ujistit se, že je spuštěný proces démon Dockeru.

Sestavení image:

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

Místní spuštění image:

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

Vaše aplikace je teď přístupná na adrese http://localhost:8080.

Přihlášení ke službě Azure Container Registry:

az acr login --name ${MY_ACR}

Odeslání image do služby Azure Container Registry:

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

Podrobnější informace o sestavování imagí kontejnerů a jejich ukládání v Azure najdete ve výukovém modulu Sestavování a ukládání imagí kontejnerů s využitím služby Azure Container Registry.

Zřízení veřejné IP adresy

Pokud má být vaše aplikace přístupná mimo interní nebo virtuální sítě, budete potřebovat veřejnou statickou IP adresu. Tuto IP adresu byste měli zřídit ve skupině prostředků uzlu clusteru, jak je znázorněno v následujícím příkladu:

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

Nasazení do AKS

Vytvořte a použijte soubory YAML pro Kubernetes. Další informace najdete v tématu Rychlý start: Nasazení clusteru Azure Kubernetes Service pomocí Azure CLI. Pokud vytváříte externí nástroj pro vyrovnávání zatížení (pro aplikaci nebo kontroler příchozího přenosu dat), jako LoadBalancerIP zadejte IP adresu zřízenou v předchozí části.

Externalizované parametry zahrňte jako proměnné prostředí. Další informace najdete v tématu Definice proměnných prostředí pro kontejner. Nezahrnujte tajné kódy (například hesla, klíče rozhraní API a připojovací řetězce JDBC). Těmi se zabývá následující část.

Při vytváření souboru YAML nasazení nezapomeňte na nastavení paměti a procesoru, aby vaše kontejnery měly správnou velikost.

Konfigurace trvalého úložiště

Pokud vaše aplikace vyžaduje jiné než nestálé úložiště, nakonfigurujte minimálně jeden trvalý svazek.

Migrace naplánovaných úloh

Pro spouštění naplánovaných úloh v clusteru AKS definujte podle potřeby úlohy Cron pro Kubernetes. Další informace najdete v tématu Spouštění automatizovaných úkolů s využitím úloh Cron.

Po migraci

Teď když je vaše aplikace migrovaná do služby Azure Kubernetes Service, byste měli ověřit, že funguje podle očekávání. Až to uděláte, máme pro vás několik doporučení, která vaší aplikaci dodají výraznější nativně cloudový charakter.

Doporučení