Dela via

Migrera WebLogic Server-program till WildFly på Azure Kubernetes Service

  • Artikel

Den här guiden beskriver vad du bör känna till när du vill migrera ett befintligt WebLogic Server-program som ska köras på WildFly i en Azure Kubernetes Service-container.

Före migrering

För att säkerställa en lyckad migrering slutför du de utvärderings- och inventeringssteg som beskrivs i följande avsnitt innan du börjar.

Om du inte kan uppfylla kraven före migreringen kan du läsa guiden för kompletterande migrering:

Lagerserverkapacitet

Dokumentera maskinvaran (minne, CPU, disk) för de aktuella produktionsservrarna och det genomsnittliga och högsta antalet begäranden och resursanvändningen. Du behöver denna information oavsett vilken migrerings väg du väljer. Det är till exempel användbart att hjälpa dig att välja storlek på de virtuella datorerna i nodpoolen, mängden minne som ska användas av containern och hur många CPU-resurser containern behöver.

Det går att ändra storlek på nodpooler i AKS. Mer information finns i Ändra storlek på nodpooler i Azure Kubernetes Service (AKS).

Inventera alla hemligheter

Innan tekniker för konfiguration som en tjänst, till exempel Azure Key Vault, fanns det inget väldefinierat koncept för hemligheter. I stället hade du skilda uppsättningar konfigurationsinställningar som fungerade som det vi nu kallar hemligheter. Med appservrar som WebLogic Server finns dessa hemligheter i många olika konfigurationsfiler och konfigurationsarkiv. Kontrollera alla egenskaper och konfigurationsfiler på produktionsservrarna efter hemligheter och lösenord. Kontrollera weblogic.xml i dina WAR. Konfigurationsfiler som innehåller lösenord eller autentiseringsuppgifter kan också finnas i ditt program. Mer information finns i Grundläggande koncept för Azure Key Vault.

Inventera alla certifikat

Dokumentera alla certifikat som används för offentliga SSL-slutpunkter. Du kan visa alla certifikat på produktionsservrarna genom att köra följande kommando:

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

Inventera JNDI-resurser

Inventera alla JNDI-resurser. Till exempel kan datakällor som databaser, ha ett associerat JNDI-namn som gör det möjligt för JPA att korrekt binda instanser av EntityManager till en viss databas. Mer information om JNDI-resurser och databaser finns i WebLogic Server-datakällor i Oracle-dokumentationen. Andra JNDI-relaterade resurser som JMS asynkron meddelandekö kan kräva migrering eller omkonfiguration. Mer information om JMS-konfiguration finns i Oracle WebLogic Server 12.2.1.4.0.

Fastställ om sessionsreplikering används

Om ditt program förlitar sig på sessionsreplikering med eller utan Oracle Coherence*Web så har du två alternativ:

  • Omstrukturera ditt program att använda en databas för sessionshantering.
  • Omstrukturera ditt program att externalisera sessionen till Azure Redis-tjänsten. Mer information finns i Azure Cache for Redis.

Dokumentets datakällor

Om ditt program använder några databaser måste du samla in följande information:

  • What is the datakällans namn?
  • Vad är konfigurationen för anslutningspoolen?
  • Var hittar jag JAR-filen för JDBC-drivrutinen?

Mer information om JDBC-drivrutiner i WebLogic finns i Använda JDBC-drivrutiner med WebLogic Server.

Fastställ om WebLogic har anpassats

Fastställ vilken av följande anpassningar som har gjorts och registrera vad som har gjorts.

  • Har startskripten ändrats? Sådana skript är setDomainEnv, commEnv, startWebLogicoch stopWebLogic.
  • Finns det några speciella parametrar som skickas till JVM?
  • Har JAR lagts till i server-classpath?

Avgör om en anslutning till lokalt behövs

