Migrera WebSphere-program till Azure Kubernetes Service (AKS)

  • Artikel

Den här guiden beskriver vad du bör känna till när du vill migrera en befintlig arbetsbelastning för WebSphere Application Server (WAS) till IBM WebSphere Liberty eller Open Liberty på Azure Kubernetes Service (AKS).

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.

Se till att målet är rätt mål för migreringsarbetet

Det första steget i en lyckad migrering av ett WAS-program till Azure är att välja det lämpligaste migreringsmålet.

WAS-traditionella körningar bra på Azure Virtual Machines. Målet för den virtuella datorn (VM) är det enklaste valet, eftersom det närmast liknar en lokal distribution. Den administrativa upplevelsen och distributionen för virtuella datorer motsvarar det du har lokalt.

Ett annat alternativ är att migrera till containrar genom att konvertera den traditionella WAS-arbetsbelastningen till programcontainrar. Du kan köra containermålet på Azure Kubernetes Service (AKS) och Azure Red Hat OpenShift. Kompromissen för denna lätthet är ekonomiska kostnader.

Generellt sett är kostnaden per minut för en VM-baserad lösning högre jämfört med containrar. Även om en containerbaserad lösning kostar mindre att köra måste du begränsa programmet så att det passar kraven för containerorkestreringsplattformen.

Om minimering av ändringar är den viktigaste faktorn för migreringen bör du överväga en VM-baserad migrering. I det här fallet kan du läsa Migrera WebSphere-program till Virtuella Azure-datorer.

Om du kan tolerera att konvertera ditt program till att köras i containrar för att minska körningskostnaden bör du överväga en AKS-baserad eller Azure Red Hat OpenShift-baserad migrering.

För AKS-baserad migrering kan du börja använda den kostnadsfria nivån. Få kostnadsfri klusterhantering och betala endast för de virtuella datorer, tillhörande lagrings- och nätverksresurser som förbrukas. I det här fallet kan du läsa Migrera WebSphere-program till Azure Kubernetes Service.

För Azure Red Hat OpenShift-baserad migrering, utöver beräknings- och infrastrukturkostnaderna, har programnoder en annan kostnad för OpenShift-licenskomponenten. Den här kostnaden debiteras baserat på antalet programnoder och instanstypen. Använd priser på begäran eller reserverade instanser, beroende på vilket som bäst uppfyller behovet av din arbetsbelastning och ditt företag. I det här fallet kan du läsa Migrera WebSphere-program till Azure Red Hat OpenShift.

Guiderna i Azure Red Hat OpenShift-dokumentationen beskriver några aspekter som är relevanta för migrering. Den fullständiga listan över instruktioner finns i Dokumentationen om Azure Red Hat OpenShift.

Avgöra om det fördefinierade Azure Marketplace-erbjudandet är en bra utgångspunkt

När du har bestämt att AKS är rätt distributionsmål måste du acceptera att IBM WebSphere Liberty-operatorn eller Open Liberty Operator (operatorn) är det enda sättet att köra Liberty på Kubernetes. När du har accepterat detta måste du bestämma om det fördefinierade Azure Marketplace-erbjudandet är en bra utgångspunkt. Här följer några saker att tänka på om det fördefinierade Azure Marketplace-erbjudandet:

  • IBM och Microsoft har skapat det här erbjudandet så att du snabbt kan etablera Liberty på AKS. Det här konceptet förklaras mer detaljerat i följande innehåll.
  • På hög nivå automatiserar erbjudandet följande steg åt dig.
    • Ta en befintlig programbild om du vill.
    • Etablera ett AKS-kluster och en Azure Container Registry-instans (ACR) om du vill.
    • Installera och konfigurera IBM WebSphere Liberty-operatorn eller Open Liberty-operatorn på AKS.
    • Använd operatorn för att köra allt. Operatorn distribuerar och hanterar containerbaserade Liberty-program i AKS. Du hittar referensdokumentationen hos IBM WebSphere Liberty-operatorn och Open Liberty-operatören.

