Migrowanie aplikacji serwera WebLogic do rozwiązania WildFly w usłudze Azure Kubernetes Service

  • Artykuł

W tym przewodniku opisano, co należy wiedzieć, kiedy chcesz przeprowadzić migrację istniejącej aplikacji serwera WebLogic do uruchamiania na platformie WildFly w kontenerze usługi Azure Kubernetes Service.

Przed migracją

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

Jeśli nie możesz spełnić wymagań dotyczących migracji wstępnej, zapoznaj się z przewodnikiem po migracji towarzyszącej:

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.

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

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>

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.

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 dwie możliwości:

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

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

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.

Uwaga

Jeśli chcesz mieć możliwość niezależnego skalowania poszczególnych aplikacji internetowych w celu lepszego korzystania z zasobów usługi Azure Kubernetes 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.

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

Korzystanie z platformy WildFly w usłudze Azure Kubernetes Service wymaga określonej wersji języka Java, dlatego należy potwierdzić, że aplikacja działa prawidłowo 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

Zobacz sekcję Requirements (Wymagania), aby dowiedzieć się, której wersji należy użyć, aby uruchomić serwer WildFly.

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ą Azure Kubernetes Service (AKS). Usługa Azure Kubernetes Service nie uniemożliwi wdrożenia aplikacji zawierającej wewnętrznie zaplanowane zadania. 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 wykonywać zaplanowane zadania w klastrze usługi AKS, definiuj zadania Kubernetes CronJob wedle potrzeby. Aby uzyskać więcej informacji, zobacz Uruchamiania zautomatyzowanych zadań przy użyciu obiektów CronJob.

Określanie, czy jest używane narzędzie do obsługi skryptów WebLogic

Jeśli obecnie używasz narzędzia WebLogic Scripting Tool (WLST) do wykonania wdrożenia, musisz ocenić, co robi. Jeśli WLST zmienia dowolne parametry aplikacji (runtime) w ramach wdrożenia, upewnij się, że te parametry są zgodne z jedną z następujących opcji:

  • Parametry są zewnętrzne jako ustawienia aplikacji.
  • Parametry są osadzone w aplikacji.
  • Parametry używają interfejsu wiersza polecenia narzędzia JBoss podczas wdrażania.

Jeśli WLST wykonuje więcej niż to, co zostało wymienione powyżej, będziesz mieć dodatkową pracę do wykonania podczas migracji.

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

Jeśli Twoja aplikacja używa interfejsów API specyficznych dla serwera WebLogic, należy wykonać jej refaktoryzację w celu usunięcia tych zależności. Na przykład jeśli użyto klasy wymienionej w dokumentacji interfejsu Java API dla programu Oracle WebLogic Server, to w aplikacji zastosowano interfejs API specyficzny dla serwera WebLogic. Należy refaktoryzować, aby usunąć odwołanie.

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 Java EE

Jeśli masz aplikacje klienckie, które łączą się z aplikacją (serwerem) za pomocą funkcji klienta aplikacji Java EE, będzie trzeba wykonać refaktoryzację aplikacji klienckich i Twojej aplikacji (serwera) tak, aby korzystała z interfejsów HTTP API.

Określanie, czy użyto planu wdrożenia

Jeśli aplikacja została wdrożona przy użyciu planu wdrożenia, oceń, co robi plan wdrożenia. Jeśli plan wdrożenia to proste wdrożenie, będzie można wdrożyć aplikację internetową bez wprowadzania żadnych zmian. Jeśli plan wdrożenia jest bardziej rozbudowany, ustal, czy możesz użyć interfejsu wiersza polecenia JBoss do prawidłowego skonfigurowania aplikacji w ramach wdrożenia. Jeśli nie można użyć interfejsu wiersza polecenia JBoss, refaktoryzuj aplikację w taki sposób, że plan wdrożenia nie jest już potrzebny.

