Migrera Tomcat-program till Tomcat på Azure App Service
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:
- Migrera Tomcat-program till containrar i Azure Kubernetes Service
- Migrera Tomcat-program till virtuella Azure-datorer (planerad guide)
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.
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.
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 Montera Azure Storage som en lokal resurs i App Service.
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 ditt program innehåller någon kod med beroenden på värdoperativsystemet måste du omstrukturera det för att ta bort dessa beroenden. Du kan till exempel behöva ersätta all användning av / eller \ i filsystemsökvägar med File.Separator eller Paths.get om programmet körs i Windows.
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 server.xml och context.xml filer. För varje objekt som du identifierade ersätter du användarnamn, lösenord, anslutningssträng eller URL med en miljövariabel.
Kommentar
Microsoft rekommenderar att du använder det säkraste tillgängliga autentiseringsflödet. Det autentiseringsflöde som beskrivs i den här proceduren, till exempel för databaser, cacheminnen, meddelanden eller AI-tjänster, kräver en mycket hög grad av förtroende för programmet och medför risker som inte finns i andra flöden. Använd endast det här flödet när säkrare alternativ, till exempel hanterade identiteter för lösenordslösa eller nyckellösa anslutningar, inte är genomförbara. För lokala datoråtgärder föredrar du användaridentiteter för lösenordslösa eller nyckellösa anslutningar.
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="{password}"
/>
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
Om du har valt att använda /home-katalogen för fillagring bör du överväga att ersätta den med Azure Storage.
Om du har konfiguration i katalogen /home som innehåller anslutningssträng, SSL-nycklar och annan hemlig information kan du överväga att använda en kombination av Azure Key Vault och/eller parameterinmatning med programinställningar där det är möjligt.
Kommentar
Microsoft rekommenderar att du använder det säkraste tillgängliga autentiseringsflödet. Det autentiseringsflöde som beskrivs i den här proceduren, till exempel för databaser, cacheminnen, meddelanden eller AI-tjänster, kräver en mycket hög grad av förtroende för programmet och medför risker som inte finns i andra flöden. Använd endast det här flödet när säkrare alternativ, till exempel hanterade identiteter för lösenordslösa eller nyckellösa anslutningar, inte är genomförbara. För lokala datoråtgärder föredrar du användaridentiteter för lösenordslösa eller nyckellösa anslutningar.
Överväg att använda distributionsfack för tillförlitliga distributioner med noll driftstopp.
Utforma och implementera en DevOps-strategi. För att bibehålla tillförlitligheten samtidigt som du ökar din utvecklingshastighet bör du överväga att automatisera distributioner och testning med Azure-pipelines. När du använder Distributionsfack kan du automatisera distributionen till ett fack följt av fackbytet.
Utforma och implementera en strategi för affärskontinuitet och haveriberedskap. För verksamhetskritiska program bör du överväga en distributionsarkitektur för flera regioner.