Udostępnij za pośrednictwem

Migrowanie aplikacji serwera WebLogic do usługi Azure Kubernetes Service (AKS)

  • Artykuł

W tym przewodniku opisano, co należy wiedzieć, kiedy chcesz przeprowadzić migrację istniejącej aplikacji serwera WebLogic (WLS) do uruchomienia w usłudze Azure Kubernetes Service (AKS).

Przed migracją

Aby zapewnić pomyślną migrację, przed rozpoczęciem wykonaj kroki oceny i spisu opisane w poniższych sekcjach.

Upewnij się, że element docelowy jest odpowiednim celem dla nakładu pracy nad migracją

Pierwszym krokiem pomyślnej migracji aplikacji WLS na platformę Azure jest wybranie najbardziej odpowiedniego celu migracji. Usługa WLS działa dobrze na maszynach wirtualnych platformy Azure lub w usłudze Azure Kubernetes Service (AKS). Obiekt docelowy maszyny wirtualnej jest najprostszym wyborem, ponieważ najbardziej przypomina wdrożenie lokalne. Środowisko administracyjne i wdrożeniowe dla maszyn wirtualnych jest bardzo podobne do środowiska lokalnego. Kompromisem za tę łatwość jest koszt ekonomiczny. Ogólnie rzecz biorąc, koszt za minutę rozwiązania opartego na maszynie wirtualnej jest wyższy w porównaniu z usługą AKS. Chociaż rozwiązanie oparte na usłudze AKS kosztuje mniej do uruchomienia, należy ograniczyć aplikację, aby mieściła się w wymaganiach usługi AKS. Jeśli minimalizacja zmian jest najważniejszym czynnikiem dla nakładu pracy nad migracją, rozważ migrację opartą na maszynie wirtualnej. W tym przypadku zobacz Migrowanie aplikacji WebLogic do usługi Azure Virtual Machines. Jeśli możesz tolerować konwertowanie aplikacji do uruchomienia w ramach platformy Kubernetes w celu zmniejszenia kosztów środowiska uruchomieniowego, rozważ migrację opartą na usłudze AKS. W takim przypadku kontynuuj migrację aplikacji serwera WebLogic do usługi Azure Kubernetes Service.

Określanie, czy wstępnie utworzona oferta witryny Azure Marketplace jest dobrym punktem wyjścia

Po podjęciu decyzji, że usługa AKS jest odpowiednim celem wdrożenia, musisz zaakceptować, że operator Oracle WLS Kubernetes (operator) jest jedynym sposobem uruchamiania zabezpieczeń WLS na platformie Kubernetes. Po zaakceptowaniu tego faktu musisz zdecydować, czy wstępnie utworzona oferta witryny Azure Marketplace jest dobrym punktem wyjścia. Poniżej przedstawiono kilka kwestii, które należy wziąć pod uwagę wstępnie utworzoną ofertę witryny Azure Marketplace.

  • Firma Oracle i firma Microsoft utworzyły tę ofertę, aby umożliwić szybką aprowizację zabezpieczeń WLS w usłudze AKS przy użyciu typu źródła głównego domeny obrazów. Ta koncepcja jest bardziej szczegółowo wyjaśniona w dalszej części tego artykułu.
  • Na wysokim poziomie oferta automatyzuje następujące kroki.
    • W razie potrzeby przejmij istniejące wdrożenie WAR lub EAR.
    • Opakuj go w kontenerze przy użyciu narzędzia WebLogic Image Tool (WIT). Aby uzyskać więcej informacji, zobacz WebLogic Image Tool w dokumentacji oracle.
    • Zainstaluj i skonfiguruj operator Kubernetes WebLogic w usłudze AKS.
    • Użyj operatora , aby uruchomić całość. Operator wywołuje narzędzie WebLogic Deploy Tooling (WDT), aby wstać środowiska WebLogic i wykonywać operacje cyklu życia domeny w powtarzalny sposób na podstawie modelu metadanych. Aby uzyskać więcej informacji, zobacz WebLogic Deploy Tooling (Narzędzia webLogic Deploy) w dokumentacji oracle.
  • Mimo że wstępnie utworzona oferta zapewnia wiele integracji usług platformy Azure, takich jak Usługa App Gateway, rejestrowanie elastyczne, integracja z bazą danych i nie tylko, upraszcza wiele założeń. Te założenia sprawiają, że oferta nie jest tak elastyczna, jak opanowanie i korzystanie z operatora samodzielnie.

Jeśli nie używasz wstępnie utworzonej oferty witryny Azure Marketplace, musisz dowiedzieć się, jak bezpośrednio używać operatora. Opanowanie operatora wykracza poza zakres tego artykułu. Pełna dokumentacja operatora Kubernetes WLS jest dostępna w witrynie Oracle.

W pozostałej części tej sekcji przedstawiono pewne zagadnienia dotyczące podejmowania decyzji o użyciu wstępnie utworzonej oferty witryny Azure Marketplace lub bezpośredniego korzystania z operatora.

Zdecyduj, czy używać wstępnie utworzonej oferty witryny Azure Marketplace

Najpierw musisz zrozumieć koncepcję "domeny" w usłudze WLS. Domena jest logicznie powiązaną grupą zasobów WLS. Aby zapoznać się z definicją kanoniczną domeny WLS, zobacz dokumentację oracle. Uruchamianie usługi WLS w usłudze AKS wymaga podjęcia decyzji, w jaki sposób usługa AKS zajmuje się domenami. Różne opcje są określane jako "typ źródła macierzystego domeny". Operator WLS Kubernetes obsługuje trzy opcje typu źródła macierzystego domeny. Wstępnie utworzona oferta witryny Azure Marketplace używa pierwszej w tej tabeli.

Typ źródła macierzystego domeny opis Aspekty pozytywne Aspekty negatywne
Model na obrazie Zabezpieczenia WLS i aplikacje znajdują się w obrazie kontenera, a wszystkie inne elementy są przechowywane poza tym obrazem. Obsługiwane przez wstępnie utworzoną ofertę. Udokumentowane jako oficjalny przykład; zobacz Oracle. W większości przypadków jest używany WDT. Większość opcji "natywna dla chmury". Najprostsza integracja ciągłej integracji/ciągłego wdrażania. Największa krzywa uczenia.
Domena w pv Domena znajduje się na trwałym woluminie Kubernetes. Koncepcyjnie podobne do uruchamiania na maszynach wirtualnych. Za pomocą konsoli WLS można wprowadzać zmiany, a te zmiany są utrwalane podczas ponownego uruchamiania zasobnika usługi AKS. Udokumentowane jako oficjalny przykład; zobacz Oracle. Niektóre wyzwania związane z systemem plików NFS muszą zostać złagodzone. Aby uzyskać więcej informacji, zobacz Oracle. Takie podejście jest najmniej "natywną dla chmury" techniką; stan znajduje się całkowicie poza klastrem usługi AKS.
Domena na obrazie Domena znajduje się w obrazie kontenera. Aplikacje znajdują się w obrazie kontenera, który jest nakładany na obraz domeny. Więcej "natywne dla chmury" niż domena w pv. Łatwiejsze w przypadku ciągłej integracji/ciągłego wdrażania. Nie można użyć konsoli WLS. Musi obsługiwać więcej obrazów kontenerów.

Ważne

Jeśli wybierzesz domenę w typie źródła PV , zdecydowanie zalecamy system plików NFS zamiast SMB. System NFS ewoluował z systemu operacyjnego UNIX i innych wariantów, takich jak GNU/Linux. Z tego powodu w przypadku korzystania z systemu plików NFS z technologiami kontenerów, takimi jak Docker, jest mniej prawdopodobne, że występują problemy z równoczesnymi operacjami odczytu i blokowania plików.

Pamiętaj o włączeniu systemu plików NFS w wersji 4.1. Wersje niższe niż wersja 4.1 będą miały problemy.

Dokumentacja operatora zawiera również przydatną tabelę porównującą różne opcje. Aby uzyskać więcej informacji, zobacz Wybieranie typu źródła macierzystego domeny.

Aby zapoznać się ze wstępnie utworzoną ofertą witryny Azure Marketplace, zobacz Szybki start: wdrażanie serwera WebLogic w usłudze Azure Kubernetes Service przy użyciu witryny Azure Portal. Aby uzyskać dokumentację referencyjną dotyczącą wstępnie utworzonej oferty witryny Azure Marketplace, zobacz Oracle.

Aby uzyskać bezpośredni dostęp do korzystania z operatora, wypróbuj przykłady w dokumentacji operatora.

Teraz, po wprowadzeniu różnych sposobów obsługi domen WLS w usłudze AKS, lepiej możesz wybrać, czy używać wstępnie utworzonej oferty witryny Azure Marketplace, czy zrobić to samodzielnie przy użyciu operatora bezpośrednio.

Ustalenie, czy wersja serwera WebLogic jest zgodna

Istniejąca wersja ZLS musi być jedną z wersji obsługiwanych przez operatora. Firma Oracle obsługuje te wersje w usłudze Oracle Container Registry (OCR). Wykonaj poniższe kroki, aby wyświetlić listę obsługiwanych wersji.

  1. Odwiedź witrynę internetową oracle Container Registry i zaloguj się. Aby uzyskać więcej informacji, zobacz https://container-registry.oracle.com/.
  2. Jeśli masz uprawnienie do pomocy technicznej, wybierz pozycję Oprogramowanie pośredniczące, a następnie wyszukaj weblogic_cpu. Wybierz pozycję weblogic_cpu.
  3. Jeśli nie masz uprawnień do pomocy technicznej z witryny Oracle, wybierz pozycję Oprogramowanie pośredniczące, a następnie wyszukaj aplikację weblogic. Wybierz pozycję weblogic.

Uwaga

