Migrowanie aplikacji JBoss EAP do usługi Azure Red Hat OpenShift
W tym przewodniku opisano, co należy wiedzieć, kiedy chcesz przeprowadzić migrację istniejącej aplikacji JBoss EAP do uruchomienia 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 element docelowy jest odpowiednim celem dla nakładu pracy nad migracją
Pierwszym krokiem pomyślnej migracji aplikacji JBoss EAP na platformę Azure jest wybranie najbardziej odpowiedniego celu migracji. Protokół JBoss EAP działa dobrze na maszynach wirtualnych platformy Azure lub w usłudze Azure Red Hat OpenShift.
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. Wybranie maszyn wirtualnych umożliwia odroczenie modernizacji.
Rozwiązanie Red Hat OpenShift łączy przetestowane i zaufane usługi w celu zmniejszenia problemów z opracowywaniem, modernizowaniem, wdrażaniem, uruchamianiem i zarządzaniem aplikacjami. Usługa Azure Red Hat OpenShift jest oparta na platformie Kubernetes. Usługa Azure Red Hat OpenShift zapewnia spójne środowisko w chmurze publicznej, lokalnie, w chmurze hybrydowej lub architekturze brzegowej.
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 JBoss EAP do protokołu JBoss EAP na maszynach wirtualnych platformy Azure. Jeśli możesz tolerować konwertowanie aplikacji do uruchomienia w usłudze Red Hat OpenShift w celu zmniejszenia kosztów środowiska uruchomieniowego, rozważ migrację opartą na usłudze Azure Red Hat OpenShift. W takim przypadku kontynuuj migrację aplikacji JBoss EAP do aplikacji JBoss EAP w usłudze Azure Red Hat OpenShift. Aby zrozumieć różnice między JBoss EAP i JBoss EAP for OpenShift, zobacz Porównanie: JBoss EAP i JBoss EAP for OpenShift.
Określanie, czy wstępnie utworzona oferta witryny Azure Marketplace jest dobrym punktem wyjścia
Najpierw zdecyduj, że usługa Azure Red Hat OpenShift jest odpowiednim celem wdrożenia. Następnie zdecyduj, czy wstępnie utworzona oferta witryny Azure Marketplace jest dobrym punktem wyjścia. Rozważ następujące kwestie dotyczące wstępnie utworzonej oferty witryny Azure Marketplace:
- Firma Red Hat i firma Microsoft stworzyli tę ofertę, aby umożliwić szybką aprowizację aplikacji JBoss EAP w usłudze Azure Red Hat OpenShift.
- Na wysokim poziomie oferta automatyzuje następujące kroki.
- Zainstaluj operator EAP w usłudze Azure Red Hat OpenShift.
- Tworzenie obrazu aplikacji przy użyciu szablonu eap-s2i-build. Aby uzyskać więcej informacji na temat interfejsu source-to-image (S2I), zobacz Using OpenJDK 11 source-to-image for OpenShift (Używanie zestawu openJDK 11 source-to-image for OpenShift).
- Wdróż aplikację Java przy użyciu operatora protokołu EAP. Aby uzyskać więcej informacji, zobacz dokumentację referencyjną operatora EAP w witrynie Red Hat.
Jeśli nie używasz wstępnie utworzonej oferty witryny Azure Marketplace, musisz dowiedzieć się, jak bezpośrednio korzystać z operatora protokołu EAP. Opanowanie operatora wykracza poza zakres tego artykułu. Pełna dokumentacja operatora EAP jest dostępna w witrynie Red Hat.
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.
Określanie, czy wersja protokołu EAP JBoss jest zgodna
Istniejąca wersja protokołu EAP JBoss musi być jedną z wersji obsługiwanych przez operatora. Aby uzyskać więcej informacji, zobacz zgodność wersji i obsługa techniczna w dokumentacji oprogramowania Red Hat.
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 są potrzebne niezależnie od wybranej ścieżki migracji. Następujące aspekty i inne korzyści wynikają ze szczegółowego spisu pojemności serwera.
- Aby ułatwić wybór rozmiaru maszyn wirtualnych w puli węzłów.
- Aby zrozumieć ilość pamięci, która ma być używana przez kontener.
- Aby dowiedzieć się, ile udziałów procesora CPU potrzebuje kontener.
Istnieje możliwość zmiany rozmiaru pul węzłów w usłudze Azure Red Hat OpenShift. Aby uzyskać więcej informacji, zobacz Zmienianie rozmiaru klastra — Microsoft Azure w dokumentacji oprogramowania Red Hat.
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 JBoss EAP, te wpisy tajne znajdują się w wielu różnych plikach konfiguracji i magazynach konfiguracji. Sprawdź wszystkie pliki właściwości i konfiguracji na serwerach produkcyjnych kątem jakichkolwiek wpisów tajnych i haseł. Pamiętaj, aby sprawdzić pliki konfiguracji, takie jak custom-config.xml lub jboss-web.xml w aplikacjach. 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 protokołu EAP dotyczącą wpisów tajnych. Aby uzyskać więcej informacji, zobacz Tworzenie wpisu tajnego w dokumentacji oprogramowania Red Hat.
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 skonfigurować w usłudze Azure Red Hat OpenShift. Aby uzyskać więcej informacji, zobacz Konfiguracja protokołu TLS w usłudze OpenShift Container Platform(replace) w dokumentacji oprogramowania Red Hat.
Sprawdzanie, czy obsługiwana wersja języka Java działa poprawnie
Wszystkie ścieżki migracji protokołu JBoss EAP do usługi Azure Red Hat OpenShift wymagają określonej wersji języka Java, która różni się w zależności od każdej ścieżki. Należy sprawdzić, czy aplikacja może działać poprawnie przy użyciu 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
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 Zarządzanie źródłami danych w dokumentacji oprogramowania Red Hat. Inne zasoby związane z JNDI, takie jak brokery komunikatów ActiveMQ Artemis, mogą wymagać migracji lub ponownej konfiguracji. Aby uzyskać więcej informacji na temat konfiguracji programu Artemis ActiveMQ, zobacz Konfigurowanie komunikatów w dokumentacji oprogramowania Red Hat.
Określenie, czy jest używana replikacja sesji
Jeśli aplikacja opiera się na replikacji sesji, z infinispan lub bez, masz trzy opcje:
- Narzędzie Infinispan działa dobrze na maszynach wirtualnych platformy Azure, ale jeśli używasz profilu zapewniającego wysoką dostępność, pamiętaj o konfiguracji grup JGroups . Ustal, czy system działa jako domena zarządzana, czy autonomiczny serwer.
- Jeśli w domenie zarządzanej profile ha lub full-ha zajmują się grupami JGroup.
- Jeśli na serwerze autonomicznym pliki konfiguracji standalone-ha.xml lub standalone-full-ha.xml zajmują się grupami JGroups.
- Platforma Microsoft Azure nie obsługuje protokołów odnajdywania JGroups opartych na multiemisji UDP. Aby uzyskać więcej informacji, zobacz Using JBoss EAP High Availability in Microsoft Azure (Korzystanie z wysokiej dostępności protokołu JBoss EAP na platformie Microsoft Azure ) w dokumentacji oprogramowania Red Hat.
- 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, w jaki JBoss EAP wykonuje replikację stanu sesji HTTP. Aby uzyskać więcej informacji, zobacz About HTTP Session Replication (Informacje o replikacji sesji HTTP) w dokumentacji oprogramowania Red Hat.
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 rozwiązaniu JBoss EAP, zobacz Zarządzanie źródłami danych w dokumentacji oprogramowania Red Hat.
Ustal, czy JBoss EAP został dostosowany
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ą host, eap_env, autonomiczną i domenę.
- 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 uruchomionym w usłudze Azure Red Hat OpenShift. Aby uzyskać więcej informacji, zobacz Configuring the JBoss EAP for OpenShift Image for Your Java Application (Konfigurowanie obrazu JBoss EAP for OpenShift dla aplikacji Java) w dokumentacji oprogramowania Red Hat.
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, możesz przeprowadzić migrację ich do serwera JMS hostowanego zewnętrznie. 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.
Aby uzyskać więcej informacji, zobacz Konfigurowanie obsługi komunikatów w dokumentacji oprogramowania Red Hat.
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 sekcji Określanie, czy JBoss EAP został dostosowany .
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 Azure Red Hat OpenShift działa w systemie OpenShift 4 przy użyciu systemu Red Hat Enterprise Linux CoreOS (RHCOS) jako systemu operacyjnego dla wszystkich węzłów płaszczyzny sterowania i procesu roboczego. Każdy kod specyficzny dla systemu operacyjnego musi być zgodny z rhCOS.
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, pamiętaj o przechwyceniu ich konfiguracji.
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.
Konto wymagań dotyczących równoważenia obciążenia
Najlepszym sposobem uwzględnienia równoważenia obciążenia jest użycie integracji z usługą App Gateway. Aby uzyskać więcej informacji, zobacz Co to jest aplikacja systemu Azure Gateway?
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 JBoss EAP w witrynie Azure Red Hat OpenShift. Wybierz pozycję Utwórz, a następnie postępuj zgodnie z instrukcjami w ofercie.
Migrowanie aplikacji
Oferta obsługuje proces source-to-Image (S2I) do kompilowania i uruchamiania aplikacji Java na obrazie JBoss EAP for OpenShift. Aplikacja Red Hat zawiera przykład pokazujący, jak to zrobić ręcznie, jeśli chcesz wdrożyć je później samodzielnie. Aby uzyskać więcej informacji, zobacz rozdział 2. Skompiluj i uruchom aplikację Java na obrazie JBoss EAP for OpenShift w dokumentacji oprogramowania Red Hat.
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ć informacje na temat niektórych potencjalnych ulepszeń po migracji, zobacz następujące artykuły:
Implementowanie skalowania. Skalowanie dynamiczne to kluczowa propozycja wartości, która uzasadnia złożoność korzystania z usługi Azure Red Hat OpenShift. Aby uzyskać informacje na temat osiągnięcia rozwiązania do skalowania, zobacz Stosowanie skalowania automatycznego do klastra platformy kontenera OpenShift w dokumentacji rozwiązania OpenShift.
Możesz chcieć wykonać więcej konfiguracji w usłudze Application Gateway. Aby uzyskać więcej informacji, zobacz Omówienie konfiguracji usługi Application Gateway.
Popraw topologię sieci dzięki zaawansowanym usługom równoważenia obciążenia. Aby uzyskać więcej informacji, zobacz Korzystanie z usług równoważenia obciążenia na platformie Azure.
Uzyskaj zoptymalizowane pod kątem języka Java monitorowanie wydajności aplikacji za pomocą usług Azure Monitor i Application Insights. Aby uzyskać więcej informacji, zobacz Monitorowanie aplikacji instrumentacji zerowej dla platformy Kubernetes — Azure Monitor Application Insights.
Wdróż aplikacje w zmigrowanym klastrze usługi Azure Red Hat OpenShift za pomocą usługi Azure DevOps. Aby uzyskać więcej informacji, zobacz Dokumentację rozpoczynania pracy z usługą Azure DevOps.
Tożsamości zarządzane platformy Azure umożliwiają zarządzanie wpisami tajnymi i przypisywanie dostępu opartego na rolach do zasobów platformy Azure. Aby uzyskać więcej informacji, zobacz Co to są tożsamości zarządzane dla zasobów platformy Azure?
Integrowanie uwierzytelniania i autoryzacji języka Java EE z identyfikatorem Entra firmy Microsoft. Aby uzyskać więcej informacji, zobacz Integrowanie identyfikatora Entra firmy Microsoft z aplikacjami — przewodnik wprowadzający.