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

Článek
10/23/2023

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:

Migrace serverových aplikací WebLogic do služby Azure Virtual Machines

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 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 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, 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ží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. 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 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
Nastavení zdrojů dat
Nastavení prostředků JNDI
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.

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

Rozbalte stažený archiv, abyste získali soubor JAR ovladače.
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>
```

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

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

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

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;

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:

Stáhněte potřebné soubory JAR a zkopírujte je do image Dockeru.
Vytvořte soubor WildFly module.xml s odkazy na tyto soubory JAR.
Vytvořte konfiguraci pro konkrétní prostředek JNDI.
Vytvořte skript rozhraní příkazového řádku JBoss, který se při sestavování Dockeru použije k registraci prostředku JNDI.
Přidejte vše do souboru Dockerfile.
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.

Stáhněte poskytovatele Apache Qpid JMS.

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

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>

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}

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

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

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

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í

Zvažte přidání názvu DNS k IP adrese přidělené vašemu kontroleru příchozího přenosu dat nebo nástroji pro vyrovnávání zatížení aplikace. Další informace najdete v tématu Vytvoření kontroleru příchozího přenosu dat se statickou veřejnou IP adresou v AKS.
Zvažte přidání diagramů HELM pro aplikaci. Tyto grafy umožňují parametrizovat nasazení aplikace tak, aby ji mohli používat a přizpůsobovat různorodí zákazníci.
Navrhněte a implementujte strategii DevOps. Pokud chcete zachovat spolehlivost a zároveň zvýšit rychlost vývoje, zvažte automatizaci nasazení a testování pomocí Azure Pipelines. Další informace najdete v tématu Sestavení a nasazení do AKS.
Povolte pro cluster monitorování Azure. Další informace najdete v tématu Povolení monitorování již nasazeného clusteru AKS. Díky tomu bude služba Azure Monitor moct shromažďovat protokoly kontejnerů, sledovat využití atd.
Zvažte zpřístupnění metrik specifických pro aplikaci přes Prometheus. Prometheus je opensourcová architektura metrik široce přijímaná v komunitě Kubernetes. Pokud chcete umožnit agregaci metrik z aplikací a automatizovanou odezvu na abnormální stavy nebo jejich eskalaci, můžete místo hostování vlastního serveru Prometheus nakonfigurovat získávání metrik Prometheus ze služby Azure Monitor. Další informace najdete v tématu Konfigurace získávání metrik Prometheus pomocí služby Azure Monitor pro kontejnery.
Navrhněte a implementujte strategii provozní kontinuity a zotavení po havárii. U nepostradatelných aplikací zvažte architekturu nasazení ve více oblastech. Další informace najdete v tématu Osvědčené postupy pro provozní kontinuitu a zotavení po havárii v AKS.
Projděte si zásady podpory verzí Kubernetes. Je vaší zodpovědností udržovat cluster AKS aktualizovaný a zajistit, aby byla neustále provozována podporovaná verze. Další informace najdete v tématu Upgrade clusteru AKS.
Všechny členy týmu, kteří zodpovídají za správu clusteru a vývoj aplikací, nechejte přečíst příslušné osvědčené postupy pro AKS. Další informace najdete v tématu Osvědčené postupy při vytváření a správě aplikací v AKS pro vývojáře a operátory cloudu.
Ujistěte se, že váš soubor nasazení obsahuje definici způsobu provádění kumulativních aktualizací. Další informace najdete v tématu věnovaném nasazování kumulativních aktualizací v dokumentaci ke Kubernetes.
Nastavte automatické škálování, které vám umožní zvládnout zatížení ve špičce. Další informace najdete v tématu Automatické škálování clusteru za účelem splnění požadavků aplikace na AKS.
Pokud chcete dosáhnout lepší optimalizace výkonu, zvažte monitorování velikosti mezipaměti kódu a přidání parametrů JVM -XX:InitialCodeCacheSize a -XX:ReservedCodeCacheSize do souboru Dockerfile. Další informace najdete v tématu věnovaném ladění mezipaměti kódu v dokumentaci Oracle.

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

Před migrací

Inventarizace kapacity serverů

Inventarizace všech tajných kódů

Inventarizace všech certifikátů

Inventarizace prostředků JNDI

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

Dokumentování zdrojů dat

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

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

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

Určení, jestli používáte své vlastní vytvořené sdílené knihovny Java EE

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

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

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

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

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

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

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

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

Určení, jestli se používá nástroj pro skriptování WebLogic

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

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

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

Určení, jestli se použil plán nasazení

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

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

Statický obsah jen pro čtení

Dynamicky publikovaný statický obsah

Dynamický nebo interní obsah

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

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

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

Určení, jestli se používá clustering WebLogic

Místní testování

Migrace

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

Vytvoření image Dockeru pro WildFly

Konfigurace svazku FlexVolume služby Key Vault

Nastavení zdrojů dat

Nastavení prostředků JNDI

Kontrola konfigurace WildFly

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

Zřízení veřejné IP adresy

Nasazení do AKS

Konfigurace trvalého úložiště

Migrace naplánovaných úloh

Po migraci

Doporučení

Váš názor

Váš názor

Další materiály