Freigeben über

Migrieren von WildFly-Anwendungen zu WildFly in Azure Kubernetes Service

  • Artikel

In diesem Leitfaden erfahren Sie, was Sie beachten sollten, wenn Sie eine vorhandene WildFly-Anwendung für die Ausführung unter WildFly in einem Azure Kubernetes Service-Container migrieren möchten.

Hinweis

Dieser Artikel enthält nur allgemeine Hinweise. Weder Microsoft noch Red Hat bieten Support für WildFly, aber die WildFly Community kann Ihnen helfen. Informationen zu Angeboten, die von Red Hat und Microsoft gemeinsam unterstützt werden, finden Sie unter Red Hat JBoss EAP auf Azure.

Vor der Migration

Führen Sie vor Beginn einer Migration die in den folgenden Abschnitten beschriebenen Schritte zur Bewertung und Bestandsermittlung aus, um eine erfolgreiche Migration zu gewährleisten.

Inventarisieren der Serverkapazität

Dokumentieren Sie die Hardware (Arbeitsspeicher, CPU, Datenträger) der aktuellen Produktionsserver und die durchschnittliche und maximale Anzahl von Anforderungen und die Ressourcennutzung. Sie benötigen diese Informationen unabhängig vom gewählten Migrationspfad. Dies ist beispielsweise hilfreich beim Auswählen der Größe von VMs in Ihrem Knotenpool, der Speichermenge für den Container und der Anzahl von benötigten CPU-Freigaben für den Container.

Es ist möglich, die Größe von Knotenpools in AKS zu ändern. Weitere Informationen finden Sie unter Ändern der Größe von Knotenpools in Azure Kubernetes Service (AKS).

Bestand: Alle Geheimnisse

Überprüfen Sie alle Eigenschaften und Konfigurationsdateien auf den Produktionsservern auf Geheimnisse und Kennwörter. Überprüfen Sie jboss-web.xml in Ihren WAR-Dateien. Unter Umständen finden Sie in Ihrer Anwendung auch Konfigurationsdateien mit Kennwörtern oder Anmeldeinformationen.

Es empfiehlt sich gegebenenfalls, diese Geheimnisse in Azure Key Vault zu speichern. Weitere Informationen finden Sie unter Grundlegende Konzepte von Azure Key Vault.

Inventarisieren aller Zertifikate

Dokumentieren Sie alle Zertifikate, die für öffentliche SSL-Endpunkte verwendet werden. Sie können alle Zertifikate auf den Produktionsservern anzeigen, indem Sie den folgenden Befehl ausführen:

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

Überprüfen, ob die unterstützte Java-Version richtig funktioniert

Für die Verwendung von WildFly in Azure Kubernetes Service ist eine bestimmte Java-Version erforderlich. Vergewissern Sie sich daher, dass Ihre Anwendung unter Verwendung dieser unterstützten Version ordnungsgemäß ausgeführt wird.

Hinweis

Diese Überprüfung ist besonders wichtig, wenn Ihr aktueller Server auf einem nicht unterstützten JDK (z. B. Oracle JDK oder IBM OpenJ9) ausgeführt wird.

Melden Sie sich an Ihrem Produktionsserver an, und führen Sie den folgenden Befehl aus, um Ihre aktuelle Java-Version zu ermitteln:

java -version

Unter Anforderungen finden Sie Informationen dazu, welche Version für die Ausführung von WildFly erforderlich ist.

Bestand: JNDI-Ressourcen

Inventarisieren Sie alle JNDI-Ressourcen. Für andere Ressourcen, z. B. JMS-Nachrichtenbroker, ist ggf. eine Migration oder Neukonfiguration erforderlich.

Ermitteln, ob die Sitzungsreplikation verwendet wird

Falls Ihre Anwendung die Sitzungsreplikation verwendet, müssen Sie Ihre Anwendung ändern, um diese Abhängigkeit zu entfernen.

Innerhalb Ihrer Anwendung

Untersuchen Sie die Datei WEB-INF/jboss-web.xml und/oder WEB-INF/web.xml.

Dokumentdatenquellen

Verwendet Ihre Anwendung Datenbanken, müssen Sie die folgenden Informationen erfassen:

  • Wie lautet der Name der Datenquelle?
  • Wie ist der Verbindungspool konfiguriert?
  • Wo ist die JAR-Datei mit den JDBC-Treibern zu finden?

Weitere Informationen finden Sie in der WildFly-Dokumentation unter DataSource-Konfiguration.

Ermitteln, ob und wie das Dateisystem verwendet wird

Für jegliche Nutzung des Dateisystems auf dem Anwendungsserver sind erneute Konfigurationen oder in selteneren Fällen auch Architekturänderungen erforderlich. Das Dateisystem kann von WildFly-Modulen oder von Ihrem Anwendungscode genutzt werden. Unter Umständen kann es zu den Szenarien kommen, die in den folgenden Abschnitten beschrieben sind.

Schreibgeschützter statischer Inhalt

Falls mit Ihrer Anwendung derzeit statischer Inhalt bereitgestellt wird, benötigen Sie dafür einen anderen Speicherort. Sie können beispielsweise erwägen, statischen Inhalt in Azure Blob Storage zu verschieben und Azure CDN hinzuzufügen, um global eine sehr hohe Downloadgeschwindigkeit zu erzielen. Weitere Informationen finden Sie unter Hosten von statischen Websites in Azure Storage und Schnellstart: Integrieren eines Azure-Speicherkontos in Azure CDN.

Dynamisch veröffentlichter statischer Inhalt

Wenn Ihre Anwendung statischen Inhalt zulässt, der von Ihrer Anwendung hochgeladen bzw. produziert wird, nach der Erstellung aber unveränderlich ist, können Sie Azure Blob Storage und Azure CDN wie oben beschrieben nutzen. Hierbei können Sie auch eine Azure-Funktion zum Verarbeiten von Uploads und der CDN-Aktualisierung verwenden. Eine entsprechende Beispielimplementierung finden Sie unter Hochladen und CDN-Vorabladen von statischem Inhalt mit Azure Functions.

Dynamischer oder interner Inhalt

Für Dateien, für die von Ihrer Anwendung häufige Schreib- und Lesevorgänge durchgeführt werden (z. B. temporäre Datendateien), oder für statische Dateien, die nur für Ihre Anwendung sichtbar sind, können Sie Azure Storage-Freigaben als persistente Volumes bereitstellen. Weitere Informationen finden Sie unter Erstellen und Verwenden eines Volumes mit Azure Files in Azure Kubernetes Service (AKS).

Ermitteln, ob für Ihre Anwendung geplante Aufträge benötigt werden

Geplante Dienste, wie z. B. Quartz Scheduler Dienste oder Unix Cron Jobs, sollten NICHT mit Azure Kubernetes Service (AKS) verwendet werden. Azure Kubernetes Service hindert Sie nicht an der Bereitstellung einer Anwendung, die intern geplante Aufgaben enthält. Wenn Ihre Anwendung aber horizontal hochskaliert wird, wird derselbe geplante Auftrag unter Umständen mehrmals pro geplantem Zeitraum ausgeführt. Diese Situation kann unerwünschte Konsequenzen haben.

Definieren Sie zum Ausführen von geplanten Aufträgen in Ihrem AKS-Cluster je nach Bedarf Kubernetes-Cron-Aufträge. Weitere Informationen finden Sie unter Ausführen von automatisierten Aufgaben per Cron-Auftrag.

Ermitteln, ob eine Verbindung mit der lokalen Umgebung erforderlich ist

Wenn Ihre Anwendung auf Ihre lokalen Dienste zugreifen muss, müssen Sie einen der Konnektivitätsdienste von Azure bereitstellen. Weitere Informationen finden Sie unter Herstellen einer Verbindung zwischen einem lokalen Netzwerk und Azure. Alternativ müssen Sie Ihre Anwendung so umgestalten, dass öffentlich zugängliche APIs genutzt werden, die von Ihren lokalen Ressourcen verfügbar gemacht werden.

