Sdílet prostřednictvím

Migrace aplikací Tomcat do Azure Container Apps

  • Článek

Tato příručka popisuje, o čem byste měli vědět, když chcete migrovat existující aplikaci Tomcat, která se má spouštět ve službě Azure Container Apps (ACA).

Před migrací

Pokud chcete zajistit úspěšnou migraci, dokončete kroky posouzení a inventáře popsané v následujících částech.

Inventář externích prostředků

Externí prostředky, jako jsou zdroje dat, zprostředkovatelé zpráv JMS a další, se vkládají přes rozhraní JNDI (Java Naming and Directory Interface). Některé z těchto prostředků mohou vyžadovat migraci nebo změnu konfigurace.

Ve vaší aplikaci

Prověřte soubor META-INF/context.xml. Hledejte elementy <Resource> uvnitř elementu <Context>.

Na aplikačních serverech

Prověřte soubory $CATALINA_BASE/conf/context.xml a $CATALINA_BASE/conf/server.xml a také soubory .xml v adresářích $CATALINA_BASE/conf/[název-modulu]/[název-hostitele].

V souborech context.xml budou prostředky JNDI popsány elementy <Resource> uvnitř elementu <Context> na nejvyšší úrovni.

V souborech server.xml budou prostředky JNDI popsány elementy <Resource> uvnitř elementu <GlobalNamingResources>.

Zdroje dat

Zdroje dat jsou prostředky JNDI s atributem type nastaveným na javax.sql.DataSource. U každého zdroje dat zdokumentujte následující informace:

  • Jaký je název zdroje dat?
  • Jaká je konfigurace fondu připojení?
  • Kde najdu soubor JAR ovladače JDBC?

Další informace najdete v postupech pro zdroj dat JNDI v dokumentaci k Tomcatu.

Všechny ostatní externí prostředky

V této příručce není možné zdokumentovat všechny možné externí závislosti. Je zodpovědností vašeho týmu, aby ověřil, že po migraci budou fungovat všechny externí závislosti vaší aplikace.

Inventář tajných kódů

Hesla a zabezpečené řetězce

Ve všech vlastnostech a konfiguračních souborech na produkčních serverech vyhledejte tajné řetězce a hesla. Nezapomeňte zkontrolovat soubory server.xml a context.xml v adresáři $CATALINA_BASE/conf. Konfigurační soubory obsahující hesla nebo přihlašovací údaje můžete najít také ve své aplikaci. Může jít o soubor META-INF/context.xml a soubory application.properties nebo application.yml pro aplikace Spring Boot.

Určení, jestli a jak se používá systém souborů

Jakékoli používání systému souborů na aplikačním serveru bude vyžadovat změnu konfigurace nebo ve vzácných případech změnu architektury. Můžete zjistit některé nebo všechny z následujících situací.

Statický obsah jen pro čtení

Pokud vaše aplikace aktuálně poskytuje statický obsah, budete pro ni potřebovat alternativní umístění. Možná budete chtít statický obsah přesunout do Azure Blob Storage a přidat Azure CDN, abyste umožnili bleskově rychlé globální stahování. Další informace najdete v tématu Hostování statického webu ve službě Azure Storage a rychlém startu: Integrace účtu úložiště Azure s Azure CDN.

Dynamicky publikovaný statický obsah

Pokud vaše aplikace umožňuje nahrávání nebo vytváření statického obsahu, který je ale po vytvoření neměnný, můžete použít Azure Blob Storage a Azure CDN, jak je popsáno výše, s funkcí Azure Functions, která zpracovává nahrávání a aktualizace CDN. Pro vaše použití jsme poskytli ukázkovou implementaci na GitHubu – Uploading and CDN-preloading static content with Azure Functions.

Zjištění mechanismu uchování relace

Pokud chcete zjistit, jaký správce uchování relace se používá, prohlédněte si soubory context.xml ve vaší aplikaci a konfiguraci služby Tomcat. Vyhledejte element <Manager> a poznamenejte si hodnotu atributu className.

Integrované implementace PersistentManageru, jako jsou StandardManager nebo FileStore, nejsou navržené pro použití s distribuovanou škálovanou platformou, jako je ACA. ACA může vyrovnávat zatížení mezi několika instancemi a transparentně restartovat libovolnou instanci kdykoli, takže zachování proměnlivého stavu v systému souborů se nedoporučuje.

Pokud je potřeba trvalost relace, budete muset použít alternativní PersistentManager implementaci, která bude zapisovat do externího úložiště dat, jako je například Správce relací VMware Tanzu s Redis Cache.

Zvláštní případy

Některé produkční scénáře můžou vyžadovat více změn nebo vyžadovat více omezení. I když takové scénáře můžou být občasné, je důležité zajistit, aby byly pro vaši aplikaci nepoužitelné nebo správně vyřešené.

Určení, jestli aplikace využívá naplánované úlohy

Naplánované úlohy, jako jsou úlohy plánovače Quartz nebo cron, nelze s kontejnerizovanými nasazeními Tomcat používat. Pokud u aplikace dojde k horizontálnímu rozšíření kapacity, může se jedna naplánovaná úloha spustit v průběhu naplánovaného období více než jednou. Tato situace může vést k nezamýšleným důsledkům.

Proveďte inventarizaci všech naplánovaných úloh uvnitř nebo vně aplikačního serveru.

Určení, jestli aplikace obsahuje kód specifický pro operační systém

Pokud vaše aplikace obsahuje jakýkoli kód se závislostmi na hostitelském operačním systému, musíte ho refaktorovat, abyste tyto závislosti odebrali. Může být například nutné nahradit jakékoli použití / cest systému souborů nebo \ v cestě File.Separator k systému souborů nebo Paths.get v případě, že je vaše aplikace spuštěná ve Windows.

Určení, jestli se používá MemoryRealm

MemoryRealm vyžaduje uchovaný soubor XML. V ACA budete muset tento soubor přidat do image kontejneru nebo ho nahrát do sdíleného úložiště, které je zpřístupněno kontejnerům. (Další informace najdete v tématu Identifikace oddílu mechanismu trvalosti relace.) Parametr pathName se bude muset odpovídajícím způsobem upravit.

Pokud chcete zjistit, jestli se aktuálně používá MemoryRealm, prohlédněte si soubory server.xml a context.xml a hledejte elementy <Realm>, jejichž atribut className je nastavený na org.apache.catalina.realm.MemoryRealm.

Místní testování

Před vytvořením imagí kontejneru migrujte aplikaci do sady JDK a Tomcat, které chcete používat v ACA. Pečlivě otestujte kompatibilitu a výkon aplikace.

Parametrizace konfigurace

Před migrací jste v souborech server.xml a context.xml pravděpodobně zjistili tajné kódy a externí závislosti, například zdroje dat. U každé takto zjištěné položky nahraďte uživatelské jméno, heslo, připojovací řetězec nebo adresu URL nějakou proměnnou prostředí.

Poznámka:

Microsoft doporučuje používat nejbezpečnější dostupný tok ověřování. Tok ověřování popsaný v tomto postupu, například pro databáze, mezipaměti, zasílání zpráv nebo služby AI, vyžaduje velmi vysoký stupeň důvěryhodnosti v aplikaci a nese rizika, která nejsou přítomna v jiných tocích. Tento tok používejte pouze v případě, že nejsou možné zabezpečit možnosti, jako jsou spravované identity pro připojení bez hesla nebo bez klíčů. V případě místních operací počítačů upřednostňujete identity uživatelů pro připojení bez hesla nebo bez klíčů.

Dejme tomu, že soubor context.xml obsahuje následující 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}"
/>

V tomto případě ho můžete změnit tak, jak je znázorněno v následujícím příkladu:

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

Migrace

Poznámka:

V některých nasazeních Tomcat může na jednom serveru Tomcat běžet několik aplikací. Pokud je to případ vašeho nasazení, důrazně doporučujeme provozovat každou aplikaci v samostatném podu. To vám umožní optimalizovat využití prostředků pro jednotlivé aplikace a zároveň minimalizovat složitost a provázanost.

Příprava artefaktů nasazení

Naklonujte úložiště GitHub pro rychlé zprovoznění Tomcat ve službě Containers. Toto úložiště obsahuje konfigurační soubory Dockerfile a Tomcat s mnoha doporučenými optimalizacemi. V následujících krocích si ukážeme úpravy, které budete pravděpodobně muset provést v těchto souborech před sestavením image kontejneru a nasazením do ACA.

Přidání prostředků JNDI

Upravte server.xml a přidejte prostředky, které jste připravili v krocích před migrací, jako jsou zdroje dat, jak je znázorněno v následujícím příkladu:

Poznámka:

Microsoft doporučuje používat nejbezpečnější dostupný tok ověřování. Tok ověřování popsaný v tomto postupu, například pro databáze, mezipaměti, zasílání zpráv nebo služby AI, vyžaduje velmi vysoký stupeň důvěryhodnosti v aplikaci a nese rizika, která nejsou přítomna v jiných tocích. Tento tok používejte pouze v případě, že nejsou možné zabezpečit možnosti, jako jsou spravované identity pro připojení bez hesla nebo bez klíčů. V případě místních operací počítačů upřednostňujete identity uživatelů pro připojení bez hesla nebo bez klíčů.

<!-- 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>

Další pokyny pro zdroje dat najdete v následujících částech postupů pro zdroj dat JNDI v dokumentaci k Tomcatu:

Sestavení a nahrání image

Nejjednodušší způsob, jak sestavit a nahrát image do služby Azure Container Registry (ACR) pro použití službou ACA, je použít az acr build tento příkaz. Tento příkaz nevyžaduje, abyste na svém počítači měli nainstalovaný Docker. Pokud například máte soubor Dockerfile z úložiště tomcat-container-quickstart a balíček aplikace petclinic.war v aktuálním adresáři, můžete image kontejneru sestavit v ACR pomocí následujícího příkazu:

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 .

Pokud má soubor WAR název ROOT.war, můžete parametr --build-arg APP_FILE... vynechat. Pokud má soubor XLM serveru název server.xml, můžete parametr --build-arg SERVER_XML... vynechat. Oba soubory musí být ve stejném adresáři jako soubor Dockerfile.

Alternativně můžete pomocí rozhraní příkazového řádku Dockeru sestavit image místně pomocí následujících příkazů. Tento přístup může zjednodušit testování a doladění image před počátečním nasazením v ACR. Vyžaduje ale instalaci rozhraní příkazového řádku Dockeru a spuštěného démona Dockeru.

# 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"

Další informace najdete v tématu Vytváření a ukládání imagí kontejnerů pomocí služby Azure Container Registry.

Nasazení do Azure Container Apps

Následující příkaz ukazuje ukázkové nasazení:

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

Podrobnější rychlý start najdete v tématu Rychlý start: Nasazení první aplikace typu kontejner.

Po migraci

Teď, když jste migrovali aplikaci do ACA, byste měli ověřit, že funguje podle očekávání. Až to uděláte, máme pro vás několik doporučení, která vaší aplikaci dodají výraznější nativní cloudový charakter.

Doporučení

  • Navrhněte a implementujte strategii provozní kontinuity a zotavení po havárii. U nepostradatelných aplikací zvažte architekturu nasazení ve více oblastech. Další informace najdete v tématu Osvědčené postupy pro provozní kontinuitu a zotavení po havárii ve službě Azure Kubernetes Service (AKS).

  • Vyhodnoťte položky v souboru logging.properties. Kvůli zvýšení výkonu zvažte odstranění nebo omezení některých výstupů protokolu.

  • Zvažte monitorování velikosti mezipaměti kódu a přidání parametrů -XX:InitialCodeCacheSize a -XX:ReservedCodeCacheSize JAVA_OPTS proměnné v souboru Dockerfile za účelem další optimalizace výkonu. Další informace najdete v tématu věnovaném ladění mezipaměti kódu v dokumentaci Oracle.

  • Zvažte přidání pravidel upozornění a skupin akcí služby Azure Monitor pro rychlé zjišťování a řešení chybových podmínek.

  • Zvažte replikaci nasazení Azure Container Apps v jiné oblasti, aby se snížila latence a vyšší spolehlivost a odolnost proti chybám. Pomocí Azure Traffic Manageru můžete vyrovnávat zatížení mezi nasazeními nebo pomocí služby Azure Front Door přidat přesměrování zpracování SSL a firewall webových aplikací s ochranou před útoky DDoS.

  • Pokud geografická replikace není nutná, zvažte přidání brány Aplikace Azure lication, která přidá přesměrování zpracování SSL a firewall webových aplikací s ochranou před útoky DDoS.