Delen via

WebLogic Server-toepassingen migreren naar WildFly in Azure Kubernetes Service

  • Artikel

In deze handleiding wordt beschreven waar u rekening mee moet houden wanneer u een bestaande WebLogic Server-toepassing wilt migreren om uit te voeren op WildFly in een Azure Kubernetes Service-container.

Premigratie

Voltooi voordat u begint de evaluatie- en inventarisstappen die in de volgende secties worden beschreven om een geslaagde migratie te garanderen.

Als u niet aan de vereisten voor de premigratie kunt voldoen, raadpleegt u de aanvullende migratiehandleiding:

Servercapaciteit inventariseren

Documenteer de hardware (geheugen, CPU, schijf) van de huidige productieserver(s) en het gemiddelde en piekaantal aanvragen en het resourcegebruik. U hebt deze informatie nodig, welk migratiepad u ook kiest. Het is bijvoorbeeld handig bij het selecteren van de grootte van de VM's in uw knooppuntgroep, de hoeveelheid geheugen die door de container moet worden gebruikt en hoeveel CPU-shares de container nodig heeft.

Het is mogelijk om het formaat van knooppuntgroepen in AKS te wijzigen. Zie Het formaat van knooppuntgroepen wijzigen in Azure Kubernetes Service (AKS) voor meer informatie.

Alle geheimen inventariseren

Voor de ontwikkeling van 'configuratie als een service'-technologieën zoals Azure Key Vault, was er geen goed gedefinieerd concept voor 'geheimen'. In plaats daarvan had u een set uiteenlopende configuratie-instellingen die functioneerden als wat we nu 'geheimen' noemen. Bij app-servers zoals WebLogic Server bevinden deze geheimen zich in veel verschillende configuratiebestanden en configuratiearchieven. Controleer alle eigenschaps- en configuratiebestanden op de productieserver(s) op geheimen en wachtwoorden. Controleer in elk geval weblogic.xml in uw WAR's. Mogelijk bevinden zich ook in uw toepassing configuratiebestanden met wachtwoorden of referenties. Zie Basisconcepten van Azure Key Vault voor meer informatie.

Alle certificaten inventariseren

Documenteer alle certificaten die worden gebruikt voor openbare SSL-eindpunten. U kunt alle certificaten op de productieserver(s) weergeven door de volgende opdracht uit te voeren:

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

JNDI-resources inventariseren

Inventariseer alle JNDI-resources. Gegevensbronnen zoals databases kunnen bijvoorbeeld een gekoppelde JNDI-naam hebben waarmee JPA op de juiste wijze exemplaren van EntityManager aan een bepaalde database kan binden. Zie WebLogic Server-gegevensbronnen in de Oracle-documentatie voor meer informatie over JNDI-resources en -databases. Andere JNDI-gerelateerde resources, zoals JMS-berichtenbrokers, moeten mogelijk worden gemigreerd of opnieuw worden geconfigureerd. Zie Oracle WebLogic Server 12.2.1.4.0 voor meer informatie over de JMS-configuratie.

Bepalen of sessiereplicatie wordt gebruikt

Als uw toepassing afhankelijk is van sessiereplicatie, met of zonder Oracle Coherence*Web, hebt u twee opties:

  • Herstructureer uw toepassing om een database te gebruiken voor sessiebeheer.
  • Herstructureer uw toepassing om de sessie te externaliseren naar Azure Redis Service. Zie Azure Cache voor Redis voor meer informatie.

Gegevensbronnen documenteren

Als uw toepassing gebruikmaakt van databases, moet u de volgende informatie vastleggen:

  • Wat is de naam van de gegevensbron?
  • Wat is de configuratie van de verbindingsgroep?
  • Waar vind ik het JAR-bestand van het JDBC-stuurprogramma?

Zie JDBC-stuurprogramma's gebruiken met WebLogic Server voor meer informatie over JDBC-stuurprogramma's in WebLogic.

Bepalen of WebLogic is aangepast

Bepaal welke van de volgende aanpassingen zijn uitgevoerd en leg vast wat er is gebeurd.

  • Zijn de opstartscripts gewijzigd? Dergelijke scripts bevatten setDomainEnv, commEnv, startWebLogic en stopWebLogic.
  • Zijn er specifieke parameters aan de JVM doorgegeven?
  • Zijn er JAR's toegevoegd aan het classpath van de server?

Bepalen of er een verbinding met on-premises services is vereist

Als voor uw toepassing toegang nodig is tot een van uw on-premises services, moet u een van de connectiviteitsservices van Azure inrichten. Zie Connect an on-premises network to Azure (Een on-premises netwerk verbinden met Azure) voor meer informatie. U moet uw toepassing ook herstructureren voor het gebruik van openbaar beschikbare API's in uw on-premises resources.

Bepalen of Java Message Service-wachtrijen (JMS) of -onderwerpen in gebruik zijn

Als uw toepassing JMS-wachtrijen of -onderwerpen gebruikt, moet u deze migreren naar een extern gehoste JMS-server. Azure Service Bus en het Advanced Message Queueing Protocol (AMQP) kunnen een uitstekende migratiestrategie zijn wanneer er gebruik wordt gemaakt van JMS. Zie Java Message Service 1.1 gebruiken met Azure Service Bus Standard en AMQP 1.0 voor meer informatie.

Als er met JMS permanente archieven zijn geconfigureerd, moet u de configuratie hiervan vastleggen en na de migratie toepassen.

Bepalen of u uw eigen aangepaste, gedeelde Java EE-bibliotheken gebruikt

Als u de functie Gedeelde Java EE-bibliotheek gebruikt, hebt u twee opties:

  • Herstructureer uw toepassingscode om alle afhankelijkheden van uw bibliotheken te verwijderen en de functionaliteit in plaats daarvan rechtstreeks in uw toepassing op te nemen.
  • Voeg de bibliotheken toe aan het klassepad van de server.

Bepalen of OSGi-bundels worden gebruikt

Als u OSGi-bundels hebt toegevoegd aan de WebLogic-server, moet u de equivalente JAR-bestanden rechtstreeks aan uw webtoepassing toevoegen.

Bepalen of uw toepassing code bevat die specifiek is voor het besturingssysteem

Als uw toepassing code bevat met afhankelijkheden van het host-besturingssysteem, moet u deze herstructureren om deze afhankelijkheden te verwijderen. U moet bijvoorbeeld het gebruik van / of \ in bestandssysteempaden vervangen door File.Separator of Paths.get als uw toepassing wordt uitgevoerd in Windows.

Bepalen of Oracle Service Bus wordt gebruikt

Als uw toepassing gebruikmaakt van Oracle Service Bus (OSB), moet u vastleggen hoe OSB is geconfigureerd. Zie Over de Oracle Service Bus-installatievoor meer informatie.

Bepalen of uw toepassing bestaat uit meerdere WAR's

Als uw toepassing bestaat uit meerdere WAR's, moet u deze allemaal behandelen als afzonderlijke toepassingen en deze handleiding voor al deze WAR's doorlopen.

Bepalen of uw toepassing is verpakt als een EAR

Als uw toepassing is verpakt als een EAR-bestand, moet u de bestanden application.xml en weblogic-application.xml controleren en de configuratie ervan vastleggen.

Notitie

Als u elk van uw webtoepassingen onafhankelijk wilt kunnen schalen voor een beter gebruik van uw Azure Kubernetes Service-resources, moet u het EAR opsplitsen in afzonderlijke webtoepassingen.

Alle externe processen en daemons identificeren die worden uitgevoerd op de productieservers

U moet alle processen die buiten de toepassingsserver worden uitgevoerd, zoals controledaemons, verwijderen of naar een andere locatie migreren.

Controleren of de ondersteunde Java-versie goed werkt

Voor het gebruik van WildFly in Azure Kubernetes Service is een specifieke versie van Java vereist. U moet dus controleren of uw toepassing correct wordt uitgevoerd met die ondersteunde versie.

Notitie

Deze validatie is vooral belangrijk als uw huidige server wordt uitgevoerd in een niet-ondersteunde JDK (zoals Oracle JDK of IBM OpenJ9).

Meld u aan bij uw productieserver en voer de volgende opdracht uit om uw huidige Java-versie te verkrijgen:

java -version

Raadpleeg Vereisten voor hulp bij welke versie u moet gebruiken om WildFly uit te voeren.

Bepalen of uw toepassing gebruikmaakt van geplande taken

Geplande taken, zoals Quartz Scheduler-taken of Unix Cron-taken, mogen niet worden gebruikt met Azure Kubernetes Service (AKS). Azure Kubernetes Service zal niet voorkomen dat u een toepassing met geplande taken intern implementeert. Als uw toepassing echter wordt uitgeschaald, kan dezelfde geplande taak meer dan één keer per geplande periode worden uitgevoerd. Deze situatie kan tot onbedoelde gevolgen leiden.

Als u geplande taken wilt uitvoeren in uw AKS-cluster, moet u de benodigde Kubernetes Cron-taken definiëren. Zie Running Automated Tasks with a CronJob (Engelstalig) voor meer informatie.

Bepalen of weblogic scripting tool wordt gebruikt

Als u momenteel het WebLogic Scripting Tool (WLST) gebruikt om de implementatie uit te voeren, moet u beoordelen wat het doet. Als WLST parameters van uw toepassing wijzigt als onderdeel van de implementatie, moet u ervoor zorgen dat deze parameters voldoen aan een van de volgende opties:

  • De parameters worden ge externaliseerd als app-instellingen.
  • De parameters worden ingesloten in uw toepassing.
  • De parameters gebruiken de JBoss CLI tijdens de implementatie.

Als WLST meer doet dan hierboven wordt vermeld, hebt u wat extra werk te doen tijdens de migratie.

Nagaan of uw toepassing code bevat die specifiek is voor WebLogic-API's

Als uw toepassing gebruikmaakt van WebLogic-specifieke API's, moet u deze herstructureren om deze afhankelijkheden te verwijderen. Als u bijvoorbeeld een klasse hebt gebruikt die wordt vermeld in de Java API Reference for Oracle WebLogic Server, hebt u een WebLogic-specifieke API in uw toepassing gebruikt. U moet de verwijzing herstructureren om de verwijzing te verwijderen.

Bepalen of uw toepassing gebruikmaakt van entiteitsbeans of CMP-beans van het type EJB 2.x

Als uw toepassing gebruikmaakt van entiteitsbeans of CMP-beans van het type EJB 2.x, moet u de toepassing herstructureren om deze afhankelijkheden te verwijderen.

Bepalen of de functie Java EE Application Client wordt gebruikt

Als u clienttoepassingen hebt die verbinding maken met uw (server)toepassing met behulp van de functie Java EE Application Client, moet u de clienttoepassingen en de (server)toepassing herstructureren voor het gebruik van HTTP-API's.

Nagaan of een implementatieplan is gebruikt

Als uw app is geïmplementeerd met behulp van een implementatieplan, beoordeelt u wat het implementatieplan doet. Als het implementatieplan een vrij eenvoudig te implementeren is, kunt u uw webtoepassing zonder wijzigingen implementeren. Als het implementatieplan uitgebreider is, bepaalt u of u de JBoss CLI kunt gebruiken om uw toepassing correct te configureren als onderdeel van de implementatie. Als het niet mogelijk is om de JBoss CLI te gebruiken, moet u uw toepassing zodanig herstructureren dat een implementatieplan niet meer nodig is.

Bepalen of EJB-timers worden gebruikt

Als in uw toepassing EJB-timers worden gebruikt, moet u controleren of de EJB-timercode door elk WildFly-exemplaar afzonderlijk kan worden geactiveerd. Deze validatie is vereist omdat elke EJB-timer in het implementatiescenario voor Azure Kubernetes Service wordt geactiveerd op een eigen WildFly-exemplaar.

Nagaan of en hoe het bestandssysteem wordt gebruikt

Voor elk gebruik van het bestandssysteem op de toepassingsserver is herconfiguratie vereist of, in zeldzame gevallen, architectuurwijzigingen. Het bestandssysteem kan worden gebruikt door gedeelde WebLogic-modules of door uw toepassingscode. U kunt enkele of alle scenario's identificeren die in de volgende secties worden beschreven.

Statische alleen-lezeninhoud

Als uw toepassing momenteel met statische inhoud werkt, hebt u hiervoor een alternatieve locatie nodig. U kunt statische inhoud verplaatsen naar Azure Blob Storage en Azure CDN toevoegen voor razendsnelle downloads wereldwijd. Zie statische websitehosting in Azure Storage en quickstart: Een Azure-opslagaccount integreren met Azure CDN voor meer informatie.

Dynamisch gepubliceerde statische inhoud

Als uw toepassing statische inhoud toestaat die wordt geüpload/geproduceerd door uw toepassing, maar onveranderbaar is nadat deze is gemaakt, kunt u Azure Blob Storage en Azure CDN gebruiken zoals hierboven beschreven, met een Azure-functie om uploads en CDN-vernieuwing te verwerken. U vindt een voorbeeldimplementatie voor gebruik in Statische inhoud uploaden en via CDN vooraf laden met Azure Functions.

Dynamische of interne inhoud

Voor bestanden die vaak worden gelezen en waarin regelmatig gegevens worden geschreven door uw toepassing (zoals tijdelijke gegevensbestanden), of voor statische bestanden die alleen zichtbaar zijn voor uw toepassing, kunt u Azure Storage-shares koppelen als permanente volumes. Zie Een volume maken en gebruiken met Azure Files in Azure Kubernetes Service (AKS) voor meer informatie.

Nagaan of andere JCA-connectors worden gebruikt

Als uw toepassing JCA-connectors gebruikt, moet u de JCA-connector valideren die op WildFly kan worden gebruikt. Als de JCA-implementatie is gekoppeld aan WebLogic, moet u de toepassing herstructureren om deze afhankelijkheid te verwijderen. Als deze kan worden gebruikt, moet u de JAR's aan het klassepad van de server toevoegen en de benodigde configuratiebestanden op de juiste locatie in de WildFly-serverdirectory's plaatsen zodat deze beschikbaar zijn.

Bepalen of uw toepassing gebruikmaakt van een resourceadapter

Als voor uw toepassing een resourceadapter (RA) vereist is, moet deze compatibel zijn met WildFly. Bepaal of de RA correct functioneert op een zelfstandig exemplaar van WildFly door deze op de server te implementeren en juist te configureren. Als de RA correct functioneert, moet u de JAR's aan het klassepad van de Docker-installatiekopie toevoegen en de benodigde configuratiebestanden op de juiste locatie in de WildFly-serverdirectory's plaatsen zodat deze beschikbaar zijn.

Bepalen of JAAS wordt gebruikt

Als uw toepassing gebruikmaakt van JAAS, moet u vastleggen hoe JAAS is geconfigureerd. Als er een database wordt gebruikt, kunt u deze converteren naar een JAAS-domein op WildFly. Als het een aangepaste implementatie is, moet u controleren of deze kan worden gebruikt op WildFly.

Bepalen of WebLogic-clustering wordt gebruikt

Waarschijnlijk hebt u uw toepassing geïmplementeerd op meerdere WebLogic-servers om hoge beschikbaarheid te garanderen. Azure Kubernetes Service kan worden geschaald, maar als u de WebLogic Cluster-API hebt gebruikt, moet u uw code herstructureren om het gebruik van die API te elimineren.

In-place tests uitvoeren

Voordat u containerinstallatiekopieën maakt, migreert u uw toepassing naar de JDK en WildFly-versies die u wilt gebruiken in AKS. Test de toepassing grondig op compatibiliteit en prestaties.

Migratie

Azure Container Registry en Azure Kubernetes Service inrichten

Maak een containerregister en een Azure Kubernetes-cluster waarvan de service-principal de lezersrol heeft in het register met behulp van de volgende opdrachten. Zorg ervoor dat u het juiste netwerkmodel kiest voor de netwerkvereisten van uw cluster.

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

Een Docker-installatiekopie voor WildFly maken

Voordat u een Dockerfile maakt, moet aan de volgende vereisten zijn voldaan:

  • Een ondersteunde JDK.
  • Een installatie van WildFly.
  • Uw JVM-runtimeopties.
  • Een manier om omgevingsvariabelen door te geven (indien van toepassing).

U kunt vervolgens de stappen uitvoeren die in de volgende secties worden beschreven, indien van toepassing. U kunt de quickstart over de opslagplaats voor WildFly op containers gebruiken als uitgangspunt voor uw Dockerfile en webtoepassing.

KeyVault FlexVolume configureren

Maak een Azure KeyVault en vul alle benodigde geheimen in. Zie de quickstart: Een geheim instellen en ophalen uit Azure Key Vault met behulp van Azure CLI voor meer informatie. Configureer vervolgens een KeyVault FlexVolume om deze geheimen toegankelijk te maken voor pods.

U moet ook het opstartscript bijwerken dat wordt gebruikt voor het bootstrappen van WildFly. Met dit script moeten de certificaten worden geïmporteerd in de door WildFly gebruikte sleutelopslag voordat de server wordt gestart.

Gegevensbronnen instellen

Als u WildFly wilt configureren voor toegang tot een gegevensbron, moet u het JDBC-stuurprogramma (JAR-bestand) toevoegen aan uw Docker-installatiekopie en vervolgens de juiste JBoss CLI-opdrachten uitvoeren. Met deze opdrachten wordt de gegevensbron ingesteld bij het bouwen van uw Docker-installatiekopie.

De volgende stappen bevatten instructies voor PostgreSQL, MySQL en SQL Server.

  1. Download het JDBC-stuurprogramma voor PostgreSQL, MySQL of SQL Server.

    Pak het gedownloade archief uit om het JAR-stuurprogrammabestand op te halen.

  2. Maak een bestand met een naam als module.xml en voeg de volgende opmaak toe. Vervang de tijdelijke aanduiding <module name> (inclusief de punthaken) door org.postgres voor PostgreSQL, com.mysql voor MySQL of com.microsoft voor SQL Server. Vervang <JDBC .jar file path> door de naam van het JAR-bestand uit de vorige stap, met inbegrip van het volledige pad naar de locatie waar u het bestand plaatst in uw Docker-installatiekopie, bijvoorbeeld in /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. Maak een bestand met een naam als datasource-commands.cli en voeg de volgende code toe. Vervang <JDBC .jar file path> door de waarde die u in de vorige stap hebt gebruikt. Vervang <module file path> door de bestandsnaam en het pad uit de vorige stap, bijvoorbeeld /opt/database/module.xml.

    Notitie

    Microsoft raadt aan de veiligste verificatiestroom te gebruiken die beschikbaar is. De verificatiestroom die in deze procedure wordt beschreven, zoals voor databases, caches, berichten of AI-services, vereist een zeer hoge mate van vertrouwen in de toepassing en brengt risico's met zich mee die niet aanwezig zijn in andere stromen. Gebruik deze stroom alleen wanneer veiligere opties, zoals beheerde identiteiten voor wachtwoordloze of sleutelloze verbindingen, niet haalbaar zijn. Voor bewerkingen van lokale machines geeft u de voorkeur aan gebruikersidentiteiten voor verbindingen zonder wachtwoord of sleutelloze verbindingen.

    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. Werk de configuratie van de JTA-gegevensbron voor uw toepassing bij:

    Open het bestand src/main/resources/META-INF/persistence.xml voor uw app en zoek het element <jta-data-source>. Vervang de inhoud zoals hier wordt weergegeven:

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

  5. Voeg het volgende toe aan uw Dockerfile zodat de gegevensbron wordt gemaakt bij het bouwen van uw Docker-installatiekopie

    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. Bepaal de DATABASE_CONNECTION_URL die moet worden gebruikt. Deze kan per databaseserver verschillen en anders zijn dan de waarden in de Azure-portal. De hier weergegeven URL-indelingen zijn vereist voor gebruik in combinatie met WildFly:

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

  7. Wanneer u de implementatie-YAML in een later stadium maakt, moet u de omgevingsvariabelen DATABASE_CONNECTION_URL, DATABASE_SERVER_ADMIN_FULL_NAME en DATABASE_SERVER_ADMIN_PASSWORD doorgeven met de juiste waarden.

Notitie

Microsoft raadt aan de veiligste verificatiestroom te gebruiken die beschikbaar is. De verificatiestroom die in deze procedure wordt beschreven, zoals voor databases, caches, berichten of AI-services, vereist een zeer hoge mate van vertrouwen in de toepassing en brengt risico's met zich mee die niet aanwezig zijn in andere stromen. Gebruik deze stroom alleen wanneer veiligere opties, zoals beheerde identiteiten voor wachtwoordloze of sleutelloze verbindingen, niet haalbaar zijn. Voor bewerkingen van lokale machines geeft u de voorkeur aan gebruikersidentiteiten voor verbindingen zonder wachtwoord of sleutelloze verbindingen.

Zie PostgreSQL, MySQL of SQL Server voor meer informatie over het configureren van databaseconnectiviteit met WildFly.

JNDI-resources instellen

Gewoonlijk gebruikt u de volgende stappen voor het instellen van elke JNDI-resource die u moet configureren voor WildFly:

  1. Download de benodigde JAR-bestanden en kopieer deze naar de Docker-installatiekopie.
  2. Maak een WildFly-bestand met de naam module.xml dat verwijst naar die JAR-bestanden.
  3. Maak elke benodigde configuratie voor de betreffende JNDI-resource.
  4. Maak het JBoss CLI-script dat moet worden gebruikt bij het maken van de Dockerfile om de JNDI-resource te registreren.
  5. Voeg alles toe aan de Dockerfile.
  6. Geef de juiste omgevingsvariabelen door in de implementatie-YAML.

In het onderstaande voorbeeld ziet u de benodigde stappen voor het maken van de JNDI-resource voor JMS-connectiviteit met Azure Service Bus.

  1. Download de JMS-provider van Apache Qpid

    Pak het gedownloade archief uit om de JAR-bestanden op te halen.

  2. Maak een bestand met een naam als module.xml en voeg de volgende opmaak toe in /opt/servicebus. Zorg ervoor dat de versienummers van de JAR-bestanden in lijn zijn met de namen van de JAR-bestanden van de vorige stap.

    <?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. Maak een bestand met de naam jndi.properties in /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. Maak een bestand met een naam als servicebus-commands.cli en voeg de volgende code toe.

    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. Voeg het volgende toe aan uw Dockerfile zodat de JNDI-gegevensbron wordt gemaakt bij het bouwen van uw Docker-installatiekopie

    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. Wanneer u de implementatie-YAML in een later stadium maakt, moet u de omgevingsvariabelen MDB_CONNECTION_FACTORY, DEFAULT_SBNAMESPACE, SB_SAS_POLICY, SB_SAS_KEY, MDB_QUEUE, SB_QUEUE, MDB_TOPIC en SB_TOPIC doorgeven met de juiste waarden.

WildFly-configuratie controleren

Raadpleeg de WildFly Admin Guide (Engelstalig) voor aanvullende stappen voorafgaand aan de migratie die niet zijn behandeld in de vorige richtlijnen.

De Docker-installatiekopie compileren en pushen naar Azure Container Registry

Nadat u de Dockerfile hebt gemaakt, moet u de Docker-installatiekopie compileren en deze publiceren naar uw Azure-containerregister.

Als u onze quickstart over de GitHub-opslagplaats voor WildFly op containers hebt gebruikt, is het proces voor het compileren en pushen van uw installatiekopie naar uw Azure-containerregister het equivalent van het aanroepen van de volgende drie opdrachten.

De omgevingsvariabele MY_ACR is in deze voorbeelden de naam van uw Azure containerregister, en de variabele MY_APP_NAME de naam van de webtoepassing die u wilt gebruiken voor uw Azure-containerregister.

Het WAR-bestand maken:

mvn package

Aanmelden bij uw Azure-containerregister:

az acr login --name ${MY_ACR}

De installatiekopie bouwen en pushen:

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

U kunt ook de Docker CLI gebruiken om de installatiekopie lokaal te bouwen en te testen, zoals wordt weergegeven in de volgende opdrachten. Met deze aanpak kunt u het testen en verfijnen van de installatiekopie voorafgaand aan de initiële implementatie in ACR vereenvoudigen. Hiervoor moet u echter de Docker CLI installeren en controleren of de Docker-daemon wordt uitgevoerd.

De installatiekopie bouwen:

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

De installatiekopie lokaal uitvoeren:

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

U hebt nu toegang tot uw toepassing op http://localhost:8080.

Aanmelden bij uw Azure-containerregister:

az acr login --name ${MY_ACR}

De installatiekopie naar uw Azure-containerregister pushen:

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

Zie de leermodule Containerinstallatiekopieën maken en opslaan met Azure Container Registry voor meer gedetailleerde informatie over het maken en opslaan van containerinstallatiekopieën in Azure.

Een openbaar IP-adres inrichten

Als uw toepassing toegankelijk moet zijn buiten uw interne of virtuele netwerk(en), hebt u een openbaar statisch IP-adres nodig. U moet dit IP-adres inrichten in de resourcegroep van het clusterknooppunt inrichten, zoals wordt weergegeven in het volgende voorbeeld:

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

Implementeren in Azure Kubernetes Service (AKS)

Maak uw Kubernetes YAML-bestand(en) en pas dit/deze toe. Zie quickstart: Een AKS-cluster (Azure Kubernetes Service) implementeren met behulp van de Azure CLI voor meer informatie. Als u een externe load balancer maakt (voor uw toepassing of voor een controller voor inkomend verkeer), geeft u het IP-adres op dat u in de vorige sectie hebt ingericht als LoadBalancerIP.

Neem extern gemaakte parameters op als omgevingsvariabelen. Zie Define Environment Variables for a Container (Engelstalig) voor meer informatie. Neem geen geheimen op (zoals wachtwoorden, API-sleutels en JDBC-verbindingsreeksen). Dergelijke zaken komen in de volgende sectie aan bod.

Zorg ervoor dat u geheugen- en CPU-instellingen opneemt in de YAML-implementatie die u maakt, zodat uw containers de juiste grootte krijgen.

Permanente opslag configureren

Als voor uw toepassing niet-vluchtige opslag vereist is, configureert u een of meer permanente volumes.

Geplande taken migreren

Als u geplande taken wilt uitvoeren in uw AKS-cluster, moet u de benodigde Kubernetes Cron-taken definiëren. Zie Running Automated Tasks with a CronJob (Engelstalig) voor meer informatie.

Postmigratie

Nu u de toepassing naar Azure Kubernetes Service hebt gemigreerd, moet u controleren of deze naar behoren werkt. Nadat u dit hebt uitgevoerd, raadpleegt u de volgende aanbevelingen om uw toepassing meer cloudeigen te maken.

Aanbevelingen