Uzyskaj uprawnienie do pomocy technicznej od firmy Oracle przed przejściem do środowiska produkcyjnego. Niepowodzenie w tym celu powoduje uruchomienie niezabezpieczonych obrazów, które nie są poprawiane pod kątem krytycznych wad zabezpieczeń. Aby uzyskać więcej informacji na temat aktualizacji poprawek krytycznych firmy Oracle, zobacz Aktualizacje poprawek krytycznych, alerty zabezpieczeń i biuletyny.

Wstępnie utworzona oferta witryny Azure Marketplace umożliwia wybranie obrazów WLS z usług OCR i Azure Container Registry (ACR), a tym samym niejawnie obsługuje wszystkie wersje dostępne w usłudze OCR. Jeśli kierujesz ofertę do ściągnięcia obrazu z usługi ACR, upewnij się, że pochodzi ona z jednej z obsługiwanych wersji wymienionych w usłudze OCR.

Utworzenie spisu pojemności serwerów

Udokumentowanie sprzętu (pamięci, procesora CPU, dysku) bieżących serwerów produkcyjnych oraz średniej i szczytowej liczby żądań oraz wykorzystania zasobów. Te informacje będą potrzebne niezależnie od wybranej ścieżki migracji. Jest to przydatne, na przykład, aby ułatwić wybór rozmiaru maszyn wirtualnych w puli węzłów, ilość pamięci używanej przez kontener oraz liczbę udziałów procesora CPU w kontenerze.

Istnieje możliwość zmiany rozmiaru pul węzłów w usłudze AKS. Aby dowiedzieć się, jak to zrobić, zobacz Zmienianie rozmiaru pul węzłów w usłudze Azure Kubernetes Service (AKS).

Utworzenie spisu wszystkich wpisów tajnych

Przed pojawieniem się technologii typu „konfiguracja jako usługa”, takich jak usługa Azure Key Vault, nie było dobrze zdefiniowanego pojęcia „wpisu tajnego”. Zamiast tego korzystano z odrębnych zestawów ustawień konfiguracji, które efektywnie funkcjonowały jak dzisiejsze „wpisy tajne”. W przypadku serwerów aplikacji, takich jak serwer WebLogic, te wpisy tajne znajdują się w wielu różnych plikach konfiguracji i w magazynach konfiguracji. Sprawdź wszystkie pliki właściwości i konfiguracji na serwerach produkcyjnych kątem jakichkolwiek wpisów tajnych i haseł. Sprawdź plik weblogic.xml w swoich plikach WAR. Możesz również znaleźć pliki konfiguracji zawierające hasła lub poświadczenia wewnątrz aplikacji. Aby uzyskać więcej informacji, zobacz Podstawowe pojęcia dotyczące usługi Azure Key Vault.

Po utworzeniu solidnego spisu wpisów tajnych zapoznaj się z dokumentacją operatora dotyczącą wpisów tajnych. Aby uzyskać więcej informacji, zobacz Wpisy tajne.

Utworzenie spisu wszystkich certyfikatów

Zapisz wszystkie certyfikaty używane na potrzeby publicznych punktów końcowych protokołu SSL. Wszystkie certyfikaty na serwerach produkcyjnych można wyświetlić, uruchamiając następujące polecenie:

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

Po utworzeniu solidnego spisu certyfikatów można je zainstalować bezpośrednio za pomocą wstępnie utworzonej oferty witryny Azure Marketplace. Aby uzyskać więcej informacji, zobacz Konfiguracja protokołu TLS/SSL. Jeśli używasz operatora bezpośrednio, zobacz Aktualizowanie certyfikatów zewnętrznych operatora.

Sprawdzanie, czy obsługiwana wersja języka Java działa poprawnie

Wszystkie ścieżki migracji z serwera WebLogic na platformę Azure wymagają konkretnej wersji języka Java, która różni się w zależności od ścieżki. Musisz sprawdzić, czy Twoja aplikacja może działać prawidłowo, używając tej obsługiwanej wersji.

Uwaga

Ta weryfikacja jest szczególnie ważna, jeśli bieżący serwer działa na nieobsługiwanym zestawie JDK (na przykład Oracle JDK lub IBM OpenJ9).

Aby uzyskać informacje na temat bieżącej wersji języka Java, zaloguj się na serwerze produkcyjnym i uruchom następujące polecenie:

java -version

Uwaga

Podczas migracji do usługi WLS na maszynach wirtualnych platformy Azure wymagania dotyczące określonych wersji języka Java są określane przez wstępnie zainstalowane środowisko Java na maszynach wirtualnych. Podczas migracji do usługi WLS w usłudze AKS określona wersja języka Java jest określana przez wybrany obraz kontenera. Istnieje wiele różnych opcji, ale wszystkie z nich korzystają z zestawu Oracle JDK.

Utworzenie spisu zasobów JNDI

Utwórz spis wszystkich zasobów JNDI. Na przykład źródła danych, takie jak bazy danych, mogą mieć skojarzoną nazwę JNDI, która umożliwia interfejsowi JPA prawidłowe powiązanie wystąpień EntityManager z określoną bazą danych. Aby uzyskać więcej informacji na temat zasobów i baz danych JNDI, zobacz WebLogic Server Data Sources (Źródła danych serwera WebLogic) w dokumentacji firmy Oracle. Inne zasoby związane z JNDI, takie jak broker komunikatów JMS, mogą wymagać migracji lub ponownej konfiguracji. Aby uzyskać więcej informacji na temat konfiguracji pakietu JMS, zobacz Oracle WebLogic Server 12.2.1.4.0.

Jeśli używasz wstępnie utworzonej oferty witryny Azure Marketplace, zestaw zasobów JNDI, które można dostosować w czasie wdrażania, jest ograniczony do tego, co obsługuje oferta. Wyszukaj ciąg JNDI w dokumentacji oferty. Jeśli używasz operatora bezpośrednio, zasoby JDNI można zdefiniować w zależności od wybranego typu źródła macierzystego domeny. W przypadku domeny w trybie PV można ustawić je w zwykły sposób, przy użyciu narzędzia WLST lub konsoli administracyjnej. Aby uzyskać informacje o domenie w obrazie lub modelu na obrazie, zobacz Typowe przesłonięcia.

Sprawdzanie konfiguracji domeny

Główną jednostką konfiguracji na serwerze WebLogic jest domena. W związku z tym plik config.xml zawiera wiele konfiguracji, nad którymi trzeba dokładnie się zastanowić podczas migracji. Plik zawiera odwołania do dodatkowych plików XML przechowywanych w podkatalogach. Firma Oracle radzi, aby do konfigurowania obiektów i usług zarządzanych przez serwer WebLogic używać zazwyczaj konsoli administracyjnej oraz zezwalać serwerowi WebLogic na obsługę pliku config.xml. Aby uzyskać więcej informacji, zobacz Pliki konfiguracji domeny.

W aplikacji

Sprawdź WEB-INF/weblogic.xml i/lub plik WEB-INF/web.xml.

Wstępnie utworzona oferta witryny Azure Marketplace automatycznie tworzy zasób domeny. Jeśli używasz operatora bezpośrednio, możesz całkowicie dostosować sposób reprezentowania domeny. Aby uzyskać pełne informacje, zobacz Zasób domeny.

Określenie, czy jest używana replikacja sesji

Jeśli aplikacja korzysta z replikacji sesji, z modułem Oracle Coherence*Web lub bez niego, masz trzy możliwości:

  • Moduł Coherence*Web można uruchamiać równolegle z serwerem WebLogic na maszynach wirtualnych platformy Azure, ale należy ręcznie skonfigurować tę opcję po aprowizacji oferty. W przypadku użycia autonomicznego modułu Coherence można również uruchomić go na maszynie wirtualnej platformy Azure, ale należy ręcznie skonfigurować tę opcję po aprowizacji oferty.
  • Refaktoryzacja aplikacji w celu użycia bazy danych do zarządzania sesją.
  • Refaktoryzacja aplikacji w celu eksternalizacji sesji do usługi Azure Redis. Aby uzyskać więcej informacji, zobacz Pamięć podręczna Azure Cache for Redis.

W przypadku wszystkich tych opcji dobrym pomysłem jest opanowanie sposobu wykonywania replikacji stanu sesji HTTP przez serwer WebLogic. Aby uzyskać więcej informacji, zobacz temat HTTP Session State Replication (Replikacja stanu sesji HTTP) w dokumentacji firmy Oracle.

Wstępnie utworzona oferta witryny Azure Marketplace obsługuje koligację sesji za pośrednictwem kontrolera ruchu przychodzącego usługi Application Gateway. Koligacja oparta na plikach cookie jest domyślnie włączona. Możesz wybrać opcję Wyłącz koligację opartą na plikach cookie, aby ją wyłączyć. Poszukaj koligacji opartej na plikach cookie w dokumentacji oferty.

Udokumentowanie źródeł danych

Jeśli aplikacja korzysta z dowolnych baz danych, należy przechwycić następujące informacje:

  • Jaka jest nazwa źródła danych?
  • Jaka jest konfiguracja puli połączeń?
  • Gdzie mogę znaleźć plik JAR sterownika JDBC?

Aby uzyskać więcej informacji na temat sterowników JDBC w usłudze WebLogic, zobacz Using JDBC Drivers with WebLogic Server (Korzystanie ze sterowników JDBC z serwerem WebLogic).

Wstępnie utworzona oferta witryny Azure Marketplace obsługuje najpopularniejsze bazy danych. Aby uzyskać więcej informacji, zobacz Baza danych. W przypadku domeny w trybie PV można ustawić je w zwykły sposób, przy użyciu narzędzia WLST lub konsoli administracyjnej. Aby uzyskać informacje o domenie w obrazie lub modelu na obrazie, zobacz Typowe przesłonięcia.

