Sdílet prostřednictvím

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

  • Článek

Tato příručka popisuje, o čem byste měli vědět, když chcete migrovat existující aplikaci Serveru WebLogic, která se má spouštět na 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.

Pokud nemůžete splnit požadavky na předběžnou migraci, projděte si doprovodnou příručku k migraci:

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ů

Před nástupem technologií „konfigurace jako služba“ typu Azure Key Vault neexistoval řádně definovaný koncept „tajných kódů“. Místo toho jste měli různorodou sadu konfiguračních nastavení, která v podstatě fungovala stejně jako dnešní „tajné kódy“. Při používání aplikačních serverů, jako je server WebLogic, se tyto tajné kódy nacházejí v mnoha různých konfiguračních souborech a úložištích konfigurací. Ve všech vlastnostech a konfiguračních souborech na produkčních serverech vyhledejte tajné kódy a hesla. Nezapomeňte zkontrolovat soubor weblogic.xml v souborech WAR. Konfigurační soubory obsahující hesla nebo přihlašovací údaje se mohou nacházet také ve vaší aplikaci. Další informace najdete v článku Základní koncepty služby Azure Key Vault.

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>

Inventarizace prostředků JNDI

Proveďte inventarizaci všech prostředků JNDI. Zdroje dat, jako jsou databáze, mohou mít například přidružený název JNDI, který umožňuje JPA správně navazovat instance EntityManager ke konkrétní databázi. Další informace o prostředcích a databázích JNDI najdete v článku Zdroje dat serveru WebLogic v dokumentaci Oracle. Jiné prostředky související s JNDI, například zprostředkovatelé zpráv JMS, mohou vyžadovat migraci nebo změnu konfigurace. Další informace o konfiguraci JMS naleznete v tématu Oracle WebLogic Server 12.2.1.4.0.

Určení, zda se používá replikace relace

Pokud vaše aplikace spoléhá na replikaci relace, ať už s modulem Oracle Coherence*Web, nebo bez něj, máte dvě možnosti:

  • Refaktorujte aplikaci tak, aby používala databázi pro správu relace.
  • Refaktorujte aplikaci tak, aby externalizovala relaci do služby Azure Redis. Další informace najdete v článku, který se věnuje službě Azure Cache for Redis.

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 o ovladačích JDBC u serveru WebLogic najdete v článku o používání ovladačů JDBC se serverem WebLogic.

Určení, zda byla platforma WebLogic přizpůsobena

Určete, která z následujících přizpůsobení byla provedena, a zachyťte provedenou akci.

  • Došlo ke změně spouštěcích skriptů? Mezi tyto skripty patří setDomainEnv, commEnv, startWebLogic a stopWebLogic.
  • Byly do prostředí JVM předány nějaké konkrétní parametry?
  • Byly do cesty ke třídě serveru přidány nějaké soubory JAR?

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 věnovaném 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 Použití služby Java Message Service 1.1 se standardem služby Azure Service Bus a 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 používáte své vlastní vytvořené sdílené knihovny Java EE

Pokud používáte funkci sdílených knihoven Java EE, máte dvě možnosti:

  • Refaktorováním kódu své aplikace odeberte všechny závislosti na těchto knihovnách a místo toho začleňte jejich funkčnost přímo do aplikace.
  • Přidejte tyto knihovny do cesty ke třídám serveru.

Určení, jestli se používají sady OSGi

Pokud jste použili sady OSGi přidané na server WebLogic, budete muset přidat ekvivalentní soubory JAR přímo do webové aplikace.

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, musíte ho refaktorovat, abyste tyto závislosti odebrali. Může být například nutné nahradit jakékoli použití / cest systému souborů nebo \ v cestě File.Separator k systému souborů nebo Paths.get v případě, že je vaše aplikace spuštěná ve Windows.

Určení, jestli se používá Oracle Service Bus

Pokud vaše aplikace používá Oracle Service Bus (OSB), budete muset zjistit konfiguraci OSB. Další informace najdete v článku Informace o instalaci Oracle Service Bus.

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 weblogic-application.xml a poznačte si jejich konfiguraci.

Poznámka:

Pokud chcete mít možnost škálovat jednotlivé webové aplikace nezávisle na tom, abyste mohli lépe využívat prostředky služby Azure Kubernetes Service, měli byste rozdělit ear do samostatných webových aplikací.

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.

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.

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 se používá nástroj pro skriptování WebLogic