Ermitteln, ob JMS-Warteschlangen oder -Themen (Java Message Service) verwendet werden

Wenn Ihre Anwendung JMS-Warteschlangen oder -Themen nutzt, müssen diese zu einem extern gehosteten JMS-Server migriert werden. Azure Service Bus und das Advanced Message Queuing Protocol (AMQP) können bei Verwendung von JMS eine hervorragende Migrationsstrategie sein. Weitere Informationen finden Sie unter Verwenden von Java Message Service 1.1 mit Azure Service Bus Standard und AMQP 1.0.

Wenn beständige JMS-Speicher konfiguriert wurden, müssen Sie die zugehörige Konfiguration erfassen und nach dem Migrationsvorgang anwenden.

Ermitteln, ob für Ihre Anwendung Entity Beans oder CMP Beans im EJB 2.x-Format verwendet werden

Wenn für Ihre Anwendung Entity Beans oder CMP Beans im EJB 2.x-Format verwendet werden, müssen Sie Ihre Anwendung umgestalten, um diese Abhängigkeiten zu entfernen.

Ermitteln, ob die Java EE-Anwendungsclientfunktion verwendet wird

Falls Sie über Clientanwendungen verfügen, die mit der Java EE-Anwendungsclientfunktion eine Verbindung mit Ihrer (Server-)Anwendung herstellen, müssen Sie sowohl Ihre Clientanwendungen als auch Ihre (Server-)Anwendung so umgestalten, dass HTTP-APIs verwendet werden.

Ermitteln, ob Ihre Anwendung betriebssystemspezifischen Code enthält

Wenn Ihre Anwendung Code mit Abhängigkeiten vom Hostbetriebssystem enthält, müssen Sie ihn umgestalten, um diese Abhängigkeiten zu beseitigen. Beispielsweise müssen Sie möglicherweise die Verwendung von / oder \ in Dateisystempfaden durch File.Separator oder Paths.get ersetzen, wenn Ihre Anwendung unter Windows ausgeführt wird.

Ermitteln, ob EJB-Zeitgeber verwendet werden

Wenn für Ihre Anwendung EJB-Zeitgeber genutzt werden, müssen Sie überprüfen, ob der EJB-Zeitgebercode von jeder WildFly-Instanz separat ausgelöst werden kann. Diese Überprüfung ist erforderlich, weil bei der Azure Kubernetes Service-Bereitstellung jeder EJB-Zeitgeber auf einer eigenen WildFly-Instanz ausgelöst wird.

Ermitteln, ob JCA-Connectors genutzt werden

Wenn für Ihre Anwendung JCA-Connectors genutzt werden, müssen Sie überprüfen, ob der JCA-Connector unter WildFly verwendet werden kann. Wenn die JCA-Implementierung mit WildFly verknüpft ist, müssen Sie Ihre Anwendung umgestalten, um diese Abhängigkeit zu beseitigen. Falls die Verwendung möglich ist, müssen Sie die JARs dem Serverklassenpfad hinzufügen und die erforderlichen Konfigurationsdateien in den WildFly-Serververzeichnissen ablegen, um die Verfügbarkeit sicherzustellen.

Ermitteln, ob JAAS verwendet wird

Wenn für Ihre Anwendung JAAS verwendet wird, müssen Sie erfassen, wie JAAS konfiguriert wird. Sofern hierfür eine Datenbank verwendet wird, können Sie sie in eine JAAS-Domäne auf WildFly konvertieren. Falls es sich um eine benutzerdefinierte Implementierung handelt, müssen Sie überprüfen, ob sie in WildFly verwendet werden kann.

Ermitteln, ob Ihre Anwendung einen Ressourcenadapter verwendet

