Migrieren von Tomcat-Anwendungen zu Tomcat unter Azure App Service

  • Artikel

In diesem Leitfaden erfahren Sie, was Sie beachten sollten, wenn Sie eine vorhandene Tomcat-Anwendung für die Ausführung unter Azure App Service mit Tomcat 9.0 migrieren 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.

Falls Sie keine dieser Voraussetzungen für die Migration erfüllen können, sehen Sie sich die folgenden Begleithandbücher an:

Wechseln zu einer unterstützten Plattform

App Service verfügt über bestimmte Versionen von Tomcat für bestimmte Versionen von Java. Migrieren Sie Ihre Anwendung zur Sicherstellung der Kompatibilität in der aktuellen Umgebung zu einer der unterstützten Versionen von Tomcat und Java, bevor Sie mit den restlichen Schritten fortfahren. Achten Sie darauf, dass Sie die sich ergebende Konfiguration umfassend testen. Verwenden Sie für diese Tests das neueste stabile Release Ihrer Linux-Distribution.

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

Auf Azure-App Service werden die Binärdateien für Java 8 von Eclipse Temurin bereitgestellt. Für Java 11, 17 und alle zukünftigen LTS-Versionen von Java stellt App Service den Microsoft Build of OpenJDK bereit. Diese Binärdateien stehen kostenlos auf den folgenden Websites zum Download zur Verfügung:

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

${CATALINA_HOME}/bin/version.sh

Laden Sie Tomcat 9 herunter, um die aktuelle, von Azure App Service verwendete Version zu erhalten. Dies hängt davon ab, welche Version Sie in Azure App Service nutzen möchten.

Bestand: Externe Ressourcen

Externe Ressourcen, z. B. Datenquellen, JMS-Nachrichtenbroker und andere, werden per JNDI (Java Naming and Directory Interface) eingefügt. Für einige dieser Ressourcen ist unter Umständen eine Migration oder erneute Konfiguration erforderlich.

Innerhalb Ihrer Anwendung

Untersuchen Sie die Datei META-INF/context.xml. Suchen Sie im <Context>-Element nach <Resource>-Elementen.

Auf den Anwendungsservern

Untersuchen Sie die Dateien $CATALINA_BASE/conf/context.xml und $CATALINA_BASE/conf/server.xml sowie die XML-Dateien, die in Verzeichnissen der Art $CATALINA_BASE/conf/[Engine-Name]/[Hostname] enthalten sind.

In context.xml-Dateien werden JNDI-Ressourcen im <Context>-Element der obersten Ebene mithilfe von <Resource>-Elementen beschrieben.

In server.xml-Dateien werden JNDI-Ressourcen im <GlobalNamingResources>-Element mithilfe von <Resource>-Elementen beschrieben.

Datenquellen

Datenquellen sind JNDI-Ressourcen, für die das type-Attribut auf javax.sql.DataSource festgelegt ist. Dokumentieren Sie für jede Datenquelle die folgenden Informationen:

  • 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 Tomcat-Dokumentation unter Anleitung zur JNDI-Datenquelle.

Alle anderen externen Ressourcen

Es würde den Rahmen dieses Leitfadens sprengen, jede mögliche externe Abhängigkeit zu dokumentieren. Ihr Team ist dafür verantwortlich, zu überprüfen, dass nach der Migration die Anforderungen aller externen Abhängigkeiten Ihrer Anwendung abgedeckt werden können.

Bestand: Geheimnisse

Kennwörter und sichere Zeichenfolgen

Überprüfen Sie alle Eigenschaften und Konfigurationsdateien auf den Produktionsservern auf Geheimniszeichenfolgen und Kennwörter. Überprüfen Sie unbedingt server.xml und context.xml in $CATALINA_BASE/conf. Unter Umständen finden Sie in Ihrer Anwendung auch Konfigurationsdateien mit Kennwörtern oder Anmeldeinformationen. Dies können Dateien wie META-INF/context.xml und für Spring Boot-Anwendungen application.properties oder application.yml sein.

Inventarisieren von Zertifikaten

Dokumentieren Sie alle Zertifikate, die für öffentliche SSL-Endpunkte oder für die Kommunikation mit Back-End-Datenbanken und anderen Systemen 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>

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. Es kann sein, dass für Sie einige bzw. alle folgenden Szenarien zutreffen.

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 StorageundSchnellstart: Integrieren eines Azure-Speicherkontos in Azure CDN. Sie können den statischen Inhalt auch direkt in einer App im Azure Spring Apps Enterprise-Plan bereitstellen. Weitere Informationen finden Sie unter Bereitstellen statischer Webdateien.

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. Sie können den statischen Inhalt auch direkt in einer App im Azure Spring Apps Enterprise-Plan bereitstellen. Weitere Informationen finden Sie unter Bereitstellen statischer Webdateien.

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 im App Service-Dateisystem bereitstellen. Weitere Informationen finden Sie unter Bereitstellen von Inhalt aus Azure Storage in App Service unter Linux.