Om ditt program behöver har åtkomst till någon av dina lokala tjänster måste du etablera en av Azures anslutningstjänster. Mer information finns i Ansluta ett lokalt nätverk till Azure. Alternativt måste du omstrukturera programmet för att använda allmänt tillgängliga API:er som dina lokala resurser exponerar.

Ta reda på om JMS-köer eller -ämnen (Java Message Service) används

Om ditt program använder JMS-köer eller -ämnen måste du migrera dem till en extern JMS-server. Azure Service Bus och AMQP (Advanced Message Queueing Protocol) kan vara en bra migreringsstrategi för de som använder JMS. Mer information finns i Använda Java Message Service 1.1 med Azure Service Bus Standard och AMQP 1.0.

Om JMS beständiga arkiv har konfigurerats måste du avbilda konfigurationen och tillämpa den efter migreringen.

Fastställ om du använder dina egna anpassade Delade Java EE-bibliotek

Om du använder funktionen med Delade Java EE-bibliotek så har du två alternativ:

  • Återför programkoden för att ta bort alla beroenden i dina bibliotek, och inkludera i stället funktionerna direkt i programmet.
  • Lägg till biblioteken till server-classpath.

Ta reda på om OSGi-paket används

Om du använde OSGi-paket som lagts till i WebLogic-servern, måste du lägga till motsvarande JAR-filer direkt i ditt webbprogram.

Ta reda på om ditt program innehåller en operativsystemsspecifik kod

Om ditt program innehåller någon kod med beroenden på värdoperativsystemet måste du omstrukturera det för att ta bort dessa beroenden. Du kan till exempel behöva ersätta all användning av / eller \ i filsystemsökvägar med File.Separator eller Paths.get om programmet körs i Windows.

Fastställ om Oracle Service Bus används

Om ditt program använder Oracle Service Bus (OSB) måste du avbilda hur OSB har konfigurerats. Mer information finns i Om Oracle Service Bus-installationen.

Ta reda på om ditt program består av flera WAR

Om ditt program består av flera WAS så ska du behandla vart och ett av dem som separarata program och gå igenom den här guiden för varje.

Ta reda på om ditt program är paketerat som EAR

Om ditt program är paketerat som en EAR-fil bör du kontrollera filerna application.xml- och weblogic-application.xml och avbilda deras konfigurationer.

Kommentar

Om du vill kunna skala var och en av dina webbprogram oberoende av varandra för bättre användning av dina Azure Kubernetes Service-resurser bör du dela upp EAR i separata webbprogram.

Identifiera alla externa processer och daemons som körs på produktionsservrarna

Om du har processer som körs utanför programservern, som övervaknings-daemons så behöver du eliminera dem eller migrera dem någon annanstans.

Validera att Java-versionen som stöds fungerar som den ska

Användning av WildFly på Azure Kubernetes Service kräver en specifik version av Java, så du måste bekräfta att programmet körs korrekt med den version som stöds.

Kommentar

Den här verifieringen är särskilt viktig om den aktuella servern körs på en JDK som inte stöds (till exempel Oracle JDK eller IBM OpenJ9).

Du får den aktuella Java-versionen genom att logga in på din produktionsserver och köra följande kommando:

java -version

I Krav finns information om vilken version du ska använda för att köra WildFly.

Ta reda på om programmet är beroende av schemalagda jobb

Schemalagda jobb, till exempel Quartz Scheduler-uppgifter eller Unix cron-jobb, ska INTE användas med Azure Kubernetes Service (AKS). Azure Kubernetes Service förhindrar att du distribuerar ett program som innehåller schemalagda uppgifter internt. Om ditt program skalas ut kan dock samma schemalagda jobb köras mer än en gång per schemalagd period. Den här situationen kan leda till oönskade konsekvenser.

Om du vill köra schemalagda jobb på ditt AKS-kluster definierar du Kubernetes CronJobs efter behov. Mer information finns i Köra automatiserade uppgifter med ett CronJob.

Avgöra om WebLogic-skriptverktyget används

Om du för närvarande använder WebLogic Scripting Tool (WLST) för att utföra distributionen måste du utvärdera vad det gör. Om WLST ändrar några (körningsparametrar) för ditt program som en del av distributionen kontrollerar du att dessa parametrar överensstämmer med något av följande alternativ:

  • Parametrarna externaliseras som appinställningar.
  • Parametrarna är inbäddade i ditt program.
  • Parametrarna använder JBoss CLI under distributionen.

Om WLST gör mer än vad som nämns ovan har du lite extra arbete att göra under migreringen.

Kontrollera om ditt program använder WebLogic-specifika API:er

Om ditt program använder WebLogic-specifika API:er måste du omstrukturera det för att ta bort dessa beroenden. Om du till exempel har använt en klass som nämns i Java API-referensen för Oracle WebLogic Server använder ditt program ett WebLogic-specifikt API. Du måste omstrukturera för att ta bort referensen.

Ta reda på om ditt program använder entitetsbönor eller DMP-bönor med EJB 2.x-format

Om programmet använder entitetsbönor eller CMP-böner med EJB 2.x-format behöver du omstrukturera programmet och ta bort dessa beroenden.

Ta reda på om funktionen Java EE-programklient används

Om du har klientprogram som ansluter till (server)programmet med hjälp av Java EE Application Client-funktionen måste du omstrukturera både klientprogrammen och (server)programmet så att det använder HTTP-API:er.

Kontrollera om en distributionsplan användes

Om din app har distribuerats med hjälp av en distributionsplan ska du utvärdera vad distributionsplanen gör. Om distributionsplanen är en direkt distribution kan du distribuera ditt webbprogram utan några ändringar. Om distributionsplanen är mer detaljerad kan du avgöra om du kan använda JBoss CLI för att konfigurera programmet korrekt som en del av distributionen. Om det inte går att använda JBoss CLI omstrukturerar du programmet på ett sådant sätt att en distributionsplan inte längre behövs.

Ta reda på om EJB-timers används

Om programmet använder EJB-timers måste du validera att EJB-timerkoden kan utlösas av varje WildFly-instans separat. Denna verifiering behövs eftersom varje EJB-timer, i Azure Kubernetes Service-distributionsscenariot, utlöses på sin egen WildFly-instans.

Kontrollera om och hur filsystemet används

All användning av filsystemet på programservern kräver omkonfiguration eller i sällsynta fall arkitektoniska ändringar. Filsystemet kan användas av delade WebLogic-moduler eller av programkoden. Du kan identifiera några eller alla scenarier som beskrivs i följande avsnitt.

Skrivskyddat statiskt innehåll

Om ditt program för tillfället hanterar statiskt innehåll behöver du en alternativ plats för det. Du kanske kan tänka dig att flytta det statiska innehållet till Azure Blob Storage och lägga till Azure CDN för blixtsnabba nedladdningar globalt. Mer information finns i Värd för statiska webbplatser i Azure Storage och snabbstart: Integrera ett Azure Storage-konto med Azure CDN.

Dynamiskt publicerat statiskt innehåll

Om ditt program tillåter att statiskt innehåll laddas upp/skapas av ditt program, men inte kan ändras efter att det har skapats, så kan du använda Azure Blob Storage och Azure CDN enligt beskrivningen ovan, med en Azure-funktion för hantering av överföringar och CDN-uppdateringar. Vi har tillhandahållit en exempelimplementering som du kan använda i Överföra och CDN-för inläsa statiskt innehåll med Azure Functions.

Dynamiskt eller internt innehåll

För filer som ofta skrivs och läses av ditt program (till exempel temporära datafiler) eller statiska filer som endast är synliga för ditt program kan du montera Azure Storage-resurser som beständiga volymer. Mer information finns i Skapa och använda en volym med Azure Files i Azure Kubernetes Service (AKS).

Kontrollera om JCA-anslutningsprogram används

Om ditt program använder JCA-anslutningsprogram måste du kontrollera att JCA-anslutningen kan användas med WildFly. Om JCA-implementeringen är kopplad till WebLogic måste du omstrukturera programmet för att ta bort beroendet. Om det kan användas måste du lägga till JAR-filer till klassökvägen för servern och placera nödvändiga konfigurationsfiler på rätt plats i WildFly-serverkatalogerna.

Ta redan på om programmet använder en resursadapter

Om programmet behöver en resursadapter måste den vara kompatibel med WildFly. Ta reda på om resursadaptern fungerar som den ska på en fristående instans av WildFly genom att distribuera den till en server och konfigurera den på rätt sätt. Om resursadaptern fungerar som den ska måste du lägga till JAR-filer till serverklassökvägen för Docker-avbildningen och placera nödvändiga konfigurationsfiler på rätt plats i WildFly-serverkatalogerna.

Ta reda på om JAAS används

Om ditt program använder JAAS måste du avbilda hur JAAS har konfigurerats. Om en databas används kan du konvertera den till en JAAS-domän på WildFly. Om det är en anpassad implementering måste du verifiera att den kan användas på WildFly.

Fastställ om WebLogic-klustring används

Förmodligen har du distribuerat ditt program på flera WebLogic-servrar för att uppnå hög tillgänglighet. Azure Kubernetes Service kan skalas, men om du använde WebLogic-kluster-API:et måste du omstrukturera koden för att eliminera användningen av det API:et.

Utför testning på plats

Innan du skapar containeravbildningar ska du migrera ditt program till de JDK- och WildFly-versioner som du tänker använda på AKS. Testa programmet noggrant för att säkerställa kompatibilitet och prestanda.

Migrering

Etablera Azure Container Registry och Azure Kubernetes Service

Använd följande kommandon till att skapa ett containerregister och ett Azure Kubernetes-kluster med ett tjänsthuvudnamn som har läsarroll i registret. Se till att välja en lämplig nätverksmodell för klustrets nätverkskrav.

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

Skapa en Docker-avbildning för WildFly

Du behöver följande för att skapa en Dockerfile:

  • Ett JDK som stöds.
  • En installation av WildFly.
  • Dina JVM-körningsalternativ.
  • Ett sätt att överföra miljövariabler (om tillämpligt).

Du kan sedan utföra stegen som beskrivs i följande avsnitt, där det är tillämpligt. Du kan använda lagringsplatsen för WildFly-containersnabbstart som utgångspunkt för din Dockerfile och webbprogram.

Konfigurera KeyVault FlexVolume

Skapa ett Azure-valv och fyll i alla nödvändiga hemligheter. Mer information finns i Snabbstart: Ange och hämta en hemlighet från Azure Key Vault med hjälp av Azure CLI. Konfigurera sedan ett FlexVolume-nyckelvalv för att göra dessa hemligheter tillgängliga för poddar.

Du behöver också uppdatera startskriptet som används för bootstrap av WildFly. Det här skriptet måste importera certifikaten till nyckelarkivet som används av WildFly innan du startar servern.

Konfigurera datakällor

Om du vill konfigurera WildFly för åtkomst till en datakälla behöver du lägga till JDBC-drivrutinens JAR-fil till Docker-avbildningen och sedan köra lämpliga JBoss CLI-kommandon. Dessa kommandon måste konfigurera datakällan när du skapar Docker-avbildningen.

I följande steg ges instruktioner för PostgreSQL, MySQL och SQL Server.

  1. Ladda ned JDBC-drivrutinen för PostgreSQL, MySQL eller SQL Server.

    Packa upp nedladdningsarkivet för att hämta drivrutinens .jar -fil.

  2. Skapa en fil med ett namn som module.xml och lägg till följande markering. Ersätt platshållaren <module name> (inklusive vinkelparenteser) med org.postgres för PostgreSQL, com.mysql för MySQL eller com.microsoft för SQL Server. Ersätt <JDBC .jar file path> med namnet på .jar-filen från de föregående steget, inklusive den fullständiga sökvägen till den plats där du vill placera filen i Docker-avbildningen, till exempel i /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. Skapa en fil med ett namn som datasource-commands.cli och lägg till följande kod. Ersätt <JDBC .jar file path> med värdet du använde i det föregående steget. Ersätt <module file path> med filnamnet och sökvägen från det föregående steget, till exempel /opt/database/module.xml.

    Kommentar

    Microsoft rekommenderar att du använder det säkraste tillgängliga autentiseringsflödet. Det autentiseringsflöde som beskrivs i den här proceduren, till exempel för databaser, cacheminnen, meddelanden eller AI-tjänster, kräver en mycket hög grad av förtroende för programmet och medför risker som inte finns i andra flöden. Använd endast det här flödet när säkrare alternativ, till exempel hanterade identiteter för lösenordslösa eller nyckellösa anslutningar, inte är genomförbara. För lokala datoråtgärder föredrar du användaridentiteter för lösenordslösa eller nyckellösa anslutningar.

    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. Uppdatera JTA-datakällans konfiguration för programmet:

    Öppna src/main/resources/META-INF/persistence.xml-filen för din app och leta reda på <jta-data-source>-elementet. Ersätt innehållet enligt följande:

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

  5. Lägg till följande i Dockerfile så att datakällan skapas när du skapar Docker-avbildningen

    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. Bestäm vilken DATABASE_CONNECTION_URL som ska användas eftersom de är olika för varje databasserver, och skiljer sig från värdena på Azure Portal. URL-formaten som visas här kravs för användning av WildFly:

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

  7. När du skapar YAML för distribution i ett senare skede behöver du överföra följande miljövariabler, DATABASE_CONNECTION_URL, DATABASE_SERVER_ADMIN_FULL_NAME och DATABASE_SERVER_ADMIN_PASSWORD med lämpliga värden.

Kommentar

Microsoft rekommenderar att du använder det säkraste tillgängliga autentiseringsflödet. Det autentiseringsflöde som beskrivs i den här proceduren, till exempel för databaser, cacheminnen, meddelanden eller AI-tjänster, kräver en mycket hög grad av förtroende för programmet och medför risker som inte finns i andra flöden. Använd endast det här flödet när säkrare alternativ, till exempel hanterade identiteter för lösenordslösa eller nyckellösa anslutningar, inte är genomförbara. För lokala datoråtgärder föredrar du användaridentiteter för lösenordslösa eller nyckellösa anslutningar.

Mer information om hur du konfigurerar databasanslutning med WildFly finns i PostgreSQL, MySQL eller SQL Server.

Konfigurera JNDI-resurser

För att konfigurera varje JNDI-resurs du behöver konfigurera på WildFly använder du vanligtvis följande steg:

  1. Ladda ned de nödvändiga JAR-filerna och kopiera dem till Docker-avbildningen.
  2. Skapa en WildFly module.xml-fil som refererar till de JAR-filerna.
  3. Skapa alla konfigurationer som krävs av den specifika JNDI-resursen.
  4. Skapa JBoss CLI-skript som ska användas vid Docker-bygge för att registrera JNDI-resursen.
  5. Lägg till allt i Dockerfile.
  6. Över de lämpliga miljövariablerna i distributionens YAML-fil.

I exemplet nedan visas stegen som behövs för att skapa JNDI-resursen för JMS-anslutning till Azure Service Bus.

  1. Ladda ned Apache Qpid JMS-providern

    Packa upp nedladdningsarkivet för att hämta .jar-filerna.

  2. Skapa en fil med ett namn som module.xml och lägg till följande markering i /opt/servicebus. Kontrollera att JAR-filernas versionsnummer överensstämmer med namnen på JAR-filerna i föregående steg.

    <?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. Skapa en jndi.properties-fil i /opt/servicebus.

    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. Skapa en fil med ett namn som servicebus-commands.cli och lägg till följande kod.

    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. Lägg till följande i Dockerfile så att JNDI-resursen skapas när du skapar Docker-avbildningen

    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. När du skapar YAML för distribution i ett senare skede behöver du överföra följande miljövariabler, MDB_CONNECTION_FACTORY, DEFAULT_SBNAMESPACE och SB_SAS_POLICY, SB_SAS_KEY, MDB_QUEUE, SB_QUEUE, MDB_TOPIC och SB_TOPIC med lämpliga värden.

