Migrera Tomcat-program till Tomcat på Azure App Service

  • Artikel

I den här guiden beskrivs vad du bör känna till när du ska migrera ett befintligt Tomcat-program och köra det i Azure App Service med Tomcat 9.0.

Före migrering

För att säkerställa en lyckad migrering slutför du de utvärderings- och inventeringssteg som beskrivs i följande avsnitt innan du börjar.

Om du inte kan uppfylla något av dessa krav före migreringen kan du läsa följande kompletterande migreringsguider:

Växla till en plattform som stöds

App Service erbjuder specifika versioner av Tomcat för vissa Java-versioner. För att säkerställa kompatibilitet migrerar du ditt program till en av de versioner av Tomcat och Java som stöds i den aktuella miljön innan du fortsätter med något av de återstående stegen. Var noga med att testa den resulterande konfigurationen fullt ut. Använd den senaste stabila versionen av Linux-distributionen i sådana tester.

Kommentar

Den här verifieringen är särskilt viktig om den aktuella servern körs på en JDK som inte stöds (till exempel Oracle JDK eller IBM OpenJ9).

Du får den aktuella Java-versionen genom att logga in på din produktionsserver och köra följande kommando:

java -version

I Azure App Service tillhandahålls binärfilerna för Java 8 från Eclipse Temurin. För Java 11, 17 och alla framtida LTS-versioner av Java tillhandahåller App Service Microsoft Build of OpenJDK. Dessa binärfiler är tillgängliga för kostnadsfri nedladdning på följande webbplatser:

Du kan hämta den aktuella Tomcat-versionen genom att logga in på produktionsservern och köra följande kommando:

${CATALINA_HOME}/bin/version.sh

Hämta den aktuella version som används av Azure App Service genom att ladda ned Tomcat 9, beroende på vilken version du planerar att använda i Azure App Service.

Inventera externa resurser

Externa resurser som datakällor, JMS asynkron meddelandekö och andra matas via Java-namngivnings- och kataloggränssnittet (JNDI). Vissa resurser kan kräva migrering eller omkonfiguration.

I ditt program

Granska filen META-INF/context.xml. Leta efter <Resource>-element i <Context>-elementet.

På programservrar

Granska filerna $CATALINA_BASE/conf/context.xml och $CATALINA_BASE/conf/server.xml samt de .xml-filer som hittas i $CATALINA_BASE/conf/[engine-name]/[host-name]-katalogerna.

I context.xml-filer kommer JNDI-resurser att beskrivas av de <Resource>-element i toppnivåelementet <Context>.

I server.xml-filer kommer JNDI-resurser att beskrivas av de <Resource>-element i toppnivåelementet <GlobalNamingResources>.

Datakällor

Datakällor är JNDI-resurser med attributet type inställt på javax.sql.DataSource. För varje datakälla, dokumenterar du följande information:

  • What is the datakällans namn?
  • Vad är konfigurationen för anslutningspoolen?
  • Var hittar jag JAR-filen för JDBC-drivrutinen?

Mer information finns i avsnittet om JNDI-datakällor i Tomcat-dokumentationen.

Alla andra externa resurser

Det är inte möjligt att dokumentera alla möjliga externa beroenden i den här guiden. Det är ditt teams ansvar att kontrollera att du kan uppfylla varje externt beroende för ditt program efter migreringen.

Inventera hemligheter

Lösenord och säkra strängar

Kontrollera alla egenskaper och konfigurationsfiler på produktionsservrarna efter hemlighetssträngar och lösenord. Se till att kontrollera server.xml och context.xml i $CATALINA_BASE/conf. Du kan även hitta konfigurationsfiler som med lösenord eller autentiseringsuppgifter i ditt program. De kan inkludera META-INF/context.xml, och för Spring Boot-program, application.properties- eller application.yml-filer.

Inventera certifikat

Dokumentera alla certifikat som används för offentliga SSL-slutpunkter eller kommunikation med serverdelsdatabaser och andra system. Du kan visa alla certifikat på produktionsservrarna genom att köra följande kommando:

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