Identifizieren eines Mechanismus für Sitzungspersistenz

Untersuchen Sie die context.xml-Dateien in Ihrer Anwendung und der Tomcat-Konfiguration, um den verwendeten Manager für Sitzungspersistenz zu ermitteln. Suchen Sie nach dem <Manager>-Element, und notieren Sie sich den Wert des className-Attributs.

Die integrierten PersistentManager-Implementierungen von Tomcat, z. B. StandardManager oder FileStore, sind nicht für die Nutzung mit einer verteilten skalierten Plattform wie App Service konzipiert. Da App Service ggf. einen Lastenausgleich zwischen verschiedenen Instanzen vornimmt und für Instanzen jederzeit einen transparenten Neustart durchführen kann, ist das dauerhafte Speichern eines veränderlichen Zustands in einem Dateisystem nicht zu empfehlen.

Ist Sitzungspersistenz erforderlich, müssen Sie eine andere PersistentManager-Implementierung verwenden, bei der in einen externen Datenspeicher geschrieben wird, z. B. VMware Tanzu-Sitzungs-Manager mit Redis Cache. Weitere Informationen finden Sie unter Verwenden von Redis als Sitzungscache mit Tomcat.

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.

Sonderfälle

Für bestimmte Produktionsszenarien sind unter Umständen zusätzliche Änderungen erforderlich, oder es gelten zusätzliche Einschränkungen. Szenarien dieser Art sind zwar eher selten, aber Sie sollten trotzdem sicherstellen, dass sie für Ihre Anwendung entweder nicht zutreffen oder korrekt behoben werden.

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

Geplante Aufträge, z. B. Quartz Scheduler-Aufgaben oder cron-Aufträge, können mit App Service nicht verwendet werden. App 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.

Inventarisieren Sie alle geplanten Aufträge innerhalb oder außerhalb des Anwendungsservers.

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 ggf. alle Vorkommen von / oder \ in Dateisystempfaden durch File.Separator oder Paths.get ersetzen.

Ermitteln, ob das Tomcat-Clustering genutzt wird

Das Tomcat-Clustering wird für Azure App Service nicht unterstützt. Stattdessen können Sie die Skalierung und den Lastenausgleich mit Azure App Service und ohne Tomcat-spezifische Funktionen konfigurieren und verwalten. Sie können den Sitzungszustand an einem alternativen Speicherort speichern, um ihn für Replikate übergreifend verfügbar zu machen. Weitere Informationen finden Sie unter Identifizieren eines Mechanismus für Sitzungspersistenz.

Suchen Sie für die Ermittlung, ob für Ihre Anwendung das Clustering verwendet wird, in der server.xml-Datei in den Elementen <Host> oder <Engine> nach dem <Cluster>-Element.

Ermitteln, ob Connectors ohne HTTP genutzt werden

App Service unterstützt nur jeweils einen HTTP-Connector. Wenn für Ihre Anwendung zusätzliche Connectors erforderlich sind, z. B. der AJP-Connector, sollten Sie App Service nicht verwenden.

Suchen Sie in der Datei server.xml Ihrer Tomcat-Konfiguration nach <Connector>-Elementen, um die von Ihrer Anwendung genutzten HTTP-Connectors zu ermitteln.

Ermitteln, ob MemoryRealm genutzt wird

Für MemoryRealm wird eine persistente XML-Datei benötigt. Diese Datei muss in Azure App Service in das Verzeichnis /home oder in eines seiner Unterverzeichnisse oder in eingebundenen Speicher hochgeladen werden. Anschließend muss der Parameter pathName entsprechend geändert werden.

Gehen Sie wie folgt vor, um zu ermitteln, ob MemoryRealm derzeit verwendet wird: Untersuchen Sie Ihre server.xml- und context.xml-Dateien, und suchen Sie nach <Realm>-Elementen, für die das className-Attribut auf org.apache.catalina.realm.MemoryRealm festgelegt ist.

Ermitteln, ob die SSL-Sitzungsverfolgung genutzt wird

App Service führt die Sitzungsabladung außerhalb der Tomcat-Runtime durch. Daher kann die SSL-Sitzungsverfolgung nicht verwendet werden. Verwenden Sie stattdessen einen anderen Modus für die Sitzungsverfolgung (COOKIE oder URL). Vermeiden Sie die Verwendung von App Service, wenn Sie die SSL-Sitzungsverfolgung benötigen.

