Migrowanie aplikacji WebSphere do usługi Azure Red Hat OpenShift

W tym przewodniku opisano, co należy wiedzieć, kiedy chcesz przeprowadzić migrację istniejącego obciążenia serwera aplikacji WebSphere (WAS) do ibm WebSphere Liberty lub Open Liberty działającego w usłudze Azure Red Hat OpenShift.

Przed migracją

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

Upewnij się, że wybrany cel jest odpowiedni dla procesu migracji

Pierwszym krokiem pomyślnej migracji aplikacji WAS na platformę Azure jest wybranie najbardziej odpowiedniego celu migracji.

Tradycyjny serwer WAS działa dobrze na platformie Azure Virtual Machines. Obiekt docelowy maszyny wirtualnej jest najprostszym wyborem, ponieważ najbardziej przypomina wdrożenie lokalne. Środowisko administracyjne i wdrożenie maszyn wirtualnych jest podobne do środowiska lokalnego.

Inną opcją jest migracja do kontenerów przez przekonwertowanie tradycyjnego obciążenia WAS na kontenery aplikacji. Obiekt docelowy kontenera można uruchomić na platformach Azure Kubernetes Service (AKS) i Azure Red Hat OpenShift. 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 kontenerami. Chociaż rozwiązanie oparte na kontenerze kosztuje mniej do uruchomienia, należy ograniczyć aplikację, aby dopasować się do wymagań platformy orkiestracji kontenerów.

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 WebSphere do usługi Azure Virtual Machines.

Jeśli możesz tolerować konwertowanie aplikacji do uruchamiania w kontenerach w celu zmniejszenia kosztów środowiska uruchomieniowego, rozważ migrację opartą na usłudze AKS lub migrację opartą na usłudze Azure Red Hat OpenShift.

W przypadku migracji opartej na usłudze AKS możesz rozpocząć korzystanie z warstwy Bezpłatna. Korzystaj z bezpłatnego zarządzania klastrem i płać tylko za wykorzystywane maszyny wirtualne, powiązaną przestrzeń dyskową i zasoby sieciowe. W tym przypadku zobacz Migrowanie aplikacji WebSphere do usługi Azure Kubernetes Service.

W przypadku migracji opartej na platformie Azure Red Hat OpenShift oprócz kosztów obliczeń i infrastruktury węzły aplikacji mają kolejny koszt składnika licencji OpenShift. Ten koszt jest rozliczany na podstawie liczby węzłów aplikacji i typu wystąpienia. Korzystaj z cen na żądanie lub instancji zarezerwowanych, w zależności od tego, które najlepiej odpowiada potrzebom Twojego obciążenia roboczego i działalności. W tym przypadku zobacz Migrowanie aplikacji WebSphere do usługi Azure Red Hat OpenShift.

Przewodniki z instrukcjami w dokumentacji usługi Azure Red Hat OpenShift obejmują niektóre aspekty istotne dla migracji. Pełną listę przewodników z instrukcjami można znaleźć w dokumentacji usługi Azure Red Hat OpenShift.

Określ, czy gotowa oferta w witrynie Azure Marketplace jest dobrym punktem wyjścia

Po podjęciu decyzji, że usługa Azure Red Hat OpenShift jest odpowiednim celem wdrożenia, musisz przyjąć do wiadomości, że operator IBM WebSphere Liberty lub Open Liberty Operator (operator) jest jedynym sposobem uruchamiania Liberty na Kubernetes. Po zaakceptowaniu tego faktu musisz zdecydować, czy wstępnie utworzona oferta witryny Azure Marketplace jest dobrym punktem wyjścia. Oto kilka kwestii, które należy wziąć pod uwagę w odniesieniu do wstępnie skonfigurowanej oferty w witrynie Azure Marketplace:

  • IBM i Microsoft stworzyły tę ofertę, aby umożliwić szybkie udostępnienie Liberty na platformie Azure Red Hat OpenShift. Ta koncepcja jest bardziej szczegółowo wyjaśniona w poniższej zawartości.
  • Na wysokim poziomie oferta automatyzuje następujące kroki.
    • W razie potrzeby użyj istniejącego obrazu aplikacji.
    • Aprowizuj klaster usługi Azure Red Hat OpenShift w razie potrzeby.
    • Zainstaluj i skonfiguruj operator IBM WebSphere Liberty lub operator Open Liberty na platformie Azure Red Hat OpenShift.
    • Użyj operatora, aby uruchomić całość. Operator wdraża konteneryzowane aplikacje Liberty i zarządza nimi w usłudze Azure Red Hat OpenShift. Dokumentację referencyjną można znaleźć w witrynie IBM WebSphere Liberty operator i operator Open Liberty.

