Migrace serverových aplikací WebLogic do služby Azure Virtual Machines

  • Článek

Tato příručka popisuje, o čem byste měli vědět, když chcete migrovat existující aplikaci WebLogic tak, aby byla provozovaná ve službě Azure Virtual Machines. Přehled dostupných řešení Serveru WebLogic na Azure Marketplace najdete v tématu Co jsou řešení pro spouštění Oracle WebLogic Serveru na virtuálních počítačích Azure?

Před migrací

Pokud chcete zajistit úspěšnou migraci, dokončete kroky posouzení a inventáře popsané v následujících částech.

Definice, co se rozumí pod pojmem „Migrace je hotová“

Tato příručka a odpovídající nabídky Azure Marketplace představují výchozí bod k urychlení migrace úloh serveru WebLogic Server do Azure. Je důležité definovat rozsah své migrace. Provádíte například migraci striktně metodou „lift and shift“ z existující infrastruktury do služby Azure Virtual Machines? Pokud ano, možná budete v pokušení při migraci provést nějaká vylepšení.

Je lepší se v maximální míře držet čisté metody „lift and shift“, ale vzít v úvahu nutné změny, jak je podrobně popsáno v této příručce. Definujte, co se rozumí pod pojmem „Migrace je hotová“, abyste věděli, kdy jste tohoto milníku dosáhli. Jakmile dosáhnete bodu „Migrace je hotová“, můžete pořídit snímek služby Virtual Machines, jak je popsáno v tématu Vytvoření snímku. Po ověření úspěšného obnovení ze snímku můžete provést vylepšení bez obav ze ztráty průběhu migrace, kterého jste zatím dosáhli.

Ujistěte se, že cíl je vhodným cílem pro vaše úsilí o migraci.

Prvním krokem úspěšné migrace aplikace WLS do Azure je výběr nejvhodnějšího cíle migrace. Služba WLS funguje dobře na virtuálních počítačích Azure nebo ve službě Azure Kubernetes Service (AKS). Cíl virtuálního počítače je nejjednodušší volbou, protože se nejvíce podobá místnímu nasazení. Prostředí pro správu a nasazení virtuálních počítačů je velmi podobné tomu, co máte místně. Kompromis pro tuto jednoduchost je ekonomické náklady. Obecně řečeno, náklady na minutu pro řešení založené na virtuálních počítačích jsou ve srovnání s AKS vyšší. I když řešení založené na AKS stojí méně, aby běžela, musíte aplikaci omezit tak, aby vyhovovala požadavkům AKS. Pokud je minimalizace změn nejdůležitějším faktorem pro vaše úsilí o migraci, zvažte migraci založenou na virtuálních počítačích. V tomto případě si přečtěte téma Migrace aplikací WebLogic do služby Azure Virtual Machines. Pokud můžete tolerovat převod aplikace tak, aby běžela v rámci Kubernetes, abyste snížili náklady na běh, zvažte migraci založenou na AKS. V tomto případě pokračujte v migraci aplikací Serveru WebLogic do služby Azure Kubernetes Service.

Určení, jestli jsou předem připravené nabídky Azure Marketplace dobrým výchozím bodem

Oracle a Microsoft se spojili s uvedením sady šablon řešení Azure na Azure Marketplace, které poskytují solidní výchozí bod pro migraci do Azure. Seznam nabídek naleznete v dokumentaci Oracle Fusion Middleware. Vyberte tu, která nejlépe odpovídá vašemu stávajícímu nasazení. Seznam nabídek najdete v článku s přehledem Co je Oracle WebLogic Server v Azure?

Pokud žádná z existujících nabídek není dobrým výchozím bodem, musíte nasazení reprodukovat ručně pomocí prostředků virtuálního počítače Azure. Podrobné pokyny najdete v tématu Ruční instalace Serveru Oracle WebLogic na virtuálních počítačích Azure. Další informace najdete v tématu Co je IaaS?

Určení, zda je verze WebLogic kompatibilní

Vaše stávající verze WebLogic musí být kompatibilní s verzí v nabídkách IaaS. Pokud chcete zobrazit nabídky pro WebLogic verze 12.2.1.4, zadejte dotaz na Azure Marketplace pro Oracle WebLogic 12.2.1.4. Pokud vaše stávající verze WebLogic není kompatibilní s danou verzí, musíte nasazení reprodukovat ručně pomocí prostředků Azure IaaS. Další informace najdete v dokumentaci k Azure.

Inventarizace kapacity serverů

Zdokumentujte hardware (paměť, procesor, disk) aktuálních produkčních serverů a také průměrný a maximální počet žádostí a využití prostředků. Výběr velikosti virtuálního počítače musí vycházet z těchto údajů. Další informace najdete v článku Velikosti cloudových služeb.

Inventarizace všech tajných kódů

Před nástupem technologií „konfigurace jako služba“ typu Azure Key Vault neexistoval řádně definovaný koncept „tajných kódů“. Místo toho jste měli různorodou sadu konfiguračních nastavení, která v podstatě fungovala stejně jako dnešní „tajné kódy“. Při používání aplikačních serverů, jako je server WebLogic, se tyto tajné kódy nacházejí v mnoha různých konfiguračních souborech a úložištích konfigurací. Ve všech vlastnostech a konfiguračních souborech na produkčních serverech vyhledejte tajné kódy a hesla. Nezapomeňte zkontrolovat soubor weblogic.xml v souborech WAR. Konfigurační soubory obsahující hesla nebo přihlašovací údaje se mohou nacházet také ve vaší aplikaci. Další informace najdete v článku Základní koncepty služby Azure Key Vault.

Inventarizace všech certifikátů

Zdokumentujte všechny certifikáty používané pro veřejné koncové body SSL. Všechny certifikáty na produkčních serverech zobrazíte spuštěním následujícího příkazu:

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

Ověření správné funkce podporované verze jazyka Java

Všechny způsoby migrace WebLogic do Azure vyžadují specifickou verzi jazyka Java, která je pro jednotlivé způsoby odlišná. Budete muset ověřit, že je vaše aplikace schopna správně fungovat při používání podporované verze.

Poznámka:

Toto ověření je obzvláště důležité, pokud se váš aktuální server provozuje na nepodporované sadě JDK (například Oracle JDK nebo IBM OpenJ9).

Aktuální verzi jazyka Java získáte tak, že se přihlásíte k produkčnímu serveru a spustíte následující příkaz:

java -version

Poznámka:

Při migraci na službu WLS na virtuálních počítačích Azure se požadavky na konkrétní verze Javy určují předem nainstalovanou javou na virtuálních počítačích. Při migraci na WLS v AKS se konkrétní verze Javy určuje zvolená image kontejneru. Existuje celá řada možností, ale všechny používají sadu Oracle JDK.

Inventarizace prostředků JNDI

Proveďte inventarizaci všech prostředků JNDI. Zdroje dat, jako jsou databáze, mohou mít například přidružený název JNDI, který umožňuje JPA správně navazovat instance EntityManager ke konkrétní databázi. Další informace o prostředcích a databázích JNDI najdete v článku Zdroje dat serveru WebLogic v dokumentaci Oracle. Jiné prostředky související s JNDI, například zprostředkovatelé zpráv JMS, mohou vyžadovat migraci nebo změnu konfigurace. Další informace o konfiguraci JMS naleznete v tématu Oracle WebLogic Server 12.2.1.4.0.

Kontrola konfigurace domény

Hlavní konfigurační jednotkou na serveru WebLogic je doména. Soubor config.xml obsahuje rozsáhlou konfiguraci, kterou při migraci musíte pečlivě zvážit. Tento soubor obsahuje odkazy na další soubory XML, které jsou uložené v podadresářích. Oracle doporučuje, abyste ke konfiguraci spravovatelných objektů a služeb serveru WebLogic normálně používali konzolu pro správu a umožnili serveru WebLogic spravovat soubor config.xml. Další informace najdete v článku Konfigurační soubory domény.

Ve vaší aplikaci

Prověřte soubor WEB-INF/weblogic.xml a/nebo soubor WEB-INF/web.xml.

Určení, zda se používá replikace relace

Pokud vaše aplikace spoléhá na replikaci relace, ať už s modulem Oracle Coherence*Web nebo bez něj, máte tři možnosti:

  • Coherence*Web může běžet spolu se serverem WebLogic na virtuálních počítačích Azure, ale tuto možnost musíte po zřízení nabídky ručně nakonfigurovat. Pokud používáte samostatný modul Coherence, můžete ho také spustit na virtuálním počítači Azure, ale tuto možnost musíte po zřízení nabídky ručně nakonfigurovat.
  • Refaktorujte aplikaci tak, aby používala databázi pro správu relace.
  • Refaktorujte aplikaci tak, aby externalizovala relaci do služby Azure Redis. Další informace najdete v článku, který se věnuje službě Azure Cache for Redis.

U všech těchto možností je vhodné osvojit si znalosti toho, jak WebLogic provádí replikaci stavu relace HTTP. Další informace najdete v článku, který se věnuje replikaci stavu relace HTTP v dokumentaci společnosti Oracle.

Dokumentování zdrojů dat

Pokud vaše aplikace používá nějaké databáze, potřebujete shromáždit 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 o ovladačích JDBC u serveru WebLogic najdete v článku o používání ovladačů JDBC se serverem WebLogic.

Určení, zda byla platforma WebLogic přizpůsobena

Určete, která z následujících přizpůsobení byla provedena, a zachyťte provedenou akci.

  • Došlo ke změně spouštěcích skriptů? Mezi tyto skripty patří setDomainEnv, commEnv, startWebLogic a stopWebLogic.
  • Byly do prostředí JVM předány nějaké konkrétní parametry?
  • Byly do cesty ke třídě serveru přidány nějaké soubory JAR?

Určení, zda se používá správa přes REST

Pokud životní cyklus vaší aplikace zahrnuje používání funkce správy přes REST, musíte zachytit, které porty slouží pro přístup k rozhraní REST API, a určit, jak se ověřují a zveřejňují. Po migraci budete muset zajistit, že se zveřejní tyto porty a ověřovací mechanismy, aby vaše aplikace mohla fungovat podobně jako před migrací. Další informace najdete v tématu, které se věnuje správě serveru Oracle WebLogic pomocí služeb pro správu RESTful.

Určení, jestli je potřeba připojení k místnímu prostředí

Pokud vaše aplikace potřebuje přístup k některým místním službám, budete muset zřídit jednu ze služeb připojení Azure. Další informace najdete v článku věnovaném připojení místní sítě k Azure. Alternativně budete muset aplikaci refaktorovat tak, aby používala veřejně přístupná rozhraní API, která nabízejí vaše místní prostředky.

Určení, jestli se používají fronty nebo témata JMS (Java Message Service)

Pokud vaše aplikace používá fronty nebo témata JMS, budete je muset migrovat na externě hostovaný server JMS. Pro aplikace používající JMS může skvělou migrační strategii představovat Azure Service Bus a rozšířený protokol řízení front zpráv (AMQP). Další informace najdete v tématu Použití služby Java Message Service 1.1 se standardem služby Azure Service Bus a AMQP 1.0.

Pokud jste nakonfigurovali trvalá úložiště JMS, musíte zachytit jejich konfiguraci a po migraci ji použít.

Pokud používáte Oracle Message Broker, můžete tento software migrovat do virtuálních počítačů Azure a používat ho beze změny.

Určení, jestli používáte své vlastní vytvořené sdílené knihovny Java EE

Pokud používáte funkci sdílených knihoven Java EE, máte dvě možnosti:

  • Refaktorováním kódu své aplikace odeberte všechny závislosti na těchto knihovnách a místo toho začleňte jejich funkčnost přímo do aplikace.
  • Přidejte tyto knihovny do cesty ke třídám serveru.

Určení, jestli se používají sady OSGi

Pokud jste použili sady OSGi přidané na server WebLogic, budete muset přidat ekvivalentní soubory JAR přímo do webové aplikace.

Určení, jestli aplikace obsahuje kód specifický pro operační systém

Pokud vaše aplikace obsahuje jakýkoli kód se závislostmi na hostitelském operačním systému, musíte ho refaktorovat, abyste tyto závislosti odebrali. Může být například nutné nahradit jakékoli použití / cest systému souborů nebo \ v cestě File.Separator k systému souborů nebo Paths.get v případě, že je vaše aplikace spuštěná ve Windows.

Určení, jestli se používá Oracle Service Bus

Pokud vaše aplikace používá Oracle Service Bus (OSB), budete muset zjistit konfiguraci OSB. Další informace najdete v článku Informace o instalaci Oracle Service Bus.

Určení, jestli se aplikace skládá z několika souborů WAR

Pokud se vaše aplikace skládá z několika souborů WAR, měli byste s těmito soubory WAR zacházet jako se samostatnými aplikacemi a projít tuto příručku pro každý z nich.

Určení, jestli je aplikace zabalená jako soubor EAR

Pokud je vaše aplikace zabalená jako soubor EAR, prověřte soubory application.xml a weblogic-application.xml a poznačte si jejich konfiguraci.

Zjištění všech vnějších procesů a démonů běžících na produkčních serverech

Pokud používáte nějaké procesy, které běží mimo aplikační server, například monitorovací démony, budete je muset eliminovat nebo migrovat jinam.

Určení, jestli se používá nástroj WLST (WebLogic Scripting Tool)

Pokud k nasazování aktuálně používáte nástroj WLST, budete muset vyhodnotit, co dělá. Pokud nástroj WLST mění jako součást nasazení nějaké (běhové) parametry vaší aplikace, budete se při testování aplikace po migraci muset ujistit, že toto chování nadále funguje.

Určení, jestli a jak se používá systém souborů

Systémy souborů virtuálních počítačů fungují z hlediska trvalosti, spouštění a vypínání stejně jako místní systémy souborů. I tak je důležité mít na paměti potřeby systému souborů a zajistit, aby virtuální počítače měly odpovídající velikost úložiště a výkon.

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.

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.

Určení síťové topologie

Aktuální sada nabídek Azure Marketplace je výchozím bodem pro vaši migraci. Pokud daná nabídka nepokrývá aspekty vaší architektury, kterou potřebujete migrovat, budete muset zjistit síťovou topologii stávajícího nasazení a reprodukovat ji v Azure, a to i po zavedení základní nabídky pomocí některé ze šablon řešení.

Toto téma je velmi rozsáhlé, následující odkazy ale mohou vaše migrační úsilí nasměrovat správným směrem:

  • Tento odkaz obsahuje výčet témat vysoké úrovně, která jsou relevantní pro migraci síťové topologie do Azure: Příručka pro rychlé sledování nasazení.
  • Tento odkaz popisuje důležité aspekty clusteringu, které mají vliv na topologii sítě: Clustering serveru WebLogic.
  • Protože zdroje dat jsou v systému WebLogic samostatnými servery, musíte je při analýze síťové topologie vzít do úvahy. Zdroje dat serveru WebLogic.
  • Také zdroje zasílání zpráv jsou samostatnými servery. Zasílání zpráv serveru WebLogic.
  • Vyrovnávání zatížení je zásadním požadavkem. Tento odkaz se věnuje straně serveru WebLogic vyrovnávání zatížení: Vyrovnávání zatížení v clusteru.

Ohled na používání adaptérů JCA a adaptérů prostředků

Pokud vaše existující aplikace používá adaptéry JCA a/nebo adaptéry prostředků pro připojení k jiným podnikovým systémům, zajistěte, aby konfigurace těchto artefaktů byla použita u serveru WebLogic provozovaného ve službě Azure Virtual Machines. Další informace najdete v článku Vytvoření a konfigurace adaptérů prostředků.

Účet pro použití vlastních poskytovatelů zabezpečení a JAAS

Pokud vaše aplikace používá JAAS, musíte zajistit správnou migraci konfigurace poskytovatelů zabezpečení. Další informace najdete v tématu, které se věnuje konfiguraci poskytovatelů zabezpečení WebLogic v dokumentaci společnosti Oracle.

Určení, jestli se používá clustering WebLogic

Kvůli dosažení vysoké dostupnosti jste aplikaci pravděpodobně nasadili na několik serverů WebLogic. Tyto clustery můžete migrovat přímo z místní instalace do služby WebLogic provozované ve službě Azure Virtual Machines. Další informace najdete v článku Konfigurační soubory domény v dokumentaci Oracle.

Účet pro požadavky na vyrovnávání zatížení

Vyrovnávání zatížení je základní součástí migrace clusteru Oracle WebLogic Serveru do Azure. Nejjednodušším řešením je použít integrovanou podporu pro Aplikace Azure lication Gateway poskytovanou v nabídce Azure Marketplace pro cluster Serveru Oracle WebLogic. Kurz k tomuto tématu najdete v tématu Kurz: Migrace clusteru serveru WebLogic do Azure s Aplikace Azure lication Gateway jako nástrojem pro vyrovnávání zatížení.

Souhrn možností Aplikace Azure lication Gateway v porovnání s jinými řešeními pro vyrovnávání zatížení Azure najdete v tématu Přehled možností vyrovnávání zatížení v Azure.

Určení, jestli se používá funkce klienta aplikace Java EE

Pokud vaše aplikace používá funkci klienta aplikace Java EE, měla by po migraci do služby Azure Virtual Machines fungovat beze změny. Další informace najdete v článku Používání modulů klientských aplikací Java EE.

Migrace

Výběr WebLogic v nabídce Azure Virtual Machines

Následující nabídky jsou k dispozici pro WebLogic ve službě Azure Virtual Machines.

Během nasazování nabídky se zobrazí výzva k výběru velikosti virtuálního počítače pro uzly serveru WebLogic. Při výběru velikosti virtuálního počítače je důležité zvážit všechny aspekty změny velikosti (paměť, procesor, disk). Další informace najdete v dokumentaci k Azure pro změnu velikosti virtuálních počítačů.

Jeden uzel serveru WebLogic bez serveru pro správu

Tato nabídka vytvoří jeden virtuální počítač a nainstaluje na něj WebLogic, ale nenakonfiguruje žádné domény. To je užitečné ve scénářích, ve kterých máte vysoce přizpůsobenou konfiguraci domény.

Jeden uzel serveru WebLogic se serverem pro správu

Tato nabídka zřídí jeden virtuální počítač a nainstaluje na něj Server WebLogic. Vytvoří doménu a spustí server pro správu.

Cluster více uzlů serveru WebLogic

Tato nabídka vytvoří vysoce dostupný cluster virtuálních počítačů serveru WebLogic.

Dynamický cluster více uzlů serveru WebLogic

Tato nabídka vytvoří vysoce dostupný a škálovatelný dynamický cluster virtuálních počítačů serveru WebLogic.

Zřízení nabídky

Po výběru nabídky, se kterou chcete začít, zřiďte nabídku podle pokynů v dokumentaci k nabídkám. Nezapomeňte vybrat název domény, který odpovídá názvu vaší stávající domény. Můžete dokonce spárovat heslo domény s heslem stávající domény.

Migrace domén

Po zřízení nabídky můžete prozkoumat konfiguraci domény a podle tohoto postupu zjistit podrobnosti, jak domény migrovat.

Připojení databází

Po migraci domén můžete databáze připojit podle pokynů v dokumentaci k nabídce. Tyto pokyny vám pomůžou počítat s veškerými tajnými kódy databáze a připojovacími řetězci.

Účet pro úložiště klíčů

Musíte zajistit migraci všech úložišť klíčů SSL, které aplikace používá. Další informace najdete v tématu Konfigurace úložišť klíčů.

Připojení zdrojů JMS

Po připojení databází můžete nakonfigurovat JMS. Další informace naleznete v tématu Fusion Middleware Správa prostředků JMS pro Oracle WebLogic Server v dokumentaci WebLogic.

Účet pro ověřování a autorizaci

Většina aplikací má nějaký druh ověřování a autorizace. Pokud pro ověřování používáte protokol LDAP, můžete nastavit službu Microsoft Entra Domain Services se zabezpečeným protokolem LDAP a nakonfigurovat připojení LDAP na serveru WebLogic. Další informace naleznete v tématu Vytvoření a konfigurace spravované domény služby Microsoft Entra Domain Services a konfigurace protokolu LDAP pro spravovanou doménu služby Microsoft Entra Domain Services.

Účet pro protokolování

Použijte integraci s Elastic v Azure poskytovanou šablonami řešení Oracle WebLogic Server Marketplace. Tento přístup představuje nejjednodušší způsob, jak se přihlásit. Seznam nabídek najdete v článku Přehled: Co jsou řešení pro provozování Oracle WebLogic Serveru na virtuálních počítačích Azure? Kompletní kurzy ke konfiguraci Elastic jsou k dispozici v následujících kurzech:

Pokud elastická integrace není vhodná, měli byste při migraci domény přenést stávající konfiguraci protokolování. Další informace naleznete v tématu Konfigurace úrovní protokolovacího nástroje java.util.logging a konfigurace souborů protokolu a filtrování zpráv protokolu pro Oracle WebLogic Server v dokumentaci Oracle.

Migrace aplikací

Techniky používané k nasazení aplikací z vývoje na testovací, přípravné a produkční servery se v jednotlivých případech velmi liší. V některých případech existuje vysoce vyvinutá platforma CI/CD, která vede k nasazení aplikací na server WebLogic. V jiných případech může být nutné některé kroky provést ručně. Jednou z výhod použití služby Azure Virtual Machines k migraci aplikací WebLogic do cloudu je to, že vaše stávající procesy budou dál fungovat.

Musíte nakonfigurovat skupinu zabezpečení sítě, kterou nabídka zřizuje, aby umožňovala přístup z kanálu CI/CD nebo systému ručního nasazení. Další informace najdete v tématu Skupiny zabezpečení sítě.

Testování

Všechny testy v kontejnerech proti aplikacím musí být nakonfigurovány tak, aby měly přístup k novým serverům běžícím v Azure. Stejně jako v případě problémů s CI/CD musíte zajistit, aby vaše testy umožňovaly přístup k aplikacím nasazeným do Azure. Další informace najdete v tématu Skupiny zabezpečení sítě.

Po migraci

Po dosažení cílů migrace, které jste definovali v části Před migrací, proveďte několik kompletních akceptačních testů, abyste ověřili, že vše funguje podle očekávání. Pokyny k některým možným vylepšením po migraci najdete v následujících doporučeních: