WildFly-toepassingen migreren naar WildFly in Azure Kubernetes Service

  • Artikel

In deze handleiding wordt beschreven waarmee u rekening moet houden wanneer u een bestaande WildFly-toepassing wilt uitvoeren op WildFly in een Azure Kubernetes Service-container.

Notitie

In dit artikel wordt alleen algemeen advies verstrekt. Microsoft noch Red Hat biedt ondersteuning voor WildFly, maar de WildFly-community kan hulp bieden. Zie Red Hat JBoss EAP in Azure voor meer informatie over aanbiedingen die gezamenlijk worden ondersteund door Red Hat en Microsoft.

Premigratie

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

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

Controleer alle eigenschaps- en configuratiebestanden op de productieserver(s) op geheimen en wachtwoorden. Controleer in elk geval jboss-web.xml in uw WAR's. Mogelijk bevinden zich ook in uw toepassing configuratiebestanden met wachtwoorden of referenties.

Overweeg deze geheimen op te slaan in Azure KeyVault. 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>

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.

JNDI-resources inventariseren

Inventariseer alle JNDI-resources. Een aantal JMS-berichtenbrokers moeten mogelijk worden gemigreerd of opnieuw worden geconfigureerd.

Bepalen of sessiereplicatie wordt gebruikt

Als uw toepassing afhankelijk is van sessiereplicatie, moet u uw toepassing zo aanpassen dat deze afhankelijkheid niet meer bestaat.

Binnen uw toepassing

Inspecteer het bestand WEB-INF/jboss-web.xml en/of WEB-INF/web.xml.

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?

Raadpleeg DataSource-configuratie in de WildFly-documentatie voor meer informatie.

Nagaan of en hoe het bestandssysteem wordt gebruikt

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

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. U kunt de statische inhoud ook rechtstreeks implementeren in een app in het Azure Spring Apps Enterprise-abonnement. Zie Statische webbestanden implementeren 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. U kunt de statische inhoud ook rechtstreeks implementeren in een app in het Azure Spring Apps Enterprise-abonnement. Zie Statische webbestanden implementeren voor meer informatie.

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 Permanent volume dynamisch maken en gebruiken met Azure Files in Azure Kubernetes Service voor meer informatie.

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 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 Een oplossing kiezen voor het verbinden van een on-premises netwerk 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. Raadpleeg JMS gebruiken met Azure Service Bus 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 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.

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

Als uw toepassing code bevat met afhankelijkheden van het hostbesturingssysteem, moet u de toepassing herstructureren om die afhankelijkheden te verwijderen. Zo moet u mogelijk de / of \ vervangen in bestandssysteempaden met File.Separator of Paths.get.

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 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 WildFly, 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 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 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 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 het bestand application.xml controleren en de configuratie vastleggen.

Notitie

Als u al uw webtoepassingen onafhankelijk van elkaar wilt kunnen schalen voor een beter gebruik van uw AKS-resources, moet u de 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.

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.

  1. KeyVault FlexVolume configureren
  2. Gegevensbronnen instellen
  3. JNDI-resources instellen
  4. WildFly-configuratie controleren

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.

    PostgreSQL

    batch
module add --name=org.postgres --resources=<JDBC .jar file path> --module-xml=<module file path>
/subsystem=datasources/jdbc-driver=postgres:add(driver-name=postgres,driver-module-name=org.postgres,driver-class-name=org.postgresql.Driver,driver-xa-datasource-class-name=org.postgresql.xa.PGXADataSource)
data-source add --name=postgresDS --driver-name=postgres --jndi-name=java:jboss/datasources/postgresDS --connection-url=$DATABASE_CONNECTION_URL --user-name=$DATABASE_SERVER_ADMIN_FULL_NAME --password=$DATABASE_SERVER_ADMIN_PASSWORD --use-ccm=true --max-pool-size=5 --blocking-timeout-wait-millis=5000 --enabled=true --driver-class=org.postgresql.Driver --exception-sorter-class-name=org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLExceptionSorter --jta=true --use-java-context=true --valid-connection-checker-class-name=org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker
reload
run batch
shutdown

    MySQL

    batch
module add --name=com.mysql --resources=<JDBC .jar file path> --module-xml=<module file path>
/subsystem=datasources/jdbc-driver=mysql:add(driver-name=mysql,driver-module-name=com.mysql,driver-class-name=com.mysql.cj.jdbc.Driver)
data-source add --name=mysqlDS --jndi-name=java:jboss/datasources/mysqlDS --connection-url=$DATABASE_CONNECTION_URL --driver-name=mysql --user-name=$DATABASE_SERVER_ADMIN_FULL_NAME --password=$DATABASE_SERVER_ADMIN_PASSWORD --use-ccm=true --max-pool-size=5 --blocking-timeout-wait-millis=5000 --enabled=true --driver-class=com.mysql.cj.jdbc.Driver --jta=true --use-java-context=true --exception-sorter-class-name=com.mysql.cj.jdbc.integration.jboss.ExtendedMysqlExceptionSorter
reload
run batch
shutdown

    SQL Server

    batch
module add --name=com.microsoft --resources=<JDBC .jar file path> --module-xml=<module file path>
/subsystem=datasources/jdbc-driver=sqlserver:add(driver-name=sqlserver,driver-module-name=com.microsoft,driver-class-name=com.microsoft.sqlserver.jdbc.SQLServerDriver,driver-datasource-class-name=com.microsoft.sqlserver.jdbc.SQLServerDataSource)
data-source add --name=sqlDS --jndi-name=java:jboss/datasources/sqlDS --driver-name=sqlserver --connection-url=$DATABASE_CONNECTION_URL --validate-on-match=true --background-validation=false --valid-connection-checker-class-name=org.jboss.jca.adapters.jdbc.extensions.mssql.MSSQLValidConnectionChecker --exception-sorter-class-name=org.jboss.jca.adapters.jdbc.extensions.mssql.MSSQLExceptionSorter
reload
run batch
shutdown

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

    PostgreSQL

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

    MySQL

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

    SQL Server

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

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

    PostgreSQL

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

    MySQL

    jdbc:mysql://<database server name>:3306/<database name>?ssl=true\&useLegacyDatetimeCode=false\&serverTimezone=GMT

    SQL Server

    jdbc:sqlserver://<database server name>:1433;database=<database name>;user=<admin name>;password=<admin password>;encrypt=true;trustServerCertificate=false;hostNameInCertificate=*.database.windows.net;loginTimeout=30;

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

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 naar AKS

Maak uw Kubernetes YAML-bestand(en) en pas dit/deze toe. Zie de quickstart: Een Azure Kubernetes Service-cluster 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. Wanneer u dat gedaan hebt, hebben we enkele aanbevelingen voor u aan de hand waarvan u de toepassing geschikter kunt maken voor de cloud.

Aanbevelingen