Migrace aplikací Tomcat na Tomcat ve službě Azure App Service

  • Článek

Tato příručka popisuje, o čem byste měli vědět, když chcete migrovat existující aplikaci Tomcat tak, aby byla provozovaná ve službě Azure App Service využívající Tomcat 9.0.

Před migrací

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

Pokud nemůžete splnit žádné z těchto požadavků na předběžnou migraci, projděte si následující doprovodné příručky k migraci:

Přepnutí na podporovanou platformu

App Service nabízí konkrétní verze služby Tomcat pro konkrétní verze jazyka Java. Pokud chcete zajistit kompatibilitu, proveďte migraci aplikace do jedné z podporovaných verzí Tomcat a Javy v aktuálním prostředí, než budete pokračovat v některém ze zbývajících kroků. Výslednou konfiguraci plně otestujte. V těchto testech použijte nejnovější stabilní verzi své linuxové distribuce.

Poznámka:

Toto ověření je obzvláště důležité, pokud se váš aktuální server provozuje na nepodporované sadě JDK (například Oracle JDK nebo IBM OpenJ9).

Aktuální verzi jazyka Java získáte tak, že se přihlásíte k produkčnímu serveru a spustíte následující příkaz:

java -version

V Aplikace Azure Service jsou binární soubory pro Javu 8 poskytovány z Eclipse Temurinu. Pro Javu 11, 17 a všechny budoucí verze LTS v Javě poskytuje App Service Microsoft Build OpenJDK. Tyto binární soubory jsou k dispozici ke stažení zdarma na následujících webech:

Aktuální verzi služby Tomcat získáte tak, že se přihlásíte k produkčnímu serveru a spustíte následující příkaz:

${CATALINA_HOME}/bin/version.sh

Pokud chcete získat aktuální verzi, kterou používá Azure App Service, stáhněte Tomcat 9 podle toho, kterou verzi hodláte ve službě Azure App Service používat.

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.

Inventarizace certifikátů

Zdokumentujte všechny certifikáty používané pro veřejné koncové body SSL nebo komunikaci s back-endovými databázemi a dalšími systémy. Všechny certifikáty na produkčních serverech zobrazíte spuštěním následujícího příkazu:

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

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. Statický obsah můžete také přímo nasadit do aplikace v plánu Azure Spring Apps Enterprise. Další informace naleznete v tématu Nasazení webových statických souborů.

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. Statický obsah můžete také přímo nasadit do aplikace v plánu Azure Spring Apps Enterprise. Další informace naleznete v tématu Nasazení webových statických souborů.

Dynamický nebo interní obsah

Pro soubory, které vaše aplikace často zapisuje a čte (například dočasné datové soubory) nebo statické soubory, které jsou viditelné jen vaší aplikaci, můžete k systému souborů App Service připojit Azure Storage. Další informace najdete v článku Obsluha obsahu z Azure Storage v App Service na Linuxu.

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.

Implementace PersistentManager integrované ve službě Tomcat, například StandardManager nebo FileStore, nejsou vhodné pro použití s distribuovanou a škálovatelnou platformou, jako je App Service. Protože App Service může vyrovnávat zatížení mezi několika instancemi a kdykoli transparentně restartovat libovolnou instanci, nedoporučuje se uchovávat proměnlivý stav v systému souborů.

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. Další informace najdete v článku Použití Redis jako mezipaměti relace se službou Tomcat.

Zjištění všech vnějších procesů a démonů běžících na produkčních serverech

Pokud používáte nějaké procesy, které běží mimo aplikační server, například monitorovací démony, budete je muset eliminovat nebo migrovat jinam.

Zvláštní případy

Určité produkční scénáře mohou vyžadovat další změny nebo zavádět dodatečná 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 se službou App Service používat. App Service vám nebrání v interním nasazení aplikace obsahující naplánované úlohy. Pokud ale u aplikace dojde k horizontálnímu rozšíření kapacity, může se stejná 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, budete muset refaktorováním tyto závislosti odebrat. Pomocí File.Separator nebo Paths.get budete například muset nahradit použití znaků / nebo \ v cestách systému souborů.

Určení, jestli se používá clustering Tomcat

Clustering Tomcat není ve službě Azure App Service podporovaný. Místo toho můžete škálování a vyrovnávání zatížení nakonfigurovat a spravovat přes Azure App Service bez specifických funkcí služby Tomcat. Uchováním stavu relace v nějakém alternativním umístění ho můžete zpřístupnit replikám. Další informace najdete v části Zjištění mechanismu uchování relace.

Pokud chcete zjistit, jestli vaše aplikace používá clustering, vyhledejte element <Cluster> uvnitř elementů <Host> nebo <Engine> v souboru server.xml.

Určení, jestli se používají jiné konektory než HTTP

App Service podporuje jen jeden konektor HTTP. Pokud vaše aplikace vyžaduje další konektory, například konektor AJP, nepoužívejte App Service.

Pokud chcete zjistit konektory HTTP používané vaší aplikací, vyhledejte element <Connector> v souboru server.xml v konfiguraci služby Tomcat.

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

MemoryRealm vyžaduje uchovaný soubor XML. Na Aplikace Azure Service budete muset tento soubor nahrát do adresáře /home nebo do některého z jeho podadresářů nebo do připojeného úložiště. Potom budete muset odpovídajícím způsobem upravit pathName parametr.

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.

Určení, jestli se používá sledování relací SSL

App Service provádí snižování zátěže relací mimo modul runtime Tomcat, takže sledování relací SSL nemůžete použít. Použijte místo toho jiný režim sledování relací (COOKIE nebo URL). Pokud potřebujete sledování relací SSL, nepoužívejte App Service.

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

Pokud používáte AccessLogValve, měli byste parametr nastavit directory na /home/LogFiles nebo na některý z jeho podadresářů.

Migrace

Parametrizace konfigurace

V krocích před migrací jste pravděpodobně identifikovali některé tajné kódy a externí závislosti, jako jsou zdroje dat, v souborech server.xml a context.xml . Pro každou položku, kterou jste identifikovali, nahraďte jakékoli uživatelské jméno, heslo, připojovací řetězec nebo adresu URL proměnnou prostředí.

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

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

Pokud chcete zajistit, aby nahrazení parametrů probíhalo pro jakýkoli soubor context.xml ve složce META-INF uvnitř nasazeného souboru .war, nezapomeňte nastavit CATALINA_OPTS proměnnou prostředí, jak je znázorněno v následujícím příkladu:

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

Zřízení plánu služby App Service

V seznamu dostupných plánů služby na stránce s cenami App Service vyberte plán, jehož specifikace jsou stejné nebo vyšší, než má aktuální produkční hardware.

Poznámka:

Pokud hodláte provozovat přípravná/testovací nasazení nebo používat sloty nasazení, musí plán služby App Service zahrnovat tuto dodatečnou kapacitu. Pro aplikace Java doporučujeme používat plány Premium nebo vyšší. Další informace najdete v článku Nastavení přípravných prostředí ve službě Azure App Service.

Pak daný plán služby App Service vytvořte. Další informace najdete v článku Správa plánu služby App Service v Azure.

Vytvoření a nasazení webových aplikací

V plánu služby App Service (kde jako zásobník modulu runtime zvolíte nějakou verzi služby Tomcat) budete muset vytvořit webovou aplikaci pro každý soubor WAR nasazený na server Tomcat.

Poznámka:

I když do jedné webové aplikace je možné nasadit několik souborů WAR, je to silně nežádoucí. Nasazení několika souborů WAR do jedné webové aplikace brání škálování jednotlivých aplikací podle toho, jaká je po nich poptávka. Zvyšuje navíc složitost pro následné kanály nasazení. Pokud na jedné adrese URL musí být dostupných několik aplikací, uvažujte o použití nějakého směrovacího řešení, jako je Azure Application Gateway.

Aplikace Maven

Pokud je vaše aplikace vytvořena ze souboru Maven POM, použijte k vytvoření webové aplikace a jejímu nasazení modul plug-in WebApp pro Maven.

Jiné aplikace než Maven

Pokud modul plug-in Maven nelze použít, budete muset webovou aplikaci zřídit prostřednictvím jiných mechanismů, mezi které patří:

Po vytvoření webové aplikace použijte k jejímu nasazení některý z dostupných mechanismů nasazení.

Migrace parametrů modulu runtime JVM

Pokud vaše aplikace vyžaduje konkrétní parametry modulu runtime, použijte k jejich určení nejvhodnější mechanismus.

Naplnění tajných kódů

K uložení všech tajných kódů vaší aplikace můžete použít Nastavení aplikace. Pokud máte v úmyslu používat stejné tajné kódy v několika aplikacích nebo vyžadujete jemně odstupňované zásady přístupu a možnosti auditu, použijte místo toho Azure Key Vault.

Konfigurace vlastní domény a SSL

Pokud vaše aplikace bude viditelná ve vlastní doméně, budete k ní muset namapovat webovou aplikaci. Další informace najdete v tématu Kurz: Mapování existujícího vlastního názvu DNS na službu Aplikace Azure Service.

Potom budete muset svázat certifikát SSL dané domény s webovou aplikací App Service. Další informace najdete v tématu Zabezpečení vlastního názvu DNS s využitím vazby SSL ve službě Azure App Service.

Import back-endových certifikátů

Všechny certifikáty pro komunikaci s back-endovými systémy, jako jsou databáze, musí být službě App Service dostupné. Další informace najdete v článku, který se věnuje přidání certifikátu SSL ve službě App Service.

Migrace zdrojů dat, knihoven a prostředků JNDI

Postup konfigurace zdroje dat najdete v části věnované zdrojům dat v tématu Konfigurace linuxové aplikace pro Azure App Service.

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

Pomocí stejného postupu jako u souborů JAR zdroje dat migrujte všechny další závislosti cesty ke třídám na úrovni serveru.

Migrujte všechny další sdílené prostředky JDNI na úrovni serveru.

Poznámka:

Pokud používáte doporučenou architekturu jednoho souboru WAR na webovou aplikaci, zvažte migraci knihoven cest ke třídám na úrovni serveru a prostředků JNDI do vaší aplikace. Tím se významně zjednoduší řízení komponent a správa změn.

Migrace zbývající konfigurace

Po dokončení předchozí části byste měli mít přizpůsobenou konfiguraci serveru v adresáři /home/tomcat/conf.

Dokončete migraci zkopírováním všech dalších konfigurací (například realms a JASPIC).

Migrace naplánovaných úloh

Pokud chcete v Azure spouštět naplánované úlohy, zvažte použití triggeru časovače pro Azure Functions. Samotný kód úlohy nemusíte do funkce migrovat. Funkce může úlohu aktivovat jednoduše tak, že vyvolá adresu URL ve vaší aplikaci. Pokud musí být spouštění těchto úloh dynamicky vyvolávané a/nebo centrálně sledované, zvažte použití Spring Batch.

Alternativně můžete pro vyvolání adresy URL vytvořit aplikaci logiky s triggerem opakování, a to bez psaní kódu mimo vaši aplikaci. Další informace najdete článcích Přehled – co je služba Azure Logic Apps? a Vytvoření, plánování a spouštění opakovaných úloh a pracovních postupů pomocí triggeru opakování ve službě Azure Logic Apps.

Poznámka:

Abyste zabránili zneužití, budete pravděpodobně muset zajistit, aby koncový bod vyvolávající úlohu vyžadoval přihlašovací údaje. V takovém případě bude tyto přihlašovací údaje muset poskytovat funkce triggeru.

Restartování a orientační test

Nakonec budete muset všechny změny konfigurace uplatnit restartováním webové aplikace. Po restartování ověřte, že vaše aplikace správně funguje.

Po migraci

Teď, když je vaše aplikace migrovaná do služby Azure App Service, 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í