Określanie, czy są używane czasomierze EJB

Jeśli aplikacja korzysta z czasomierzy EJB, należy zweryfikować, czy kod czasomierza EJB może być wyzwalany niezależnie przez każde wystąpienie serwera WildFly. Ta weryfikacja jest konieczna, ponieważ w scenariuszu wdrażania usługi Azure Kubernetes Service każdy czasomierz EJB będzie wyzwalany we własnym wystąpieniu serwera WildFly.

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. System plików może być używany przez udostępnione moduły WebLogic lub kod aplikacji. Możesz zidentyfikować niektóre lub wszystkie scenariusze opisane w poniższych sekcjach.

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

Na potrzeby plików często zapisywanych i odczytywanych przez aplikację (na przykład plików danych tymczasowych) lub plików statycznych, które są widoczne tylko dla aplikacji, możesz zainstalować udziały plików usługi Azure Storage jako trwałe woluminy. Aby uzyskać więcej informacji, zobacz Dynamiczne tworzenie i korzystanie z trwałego woluminu za pomocą usługi Azure Files w usłudze Azure Kubernetes Service.

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

Jeśli Twoja aplikacja korzysta z łączników JCA, musisz sprawdzić, czy łącznik JCA może być używany na serwerze WildFly. Jeśli implementacja JCA jest powiązana z serwerem WebLogic, trzeba będzie wykonać refaktoryzację aplikacji w celu usunięcia tej zależności. Jeśli można go używać, trzeba będzie dodać pliki JAR do ścieżki klas serwera i umieścić niezbędne pliki konfiguracyjne w prawidłowej lokalizacji w katalogach serwera WildFly, aby były dostępne.

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

Jeśli aplikacja wymaga adaptera zasobów, musi być zgodna z serwerem WildFly. Ustal, czy adapter zasobów działa prawidłowo na autonomicznym wystąpieniu serwera WildFly, wdrażając go na serwerze i poprawnie konfigurując. Jeśli adapter zasobów będzie działać prawidłowo, trzeba będzie dodać pliki JAR do ścieżki klas serwera obrazu platformy Docker i umieścić niezbędne pliki konfiguracji w poprawnej lokalizacji w katalogach serwera WildFly, aby były dostępne.

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 korzysta ona z bazy danych, możesz ją przekonwertować na domenę usługi JAAS na serwerze WildFly. Jeśli jest to implementacja niestandardowa, będzie trzeba sprawdzić, czy może być używana na serwerze WildFly.

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. Usługa Azure Kubernetes Service umożliwia skalowanie, ale jeśli używasz interfejsu API klastra WebLogic, musisz refaktoryzować kod, aby wyeliminować użycie tego interfejsu API.

Wykonywanie testów w miejscu

Przed utworzeniem obrazów kontenerów dokonaj migracji aplikacji do wersji zestawu JDK i serwera WildFly, których zamierzasz używać w usłudze AKS. Dokładnie przetestuj swoją aplikację, aby zagwarantować jej zgodność i wydajność.

Migracja

Aprowizacja usług Azure Container Registry i Azure Kubernetes Service

Użyj następujących poleceń, aby utworzyć rejestr kontenerów i klaster usługi Azure Kubernetes, którego jednostka usługi ma rolę czytelnika w rejestrze. Upewnij się, że wybrano odpowiedni model sieci dopasowany do wymagań w zakresie łączności sieciowej klastra.

az group create \
    --resource-group $resourceGroup \
    --location eastus
az acr create \
    --resource-group $resourceGroup \
    --name $acrName \
    --sku Standard
az aks create \
    --resource-group $resourceGroup \
    --name $aksName \
    --attach-acr $acrName \
    --network-plugin azure

Tworzenie obrazu platformy Docker dla serwera WildFly

Aby można było utworzyć plik Dockerfile, konieczne są:

  • Obsługiwany zestaw JDK.
  • Instalacja oprogramowania WildFly.
  • Opcje środowiska uruchomieniowego maszyny JVM.
  • Sposób przekazywania zmiennych środowiskowych (jeśli dotyczy).

Następnie można wykonać kroki opisane w poniższych sekcjach, jeśli mają zastosowanie. Jako punktu wyjścia dla pliku Dockerfile i aplikacji internetowej możesz użyć repozytorium WildFly Container Quickstart.

  1. Konfigurowanie usługi KeyVault FlexVolume
  2. Konfigurowanie źródeł danych
  3. Konfigurowanie zasobów JNDI
  4. Przegląd konfiguracji serwera WildFly

Konfigurowanie usługi KeyVault FlexVolume

Utwórz usługę Azure KeyVault i wypełnij wszystkie niezbędne wpisy tajne. Aby uzyskać więcej informacji, zobacz Szybki start: ustawianie i pobieranie wpisu tajnego z usługi Azure Key Vault przy użyciu interfejsu wiersza polecenia platformy Azure. Następnie skonfiguruj usługę KeyVault FlexVolume, aby udostępnić te wpisy tajne w zasobnikach.

Będzie trzeba też zaktualizować skrypt uruchamiania używany do ładowania początkowego serwera WildFly. Ten skrypt musi zaimportować certyfikaty do magazynu kluczy używanego przez serwer WildFly przed uruchomieniem serwera.

Konfigurowanie źródeł danych

Aby skonfigurować serwer WildFly do uzyskiwania dostępu do źródła danych, trzeba będzie dodać plik JAR sterownika JDBC do obrazu platformy Docker, a następnie wykonać odpowiednie polecenia interfejsu wiersza polecenia JBoss. Te polecenia muszą skonfigurować źródło danych podczas tworzenia obrazu platformy Docker.

Następujące kroki zawierają instrukcje dotyczące baz danych PostgreSQL, MySQL i SQL Server.

  1. Pobierz sterownik JDBC dla bazy danych PostgreSQL, MySQL lub SQL Server.

    Rozpakuj pobrane archiwum, aby pobrać plik jar sterownika.

  2. Utwórz plik o nazwie takiej jak module.xml i dodaj następujący znacznik. Zastąp element <module name> (łącznie z nawiasami ostrymi) wartością org.postgres dla bazy danych PostgreSQL, com.mysql dla MySQL lub com.microsoft dla SQL Server. Zastąp element <JDBC .jar file path> nazwą pliku jar z poprzedniego kroku, włącznie z pełną ścieżką do lokalizacji, w której zostanie umieszczony plik w obrazie platformy Docker, na przykład w /opt/database.

    <?xml version="1.0" ?>
<module xmlns="urn:jboss:module:1.1" name="<module name>">
    <resources>
       <resource-root path="<JDBC .jar file path>" />
    </resources>
    <dependencies>
        <module name="javax.api"/>
        <module name="javax.transaction.api"/>
    </dependencies>
</module>

  3. Utwórz plik o nazwie takiej jak datasource-commands.cli i dodaj następujący kod. Zastąp element <JDBC .jar file path> wartością użytą w poprzednim kroku. Zastąp element <module file path> nazwą pliku i ścieżką z poprzedniego kroku, na przykład /opt/database/module.xml.

    PostgreSQL

    batch
module add --name=org.postgres --resources=<JDBC .jar file path> --module-xml=<module file path>
/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=$DATABASE_CONNECTION_URL --user-name=$DATABASE_SERVER_ADMIN_FULL_NAME --password=$DATABASE_SERVER_ADMIN_PASSWORD --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
reload
run batch
shutdown

    MySQL

    batch
module add --name=com.mysql --resources=<JDBC .jar file path> --module-xml=<module file path>
/subsystem=datasources/jdbc-driver=mysql:add(driver-name=mysql,driver-module-name=com.mysql,driver-class-name=com.mysql.cj.jdbc.Driver)
data-source add --name=mysqlDS --jndi-name=java:jboss/datasources/mysqlDS --connection-url=$DATABASE_CONNECTION_URL --driver-name=mysql --user-name=$DATABASE_SERVER_ADMIN_FULL_NAME --password=$DATABASE_SERVER_ADMIN_PASSWORD --use-ccm=true --max-pool-size=5 --blocking-timeout-wait-millis=5000 --enabled=true --driver-class=com.mysql.cj.jdbc.Driver --jta=true --use-java-context=true --exception-sorter-class-name=com.mysql.cj.jdbc.integration.jboss.ExtendedMysqlExceptionSorter
reload
run batch
shutdown

    SQL Server

    batch
module add --name=com.microsoft --resources=<JDBC .jar file path> --module-xml=<module file path>
/subsystem=datasources/jdbc-driver=sqlserver:add(driver-name=sqlserver,driver-module-name=com.microsoft,driver-class-name=com.microsoft.sqlserver.jdbc.SQLServerDriver,driver-datasource-class-name=com.microsoft.sqlserver.jdbc.SQLServerDataSource)
data-source add --name=sqlDS --jndi-name=java:jboss/datasources/sqlDS --driver-name=sqlserver --connection-url=$DATABASE_CONNECTION_URL --validate-on-match=true --background-validation=false --valid-connection-checker-class-name=org.jboss.jca.adapters.jdbc.extensions.mssql.MSSQLValidConnectionChecker --exception-sorter-class-name=org.jboss.jca.adapters.jdbc.extensions.mssql.MSSQLExceptionSorter
reload
run batch
shutdown

  4. Zaktualizuj konfigurację źródła danych JTA dla swojej aplikacji:

    Otwórz plik src/main/resources/META-INF/persistence.xml dla swojej aplikacji i znajdź element <jta-data-source>. Zastąp jego zawartość w następujący sposób:

    PostgreSQL

    <jta-data-source>java:jboss/datasources/postgresDS</jta-data-source>

    MySQL

    <jta-data-source>java:jboss/datasources/mysqlDS</jta-data-source>

    SQL Server

    <jta-data-source>java:jboss/datasources/postgresDS</jta-data-source>

  5. Dodaj następujące informacje do pliku Dockerfile, aby źródło danych było tworzone podczas tworzenia obrazu platformy Docker

    RUN /bin/bash -c '<WILDFLY_INSTALL_PATH>/bin/standalone.sh --start-mode admin-only &' && \
sleep 30 && \
<WILDFLY_INSTALL_PATH>/bin/jboss-cli.sh -c --file=/opt/database/datasource-commands.cli && \
sleep 30

  6. Określ wartość DATABASE_CONNECTION_URL, która ma być używana, ponieważ wartości te różnią się dla każdego serwera bazy danych i są inne niż wartości w witrynie Azure Portal. Pokazane tu formaty adresów URL są wymagane do użycia przez serwer WildFly:

    PostgreSQL

    jdbc:postgresql://<database server name>:5432/<database name>?ssl=true

    MySQL

    jdbc:mysql://<database server name>:3306/<database name>?ssl=true\&useLegacyDatetimeCode=false\&serverTimezone=GMT

    SQL Server

    jdbc:sqlserver://<database server name>:1433;database=<database name>;user=<admin name>;password=<admin password>;encrypt=true;trustServerCertificate=false;hostNameInCertificate=*.database.windows.net;loginTimeout=30;

  7. Podczas tworzenia pliku YAML wdrożenia na późniejszym etapie należy przekazać zmienne środowiskowe DATABASE_CONNECTION_URL, DATABASE_SERVER_ADMIN_FULL_NAME i DATABASE_SERVER_ADMIN_PASSWORD z odpowiednimi wartościami.

Aby uzyskać więcej informacji na temat konfigurowania łączności bazy danych z serwerem WildFly, zobacz PostgreSQL, MySQL lub SQL Server.

Konfigurowanie zasobów JNDI

Aby skonfigurować każdy zasób JNDI, który musi być skonfigurowany na serwerze WildFly, zazwyczaj należy wykonać następujące kroki:

  1. Pobierz niezbędne pliki JAR i skopiuj je do obrazu platformy Docker.
  2. Utwórz plik module.xml serwera WildFly odwołujący się do tych plików JAR.
  3. Utwórz dowolną konfigurację wymaganą przez konkretny zasób JNDI.
  4. Utwórz skrypt interfejsu wiersza polecenia JBoss, który ma być używany podczas tworzenia przez platformę Docker w celu zarejestrowania zasobu JNDI.
  5. Dodaj wszystko do pliku Dockerfile.
  6. Przekaż odpowiednie zmienne środowiskowe w pliku YAML wdrożenia.

W poniższym przykładzie przedstawiono kroki wymagane do utworzenia zasobu JNDI na potrzeby łączności usługi JMS z usługą Azure Service Bus.

  1. Pobierz dostawcę Apache Qpid JMS

    Rozpakuj pobrane archiwum, aby uzyskać pliki jar.

  2. Utwórz plik o nazwie takiej jak module.xml i dodaj następujący kod w ścieżce /opt/servicebus. Upewnij się, że numery wersji plików JAR zgadzają się z nazwami plików JAR z poprzedniego kroku.

    <?xml version="1.0" ?>
<module xmlns="urn:jboss:module:1.1" name="org.jboss.genericjms.provider">
 <resources>
  <resource-root path="proton-j-0.31.0.jar"/>
  <resource-root path="qpid-jms-client-0.40.0.jar"/>
  <resource-root path="slf4j-log4j12-1.7.25.jar"/>
  <resource-root path="slf4j-api-1.7.25.jar"/>
  <resource-root path="log4j-1.2.17.jar"/>
  <resource-root path="netty-buffer-4.1.32.Final.jar" />
  <resource-root path="netty-codec-4.1.32.Final.jar" />
  <resource-root path="netty-codec-http-4.1.32.Final.jar" />
  <resource-root path="netty-common-4.1.32.Final.jar" />
  <resource-root path="netty-handler-4.1.32.Final.jar" />
  <resource-root path="netty-resolver-4.1.32.Final.jar" />
  <resource-root path="netty-transport-4.1.32.Final.jar" />
  <resource-root path="netty-transport-native-epoll-4.1.32.Final-linux-x86_64.jar" />
  <resource-root path="netty-transport-native-kqueue-4.1.32.Final-osx-x86_64.jar" />
  <resource-root path="netty-transport-native-unix-common-4.1.32.Final.jar" />
  <resource-root path="qpid-jms-discovery-0.40.0.jar" />
 </resources>
 <dependencies>
  <module name="javax.api"/>
  <module name="javax.jms.api"/>
 </dependencies>
</module>

  3. Utwórz plik jndi.properties w ścieżce /opt/servicebus.

    connectionfactory.${MDB_CONNECTION_FACTORY}=amqps://${DEFAULT_SBNAMESPACE}.servicebus.windows.net?amqp.idleTimeout=120000&jms.username=${SB_SAS_POLICY}&jms.password=${SB_SAS_KEY}
queue.${MDB_QUEUE}=${SB_QUEUE}
topic.${MDB_TOPIC}=${SB_TOPIC}

  4. Utwórz plik o nazwie takiej jak servicebus-commands.cli i dodaj następujący kod.

    batch
/subsystem=ee:write-attribute(name=annotation-property-replacement,value=true)
/system-property=property.mymdb.queue:add(value=myqueue)
/system-property=property.connection.factory:add(value=java:global/remoteJMS/SBF)
/subsystem=ee:list-add(name=global-modules, value={"name" => "org.jboss.genericjms.provider", "slot" =>"main"}
/subsystem=naming/binding="java:global/remoteJMS":add(binding-type=external-context,module=org.jboss.genericjms.provider,class=javax.naming.InitialContext,environment=[java.naming.factory.initial=org.apache.qpid.jms.jndi.JmsInitialContextFactory,org.jboss.as.naming.lookup.by.string=true,java.naming.provider.url=/opt/servicebus/jndi.properties])
/subsystem=resource-adapters/resource-adapter=generic-ra:add(module=org.jboss.genericjms,transaction-support=XATransaction)
/subsystem=resource-adapters/resource-adapter=generic-ra/connection-definitions=sbf-cd:add(class-name=org.jboss.resource.adapter.jms.JmsManagedConnectionFactory, jndi-name=java:/jms/${MDB_CONNECTION_FACTORY})
/subsystem=resource-adapters/resource-adapter=generic-ra/connection-definitions=sbf-cd/config-properties=ConnectionFactory:add(value=${MDB_CONNECTION_FACTORY})
/subsystem=resource-adapters/resource-adapter=generic-ra/connection-definitions=sbf-cd/config-properties=JndiParameters:add(value="java.naming.factory.initial=org.apache.qpid.jms.jndi.JmsInitialContextFactory;java.naming.provider.url=/opt/servicebus/jndi.properties")
/subsystem=resource-adapters/resource-adapter=generic-ra/connection-definitions=sbf-cd:write-attribute(name=security-application,value=true)
/subsystem=ejb3:write-attribute(name=default-resource-adapter-name, value=generic-ra)
run-batch
reload
shutdown

  5. Dodaj następujące elementy do pliku Dockerfile, aby zasób JNDI został utworzony podczas tworzenia obrazu platformy Docker

    RUN /bin/bash -c '<WILDFLY_INSTALL_PATH>/bin/standalone.sh --start-mode admin-only &' && \
sleep 30 && \
<WILDFLY_INSTALL_PATH>/bin/jboss-cli.sh -c --file=/opt/servicebus/servicebus-commands.cli && \
sleep 30

  6. Podczas tworzenia pliku YAML wdrożenia na późniejszym etapie będzie trzeba przekazać zmienne środowiskowe MDB_CONNECTION_FACTORY, DEFAULT_SBNAMESPACE, SB_SAS_POLICY, SB_SAS_KEY, MDB_QUEUE, SB_QUEUE, MDB_TOPIC i SB_TOPIC z odpowiednimi wartościami.

Przegląd konfiguracji serwera WildFly

Zapoznaj się z przewodnikiem administratora serwera WildFly w celu uzyskania informacji o wszelkich dodatkowych krokach poprzedzających migrację, które nie zostały omówione we wcześniejszych wskazówkach.

Tworzenie obrazu platformy Docker i wypychanie go do usługi Azure Container Registry

Po utworzeniu pliku Dockerfile trzeba będzie utworzyć obraz platformy Docker i opublikować go w usłudze Azure Container Registry.

Jeśli zostało użyte nasze repozytorium GitHub WildFly Container Quickstart, proces tworzenia i wypychania obrazu do usługi Azure Container Registry będzie odpowiednikiem wywołania następujących trzech poleceń.

W tych przykładach zmienna środowiskowa MY_ACR przechowuje nazwę rejestru kontenerów platformy Azure, a zmienna MY_APP_NAME przechowuje nazwę aplikacji internetowej, która ma być używana w usłudze Azure Container Registry.

Tworzenie pliku WAR:

mvn package

Logowanie się do usługi Azure Container Registry:

az acr login --name ${MY_ACR}

Tworzenie i wypychanie obrazu:

az acr build --image ${MY_ACR}.azurecr.io/${MY_APP_NAME} --file src/main/docker/Dockerfile .

Alternatywnie możesz użyć interfejsu wiersza polecenia platformy Docker, aby najpierw utworzyć i przetestować obraz lokalnie, jak pokazano w poniższych poleceniach. Takie podejście może uprościć testowanie i udoskonalanie obrazu przed początkowym wdrożeniem w usłudze ACR. Jednak wymaga to zainstalowania interfejsu wiersza polecenia platformy Docker i upewnienia się, że jest uruchomiony demon platformy Docker.

Tworzenie obrazu:

docker build -t ${MY_ACR}.azurecr.io/${MY_APP_NAME}

Uruchamianie obrazu lokalnie:

docker run -it -p 8080:8080 ${MY_ACR}.azurecr.io/${MY_APP_NAME}

Teraz możesz uzyskać dostęp do swojej aplikacji pod adresem http://localhost:8080.

Logowanie się do usługi Azure Container Registry:

az acr login --name ${MY_ACR}

Wypychanie obrazu do usługi Azure Container Registry:

docker push ${MY_ACR}.azurecr.io/${MY_APP_NAME}

Aby uzyskać bardziej szczegółowe informacje na temat tworzenia i przechowywania obrazów kontenerów na platformie Azure, zobacz w witrynie Learn moduł Tworzenie i przechowywanie obrazów kontenerów za pomocą usługi Azure Container Registry.

Aprowizacja publicznego adresu IP

Jeśli aplikacja ma być dostępna spoza sieci wewnętrznej lub wirtualnej, będziesz potrzebować publicznego statycznego adresu IP. Ten adres IP należy zaaprowizować w grupie zasobów węzła klastra, jak pokazano w następującym przykładzie:

export nodeResourceGroup=$(az aks show \
    --resource-group $resourceGroup \
    --name $aksName \
    --query 'nodeResourceGroup' \
    --output tsv)
export publicIp=$(az network public-ip create \
    --resource-group $nodeResourceGroup \
    --name applicationIp \
    --sku Standard \
    --allocation-method Static \
    --query 'publicIp.ipAddress' \
    --output tsv)
echo "Your public IP address is ${publicIp}."

Wdrażanie w usłudze AKS

Utwórz i zastosuj pliki YAML platformy Kubernetes. Aby uzyskać więcej informacji, zobacz Szybki start: wdrażanie klastra usługi Azure Kubernetes Service przy użyciu interfejsu wiersza polecenia platformy Azure. Jeśli tworzysz zewnętrzny moduł równoważenia obciążenia (dla aplikacji lub kontrolera ruchu przychodzącego), upewnij się, że adres IP aprowizowany w poprzedniej sekcji zostanie podany jako LoadBalancerIP.

Uwzględnij uzewnętrzniane parametry jako zmienne środowiskowe. Aby uzyskać więcej informacji, zobacz Definiowanie zmiennych środowiskowych dla kontenera. Nie dołączaj wpisów tajnych (takich jak hasła, klucze interfejsu API i parametry połączenia JDBC). Są one omówione w następującej sekcji.

Należy pamiętać o uwzględnieniu ustawień pamięci i procesora podczas tworzenia pliku YAML wdrożenia, aby kontenery miały właściwe rozmiary.

Konfigurowanie magazynu trwałego

Jeśli aplikacja wymaga magazynu trwałego, należy skonfigurować co najmniej jeden wolumin trwały.

Migrowanie zaplanowanych zadań

Aby wykonywać zaplanowane zadania w klastrze usługi AKS, definiuj zadania Kubernetes CronJob wedle potrzeby. Aby uzyskać więcej informacji, zobacz Uruchamiania zautomatyzowanych zadań przy użyciu obiektów CronJob.

Po migracji

Po przeprowadzeniu migracji aplikacji do usługi Azure Kubernetes Service należy sprawdzić, czy działa ona zgodnie z oczekiwaniami. Po wykonaniu tej czynności zapoznaj się z poniższymi zaleceniami, aby aplikacja bardziej natywna dla chmury.

Zalecenia