Tomcat-apps migreren naar Tomcat in Azure App Service

  • Artikel
  • 11 minuten om te lezen

In deze handleiding wordt beschreven waar u rekening mee moet houden wanneer u een bestaande Tomcat-toepassing wilt migreren om te worden uitgevoerd op Azure App Service tomcat 9.0.

Premigratie

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

Als u niet aan een van deze vereisten vóór de migratie kunt voldoen, bekijkt u de volgende handleidingen voor migratie:

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 verder gaat 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

Als u de huidige versie wilt verkrijgen die door Azure App Service wordt gebruikt, downloadt u Zulu 8 als u van plan bent de Java 8 Runtime te gebruiken, of Zulu 11 als u van plan bent de Java 11 Runtime te gebruiken.

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 wordt gebruikt door Azure App Service, downloadt u Tomcat 9,afhankelijk van de versie die u wilt gebruiken in Azure App Service.

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 -elementen binnen het <Context>-element op het hoogste niveau.

In server.xml-bestanden worden JNDI-resources beschreven door de -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?

Zie how-TO voor JNDI Datasource in de Tomcat-documentatie voor meer informatie.

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>

Bepalen 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 Hosting van statische websites in Azure Storage en Quickstart: Een Azure-opslagaccount integreren met Azure CDN .

Dynamisch gepubliceerde statische inhoud

Als uw toepassing statische inhoud toestaat die wordt geüpload/geproduceerd door uw toepassing, maar onveranderbaar is nadat deze is gemaakt, kunt u Azure Blob Storage en Azure CDN gebruiken zoals hierboven beschreven, met een Azure-functie om uploads en CDN-vernieuwing te verwerken. U vindt een voorbeeldimplementatie voor gebruik in Statische inhoud uploaden en via CDN vooraf laden met Azure Functions.

Dynamische of interne inhoud

Voor bestanden die vaak worden gelezen en 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.

De methode voor 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 sessie persistentie is vereist, moet u een alternatieve implementatie gebruiken die naar een extern gegevensopslag schrijft, zoals PersistentManager 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.

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 niet vaak voorkomen, is het belangrijk om ervoor te zorgen dat ze niet van toepassing zijn op uw toepassing of juist 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 intern een toepassing met geplande taken 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 app code bevat met afhankelijkheden van het hostbesturingssysteem, moet u de app 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 <Cluster>.

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 <Connector> in uw Tomcat-configuratie.

Bepalen of MemoryRealm wordt gebruikt

Voor MemoryRealm is een persistent XML-bestand vereist. In Azure AppService moet u dit bestand uploaden naar de map /home of een van de subdirectory's, of naar de aan elkaar geplaatste opslag. Vervolgens moet u de pathName parameter dienovereenkomstig wijzigen.

Als u wilt bepalen of MemoryRealm momenteel wordt gebruikt, controleert u de bestanden MemoryRealm en context.xml en zoekt u naar -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 of een van de /home/LogFiles subdirecties.

Migratie

De configuratie parameteriseren

In de stappen vóór de migratie hebt u waarschijnlijk een aantal geheimen en externe afhankelijkheden, zoals gegevensbron, inserver.xmlen context.xml geïdentificeerd. Vervang voor elk item dat u hebt geïdentificeerd een gebruikersnaam, wachtwoord, connection string url 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}"
/>

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-apps. 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 Voor meer informatie Zelfstudie: Een bestaande aangepaste DNS-naam aan een Azure App Service.

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

Zie de sectie Gegevensbronnen van Een Linux Java-appconfigureren voor meer informatie over het configureren van Azure App Service.

Zie de volgende secties van de instructies voor JNDI-gegevensbron in de Tomcat-documentatie voor aanvullende instructies voor gegevensbron:

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 eventuele aanvullende configuraties te kopiëren (zoals realms en WILTPIC)

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 opstarten 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