Uwaga
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
W tym przewodniku opisano, co należy wiedzieć, kiedy chcesz przeprowadzić migrację istniejącej aplikacji Red Hat JBoss Enterprise Application Platform (EAP) do uruchamiania w aplikacji JBoss EAP w wystąpieniu usługi Azure App Service.
Przygotowanie do migracji
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 rozmiaru maszyn wirtualnych w puli węzłów, ilość pamięci używanej przez kontener oraz liczbę udziałów procesora CPU w kontenerze.
Jeśli masz dane testowania obciążenia, utwórz migawkę bieżących wyników testu, aby można było ponownie uruchomić testy po migracji, aby upewnić się, że spełniasz oczekiwane cele wydajności.
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
Sprawdź wszystkie atrybuty i pliki konfiguracji na serwerach produkcyjnych pod kątem tajnych informacji i haseł. Pamiętaj, aby sprawdzić jboss-web.xml w plikach archiwum aplikacji webowej (WAR). Pliki konfiguracji zawierające hasła lub poświadczenia można również znaleźć w aplikacji.
Rozważ przechowywanie tych wpisów tajnych w usłudze Azure Key Vault. Aby uzyskać więcej informacji, zobacz Podstawowe pojęcia dotyczące usługi Azure Key Vault.
W wystąpieniu usługi App Service można używać wpisów tajnych usługi Key Vault z odwołaniami usługi Key Vault. Odwołania do usługi Key Vault umożliwiają używanie wpisów tajnych w aplikacji przy zachowaniu ich bezpieczeństwa i szyfrowania w spoczynku. Aby uzyskać więcej informacji, zobacz Use Key Vault references for App Service and Azure Functions (Używanie odwołań usługi Key Vault dla usług App Service i Azure Functions).
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 App Service wymaga obsługiwanej wersji języka Java. Aby uzyskać wskazówki dotyczące używanej wersji zestawu Java Development Kit (JDK), zobacz Obsługiwane konfiguracje w dokumentacji oprogramowania Red Hat.
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 zewnętrznych
Zasoby zewnętrzne, takie jak źródła danych, brokery komunikatów usługi Java Message Service (JMS) oraz inne są wstrzykiwane za pośrednictwem Interfejsu Nazw i Katalogów Javy (JNDI). Niektóre takie zasoby mogą wymagać migracji lub ponownej konfiguracji.
W aplikacji
Sprawdź pliki WEB-INF/jboss-web.xml i/lub WEB-INF/web.xml. Poszukaj elementów <Resource>
wewnątrz elementu <Context>
.
Źródła danych
Źródła danych to zasoby JNDI z atrybutem type
ustawionym na javax.sql.DataSource
. Dla każdego źródła danych należy udokumentować następujące informacje:
- Jaka jest nazwa źródła danych?
- Jaka jest konfiguracja puli połączeń?
- Gdzie można znaleźć plik JAR sterownika JDBC (Java Database Connectivity)?
Aby uzyskać więcej informacji, zobacz O źródłach danych JBoss Enterprise Application Platform (EAP) w dokumentacji JBoss EAP.
Wszystkie inne zasoby zewnętrzne
Nie jest możliwe udokumentowanie każdej możliwej zależności zewnętrznej w tym przewodniku. Twój zespół odpowiada za sprawdzenie, czy każda zależność zewnętrzna aplikacji może być spełniona po migracji.
Określanie, czy i jak jest używany system plików
Każde użycie systemu plików na serwerze aplikacji wymaga ponownej konfiguracji lub, w rzadkich przypadkach, zmian architektury. Moduły JBoss EAP lub kod aplikacji mogą używać systemu plików. Niektóre lub wszystkie scenariusze opisane w poniższych sekcjach można zidentyfikować.
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.
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 użyć lokalnego magazynu plików skojarzonego z planem usługi App Service. Aby uzyskać więcej informacji, zobacz Funkcje systemu operacyjnego w usłudze aplikacja systemu Azure i Opis systemu plików usługi aplikacja systemu Azure Service.
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.
Utwórz spis wszystkich zaplanowanych zadań uruchomionych na serwerach produkcyjnych wewnątrz lub poza kodem aplikacji.
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 (AMQP) 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.
Określanie, czy są używane łączniki JCA
Jeśli aplikacja używa łączników JCA (Java Connector Architecture), sprawdź, czy możesz użyć łącznika JCA w aplikacji JBoss EAP. Jeśli możesz użyć łącznika JCA w programie JBoss EAP, aby był dostępny, musisz dodać pliki Java Archive (JAR) do ścieżki klasy serwera i umieścić niezbędne pliki konfiguracji w odpowiedniej lokalizacji w katalogach serwerów JBoss EAP.
Określanie, czy usługa JAAS jest w użyciu
Jeśli Twoja aplikacja korzysta z usługi JAAS, należy przechwycić sposób konfiguracji tej usługi. 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 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 Twoja aplikacja jest spakowana jako plik EAR, przejrzyj i zarejestruj konfigurację pliku application.xml.
Uwaga
Jeśli chcesz mieć możliwość niezależnego skalowania poszczególnych aplikacji internetowych w celu lepszego wykorzystania zasobów usługi App Service, należy podzielić EAR na oddzielne aplikacje internetowe.
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.
Wykonywanie testów w miejscu
Przed utworzeniem usługi Web Apps przeprowadź migrację aplikacji do wersji JDK i JBoss EAP, które mają być używane w usłudze App Service. Dokładnie przetestuj swoją aplikację, aby zagwarantować jej zgodność i wydajność.
Uwagi dotyczące funkcji JBoss EAP w usłudze App Service
W przypadku korzystania z protokołu JBoss EAP w usłudze App Service należy wziąć pod uwagę następujące uwagi.
Konsola zarządzania JBoss EAP: konsola internetowa JBoss nie jest uwidoczniona w usłudze App Service. Zamiast tego witryna Azure Portal udostępnia interfejsy API zarządzania dla aplikacji i należy wdrożyć przy użyciu interfejsu wiersza polecenia platformy Azure, wtyczki Azure Maven lub innych narzędzi deweloperskich platformy Azure. Podczas uruchamiania aplikacji można przeprowadzić dalszą konfigurację zasobów JBoss przy użyciu interfejsu wiersza polecenia narzędzia JBoss.
Transakcje: Obsługiwany jest interfejs API transakcji, a także istnieje wsparcie dla automatycznego przywracania transakcji. Aby uzyskać więcej informacji, zobacz Zarządzanie transakcjami na platformie JBoss EAP w dokumentacji oprogramowania Red Hat.
Tryb domeny zarządzanej: w środowisku produkcyjnym z wieloma serwerami tryb domeny zarządzanej w aplikacji JBoss EAP oferuje scentralizowane funkcje zarządzane. Jednak w przypadku aplikacji JBoss EAP w usłudze App Service platforma App Service przejmuje odpowiedzialność za konfigurację wystąpień serwera i zarządzanie nimi. Usługa App Service eliminuje konieczność korzystania z trybu domeny zarządzanej JBoss EAP. Tryb domeny jest dobrym wyborem w przypadku wdrożeń wieloserwerowych opartych na maszynach wirtualnych. Aby uzyskać więcej informacji, zobacz Informacje o domenach zarządzanych w dokumentacji oprogramowania Red Hat.
Klastrowanie serwer-serwer: usługa App Service w pełni obsługuje wdrożenia klastrowane JBoss EAP. Oznacza to, że można bezpiecznie użyć:
- Fasola sesji stanowej.
- Transakcje rozproszone.
- Podobne funkcje, które wymagają komunikacji między wystąpieniami lub wysokiej dostępności.
Aby uzyskać więcej informacji, zobacz sekcję Clustering (Klastrowanie ) w temacie Configure a Java app for Azure App Service (Konfigurowanie aplikacji Java dla usługi Azure App Service).
Migracja
Zestaw narzędzi Red Hat do migracji aplikacji
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 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 ułatwia rozwiązywanie problemów z innymi składnikami podróży migracji, takimi 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.
Aprowizuj usługę aplikacja systemu Azure dla środowiska uruchomieniowego protokołu EAP JBoss
Użyj następujących poleceń, aby utworzyć grupę zasobów i plan usługi aplikacja systemu Azure. Po utworzeniu planu usługi App Service zostanie utworzony plan aplikacji internetowej systemu Linux przy użyciu środowiska uruchomieniowego JBoss Enterprise Application Platform (EAP).
Upewnij się, że określone zmienne środowiskowe mają odpowiednie wartości.
az group create --resource-group $resourceGroup --location eastus
az acr create --resource-group $resourceGroup --name $acrName --sku Standard
az appservice plan create \
--resource-group $resourceGroup \
--name $jbossAppService \
--is-linux \
--sku P0v3
az webapp create \
--resource-group $resourceGroup \
--name $jbossWebApp \
--plan $jbossAppServicePlan \
--runtime "JBOSSEAP|8-java17"
# Or use "JBOSSEAP|8-java11" if you're using Java 11
Kompilowanie aplikacji
Skompiluj aplikację przy użyciu następującego polecenia narzędzia Maven.
mvn clean install -DskipTests
Wdrażanie aplikacji
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 Szybki start: tworzenie aplikacji Java w usłudze aplikacja systemu Azure Service.
Aby zautomatyzować wdrażanie aplikacji JBoss EAP, możesz użyć zadania usługi Azure Pipelines dla aplikacji internetowej lub akcji usługi GitHub na potrzeby wdrażania w usłudze Azure WebApp.
Konfigurowanie źródeł danych
Podczas rejestrowania źródła danych przy użyciu platformy JBoss Enterprise Application Platform (EAP) istnieją trzy podstawowe kroki: przekazywanie sterownika JDBC (Java Database Connectivity), dodawanie sterownika JDBC jako modułu i rejestrowanie modułu. Aby uzyskać więcej informacji, zobacz Zarządzanie źródłami danych w dokumentacji protokołu EAP JBoss. Usługa App Service to bezstanowa usługa hostingu, więc polecenia konfiguracji do dodawania i rejestrowania modułu źródła danych muszą być skryptowe i stosowane podczas uruchamiania kontenera.
Aby skonfigurować źródła danych, wykonaj następujące kroki.
Uzyskaj sterownik JDBC bazy danych.
Utwórz plik definicji modułu XML dla sterownika JDBC. Pokazany przykład to definicja modułu dla bazy danych PostgreSQL. Pamiętaj, aby zastąpić
resource-root path
wartość ścieżką do używanego sterownika JDBC.<?xml version="1.0" ?> <module xmlns="urn:jboss:module:1.1" name="org.postgres"> <resources> <!-- ***** IMPORTANT: REPLACE THIS PLACEHOLDER *******--> <resource-root path="/home/site/deployments/tools/postgresql-42.2.12.jar" /> </resources> <dependencies> <module name="javax.api"/> <module name="javax.transaction.api"/> </dependencies> </module>
Umieść polecenia interfejsu wiersza polecenia JBoss w pliku o nazwie jboss-cli-commands.cli. Polecenia JBoss muszą dodać moduł i zarejestrować go jako źródło danych. W przykładzie przedstawiono polecenia JBoss CLI dla PostgreSQL.
Uwaga
Firma Microsoft zaleca korzystanie z najbezpieczniejszego dostępnego przepływu uwierzytelniania. Przepływ uwierzytelniania opisany w tej procedurze, taki jak bazy danych, pamięci podręczne, komunikaty lub usługi sztucznej inteligencji, wymaga bardzo wysokiego stopnia zaufania w aplikacji i niesie ze sobą ryzyko, które nie występują w innych przepływach. Użyj tego przepływu tylko wtedy, gdy bardziej bezpieczne opcje, takie jak tożsamości zarządzane dla połączeń bez hasła lub bez kluczy, nie są opłacalne. W przypadku operacji maszyny lokalnej preferuj tożsamości użytkowników dla połączeń bez hasła lub bez klucza.
module add --name=org.postgres --resources=/home/site/deployments/tools/postgresql-42.2.12.jar --module-xml=/home/site/deployments/tools/postgres-module.xml /subsystem=datasources/jdbc-driver=postgres:add(driver-name="postgres",driver-module-name="org.postgres",driver-class-name=org.postgresql.Driver,driver-xa-datasource-class-name=org.postgresql.xa.PGXADataSource) data-source add --name=postgresDS --driver-name=postgres --jndi-name=java:jboss/datasources/postgresDS --connection-url=${POSTGRES_CONNECTION_URL,env.POSTGRES_CONNECTION_URL:jdbc:postgresql://db:5432/postgres} --user-name=${POSTGRES_SERVER_ADMIN_FULL_NAME,env.POSTGRES_SERVER_ADMIN_FULL_NAME:postgres} --password=${POSTGRES_SERVER_ADMIN_PASSWORD,env.POSTGRES_SERVER_ADMIN_PASSWORD:example} --use-ccm=true --max-pool-size=5 --blocking-timeout-wait-millis=5000 --enabled=true --driver-class=org.postgresql.Driver --exception-sorter-class-name=org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLExceptionSorter --jta=true --use-java-context=true --valid-connection-checker-class-name=org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker
Utwórz skrypt startowy o nazwie startup_script.sh , który wywołuje polecenia interfejsu wiersza polecenia JBoss. W przykładzie pokazano, jak wywołać plik jboss-cli-commands.cli . Później skonfigurujesz usługę App Service tak, aby uruchamiała ten skrypt po uruchomieniu wystąpienia.
$JBOSS_HOME/bin/jboss-cli.sh --connect --file=/home/site/deployments/tools/jboss-cli-commands.cli
Korzystając z wybranego klienta FTP, przekaż sterownik JDBC, jboss-cli-commands.cli, startup_script.sh i definicję modułu do /site/deployments/tools/.
Skonfiguruj witrynę do uruchamiania startup_script.sh po uruchomieniu kontenera. W witrynie Azure Portal przejdź do pozycji Ogólne ustawienia > konfiguracji > Polecenie uruchamiania. Ustaw pole polecenia uruchamiania na /home/site/deployments/tools/startup_script.sh, a następnie wybierz pozycję Zapisz.
Uruchom ponownie aplikację internetową, co powoduje uruchomienie skryptu konfiguracji.
Zaktualizuj konfigurację źródła danych interfejsu API transakcji Java (JTA) dla aplikacji. Otwórz plik src/main/resources/META-INF/persistence.xml aplikacji i znajdź
<jta-data-source>
element . Zastąp jego zawartość w następujący sposób:<jta-data-source>java:jboss/datasources/postgresDS</jta-data-source>
Kompilowanie aplikacji
Skompiluj aplikację przy użyciu następującego polecenia narzędzia Maven.
mvn clean install -DskipTests
Wdrażanie aplikacji
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 Szybki start: tworzenie aplikacji Java w usłudze aplikacja systemu Azure Service.
Aby zautomatyzować wdrażanie aplikacji JBoss EAP, możesz użyć zadania usługi Azure Pipelines dla aplikacji internetowej lub akcji usługi GitHub na potrzeby wdrażania w usłudze Azure WebApp.
Po migracji
Po przeprowadzeniu migracji aplikacji do usługi Azure App Service należy sprawdzić, czy działa zgodnie z oczekiwaniami. Po wykonaniu tej czynności mamy pewne zalecenia, które mogą sprawić, że aplikacja będzie bardziej natywna dla chmury.
Zalecenia
Jeśli zdecydujesz się użyć katalogu /home do przechowywania plików, rozważ zastąpienie go usługą Azure Storage. Aby uzyskać więcej informacji, zobacz Access Azure Storage as a network share from a container in App Service (Uzyskiwanie dostępu do usługi Azure Storage jako udziału sieciowego z kontenera w usłudze App Service).
Jeśli masz konfigurację w katalogu /home, który zawiera parametry połączenia, klucze SSL i inne informacje tajne, rozważ użycie usługi Azure Key Vault i/lub iniekcji parametrów z ustawieniami aplikacji tam, gdzie to możliwe. Aby uzyskać więcej informacji, zobacz Use Key Vault references for App Service and Azure Functions and Configure an App Service app in the Azure Portal (Korzystanie z odwołań usługi Key Vault dla usług App Service i Azure Functions ) oraz Configure an App Service app in the Azure Portal (Konfigurowanie aplikacji usługi App Service w witrynie Azure Portal).
Rozważ użycie miejsc wdrożenia w celu zapewnienia niezawodnych wdrożeń z zerowym przestojem. Aby uzyskać więcej informacji, zobacz Konfigurowanie środowisk przejściowych w usłudze Azure App Service.
Zaprojektuj i zaimplementuj strategię DevOps. Aby zachować niezawodność przy jednoczesnym zwiększaniu szybkości tworzenia rozwiązań, rozważ automatyzację wdrożeń i testowania przy użyciu usługi Azure Pipelines. Aby uzyskać więcej informacji, zobacz Kompilowanie i wdrażanie w aplikacji internetowej Java. W przypadku korzystania z miejsc wdrożenia można zautomatyzować wdrażanie w miejscu , po którym następuje zamiana miejsca. Aby uzyskać więcej informacji, zobacz sekcję Wdrażanie w miejscu w temacie Wdrażanie aplikacji internetowej platformy Azure (Linux).
Zaprojektuj i zaimplementuj strategię ciągłości działania i odzyskiwania po awarii. W przypadku aplikacji o krytycznym znaczeniu rozważ zastosowanie architektury wdrażania w wielu regionach. Aby uzyskać więcej informacji, zobacz Aplikacja internetowa o wysokiej dostępności w wielu regionach.