Jeśli nie używasz wstępnie skonfigurowanej oferty z Azure Marketplace, musisz nauczyć się, jak używać operatora bezpośrednio. Opanowanie operatora wykracza poza zakres tego artykułu. Pełna dokumentacja operatora jest dostępna w witrynie IBM WebSphere Liberty operator i operator Open Liberty.

Teraz, po zapoznaniu się z różnymi sposobami korzystania z Liberty w środowisku Azure Red Hat OpenShift, łatwiej będzie Ci zdecydować, czy skorzystać z gotowej oferty z Azure Marketplace, czy skonfigurować to samodzielnie, korzystając bezpośrednio z operatora.

Określ, czy wersja Liberty jest kompatybilna

Potrzebujesz operatora Open Liberty lub operatora WebSphere Liberty, aby wdrażać aplikacje w klastrach opartych na platformie Kubernetes i zarządzać nimi. Upewnij się, że istniejąca wersja Liberty jest jedną z wersji obsługiwanych przez operatora. Wersje Open Liberty są obsługiwane w witrynie GitHub OpenLiberty/open-liberty. IBM obsługuje wersje serwera IBM WebSphere Application Server Liberty. Aby uzyskać więcej informacji, zobacz WebSphere Application Server Liberty.

Gotowa oferta w Azure Marketplace umożliwia wybór obrazów aplikacji z publicznego rejestru, a tym samym domyślnie obsługuje wszystkie wersje aplikacji.

Określanie, czy wymagana jest licencja

W przypadku ibm WebSphere Liberty należy zaakceptować warunki umowy licencyjnej, która odpowiada wersji programu IBM w kontenerze aplikacji. Aby zidentyfikować i wyświetlić odpowiednią umowę licencyjną, zobacz Wyświetlanie informacji o licencji dla operatora WebSphere Liberty. Aby uzyskać więcej informacji, zobacz Running WebSphere Liberty on Microsoft Azure (Uruchamianie platformy WebSphere Liberty na platformie Microsoft Azure).

Jeśli edycja produktu jest inna niż domyślna edycja IBM WebSphere Application Server (base), element .spec.license.edition value musi określać edycję produktu. Inne dostępne opcje to IBM WebSphere Application Server Liberty Core i IBM WebSphere Application Server Network Deployment. Wstępnie utworzona oferta witryny Azure Marketplace umożliwia wybranie obsługiwanej wersji produktu.

Różnice w inwentaryzacji przy użyciu narzędzi migracyjnych IBM

Aby przenieść aplikacje na serwer WebSphere Application Server Liberty lub Open Liberty, należy zaplanować migrację, przeanalizować aplikacje i zaktualizować kod źródłowy. FIRMA IBM udostępnia narzędzia migracji, które ułatwiają identyfikowanie wszelkich różnic między bieżącym środowiskiem a technologiami w nowym środowisku Liberty, takimi jak Java EE 7 lub Java EE 8 oraz Java SE 8 lub Java SE 11. Aby uzyskać więcej informacji, zobacz Migracja aplikacji do Liberty.

Inwentaryzacja wydajnoś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 są potrzebne niezależnie od wybranej ścieżki migracji. Te informacje są przydatne, na przykład, aby ułatwić wybór rozmiaru maszyn wirtualnych w węźle, ilość pamięci używanej przez kontener oraz liczbę udziałów procesora CPU, których potrzebuje kontener.

Aby korzystać z nieużywanej pojemności przy znaczących oszczędnościach kosztów, można użyć maszyn wirtualnych typu spot platformy Azure w usłudze Azure Red Hat OpenShift. Aby dowiedzieć się, jak to zrobić, zobacz Używanie maszyn wirtualnych usługi Azure Spot w klastrze usługi Azure Red Hat OpenShift.

Zinwentaryzuj wszystkie sekrety

Przed pojawieniem się technologii typu „konfiguracja jako usługa”, takich jak Azure Key Vault, nie istniało dobrze zdefiniowane pojęcie „sekretów”. Zamiast tego miałeś rozproszony zestaw ustawień konfiguracyjnych, który w praktyce działał jak to, co dziś nazywamy „sekretami”. W przypadku serwerów aplikacji, takich jak WAS, te wpisy tajne znajdują się w wielu różnych plikach konfiguracji i magazynach konfiguracji. Sprawdź wszystkie pliki z właściwościami i pliki konfiguracyjne na serwerze/serwerach produkcyjnych pod kątem wszelkich sekretów i haseł. Możesz również znaleźć pliki konfiguracji zawierające hasła lub poświadczenia wewnątrz aplikacji. WAS przechowuje dane konfiguracji w kilku dokumentach w kaskadowej hierarchii katalogów. Większość dokumentów konfiguracyjnych ma zawartość XML. Aby uzyskać więcej informacji, zobacz Dokumenty konfiguracji i Podstawowe pojęcia dotyczące usługi Azure Key Vault.

Gdy masz już kompletną listę sekretów, zapoznaj się z dokumentacją operatora dotyczącą sekretów. Aby uzyskać więcej informacji, zobacz następujące artykuły:

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 skonfiguruj je przy użyciu następujących artykułów:

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

Korzystanie z platformy Liberty wymaga określonej wersji języka Java, dlatego należy potwierdzić, że aplikacja działa prawidłowo przy użyciu tej obsługiwanej wersji.

Środowisko uruchomieniowe serwera Aplikacji WebSphere Liberty ma określone wymagania dotyczące minimalnego poziomu środowiska uruchomieniowego Java Runtime Environment (JRE). Aby uzyskać więcej informacji, zobacz Zależności wersji języka Java dla funkcji.

Open Liberty wymaga środowiska uruchomieniowego Java SE. Można go uruchomić przy użyciu dystrybucji Java Runtime Environment (JRE) lub Java SE Development Kit (JDK). Aby uzyskać więcej informacji, zobacz Obsługiwane wersje środowiska Java SE.

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 WebSphere Data Sources (Źródła danych WebSphere) w dokumentacji ibm. 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 Using JMS resources (Korzystanie z zasobów JMS).

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. W przypadku platformy WebSphere Liberty w usłudze Azure Kubernetes Service (AKS) można udostępnić obiekt w domyślnej przestrzeni nazw Java Naming and Directory Interface (JNDI). Aby uzyskać więcej informacji, zobacz Programowanie z użyciem domyślnej przestrzeni nazw JNDI w funkcji Liberty. W przypadku Open Liberty zobacz Java Naming and Directory Interface.

Sprawdzanie konfiguracji profilu

Główną jednostką konfiguracji w usłudze WAS jest profil. W związku z tym plik resources.xml zawiera wiele konfiguracji, które należy dokładnie rozważyć pod kątem migracji. Plik zawiera odwołania do innych plików XML przechowywanych w podkatalogach. Aby uzyskać więcej informacji, zobacz Zarządzanie profilami w systemach operacyjnych rozproszonych i IBM i.

W aplikacji

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

Te dostosowania należy przechwycić w obrazie kontenera uruchomionym przez usługę Azure Red Hat OpenShift. W przypadku korzystania ze wstępnie utworzonej oferty witryny Azure Marketplace takie dostosowania są najlepiej obsługiwane przez utworzenie niestandardowego obrazu kontenera i udostępnienie go w rejestrze publicznym, a następnie wskazanie tego rejestru podczas wdrażania.

Jeśli używasz komórki Network Deployment serwera WebSphere Application Server, każdy członek klastra działa w instalacji tradycyjnego serwera WAS. Liberty to lekki profil serwera aplikacji WebSphere. Jest to elastyczny i dynamiczny profil WAS, który umożliwia serwerOWI WAS wdrażanie tylko wymaganych funkcji niestandardowych zamiast wdrażania dużego zestawu dostępnych składników JEE.

Określenie, czy jest używana replikacja sesji

Jeśli aplikacja korzysta z replikacji sesji, dostępne są następujące opcje:

  • W przypadku sesji HTTP, zgodnie z poziomem zarządzania sesjami, można użyć pamięci podręcznej lub bazy danych do zbierania danych sesji.
  • W przypadku sesji rozproszonych można zapisywać sesje w bazie danych przy użyciu trwałości sesji bazy danych.
  • W przypadku dynamicznej pamięci podręcznej można zarządzać danymi sesji w pamięci podręcznej lub w bazie danych.
  • Możesz refaktoryzować aplikację, aby używać bazy danych do zarządzania sesjami.
  • Możesz refaktoryzować aplikację w celu zewnętrzności sesji w usłudze Azure Redis Service. Aby uzyskać więcej informacji, zobacz Azure Cache for Redis.

W przypadku wszystkich tych opcji dobrym pomysłem jest opanowanie sposobu, w jaki Liberty wykonuje replikację stanu sesji HTTP. Poniższe dokumenty pomagają zrozumieć, jak zarządzać sesjami HTTP w wolności:

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 programie WAS, zobacz temat Używanie sterowników JDBC z programem WebSphere Application Server.

Konfiguracja JDBC jest podstawową konfiguracją serwera w liberty. Aby uzyskać więcej informacji, zobacz Sterownik JDBC.

Wstępnie utworzona oferta witryny Azure Marketplace ma ograniczoną obsługę baz danych. Można zarządzać konfiguracją w obrazach aplikacji i użyć tego obrazu podczas wdrażania oferty.

Określanie, czy funkcja WAS została dostosowana

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 obejmują wsadmin, AdminControl, AdminConfig, AdminApp i AdminTask.
  • Czy do środowiska JVM są przekazywane określone parametry?
  • Czy do ścieżki klas serwera zostały dodane pliki JAR?
  • Czy obiekty na poziomie systemu operacyjnego, takie jak systemd były używane do automatycznego uruchamiania składników WAS po ponownym uruchomieniu serwera?

Należy uwzględnić zagadnienia dotyczące migracji w zależności od odpowiedzi na te pytania.

Te dostosowania należy przechwycić w obrazie kontenera uruchomionym przez usługę Azure Red Hat OpenShift. W przypadku korzystania ze wstępnie utworzonej oferty witryny Azure Marketplace takie dostosowania są najlepiej obsługiwane przez utworzenie niestandardowego obrazu kontenera i udostępnienie go w rejestrze publicznym, a następnie wskazanie tego rejestru podczas wdrażania.

Ustal, czy połączenie ze środowiskiem lokalnym jest wymagane

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. Alternatywnie musisz zrefaktoryzować aplikację tak, aby korzystała z publicznie dostępnych interfejsów API udostępnianych przez twoje zasoby lokalne.

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

Jeśli aplikacja korzysta z kolejek lub tematów JMS, musisz przeprowadzić migrację ich do serwera JMS hostowanego zewnętrznie. Jedną ze strategii dla osób korzystających z programu JMS jest użycie usługi Azure Service Bus i protokołu Advanced Message Queuing Protocol. 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).

Jeśli skonfigurowano magazyny trwałe JMS, należy przechwycić ich konfigurację i zastosować ją po migracji.

Jeśli używasz oprogramowania IBM MQ, możesz migrować to oprogramowanie do usługi Azure Virtual Machines i używać go w takim stanie, w jakim jest.

Firma Microsoft ma rozwiązanie do integracji oprogramowania IBM MQ z usługą Logic Apps. Aby uzyskać więcej informacji, zobacz Łączenie z serwerem IBM MQ z poziomu przepływu pracy w usłudze Azure Logic Apps.

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, co opisano w artykule Uzyskiwanie dostępu do interfejsów API innych firm z poziomu aplikacji Java EE.

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

Jeśli użyto pakietów OSGi dodanych do bazy danych WAS, musisz dodać równoważne pliki JAR bezpośrednio do aplikacji internetowej.

Możesz uwzględnić pakiety w obrazie dostarczanym z gotową ofertą Azure Marketplace. Aby uzyskać więcej informacji, zobacz Konfigurowanie bibliotek dla aplikacji OSGi.

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 w ścieżkach systemu plików każdego wystąpienia znaku / lub \ znakiem File.Separator lub Paths.get, jeśli aplikacja jest uruchomiona w systemie Windows.

Usługa Liberty w usłudze Azure Red Hat OpenShift działa w systemie Linux x86_64. Każdy kod specyficzny dla systemu operacyjnego musi być zgodny z systemem Linux. Aby dowiedzieć się, jak odnajdywać określone informacje o systemie operacyjnym, wykonaj kroki opisane w sekcji Określanie, czy wersja Liberty jest zgodna .

Określanie, czy jest używana usługa IBM Integration Bus

Jeśli aplikacja korzysta z usługi IBM Integration Bus, musisz przechwycić sposób konfigurowania usługi IBM Integration Bus. Aby uzyskać więcej informacji, zobacz dokumentację usługi IBM Integration Bus.

IBM Integration Bus nie jest bezpośrednio obsługiwany we wstępnie skonfigurowanej ofercie Azure Marketplace. Aby włączyć tę funkcję, postępuj zgodnie z instrukcjami w sekcji Włączanie aplikacji JMS w Liberty w celu połączenia z magistralą integracji usług w dokumentacji IBM.

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 aplikacja jest spakowana jako plik EAR, koniecznie sprawdź pliki application.xml, ibm-application-bnd.xmi i ibm-application-ext.xmi oraz zanotuj ich konfigurację. Aby uzyskać więcej informacji, zobacz Tworzenie pakietu archiwum przedsiębiorstwa (EAR) w witrynie WebSphere.

Wstępnie utworzona oferta witryny Azure Marketplace umożliwia korzystanie z istniejącego obrazu kontenera. Aplikację można przygotować zgodnie z wymaganiami biznesowymi.

Zidentyfikuj wszystkie zewnętrzne procesy i demony uruchomione na serwerach produkcyjnych

Jeśli jakieś procesy działają poza serwerem aplikacyjnym, na przykład demony monitorujące, musisz je usunąć lub przenieść w inne miejsce.

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

Kubernetes obsługuje systemy plików za pomocą woluminów trwałych (PV). Montowanie woluminów trwałych nie jest obsługiwane w gotowej ofercie Azure Marketplace. Aby utworzyć klasę Azure Files StorageClass, postępuj zgodnie z instrukcjami w artykule Create an Azure Files StorageClass on Azure Red Hat OpenShift 4 (Tworzenie klasy Azure Files StorageClass w usłudze Azure Red Hat OpenShift 4).

Zawartość statyczna tylko do odczytu

Jeśli aplikacja aktualnie obsługuje zawartość statyczną, potrzebujesz dla niej alternatywnej lokalizacji. Należy rozważyć przeniesienie zawartości statycznej do usługi Azure Blob Storage i dodanie usługi Azure Front Door w celu szybkiego pobierania na całym świecie. Aby uzyskać więcej informacji, zobacz hostowanie statycznej witryny internetowej w usłudze Azure Storage i Integrowanie konta usługi Azure Storage z usługą Azure Front Door.

Określanie topologii sieci

Bieżący zestaw ofert witryny Azure Marketplace jest punktem wyjścia do migracji. Jeśli oferta nie obejmuje elementów architektury, które musisz zmigrować, musisz udokumentować topologię sieci swojego obecnego wdrożenia. Następnie należy odtworzyć topologię na platformie Azure, nawet po utworzeniu podstawowej oferty przy użyciu jednego z szablonów rozwiązań.

Topologia sieci jest szerokim tematem, ale następujące odwołania mogą dać pewne wskazówki dla wysiłków związanych z migracją:

Uwzględnij użycie adapterów JCA i adapterów zasobów