Wenn für Ihre Anwendung ein Ressourcenadapter (RA) benötigt wird, muss dieser mit WildFly kompatibel sein. Ermitteln Sie, ob der RA für eine eigenständige Instanz von WildFly richtig funktioniert, indem Sie ihn auf dem Server bereitstellen und entsprechend konfigurieren. Falls der RA richtig funktioniert, müssen Sie die JARs dem Serverklassenpfad des Docker-Images hinzufügen und die erforderlichen Konfigurationsdateien in den WildFly-Serververzeichnissen ablegen, um die Verfügbarkeit sicherzustellen.

Ermitteln, ob Ihre Anwendung aus mehreren WAR-Dateien besteht

Besteht Ihre Anwendung aus mehreren WAR-Dateien, sollten Sie die einzelnen WAR-Dateien als separate Anwendungen behandeln und für jede Datei diese Anleitung ausführen.

Ermitteln, ob Ihre Anwendung als EAR-Datei gepackt ist

Ist Ihre Anwendung als EAR-Datei gepackt, untersuchen Sie die Datei application.xml, und erfassen Sie die Konfiguration.

Hinweis

Wenn Sie in der Lage sein möchten, jede Ihrer Webanwendungen unabhängig zu skalieren, um Ihre Azure Kubernetes Service -Ressourcen (AKS) besser zu nutzen, sollten Sie das EAR in separate Webanwendungen aufteilen.

Ermitteln aller externen Prozesse und Daemons, die auf den Produktionsservern ausgeführt werden

Werden einige Ihrer Prozesse außerhalb des Anwendungsservers ausgeführt (z. B. die Überwachung von Daemons), müssen Sie sie beseitigen oder zu einem anderen Ort migrieren.

Durchführen von direkten Tests

Migrieren Sie Ihre Anwendung vor dem Erstellen von Containerimages zu den Versionen des JDK und von WildFly, die Sie für AKS nutzen möchten. Führen Sie für die Anwendung gründliche Tests durch, um die Kompatibilität und Leistung sicherzustellen.

Migration

Bereitstellen von Azure Container Registry und Azure Kubernetes Service

Verwenden Sie die folgenden Befehle zum Erstellen einer Containerregistrierung und eines Azure Kubernetes-Clusters mit einem Dienstprinzipal, der für die Registrierung über die Rolle „Leser“ verfügt. Achten Sie darauf, dass Sie für die Netzwerkanforderungen Ihres Clusters das richtige Netzwerkmodell auswählen.

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

Erstellen eines Docker-Images für WildFly

Zum Erstellen eines Dockerfile benötigen Sie Folgendes:

  • Ein unterstütztes JDK.
  • Eine Installation von WildFly
  • Ihre JVM-Runtimeoptionen.
  • Eine Möglichkeit zum Übergeben von Umgebungsvariablen (falls zutreffend).

Sie können bei Bedarf dann die in den folgenden Abschnitten beschriebenen Schritte ausführen. Sie können das Schnellstartrepository für WildFly-Container als Ausgangspunkt für Ihr Dockerfile und die Webanwendung verwenden.

Konfigurieren von KeyVault FlexVolume

Erstellen Sie eine Azure Key Vault-Instanz, und fügen Sie alle erforderlichen Geheimnisse ein. Weitere Informationen finden Sie unter Schnellstart: Festlegen und Abrufen eines Geheimnisses aus Azure Key Vault mithilfe der Azure CLI. Konfigurieren Sie anschließend eine KeyVault FlexVolume-Instanz, um diese Geheimnisse für Pods zugänglich zu machen.

Außerdem müssen Sie das Startskript aktualisieren, das für das WildFly-Bootstrapping verwendet wird. Mit diesem Skript müssen die Zertifikate in den von WildFly genutzten Keystore importiert werden, bevor der Server gestartet wird.

Einrichten von Datenquellen

Zum Konfigurieren von WildFly für den Zugriff auf eine Datenquelle müssen Sie die JDBC-JAR-Treiberdatei Ihrem Docker-Image hinzufügen und anschließend die entsprechenden JBoss CLI-Befehle ausführen. Mit diesen Befehlen muss beim Erstellen des Docker-Images die Datenquelle eingerichtet werden.

Die folgenden Schritte enthalten eine Anleitung für PostgreSQL, MySQL und SQL Server.

  1. Laden Sie den JDBC-Treiber für PostgreSQL, MySQL oder SQL Server herunter.

    Entpacken Sie das heruntergeladene Archiv, um die JAR-Treiberdatei zu erhalten.

  2. Erstellen Sie eine Datei mit einem Namen wie module.xml, und fügen Sie das folgende Markup hinzu. Ersetzen Sie den Platzhalter <module name> (einschließlich der spitzen Klammern) mit org.postgres für PostgreSQL, com.mysql für MySQL oder com.microsoft für SQL Server. Ersetzen Sie <JDBC .jar file path> durch den Namen der JAR-Datei aus dem vorherigen Schritt. Hierzu gehört auch der vollständige Pfad des Speicherorts, an dem Sie die Datei in Ihrem Docker-Image anordnen möchten, z. B. /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. Erstellen Sie eine Datei mit einem Namen wie datasource-commands.cli, und fügen Sie den unten angegebenen Code hinzu. Ersetzen Sie <JDBC .jar file path> durch den Wert, den Sie im vorherigen Schritt verwendet haben. Ersetzen Sie <module file path> durch den Dateinamen und Pfad aus dem vorherigen Schritt, z. B. /opt/database/module.xml.

    Hinweis

    Microsoft empfiehlt, immer den sichersten Authentifizierungsflow zu verwenden, der verfügbar ist. Der in diesem Verfahren beschriebene Authentifizierungsfluss, z. B. für Datenbanken, Caches, Nachrichten oder KI-Dienste, erfordert ein sehr hohes Vertrauen in die Anwendung und trägt Risiken, die in anderen Flüssen nicht vorhanden sind. Verwenden Sie diesen Fluss nur, wenn sicherere Optionen wie verwaltete Identitäten für kennwortlose oder schlüssellose Verbindungen nicht geeignet sind. Bei Vorgängen des lokalen Computers bevorzugen Sie Benutzeridentitäten für kennwortlose oder schlüssellose Verbindungen.

    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. Aktualisieren Sie die JTA-Datenquellenkonfiguration für Ihre Anwendung:

    Öffnen Sie die Datei src/main/resources/META-INF/persistence.xml für Ihre App, und suchen Sie nach dem Element <jta-data-source>. Ersetzen Sie seinen Inhalt wie folgt:

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

  5. Fügen Sie Ihrem Dockerfile Folgendes hinzu, damit die Datenquelle während des Buildvorgangs für Ihr Docker-Image erstellt wird.

    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. Ermitteln Sie die zu verwendende DATABASE_CONNECTION_URL. Sie unterscheidet sich für jeden Datenbankserver und auch von den Werten im Azure-Portal. Die hier angezeigten URL-Formate sind für die Verwendung durch WildFly erforderlich:

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

  7. Beim späteren Erstellen Ihrer YAML-Bereitstellungsdatei müssen Sie die Umgebungsvariablen DATABASE_CONNECTION_URL, DATABASE_SERVER_ADMIN_FULL_NAME und DATABASE_SERVER_ADMIN_PASSWORD durch die entsprechenden Werte ersetzen.

Hinweis

Microsoft empfiehlt, immer den sichersten Authentifizierungsflow zu verwenden, der verfügbar ist. Der in diesem Verfahren beschriebene Authentifizierungsfluss, z. B. für Datenbanken, Caches, Nachrichten oder KI-Dienste, erfordert ein sehr hohes Vertrauen in die Anwendung und trägt Risiken, die in anderen Flüssen nicht vorhanden sind. Verwenden Sie diesen Fluss nur, wenn sicherere Optionen wie verwaltete Identitäten für kennwortlose oder schlüssellose Verbindungen nicht geeignet sind. Bei Vorgängen des lokalen Computers bevorzugen Sie Benutzeridentitäten für kennwortlose oder schlüssellose Verbindungen.

Weitere Informationen über die Konfigurierung der Datenbankverbindungen mit WildFly finden Sie unter PostgreSQL, MySQL oder SQL Server.

Einrichten von JNDI-Ressourcen

Normalerweise führen Sie die folgenden Schritte aus, um die einzelnen JNDI-Ressourcen einzurichten, die Sie für WildFly konfigurieren müssen:

  1. Laden Sie die erforderlichen JAR-Dateien herunter, und kopieren Sie sie in das Docker-Image.
  2. Erstellen Sie die WildFly-Datei module.xml, und verweisen Sie darin auf diese JAR-Dateien.
  3. Erstellen Sie eine beliebige Konfiguration, die von der jeweiligen JNDI-Ressource benötigt wird.
  4. Erstellen Sie ein JBoss CLI-Skript, das während des Docker-Buildvorgangs zum Registrieren der JNDI-Ressource verwendet werden soll.
  5. Fügen Sie all diese Elemente dem Dockerfile hinzu.
  6. Übergeben Sie die entsprechenden Umgebungsvariablen in Ihrer YAML-Bereitstellungsdatei.

Das Beispiel unten enthält die Schritte, die zum Erstellen der JNDI-Ressource für die JMS-Konnektivität mit Azure Service Bus ausgeführt werden müssen.

  1. Laden Sie den Apache Qpid JMS-Anbieter herunter.

    Entpacken Sie das heruntergeladene Archiv, um die JAR-Dateien zu erhalten.

  2. Erstellen Sie eine Datei mit einem Namen wie module.xml, und fügen Sie das folgende Markup in /opt/servicebus hinzu. Stellen Sie sicher, dass die Versionsnummern der JAR-Dateien mit den Namen der JAR-Dateien aus dem vorherigen Schritt übereinstimmen.

    <?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. Erstellen Sie in /opt/servicebus die Datei jndi.properties.

    connectionfactory.${MDB_CONNECTION_FACTORY}=amqps://${DEFAULT_SBNAMESPACE}.servicebus.windows.net?amqp.idleTimeout=120000&jms.username=${SB_SAS_POLICY}&jms.password=${SB_SAS_KEY}
queue.${MDB_QUEUE}=${SB_QUEUE}
topic.${MDB_TOPIC}=${SB_TOPIC}

  4. Erstellen Sie eine Datei mit einem Namen wie servicebus-commands.cli, und fügen Sie den unten angegebenen Code hinzu.

    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. Fügen Sie Ihrem Dockerfile Folgendes hinzu, damit die JNDI-Ressource während des Buildvorgangs für Ihr Docker-Image erstellt wird.

    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. Beim späteren Erstellen Ihrer YAML-Bereitstellungsdatei müssen Sie die Umgebungsvariablen MDB_CONNECTION_FACTORY, DEFAULT_SBNAMESPACE und SB_SAS_POLICY, SB_SAS_KEY, MDB_QUEUE, SB_QUEUE, MDB_TOPIC und SB_TOPIC durch die entsprechenden Werte ersetzen.

Überprüfen der WildFly-Konfiguration

Lesen Sie das WildFly-Administratorhandbuch, um sich über alle weiteren Schritte zu informieren, die vor der Migration ausgeführt werden müssen und in diesem Leitfaden nicht beschrieben sind.

Erstellen und Pushen des Docker-Images für Azure Container Registry

Nachdem Sie das Dockerfile erstellt haben, müssen Sie das Docker-Image erstellen und in Ihrer Azure Container Registry-Instanz veröffentlichen.

Wenn Sie unser GitHub-Schnellstartrepository für WildFly-Container verwendet haben, entspricht der Prozess zum Erstellen und Pushen Ihres Images für Ihre Azure Container Registry-Instanz dem Aufrufen der folgenden drei Befehle.

In diesen Beispielen enthält die Umgebungsvariable MY_ACR den Namen Ihrer Azure Container Registry-Instanz und die Variable MY_APP_NAME den Namen der Webanwendung, die Sie in Ihrer Azure Container Registry-Instanz verwenden möchten.

Erstellen der WAR-Datei:

mvn package

Anmelden bei Ihrer Azure Container Registry-Instanz:

az acr login --name ${MY_ACR}

Erstellen und Pushen des Images:

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

Alternativ können Sie die Docker CLI verwenden, um das Image zuerst lokal zu erstellen und zu testen. Dies ist in den folgenden Befehlen veranschaulicht. Dieser Ansatz kann das Testen und Optimieren des Images vor der ersten Bereitstellung unter ACR vereinfachen. Hierfür ist es aber erforderlich, die Docker CLI zu installieren und sicherzustellen, dass der Docker-Daemon ausgeführt wird.

Erstellen des Images:

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

Lokales Ausführen des Images:

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

Sie können jetzt unter http://localhost:8080 auf Ihre Anwendung zugreifen.

Anmelden bei Ihrer Azure Container Registry-Instanz:

az acr login --name ${MY_ACR}

Pushen des Images an Ihre Azure Container Registry-Instanz:

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

Ausführlichere Informationen zum Erstellen und Speichern von Containerimages in Azure finden Sie im Lernmodul Erstellen und Speichern von Containerimages mit Azure Container Registry.

Bereitstellen einer öffentlichen IP-Adresse

Wenn für Ihre Anwendung der Zugriff von außerhalb Ihrer internen oder virtuellen Netzwerke möglich sein soll, benötigen Sie eine öffentliche statische IP-Adresse. Sie sollten diese IP-Adresse in der Knotenressourcengruppe Ihres Clusters bereitstellen. Dies wird im folgenden Beispiel veranschaulicht:

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

Bereitstellen für Azure Kubernetes Service (AKS)

Es wird beschrieben, wie Sie Ihre Kubernetes-YAML-Datei(en) erstellen und anwenden. Weitere Informationen finden Sie in der Schnellstartanleitung: Bereitstellen eines Azure Kubernetes Service (AKS)-Clusters mithilfe der Azure CLI. Wenn Sie einen externen Lastenausgleich erstellen (ob für Ihre Anwendung oder einen Eingangscontroller), sollten Sie darauf achten, dass Sie die IP-Adresse aus dem vorherigen Abschnitt als LoadBalancerIP angeben.

Binden Sie externalisierte Parameter als Umgebungsvariablen ein. Weitere Informationen finden Sie unter Definieren von Umgebungsvariablen für einen Container. Vermeiden Sie die Einbindung von Geheimnissen (z. B. Kennwörter, API-Schlüssel und JDBC-Verbindungszeichenfolgen). Diese werden im folgenden Abschnitt beschrieben.

Beachten Sie beim Erstellen Ihrer YAML-Bereitstellungsdatei die Einstellungen für Arbeitsspeicher und CPU, damit Ihre Container die richtige Größe haben.

Konfigurieren von persistentem Speicher

Konfigurieren Sie ein oder mehrere persistente Volumes, wenn für Ihre Anwendung nicht flüchtiger Speicher benötigt wird.

Migrieren von geplanten Aufträgen

Definieren Sie zum Ausführen von geplanten Aufträgen in Ihrem AKS-Cluster je nach Bedarf Kubernetes-Cron-Aufträge. Weitere Informationen finden Sie unter Ausführen von automatisierten Aufgaben per Cron-Auftrag.

Nach der Migration

Nachdem Sie Ihre Anwendung zu Azure Kubernetes Service migriert haben, sollten Sie sich vergewissern, dass sie wie erwartet funktioniert. Anschließend können Sie sich dann über unsere Empfehlungen informieren, mit denen Sie Ihre Anwendung cloudnativer gestalten können.

Empfehlungen