Läs på engelska

Dela via

Migrera WebSphere-program till WildFly på Azure Kubernetes Service

  • Artikel

I den här guiden förklarar vi vad du behöver veta när du ska migrera ett befintligt WebSphere-program som ska köras på WildFly i en Azure Kubernetes Service-container.

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.

Lagerserverkapacitet

Dokumentera maskinvaran (minne, CPU, disk) för de aktuella produktionsservrarna och det genomsnittliga och högsta antalet begäranden och resursanvändningen. Du behöver denna information oavsett vilken migrerings väg du väljer. Det är till exempel användbart att hjälpa dig att välja storlek på de virtuella datorerna i nodpoolen, mängden minne som ska användas av containern och hur många CPU-resurser containern behöver.

Det går att ändra storlek på nodpooler i AKS. Mer information finns i Ändra storlek på nodpooler i Azure Kubernetes Service (AKS).

Inventera alla hemligheter

Kontrollera alla egenskaper och konfigurationsfiler på produktionsservrarna efter hemligheter och lösenord. Kontrollera ibm-web-bnd.xml i dina WAR-filer. Konfigurationsfiler som innehåller lösenord eller autentiseringsuppgifter kan också finnas i ditt program.

Inventera alla certifikat

Dokumentera alla certifikat som används för offentliga SSL-slutpunkter. Du kan visa alla certifikat på produktionsservrarna genom att köra följande kommando:

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

Validera att Java-versionen som stöds fungerar som den ska

Användning av WildFly på Azure Kubernetes Service kräver en specifik version av Java, så du måste bekräfta att programmet körs korrekt med den version som stöds.

Anteckning

Den här verifieringen är särskilt viktig om den aktuella servern körs på en JDK som inte stöds (till exempel Oracle JDK eller IBM OpenJ9).

Du får den aktuella Java-versionen genom att logga in på din produktionsserver och köra följande kommando:

Bash 
java -version

I Krav finns information om vilken version du ska använda för att köra WildFly.

Inventera JNDI-resurser

Inventera alla JNDI-resurser. Vissa asynkrona JMS-meddelandetjänster kan kräva migrering eller omkonfiguration.

I ditt program

Inspektera filen WEB-INF/ibm-web-bnd.xml och/eller WEB-INF/web.xml.

Dokumentets datakällor

Om ditt program använder några databaser måste du samla in 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 att konfigurera databasanslutningar i WebSphere-dokumentationen.

Kontrollera om och hur filsystemet används

All användning av programserverns filsystem kräver omkonfiguration eller, i sällsynta fall, arkitektoniska ändringar. Filsystemet kan användas av WebSphere-moduler eller av din programkod. Du kanske identifierar några eller alla scenarier som beskrivs i följande avsnitt.

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.

Dynamiskt eller internt innehåll

För filer som ofta skrivs och läses av ditt program (till exempel temporära datafiler) eller statiska filer som endast är synliga för ditt program kan du montera Azure Storage-resurser som beständiga volymer. Mer information finns i Skapa och använda en volym med Azure Files i Azure Kubernetes Service (AKS).

Ta reda på om programmet är beroende av schemalagda jobb

Schemalagda jobb, till exempel Quartz Scheduler-uppgifter eller Unix cron-jobb, ska INTE användas med Azure Kubernetes Service (AKS). Azure Kubernetes Service förhindrar att du distribuerar ett program som innehåller schemalagda uppgifter internt. Om ditt program skalas ut kan dock samma schemalagda jobb köras mer än en gång per schemalagd period. Den här situationen kan leda till oönskade konsekvenser.

Om du vill köra schemalagda jobb på ditt AKS-kluster definierar du Kubernetes CronJobs efter behov. Mer information finns i Köra automatiserade uppgifter med ett CronJob.

Avgör om en anslutning till lokalt behövs

Om ditt program behöver har åtkomst till någon av dina lokala tjänster måste du etablera en av Azures anslutningstjänster. Mer information finns i Ansluta ett lokalt nätverk till Azure. Alternativt måste du omstrukturera programmet för att använda allmänt tillgängliga API:er som dina lokala resurser exponerar.

Ta reda på om JMS-köer eller -ämnen (Java Message Service) används

Om ditt program använder JMS-köer eller -ämnen måste du migrera dem till en extern JMS-server. Azure Service Bus och AMQP (Advanced Message Queueing Protocol) kan vara en bra migreringsstrategi för de som använder JMS. Mer information finns i Använda Java Message Service 1.1 med Azure Service Bus Standard och AMQP 1.0.

Om JMS beständiga arkiv har konfigurerats måste du avbilda konfigurationen och tillämpa den efter migreringen.

Kontrollera om ditt program använder WebSphere-specifika API:er

Om ditt program använder WebSphere-specifika API:er måste du omstrukturera det för att ta bort dessa beroenden. Om du till exempel har använt en klass som nämns i specifikationen för version 9.0 av API:et för IBM WebSphere Application Server använder ditt program ett WebSphere-specifikt API.

Ta reda på om ditt program använder entitetsbönor eller DMP-bönor med EJB 2.x-format

Om programmet använder entitetsbönor eller CMP-böner med EJB 2.x-format behöver du omstrukturera programmet och ta bort dessa beroenden.

Ta reda på om funktionen Java EE-programklient används

Om du har klientprogram som ansluter till (server)programmet med hjälp av Java EE Application Client-funktionen måste du omstrukturera både klientprogrammen och (server)programmet så att det använder HTTP-API:er.

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.

Ta reda på om EJB-timers används

Om programmet använder EJB-timers måste du validera att EJB-timerkoden kan utlösas av varje WildFly-instans separat. Denna verifiering behövs eftersom varje EJB-timer, i Azure Kubernetes Service-distributionsscenariot, utlöses på sin egen WildFly-instans.

Kontrollera om JCA-anslutningsprogram används

Om ditt program använder JCA-anslutningsprogram måste du kontrollera att JCA-anslutningen kan användas med WildFly. Om JCA-implementeringen är kopplad till WebSphere måste du omstrukturera programmet för att ta bort beroendet. Om det kan användas måste du lägga till JAR-filer till klassökvägen för servern och placera nödvändiga konfigurationsfiler på rätt plats i WildFly-serverkatalogerna.

Ta reda på om JAAS används

Om ditt program använder JAAS måste du avbilda hur JAAS har konfigurerats. Om en databas används kan du konvertera den till en JAAS-domän på WildFly. Om det är en anpassad implementering måste du verifiera att den kan användas på WildFly.

Ta redan på om programmet använder en resursadapter

Om programmet behöver en resursadapter måste den vara kompatibel med WildFly. Ta reda på om resursadaptern fungerar som den ska på en fristående instans av WildFly genom att distribuera den till en server och konfigurera den på rätt sätt. Om resursadaptern fungerar som den ska måste du lägga till JAR-filer till serverklassökvägen för Docker-avbildningen och placera nödvändiga konfigurationsfiler på rätt plats i WildFly-serverkatalogerna.

Ta reda på om ditt program består av flera WAR

Om ditt program består av flera WAS så ska du behandla vart och ett av dem som separarata program och gå igenom den här guiden för varje.

Ta reda på om ditt program är paketerat som EAR

Om ditt program är paketerat som en EAR-fil kontrollerar du filerna application.xml och application-bnd.xml och avbildar deras konfigurationer.

Anteckning

Om du vill kunna skala var och en av dina webbprogram oberoende av varandra för bättre användning av dina Azure Kubernetes Service-resurser (AKS) bör du dela upp EAR i separata webbprogram.

Identifiera alla externa processer och daemons som körs på produktionsservrarna

Om du har processer som körs utanför programservern, som övervaknings-daemons så behöver du eliminera dem eller migrera dem någon annanstans.

Utför testning på plats

Innan du skapar containeravbildningar ska du migrera ditt program till de JDK- och WildFly-versioner som du tänker använda på AKS. Testa programmet noggrant för att säkerställa kompatibilitet och prestanda.

Migrering

Etablera Azure Container Registry och Azure Kubernetes Service

Använd följande kommandon till att skapa ett containerregister och ett Azure Kubernetes-kluster med ett tjänsthuvudnamn som har läsarroll i registret. Se till att välja en lämplig nätverksmodell för klustrets nätverkskrav.

Azure CLI 
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

Skapa en Docker-avbildning för WildFly

Du behöver följande för att skapa en Dockerfile:

  • Ett JDK som stöds.
  • En installation av WildFly.
  • Dina JVM-körningsalternativ.
  • Ett sätt att överföra miljövariabler (om tillämpligt).

Du kan sedan utföra stegen som beskrivs i följande avsnitt, där det är tillämpligt. Du kan använda lagringsplatsen för WildFly-containersnabbstart som utgångspunkt för din Dockerfile och webbprogram.

Konfigurera KeyVault FlexVolume

Skapa ett Azure-valv och fyll i alla nödvändiga hemligheter. Mer information finns i Snabbstart: Ange och hämta en hemlighet från Azure Key Vault med hjälp av Azure CLI. Konfigurera sedan ett FlexVolume-nyckelvalv för att göra dessa hemligheter tillgängliga för poddar.

Du behöver också uppdatera startskriptet som används för bootstrap av WildFly. Det här skriptet måste importera certifikaten till nyckelarkivet som används av WildFly innan du startar servern.

Konfigurera datakällor

Om du vill konfigurera WildFly för åtkomst till en datakälla behöver du lägga till JDBC-drivrutinens JAR-fil till Docker-avbildningen och sedan köra lämpliga JBoss CLI-kommandon. Dessa kommandon måste konfigurera datakällan när du skapar Docker-avbildningen.

I följande steg ges instruktioner för PostgreSQL, MySQL och SQL Server.

  1. Ladda ned JDBC-drivrutinen för PostgreSQL, MySQL eller SQL Server.

    Packa upp nedladdningsarkivet för att hämta drivrutinens .jar -fil.

  2. Skapa en fil med ett namn som module.xml och lägg till följande markering. Ersätt platshållaren <module name> (inklusive vinkelparenteser) med org.postgres för PostgreSQL, com.mysql för MySQL eller com.microsoft för SQL Server. Ersätt <JDBC .jar file path> med namnet på .jar-filen från de föregående steget, inklusive den fullständiga sökvägen till den plats där du vill placera filen i Docker-avbildningen, till exempel i /opt/database.

    XML 
    <?xml version="1.0" ?>
<module xmlns="urn:jboss:module:1.1" name="<module name>">
    <resources>
       <resource-root path="<JDBC .jar file path>" />
    </resources>
    <dependencies>
        <module name="javax.api"/>
        <module name="javax.transaction.api"/>
    </dependencies>
</module>

  3. Skapa en fil med ett namn som datasource-commands.cli och lägg till följande kod. Ersätt <JDBC .jar file path> med värdet du använde i det föregående steget. Ersätt <module file path> med filnamnet och sökvägen från det föregående steget, till exempel /opt/database/module.xml.

    Anteckning

    Microsoft rekommenderar att du använder det säkraste tillgängliga autentiseringsflödet. Det autentiseringsflöde som beskrivs i den här proceduren, till exempel för databaser, cacheminnen, meddelanden eller AI-tjänster, kräver en mycket hög grad av förtroende för programmet och medför risker som inte finns i andra flöden. Använd endast det här flödet när säkrare alternativ, till exempel hanterade identiteter för lösenordslösa eller nyckellösa anslutningar, inte är genomförbara. För lokala datoråtgärder föredrar du användaridentiteter för lösenordslösa eller nyckellösa anslutningar.

    Console 
    batch
module add --name=org.postgres --resources=<JDBC .jar file path> --module-xml=<module file path>
/subsystem=datasources/jdbc-driver=postgres:add(driver-name=postgres,driver-module-name=org.postgres,driver-class-name=org.postgresql.Driver,driver-xa-datasource-class-name=org.postgresql.xa.PGXADataSource)
data-source add --name=postgresDS --driver-name=postgres --jndi-name=java:jboss/datasources/postgresDS --connection-url=$DATABASE_CONNECTION_URL --user-name=$DATABASE_SERVER_ADMIN_FULL_NAME --password=$DATABASE_SERVER_ADMIN_PASSWORD --use-ccm=true --max-pool-size=5 --blocking-timeout-wait-millis=5000 --enabled=true --driver-class=org.postgresql.Driver --exception-sorter-class-name=org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLExceptionSorter --jta=true --use-java-context=true --valid-connection-checker-class-name=org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker
reload
run batch
shutdown

  4. Uppdatera JTA-datakällans konfiguration för programmet:

    Öppna src/main/resources/META-INF/persistence.xml-filen för din app och leta reda på <jta-data-source>-elementet. Ersätt innehållet enligt följande:

    XML 
    <jta-data-source>java:jboss/datasources/postgresDS</jta-data-source>

  5. Lägg till följande i Dockerfile så att datakällan skapas när du skapar Docker-avbildningen

    Console 
    RUN /bin/bash -c '<WILDFLY_INSTALL_PATH>/bin/standalone.sh --start-mode admin-only &' && \
sleep 30 && \
<WILDFLY_INSTALL_PATH>/bin/jboss-cli.sh -c --file=/opt/database/datasource-commands.cli && \
sleep 30

  6. Bestäm vilken DATABASE_CONNECTION_URL som ska användas eftersom de är olika för varje databasserver, och skiljer sig från värdena på Azure Portal. URL-formaten som visas här kravs för användning av WildFly:

    Console 
    jdbc:postgresql://<database server name>:5432/<database name>?ssl=true

  7. När du skapar YAML för distribution i ett senare skede behöver du överföra följande miljövariabler, DATABASE_CONNECTION_URL, DATABASE_SERVER_ADMIN_FULL_NAME och DATABASE_SERVER_ADMIN_PASSWORD med lämpliga värden.

Anteckning

Microsoft rekommenderar att du använder det säkraste tillgängliga autentiseringsflödet. Det autentiseringsflöde som beskrivs i den här proceduren, till exempel för databaser, cacheminnen, meddelanden eller AI-tjänster, kräver en mycket hög grad av förtroende för programmet och medför risker som inte finns i andra flöden. Använd endast det här flödet när säkrare alternativ, till exempel hanterade identiteter för lösenordslösa eller nyckellösa anslutningar, inte är genomförbara. För lokala datoråtgärder föredrar du användaridentiteter för lösenordslösa eller nyckellösa anslutningar.

Mer information om hur du konfigurerar databasanslutning med WildFly finns i PostgreSQL, MySQL eller SQL Server.

Konfigurera JNDI-resurser

För att konfigurera varje JNDI-resurs du behöver konfigurera på WildFly använder du vanligtvis följande steg:

  1. Ladda ned de nödvändiga JAR-filerna och kopiera dem till Docker-avbildningen.
  2. Skapa en WildFly module.xml-fil som refererar till de JAR-filerna.
  3. Skapa alla konfigurationer som krävs av den specifika JNDI-resursen.
  4. Skapa JBoss CLI-skript som ska användas vid Docker-bygge för att registrera JNDI-resursen.
  5. Lägg till allt i Dockerfile.
  6. Över de lämpliga miljövariablerna i distributionens YAML-fil.

I exemplet nedan visas stegen som behövs för att skapa JNDI-resursen för JMS-anslutning till Azure Service Bus.

  1. Ladda ned Apache Qpid JMS-providern

    Packa upp nedladdningsarkivet för att hämta .jar-filerna.

  2. Skapa en fil med ett namn som module.xml och lägg till följande markering i /opt/servicebus. Kontrollera att JAR-filernas versionsnummer överensstämmer med namnen på JAR-filerna i föregående steg.

    XML 
    <?xml version="1.0" ?>
<module xmlns="urn:jboss:module:1.1" name="org.jboss.genericjms.provider">
 <resources>
  <resource-root path="proton-j-0.31.0.jar"/>
  <resource-root path="qpid-jms-client-0.40.0.jar"/>
  <resource-root path="slf4j-log4j12-1.7.25.jar"/>
  <resource-root path="slf4j-api-1.7.25.jar"/>
  <resource-root path="log4j-1.2.17.jar"/>
  <resource-root path="netty-buffer-4.1.32.Final.jar" />
  <resource-root path="netty-codec-4.1.32.Final.jar" />
  <resource-root path="netty-codec-http-4.1.32.Final.jar" />
  <resource-root path="netty-common-4.1.32.Final.jar" />
  <resource-root path="netty-handler-4.1.32.Final.jar" />
  <resource-root path="netty-resolver-4.1.32.Final.jar" />
  <resource-root path="netty-transport-4.1.32.Final.jar" />
  <resource-root path="netty-transport-native-epoll-4.1.32.Final-linux-x86_64.jar" />
  <resource-root path="netty-transport-native-kqueue-4.1.32.Final-osx-x86_64.jar" />
  <resource-root path="netty-transport-native-unix-common-4.1.32.Final.jar" />
  <resource-root path="qpid-jms-discovery-0.40.0.jar" />
 </resources>
 <dependencies>
  <module name="javax.api"/>
  <module name="javax.jms.api"/>
 </dependencies>
</module>

  3. Skapa en jndi.properties-fil i /opt/servicebus.

    Console 
    connectionfactory.${MDB_CONNECTION_FACTORY}=amqps://${DEFAULT_SBNAMESPACE}.servicebus.windows.net?amqp.idleTimeout=120000&jms.username=${SB_SAS_POLICY}&jms.password=${SB_SAS_KEY}
queue.${MDB_QUEUE}=${SB_QUEUE}
topic.${MDB_TOPIC}=${SB_TOPIC}

  4. Skapa en fil med ett namn som servicebus-commands.cli och lägg till följande kod.

    Console 
    batch
/subsystem=ee:write-attribute(name=annotation-property-replacement,value=true)
/system-property=property.mymdb.queue:add(value=myqueue)
/system-property=property.connection.factory:add(value=java:global/remoteJMS/SBF)
/subsystem=ee:list-add(name=global-modules, value={"name" => "org.jboss.genericjms.provider", "slot" =>"main"}
/subsystem=naming/binding="java:global/remoteJMS":add(binding-type=external-context,module=org.jboss.genericjms.provider,class=javax.naming.InitialContext,environment=[java.naming.factory.initial=org.apache.qpid.jms.jndi.JmsInitialContextFactory,org.jboss.as.naming.lookup.by.string=true,java.naming.provider.url=/opt/servicebus/jndi.properties])
/subsystem=resource-adapters/resource-adapter=generic-ra:add(module=org.jboss.genericjms,transaction-support=XATransaction)
/subsystem=resource-adapters/resource-adapter=generic-ra/connection-definitions=sbf-cd:add(class-name=org.jboss.resource.adapter.jms.JmsManagedConnectionFactory, jndi-name=java:/jms/${MDB_CONNECTION_FACTORY})
/subsystem=resource-adapters/resource-adapter=generic-ra/connection-definitions=sbf-cd/config-properties=ConnectionFactory:add(value=${MDB_CONNECTION_FACTORY})
/subsystem=resource-adapters/resource-adapter=generic-ra/connection-definitions=sbf-cd/config-properties=JndiParameters:add(value="java.naming.factory.initial=org.apache.qpid.jms.jndi.JmsInitialContextFactory;java.naming.provider.url=/opt/servicebus/jndi.properties")
/subsystem=resource-adapters/resource-adapter=generic-ra/connection-definitions=sbf-cd:write-attribute(name=security-application,value=true)
/subsystem=ejb3:write-attribute(name=default-resource-adapter-name, value=generic-ra)
run-batch
reload
shutdown

  5. Lägg till följande i Dockerfile så att JNDI-resursen skapas när du skapar Docker-avbildningen

    Console 
    RUN /bin/bash -c '<WILDFLY_INSTALL_PATH>/bin/standalone.sh --start-mode admin-only &' && \
sleep 30 && \
<WILDFLY_INSTALL_PATH>/bin/jboss-cli.sh -c --file=/opt/servicebus/servicebus-commands.cli && \
sleep 30

  6. När du skapar YAML för distribution i ett senare skede behöver du överföra följande miljövariabler, MDB_CONNECTION_FACTORY, DEFAULT_SBNAMESPACE och SB_SAS_POLICY, SB_SAS_KEY, MDB_QUEUE, SB_QUEUE, MDB_TOPIC och SB_TOPIC med lämpliga värden.

Granska WildFly-konfiguration

Läs administratörsguiden för WildFly för att ta del av eventuella ytterligare steg före migrering som inte tas upp i de föregående anvisningarna.

Skapa och överföra Docker-avbildningen till Azure Container Registry

När du har skapat Dockerfile måste du skapa Docker-avbildningen och publicera den i ditt Azure-containerregister.

Om du har använt vår GitHub-lagringsplats för WildFly-containersnabbstart är processen för att skapa och överföra avbildningen till ditt Azure-containerregister densamma som att anropa följande tre kommandon.

I dessa exempel innehåller MY_ACR-miljövariabeln namnet på ditt Azure-containerregister och MY_APP_NAME-variabeln innehåller namnet på det webbprogram som du vill använda i ditt Azure-containerregister.

Skapa WAR-filen:

Bash 
mvn package

Logga in på ditt Azure-containerregister:

Azure CLI 
az acr login --name ${MY_ACR}

Skapa och överföra avbildningen:

Azure CLI 
az acr build --image ${MY_ACR}.azurecr.io/${MY_APP_NAME} --file src/main/docker/Dockerfile .

Du kan också använda Docker CLI för att först skapa och testa avbildningen lokalt, enligt följande kommandon. Den här metoden kan förenkla testningen och förfina avbildningen före den första distributionen till ACR. Du måste dock installera Docker CLI och se till att Docker-daemon körs.

Skapa avbildningen:

Bash 
docker build -t ${MY_ACR}.azurecr.io/${MY_APP_NAME}

Kör avbildningen lokalt:

Bash 
docker run -it -p 8080:8080 ${MY_ACR}.azurecr.io/${MY_APP_NAME}

Nu kan du komma åt ditt program på http://localhost:8080.

Logga in på ditt Azure-containerregister:

Azure CLI 
az acr login --name ${MY_ACR}

Överför avbildningen till Azure-containerregistret:

Bash 
docker push ${MY_ACR}.azurecr.io/${MY_APP_NAME}

Mer detaljerad information om hur du skapar och lagrar containeravbildningar finns i Learn-modulen Skapa och lagra containeravbildningar med Azure Container Registry.

Distribuera en offentlig IP-adress

Om ditt program ska vara tillgängligt utanför dina interna eller virtuella nätverk behöver du en offentlig statisk IP-adress. Du bör etablera den här IP-adressen i klustrets nodresursgrupp, enligt följande exempel:

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

Distribuera till Azure Kubernetes Service (AKS)

Skapa och använd dina Kubernetes YAML-fil(er). Mer information finns i Snabbstart: Distribuera ett AKS-kluster (Azure Kubernetes Service) med hjälp av Azure CLI. Om du skapar en extern lastbalanserare (oavsett om det är för ditt program eller en ingångskontroll) måste du ange IP-adressen som etablerades i föregående avsnitt som LoadBalancerIP.

Ta med externa parametrar som miljövariabler. Mer information finns i artikeln om att definiera miljövariabler för en container. Ta inte med hemligheter (till exempel lösenord, API-nycklar och JDBC-anslutningssträngar). Dessa beskrivs i följande avsnitt.

Se till att inkludera minnes- och CPU-inställningar när du skapar distributionens YAML-fil så att containrarna får rätt storlek.

Konfigurera beständig lagring

Om programmet kräver icke-flyktig lagring kan du konfigurera en eller flera Beständiga volymer.

Migrera schemalagda jobb

Om du vill köra schemalagda jobb på ditt AKS-kluster definierar du Kubernetes CronJobs efter behov. Mer information finns i Köra automatiserade uppgifter med ett CronJob.

Efter migreringen

Nu när du har migrerat ditt program till Azure Kubernetes Service kontrollerar du att det fungerar som förväntat. När du har gjort det har vi några rekommendationer som hjälper dig att göra programmet mer molnanpassat.

Rekommendationer