Freigeben über

Migrieren von WebLogic-Anwendungen zu WildFly in Azure Kubernetes Service

  • Artikel

Diese Anleitung beschreibt, was Sie beachten sollten, wenn Sie eine vorhandene WebLogic Server-Anwendung auf WildFly in einem Azure Kubernetes Service Container ausführen möchten.

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.

Wenn Sie die Anforderungen vor der Migration nicht erfüllen können, lesen Sie die dazugehörige Anleitung zur Migration:

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

Vor der Einführung von „Configuration-as-a-Service“-Technologien, z. B. Azure Key Vault, gab es kein gut definiertes Konzept für „Geheimnisse“. Stattdessen haben Sie über viele unterschiedliche Konfigurationseinstellungen verfügt, die quasi als die nun verwendeten „Geheimnisse“ gedient haben. Bei App-Servern, z. B. WebLogic Server, sind diese Geheimnisse in vielen unterschiedlichen Konfigurationsdateien und -speichern enthalten. Überprüfen Sie alle Eigenschaften und Konfigurationsdateien auf den Produktionsservern auf Geheimnisse und Kennwörter. Sehen Sie in der Datei weblogic.xml in Ihren WARs nach. Unter Umständen finden Sie in Ihrer Anwendung auch Konfigurationsdateien mit Kennwörtern oder Anmeldeinformationen. 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>

Bestand: JNDI-Ressourcen

Inventarisieren Sie alle JNDI-Ressourcen. Datenquellen, z. B. Datenbanken, können beispielsweise über einen zugeordneten JNDI-Namen verfügen, mit dem Instanzen von EntityManager von JPA korrekt an eine bestimmte Datenbank gebunden werden können. Weitere Informationen zu JNDI-Ressourcen und -Datenbanken finden Sie in der Oracle-Dokumentation unter WebLogic Server-Datenquellen. Für andere JNDI-bezogene Ressourcen, z. B. JMS-Nachrichtenbroker, ist ggf. eine Migration oder Neukonfiguration erforderlich. Weitere Informationen zur JMS-Konfiguration finden Sie unter Oracle WebLogic Server 12.2.1.4.0.

Ermitteln, ob die Sitzungsreplikation verwendet wird

Wenn für Ihre Anwendung die Sitzungsreplikation benötigt wird, haben Sie zwei Optionen (mit oder ohne Oracle Coherence*Web):

  • Gestalten Sie Ihre Anwendung so um, dass eine Datenbank für die Sitzungsverwaltung verwendet wird.
  • Gestalten Sie Ihre Anwendung so um, dass die Sitzung für den Azure Redis-Dienst externalisiert wird. Weitere Informationen finden Sie unter Azure Cache for Redis.

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 zu JDBC-Treibern in WebLogic finden Sie unter Verwenden von JDBC-Treibern mit einem WebLogic-Server.

Ermitteln, ob WebLogic angepasst wurde

Ermitteln Sie, welche der folgenden Anpassungen vorgenommen wurden, und erfassen Sie sie.

  • Wurden die Startskripts geändert? Zu diesen Skripts gehören setDomainEnv, commEnv, startWebLogic und stopWebLogic.
  • Werden an JVM spezifische Parameter übergeben?
  • Werden dem Klassenpfad des Servers JAR-Dateien hinzugefügt?

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 Sie, ob Sie eigene benutzerdefinierte freigegebene Java EE-Bibliotheken verwenden

Wenn Sie das Features für freigegebene Java EE-Bibliotheken verwenden, haben Sie zwei Optionen:

  • Gestalten Sie Ihren Anwendungscode um, um alle Abhängigkeiten von Ihren Bibliotheken zu entfernen, und integrieren Sie die Funktionalität stattdessen direkt in Ihre Anwendung.
  • Fügen Sie die Bibliotheken zum Serverklassenpfad hinzu.

Ermitteln, ob OSGi-Pakete verwendet werden

Wenn Sie dem WebLogic-Server hinzugefügte OSGi-Pakete verwendet haben, müssen Sie die entsprechenden JAR-Dateien direkt Ihrer Webanwendung hinzufügen.

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 Oracle Service Bus verwendet wird

Wenn Ihre Anwendung Oracle Service Bus (OSB) verwendet, müssen Sie erfassen, wie OSB konfiguriert ist. Weitere Informationen finden Sie unter Informationen zur Installation von Oracle Service Bus.

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, sehen Sie sich unbedingt die Dateien application.xml und weblogic-application.xml an, und erfassen Sie deren Konfigurationen.

Hinweis

Wenn Sie in der Lage sein möchten, jede Ihrer Webanwendungen unabhängig zu skalieren, um die Ressourcen des Azure Kubernetes Service besser zu nutzen, sollten Sie die 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.

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

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.

Bestimmen Sie, ob das WebLogic Scripting Tool verwendet wird

Wenn Sie derzeit das WebLogic Scripting Tool (WLST) für die Bereitstellung verwenden, müssen Sie bewerten, was es tut. Wenn WLST im Rahmen der Bereitstellung irgendwelche (Laufzeit-)Parameter Ihrer Anwendung ändert, stellen Sie sicher, dass diese Parameter einer der folgenden Optionen entsprechen:

  • Die Parameter werden als App-Einstellungen externalisiert.
  • Die Parameter sind in Ihre Anwendung eingebettet.
  • Die Parameter werden während der Bereitstellung mit dem JBoss CLI verwendet.

Wenn WLST mehr als die oben genannten Parameter verwendet, müssen Sie während der Migration zusätzliche Arbeit leisten.

Ermitteln, ob für Ihre Anwendung WebLogic-spezifische APIs verwendet werden

Wenn für Ihre Anwendung WebLogic-spezifische APIs verwendet werden, müssen Sie sie umgestalten, um diese Abhängigkeiten zu beseitigen. Wenn Sie beispielsweise eine Klasse verwendet haben, die in der Java-API-Referenz für Oracle WebLogic Server erwähnt wird, haben Sie in Ihrer Anwendung eine WebLogic-spezifische API genutzt. Sie müssten ein Refactoring durchführen, um den Verweis zu entfernen.

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 ein Bereitstellungsplan verwendet wurde

Wenn Ihre App mithilfe eines Bereitstellungsplans bereitgestellt wurde, bewerten Sie, was der Plan für die Bereitstellung tut. Wenn es im Bereitstellungsplan um eine direkte Bereitstellung geht, können Sie Ihre Webanwendung ohne weitere Änderungen bereitstellen. Wenn der Plan für die Bereitstellung aufwändiger ist, stellen Sie fest, ob Sie die JBoss CLI verwenden können, um Ihre Anwendung als Element der Bereitstellung ordnungsgemäß zu konfigurieren. Wenn es nicht möglich ist, das JBoss CLI zu verwenden, refactoring Sie Ihre Anwendung so, dass ein Plan zur Bereitstellung nicht mehr benötigt 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 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 wird möglicherweise von gemeinsam genutzten WebLogic-Modulen oder von Ihrem Code verwendet. Sie könnten einige oder alle der in den folgenden Abschnitten beschriebenen Szenarien identifizieren.

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 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 an WebLogic gebunden ist, müssen Sie Ihre Anwendung so umgestalten, dass diese Abhängigkeit beseitigt wird. 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 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 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 das WebLogic-Clustering genutzt wird

Höchstwahrscheinlich haben Sie Ihre Anwendung auf mehreren WebLogic-Servern bereitgestellt, um Hochverfügbarkeit zu erzielen. Azure Kubernetes Service ist skalierbar, aber wenn Sie die WebLogic Cluster API verwendet haben, müssen Sie Ihren Code so umgestalten, dass die Verwendung dieser API entfällt.

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 nun zu Azure Kubernetes Service migriert haben, sollten Sie sich vergewissern, dass sie wie erwartet funktioniert. Wenn Sie das getan haben, lesen Sie die folgenden Empfehlungen, um Ihre Anwendung Cloud-nativer zu machen.

Empfehlungen