Tomcat-alkalmazások migrálása a Tomcatbe az Azure App Service-en

  • Cikk

Ez az útmutató leírja, milyen szempontokat érdemes megfontolnia, amikor egy meglévő Tomcat-alkalmazást az Azure App Service-beli futtatásra kíván migrálni a Tomcat 9.0 használatával.

A migrálás előtt

A sikeres migrálás biztosításához a kezdés előtt végezze el az alábbi szakaszokban leírt értékelési és leltározási lépéseket.

Ha a migrálás előtti követelmények egyikét sem tudja teljesíteni, tekintse meg a következő kísérő áttelepítési útmutatókat:

Váltás egy támogatott platformra

Az App Service a Tomcat specifikus verzióit nyújtja a Java specifikus verzióin. A kompatibilitás biztosítása érdekében migrálja az alkalmazást a Tomcat és a Java aktuális környezetének egyik támogatott verziójába, mielőtt továbblép a többi lépéssel. Ügyeljen arra, hogy teljes körűen tesztelje a konfigurációt. Használja a Linux-disztribúció legújabb stabil kiadását az ilyen tesztekben.

Megjegyzés:

Ez az ellenőrzés különösen fontos, ha az aktuális kiszolgáló egy nem támogatott JDK-n fut (például az Oracle JDK-n vagy az IBM OpenJ9 rendszeren).

A jelenlegi Java-verzió beszerzéséhez jelentkezzen be az éles kiszolgálóra, és futtassa a következő parancsot:

java -version

A Azure-alkalmazás szolgáltatásban a Java 8 bináris fájljait az Eclipse Temurin biztosítja. A Java 11- és 17-es verziójához, valamint a Java összes jövőbeli LTS-kiadásához az App Service biztosítja az OpenJDK Microsoft-buildet. Ezek a bináris fájlok ingyenesen letölthetők a következő webhelyeken:

A jelenlegi Tomcat-verzió beszerzéséhez jelentkezzen be az éles kiszolgálóra, és futtassa a következő parancsot:

${CATALINA_HOME}/bin/version.sh

Az Azure App Service által használt aktuális verzió beszerzéséhez töltse le a Tomcat 9-et attól függően, hogy melyik verziót kívánja használni az Azure App Service-ben.

Külső források leltározása

A külső erőforrások (például adatforrások, JMS-üzenetközvetítők és hasonlók) a Java Naming and Directory Interface-en (JNDI) keresztül injektálhatók. Az ilyen erőforrások némelyikéhez migrálásra vagy újrakonfigurálásra lehet szükség.

Az alkalmazáson belül

Vizsgálja meg a META-INF/context.xml fájlt. Keressen <Resource> elemeket a <Context> elemen belül.

Az alkalmazáskiszolgáló(ko)n

Vizsgálja meg a $CATALINA_BASE/conf/context.xml and $CATALINA_BASE/conf/server.xml fájlokat, valamint a $CATALINA_BASE/conf/[engine-name]/[host-name] könyvtár .xml kiterjesztésű fájljait.

A context.xml fájlok JNDI-erőforrásait a felső szintű <Context> elem <Resource> elemei ismertetik.

A server.xml fájlok JNDI-erőforrásait a <GlobalNamingResources> elem <Resource> elemei ismertetik.

Adatforrások

Az adatforrások olyan JNDI-erőforrások, amelyek type attribútuma javax.sql.DataSource értékre van állítva. Minden adatforráshoz jegyezze fel az alábbi adatokat:

  • Mi az adatforrás neve?
  • Milyen a kapcsolatkészlet konfigurációja?
  • Hol található a JDBC-illesztőprogram JAR-fájlja?

További információért tekintse meg a Tomcat dokumentációjának a JNDI-adatforrások használatát ismertető szakaszát.

Minden egyéb külső forrás