Pokud k nasazení aktuálně používáte nástroj WLST (WebLogic Scripting Tool), budete muset posoudit, co to dělá. Pokud WLST mění některé parametry aplikace (runtime) v rámci nasazení, ujistěte se, že tyto parametry odpovídají jedné z následujících možností:

  • Parametry se externalizují jako nastavení aplikace.
  • Parametry jsou vloženy do vaší aplikace.
  • Parametry během nasazování používají rozhraní příkazového řádku JBoss.

Pokud WLST dělá víc, než je uvedeno výše, budete mít během migrace ještě další práci.

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

Pokud vaše aplikace využívá rozhraní API specifická pro WebLogic, musíte je refaktorovat, aby se tyto závislosti odstranili. Pokud jste například použili třídu uvedenou v referenčních informacích k Java API pro Oracle WebLogic Server, znamená to, že jste ve vaší aplikaci použili rozhraní API specifické pro WebLogic. Abyste mohli odkaz odebrat, musíte refaktorovat.

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 se použil plán nasazení

Pokud byla vaše aplikace nasazená pomocí plánu nasazení, vyhodnoťte, co plán nasazení dělá. Pokud plán znamená přímé nasazení, můžete webovou aplikaci nasadit bez jakýchkoli změn. Pokud je plán nasazení propracovanější, určete, jestli můžete pomocí rozhraní příkazového řádku JBoss správně nakonfigurovat aplikaci jako součást nasazení. Pokud není možné použít JBoss CLI, refaktorujte aplikaci takovým způsobem, aby plán nasazení už nebyl potřeba.

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 a jak se používá systém souborů

Jakékoli použití systému souborů na aplikačním serveru vyžaduje změnu konfigurace nebo ve výjimečných případech změny architektury. Systém souborů může být používán sdílenými moduly WebLogic nebo kódem vaší aplikace. Můžete identifikovat některé nebo všechny scénáře popsané v následujících částech.

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.

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.

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 tématu Vytvoření a použití svazku se službou Azure Files ve službě Azure Kubernetes Service (AKS).

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

Pokud vaše aplikace používá konektory JCA, budete muset ověřit, že se konektor JCA dá použít ve WildFly. Pokud je implementace JCA navázaná na WebLogic, 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 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 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 se používá clustering WebLogic

Kvůli dosažení vysoké dostupnosti jste aplikaci pravděpodobně nasadili na několik serverů WebLogic. Služba Azure Kubernetes Service je schopná škálovat, ale pokud jste použili rozhraní API clusteru WebLogic, musíte refaktorovat kód, aby se eliminovalo použití tohoto rozhraní API.

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.

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.

    Poznámka:

    Microsoft doporučuje používat nejbezpečnější dostupný tok ověřování. Tok ověřování popsaný v tomto postupu, například pro databáze, mezipaměti, zasílání zpráv nebo služby AI, vyžaduje velmi vysoký stupeň důvěryhodnosti v aplikaci a nese rizika, která nejsou přítomna v jiných tocích. Tento tok používejte pouze v případě, že nejsou možné zabezpečit možnosti, jako jsou spravované identity pro připojení bez hesla nebo bez klíčů. V případě místních operací počítačů upřednostňujete identity uživatelů pro připojení bez hesla nebo bez klíčů.

    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

  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:

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

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

  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.

Poznámka:

Microsoft doporučuje používat nejbezpečnější dostupný tok ověřování. Tok ověřování popsaný v tomto postupu, například pro databáze, mezipaměti, zasílání zpráv nebo služby AI, vyžaduje velmi vysoký stupeň důvěryhodnosti v aplikaci a nese rizika, která nejsou přítomna v jiných tocích. Tento tok používejte pouze v případě, že nejsou možné zabezpečit možnosti, jako jsou spravované identity pro připojení bez hesla nebo bez klíčů. V případě místních operací počítačů upřednostňujete identity uživatelů pro připojení bez hesla nebo bez klíčů.

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 služby Azure Kubernetes Service (AKS)

Vytvořte a použijte soubory YAML pro Kubernetes. Další informace najdete v tématu Rychlý start: Nasazení clusteru Azure Kubernetes Service (AKS) 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í. Potom se podívejte na následující doporučení, která vaší aplikaci usnadní nativní cloud.

Doporučení