Ustalanie, czy oprogramowanie WebLogic zostało dostosowane

Ustal, które z następujących dostosowań zostały wdrożone, i określ, jakie działania zostały wykonane.

  • Czy zostały zmienione skrypty uruchamiania? Takie skrypty to setDomainEnv, commEnv, startWebLogic i stopWebLogic.
  • Czy do środowiska JVM są przekazywane określone parametry?
  • Czy do ścieżki klas serwera zostały dodane pliki JAR?

Te dostosowania należy przechwycić w obrazie kontenera uruchamianym przez usługę AKS. W przypadku wstępnie utworzonej oferty witryny Azure Marketplace takie dostosowania są najlepiej obsługiwane przez utworzenie niestandardowego obrazu kontenera i udostępnienie go w usłudze Azure Container Registry, a następnie wskazanie tego rejestru podczas wdrażania. Aby uzyskać więcej informacji, zobacz Wybór obrazu. Jeśli używasz operatora bezpośrednio, zobacz Zmienne środowiskowe opcji JVM i Pamięci JVM.

Określenie, czy używa się zarządzania za pośrednictwem interfejsu REST

Jeśli cykl życia aplikacji obejmuje zarządzanie przy użyciu interfejsu REST, należy przechwycić informacje o tym, które porty są używane w celu uzyskania dostępu do interfejsu API REST, i określić sposób ich uwierzytelniania oraz ujawniania. Po migracji należy się upewnić, że te same porty i mechanizmy uwierzytelniania są uwidocznione, aby cykl życia aplikacji mógł działać w podobny sposób, jak przed migracją. Aby uzyskać więcej informacji, zobacz Administering Oracle WebLogic Server with RESTful Management Services (Zarządzanie serwerem Oracle WebLogic Server przy użyciu usług do zarządzania opartych na interfejsie REST).

Jedynym typem źródła macierzystego domeny, w którym warto nadal używać zarządzania za pośrednictwem interfejsu REST, jest domena w trybie PV. Można go używać z innymi typami źródła macierzystego domeny, ale wprowadzone zmiany są efemeryczne i nie są utrwalane podczas ponownego uruchamiania zasobnika.

Określenie, czy jest konieczne połączenie z lokalną usługą

Jeśli aplikacja wymaga dostępu do dowolnych usług lokalnych, musisz aprowizować jedną z usług łączności platformy Azure. Aby uzyskać więcej informacji, zobacz Łączenie sieci lokalnej z platformą Azure. Możesz również przeprowadzić refaktoryzację aplikacji, aby korzystać z publicznie dostępnych interfejsów API uwidacznianych przez Twoje zasoby lokalne.

Określanie, czy używane są kolejki lub tematy Java Message Service (JMS)

Jeśli aplikacja korzysta z kolejek lub tematów JMS, należy je zmigrować do zewnętrznie hostowanego serwera JMS. Usługa Azure Service Bus i protokół Advanced Message Queuing Protocol mogą stanowić doskonałą strategię migracji w przypadku korzystania z usługi JMS. Aby uzyskać więcej informacji, zobacz Use Java Message Service 1.1 with Azure Service Bus standard and AMQP 1.0 (Używanie usługi Java Message Service Service 1.1 z usługą Azure Service Bus w warstwie Standardowa i AMQP 1.0).

W przypadku skonfigurowania magazynów trwałych usługi JMS należy przechwycić ich konfigurację i zastosować ją po migracji.

W przypadku korzystania z programu Oracle Message Broker można migrować to oprogramowanie do maszyn wirtualnych platformy Azure i używać go w niezmienionym stanie.

Ustalanie, czy są używane niestandardowe, udostępnione biblioteki Java EE

Jeśli korzystasz z funkcji udostępnionych bibliotek Java EE, masz dwie opcje:

  • Przeprowadź refaktoryzację kodu aplikacji, usuwając wszystkie zależności od bibliotek, i dołącz funkcje bezpośrednio do aplikacji.
  • Dodaj biblioteki do ścieżki klas serwera.

Te biblioteki można obsługiwać przy użyciu tych samych technik, jak opisano w artykule Określanie, czy program WebLogic został dostosowany.

Określanie, czy są używane pakiety technologii OSGi

Jeśli użyto pakietów technologii OSGi dodanych do serwera WebLogic, należy dodać równoważne pliki JAR bezpośrednio do aplikacji internetowej.

Możesz je uwzględnić w ofercie WAR lub EAR dostarczonej do wstępnie utworzonej oferty witryny Azure Marketplace lub bezpośrednio za pomocą operatora.

Określanie, czy aplikacja zawiera kod właściwy dla systemu operacyjnego

Jeśli aplikacja zawiera jakikolwiek kod z zależnościami systemu operacyjnego hosta, należy go refaktoryzować, aby usunąć te zależności. Na przykład może być konieczne zastąpienie dowolnego użycia ścieżki / systemu plików lub \ w ścieżkach File.Separator systemu plików lub Paths.get jeśli aplikacja jest uruchomiona w systemie Windows.

