Migrowanie aplikacji WebSphere do protokołu EAP JBoss w usłudze aplikacja systemu Azure

  • Artykuł

W tym przewodniku opisano, co należy wiedzieć, kiedy chcesz przeprowadzić migrację istniejącej aplikacji WebSphere do uruchomienia w usłudze aplikacja systemu Azure przy użyciu protokołu EAP JBoss.

Przed migracją

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

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 planu usługi App Service.

Lista dostępnych warstw planu usługi App Service zawiera informacje o pamięci, rdzeniach procesora CPU, magazynie i cenach. Należy pamiętać, że protokół JBoss EAP w usłudze App Service jest dostępny tylko w warstwach Premium V3 i Izolowany plan usługi App Service w wersji 2 .

Utworzenie spisu wszystkich wpisów tajnych

Sprawdź wszystkie właściwości i pliki konfiguracji na serwerze produkcyjnym lub serwerach pod kątem wszelkich wpisów tajnych i haseł. Pamiętaj, aby sprawdzić plik ibm-web-bnd.xml w swoich plikach WAR. Wewnątrz aplikacji możesz również znaleźć pliki konfiguracji zawierające hasła lub poświadczenia. Te pliki mogą obejmować pliki application.properties lub application.yml, w przypadku aplikacji Spring Boot.

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

Protokół JBoss EAP w usłudze aplikacja systemu Azure obsługuje środowisko Java 8 i 11. Dlatego musisz sprawdzić, czy Twoja aplikacja może działać prawidłowo, używając tej obsługiwanej wersji. Ta weryfikacja jest szczególnie ważna, jeśli bieżący serwer używa obsługiwanego zestawu 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. Niektóre zasoby, takie jak brokery komunikatów JMS, mogą wymagać migracji lub ponownej konfiguracji.

W aplikacji

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

Określanie, czy bazy danych są używane

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

  • Nazwa źródła danych.
  • Konfiguracja puli połączeń.
  • Lokalizacja pliku JAR sterownika JDBC.

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

Każde użycie systemu plików na serwerze aplikacji będzie wymagało ponownej konfiguracji lub, w rzadkich przypadkach, zmiany architektury. System plików może być używany przez moduły udostępnione WebSphere lub kod aplikacji. Można zidentyfikować niektóre lub wszystkie z następujących scenariuszy.

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.

Zawartość dynamiczna lub wewnętrzna

W przypadku plików, które są często zapisywane i odczytywane przez aplikację (np. pliki danych tymczasowych) lub pliki statyczne widoczne tylko dla aplikacji, można zainstalować usługę Azure Storage w systemie plików usługi App Service. Aby uzyskać więcej informacji, zobacz Obsługa zawartości z usługi Azure Storage w usłudze App Service w systemie Linux.

Określanie, czy Twoja aplikacja bazuje na zaplanowanych zadaniach

Zaplanowane zadania, takie jak zadania usługi Quartz Scheduler lub zadania cron systemu Unix, nie powinny być używane z usługą aplikacja systemu Azure Service. usługa aplikacja systemu Azure nie uniemożliwi wdrażania aplikacji zawierającej zaplanowane zadania wewnętrznie. Jeśli jednak aplikacja jest skalowana w poziomie, to samo zaplanowane zadanie może zostać uruchomione więcej niż raz w zaplanowanym okresie. Ta sytuacja może prowadzić do niezamierzonych konsekwencji.

Aby wykonać zaplanowane zadania na platformie Azure, rozważ użycie usługi Azure Functions z wyzwalaczem czasomierza. Aby uzyskać więcej informacji, zobacz Wyzwalacz czasomierza dla usługi Azure Functions. Nie musisz migrować kodu zadania do funkcji. Aby wyzwolić zadanie, funkcja może po prostu wywoływać adres URL w aplikacji.

Uwaga

Aby zapobiec złośliwemu użyciu, prawdopodobnie trzeba będzie wprowadzić wymaganie podania poświadczeń w punkcie końcowym wywoływania zadania. W takim przypadku poświadczenia muszą zostać podane przez funkcję wyzwalacza.

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

Określanie, czy aplikacja używa interfejsów API specyficznych dla serwera WebSphere

Jeśli aplikacja korzysta z interfejsów API specyficznych dla platformy WebSphere, musisz refaktoryzować aplikację, aby nie używać ich. Zestaw narzędzi Red Hat Migration Toolkit for Apps może pomóc w usuwaniu i refaktoryzacji tych zależności.

Określanie, czy aplikacja używa obiektów bean jednostek lub obiektów bean CMP w stylu EJB 2.x

Jeśli aplikacja używa obiektów bean jednostek lub obiektów bean CMP w stylu EJB 2.x, należy wykonać refaktoryzację aplikacji w taki sposób, aby usunąć te zależności.

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

Jeśli masz aplikacje klienckie, które łączą się z aplikacją (serwer) przy użyciu funkcji klienta aplikacji JavaEE, należy refaktoryzować zarówno aplikacje klienckie, jak i aplikację (serwer) w celu używania interfejsów API HTTP.

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ślanie, czy są używane czasomierze EJB

Jeśli aplikacja używa czasomierzy EJB, należy sprawdzić, czy kod czasomierza EJB może być wyzwalany niezależnie przez każde wystąpienie protokołu JBoss EAP. Ta weryfikacja jest wymagana, ponieważ gdy usługa App Service jest skalowana w poziomie, każdy czasomierz EJB zostanie wyzwolony we własnym wystąpieniu protokołu EAP JBoss.

Określanie, czy są używane łączniki JCA

Jeśli aplikacja używa łączników JCA, należy sprawdzić, czy łącznik JCA może być używany w aplikacji JBoss EAP. Jeśli implementacja JCA jest powiązana z platformą WebSphere, należy refaktoryzować aplikację, aby usunąć zależność od łącznika JCA. Jeśli można użyć łącznika JCA, należy dodać pliki JAR do ścieżki klasy serwera. Należy również umieścić niezbędne pliki konfiguracji w odpowiedniej lokalizacji w katalogach serwerów JBoss EAP, aby było dostępne.

Określanie, czy usługa JAAS jest w użyciu

Jeśli aplikacja korzysta z usługi JAAS, musisz przechwycić sposób konfigurowania usługi JAAS. Jeśli używa ona bazy danych, możesz przekonwertować ją na domenę JAAS w aplikacji JBoss EAP. Jeśli jest to implementacja niestandardowa, należy sprawdzić, czy może być używana w aplikacji JBoss EAP.

Określanie, czy aplikacja używa adaptera zasobów

Jeśli aplikacja wymaga karty zasobów (RA), musi być zgodna z protokołem JBoss EAP. Ustal, czy usługa RA działa prawidłowo w autonomicznym wystąpieniu protokołu JBoss EAP, wdrażając go na serwerze i prawidłowo ją konfigurując. Jeśli ra działa prawidłowo, należy dodać pliki JAR do ścieżki klas serwera wystąpienia usługi App Service i umieścić niezbędne pliki konfiguracji w prawidłowej lokalizacji w katalogach serwerów JBoss EAP, aby były dostępne.

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, sprawdź pliki application.xml i ibm-application-bnd.xml i przechwytują ich konfiguracje.

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.

Migracja

Red Hat Migration Toolkit for Apps

Zestaw narzędzi Red Hat Migration Toolkit for Applications to bezpłatne rozszerzenie dla programu Visual Studio Code. To rozszerzenie analizuje kod i konfigurację aplikacji, aby udostępnić zalecenia dotyczące migrowania aplikacji Jakarta EE do protokołu JBoss EAP z innych serwerów aplikacji, takich jak usuwanie zależności z zastrzeżonych interfejsów API. Rozszerzenie udostępnia również zalecenia w przypadku migracji do chmury ze środowiska lokalnego. Aby uzyskać więcej informacji, zobacz Migration Toolkit for Applications overview (Omówienie zestawu narzędzi migracji dla aplikacji).

Zawartość tego przewodnika pomoże Ci rozwiązać inne składniki podróży migracji, takie jak wybór prawidłowego typu planu usługi App Service, zewnętrzna lokalizacja sesji oraz zarządzanie wystąpieniami protokołu EAP zamiast interfejsu zarządzania JBoss przy użyciu platformy Azure.

Aprowizacja planu usługi App Service

Z listy dostępnych planów usług wybierz plan, którego specyfikacje spełniają lub przekraczają specyfikacje bieżącego sprzętu produkcyjnego.

Uwaga

Jeśli planujesz uruchamianie wdrożeń przejściowych/kanarkowych lub korzystanie z miejsc wdrożenia, plan usługi App Service musi uwzględniać dodatkową pojemność. W przypadku aplikacji języka Java zalecamy korzystanie z planów Premium lub wyższych.

Utwórz ten plan usługi App Service.

Tworzenie i wdrażanie aplikacji internetowych

Musisz utworzyć aplikację internetową w planie usługi App Service dla każdego pliku WAR wdrożonego na serwerze JBoss EAP.

Uwaga

Chociaż istnieje możliwość wdrożenia wielu plików WAR w pojedynczej aplikacji internetowej, jest to wysoce niepożądane. Wdrożenie wielu plików WAR w pojedynczej aplikacji internetowej uniemożliwia skalowanie poszczególnych aplikacji zgodnie z ich wymaganiami dotyczącymi użycia. Zwiększa również złożoność kolejnych potoków wdrażania. Jeśli pod pojedynczym adresem URL musi być dostępnych wiele aplikacji, rozważ użycie rozwiązania routingu, takiego jak Azure Application Gateway.

Aplikacje Maven

Jeśli aplikacja została skompilowana z pliku POM narzędzia Maven, użyj wtyczki Webapp dla narzędzia Maven, aby utworzyć aplikację internetową i wdrożyć aplikację. Aby uzyskać więcej informacji, zobacz sekcję Konfigurowanie wtyczki Maven w przewodniku Szybki start: tworzenie aplikacji Java w usłudze aplikacja systemu Azure Service.

Aplikacje inne niż Maven

Jeśli nie możesz użyć wtyczki Maven, musisz zaaprowizować aplikację internetową za pomocą innych mechanizmów, takich jak:

Po utworzeniu aplikacji internetowej użyj jednego z dostępnych mechanizmów wdrażania, aby wdrożyć aplikację. Aby uzyskać więcej informacji, zobaczWdrażanie plików w usłudze App Service.

Migracja opcji środowiska uruchomieniowego JVM

Jeśli aplikacja wymaga określonych opcji środowiska uruchomieniowego, użyj najbardziej odpowiedniego mechanizmu, aby je określić. Aby uzyskać więcej informacji, zobacz sekcję Ustawianie opcji środowiska uruchomieniowego języka Java w temacie Konfigurowanie aplikacji Java dla usługi aplikacja systemu Azure Service.

Wypełnianie wpisów tajnych

Do przechowywania wszelkich wpisów tajnych specyficznych dla aplikacji użyj ustawień aplikacji. Jeśli zamierzasz używać tego samego wpisu tajnego lub wpisów tajnych w wielu aplikacjach lub potrzebujesz precyzyjnych zasad dostępu i możliwości inspekcji, zamiast tego użyj odwołań usługi Azure Key Vault. Aby uzyskać więcej informacji, zobacz sekcję Use KeyVault References (Używanie odwołań do usługi KeyVault) w temacie Configure a Java app for aplikacja systemu Azure Service (Konfigurowanie aplikacji Java dla usługi aplikacja systemu Azure Service).

Konfigurowanie domeny niestandardowej oraz protokołu SSL

Jeśli aplikacja będzie widoczna w domenie niestandardowej, należy na nią zamapować aplikację internetową. Aby uzyskać więcej informacji, zobacz Samouczek: mapowania istniejącej niestandardowej nazwy DNS na usługę aplikacja systemu Azure Service.

Następnie należy powiązać certyfikat TLS/SSL dla tej domeny z aplikacją internetową usługi App Service. Aby uzyskać więcej informacji, zobacz Zabezpieczanie niestandardowej nazwy DNS przy użyciu powiązania TLS/SSL w usłudze aplikacja systemu Azure.

Migracja źródeł danych, bibliotek i zasobów JNDI

Aby przeprowadzić migrację źródeł danych, wykonaj kroki opisane w sekcji Konfigurowanie źródeł danych w temacie Konfigurowanie aplikacji Java dla usługi aplikacja systemu Azure Service.

Przeprowadź migrację wszelkich dodatkowych zależności ścieżki klas na poziomie serwera, postępując zgodnie z instrukcjami w sekcji JBoss EAP w temacie Konfigurowanie aplikacji Java dla usługi aplikacja systemu Azure Service.

Migrowanie wszelkich dodatkowych udostępnionych zasobów JDNI na poziomie serwera. Aby uzyskać więcej informacji, zobacz sekcję JBoss EAP w temacie Configure a Java app for aplikacja systemu Azure Service (Konfigurowanie aplikacji Java dla usługi aplikacja systemu Azure).

Uwaga

Jeśli korzystasz z zalecanej architektury jednej architektury WAR na aplikację, rozważ migrację bibliotek klas na poziomie serwera i zasobów JNDI do aplikacji. W ten sposób znacznie uprości zarządzanie składnikami i zarządzanie zmianami. Jeśli chcesz wdrożyć więcej niż jedną war na aplikację, zapoznaj się z jednym z naszych przewodników towarzyszących wymienionych na początku tego przewodnika.

Migrowanie zaplanowanych zadań

Co najmniej należy przenieść zaplanowane zadania na maszynę wirtualną platformy Azure, aby nie były już częścią aplikacji. Alternatywnie możesz zmodernizować je w środowisku Java opartym na zdarzeniach przy użyciu usług platformy Azure, takich jak Azure Functions, SQL Database i Event Hubs.

Ponowne uruchamianie i test dymny

Na koniec musisz ponownie uruchomić aplikację internetową, aby zastosować wszystkie zmiany konfiguracji. Po zakończeniu ponownego uruchamiania sprawdź, czy aplikacja działa prawidłowo.

Po migracji

Po przeprowadzeniu migracji aplikacji do usługi aplikacja systemu Azure należy sprawdzić, czy działa zgodnie z oczekiwaniami. Po wykonaniu tych czynności skorzystaj z naszych zaleceń, które mogą sprawić, że aplikacja będzie bardziej natywna w chmurze.

Zalecenia