Delen via

Tomcat-toepassingen migreren naar Azure Container Apps

  • Artikel

In deze handleiding wordt beschreven waar u rekening mee moet houden wanneer u een bestaande Tomcat-toepassing wilt migreren die moet worden uitgevoerd in Azure Container Apps (ACA).

Premigratie

Voltooi voordat u begint de evaluatie- en inventarisstappen die in de volgende secties worden beschreven om een geslaagde migratie te garanderen.

Externe resources inventariseren

Externe resources, zoals gegevensbronnen, JMS-berichtenbrokers en andere resources, worden ingevoerd via Java Naming and Directory Interface (JNDI). Voor sommige resources kan migratie of herconfiguratie vereist zijn.

Binnen uw toepassing

Inspecteer het bestand META-INF/context.xml. Zoek naar <Resource>-elementen in het <Context>-element.

Op de toepassingsserver(s)

Inspecteer de bestanden $CATALINA_BASE/conf/context.xml en $CATALINA_BASE/conf/server.xml en de .xml bestanden in $CATALINA_BASE/conf/<engine-name>/<hostnaam> mappen.

In context.xml-bestanden worden JNDI-resources beschreven door de <Resource>-elementen binnen het <Context>-element op het hoogste niveau.

In server.xml-bestanden worden JNDI-resources beschreven door de <Resource>-elementen binnen het <GlobalNamingResources>-element.

Gegevensbronnen

Gegevensbronnen zijn JNDI-resources waarvoor het kenmerk type is ingesteld op javax.sql.DataSource. Documenteer voor elke gegevensbron de volgende informatie:

  • Wat is de naam van de gegevensbron?
  • Wat is de configuratie van de verbindingsgroep?
  • Waar vind ik het JAR-bestand van het JDBC-stuurprogramma?

Raadpleeg JNDI Datasource HOW-TO in de Tomcat-documentatie.

Alle andere externe resources

Het is niet haalbaar om alle mogelijke externe afhankelijkheden in deze handleiding te documenteren. Het is de verantwoordelijkheid van uw team om alle externe afhankelijkheden van uw toepassing te verifiëren na de migratie.

Geheimen inventariseren

Wachtwoorden en beveiligde tekenreeksen

Controleer alle eigenschaps- en configuratiebestanden op de productieserver(s) op geheime tekenreeksen en wachtwoorden. Controleer in elk geval server.xml en context.xml in $CATALINA_BASE/conf. U kunt ook configuratiebestanden met wachtwoorden of referenties in uw toepassing aantreffen. Het kan gaan om de bestanden META-INF/context.xml en, voor Spring Boot-toepassingen, application.properties of application.yml.

Nagaan of en hoe het bestandssysteem wordt gebruikt

Voor het gebruik van het bestandssysteem op de toepassingsserver is herconfiguratie vereist of zijn in zeldzame gevallen architectuurwijzigingen vereist. U kunt enkele of elk van de volgende scenario's identificeren.

Statische alleen-lezeninhoud

Als uw toepassing momenteel met statische inhoud werkt, hebt u hiervoor een alternatieve locatie nodig. U kunt statische inhoud verplaatsen naar Azure Blob Storage en Azure CDN toevoegen voor razendsnelle downloads wereldwijd. Zie statische websitehosting in Azure Storage en quickstart: Een Azure-opslagaccount integreren met Azure CDN voor meer informatie.

Dynamisch gepubliceerde statische inhoud

Als uw toepassing statische inhoud toestaat die wordt geüpload/geproduceerd door uw toepassing, maar onveranderbaar is nadat deze is gemaakt, kunt u Azure Blob Storage en Azure CDN gebruiken zoals hierboven beschreven, met een Azure-functie om uploads en CDN-vernieuwing te verwerken. U vindt een voorbeeldimplementatie voor gebruik in Statische inhoud uploaden en via CDN vooraf laden met Azure Functions.

Methode voor de sessiepersistentie bepalen

Controleer de context.xml-bestanden in uw toepassing en Tomcat-configuratie om te bepalen welk sessiepersistentiebeheer wordt gebruikt. Ga naar het element <Manager> en noteer de waarde van het kenmerk className.

De ingebouwde PersistentManager-implementaties van Tomcat, zoals StandardManager of FileStore, zijn niet ontworpen voor gebruik met een gedistribueerd, geschaald platform zoals ACA. ACA kan een taakverdeling tussen verschillende exemplaren uitvoeren en elk exemplaar op elk gewenst moment transparant opnieuw opstarten, zodat de onveranderbare status van een bestandssysteem niet wordt aanbevolen.

Als sessiepersistentie vereist is, moet u een alternatieve PersistentManager implementatie gebruiken die naar een extern gegevensarchief schrijft, zoals VMware Tanzu Session Manager met Redis Cache.

Speciale gevallen

Voor bepaalde productiescenario's zijn mogelijk meer wijzigingen vereist of worden er meer beperkingen opgelegd. Hoewel dergelijke scenario's incidenteel kunnen zijn, is het belangrijk om ervoor te zorgen dat deze niet van toepassing zijn op uw toepassing of correct zijn opgelost.

Bepalen of de toepassing gebruikmaakt van geplande taken

Geplande taken, zoals Quartz Scheduler-taken of Cron-taken, kunnen niet worden gebruikt met in containers geplaatste Tomcat-implementaties. Als uw toepassing wordt uitgeschaald, kan één geplande taak meer dan één keer per geplande periode worden uitgevoerd. Deze situatie kan tot onbedoelde gevolgen leiden.

Maak een inventaris van de geplande taken binnen of buiten de toepassingsserver.

Bepalen of uw toepassing code bevat die specifiek is voor het besturingssysteem

Als uw toepassing code bevat met afhankelijkheden van het host-besturingssysteem, moet u deze herstructureren om deze afhankelijkheden te verwijderen. U moet bijvoorbeeld het gebruik van / of \ in bestandssysteempaden vervangen door File.Separator of Paths.get als uw toepassing wordt uitgevoerd in Windows.

Bepalen of MemoryRealm wordt gebruikt

Voor MemoryRealm is een persistent XML-bestand vereist. In ACA moet u dit bestand toevoegen aan de containerinstallatiekopieën of uploaden naar gedeelde opslag die beschikbaar wordt gesteld aan containers. (Zie voor meer informatie de Sectie sessiepersistentiemechanisme identificeren.) De pathName parameter moet dienovereenkomstig worden gewijzigd.

Als u wilt bepalen of MemoryRealm op het huidige moment wordt gebruikt, controleert u de bestanden server.xml en context.xml en zoekt u naar <Realm>-elementen waarbij het kenmerk className is ingesteld op org.apache.catalina.realm.MemoryRealm.

In-place tests

Voordat u containerinstallatiekopieën maakt, migreert u uw toepassing naar de JDK en Tomcat die u op ACA wilt gebruiken. Test uw toepassing grondig op compatibiliteit en prestaties.

De configuratie parameteriseren

In de fase voorafgaand aan de migratie hebt u waarschijnlijk de geheimen en externe afhankelijkheden geïdentificeerd, zoals gegevensbronnen, in de bestanden server.xml en context.xml. Vervang voor elk item dat als zodanig is geïdentificeerd de gebruikersnaam, het wachtwoord, de verbindingsreeks of URL door een omgevingsvariabele.

Notitie

Microsoft raadt aan de veiligste verificatiestroom te gebruiken die beschikbaar is. De verificatiestroom die in deze procedure wordt beschreven, zoals voor databases, caches, berichten of AI-services, vereist een zeer hoge mate van vertrouwen in de toepassing en brengt risico's met zich mee die niet aanwezig zijn in andere stromen. Gebruik deze stroom alleen wanneer veiligere opties, zoals beheerde identiteiten voor wachtwoordloze of sleutelloze verbindingen, niet haalbaar zijn. Voor bewerkingen van lokale machines geeft u de voorkeur aan gebruikersidentiteiten voor verbindingen zonder wachtwoord of sleutelloze verbindingen.

Stel bijvoorbeeld dat het bestand context.xml het volgende element bevat:

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

In dat geval kunt u dit wijzigen zoals wordt weergegeven in het volgende voorbeeld:

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

Migratie

Notitie

In sommige Tomcat-implementaties worden mogelijk meerdere toepassingen uitgevoerd op één Tomcat-server. Als dit het geval is in uw implementatie, wordt het ten zeerste aanbevolen elke toepassing uit te voeren in een afzonderlijke pod. Zo kunt u het resourcegebruik voor elke toepassing optimaliseren en tegelijkertijd de complexiteit en koppeling minimaliseren.

De implementatieartefacten voorbereiden

Kloon de Tomcat on Containers Quickstart GitHub-opslagplaats. Deze opslagplaats bevat een Dockerfile- en Tomcat-configuratiebestanden met veel aanbevolen optimalisaties. In de onderstaande stappen worden wijzigingen beschreven die u waarschijnlijk moet aanbrengen in deze bestanden voordat u de containerinstallatiekopieën bouwt en implementeert in ACA.

JNDI-resources toevoegen

Bewerk server.xml om de resources toe te voegen die u hebt voorbereid in de stappen vóór de migratie, zoals gegevensbronnen, zoals wordt weergegeven in het volgende voorbeeld:

Notitie

Microsoft raadt aan de veiligste verificatiestroom te gebruiken die beschikbaar is. De verificatiestroom die in deze procedure wordt beschreven, zoals voor databases, caches, berichten of AI-services, vereist een zeer hoge mate van vertrouwen in de toepassing en brengt risico's met zich mee die niet aanwezig zijn in andere stromen. Gebruik deze stroom alleen wanneer veiligere opties, zoals beheerde identiteiten voor wachtwoordloze of sleutelloze verbindingen, niet haalbaar zijn. Voor bewerkingen van lokale machines geeft u de voorkeur aan gebruikersidentiteiten voor verbindingen zonder wachtwoord of sleutelloze verbindingen.

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

Raadpleeg de volgende gedeelten van JNDI Datasource How-To in de Tomcat-documentatie voor aanvullende gegevensbroninstructies:

De installatiekopie bouwen en pushen

De eenvoudigste manier om de installatiekopieën te bouwen en te uploaden naar Azure Container Registry (ACR) voor gebruik door ACA, is door de az acr build opdracht te gebruiken. Voor deze opdracht hoeft Docker niet op uw computer geïnstalleerd te zijn. Als u bijvoorbeeld de Dockerfile uit de opslagplaats tomcat-container-quickstart en het toepassingspakket petclinic.war in de huidige map hebt, kunt u de containerinstallatiekopie in ACR bouwen met de volgende opdracht:

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 .

U kunt de parameter --build-arg APP_FILE... weglaten als uw WAR-bestand de naam ROOT.war heeft. U kunt de parameter --build-arg SERVER_XML... weglaten als uw XML-bestand de naam server.xml heeft. Beide bestanden moeten zich in dezelfde map als Dockerfile bevinden.

U kunt ook Docker CLI gebruiken om de installatiekopieën lokaal te bouwen met behulp van de volgende opdrachten. Met deze aanpak kunt u het testen en verfijnen van de installatiekopie voorafgaand aan de initiële implementatie in ACR vereenvoudigen. Hiervoor moet Docker CLI zijn geïnstalleerd en de Docker-daemon actief zijn.

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

Zie Containerinstallatiekopieën bouwen en opslaan met Azure Container Registry voor meer informatie.

Implementeren in Azure Container Apps

De volgende opdracht toont een voorbeeldimplementatie:

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

Zie Quickstart: Uw eerste container-app implementeren voor een uitgebreidere quickstart.

Postmigratie

Nu u uw toepassing naar ACA hebt gemigreerd, moet u controleren of deze werkt zoals verwacht. Wanneer u dat gedaan hebt, hebben we enkele aanbevelingen voor u aan de hand waarvan u de toepassing geschikter kunt maken voor de cloud.

Aanbevelingen

  • Ontwerp en implementeer een strategie voor bedrijfscontinuïteit en herstel na noodgevallen. Voor bedrijfskritische toepassingen kunt u het beste een implementatiearchitectuur voor meerdere regio's gebruiken. Zie Best practices voor bedrijfscontinuïteit en herstel na noodgevallen in Azure Kubernetes Service (AKS) voor meer informatie.

  • Controleer de items in het bestand logging.properties. U kunt een deel van de logboekuitvoer elimineren of beperken om de prestaties te verbeteren.

  • Overweeg om de grootte van de codecache te bewaken en de parameters -XX:InitialCodeCacheSize en -XX:ReservedCodeCacheSize de JAVA_OPTS variabele in het Dockerfile toe te voegen om de prestaties verder te optimaliseren. Zie Codecache Tuning (Engelstalig) in de documentatie van Oracle voor meer informatie.

  • Overweeg om waarschuwingsregels en actiegroepen van Azure Monitor toe te voegen om snel aberrante voorwaarden te detecteren en op te lossen.

  • Overweeg om de Implementatie van Azure Container Apps in een andere regio te repliceren voor lagere latentie en hogere betrouwbaarheid en fouttolerantie. Gebruik Azure Traffic Manager om de taakverdeling tussen implementaties te verdelen of Azure Front Door te gebruiken om SSL-offloading en Web Application Firewall toe te voegen met DDoS-beveiliging.

  • Als geo-replicatie niet nodig is, kunt u een Azure-toepassing-gateway toevoegen om SSL-offloading en Web Application Firewall toe te voegen met DDoS-beveiliging.