Tomcat-apps migreren naar Tomcat in Azure App Service

  • Artikel

In deze handleiding wordt beschreven waarmee u rekening moet houden wanneer u een bestaande Tomcat-app wilt migreren zodat deze kan worden uitgevoerd in Azure App Service met behulp van Tomcat 9.0.

Premigratie

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

Als u niet aan een van deze vereisten vóór de migratie kunt voldoen, raadpleegt u de volgende aanvullende migratiehandleidingen:

Overschakelen naar een ondersteund platform

App Service biedt specifieke versies van Tomcat in bepaalde versies van Java. Om compatibiliteit te garanderen, migreert u uw toepassing naar een van de ondersteunde versies van Tomcat en Java in de huidige omgeving voordat u doorgaat met een van de resterende stappen. Zorg ervoor dat de uiteindelijke configuratie volledig wordt getest. Gebruik in dergelijke tests de laatste stabiele versie van uw Linux-distributie.

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

Op Azure-app Service worden de binaire bestanden voor Java 8 geleverd vanuit Eclipse Temurin. Voor Java 11, 17 en alle toekomstige LTS-releases van Java biedt App Service de Microsoft Build van OpenJDK. Deze binaire bestanden zijn gratis te downloaden op de volgende sites:

Meld u aan bij uw productieserver en voer de volgende opdracht uit om uw huidige Tomcat-versie te verkrijgen:

${CATALINA_HOME}/bin/version.sh

Als u de huidige versie wilt verkrijgen die door Azure App Service wordt gebruikt, downloadt u Tomcat 9, afhankelijk van de versie die u in Azure App Service wilt gebruiken.

Externe resources inventariseren

Externe resources, zoals gegevensbronnen, JMS-berichtenbrokers en andere resources, worden ingevoerd via Java Naming and Directory Interface (JNDI). Voor sommige resources kan migratie of herconfiguratie vereist zijn.

Binnen uw toepassing

Inspecteer het bestand META-INF/context.xml. Zoek naar <Resource>-elementen in het <Context>-element.

Op de toepassingsserver(s)

Inspecteer de bestanden $CATALINA_BASE/conf/context.xml en $CATALINA_BASE/conf/server.xml, evenals de .xml-bestanden die zich bevinden in de mappen $CATALINA_BASE/conf/[engine-name]/[host-name].

In context.xml-bestanden worden JNDI-resources beschreven door de <Resource>-elementen binnen het <Context>-element op het hoogste niveau.

In server.xml-bestanden worden JNDI-resources beschreven door de <Resource>-elementen binnen het <GlobalNamingResources>-element.

Gegevensbronnen

Gegevensbronnen zijn JNDI-resources waarvoor het kenmerk type is ingesteld op javax.sql.DataSource. Documenteer voor elke gegevensbron de volgende informatie:

  • 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 JNDI Datasource HOW-TO in de Tomcat-documentatie.

Alle andere externe resources

Het is niet haalbaar om alle mogelijke externe afhankelijkheden in deze handleiding te documenteren. Het is de verantwoordelijkheid van uw team om alle externe afhankelijkheden van uw toepassing te verifiëren na de migratie.

Geheimen inventariseren

Wachtwoorden en beveiligde tekenreeksen

Controleer alle eigenschaps- en configuratiebestanden op de productieserver(s) op geheime tekenreeksen en wachtwoorden. Controleer in elk geval server.xml en context.xml in $CATALINA_BASE/conf. U kunt ook configuratiebestanden met wachtwoorden of referenties in uw toepassing aantreffen. Het kan gaan om de bestanden META-INF/context.xml en, voor Spring Boot-toepassingen, application.properties of application.yml.

Certificaten inventariseren

Documenteer alle certificaten die worden gebruikt voor openbare SSL-eindpunten of communicatie met back-enddatabases en andere systemen. U kunt alle certificaten op de productieserver(s) weergeven door de volgende opdracht uit te voeren:

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

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. U kunt enkele of elk van de volgende scenario's identificeren.

Statische alleen-lezeninhoud

Als uw toepassing momenteel met statische inhoud werkt, hebt u hiervoor een alternatieve locatie nodig. U kunt statische inhoud verplaatsen naar Azure Blob Storage en Azure CDN toevoegen voor razendsnelle downloads wereldwijd. Zie statische websitehosting in Azure Storage en quickstart: Een Azure-opslagaccount integreren met Azure CDN voor meer informatie. U kunt de statische inhoud ook rechtstreeks implementeren in een app in het Azure Spring Apps Enterprise-abonnement. Zie Statische webbestanden implementeren voor meer informatie.

Dynamisch gepubliceerde statische inhoud

Als uw toepassing statische inhoud toestaat die wordt geüpload/geproduceerd door uw toepassing, maar onveranderbaar is nadat deze is gemaakt, kunt u Azure Blob Storage en Azure CDN gebruiken zoals hierboven beschreven, met een Azure-functie om uploads en CDN-vernieuwing te verwerken. U vindt een voorbeeldimplementatie voor gebruik in Statische inhoud uploaden en via CDN vooraf laden met Azure Functions. U kunt de statische inhoud ook rechtstreeks implementeren in een app in het Azure Spring Apps Enterprise-abonnement. Zie Statische webbestanden implementeren voor meer informatie.

Dynamische of interne inhoud

Voor bestanden die vaak worden gelezen en waarheen regelmatig gegevens worden geschreven door uw app (zoals tijdelijke gegevensbestanden) of statische bestanden die alleen zichtbaar zijn voor uw app, kunt u Azure Storage koppelen aan het App Service-bestandssysteem. Zie Inhoud uit Azure Storage leveren in App Service voor Linux voor meer informatie.

Methode voor de sessiepersistentie bepalen

Controleer de context.xml-bestanden in uw toepassing en Tomcat-configuratie om te bepalen welk sessiepersistentiebeheer wordt gebruikt. Ga naar het element <Manager> en noteer de waarde van het kenmerk className.

De ingebouwde PersistentManager-implementaties van Tomcat, zoals StandardManager of FileStore, zijn niet ontworpen om te worden gebruikt met een gedistribueerd, geschaald platform zoals App Service. Omdat App Service een taakverdeling tussen verschillende instanties kan toepassen en instanties op elk gewenst moment op transparante wijze opnieuw kan opstarten, wordt het niet aanbevolen om een veranderlijke status te blijven behouden voor een bestandssysteem.

Als sessiepersistentie vereist is, moet u een alternatieve PersistentManager implementatie gebruiken die naar een extern gegevensarchief schrijft, zoals VMware Tanzu Session Manager met Redis Cache. Zie Redis als een sessiecache gebruiken met Tomcat voor meer informatie.

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.

Speciale gevallen

Voor bepaalde productiescenario's zijn mogelijk aanvullende wijzigingen vereist of gelden extra beperkingen. Hoewel dergelijke scenario's incidenteel kunnen zijn, is het belangrijk om ervoor te zorgen dat deze niet van toepassing zijn op uw toepassing of correct zijn opgelost.

Bepalen of de toepassing gebruikmaakt van geplande taken

Geplande taken, zoals Quartz Scheduler-taken of Cron-taken, kunnen niet met App Service worden gebruikt. App Service voorkomt niet 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.

Maak een inventaris van de geplande taken binnen of buiten de toepassingsserver.

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

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

Bepalen of Tomcat-clustering wordt gebruikt

Tomcat-clustering wordt niet ondersteund in Azure App Service. In plaats daarvan kunt u het schalen en de taakverdeling configureren en beheren via Azure App Service zonder Tomcat-functionaliteit. U kunt de sessiestatus doorvoeren op een andere locatie, zodat deze beschikbaar is in verschillende replica's. Zie Methode voor de sessiepersistentie bepalen voor meer informatie.

Als u wilt bepalen of uw app gebruikmaakt van clustering, zoekt u naar het element <Cluster> in de elementen <Host> of <Engine> in het bestand server.xml.

Bepalen of andere connectors dan HTTP-connectors worden gebruikt

App Service ondersteunt slechts één HTTP-connector. Als voor uw app aanvullende connectors zijn vereist, zoals de AJP-connector, moet u App Service niet gebruiken.

Als u wilt weten welke HTTP-connectors door uw app worden gebruikt, zoekt u naar <Connector>-elementen in het bestand server.xml in uw Tomcat-configuratie.

Bepalen of MemoryRealm wordt gebruikt

Voor MemoryRealm is een persistent XML-bestand vereist. In Azure-app Service moet u dit bestand uploaden naar de /home-map of een van de bijbehorende submappen of naar gekoppelde opslag. Vervolgens moet u de pathName parameter dienovereenkomstig wijzigen.

Als u wilt bepalen of MemoryRealm op het huidige moment wordt gebruikt, controleert u de bestanden server.xml en context.xml en zoekt u naar <Realm>-elementen waarbij het kenmerk className is ingesteld op org.apache.catalina.realm.MemoryRealm.

Bepalen of SSL-sessietracering wordt gebruikt

App Service voert sessie-offloading uit buiten de Tomcat-runtime, zodat u geen SSL-sessietracking kunt gebruiken. Gebruik in plaats daarvan een andere modus voor het bijhouden van sessies (COOKIE of URL). Als u SSL-sessietracering nodig hebt, moet u App Service niet gebruiken.

Bepalen of AccessLogValve wordt gebruikt

Als u AccessLogValve gebruikt, moet u de parameter instellen op /home/LogFiles of een van de directory bijbehorende submappen.

Migratie

De configuratie parameteriseren

In de stappen vóór de migratie hebt u waarschijnlijk enkele geheimen en externe afhankelijkheden geïdentificeerd, zoals gegevensbronnen, in server.xml - en context.xml-bestanden . Vervang voor elk item dat u hebt geïdentificeerd een gebruikersnaam, wachtwoord, verbindingsreeks of URL door een omgevingsvariabele.

Stel bijvoorbeeld dat het bestand context.xml het volgende element bevat:

<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 dat geval kunt u dit wijzigen zoals wordt weergegeven in het volgende voorbeeld:

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

Als u ervoor wilt zorgen dat parametervervanging plaatsvindt voor elk context.XML-bestand in de map META-INF in een geïmplementeerd WAR-bestand , moet u de CATALINA_OPTS omgevingsvariabele instellen, zoals wordt weergegeven in het volgende voorbeeld:

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

Een App Service-plan inrichten

Selecteer in de lijst met beschikbare serviceabonnementen in App Service-prijzen het abonnement waarvan de specificaties voldoen aan of hoger zijn dan die van de huidige productiehardware.

Notitie

Als u van plan bent om faserings-/canaryimplementaties uit te voeren of om implementatiesites te gebruiken, moet het App Service-plan over die extra capaciteit beschikken. Het wordt aanbevolen om Premium-abonnementen of hoger te gebruiken voor Java-toepassingen. Zie Faseringsomgevingen in Azure App Service instellen voor meer informatie.

Maak vervolgens het App Service-plan. Zie Een App Service-plan beheren in Azure voor meer informatie.

Web-app(s) maken en implementeren

U moet een web-app maken in uw App Service-plan (waarbij u een versie van Tomcat kiest als runtimestack) voor elk WAR-bestand dat op uw Tomcat-server is geïmplementeerd.

Notitie

Hoewel het mogelijk is om meerdere WAR-bestanden te implementeren in één web-app, is dit zeer onwenselijk. Wanneer u meerdere WAR-bestanden in één web-app implementeert, wordt voorkomen dat elke app wordt geschaald op basis van de eigen gebruiksvereisten. Het veroorzaakt ook meer complexiteit voor volgende implementatiepijplijnen. Als er meerdere apps op één URL beschikbaar moeten zijn, kunt u het beste een routeringsoplossing, zoals Azure Application Gateway, gebruiken.

Maven-apps

Als uw toepassing is ontwikkeld op basis van een Maven POM-bestand, gebruikt u de web-app-invoegtoepassing voor Maven om de web-app te maken en uw toepassing te implementeren.

Andere toepassingen dan Maven-toepassingen

Als u de Maven-invoegtoepassing niet kunt gebruiken, moet u de web-app op andere manieren inrichten, zoals:

Wanneer de web-app is gemaakt, gebruikt u een van de beschikbare implementatiemethoden om uw app te implementeren.

JVM-runtimeopties migreren

Als voor uw app specifieke runtimeopties vereist zijn, gebruikt u de beste methode om deze op te geven.

Geheimen vullen

Gebruik app-instellingen om geheimen op te slaan die specifiek zijn voor uw app. Als u dezelfde geheimen wilt gebruiken voor meerdere apps of als u meer gedetailleerde toegangsbeleidsregels en controlefuncties wilt toepassen, kunt u in plaats daarvan Azure Key Vault gebruiken.

Aangepast domein en SSL configureren

Als uw toepassing wordt weergegeven in een aangepast domein, moet u uw webtoepassing hieraan toewijzen. Zie Zelfstudie: Een bestaande aangepaste DNS-naam toewijzen aan Azure-app Service voor meer informatie.

Vervolgens moet u het SSL-certificaat voor dat domein binden aan uw App Service-web-app. Zie Een aangepaste DNS-naam beveiligen met een SSL-binding in Azure App Service voor meer informatie.

Back-endcertificaten importeren

Alle certificaten voor het communiceren met back-endsystemen, zoals databases, moeten beschikbaar worden gesteld aan App Service. Zie Een SSL-certificaat toevoegen in App Service voor meer informatie.

Gegevensbronnen, bibliotheken en JNDI-resources migreren

Raadpleeg het gedeelte Gegevensbronnen van Een Linux Java-app configureren voor Azure App Service voor stappen voor gegevensbronconfiguratie.

Raadpleeg de volgende gedeelten van JNDI Datasource How-To in de Tomcat-documentatie voor aanvullende gegevensbroninstructies:

Migreer eventuele aanvullende klassepadafhankelijkheden op serverniveau door dezelfde stappen uit te voeren als voor de JAR-bestanden voor de gegevensbronnen.

Migreer eventuele aanvullende gedeelde JNDI-resources op serverniveau.

Notitie

Als u gebruikmaakt van de aanbevolen architectuur van één WAR per web-app, kunt u de klassepadbibliotheken op serverniveau en JNDI-resources het beste naar uw app migreren. Dit betekent een aanzienlijke vereenvoudiging van het onderdelen- en wijzigingsbeheer.

Resterende configuratie migreren

Wanneer u de voorgaande sectie hebt voltooid, moet uw aanpasbare serverconfiguratie in /home/tomcat/conf staan.

Voltooi de migratie door aanvullende configuratie (zoals realms en JASPIC) te kopiëren.

Geplande taken migreren

Als u geplande taken wilt uitvoeren in Azure, kunt u gebruikmaken van een Timertrigger voor Azure Functions. U hoeft de taakcode zelf niet naar een functie te migreren. Via de functie kan eenvoudig een URL in uw toepassing worden aangeroepen om de taak te activeren. Als dergelijke taakuitvoeringen dynamisch moeten worden aangeroepen en/of centraal moeten worden bijgehouden, kunt u Spring Batch gebruiken.

U kunt ook een logische app maken met een terugkeertrigger om de URL aan te roepen zonder dat u code hoeft te schrijven buiten uw toepassing. Zie Overzicht - wat is Azure Logic Apps? en Terugkerende taken en werkstromen maken, plannen en uitvoeren met de terugkeertrigger in Azure Logic Apps voor meer informatie.

Notitie

Om kwaadwillend gebruik te voorkomen, moet u er waarschijnlijk voor zorgen dat er referenties vereist zijn voor het eindpunt dat de taak aanroept. In dit geval moeten de referenties worden opgegeven door de triggerfunctie.

Opnieuw starten en functioneel testen

Ten slotte moet u de web-app opnieuw starten om alle configuratiewijzigingen toe te passen. Wanneer de web-app opnieuw is gestart, controleert u of deze juist wordt uitgevoerd.

Postmigratie

Nu u de app naar Azure App 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 app geschikter kunt maken voor de cloud.

Aanbevelingen