Ermitteln, ob AccessLogValve genutzt wird

Bei Verwendung von AccessLogValve muss der Parameter directory auf /home/LogFiles oder auf eines der zugehörigen Unterverzeichnisse festgelegt werden.

Migration

Parametrisieren der Konfiguration

Im Rahmen der Migrationsvorbereitung haben Sie wahrscheinlich einige Geheimnisse und externe Abhängigkeiten (beispielsweise Datenquellen) in den Dateien server.xml und context.xml ermittelt. Ersetzen Sie für alle ermittelten Elemente jeweils den Benutzernamen, das Kennwort, die Verbindungszeichenfolge und die URL durch eine Umgebungsvariable.

Angenommen, die context.xml-Datei enthält das folgende Element:

<Resource
    name="jdbc/dbconnection"
    type="javax.sql.DataSource"
    url="jdbc:postgresql://postgresdb.contoso.com/wickedsecret?ssl=true"
    driverClassName="org.postgresql.Driver"
    username="postgres"
    password="t00secure2gue$$"
/>

In diesem Fall können Sie die Änderungen vornehmen, die im folgenden Beispiel angegeben sind:

<Resource
    name="jdbc/dbconnection"
    type="javax.sql.DataSource"
    url="${postgresdb.connectionString}"
    driverClassName="org.postgresql.Driver"
    username="${postgresdb.username}"
    password="${postgresdb.password}"
/>

Um sicherzustellen, dass die Parameterersetzung für eine beliebige Context.xml-Datei innerhalb des META-INF-Ordners innerhalb einer bereitgestellten WAR-Datei erfolgt, müssen Sie die CATALINA_OPTS Umgebungsvariable wie im folgenden Beispiel gezeigt festlegen:

export CATALINA_OPTS="-Dorg.apache.tomcat.util.digester.PROPERTY_SOURCE=org.apache.tomcat.util.digester.EnvironmentPropertySource"

Bereitstellen eines App Service-Plans

Wählen Sie unter App Service – Preise in der Liste mit den verfügbaren App Service-Plänen die Option aus, bei der die Spezifikationen die Vorgaben der aktuellen Produktionshardware erfüllen bzw. übererfüllen.

Hinweis

Wenn Sie die Ausführung von Staging- bzw. Canarybereitstellungen planen oder Bereitstellungsslots nutzen möchten, muss der App Service-Plan diese zusätzliche Kapazität enthalten. Wir empfehlen Ihnen die Verwendung eines Premium-Plans (oder höher) für Java-Anwendungen. Weitere Informationen finden Sie unter Einrichten von Stagingumgebungen in Azure App Service.

Erstellen Sie anschließend den App Service Plan. Weitere Informationen finden Sie unter Verwalten eines App Service-Plans in Azure.

Erstellen und Bereitstellen von Web-Apps

Sie müssen für jede WAR-Datei, die auf Ihrem Tomcat-Server bereitgestellt wird, eine Web-App in Ihrem App Service-Plan erstellen (und eine Version von Tomcat als Laufzeitstapel auswählen).

Hinweis

Es ist zwar möglich, für eine Web-App mehrere WAR-Dateien bereitzustellen, aber dies entspricht nicht der empfohlenen Vorgehensweise. Die Bereitstellung mehrerer WAR-Dateien für eine Web-App verhindert, dass jede Anwendung gemäß ihren jeweiligen Nutzungsanforderungen skaliert werden kann. Darüber hinaus wird hierdurch die Komplexität nachfolgender Bereitstellungspipelines erhöht. Wenn mehrere Anwendungen unter einer einzelnen URL verfügbar sein sollen, sollten Sie den Einsatz einer Routinglösung, z. B. Azure Application Gateway, erwägen.

Maven-Anwendungen

Wenn Ihre Anwendung über eine Maven-POM-Datei erstellt wurde, sollten Sie das Web-App-Plug-In für Maven verwenden, um die Web-App zu erstellen und Ihre Anwendung bereitzustellen.

Nicht auf Maven basierende Anwendungen

Falls Sie das Maven-Plug-In nicht verwenden können, müssen Sie die Web-App über andere Mechanismen bereitstellen, z. B.:

Verwenden Sie nach der Erstellung der Web-App einen der verfügbaren Bereitstellungsmechanismen, um Ihre Anwendung bereitzustellen.

Migrieren von JVM-Runtimeoptionen

Wenn für Ihre Anwendung bestimmte Runtimeoptionen benötigt werden, sollten Sie zum Angeben den am besten geeigneten Mechanismus verwenden.

Einfügen von Geheimnissen

Verwenden Sie die Anwendungseinstellungen, um die spezifischen Geheimnisse für Ihre Anwendung zu speichern. Falls Sie die gleichen Geheimnisse für mehrere Anwendungen nutzen möchten oder differenzierte Zugriffsrichtlinien und Überwachungsfunktionen benötigen, sollten Sie stattdessen Azure Key Vault nutzen.

Konfigurieren der benutzerdefinierten Domäne und der Nutzung von SSL

Wenn Ihre Anwendung in einer benutzerdefinierten Domäne sichtbar ist, müssen Sie Ihre Webanwendung zuordnen. Weitere Informationen finden Sie unter Tutorial: Zuordnen eines vorhandenen benutzerdefinierten DNS-Namens zu Azure App Service.

Anschließend müssen Sie das SSL-Zertifikat für diese Domäne an Ihre App Service-Web-App binden. Weitere Informationen finden Sie unter Schützen eines benutzerdefinierten DNS-Namens mit einer SSL-Bindung in Azure App Service.

Importieren von Back-End-Zertifikaten

Alle Zertifikate für die Kommunikation mit Back-End-Systemen (z. B. Datenbanken) müssen für App Service verfügbar gemacht werden. Weitere Informationen finden Sie unter Hinzufügen eines SSL-Zertifikats in Azure App Service.

Migrieren von Datenquellen, Bibliotheken und JNDI-Ressourcen

Informationen zu den Konfigurationsschritten für Datenquellen finden Sie unter Konfigurieren einer Linux-Java-App für Azure App Service im Abschnitt Datenquellen.

Weitere Anweisungen zu Datenquellen finden Sie in der Tomcat-Dokumentation in den folgenden Abschnitten der Anleitung zur JNDI-Datenquelle:

Migrieren Sie alle zusätzlichen Klassenpfadabhängigkeiten auf Serverebene, indem Sie die gleichen Schritte wie für die JAR-Dateien der Datenquelle ausführen.

Migrieren Sie alle zusätzlichen freigegebenen JDNI-Ressourcen auf Serverebene.

Hinweis

Wenn Sie sich an die empfohlene Architektur mit einer WAR-Datei pro Web-App halten, sollten Sie erwägen, Klassenpfadbibliotheken auf Serverebene und JNDI-Ressourcen zu Ihrer Anwendung zu migrieren. Bereiche wie Governance und Change Management für Komponenten werden so erheblich vereinfacht.

Migrieren der restlichen Konfiguration

Wenn Sie den vorherigen Abschnitt abgeschlossen haben, sollten Sie unter /home/tomcat/conf über Ihre anpassbare Serverkonfiguration verfügen.

Schließen Sie die Migration ab, indem Sie alle zusätzlichen Konfigurationen kopieren (beispielsweise realms und JASPIC).

Migrieren von geplanten Aufträgen

Erwägen Sie für die Ausführung von geplanten Aufträgen in Azure die Verwendung eines Zeitgebertriggers für Azure Functions. Hierbei ist es nicht erforderlich, den eigentlichen Auftragscode in eine Funktion zu migrieren. Für die Funktion kann einfach eine URL in Ihrer Anwendung aufgerufen werden, um den Auftrag auszulösen. Wenn Auftragsausführungen dieser Art dynamisch aufgerufen bzw. zentral nachverfolgt werden müssen, sollten Sie die Nutzung von Spring Batch erwägen.

Alternativ können Sie eine Logik-App mit einem Wiederholungstrigger erstellen, um die URL aufzurufen, ohne außerhalb Ihrer Anwendung Code schreiben zu müssen. Weitere Informationen finden Sie unter Übersicht: Was ist Azure Logic Apps? und Erstellen, Planen und Ausführen von wiederkehrenden Aufgaben und Workflows mit dem Serientrigger in Azure Logic Apps.

Hinweis

Zur Verhinderung einer missbräuchlichen Nutzung müssen Sie ggf. sicherstellen, dass für den Endpunkt zum Aufrufen des Auftrags Anmeldeinformationen benötigt werden. In diesem Fall müssen die Anmeldeinformationen von der Triggerfunktion bereitgestellt werden.

Neustarten und Durchführen des Buildüberprüfungstests

Abschließend müssen Sie Ihre Web-App neu starten, um alle Konfigurationsänderungen anzuwenden. Vergewissern Sie sich nach Abschluss des Neustarts, dass Ihre Anwendung korrekt ausgeführt wird.

Nach der Migration

Nachdem Sie Ihre Anwendung nun zu Azure App Service migriert haben, sollten Sie überprüfen, ob sie wie erwartet funktioniert. Als Nächstes können Sie sich dann über unsere Empfehlungen informieren, mit denen Sie Ihre Anwendung cloudnativer gestalten können.

Empfehlungen