Migrowanie aplikacji serwera WebSphere do serwera WildFly w usłudze Azure Kubernetes Service

  • Artykuł

W tym przewodniku opisano, na co należy zwrócić uwagę, aby przeprowadzić migrację istniejącej aplikacji serwera WebSphere w celu uruchomienia jej na serwerze 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.

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

Sprawdź wszystkie pliki właściwości i konfiguracji na serwerach produkcyjnych kątem jakichkolwiek 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.

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

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.

Utworzenie spisu zasobów JNDI

Utwórz spis wszystkich zasobów JNDI. Niektóre elementy, takie jak broker 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.

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, zobacz sekcję Configuring database connectivity (Konfigurowanie łączności z bazą danych) w dokumentacji serwera WebSphere.

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 serwera WebSphere lub kod aplikacji. Można 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 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ś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 Twoja aplikacja używa interfejsów API specyficznych dla serwera WebSphere, należy wykonać jej refaktoryzację w celu usunięcia tych zależności. Na przykład jeśli użyto klasy wymienionej w specyfikacji interfejsu API serwera IBM WebSphere Application Server, Release 9.0, to w aplikacji został zastosowany interfejs API specyficzny dla serwera WebSphere.

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

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.

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 konfiguracje plików application.xml i application-bnd.xml.

Uwaga

Aby mieć możliwość niezależnego skalowania poszczególnych aplikacji internetowych w celu lepszego wykorzystania zasobów usługi AKS, należy podzielić plik 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 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 tych czynności skorzystaj z naszych zaleceń, które mogą sprawić, że aplikacja będzie bardziej natywna dla chmury.

Zalecenia