Ebben az útmutatóban nem tudunk dokumentálni minden lehetséges külső függőséget. Az Ön csapatának felelőssége, hogy ellenőrizze azt, hogy az alkalmazás minden külső függősége megvalósítható a migrálás után.

A leltár titkos kódjai

Jelszavak és biztonságos sztringek

Ellenőrizze az éles kiszolgáló(k) minden tulajdonságát és konfigurációs fájlját titkos sztringekhez és jelszavakhoz. Ellenőrizze a server.xml és a context.xml fájlt a $CATALINA_BASE/conf helyen. Az alkalmazásban jelszavakat vagy hitelesítő adatokat tartalmazó konfigurációs fájlok is szerepelhetnek. Ilyen a META-INF/context.xml, valamint Spring Boot-alkalmazások esetén az application.properties vagy az application.yml.

Leltártanúsítványok

Dokumentálja a nyilvános SSL-végpontokhoz vagy a háttéradatbázisokkal és más rendszerekkel való kommunikációhoz használt összes tanúsítványt. A következő parancs futtatásával megtekintheti az éles kiszolgáló(ko)n található összes tanúsítványt:

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

Határozza meg, használják-e a fájlrendszert, és ha igen, hogyan

Az alkalmazáskiszolgáló fájlrendszerének bármely használatához újrakonfigurálásra vagy bizonyos ritka esetekben architekturális módosításokra van szükség. Az alábbi forgatókönyvek némelyike vagy mindegyike igaz lehet Önre.

Csak olvasható statikus tartalom

Ha az alkalmazás jelenleg statikus tartalmat szolgáltat, szüksége lesz egy másik helyre hozzá. A statikus tartalmat célszerű az Azure Blob Storage-ba helyezni és az Azure CDN hozzáadásával biztosítani a villámgyors globális letöltést. További információ: Statikus webhely üzemeltetése az Azure Storage-ban és rövid útmutató: Azure Storage-fiók integrálása az Azure CDN-nel. A statikus tartalmat közvetlenül is üzembe helyezheti egy alkalmazáson az Azure Spring Apps Enterprise-csomagban. További információ: Webes statikus fájlok üzembe helyezése.

Dinamikusan közzétett statikus tartalom

Ha az alkalmazás engedélyezi az alkalmazás által feltöltött/előállított statikus tartalmakat, azonban a létrehozás után nem módosítható, az Azure Blob Storage és az Azure CDN fent ismertetett módon történő, egy Azure-függvénnyel közös használatával kezelheti a feltöltéseket és a CDN-frissítést. A Statikus tartalom feltöltése és CDN-előtöltése az Azure Functions szolgáltatással című témakörben megadtunk egy szabadon használható mintaimplementációt. A statikus tartalmat közvetlenül is üzembe helyezheti egy alkalmazáson az Azure Spring Apps Enterprise-csomagban. További információ: Webes statikus fájlok üzembe helyezése.

Dinamikus vagy belső tartalom

Az alkalmazás által gyakran írt és olvasott fájlok (például az ideiglenes adatfájlok) vagy a kizárólag az alkalmazás számára látható statikus fájlok esetében csatlakoztathatja az Azure Storage-ot az App Service-fájlrendszerhez. További információ: Azure Storage-tartalom kiszolgálása a Linuxos App Service-ben.

A munkamenet-megőrzési mechanizmus azonosítása

A használt munkamenetmegőrzés-kezelő azonosításához vizsgálja meg az alkalmazásban és a Tomcat konfigurációjában található context.xml fájlokat. Keresse meg a <Manager> elemet, és jegyezze fel a className attribútum értékét.

A Tomcat beépített PersistentManager-implementációi, például a StandardManager vagy a FileStore nem arra lett tervezve, hogy olyan elosztott, skálázható platformokkal használják, mint például az App Service. Mivel az App Service több példány között végez terheléselosztást, és bármely példányt bármikor transzparens módon újraindítja, a módosítható állapot fájlrendszerben való rögzítése nem ajánlott.

Ha a munkamenetek megőrzése szükséges, egy másik PersistentManager implementációt kell használnia, amely egy külső adattárba fog írni, például a VMware Tanzu Session Manager és a Redis Cache használatával. További információ: A Redis használata munkamenet-gyorsítótárként a Tomcathez.

Az éles kiszolgálókon futó összes külső folyamat és démon azonosítása

Ha rendelkezik az alkalmazáskiszolgálón kívül futó folyamatokkal, például figyelési démonokkal, ezeket el kell távolítania, vagy máshová kell migrálnia.

Különleges esetek

Bizonyos éles forgatókönyvek további módosítást igényelhetnek, vagy további korlátozásokat szabhatnak ki. Bár az ilyen forgatókönyvek ritkán fordulnak elő, fontos meggyőződni arról, hogy nem alkalmazhatók az alkalmazásra, vagy helyesen oldják fel őket.

Annak meghatározása, hogy az alkalmazás ütemezett feladatokra támaszkodik-e

Ütemezett feladatok (például Quartz Scheduler- vagy Cron-feladatok) nem használhatók az App Service-szel. Az App Service nem akadályozza meg az ütemezett feladatokat tartalmazó alkalmazások belső üzembe helyezését. Ha azonban az alkalmazást horizontálisan felskálázza, ez az ütemezett feladat ütemezett időszakonként többször is lefuthat. Ez nem várt következményekkel járhat.

Leltárazzon minden ütemezett feladatot az alkalmazáskiszolgálón belül és kívül is.

Annak meghatározása, hogy az alkalmazás tartalmaz-e az operációs rendszerre vonatkozó kódot

Ha az alkalmazás tartalmaz a gazdagép operációs rendszeréhez tartozó függőségekkel rendelkező kódot, azt Önnek újra kell bontania a függőségek eltávolításához. Előfordulhat például, hogy a File.Separator vagy Paths.get fájlrendszerbeli útvonalakkal rendelkező /- vagy \-előfordulásokat cserélnie kell.

Annak meghatározása, hogy az alkalmazás használ-e Tomcat-fürtözést

A Tomcat-fürtözés nem támogatott Azure App Service-ben. Ehelyett Tomcat-specifikus funkciók nélkül konfigurálhatja és kezelheti az Azure App Service-beli méretezést és terheléselosztást. A munkamenet-állapotot megtarthatja egy másik helyen, így elérhetővé teheti minden replikában. További információ: A munkamenet-megőrzési mechanizmus azonosítása.

Annak megállapításához, hogy az alkalmazás használ-e fürtözést, keresse meg a <Cluster> elemet a server.xml fájl <Host> vagy <Engine> elemében.

Annak meghatározása, hogy az alkalmazás használ-e nem HTTP-összekötőket

Az App Service csak egyetlen HTTP-összekötőt támogat. Ha az alkalmazáshoz további összekötők szükségesek, például az AJP-összekötő, ne használja az App Service-t.

Az alkalmazás által használt HTTP-összekötők azonosításához keressen <Connector> elemeket a Tomcat-konfiguráció server.xml fájljában.

Annak meghatározása, hogy használatban van-e a MemoryRealm

A MemoryRealm használatához egy megőrzött XML-fájl szükséges. A Azure-alkalmazás Service szolgáltatásban fel kell töltenie ezt a fájlt a /home könyvtárba vagy annak egyik alkönyvtárába, vagy a csatlakoztatott tárolóba. Ezután ennek megfelelően módosítania kell a pathName paramétert.

Annak megállapításához, hogy a MemoryRealm jelenleg használatban van-e, vizsgálja meg a server.xml és a context.xml fájlt, és keresse meg azokat a <Realm> elemeket, amelyekben a className attribútum az org.apache.catalina.realm.MemoryRealm értékre van beállítva.

Annak meghatározása, hogy használatban van-e az SSL-munkamenetek nyomon követése

Az App Service a Tomcat-futtatókörnyezeten kívül hajt végre munkamenet-kiszervezést, így nem használhat SSL-munkamenet-követést. Ehelyett használjon másik munkamenet-követési módot (COOKIE vagy URL). Ha SSL-munkamenet-követésre van szüksége, ne használja az App Service-t.

Annak meghatározása, hogy használatban van-e az AccessLogValve

Az AccessLogValve használata esetén a paramétert directory/home/LogFiles vagy annak egyik alkönyvtárát kell beállítania.

Áttelepítés

A konfiguráció paraméterezése

A migrálás előtti lépésekben valószínűleg azonosított bizonyos titkos kulcsokat és külső függőségeket, például adatforrásokat a server.xml és a context.xml fájlokban. Minden azonosított elemnél cserélje le a felhasználónevet, jelszót, kapcsolati sztring vagy URL-címet egy környezeti változóra.

Tegyük fel például, hogy a context.xml fájl a következő elemet tartalmazza:

<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$$"
/>

Ebben az esetben a következő példában látható módon módosíthatja azt:

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

Annak érdekében, hogy a paraméter-helyettesítés a telepített .war fájl META-INF mappájában található bármely context.xml fájl esetében történjen, állítsa be a környezeti változót az CATALINA_OPTS alábbi példában látható módon:

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

App Service-csomag kiépítése

Az App Service-díjszabás elérhető szolgáltatáscsomagjainak listájában válasszon ki egyet, amelynek specifikációi megfelelnek a jelenlegi éles hardvereknek, vagy meghaladják azok elvárásait.

Megjegyzés:

Ha előkészítési/Canary-alapú üzemet szeretne futtatni, vagy üzembe helyezési pontokat tervez használni, az App Service-csomagnak tartalmaznia kell az ehhez megfelelő plusz kapacitást. Java-alkalmazásokhoz Premium vagy magasabb szintű csomag használatát javasoljuk. További információ: Átmeneti környezetek beállítása az Azure App Service-ben.

Ezután hozza létre az App Service-csomagot. További információ: App Service-csomag kezelése az Azure-ban.

Webalkalmazás(ok) létrehozása és üzembe helyezése

Minden, a Tomcat-kiszolgálón üzembe helyezett WAR-fájlhoz létre kell hoznia egy webalkalmazást az App Service-csomagban (a Tomcat egyik verzióját választva futtatókörnyezeti veremnek).

Megjegyzés:

Habár több WAR-fájlt is üzembe helyezhet egyetlen webalkalmazásban, ez nagyon nem javasolt. Több WAR-fájl egyetlen webalkalmazásban való üzembe helyezése megakadályozza, hogy az alkalmazások saját használati igényeiknek megfelelően legyenek méretezhetők. Emellett összetettebbé teszi a későbbi üzembe helyezési folyamatokat is. Ha több alkalmazásnak is elérhetőnek kell lennie egyetlen URL-címen, érdemes lehet olyan útválasztási megoldást használnia, mint például az Azure Application Gateway.

Maven-alkalmazások

Ha az alkalmazása egy Maven POM-fájl alapján készült, használja a Maven webalkalmazási beépülő modulját a webalkalmazás létrehozásához és az alkalmazás üzembe helyezéséhez.

Nem Maven-alkalmazások

Ha nem tudja használni a Maven beépülő modulját, a webalkalmazást más mechanizmusokkal kell kiépítenie, például:

A webalkalmazás létrehozása után az elérhető üzembe helyezési mechanizmusok egyikével helyezze üzembe az alkalmazást.

JVM futtatókörnyezeti beállítások migrálása

Ha az alkalmazáshoz konkrét futtatókörnyezeti beállítások szükségesek, a legmegfelelőbb mechanizmussal adja meg azokat.

Titkos kulcsok feltöltése

Az alkalmazásbeállításokkal tárolhatja az alkalmazáshoz tartozó összes titkos kódot. Ha ugyanazokat a titkos kódokat szeretné használni több alkalmazáshoz, vagy részletes hozzáférési szabályzatokat és naplózási funkciókat szeretne alkalmazni, használja inkább az Azure Key Vaultot.

Egyéni tartomány és SSL konfigurálása

Ha az alkalmazás látható egy egyéni tartományban, le kell képeznie rá a webalkalmazást. További információ: Oktatóanyag: Meglévő egyéni DNS-név leképezése Azure-alkalmazás szolgáltatásra.

Ezután kötést kell létrehoznia az tartomány SSL-tanúsítványa és az App Service-webalkalmazás között. További információ: Egyéni DNS-név védelme SSL-kötéssel az Azure App Service-ben.

Háttértanúsítványok importálása

A háttérrendszerekkel (például az adatbázisokkal) való kommunikáció minden tanúsítványát elérhetővé kell tenni az App Service-ben. További információ: SSL-tanúsítvány hozzáadása az App Service-hez.

Adatforrások, könyvtárak és JNDI-erőforrások migrálása

Az adatforrás konfigurálásának lépéseiért tekintse meg az Adatforrások szakaszt a linuxos Java-alkalmazások Azure App Service-beli használatra való konfigurálását ismertető részben.

Az adatforrásokkal kapcsolatos további útmutatásért tekintse meg a Tomcat dokumentációjának alábbi, a JNDI-adatforrások használatát ismertető szakaszait:

Az adatforrások JAR-fájljaira vonatkozó lépéseket követve migráljon minden további kiszolgálószintű osztályútvonal-függőséget.

Migrálja az összes további megosztott kiszolgálói szintű JDNI-erőforrást.

Megjegyzés:

Ha webalkalmazásonként a javasolt egy WAR-fájlt használja, célszerű lehet a kiszolgálószintű osztályútvonal-könyvtárakat és JNDI-erőforrásokat az alkalmazásba migrálni. Ez jelentősen leegyszerűsíti az összetevők irányítását és a változások kezelését.

A fennmaradó konfiguráció migrálása

Az előző szakasz elvégzése után a testreszabható kiszolgálókonfiguráció elérhető a /home/tomcat/conf területen.

Fejezze be a migrálást az esetleges további konfigurációk (például a tartományok és a JASPIC) másolásával

Ütemezett feladatok migrálása

Az Azure-ban ütemezett feladatok végrehajtásához célszerű egy Azure Functions-beli időzítő eseményindítót használni. Nem kell a feladat kódját egy függvénybe migrálnia. A függvény egyszerűen meghívhat egy URL-címet az alkalmazásban a feladat aktiválásához. Ha a feladatok végrehajtását dinamikusan kell meghívni és/vagy központilag nyomon követni, célszerű a Spring Batchet használni.

Másik lehetőségként létrehozhat egy Logic Apps-alkalmazást, amely egy Recurrence eseményindítót tartalmaz, hogy meghívhassa az URL-címet anélkül, hogy az alkalmazáson kívül kódot kellene írnia. További információ: Áttekintés – Mi az Azure Logic Apps? és Ismétlődő feladatok és munkafolyamatok létrehozása, ütemezése és futtatása az Azure Logic Apps Recurrence eseményindítójával.

Megjegyzés:

A kártékony használat megelőzése érdekében valószínűleg meg kell győződnie arról, hogy a feladat meghívási végpontja megköveteli a hitelesítő adatokat. Ebben az esetben az eseményindító függvénynek meg kell adnia a hitelesítő adatokat.

Újraindítás és buildtesztelés

Utolsó lépésként újra kell indítania a webalkalmazást a konfigurációs módosítások alkalmazásához. Az újraindítást követően ellenőrizze, hogy az alkalmazás megfelelően fut-e.

A migrálás után

Now that you have your application migrated to Azure App Service you should verify that it works as you expect. Ezután az alábbi javaslatokkal natívabbá teheti az alkalmazást a felhő számára.

Javaslatok