Migrowanie aplikacji serwera WebLogic do usługi Azure Virtual Machines

  • Artykuł

W tym przewodniku opisano, na co należy zwrócić uwagę, aby przeprowadzić migrację istniejącej aplikacji WebLogic w celu uruchomienia jej w usłudze Azure Virtual Machines. Aby zapoznać się z omówieniem dostępnych rozwiązań serwera WebLogic w witrynie Azure Marketplace, zobacz Co to są rozwiązania do uruchamiania serwera Oracle WebLogic na maszynach wirtualnych platformy Azure?

Przed migracją

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

Określenie punktu oznaczającego „ukończenie migracji”

Ten przewodnik oraz odpowiednie oferty portalu Azure Marketplace są punktem wyjścia dla przyspieszenia migracji obciążeń serwera WebLogic na platformę Azure. Ważne jest, aby zdefiniować zakres nakładów pracy w związku z migracją. Przykładowo, czy stosujesz rygorystyczną metodę migracji „lift and shift” z istniejącej infrastruktury do usługi Azure Virtual Machines? Jeśli tak, idea równoczesnego zastosowania metody „lift and improve” podczas migracji może być kusząca.

Lepiej jednak trzymać się ściśle planu opartego na metodzie „lift and shift”, uwzględniając niezbędne zmiany zgodnie z opisem zawartym w tym przewodniku. Zdefiniuj punkt kontrolny oznaczający „ukończenie migracji”, aby wiedzieć, kiedy zostanie osiągnięty. Po osiągnięciu „ukończenia migracji” możesz wykonać migawkę usługi Virtual Machines, zgodnie z opisem zawartym w artykule Tworzenie migawki. Po zweryfikowaniu, że możesz pomyślnie przywrócić migawkę, możesz wykonać ulepszenia bez obawy przed utratą postępów migracji osiągniętych do tej pory.

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 utworzone oferty witryny Azure Marketplace są dobrym punktem wyjścia

Firma Oracle i firma Microsoft nawiązały współpracowanie z zestawem szablonów rozwiązań platformy Azure w witrynie Azure Marketplace w celu zapewnienia solidnego punktu wyjścia do migracji na platformę Azure. Zapoznaj się z dokumentacją usługi Oracle Fusion Middleware, aby uzyskać listę ofert i wybrać tę, która najlepiej odpowiada istniejącemu wdrożeniu. Listę ofert można znaleźć w artykule Omówienie Co to jest oracle WebLogic Server na platformie Azure?

Jeśli żadna z istniejących ofert nie jest dobrym punktem wyjścia, musisz odtworzyć wdrożenie ręcznie przy użyciu zasobów maszyny wirtualnej platformy Azure. Wskazówki krok po kroku można znaleźć w temacie Ręczne instalowanie serwera Oracle WebLogic na maszynach wirtualnych platformy Azure. Aby uzyskać więcej informacji, zobacz Co to jest IaaS?

Ustalenie, czy wersja serwera WebLogic jest zgodna

Istniejąca wersja serwera WebLogic musi być zgodna z wersją w ofertach IaaS. Aby wyświetlić oferty aplikacji WebLogic w wersji 12.2.1.3, wykonaj zapytanie dotyczące witryny Azure Marketplace dla oprogramowania Oracle WebLogic 12.2.1.3. Jeśli istniejąca wersja serwera WebLogic nie jest zgodna z tą wersją, musisz odtworzyć wdrożenie ręcznie przy użyciu zasobów IaaS platformy Azure. Aby uzyskać więcej informacji, zapoznaj się z dokumentacją platformy Azure.

Utworzenie spisu pojemności serwerów

Zapisz składniki sprzętowe (pamięć, procesor, dysk) bieżących serwerów produkcyjnych, a także średnią i szczytową liczbę żądań oraz użycie zasobów. Te informacje są ważne w kontekście wyboru rozmiaru maszyny wirtualnej. Aby uzyskać więcej informacji, zobacz Rozmiary usług Cloud Services.

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.

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>

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.

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.

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.

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).

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?

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).

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 Wybieranie rozwiązania do łączenia 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 Używanie usługi JMS z usługą Azure Service Bus i protokołem 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.

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.

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

Jeśli aplikacja zawiera dowolny kod z zależnościami w systemie operacyjnym hosta, musisz przeprowadzić jej refaktoryzację, aby usunąć te zależności. Na przykład może być konieczne zastąpienie każdego użycia symbolu / lub \ w ścieżkach systemu plików przez File.Separator lub Paths.get.

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).

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.

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.

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

Pod względem trwałości, uruchamiania i zamykania systemy plików maszyn wirtualnych działają tak samo jak lokalne systemy plików. Mimo to, ważne jest, aby znać wymagania systemu plików i zapewnić maszynom wirtualnym odpowiedni rozmiar oraz wydajność magazynu.

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. Możesz również bezpośrednio wdrożyć zawartość statyczną w aplikacji w planie Azure Spring Apps Enterprise. Aby uzyskać więcej informacji, zobacz Wdrażanie internetowych plików statycznych.

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. Możesz również bezpośrednio wdrożyć zawartość statyczną w aplikacji w planie Azure Spring Apps Enterprise. Aby uzyskać więcej informacji, zobacz Wdrażanie internetowych plików statycznych.

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 istniejąca aplikacja łączy się z innymi systemami przedsiębiorstwa przy użyciu kart JCA i/lub kart zasobów, upewnij się, że konfiguracja tych artefaktów została zastosowana do serwera WebLogic działającego w usłudze Azure Virtual Machines. Aby uzyskać więcej informacji, zobacz Creating and Configuring Resource Adapters (Tworzenie i konfigurowanie kart zasobów)

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.

Ustalanie, czy jest używane klastrowanie serwera WebLogic

W większości przypadków aplikację wdraża się na wielu serwerach WebLogic w celu zapewnienia wysokiej dostępności. Klastry te można migrować bezpośrednio z instalacji lokalnej na serwery WebLogic uruchomione w usłudze Azure Virtual Machines. Aby uzyskać więcej informacji, zobacz Pliki konfiguracji domeny w dokumentacji Oracle.

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

Równoważenie obciążenia jest istotną częścią migracji klastra Oracle WebLogic Server na platformę Azure. Najprostszym rozwiązaniem jest użycie wbudowanej obsługi bramy aplikacja systemu Azure dostępnej w ofercie witryny Azure Marketplace dla klastra Oracle WebLogic Server. Aby zapoznać się z samouczkiem dotyczącym tego tematu, 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.

Podsumowanie możliwości usługi aplikacja systemu Azure Gateway w porównaniu z innymi rozwiązaniami równoważenia obciążenia platformy Azure można znaleźć w temacie Omówienie opcji równoważenia obciążenia na platformie Azure.

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

Jeśli aplikacja używa funkcji klienta aplikacji Java EE, po zakończeniu migracji do usługi Azure Virtual Machines powinna działać bez żadnych zmian. Aby uzyskać więcej informacji, zobacz Using Java EE Client Application Modules (Używanie modułów aplikacji klienta Java EE).

Migracja

Wybieranie oferty serwera WebLogic w usłudze Azure Virtual Machines

Następujące oferty są dostępne dla serwera WebLogic w usłudze Azure Virtual Machines.

Podczas wdrażania oferty zostanie wyświetlony monit o wybranie rozmiaru maszyny wirtualnej dla węzłów serwera WebLogic. Ważne jest, aby uwzględnić wszystkie aspekty rozmiaru (pamięć, procesor, dysk) wybranej maszyny wirtualnej. Aby uzyskać więcej informacji, zobacz dokumentację platformy Azure dotyczącą ustalania rozmiaru maszyny wirtualnej

Pojedynczy węzeł serwera WebLogic bez serwera administracyjnego

Ta oferta tworzy pojedynczą maszynę wirtualną i instaluje na niej serwer WebLogic, ale nie konfiguruje żadnych domen, co jest przydatne w scenariuszach, w których istnieje wysoce dostosowana konfiguracja domeny.

Pojedynczy węzeł serwera WebLogic z serwerem administracyjnym

Ta oferta aprowizuje pojedynczą maszynę wirtualną i instaluje na niej serwer WebLogic. Tworzy domenę i uruchamia serwer administracyjny.

Klaster N-węzłowy serwera WebLogic

Ta oferta tworzy klaster o wysokiej dostępności z maszyn wirtualnych serwera WebLogic.

N-węzłowy klaster dynamiczny serwera WebLogic

Ta oferta tworzy skalowalny, dynamiczny klaster o wysokiej dostępności z maszyn wirtualnych serwera WebLogic.

Aprowizacja oferty

Po wybraniu oferty początkowej postępuj zgodnie z instrukcjami w dokumentacji dotyczącej ofert w celu aprowizacji oferty. Upewnij się, że wybrano nazwę domeny zgodną z istniejącą nazwą domeny. Możesz nawet dopasować hasło domeny do istniejącego hasła domeny.

Migrowanie domen

Po aprowizacji oferty możesz sprawdzić konfigurację domeny i skorzystać z tych wskazówek, aby uzyskać szczegółowe informacje dotyczące migrowania domen.

Łączenie baz danych

Po przeprowadzeniu migracji domen można połączyć bazy danych, postępując zgodnie z instrukcjami w dokumentacji oferty. Te instrukcje ułatwiają uwzględnianie wszelkich wpisów tajnych bazy danych i ciągów dostępu.

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 połączeniu baz danych można skonfigurować usługę JMS. Aby uzyskać więcej informacji, zobacz Fusion Middleware Administracja istering JMS Resources for Oracle WebLogic Server w dokumentacji serwera WebLogic.

Konto na potrzeby uwierzytelniania i autoryzacji

Większość aplikacji ma pewnego rodzaju uwierzytelnianie i autoryzację. Jeśli używasz protokołu LDAP do uwierzytelniania, możesz skonfigurować usługi Microsoft Entra Domain Services z bezpiecznym protokołem LDAP i skonfigurować połączenia LDAP na serwerze WebLogic. Aby uzyskać więcej informacji, zobacz Tworzenie i konfigurowanie domeny zarządzanej usług Microsoft Entra Domain Services i Konfigurowanie bezpiecznego protokołu LDAP dla domeny zarządzanej usług Microsoft Entra Domain Services.

Konto na potrzeby rejestrowania

Użyj integracji z usługą Elastic on Azure dostarczonej przez szablony rozwiązań oracle WebLogic Server marketplace. To podejście jest najprostszym sposobem uwzględnienia rejestrowania. Listę ofert można znaleźć w artykule Omówienie Jakie są rozwiązania dotyczące uruchamiania programu Oracle WebLogic Server na maszynach wirtualnych platformy Azure? Kompletne samouczki dotyczące konfigurowania elastycznego są dostępne w następujących artykułach:

Jeśli integracja elastyczna nie jest odpowiednia, należy przenieść istniejącą konfigurację rejestrowania podczas migracji domeny. Aby uzyskać więcej informacji, zobacz Configure java.util.logging logger levels (Konfigurowanie poziomów rejestratora java.util.logging) oraz Configuring Log Files and Filtering Log Messages for Oracle WebLogic Server (Konfigurowanie poziomów rejestratora java.util.logging) i Configuring Log Files and Filtering Log Messages for Oracle WebLogic Server (Konfigurowanie plików dziennika i filtrowanie komunikatów dziennika dla serwera Oracle WebLogic Server ) w dokumentacji oracle.

Migrowanie aplikacji

Techniki używane do wdrażania aplikacji od zespołu programistycznego do serwerów testowych, przejściowych i produkcyjnych różnią się znacznie w poszczególnych przypadkach. W niektórych przypadkach istnieje wysoce rozwinięta platforma ciągłej integracji/ciągłego wdrażania, która powoduje wdrożenie aplikacji na serwerze WebLogic. W innych przypadkach proces może być realizowany w większym stopniu ręcznie. Jedną z zalet używania usługi Azure Virtual Machines do migrowania aplikacji WebLogic do chmury jest to, że istniejące procesy nadal działają.

Należy skonfigurować sieciową grupę zabezpieczeń, która aprowizuje dostęp z potoku ciągłej integracji/ciągłego wdrażania lub ręcznego systemu wdrażania. Aby uzyskać więcej informacji, zobacz Sieciowe grupy zabezpieczeń.

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: