Tomcat-alkalmazások migrálása az Azure Container Appsbe

Cikk
10/23/2023

Ez az útmutató azt ismerteti, hogy mire érdemes figyelnie, ha egy meglévő Tomcat-alkalmazást szeretne migrálni az Azure Container Apps (ACA) futtatásához.

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.

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.

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.

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 elosztott, skálázott platformmal, például ACA-val való használatra készültek. Az ACA több példány közötti terheléselosztást is betölthet, és bármikor transzparens módon újraindíthatja a példányokat, ezért nem ajánlott a rendszer számára a mutable állapot megőrzése.

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.

Különleges esetek

Bizonyos éles forgatókönyvek több módosítást igényelhetnek, vagy további korlátozásokat írhatnak elő. 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 tárolóalapú üzemelő Tomcat-példányokkal. Ha az alkalmazást horizontálisan fel van skálázva, egy ü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 használatban van-e a MemoryRealm

A MemoryRealm használatához egy megőrzött XML-fájl szükséges. Az ACA-n hozzá kell adnia ezt a fájlt a tároló lemezképéhez, vagy fel kell töltenie a tárolók számára elérhetővé tett megosztott tárolóba. (További információ: Munkamenet-megőrzési mechanizmus szakaszának azonosítása.) A pathName paramétert ennek megfelelően módosítani kell.

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.

Helyi tesztelés

Tárolólemezképek létrehozása előtt migrálja az alkalmazást az ACA-n használni kívánt JDK-ba és Tomcatbe. Az alkalmazás kompatibilitásának és teljesítményének biztosítása érdekében alaposan tesztelje az alkalmazást.

A konfiguráció paraméterezése

A migrálás előtt valószínűleg azonosítja azokat a titkos kódokat és külső függőségeket, például adatforrásokat a server.xml és a context.xml fájlban. Minden így azonosított elemnél cserélje le a felhasználónevet, a jelszót, a kapcsolati sztringet vagy az 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}"
/>

Áttelepítés

Megjegyzés:

Egyes Tomcat-környezetekben előfordulhat, hogy több alkalmazás fut egyetlen Tomcat-kiszolgálón. Ha a környezetben ez a helyzet, erősen ajánlott minden alkalmazást különálló podon futtatni. Ez lehetővé teszi, hogy minden egyes alkalmazás esetében optimalizálja az erőforrások kihasználását, miközben minimalizálja a bonyolultságot és az összekapcsolást.

Az üzembe helyezési összetevők előkészítése

Klónozza a Tomcat on Containers gyorsútmutató GitHub-adattárát. Ez az adattár dockerfile- és Tomcat-konfigurációs fájlokat tartalmaz, sok ajánlott optimalizálással. Az alábbi lépésekben bemutatjuk azokat a módosításokat, amelyekre a tárolólemezkép létrehozása és az ACA-ban való üzembe helyezés előtt valószínűleg szükség lesz ezekre a fájlokra.

JNDI-erőforrások hozzáadása

Szerkessze a server.xml fájlt a migrálás előtti lépésekben előkészített erőforrások( például adatforrások) hozzáadásához az alábbi példában látható módon:

<!-- Global JNDI resources
      Documentation at /docs/jndi-resources-howto.html
-->
<GlobalNamingResources>
    <!-- Editable user database that can also be used by
         UserDatabaseRealm to authenticate users
    -->
    <Resource name="UserDatabase" auth="Container"
              type="org.apache.catalina.UserDatabase"
              description="User database that can be updated and saved"
              factory="org.apache.catalina.users.MemoryUserDatabaseFactory"
              pathname="conf/tomcat-users.xml"
               />

    <!-- Migrated datasources here: -->
    <Resource
        name="jdbc/dbconnection"
        type="javax.sql.DataSource"
        url="${postgresdb.connectionString}"
        driverClassName="org.postgresql.Driver"
        username="${postgresdb.username}"
        password="${postgresdb.password}"
    />
    <!-- End of migrated datasources -->
</GlobalNamingResources>

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:

A lemezkép létrehozása és leküldése

A rendszerkép az ACA általi használatra legegyszerűbben a parancs használatával készíthető el és tölthető fel az az acr build Azure Container Registrybe (ACR). Ehhez a parancshoz nem szükséges, hogy a Docker telepítve legyen a számítógépen. Ha például a Dockerfile a tomcat-container-quickstart adattárból és a petclinic.war alkalmazáscsomagból származik az aktuális könyvtárban, a következő paranccsal hozhatja létre a tárolórendszerképet az ACR-ben:

az acr build \
    --registry $acrName \
    --image "${acrName}.azurecr.io/petclinic:{{.Run.ID}}" 
    --build-arg APP_FILE=petclinic.war \
    --build-arg SERVER_XML=prod.server.xml .

Ha a WAR-fájl neve ROOT.war, elhagyhatja a --build-arg APP_FILE... paramétert. Ha a kiszolgáló XML-fájljának neve server.xml, elhagyhatja a --build-arg SERVER_XML... paramétert. Mindkét fájlnak ugyanabban a könyvtárban kell lennie, mint a Dockerfile.

Másik lehetőségként a Docker CLI-vel helyileg is létrehozhatja a rendszerképet az alábbi parancsokkal. Ez a megközelítés leegyszerűsítheti a lemezképek tesztelését és finomítását az ACR-ben való kezdeti üzembe helyezés előtt. Ehhez azonban a Docker CLI-jének telepítve kell lennie, és futnia kell a Docker-démonnak.

# Build the image locally.
sudo docker build . --build-arg APP_FILE=petclinic.war -t "${acrName}.azurecr.io/petclinic:1"

# Run the image locally.
sudo docker run -d -p 8080:8080 "${acrName}.azurecr.io/petclinic:1"

# You can now access your application with a browser at http://localhost:8080.

# Sign in to ACR.
sudo az acr login --name $acrName

# Push the image to ACR.
sudo docker push "${acrName}.azurecr.io/petclinic:1"

További információ: Tárolólemezképek létrehozása és tárolása az Azure Container Registry használatával.

Üzembe helyezés az Azure Container Appsben

Az alábbi parancs egy példatelepítést mutat be:

az containerapp create \
    --resource-group <RESOURCE_GROUP> \
    --name <APP_NAME> \
    --environment <ENVIRONMENT_NAME> \
    --image <IMAGE_NAME> \
    --target-port 8080 \
    --ingress 'external' \
    --registry-server <REGISTRY_SERVER> \
    --min-replicas 1

Részletesebb rövid útmutatóért lásd : Rövid útmutató: Az első tárolóalkalmazás üzembe helyezése.

A migrálás után

Most, hogy migrálta az alkalmazást az ACA-ba, ellenőriznie kell, hogy a várt módon működik-e. Ezután az alábbi ajánlásokkal natívabbá teheti az alkalmazást a felhő számára.

Javaslatok

Tervezzen meg és implementáljon egy üzletmenet-folytonossági és vészhelyreállítási stratégiát. A kritikus fontosságú alkalmazásokhoz fontolja meg a többrégiós üzembehelyezési architektúra használatát. További információ: Ajánlott eljárások az üzletmenet-folytonossághoz és a vészhelyreállításhoz az Azure Kubernetes Service-ben (AKS).
Értékelje ki a logging.properties fájlban található elemeket. A teljesítmény javítása érdekében vegye fontolóra a naplózási kimenet egy részének megszüntetését vagy csökkentését.
A teljesítmény további optimalizálása érdekében érdemes figyelni a kódgyorsítótár méretét, és hozzáadni a paramétereket -XX:InitialCodeCacheSize és -XX:ReservedCodeCacheSize a JAVA_OPTS változót a Dockerfile-ban. További információt az Oracle-dokumentáció kódgyorsítótárak finomhangolásáról szóló szakaszában talál.
Fontolja meg az Azure Monitor riasztási szabályainak és műveleti csoportjainak hozzáadását az aberrált feltételek gyors észleléséhez és kezeléséhez.
Fontolja meg az Azure Container Apps üzembe helyezésének replikálását egy másik régióban az alacsonyabb késés, valamint a nagyobb megbízhatóság és hibatűrés érdekében. Az Azure Traffic Managerrel terheléselosztást helyezhet üzembe az üzemelő példányok között, vagy az Azure Front Door használatával SSL-kiszervezést és webalkalmazási tűzfalat adhat hozzá DDoS-védelemmel.
Ha nincs szükség georeplikációra, fontolja meg egy Azure-alkalmazás-átjáró hozzáadását az SSL-kiszervezés és a webalkalmazási tűzfal DDoS-védelemmel való hozzáadásához.