Om du inte använder det fördefinierade Azure Marketplace-erbjudandet måste du lära dig hur du använder operatorn direkt. Att hantera operatorn ligger utanför omfånget för den här artikeln. Den fullständiga dokumentationen för operatören finns på IBM WebSphere Liberty-operatorn och Open Liberty-operatören.

Nu när du har introducerats för de olika sätten att hantera Liberty på AKS är det bättre att välja om du vill använda det fördefinierade Azure Marketplace-erbjudandet eller göra det själv med hjälp av operatören direkt.

Avgöra om Liberty-versionen är kompatibel

Du behöver Open Liberty-operatorn eller WebSphere Liberty-operatorn för att distribuera och hantera program i Kubernetes-baserade kluster. Kontrollera att din befintliga Liberty-version är en av de versioner som stöds av operatorn. Versioner av Open Liberty underhålls i GitHub OpenLiberty/open-liberty. IBM underhåller versioner av IBM WebSphere Application Server Liberty. Mer information finns i WebSphere Application Server Liberty.

Med det fördefinierade Azure Marketplace-erbjudandet kan du välja dina programbilder från det offentliga registret och därmed implicit ha stöd för alla versioner.

Avgöra om en licens behövs

För IBM WebSphere Liberty måste du godkänna villkoren i licensavtalet som motsvarar versionen av IBM-programmet i programcontainern. Det licensavtal som gäller för det här IBM-programmet finns i Visa licensinformation för WebSphere Liberty-operatör. Mer information finns i Köra WebSphere Liberty på Microsoft Azure.

Om produktutgåvan är något annat än ibm WebSphere-standardprogramservern (bas) .spec.license.edition value måste du ange produktutgåvan. Andra tillgängliga värden är IBM WebSphere Application Server Liberty Core och IBM WebSphere Application Server Network Deployment. Med det fördefinierade Azure Marketplace-erbjudandet kan du välja den produktversion som stöds.

Inventeringsskillnader med IBM-migreringsverktyg

Om du vill flytta dina program till WebSphere Application Server Liberty eller Open Liberty måste du planera migreringen, analysera dina program och uppdatera källkoden. IBM tillhandahåller migreringsverktyg som hjälper dig att identifiera eventuella skillnader mellan din aktuella miljö och teknikerna i din nya Liberty-miljö, till exempel Java EE 7 eller Java EE 8 och Java SE 8 eller Java SE 11. Mer information finns i Migrera program till Liberty.

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

Innan tekniker för konfiguration som en tjänst, till exempel Azure Key Vault, fanns det inget väldefinierat koncept för hemligheter. I stället hade du skilda uppsättningar konfigurationsinställningar som fungerade som det vi nu kallar hemligheter. Med appservrar som WAS finns dessa hemligheter i många olika konfigurationsfiler och konfigurationslager. Kontrollera alla egenskaper och konfigurationsfiler på produktionsservrarna efter hemligheter och lösenord. Konfigurationsfiler som innehåller lösenord eller autentiseringsuppgifter kan också finnas i ditt program. WAS lagrar konfigurationsdata i flera dokument i en sammanhängande hierarki med kataloger. De flesta konfigurationsdokument har XML-innehåll. Mer information finns i Konfigurationsdokument och Grundläggande begrepp i Azure Key Vault.

När du har en gedigen inventering av hemligheter kan du läsa operatörsdokumentationen om hemligheter. Mer information finns i följande artiklar:

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:

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

När du har en gedigen inventering av certifikat konfigurerar du dem med hjälp av följande artiklar:

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

Att använda Liberty kräver en specifik version av Java, så du måste bekräfta att programmet körs korrekt med den version som stöds.

Körningen av WebSphere Application Server Liberty har specifika krav för miniminivån för Java Runtime Environment (JRE). Mer information finns i Java-versionsberoenden för funktioner.

Open Liberty kräver en Java SE-körning. Den kan köras med hjälp av antingen en Java Runtime Environment (JRE) eller en JDK-distribution (Java SE Development Kit). Mer information finns i Java SE-versioner som stöds.

Inventera JNDI-resurser

Inventera alla JNDI-resurser. Till exempel kan datakällor som databaser, ha ett associerat JNDI-namn som gör det möjligt för JPA att korrekt binda instanser av EntityManager till en viss databas. Mer information om JNDI-resurser och databaser finns i WebSphere Data Sources i IBM-dokumentationen. Andra JNDI-relaterade resurser som JMS asynkron meddelandekö kan kräva migrering eller omkonfiguration. Mer information om JMS-konfiguration finns i Använda JMS-resurser.

Om du använder det fördefinierade Azure Marketplace-erbjudandet är den uppsättning JNDI-resurser som du kan anpassa vid distributionstiden begränsad till vad erbjudandet stöder. För WebSphere Liberty på AKS kan du göra ett objekt tillgängligt i JNDI-namnområdet (Java Naming and Directory Interface) som standard. Mer information finns i Utveckla med JNDI-standardnamnområdet i en Liberty-funktion. För Open Liberty, se Java-namngivning och kataloggränssnitt.

Granska profilkonfigurationen

Huvudkonfigurationsenheten i WAS är profilen. Därför innehåller filen resources.xml en mängd konfigurationer som du noggrant måste överväga för migrering. Filen innehåller referenser till andra XML-filer som lagras i underkataloger. Mer information finns i Hantera profiler på distribuerade operativsystem och IBM i-operativsystem.

I ditt program

Granska filen deployment.xml och/eller WEB-INF/web.xml .

Du måste samla in de här anpassningarna i containeravbildningen som AKS kör. När du använder det fördefinierade Azure Marketplace-erbjudandet hanteras sådana anpassningar bäst genom att skapa en anpassad containeravbildning och göra den tillgänglig i ett offentligt register och sedan peka på registret vid distributionstillfället.

Om du använder en WebSphere Application Server Network Deployment-cell körs varje klustermedlem i en installation av traditionell WAS. Liberty är en lätt profil för WebSphere Application Server. Det är en flexibel och dynamisk profil för WAS, som gör det möjligt för WAS-servern att endast distribuera nödvändiga anpassade funktioner i stället för att distribuera en stor uppsättning tillgängliga Java EE-komponenter.

Fastställ om sessionsreplikering används

Om programmet förlitar sig på sessionsreplikering har du följande alternativ:

  • För HTTP-sessioner, enligt nivån för sessionshantering, kan du använda cacheminne eller en databas för att samla in sessionsdata.
  • För distribuerade sessioner kan du spara sessioner i en databas med hjälp av databassessionens beständighet.
  • För dynamisk cache kan du hantera sessionsdata i cacheminnet eller en databas.
  • Du kan omstrukturera ditt program för att använda en databas för sessionshantering.
  • Du kan omstrukturera ditt program för att externalisera sessionen till Azure Redis Service. Mer information finns i Azure Cache for Redis.

För alla dessa alternativ är det en bra idé att lära sig hur Liberty utför HTTP-sessionstillståndsreplikering. Följande dokument hjälper dig att förstå hur du hanterar HTTP-sessioner i Liberty:

Det fördefinierade Azure Marketplace-erbjudandet stöder sessionstillhörighet via Application Gateway-ingresskontrollanten. När du distribuerar erbjudandet väljer du Aktivera cookiebaserad tillhörighet.

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 om JDBC-drivrutiner i WAS finns i Använda JDBC-drivrutiner med WebSphere Application Server.

JDBC-konfiguration är en kärnserverkonfiguration i Liberty. Mer information finns i JDBC-drivrutin.

Det fördefinierade Azure Marketplace-erbjudandet har begränsat stöd för databaser. Du kan hantera konfigurationen i programbilderna och använda avbildningen när du distribuerar erbjudandet.

Avgöra om WAS har anpassats

Fastställ vilken av följande anpassningar som har gjorts och registrera vad som har gjorts.

  • Har startskripten ändrats? Sådana skript omfattar wsadmin, AdminControl, AdminConfig, AdminApp och AdminTask.
  • Finns det några speciella parametrar som skickas till JVM?
  • Har JAR lagts till i server-classpath?
  • Har operativsystemnivåanläggningar som systemd använts för att få WAS-komponenter att starta automatiskt efter en omstart av servern?

Du måste ta hänsyn till migreringsöverväganden beroende på svaren på dessa frågor.

Du måste samla in de här anpassningarna i containeravbildningen som AKS kör. När du använder det fördefinierade Azure Marketplace-erbjudandet hanteras sådana anpassningar bäst genom att skapa en anpassad containeravbildning och göra den tillgänglig i ett offentligt register och sedan peka på registret vid distributionstillfället.

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 externT värdbaserad JMS-server. En strategi för dem som använder JMS är att använda Azure Service Bus och Advanced Message Queuing Protocol. Mer information finns i Använda Java Message Service 1.1 med Azure Service Bus Standard och AMQP 1.0.

Om du har konfigurerat JMS-beständiga butiker måste du avbilda deras konfiguration och tillämpa den efter migreringen.

Om du använder IBM MQ kan du migrera den här programvaran till Azure Virtual Machines och använda den som den är.

Microsoft har en lösning för att integrera IBM MQ med Logic Apps. Mer information finns i Ansluta till en IBM MQ-server från ett arbetsflöde i Azure Logic Apps.

Fastställ om du använder dina egna anpassade Delade Java EE-bibliotek

Om du använder funktionen med Delade Java EE-bibliotek så har du två alternativ:

  • Återför programkoden för att ta bort alla beroenden i dina bibliotek, och inkludera i stället funktionerna direkt i programmet.
  • Lägg till biblioteken till server-classpath.

Du kan hantera dessa bibliotek med samma tekniker som beskrivs i Åtkomst till API:er från tredje part från ett Java EE-program.

Ta reda på om OSGi-paket används

Om du använde OSGi-paket som lagts till i WAS måste du lägga till motsvarande JAR-filer direkt i webbappen.

Du kan inkludera paketen i avbildningen som levereras till det fördefinierade Azure Marketplace-erbjudandet. Mer information finns i Konfigurera bibliotek för OSGi-program.

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.

Liberty på AKS körs på Linux x86_64. All OS-specifik kod måste vara kompatibel med Linux. Om du vill lära dig hur du identifierar specifik os-information följer du stegen i avsnittet Avgöra om Liberty-versionen är kompatibel .

Avgöra om IBM Integration Bus används

Om ditt program använder IBM Integration Bus måste du samla in hur IBM Integration Bus har konfigurerats. Mer information finns i IBM Integration Bus-dokumentationen.

IBM Integration Bus stöds inte direkt i det fördefinierade Azure Marketplace-erbjudandet. Om du vill aktivera funktionen följer du anvisningarna i Aktivera JMS-programmet på Liberty för att ansluta till tjänstintegreringsbussen i IBM-dokumentationen.

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 paketeras som en EAR-fil bör du undersöka filerna application.xml, ibm-application-bnd.xmi och ibm-application-ext.xmi och avbilda deras konfigurationer. Mer information finns i Skapa enterprise archive-paketet (EAR) på WebSphere.

Med det fördefinierade Azure Marketplace-erbjudandet kan du använda en befintlig containeravbildning. Du kan förbereda programmet enligt dina affärskrav.

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.

Kontrollera om och hur filsystemet används

Kubernetes hanterar filsystem med beständiga volymer (PV). Montering av beständiga volymer stöds inte i det fördefinierade Azure Marketplace-erbjudandet. Om du vill aktivera olika lagringsalternativ följer du anvisningarna i Lagringsalternativ för program i Azure Kubernetes Service.

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.

Ta reda på nätverkstopologin

Den aktuella uppsättningen Azure Marketplace-erbjudanden är en startpunkt för migreringen. Om erbjudandet inte omfattar aspekter av din arkitektur som du behöver migrera måste du samla in nätverkstopologin för din befintliga distribution. Sedan måste du återskapa topologin i Azure, även efter att du har skapat det grundläggande erbjudandet med en av lösningsmallarna.

Nätverkstopologi är ett brett ämne, men följande referenser kan ge en viss riktning till migreringsarbetet:

Konto för användning av JCA-kort och resurskort

Om ditt befintliga program använder JCA-kort eller resurskort för att ansluta till andra företagssystem kontrollerar du att du tillämpar konfigurationen för dessa artefakter på Liberty-servern som körs på Azure Kubernetes Service (AKS). Mer information finns i Översikt över JCA-konfigurationselement och Java Connector-arkitektur.

Avgöra om klustring används

Operatorn hanterar klustring för alla möjliga sätt att köra WAS-arbetsbelastning på AKS.

Inspektera DIN EJB-klustring

Om ditt program använder lokala Enterprise Java Beans (EJB) kan du behöva migrera dem till en klustrad EJB. Mer information finns i Utveckla EJB-program på Liberty.

Konto för belastningsutjämningskrav

Det bästa sättet att ta hänsyn till belastningsutjämning är att använda App Gateway-integreringen som tillhandahålls av det inbyggda Azure Marketplace-erbjudandet.

Migrering

Stegen i det här avsnittet förutsätter att din analys har lett till att du bestämmer dig för att använda det fördefinierade Azure Marketplace-erbjudandet.

Få tillgång till erbjudandet

Information om hur du öppnar erbjudandet i Azure Portal finns i IBM WebSphere Liberty och Open Liberty på Azure Kubernetes Service. Välj Skapa och använd sedan den information som du samlade in i föregående steg för att fylla i fälten i erbjudandet.

KeyStores-konto

Du måste ta hänsyn till migreringen av alla SSL/TLS KeyStores som används av ditt program. Mer information finns i Konfigurera KeyStores.

Anslut JMS-källorna

När du har anslutit databaserna kan du konfigurera JMS genom att följa anvisningarna i Översikt över JCA-konfigurationselement i IBM-dokumentationen.

Loggningskonto

Du kan inte göra molnet utan att hantera loggning. Operatorn tillhandahåller olika metoder för övervakning. Mer information finns i Övervaka Liberty-serverns körningsmiljö. Om du föredrar att använda Elastic Stack ger Azure bra stöd för Elastic. Fullständig information finns i Vad är elastisk integrering med Azure? Du kan kombinera kunskapen i dessa två resurser för att uppnå en Azure-optimerad loggningslösning för Liberty på AKS.

Migrera dina program

Oavsett om du har valt att tillhandahålla en programbild vid distributionstillfället måste du uppdatera programmet via CI/CD. IBM-dokumentationen har ett exempel som visar hur du gör den här uppdateringen. Mer information finns i Distribuera program i Liberty.

Konfigurera tester

Du måste konfigurera alla tester i containern mot program för att få åtkomst till de nya servrar som körs i Azure. Precis som med CI/CD-problemen måste du se till att de nödvändiga nätverkssäkerhetsreglerna tillåter dina tester att komma åt de program som distribueras till Azure. Mer information finns i Nätverkssäkerhetsgrupper.

Efter migreringen

När du har nått de migreringsmål som du definierade i steget före migreringen, så utför några godkännandetester från slutpunkt till slutpunkt för att se att allt fungerar som förväntat. Följande artiklar innehåller information om förbättringar efter migreringen: