Migrowanie aplikacji serwera WildFly do serwera WildFly w usłudze Azure Kubernetes Service
W tym przewodniku opisano, na co należy zwrócić uwagę, aby przeprowadzić migrację istniejącej aplikacji serwera WildFly w celu uruchomienia jej na serwerze WildFly w kontenerze usługi Azure Kubernetes Service.
Uwaga
Ten artykuł zawiera tylko ogólne porady. Ani firma Microsoft, ani Red Hat nie oferują pomocy technicznej dla środowiska WildFly, ale społeczność WildFly może zaoferować pomoc. Aby uzyskać informacje na temat ofert obsługiwanych wspólnie przez firmy Red Hat i Microsoft, zobacz Red Hat JBoss EAP na platformie Azure.
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ł. Sprawdź plik jboss-web.xml w swoich plikach WAR. Wewnątrz aplikacji możesz również znaleźć pliki konfiguracji zawierające hasła lub poświadczenia.
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.
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.
Określenie, czy jest używana replikacja sesji
Jeśli Twoja aplikacja korzysta z replikacji sesji, należy zmienić aplikację, aby usunąć tę zależność.
W aplikacji
Sprawdź plik WEB-INF/jboss-web.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ę DataSource Configuration (Konfiguracja źródła danych) w dokumentacji serwera WildFly.
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 WildFly 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 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 WildFly, 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 konfigurację pliku application.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.
- Konfigurowanie usługi KeyVault FlexVolume
- Konfigurowanie źródeł danych
- Konfigurowanie zasobów JNDI
- 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.
Pobierz sterownik JDBC dla bazy danych PostgreSQL, MySQL lub SQL Server.
Rozpakuj pobrane archiwum, aby pobrać plik jar sterownika.
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 lubcom.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>
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
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>
Dodaj następujące informacje do pliku
Dockerfile
, aby źródło danych było tworzone podczas tworzenia obrazu platformy DockerRUN /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
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;
Podczas tworzenia pliku YAML wdrożenia na późniejszym etapie należy przekazać zmienne środowiskowe
DATABASE_CONNECTION_URL
,DATABASE_SERVER_ADMIN_FULL_NAME
iDATABASE_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:
- Pobierz niezbędne pliki JAR i skopiuj je do obrazu platformy Docker.
- Utwórz plik module.xml serwera WildFly odwołujący się do tych plików JAR.
- Utwórz dowolną konfigurację wymaganą przez konkretny zasób JNDI.
- Utwórz skrypt interfejsu wiersza polecenia JBoss, który ma być używany podczas tworzenia przez platformę Docker w celu zarejestrowania zasobu JNDI.
- Dodaj wszystko do pliku Dockerfile.
- 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.
Pobierz dostawcę Apache Qpid JMS
Rozpakuj pobrane archiwum, aby uzyskać pliki jar.
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>
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}
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
Dodaj następujące elementy do pliku
Dockerfile
, aby zasób JNDI został utworzony podczas tworzenia obrazu platformy DockerRUN /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
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
iSB_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
Rozważ dodanie nazwy DNS do adresu IP przydzielonego do kontrolera ruchu przychodzącego lub modułu równoważenia obciążenia aplikacji. Aby uzyskać więcej informacji, zobacz Tworzenie kontrolera ruchu przychodzącego ze statycznym publicznym adresem IP w usłudze AKS.
Rozważ dodanie do swojej aplikacji elementu chart programu HELM. Wykres HELM umożliwia parametryzację wdrożenia aplikacji w celu używania i dostosowywania aplikacji przez bardziej różnorodnych klientów.
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 Tworzenie i wdrażanie w usłudze AKS.
Włącz monitorowanie platformy Azure dla klastra. Aby uzyskać więcej informacji, zobacz Włączanie monitorowania już wdrożonego klastra usługi AKS. Dzięki temu monitor platformy Azure może zbierać dzienniki kontenerów, śledzić użycie i tak dalej.
Rozważ ujawnienie metryk właściwych dla aplikacji za pośrednictwem systemu Prometheus. Prometheus to struktura metryk typu open source, szeroko przyjęta w społeczności Kubernetes. Wycinanie metryk systemu Prometheus można skonfigurować w usłudze Azure Monitor zamiast hostować własny serwer Prometheus w celu włączenia agregacji metryk z aplikacji i umożliwienia automatycznego reagowania na nietypowe warunki lub ich eskalowania. Aby uzyskać więcej informacji, zobacz Konfigurowanie wycinania metryk systemu Prometheus z usługą Azure Monitor dla kontenerów.
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 Najlepsze rozwiązania dotyczące zapewnienia ciągłości działania firmy i odzyskiwania po awarii w usłudze AKS.
Zapoznaj się z zasadami obsługi wersji platformy Kubernetes. To Ty ponosisz odpowiedzialność za aktualizowanie klastra usługi AKS, aby mieć pewność, że zawsze korzysta z obsługiwanej wersji. Aby uzyskać więcej informacji, zobacz Uaktualnianie klastra usługi AKS.
Wszyscy członkowie zespołu odpowiedzialni za administrowanie klastrami i programowanie aplikacji powinni zapoznać się z odpowiednimi najlepszymi rozwiązaniami dotyczącymi usługi AKS. Aby uzyskać więcej informacji, zobacz Najlepsze rozwiązania dla deweloperów i operatorów klastra w zakresie tworzenia aplikacji i zarządzania nimi w usłudze AKS.
Upewnij się, że plik wdrożenia określa sposób przeprowadzania aktualizacji stopniowych. Aby uzyskać więcej informacji, zobacz Wdrażanie aktualizacji stopniowej w dokumentacji platformy Kubernetes.
Skonfiguruj automatyczne skalowanie, aby radzić sobie z obciążeniem w czasie szczytu. Aby uzyskać więcej informacji, zobacz Automatyczne skalowanie klastra odpowiednio do wymagań aplikacji w usłudze AKS.
Rozważ monitorowanie rozmiaru pamięci podręcznej kodu oraz dodanie parametrów maszyny JVM
-XX:InitialCodeCacheSize
i-XX:ReservedCodeCacheSize
w pliku Dockerfile w celu zoptymalizowania wydajności. Aby uzyskać więcej informacji, zobacz Dostrajanie pamięci podręcznej kodu w dokumentacji programu Oracle.
Opinia
https://aka.ms/ContentUserFeedback.
Dostępne już wkrótce: W 2024 r. będziemy stopniowo wycofywać zgłoszenia z serwisu GitHub jako mechanizm przesyłania opinii na temat zawartości i zastępować go nowym systemem opinii. Aby uzyskać więcej informacji, sprawdź:Prześlij i wyświetl opinię dla