Usługa WLS w usłudze AKS działa w systemie Oracle Linux. Każdy kod specyficzny dla systemu operacyjnego musi być zgodny z systemem Oracle Linux. Aby dowiedzieć się, jak odnajdywać określone informacje o systemie operacyjnym, wykonaj kroki opisane w artykule Określanie, czy wersja serwera WebLogic jest zgodna.

Określenie, czy używana jest magistrala usług Oracle Service Bus

Jeśli aplikacja korzysta z magistrali usług Oracle Service Bus (OSB), należy przechwycić sposób konfiguracji OSB. Aby uzyskać więcej informacji, zobacz About the Oracle Service Bus Installation (Informacje dotyczące instalacji magistrali usług Oracle Service Bus).

System operacyjny OSB nie jest bezpośrednio obsługiwany w wstępnie utworzonej ofercie witryny Azure Marketplace. Jeśli musisz użyć systemu operacyjnego, musisz użyć operatora bezpośrednio.

Ustalanie, czy aplikacja składa się z wielu plików WAR

Jeśli Twoja aplikacja składa się z wielu plików WAR, należy traktować poszczególne pliki jako oddzielne aplikacje. W przypadku każdej z nich należy wykonać instrukcje opisane w tym przewodniku.

Ustalanie, czy aplikacja jest spakowana jako plik EAR

Jeśli Twoja aplikacja jest spakowana jako plik EAR, zarejestruj konfiguracje plików application.xml i weblogic-application.xml.

Wstępnie utworzona oferta witryny Azure Marketplace obsługuje usługi WARS i EARs. Używanie operatora bezpośrednio obsługuje również usługi WARs i EARs.

Identyfikacja wszystkich procesów i demonów zewnętrznych działających na serwerach produkcyjnych

Jeśli masz jakiekolwiek procesy działające poza serwerem aplikacji, takie jak demony monitorowania, musisz wyeliminować je lub zmigrować do innego miejsca.

Ustalanie, czy jest używane narzędzie WebLogic Scripting Tool (WLST)

Jeśli wdrożenie jest wykonywane za pomocą narzędzia WLST, należy ocenić jego działanie. Jeśli w ramach wdrożenia narzędzie WLST zmienia jakieś parametry aplikacji (w środowisku uruchomieniowym), należy się upewnić, że to zachowanie pozostanie niezmienione podczas testowania aplikacji po migracji.

Jedynym typem źródła macierzystego domeny zgodnym z użyciem biblioteki WLST jest domena w trybie PV. Aby uzyskać więcej informacji, zobacz Domena główna na pv.

Określanie, czy i jak jest używany system plików

Platforma Kubernetes zajmuje się systemami plików z woluminami trwałymi (PV). Instalowanie trwałych woluminów jest obsługiwane w wstępnie utworzonej ofercie witryny Azure Marketplace i bezpośrednio przy użyciu operatora. Jeśli używasz domeny w trybie PV, system plików jest centralnym aspektem konfiguracji.

Zawartość statyczna tylko do odczytu

Jeśli aplikacja aktualnie obsługuje zawartość statyczną, potrzebna jest dodatkowa lokalizacja. Warto rozważyć przeniesienie zawartości statycznej do usługi Azure Blob Storage i dodanie usługi Azure CDN, aby zapewnić błyskawiczne pobieranie na całym świecie. Aby uzyskać więcej informacji, zobacz Hostowanie statycznej witryny internetowej w usłudze Azure Storage i Szybki start: integrowanie konta usługi Azure Storage z usługą Azure CDN.

Dynamicznie publikowana zawartość statyczna

Jeśli aplikacja zezwala na zawartość statyczną, która została przekazana/utworzona przez aplikację, ale pozostaje niezmienna po jej utworzeniu, możesz użyć usług Azure Blob Storage i Azure CDN, jak opisano powyżej, oraz usługi Azure Function do obsługiwania przekazywania i odświeżania usługi CDN. Udostępniliśmy przykładową implementację do użycia w temacie Przekazywanie zawartości statycznej i jej wstępne ładowanie w usłudze CDN za pomocą usługi Azure Functions.

Określanie topologii sieci

Bieżący zestaw ofert witryny Azure Marketplace jest punktem wyjścia do migracji. Jeśli oferta nie obejmuje aspektów migrowanej architektury, musisz określić topologię sieci w bieżącym wdrożeniu i odtworzyć ją na platformie Azure — nawet po rozszerzeniu podstawowej oferty przy użyciu jednego z szablonów rozwiązań.

Ten temat jest bardzo szeroki, ale poniższa dokumentacja może pomóc Ci ukierunkować działania związane z migracją:

Konto do korzystania z kart JCA i kart zasobów

Jeśli wdrożenie opiera się na kartach zasobów, najbardziej obsługiwaną opcją jest Domena główna na pv.

Konto do korzystania z niestandardowych dostawców zabezpieczeń i JAAS

Jeśli aplikacja korzysta z usługi JAAS, musisz upewnić się, że konfiguracja dostawców zabezpieczeń została prawidłowo zmigrowana. Aby uzyskać więcej informacji, zobacz About Configuring WebLogic Security Providers (Informacje na temat konfigurowania dostawców zabezpieczeń rozwiązania WebLogic) w dokumentacji Oracle.

Jeśli wdrożenie opiera się na dostawcach zabezpieczeń, najbardziej obsługiwaną opcją jest domena główna w sieci PV.

Ustalanie, czy jest używane klastrowanie serwera WebLogic

Operator obsługuje klastrowanie na wszystkie możliwe sposoby uruchamiania usługi WLS w usłudze AKS.

Sprawdzanie klastrowania EJB

Jeśli aplikacja korzysta z lokalnej usługi EJB, musisz przeprowadzić migrację ich do klastrowanej usługi EJB. Aby uzyskać więcej informacji, zobacz Clustered versus local EJB (Klastrowane i lokalne EJB).

Konto wymagań dotyczących równoważenia obciążenia

Najlepszym sposobem, aby uwzględnić równoważenie obciążenia, jest użycie integracji usługi App Gateway dostarczonej przez wbudowaną ofertę witryny Azure Marketplace. Aby uzyskać więcej informacji, zobacz Samouczek: migrowanie klastra serwera WebLogic na platformę Azure przy użyciu usługi aplikacja systemu Azure Gateway jako modułu równoważenia obciążenia.

Określanie, czy jest używana funkcja klienta aplikacji Java EE

Jeśli wdrożenie opiera się na klientach aplikacji Java EE, najlepiej używać operatora bezpośrednio. Aby uzyskać więcej informacji, zobacz Klienci zewnętrzni.

Określanie, czy jest potrzebnych wiele obrazów kontenerów

Domena serwera WebLogic może zawierać wiele klastrów. Na przykład wielowarstwowa aplikacja może być reprezentowana w jednej domenie, ale ma dwa klastry, np. "fronton" i "zaplecze". Warto zaktualizować fronton bez aktualizowania zaplecza i na odwrót. Jednak w przypadku typu źródła głównego domeny obrazów cała domena jest reprezentowana w jednym obrazie kontenera. Aby uwzględnić ten przypadek użycia, należy oddzielić klastry do własnych domen, z których każdy ma własny obraz kontenera. Operator może zarządzać wieloma domenami w wielu przestrzeniach nazw. Aby uzyskać więcej informacji, zobacz Wybieranie strategii wyboru przestrzeni nazw domeny

Wdrożenie wielu domen może powodować problemy z dostępem T3 między domenami. Aby rozwiązać te problemy, włącz niestandardowy kanał zgodnie z opisem w temacie Określanie, czy jest wymagany włączanie nieznanego dostępu do hosta.

Określanie, czy jest wymagane włączanie nieznanego dostępu do hosta

Może być konieczne włączenie nieznanego dostępu do hosta przez zastosowanie poprawki do serwera WebLogic w następujących scenariuszach:

  • Zezwalaj na dostęp T3 z klientów zewnętrznych spoza usługi AKS do klastrów WLS w usłudze AKS za pośrednictwem kanału niestandardowego.
  • Zezwalaj na dostęp T3 między różnymi domenami WLS w usłudze AKS za pośrednictwem kanału niestandardowego.

