Tomcat-alkalmazások migrálása Azure Kubernetes Service-beli tárolókba

  • Cikk

Ez az útmutató bemutatja a megfontolandó szempontokat egy meglévő Tomcat-alkalmazás migrálásához és az Azure Kubernetes Service- (AKS-) beli 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.

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 állandó kötetként csatlakoztathatók Azure Storage-megosztások. További információért lásd: Tartós kötet dinamikus létrehozása és használata Azure-fájlokkal az Azure Kubernetes 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 a Kubernetes. Az AKS több pod között végez terheléselosztást, és bármely podot 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.

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. Habár ezek a forgatókönyvek ritkán fordulnak elő, fontos, hogy meggyőződjön arról, hogy ne forduljanak elő az alkalmazásával, vagy ha igen, megfelelően feloldja ő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 olyan kódot tartalmaz, amely az alkalmazást futtató operációs rendszerre vonatkozik, az alkalmazást újra kell bontani úgy, hogy NE támaszkodjon a mögöttes operációs rendszerre. Előfordulhat például, hogy a rendszerelérési útvonalakban a / vagy \ jeleket például File.Separator vagy Path.get elemre kell cserélni.

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 Kubernetes szolgáltatásban ezt a fájlt hozzá kell adni a tárolólemezképhez, vagy fel kell tölteni a tárolók számára elérhetővé tett megosztott tárhelyre. A pathName paramétert ennek megfelelően kell módosítani.

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

A tárolóalapú üzemelő példányokban az SSL-munkamenetek jellemzően az alkalmazástárolón kívülre vannak kiürítve, általában a bejövőforgalom-vezérlővel. Ha az alkalmazáshoz az SSL-munkamenetek nyomon követése szükséges, győződjön meg arról, hogy az SSL-forgalom közvetlenül az alkalmazástárolón át van továbbítva.

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

Ha az AccessLogValve használatban van, a directory paramétert egy csatlakoztatott Azure Files-megosztásra vagy annak egyik alkönyvtárára kell beállítani.

Helyi tesztelés

Tárolólemezképek létrehozása előtt migrálja az alkalmazást arra a JDK-ra és Tomcatre, amelyet az AKS-ben kíván használni. 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

Az első lépés („A tárolóregisztrációs adatbázis és az AKS kiépítése”) kivételével ajánlott külön-külön követni a lenti lépéseket minden migrálni kívánt alkalmazás (WAR-fájl) esetében.

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.

A tárolóregisztrációs adatbázis és az AKS kiépítése

Hozzon létre egy tárolóregisztrációs adatbázist, és egy Azure Kubernetes-fürtöt, amelynek szolgáltatásneve az Olvasó szerepkörrel rendelkezik a regisztrációs adatbázisban. Ügyeljen arra, hogy megfelelő hálózati modellt válasszon a fürt hálózati követelményeihez.

az group create \
    --resource-group $resourceGroup \
    --location eastus
az acr create \
    --resource-group $resourceGroup \
    --name $acrName \
    --sku Standard
az aks create \
    --resource-group $resourceGroup \
    --name $aksName \
    --attach-acr $acrName \
    --network-plugin azure

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

Klónozza a Tomcat tárolókban való használatára vonatkozó gyorsútmutató GitHub-adattárát. Ez egy Dockerfile-t és Tomcat-konfigurációs fájlokat tartalmaz számos javasolt optimalizációval. A lenti lépésekben felvázoljuk azokat a módosításokat, amelyeket valószínűleg el kell végeznie ezekben a fájlokban a tárolólemezkép létrehozása és az AKS-ben való üzembe helyezése előtt.

Portok megnyitása a fürtözéshez, ha szükséges

Ha Tomcat-fürtözést kíván használni az AKS-ben, győződjön meg arról, hogy a szükséges porttartomány közzé van téve a Dockerfile-ban. A kiszolgáló IP-címének a server.xml fájlban való megadásához ügyeljen arra, hogy egy olyan változó értékét használja, amely a tároló indításakor a pod IP-címére van inicializálva.

Másik lehetőségként a munkamenet-állapot is rögzíthető egy eltérő helyen, hogy minden replika számára elérhető legyen.

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.

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

Szerkessze a server.xml fájlt, és adja hozzá a migrálást megelőző lépésekben előkészített erőforrásokat, például az adatforrásokat.

Például:

<!-- 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 legegyszerűbben az az acr build parancs használatával hozhatja létre a lemezképet és töltheti fel az Azure Container Registrybe (az ACR-be) az AKS általi használatra. Ehhez a parancshoz nem szükséges, hogy a Docker telepítve legyen a számítógépen. Ha például a fenti Dockerfile és a petclinic.war alkalmazáscsomag az aktuális könyvtárban van, akkor egy lépéssel létrehozhatja a tárolólemezképét az ACR-ben:

az acr build \
    --image "${acrName}.azurecr.io/petclinic:{{.Run.ID}}" \
    --registry $acrName \
    --build-arg APP_FILE=petclinic.war \
    --build-arg=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-jével is létrehozhatja a lemezképet helyileg. 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"

# Your application can now be accessed with a browser at http://localhost:8080.

# Log into ACR
sudo az acr login --name $acrName

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

További információ: Learn modul tárolórendszerképek azure-beli létrehozásához és tárolásához.

Nyilvános IP-cím kiosztása

Ha az alkalmazásnak elérhetőnek kell lennie kívülről, illetve a belső vagy a virtuális hálózat(ok)ból, szükség lesz egy nyilvános statikus IP-címre. Ezt az IP-címet a fürt csomópontjának erőforráscsoportjában kell kiosztani.

export nodeResourceGroup=$(az aks show \
    --resource-group $resourceGroup \
    --name $aksName \
    --query 'nodeResourceGroup' \
    --output tsv)
export publicIp=$(az network public-ip create \
    --resource-group $nodeResourceGroup \
    --name applicationIp \
    --sku Standard \
    --allocation-method Static \
    --query 'publicIp.ipAddress' \
    --output tsv)
echo "Your public IP address is ${publicIp}."

Üzembe helyezés az AKS-ben

Hozza létre és alkalmazza a Kubernetes YAML-fájlját vagy -fájljait. Ha külső terheléselosztót hoz létre (akár az alkalmazáshoz, akár egy bejövőforgalom-vezérlőhöz), mindenképpen az előző szakaszban kiosztott IP-címet adja meg LoadBalancerIP értékként.

Az externalizált paramétereket környezeti változókként adja meg. Ne adjon meg titkos kódokat (például jelszavakat, API-kulcsokat és JDBC-kapcsolati sztringeket). A titkos kulcsokkal A KeyVault FlexVolume-kötet konfigurálása című szakasz foglalkozik.

Állandó tároló konfigurálása

Ha az alkalmazás permanens tárolót igényel, állítson be egy vagy több tartós kötetet.

Érdemes lehet a tartós kötetet a Tomcat-naplók könyvtárához (/tomcat_logs) csatlakoztatott Azure Files szolgáltatással létrehozni a naplók központi megőrzése érdekében. További információért lásd: Tartós kötet dinamikus létrehozása és használata az Azure Files-zal az Azure Kubernetes Service (AKS) szolgáltatásban.

A KeyVault FlexVolume-kötet konfigurálása

Hozzon létre egy Azure KeyVault-kulcstartót, és töltse fel az összes szükséges titkos kódot. Ezután konfiguráljon egy KeyVault FlexVolume-kötetet, hogy ezek a titkos kódok elérhetők legyenek a podok számára.

A tanúsítványok a tárolóban lévő helyi kulcstárba történő importálásához módosítania kell az indítási szkriptet (startup.sh a Tomcat on Containers GitHub-adattárban).

Ütemezett feladatok migrálása

Az AKS-fürtön ütemezett feladatok végrehajtásához szükség szerint definiáljon Cron-feladatokat.

A migrálás után

Most, hogy migrálta az alkalmazást az AKS-be, 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.