Kontrollera om och hur filsystemet används

All användning av programserverns filsystem kräver omkonfiguration eller, i sällsynta fall, arkitektoniska ändringar. Du kanske känner igen några eller alla av följande scenarier.

Skrivskyddat statiskt innehåll

Om ditt program för tillfället hanterar statiskt innehåll behöver du en alternativ plats för det. Du kanske kan tänka dig att flytta det statiska innehållet till Azure Blob Storage och lägga till Azure CDN för blixtsnabba nedladdningar globalt. Mer information finns i Värd för statiska webbplatser i Azure Storage och snabbstart: Integrera ett Azure Storage-konto med Azure CDN. Du kan också distribuera det statiska innehållet direkt till en app i Azure Spring Apps Enterprise-planen. Mer information finns i Distribuera webbstatiska filer.

Dynamiskt publicerat statiskt innehåll

Om ditt program tillåter att statiskt innehåll laddas upp/skapas av ditt program, men inte kan ändras efter att det har skapats, så kan du använda Azure Blob Storage och Azure CDN enligt beskrivningen ovan, med en Azure-funktion för hantering av överföringar och CDN-uppdateringar. Vi har tillhandahållit en exempelimplementering som du kan använda i Överföra och CDN-för inläsa statiskt innehåll med Azure Functions. Du kan också distribuera det statiska innehållet direkt till en app i Azure Spring Apps Enterprise-planen. Mer information finns i Distribuera webbstatiska filer.

Dynamiskt eller internt innehåll

För filer som ofta skrivs och läses av ditt program (till exempel temporära datafiler) eller statiska filer som endast är synliga för ditt program kan du montera Azure Storage i App Service-filsystemet. Mer information finns i Hantera innehåll från Azure Storage i App Service på Linux.

Identifiera mekanism för beständig session

Om du vill identifiera vilken funktion för beständig session som används kan du granska context.xml-filerna i program- och Tomcat-konfigurationen. Leta efter elementet <Manager> och anteckna värdet för attributet className.

Tomcats inbyggda PersistentManager-implementeringar, till exempel StandardManager eller FileStore, har inte utformats för användning med en distribuerad, skalad plattform som App Service. Eftersom App Service kan belastningsutjämna mellan flera instanser och starta om alla instanser när som helst med insyn, vilket gör att föränderligt tillstånd till ett filsystem inte rekommenderas.

Om sessionspersistence krävs måste du använda en alternativ PersistentManager implementering som skriver till ett externt datalager, till exempel VMware Tanzu Session Manager med Redis Cache. Mer information finns i Använda Redis som sessioncache med Tomcat.

Identifiera alla externa processer och daemons som körs på produktionsservrarna

Om du har processer som körs utanför programservern, som övervaknings-daemons så behöver du eliminera dem eller migrera dem någon annanstans.

Särskilda fall

Vissa produktionsscenarier kan kräva ytterligare ändringar eller införa ytterligare begränsningar. Även om sådana scenarier kan vara ovanliga är det viktigt att se till att de antingen inte kan tillämpas på ditt program eller åtgärdas korrekt.

Avgör om programmet är beroende av schemalagda uppgifter

Schemalagda jobb, t. ex. Quartz Scheduler-uppgifter eller cron-jobb, kan inte användas med App Service. App Service hindrar dig inte från att distribuera ett program som innehåller schemalagda uppgifter internt. Om ditt program skalas ut kan dock samma schemalagda jobb köras mer än en gång per schemalagd period. Den här situationen kan leda till oönskade konsekvenser.

Inventera schemalagda jobb, inuti eller utanför programservern.

Ta reda på om ditt program innehåller en operativsystemsspecifik kod

Om programmet innehåller en kod med beroenden i värdoperativsystemet måste du omstrukturera det för att ta bort dessa beroenden. Du kan exempelvis bli tvungen att ersätta all användning av / eller \ i filsystemets sökvägar med File.Separator eller Paths.get.

Fastställa om Tomcat-klustring används

Tomcat-klustring stöds inte på Azure App Service. I stället kan du konfigurera och hantera skalning och lastbalansering genom Azure App Service utan Tomcat-specifika funktioner. Du kan göra sessionstillståndet tillgängligt för alla repliker genom att spara det på en alternativ plats. Mer information finns i Identifiera mekanismen för sessionspermanens.

Du kan ta reda på om ditt program använder kluster genom att leta efter elementet <Cluster> inuti elementen <Host> eller <Engine> i filen server.xml.

Fastställa huruvida icke-HTTP-anslutningar används eller inte

App Service stöder bara ett enda HTTP-anslutningsprogram. Om programmet kräver ytterligare anslutningsprogram, t.ex. AJP-anslutningsprogrammet, så använd inte App Service.

Om du vill identifiera HTTP-anslutningsprogram som används av ditt program, så sök efter <Connector>-element i filen server.xml i din Tomcat-konfiguration.

Avgör om MemoryRealm används

MemoryRealm- kräver en sparad XML-fil. I Azure AppService måste du ladda upp den här filen till katalogen /home eller någon av dess underkataloger eller till monterad lagring. Sedan måste du ändra parametern i pathName enlighet med detta.

Du kan ta reda på om MemoryRealm används just nu genom att granska filerna server.xml och context.xml och söka efter <Realm> element där className-attributet är inställt på org.apache.catalina.realm.MemoryRealm.

Ta reda på om SSL-sessionshantering används

App Service utför sessionsavlastning utanför Tomcat-körningen, så du kan inte använda SSL-sessionsspårning. Använd ett annat sessionsspårningsläge istället (COOKIE eller URL). Om du behöver SSL-sessionsspårning, så använd inte App Service.

Fastställ om AccessLogValve används

Om du använder AccessLogValve bör du ange parametern directory till /home/LogFiles eller någon av dess underkataloger.

Migrering

Parameterisera konfigurationen

I stegen före migreringen identifierade du förmodligen vissa hemligheter och externa beroenden, till exempel datakällor, i filerna server.xml och context.xml . För varje objekt som du identifierade ersätter du användarnamn, lösenord, anslutningssträng eller URL med en miljövariabel.

Anta till exempel att filen context.xml innehåller följande 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$$"
/>

I det här fallet kan du ändra det som visas i följande exempel:

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

Se till att parameterersättning sker för alla context.xml-filer i mappen META-INF i en distribuerad .war-fil genom att ange CATALINA_OPTS miljövariabeln enligt följande exempel:

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

Etablera en App Service-plan

I listan över tillgängliga tjänstplaner på App Service-prissättning väljer du den plan vars specifikationer uppfyller eller överskrider den aktuella produktionsmaskinvarans specifikationer.

Kommentar

Om du planerar att köra mellanlagrings-/kontrollvärdesdistributioner eller använda distributionsfack måste App Service-planen innehålla denna ytterligare kapacitet. Vi rekommenderar att du använder en Premium-plan eller högre för Java-program. Mer information finns i Konfigurera mellanlagringsmiljöer i Azure App Service.

Skapa sedan App Service-planen. Mer information finns i Hanera en App Service-plan i Azure.

Skapa och distribuera webbappar

Du måste skapa en webbapp i App Services-planen (och välja en Tomcat-version som körningsstack) för varje WAR-fil som distribueras till Tomcat-servern.

Kommentar

Även om det är möjligt att distribuera flera WAR-filer till en enda webbapp, så är det synnerligen olämpligt. Om du distribuerar flera WAR-filer till en enda webbapp, så förhindrar du varje enskilt program från att skalas enligt dess egna användningskrav. Det ökar också komplexiteten för efterföljande distributionspipelines. Om flera program måste vara tillgängliga på samma URL bör du överväga att använda en routningslösning som Azure Application Gateway.

Maven-program

Om programmet har skapats från en Maven POM-fil, så skapa webbappen och distribuera ditt program genom att använda webbapps-plugin-programmet för Maven.

Andra program än Maven-program

Om du inte kan använda Maven-plugin-programmet måste du etablera webbappen med andra medel, som exempelvis:

När webbappen har skapats kan du distribuera programmet genom att använda någon av de tillgängliga distributionsmetoderna.

Migrera JVM-körningsalternativen

Om ditt program kräver specifika körningsalternativ, så använd den lämpligaste metoden för att ange dem.

Fyll i hemligheter

Använd Programinställningar när du ska lagra alla hemligheter som är specifika för ditt program. Om du tänker använda samma hemlighet(er) för flera program eller om du behöver detaljerade åtkomstprinciper och granskningsfunktioner, så använd Azure Key Vault i stället.

Aktivera anpassad domän SSL

Om programmet ska vara synligt i en anpassad domän måste du mappa ditt webbprogram till det. Mer information finns i Självstudie: Mappa ett befintligt anpassat DNS-namn till Azure App Service.

Sedan måste du binda SSL-certifikatet för den domänen till din App Service-webbapp. Mer information finns i Skydda ett anpassat DNS-namn med en SSL-bindning i Azure App Service.

Importera serverdelscertifikat

Alla certifikat för att kommunicera med serverdelssystem, t. ex. databaser, måste göras tillgängliga för App Service. Mer information finns i Lägga till ett SSL-certifikat i App Service.

Migrera datakällor, bibliotek och JNDI-resurser

Konfigurationsstegen för datakällan finns i avsnittet Datakällor i Konfigurera en Java-app i Linux för Azure App Service.

Mer information om datakällor finns i följande avsnitt om JNDI-datakällor i Tomcat-dokumentationen:

Migrera eventuella ytterligare klassökvägsberoenden på servernivå genom att följa samma steg som för JAR-datakällsfiler.

Migrera eventuella ytterligare delade JDNI-resurser på servernivå.

Kommentar

Om du följer den rekommenderade arkitekturen för en WAR per webbapp, så bör du överväga att migrera klassökvägsbibliotek på servernivå och JNDI-resurser till ditt program. Detta förenklar avsevärt komponentstyrningen och ändringshanteringen.

Migrera återstående konfiguration

När du har slutfört föregående avsnitt bör du ha en anpassningsbar serverkonfiguration i /home/tomcat/conf.

Slutför migreringen genom att kopiera eventuell ytterligare konfiguration (som sfärer och JASPIC)

Migrera schemalagda jobb

Om du vill köra schemalagda jobb på Azure bör du överväga att använda en Timer-utlösare för Azure Functions. Du behöver inte migrera själva jobbkoden till en funktion. Funktionen kan helt enkelt anropa en URL i ditt program för att utlösa jobbet. Om sådana jobb körningar måste anropas dynamiskt och/eller spåras centralt, bör du överväga att använda Spring Batch.

Du kan även skapa en logikapp med en upprepningsutlösare för att anropa URL:en utan att skriva någon kod utanför programmet. Mer information finns i Översikt – vad är Azure Logic Apps? och Skapa, Schemalägga och köra återkommande uppgifter och arbetsflöden med upprepningsutlösaren i Azure Logic Apps.

Kommentar

För att förhindra skadlig användning måste du förmodligen se till att jobbanropets slutpunkt kräver autentiseringsuppgifter. I det här fallet måste utlösarfunktionen ange autentiseringsuppgifterna.

Omstart- och röktest

Slutligen måste du starta om din webbapp, så att alla konfigurationsändringar tillämpas. När omstarten är klar kontrollerar du att programmet fungerar som det ska.

Efter migreringen

Nu när du har migrerat ditt program till Azure App Service bör du kontrollera att det fungerar som förväntat. När du väl har gjort detta, så har vi några rekommendationer som hjälper dig att göra ditt program mer molnanpassat.

Rekommendationer