Aby uzyskać szczegółowe informacje na temat poprawki, postępuj zgodnie ze wskazówkami w temacie How to Use the Patch Search in My Oracle Support(MOS) (Jak używać wyszukiwania poprawek w programie My Oracle Support(MOS) i wyszukaj poprawkę 30656708.

Po zastosowaniu poprawki zobacz Włączanie nieznanego dostępu do hosta.

Migracja

W krokach w tej sekcji założono, że analiza doprowadziła Cię do podjęcia decyzji o użyciu wstępnie utworzonej oferty witryny Azure Marketplace.

Aprowizacja oferty

Aby otworzyć ofertę w witrynie Azure Portal, zobacz https://aka.ms/wlsaks. Wybierz pozycję Utwórz, a następnie postępuj zgodnie z instrukcjami w dokumentacji oferty. Skorzystaj z informacji zebranych w poprzednich krokach, aby ułatwić wypełnianie pól oferty.

Migrowanie domen

Po aprowizowanej ofercie wyprowadź domenę, wykonując następujące kroki.

Jeśli nastąpi przejście z dala od strony Wdrożenie jest w toku , poniższe kroki pokazują, jak wrócić do tej strony. Jeśli nadal znajdujesz się na stronie z wyświetlonym komunikatem Wdrożenie zostało ukończone, możesz przejść do kroku 5.

  1. W lewym górnym rogu dowolnej strony portalu wybierz menu hamburger i wybierz pozycję Grupy zasobów.

  2. W polu z tekstem Filtr dla dowolnego pola wprowadź kilka pierwszych znaków utworzonej wcześniej grupy zasobów. Jeśli wykonano zalecaną konwencję, wprowadź swoje inicjały, a następnie wybierz odpowiednią grupę zasobów.

  3. W okienku nawigacji po lewej stronie w sekcji Ustawienia wybierz pozycję Wdrożenia , aby wyświetlić uporządkowaną listę wdrożeń w tej grupie zasobów z najnowszą.

  4. Przewiń do najstarszego wpisu na tej liście. Ten wpis odpowiada wdrożeniu rozpoczętym w poprzedniej sekcji. Wybierz najstarsze wdrożenie, jak pokazano na poniższym zrzucie ekranu.

    Zrzut ekranu witryny Azure Portal przedstawiający listę wdrożeń grup zasobów.

  5. W panelu po lewej stronie wybierz pozycję Dane wyjściowe. Ta lista zawiera wartości wyjściowe z wdrożenia. Przydatne informacje są zawarte w danych wyjściowych. Interesuje nas dane wyjściowe, które umożliwiają nam sprawdzenie domeny i interakcję z operatorem. Inne wartości w danych wyjściowych zostały szczegółowo wyjaśnione w podręczniku użytkownika aplikacji WebLogic w usłudze AKS.

  6. Znajdź dane wyjściowe o nazwie shellCmdtoConnectAks. Wklej wartość danych wyjściowych w powłoce powłoki Bash i uruchom polecenie . To polecenie umożliwia użycie polecenia zgodnie z kubectl opisem w temacie Łączenie z klastrem.

  7. Znajdź dane wyjściowe o nazwie shellCmdtoOutputWlsDomainYaml. Wklej wartość danych wyjściowych w powłoce powłoki Bash i uruchom polecenie . To polecenie zwraca zasób domeny jako plik YAML.

  8. Teraz, gdy masz domenę YAML bieżącego wdrożenia, możesz zastosować wiedzę w temacie Wdrażanie plików YAML zasobów domeny i przejrzeć te wskazówki, aby uzyskać więcej wskazówek dotyczących migrowania domen. Te wskazówki wymagają dostosowania do sposobu wykonywania czynności na platformie Kubernetes, ale nadal warto wiedzieć o tym.

Konto magazynów kluczy

Należy uwzględnić migrację wszystkich magazynów kluczy SSL używanych przez aplikację. Więcej informacji znajduje się w temacie Konfigurowanie magazynów kluczy.

Łączenie źródeł interfejsu JMS

Po nawiązaniu połączenia z bazami danych można skonfigurować interfejs JMS, postępując zgodnie z instrukcjami w temacie Fusion Middleware Administering JMS Resources for Oracle WebLogic Server (Zarządzanie zasobami JMS na platformie Fusion Middleware na potrzeby serwera Oracle WebLogic) w dokumentacji serwera WebLogic.

Konto na potrzeby rejestrowania

Nie można wykonywać czynności w chmurze bez rejestrowania głównego. Operator udostępnia przykłady użycia narzędzi Elasticsearch i Kibana. Aby uzyskać więcej informacji, zobacz dokumentację operatora. Platforma Azure zapewnia doskonałą obsługę funkcji Elastic. Aby uzyskać szczegółowe informacje, zobacz Co to jest elastyczna integracja z platformą Azure?. Możesz połączyć wiedzę z tych dwóch zasobów, aby uzyskać zoptymalizowane pod kątem platformy Azure rozwiązanie do rejestrowania dla usługi WLS w usłudze AKS.

Migrowanie aplikacji

Niezależnie od tego, czy wybrano udostępnienie pliku WAR lub EAR podczas wdrażania, musisz zaktualizować aplikację za pośrednictwem ciągłej integracji/ciągłego wdrażania. Dokumentacja operatora zawiera przykład pokazujący, jak wykonać tę aktualizację. Aby uzyskać więcej informacji, zobacz Update 3. Inne przykłady aktualizacji są istotne dla migracji i warto je eksplorować.

Testowanie

Wszystkie testy w kontenerze wykonywane wobec aplikacji muszą być skonfigurowane w taki sposób, aby uzyskiwać dostęp do nowych serwerów działających na platformie Azure. Podobnie jak w przypadku problemów dotyczących ciągłej integracji/ciągłego wdrażania, należy upewnić się, że niezbędne reguły zabezpieczeń sieci umożliwiają testom dostęp do aplikacji wdrożonych na platformie Azure. Aby uzyskać więcej informacji, zobacz Sieciowe grupy zabezpieczeń.

Po migracji

Po osiągnięciu celów migracji zdefiniowanych w kroku Czynności przed migracją wykonaj niektóre kompleksowe testy akceptacyjne, aby sprawdzić, czy wszystko działa zgodnie z oczekiwaniami. Aby uzyskać wskazówki dotyczące niektórych potencjalnych ulepszeń po migracji, zobacz następujące zalecenia: