Migrera Tomcat-program till Azure Container Apps

Den här guiden beskriver vad du bör känna till när du vill migrera ett befintligt Tomcat-program som ska köras i Azure Container Apps (ACA).

Före migrering

För att säkerställa en lyckad migrering slutför du de utvärderings- och inventeringssteg som beskrivs i följande avsnitt innan du börjar.

Inventera externa resurser

Externa resurser som datakällor, JMS asynkron meddelandekö och andra matas via Java-namngivnings- och kataloggränssnittet (JNDI). Vissa resurser kan kräva migrering eller omkonfiguration.

I ditt program

Granska filen META-INF/context.xml. Leta efter <Resource>-element i <Context>-elementet.

På programservrar

Granska filerna $CATALINA_BASE/conf/context.xml och $CATALINA_BASE/conf/server.xml samt de .xml-filer som hittas i $CATALINA_BASE/conf/[engine-name]/[host-name]-katalogerna.

I context.xml-filer kommer JNDI-resurser att beskrivas av de <Resource>-element i toppnivåelementet <Context>.

I server.xml-filer kommer JNDI-resurser att beskrivas av de <Resource>-element i toppnivåelementet <GlobalNamingResources>.

Datakällor

Datakällor är JNDI-resurser med attributet type inställt på javax.sql.DataSource. För varje datakälla, dokumenterar du följande information:

• What is the datakällans namn?
• Vad är konfigurationen för anslutningspoolen?
• Var hittar jag JAR-filen för JDBC-drivrutinen?

Mer information finns i avsnittet om JNDI-datakällor i Tomcat-dokumentationen.

Alla andra externa resurser

Det är inte möjligt att dokumentera alla möjliga externa beroenden i den här guiden. Det är ditt teams ansvar att kontrollera att du kan uppfylla varje externt beroende för ditt program efter migreringen.

Inventera hemligheter

Lösenord och säkra strängar

Kontrollera alla egenskaper och konfigurationsfiler på produktionsservrarna efter hemlighetssträngar och lösenord. Se till att kontrollera server.xml och context.xml i $CATALINA_BASE/conf. Du kan även hitta konfigurationsfiler som med lösenord eller autentiseringsuppgifter i ditt program. De kan inkludera META-INF/context.xml, och för Spring Boot-program, application.properties- eller application.yml-filer.

Kontrollera om och hur filsystemet används

All användning av programserverns filsystem kräver omkonfiguration eller, i sällsynta fall, arkitektoniska ändringar. Du kanske känner igen några eller alla av följande scenarier.

Skrivskyddat statiskt innehåll

Om ditt program för tillfället hanterar statiskt innehåll behöver du en alternativ plats för det. Du kanske kan tänka dig att flytta det statiska innehållet till Azure Blob Storage och lägga till Azure CDN för blixtsnabba nedladdningar globalt. Mer information finns i Värd för statiska webbplatser i Azure Storage och snabbstart: Integrera ett Azure Storage-konto med Azure CDN.

Dynamiskt publicerat statiskt innehåll

Om ditt program tillåter att statiskt innehåll laddas upp/skapas av ditt program, men inte kan ändras efter att det har skapats, så kan du använda Azure Blob Storage och Azure CDN enligt beskrivningen ovan, med en Azure-funktion för hantering av överföringar och CDN-uppdateringar. Vi har tillhandahållit en exempelimplementering som du kan använda i Överföra och CDN-för inläsa statiskt innehåll med Azure Functions.

Identifiera mekanism för beständig session

Om du vill identifiera vilken funktion för beständig session som används kan du granska context.xml-filerna i program- och Tomcat-konfigurationen. Leta efter elementet <Manager> och anteckna värdet för attributet className.

Tomcats inbyggda PersistentManager-implementeringar , till exempel StandardManager eller FileStore , är inte utformade för användning med en distribuerad, skalad plattform som ACA. ACA kan belastningsutjämning mellan flera instanser och transparent starta om alla instanser när som helst, så att bevara föränderligt tillstånd till ett filsystem rekommenderas inte.

Om sessionspersistence krävs måste du använda en alternativ PersistentManager implementering som skriver till ett externt datalager, till exempel VMware Tanzu Session Manager med Redis Cache.

Särskilda fall

Vissa produktionsscenarier kan kräva fler ändringar eller införa fler begränsningar. Även om sådana scenarier kan vara ovanliga är det viktigt att se till att de antingen inte kan tillämpas på ditt program eller åtgärdas korrekt.

Avgör om programmet är beroende av schemalagda uppgifter

Schemalagda uppgifter, t. ex. Quartz Scheduler-uppgifter eller cron-jobb, kan inte användas med Tomcat-distributioner i behållare. Om ditt program skalas ut kan ett schemalagt jobb köras mer än en gång per schemalagd period. Den här situationen kan leda till oönskade konsekvenser.

Inventera schemalagda jobb, inuti eller utanför programservern.

Ta reda på om ditt program innehåller en operativsystemsspecifik kod

Om ditt program innehåller någon kod med beroenden på värdoperativsystemet måste du omstrukturera det för att ta bort dessa beroenden. Du kan till exempel behöva ersätta all användning av / eller \ i filsystemsökvägar med File.Separator eller Paths.get om programmet körs i Windows.

Avgör om MemoryRealm används

MemoryRealm- kräver en sparad XML-fil. På ACA måste du lägga till den här filen i containeravbildningen eller ladda upp den till delad lagring som görs tillgänglig för containrar. (Mer information finns i Identifiera avsnittet mekanism för sessionspersistens.) Parametern pathName måste ändras i enlighet med detta.

Du kan ta reda på om MemoryRealm används just nu genom att granska filerna server.xml och context.xml och söka efter <Realm> element där className-attributet är inställt på org.apache.catalina.realm.MemoryRealm.

Testning på plats

Innan du skapar containeravbildningar migrerar du programmet till JDK och Tomcat som du tänker använda på ACA. Testa programmet noggrant för att säkerställa kompatibilitet och prestanda.

Parameterisera konfigurationen

I förväg har du förmodligen identifierat hemligheter och externa beroenden, till exempel datakällor, i filerna Server.xml och context.xml. Ersätt eventuella användarnamn, lösenord, anslutningssträngar eller URL:er med en miljövariabel för varje objekt som identifieras på detta sätt.

Anta till exempel att filen context.xml innehåller följande 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}"
/>

I det här fallet kan du ändra det som visas i följande exempel:

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

Migrering

Förbereda distributionsartefakter

Klona GitHub-lagringsplatsen Tomcat på containrar . Den här lagringsplatsen innehåller en Dockerfile- och Tomcat-konfigurationsfiler med många rekommenderade optimeringar. I stegen nedan beskriver vi de ändringar som du förmodligen behöver göra i dessa filer innan du skapar containeravbildningen och distribuerar till ACA.

Lägg till JNDI-resurser

Redigera server.xml för att lägga till de resurser som du förberedde i stegen före migreringen, till exempel Datakällor, som du ser i följande exempel:

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

Mer information om datakällor finns i följande avsnitt om JNDI-datakällor i Tomcat-dokumentationen:

• MySQL
• PostgreSQL
• SQL Server

Kompilera och överföra avbildningen

Det enklaste sättet att skapa och ladda upp avbildningen till Azure Container Registry (ACR) för användning av ACA är att använda az acr build kommandot . Det här kommandot kräver inte att Docker är installerat på datorn. Om du till exempel har Dockerfile från lagringsplatsen tomcat-container-quickstart och programpaketet petclinic.war i den aktuella katalogen kan du skapa containeravbildningen i ACR med följande kommando:

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 .

Du kan utelämna parametern --build-arg APP_FILE... om WAR-filen heter ROOT.war. Du kan utelämna parametern --build-arg SERVER_XML... om serverns XML-fil heter server.xml. Båda filerna måste finnas i samma katalog som Dockerfile.

Du kan också använda Docker CLI för att skapa avbildningen lokalt med hjälp av följande kommandon. Den här metoden kan förenkla testningen och förfina avbildningen före den första distributionen till ACR. Dock kräver det att Docker-kommandoradsgränssnittet installeras och att Docker-daemon körs.

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

Mer information finns i Skapa och lagra containeravbildningar med Azure Container Registry.

Distribuera till Azure Container Apps

Följande kommando visar ett exempel på distribution:

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

En mer ingående snabbstart finns i Snabbstart: Distribuera din första containerapp.

Efter migreringen

Nu när du har migrerat ditt program till ACA bör du kontrollera att det fungerar som förväntat. När du har gjort det har vi några rekommendationer för dig som kan göra ditt program lämpligare för molnet.

Rekommendationer

• Utforma och implementera en strategi för affärskontinuitet och haveriberedskap. För verksamhetskritiska program bör du överväga en distributionsarkitektur för flera regioner. Mer information finns i Metodtips för affärskontinuitet och haveriberedskap i Azure Kubernetes Service (AKS).

• Utvärdera objekten i filen logging.properties. Överväg att ta bort eller minska några av loggningsresultatet för att förbättra prestandan.

• Överväg att övervaka kodens cachestorlek och lägga till parametrarna -XX:InitialCodeCacheSize och -XX:ReservedCodeCacheSize till variabeln JAVA_OPTS i Dockerfile för att ytterligare optimera prestanda. Mer information finns i Codecache Tuning i Oracle-dokumentationen.

• Överväg att lägga till Azure Monitor-aviseringsregler och åtgärdsgrupper för att snabbt identifiera och hantera avvikande villkor.

• Överväg att replikera Azure Container Apps-distributionen i en annan region för lägre svarstid och högre tillförlitlighet och feltolerans. Använd Azure Traffic Manager för att belastningsutjämna mellan distributioner eller använda Azure Front Door för att lägga till SSL-avlastning och brandvägg för webbprogram med DDoS-skydd.

• Om geo-replikering inte behövs kan du överväga att lägga till en Azure Application Gateway för att lägga till SSL-avlastning och brandvägg för webbprogram med DDoS-skydd.