Migrace aplikací Tomcat do kontejnerů ve službě Azure Kubernetes 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á v kontejneru služby Azure Kubernetes Service (AKS).

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. 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 připojit sdílené složky Azure Storage jako trvalé svazky. Další informace najdete v článku Dynamické vytváření a používání trvalého svazku s Azure Files ve službě Azure Kubernetes Service.

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 Kubernetes. Protože AKS může vyrovnávat zatížení mezi několika pody a kdykoli transparentně restartovat libovolný pod, 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.

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 nebývají časté, je důležité ověřit, že se vaší aplikace netýkají, a pokud ano, je třeba je správně vyřešit.

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, který je přizpůsobený operačnímu systému, na kterém tato aplikace běží, musí se refaktorovat tak, aby NESPOLÉHALA na podkladový operační systém. Například znaky / nebo \ použité v cestách systému souborů je potřeba nahradit pomocí File.Separator nebo Path.get.

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

MemoryRealm vyžaduje uchovaný soubor XML. V Kubernetes se tento soubor bude muset přidat do image kontejneru nebo nahrát do sdíleného úložiště, které je přístupné kontejnerům. Parametr pathName bude potřeba odpovídajícím způsobem změnit.

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

U kontejnerizovaných nasazení se zatížení relací SSL zpravidla snižuje mimo kontejner aplikace, většinou pomocí kontroleru příchozího přenosu dat. Pokud vaše aplikace vyžaduje sledování relací SSL, zajistěte, aby provoz SSL procházel přímo do kontejneru aplikace.

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

Pokud se používá AccessLogValve, měl by být parametr directory nastavený na připojené sdílené složky Azure Files nebo na některý z jejich podadresářů.

Místní testování

Před vytvořením imagí kontejneru migrujte aplikaci do služeb JDK a Tomcat, které máte v plánu používat na AKS. 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í.

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

Migrace

S výjimkou prvního kroku (Zřízení registru kontejnerů a AKS) doporučujeme u každé aplikace (souboru WAR), kterou chcete migrovat, použít následující postup.

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.

Zřízení registru kontejnerů a AKS

Vytvořte registr kontejnerů a cluster Azure Kubernetes, jehož instanční objekt má v registru roli Čtenář. Nezapomeňte zvolit vhodný model sítě pro požadavky na síť vašeho clusteru.

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

Příprava artefaktů nasazení

Naklonujte úložiště GitHubu s názvem Tomcat On Containers Quickstart. Obsahuje konfigurační soubory Dockerfile a Tomcat s množstvím doporučených optimalizací. V následujícím postupu ukazujeme změny, které nejspíše budete muset v těchto souborech udělat před sestavením image kontejneru a nasazením do AKS.

Otevření portů pro clustering (pokud se vyžaduje)

Pokud máte v úmyslu používat v AKS clustering Tomcat, zajistěte, aby byly v souboru Dockerfile zpřístupněny potřebné rozsahy portů. Pokud chcete v souboru server.xml zadat IP adresu serveru, použijte hodnotu z proměnné, která se při spuštění kontejneru inicializuje na IP adresu podu.

Stav relace můžete případně uchovat v alternativním umístění, aby byl k dispozici replikám.

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

Přidání prostředků JNDI

Úpravou souboru server.xml přidejte prostředky, které jste připravili v krocích před migrací, například zdroje dat.

Příklad:

<!-- 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 sestavení a nahrání image do Azure Container Registry (ACR) tak, aby ji mohla používat služba AKS, spočívá v použití příkazu az acr build. Tento příkaz nevyžaduje, abyste na svém počítači měli nainstalovaný Docker. Pokud máte například předchozí soubor Dockerfile a balíček aplikace petclinic.war v aktuálním adresáři, můžete image kontejneru v ACR sestavit v jednom kroku:

az acr build \
    --image "${acrName}.azurecr.io/petclinic:{{.Run.ID}}" \
    --registry $acrName \
    --build-arg APP_FILE=petclinic.war \
    --build-arg=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.

K místnímu sestavení image můžete také použít rozhraní příkazového řádku Dockeru. 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"

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

Další informace najdete v modulu Learn pro vytváření a ukládání imagí kontejnerů v Azure.

Zřízení veřejné IP adresy

Pokud má být vaše aplikace přístupná mimo interní nebo virtuální sítě, bude vyžadována veřejná statická IP adresa. Tato IP adresa by měla být zřízena ve skupině prostředků uzlu clusteru.

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

Nasazení do AKS

Vytvořte a použijte soubory YAML pro Kubernetes. Pokud vytváříte externí nástroj pro vyrovnávání zatížení (pro aplikaci nebo kontroler příchozího přenosu dat), jako LoadBalancerIP zadejte IP adresu zřízenou v předchozí části.

Externalizované parametry zahrňte jako proměnné prostředí. Nezahrnujte tajné kódy (například hesla, klíče rozhraní API a připojovací řetězce JDBC). Tajné kódy jsou probrané v části Konfigurace svazku FlexVolume ve službě KeyVault.

Konfigurace trvalého úložiště

Pokud vaše aplikace vyžaduje jiné než nestálé úložiště, nakonfigurujte minimálně jeden trvalý svazek.

Kvůli centrálnímu ukládání protokolů můžete vytvořit trvalý svazek pomocí souborů Azure Files připojených k adresáři protokolu Tomcat (/tomcat_logs). Další informace najdete v článku Dynamické vytváření a používání trvalého svazku s Azure Files ve službě Azure Kubernetes Service (AKS).

Konfigurace svazku FlexVolume služby Key Vault

Vytvořte trezor klíčů Azure a naplňte všechny potřebné tajné kódy. Pak nakonfigurujte svazek FlexVolume služby KeyVault tak, aby tyto tajné kódy byly přístupné podům.

Aby se certifikáty naimportovaly do místního úložiště klíčů v kontejneru, budete muset změnit spouštěcí skript (startup.sh v úložišti GitHubu s názvem Tomcat on Containers).

Migrace naplánovaných úloh

Pro spouštění naplánovaných úloh v clusteru AKS definujte podle potřeby úlohy Cron.

Po migraci

Teď, když je vaše aplikace migrovaná do AKS, 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.