Jeśli istniejąca aplikacja używa kart JCA lub kart zasobów do łączenia się z innymi systemami przedsiębiorstwa, upewnij się, że zastosowano konfigurację tych artefaktów do serwera Liberty uruchomionego w usłudze Azure Kubernetes Service (AKS). Aby uzyskać więcej informacji, zobacz Omówienie elementów konfiguracji JCA i Architektury łącznika Języka Java.

Określanie, czy jest używane klastrowanie

Operator obsługuje klastrowanie na wszystkie możliwe sposoby uruchamiania obciążenia WAS w usłudze Azure Red Hat OpenShift.

Sprawdź klastrowanie EJB

Jeśli aplikacja korzysta z lokalnych komponentów Enterprise JavaBeans (EJB), może być konieczne zmigrowanie ich do klastrowego komponentu EJB. Aby uzyskać więcej informacji, zobacz Tworzenie aplikacji EJB w środowisku Liberty.

Uwzględnij wymagania dotyczące równoważenia obciążenia

Wstępnie skompilowana oferta Azure Marketplace używa wbudowanej trasy platformy OpenShift do hostowania aplikacji pod publicznym adresem URL oraz do obsługi równoważenia obciążenia. Aby uzyskać więcej informacji, zobacz Konfiguracja usługi OpenShift Route.

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.

Udostępnij ofertę

Aby otworzyć ofertę w witrynie Azure Portal, zobacz IBM WebSphere Liberty i Open Liberty w witrynie Azure Red Hat OpenShift. Wybierz pozycję Utwórz, a następnie użyj informacji zebranych w poprzednich krokach, aby ułatwić wypełnianie pól oferty.

Konto dla magazynów kluczy

Musisz uwzględnić migrację wszystkich magazynów kluczy SSL/TLS używanych przez aplikację. Więcej informacji można znaleźć w temacie Konfigurowanie magazynów kluczy.

Połącz źródła JMS

Po połączeniu baz danych można skonfigurować program JMS, postępując zgodnie z instrukcjami w temacie Omówienie elementów konfiguracji JCA w dokumentacji ibm.

Konto do logowania

Nie da się działać w chmurze bez opanowania logowania. Operator udostępnia różne podejścia do monitorowania. Aby uzyskać więcej informacji, zobacz Monitorowanie środowiska uruchomieniowego serwera Liberty. Warto opanować system rejestrowania i monitorowania w systemie Red Hat OpenShift. Aby uzyskać więcej informacji, zobacz Understanding the logging subsystem for Red Hat OpenShift and About OpenShift Container Platform monitoring (Omówienie podsystemu rejestrowania dla monitorowania platformy kontenera Red Hat OpenShift i About OpenShift Container Platform). Możesz skonfigurować analizę kontenerów w usłudze Azure Monitor dla usługi Azure Red Hat OpenShift. Aby uzyskać więcej informacji, zobacz Konfigurowanie szczegółowych informacji o kontenerze usługi Azure Monitor dla usługi Azure Red Hat OpenShift. Jeśli wolisz korzystać z usługi Elastic Stack, platforma Azure zapewnia doskonałą obsługę funkcji Elastic. Aby uzyskać szczegółowe informacje, zobacz Co to jest integracja elastyczna z platformą Azure? Możesz połączyć wiedzę z tych zasobów, aby uzyskać zoptymalizowane pod kątem platformy Azure rozwiązanie do rejestrowania dla platformy Liberty w usłudze Azure Red Hat OpenShift.

Migrowanie aplikacji

Niezależnie od tego, czy podczas wdrażania zdecydowałeś(-aś) się dostarczyć obraz aplikacji, czy nie, musisz zaktualizować aplikację za pomocą CI/CD. Dokumentacja platformy OpenShift zawiera przykłady pokazujące, jak wykonać tę aktualizację. Aby uzyskać więcej informacji, zobacz Omówienie CI/CD platformy OpenShift Container Platform.

Konfigurowanie testów

Aby uzyskać dostęp do nowych serwerów działających na platformie Azure, należy skonfigurować wszystkie testy w kontenerze względem aplikacji. Podobnie jak w przypadku kwestii związanych z CI/CD, należy upewnić się, że niezbędne reguły zabezpieczeń sieciowych 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. Następujące artykuły zawierają informacje na temat ulepszeń po migracji:

  • Last updated on