WildFly-toepassingen migreren naar WildFly in Azure Kubernetes Service
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.
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.
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 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 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 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 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 elk van uw webtoepassingen onafhankelijk wilt kunnen schalen voor een beter gebruik van uw AKS-resources (Azure Kubernetes Service), 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.
- KeyVault FlexVolume configureren
- Gegevensbronnen instellen
- JNDI-resources instellen
- 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.
Download het JDBC-stuurprogramma voor PostgreSQL, MySQL of SQL Server.
Pak het gedownloade archief uit om het JAR-stuurprogrammabestand op te halen.
Maak een bestand met een naam als
module.xml
en voeg de volgende opmaak toe. Vervang de tijdelijke aanduiding<module name>
(inclusief de punthaken) doororg.postgres
voor PostgreSQL,com.mysql
voor MySQL ofcom.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>
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
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>
Voeg het volgende toe aan uw
Dockerfile
zodat de gegevensbron wordt gemaakt bij het bouwen van uw Docker-installatiekopieRUN /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
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;
Wanneer u de implementatie-YAML in een later stadium maakt, moet u de omgevingsvariabelen
DATABASE_CONNECTION_URL
,DATABASE_SERVER_ADMIN_FULL_NAME
enDATABASE_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:
- Download de benodigde JAR-bestanden en kopieer deze naar de Docker-installatiekopie.
- Maak een WildFly-bestand met de naam module.xml dat verwijst naar die JAR-bestanden.
- Maak elke benodigde configuratie voor de betreffende JNDI-resource.
- Maak het JBoss CLI-script dat moet worden gebruikt bij het maken van de Dockerfile om de JNDI-resource te registreren.
- Voeg alles toe aan de Dockerfile.
- 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.
Download de JMS-provider van Apache Qpid
Pak het gedownloade archief uit om de JAR-bestanden op te halen.
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>
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}
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
Voeg het volgende toe aan uw
Dockerfile
zodat de JNDI-gegevensbron wordt gemaakt bij het bouwen van uw Docker-installatiekopieRUN /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
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
enSB_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. 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
U kunt een DNS-naam toevoegen aan het IP-adres dat is toegewezen aan uw controller voor inkomend verkeer of uw load balancer voor toepassingen. Zie TLS gebruiken met een ingangscontroller in Azure Kubernetes Service (AKS) voor meer informatie.
U kunt Helm-grafieken toevoegen voor uw toepassing. Met een Helm-grafiek kunt u de implementatie van uw toepassing parameteriseren voor gebruik en aanpassing door een gevarieerdere set klanten.
Ontwerp en implementeer een DevOps-strategie. Als u sneller wilt ontwikkelen zonder dat dit ten koste gaat van de betrouwbaarheid, kunt u het beste implementaties en testen automatiseren met Azure Pipelines. Zie Bouwen en implementeren in Azure Kubernetes Service met Azure Pipelines voor meer informatie.
Schakel Azure Monitoring in voor het cluster. Zie Bewaking inschakelen voor Kubernetes-clusters voor meer informatie. Zo kan Azure Monitor containerlogboeken verzamelen, het gebruik bijhouden, enzovoort.
U kunt toepassingsspecifieke metrische gegevens beschikbaar maken via Prometheus. Prometheus is een open source-framework voor metrische gegevens dat veel wordt gebruikt in de Kubernetes-community. U kunt Scraping van metrische gegevens voor Prometheus in Azure Monitor configureren in plaats van uw eigen Prometheus-server te hosten om metrische aggregatie van uw toepassingen en automatische reacties op of escalatie van afwijkende omstandigheden mogelijk te maken. Zie Prometheus en Grafana inschakelen voor meer informatie.
Ontwerp en implementeer een strategie voor bedrijfscontinuïteit en herstel na noodgevallen. Voor bedrijfskritische toepassingen kunt u het beste een implementatiearchitectuur voor meerdere regio's gebruiken. Zie overzicht van hoge beschikbaarheid en herstel na noodgevallen voor AKS (Azure Kubernetes Service) voor meer informatie.
Raadpleeg het Beleid voor ondersteuning van Kubernetes-versies. Het is uw verantwoordelijkheid om uw AKS-cluster bij te werken zodat er altijd een ondersteunde versie wordt uitgevoerd. Zie Upgradeopties voor AKS-clusters (Azure Kubernetes Service) voor meer informatie.
Zorg ervoor dat alle teamleden die verantwoordelijk zijn voor clusterbeheer en toepassingsontwikkeling de relevante best practices voor AKS bekijken. Zie best practices voor clusteroperator en ontwikkelaars voor meer informatie voor het bouwen en beheren van toepassingen in Azure Kubernetes Service (AKS).
Zorg ervoor dat in het implementatiebestand is aangegeven hoe rolling updates worden uitgevoerd. Zie Rolling Update Deployment (Engelstalig) in de documentatie van Kubernetes voor meer informatie.
Stel automatische schaling in om piekbelastingen te kunnen opvangen. Zie Automatische schaalaanpassing van clusters gebruiken in Azure Kubernetes Service (AKS) voor meer informatie.
U kunt de grootte van de codecache bewaken en de JVM-parameters
-XX:InitialCodeCacheSize
en-XX:ReservedCodeCacheSize
toevoegen in de Dockerfile om de prestaties verder te verbeteren. Zie Codecache Tuning (Engelstalig) in de documentatie van Oracle voor meer informatie.