Granska WildFly-konfiguration

Läs administratörsguiden för WildFly för att ta del av eventuella ytterligare steg före migrering som inte tas upp i de föregående anvisningarna.

Skapa och överföra Docker-avbildningen till Azure Container Registry

När du har skapat Dockerfile måste du skapa Docker-avbildningen och publicera den i ditt Azure-containerregister.

Om du har använt vår GitHub-lagringsplats för WildFly-containersnabbstart är processen för att skapa och överföra avbildningen till ditt Azure-containerregister densamma som att anropa följande tre kommandon.

I dessa exempel innehåller MY_ACR-miljövariabeln namnet på ditt Azure-containerregister och MY_APP_NAME-variabeln innehåller namnet på det webbprogram som du vill använda i ditt Azure-containerregister.

Skapa WAR-filen:

mvn package

Logga in på ditt Azure-containerregister:

az acr login --name ${MY_ACR}

Skapa och överföra avbildningen:

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

Du kan också använda Docker CLI för att först skapa och testa avbildningen lokalt, enligt följande kommandon. Den här metoden kan förenkla testningen och förfina avbildningen före den första distributionen till ACR. Du måste dock installera Docker CLI och se till att Docker-daemon körs.

Skapa avbildningen:

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

Kör avbildningen lokalt:

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

Nu kan du komma åt ditt program på http://localhost:8080.

Logga in på ditt Azure-containerregister:

az acr login --name ${MY_ACR}

Överför avbildningen till Azure-containerregistret:

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

Mer detaljerad information om hur du skapar och lagrar containeravbildningar finns i Learn-modulen Skapa och lagra containeravbildningar med Azure Container Registry.

Distribuera en offentlig IP-adress

Om ditt program ska vara tillgängligt utanför dina interna eller virtuella nätverk behöver du en offentlig statisk IP-adress. Du bör etablera den här IP-adressen i klustrets nodresursgrupp, enligt följande exempel:

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

Distribuera till Azure Kubernetes Service (AKS)

Skapa och använd dina Kubernetes YAML-fil(er). Mer information finns i Snabbstart: Distribuera ett AKS-kluster (Azure Kubernetes Service) med hjälp av Azure CLI. Om du skapar en extern lastbalanserare (oavsett om det är för ditt program eller en ingångskontroll) måste du ange IP-adressen som etablerades i föregående avsnitt som LoadBalancerIP.

Ta med externa parametrar som miljövariabler. Mer information finns i artikeln om att definiera miljövariabler för en container. Ta inte med hemligheter (till exempel lösenord, API-nycklar och JDBC-anslutningssträngar). Dessa beskrivs i följande avsnitt.

Se till att inkludera minnes- och CPU-inställningar när du skapar distributionens YAML-fil så att containrarna får rätt storlek.

Konfigurera beständig lagring

Om programmet kräver icke-flyktig lagring kan du konfigurera en eller flera Beständiga volymer.

Migrera schemalagda jobb

Om du vill köra schemalagda jobb på ditt AKS-kluster definierar du Kubernetes CronJobs efter behov. Mer information finns i Köra automatiserade uppgifter med ett CronJob.

Efter migreringen

Nu när du har migrerat ditt program till Azure Kubernetes Service kontrollerar du att det fungerar som förväntat. När du har gjort det kan du se följande rekommendationer för att göra ditt program mer molnbaserat.

Rekommendationer