Memigrasikan aplikasi JBoss EAP ke WildFly di Azure Kubernetes Service.

  • Artikel

Panduan ini menguraikan apa yang sebaiknya Anda ketahui saat ingin memigrasikan aplikasi JBoss EAP yang sudah ada untuk berjalan di WildFly dalam kontainer Azure Kubernetes Service.

Pra-migrasi

Untuk memastikan keberhasilan migrasi, sebelum memulai, selesaikan langkah-langkah penilaian dan inventaris yang dijelaskan di bagian berikut.

Kapasitas server inventaris

Dokumentasikan perangkat keras (memori, CPU, disk) dari server produksi saat ini dan jumlah permintaan rata-rata dan puncak, serta pemanfaatan sumber daya. Anda akan memerlukan informasi ini terlepas dari jalur migrasi yang Anda pilih. Ini berguna, misalnya, untuk membantu memandu pemilihan ukuran VM di kumpulan simpul Anda, jumlah memori yang akan digunakan oleh kontainer, dan berapa banyak CPU yang berbagi kebutuhan kontainer.

Anda dapat mengubah ukuran kumpulan simpul di AKS. Untuk mempelajari caranya, lihat Mengubah ukuran kumpulan simpul di Azure Kubernetes Service (AKS).

Inventaris semua rahasia

Periksa semua properti dan file konfigurasi di server produksi untuk rahasia dan kata sandi apa pun. Pastikan untuk memeriksa jboss-web.xml di file WAR Anda. File konfigurasi yang berisi kata sandi atau info masuk juga dapat ditemukan di dalam aplikasi Anda.

Pertimbangkan untuk menyimpan rahasia tersebut di Azure KeyVault. Untuk informasi selengkapnya, kunjungi konsep dasar Azure Key Vault.

Inventaris semua sertifikat

Dokumentasikan semua sertifikat yang digunakan untuk titik akhir SSL publik. Anda bisa melihat semua sertifikat di server produksi dengan menjalankan perintah berikut ini:

keytool -list -v -keystore <path to keystore>

Memvalidasi bahwa versi Java yang didukung berfungsi dengan benar

Menggunakan WildFly di Azure Kubernetes Service memerlukan versi Java tertentu, sehingga Anda harus mengonfirmasi bahwa aplikasi Anda berjalan dengan benar menggunakan versi yang didukung tersebut.

Catatan

Validasi ini sangat penting jika server Anda saat ini berjalan pada JDK yang tidak didukung (seperti Oracle JDK atau IBM OpenJ9).

Untuk mendapatkan versi Java Anda saat ini, masuk ke server produksi Anda dan jalankan perintah berikut:

java -version

Lihat Persyaratan untuk panduan mengenai versi apa yang harus digunakan untuk menjalankan WildFly.

Inventaris sumber daya JNDI

Inventarisasikan semua sumber daya JNDI. Beberapa, seperti broker pesan JMS, mungkin memerlukan migrasi atau konfigurasi ulang.

Menentukan apakah replikasi sesi digunakan

Jika aplikasi Anda bergantung pada replikasi sesi, Anda harus mengubah aplikasi untuk menghapus dependensi ini.

Di dalam aplikasi Anda

Periksa file WEB-INF/jboss-web.xml dan/atau WEB-INF/web.xml.

Mendokumentasikan sumber data

Jika aplikasi Anda menggunakan database apa pun, Anda perlu mengambil informasi berikut:

  • Apa nama sumber datanya?
  • Apa konfigurasi kumpulan koneksinya?
  • Di mana saya dapat menemukan file JAR driver JDBC?

Untuk informasi selengkapnya, lihat Tentang JBoss EAP Datasources dalam dokumentasi JBoss EAP.

Menentukan apakah dan bagaimana sistem berkas digunakan

Setiap penggunaan sistem file pada server aplikasi akan memerlukan konfigurasi ulang atau, dalam kasus yang jarang terjadi, perubahan arsitektur. Sistem file dapat digunakan oleh modul JBoss EAP atau dengan kode aplikasi Anda. Anda dapat mengidentifikasi beberapa atau semua skenario yang dijelaskan di bagian berikut.

Konten statis baca-saja

Jika aplikasi Anda saat ini menyajikan konten statis, Anda memerlukan lokasi alternatif untuk itu. Anda mungkin ingin mempertimbangkan untuk memindahkan konten statik ke Azure Blob Storage dan menambahkan Azure CDN untuk unduhan secepat kilat secara global. Untuk informasi selengkapnya, lihat Hosting situs web statis di Penyimpanan Azure dan Mulai Cepat: Mengintegrasikan akun Microsoft Azure Storage dengan Azure CDN. Anda juga dapat langsung menyebarkan konten statis ke aplikasi dalam paket Azure Spring Apps Enterprise. Untuk informasi selengkapnya, lihat Menyebarkan file statis web.

Konten statis yang diterbitkan secara dinamis

Jika aplikasi Anda memungkinkan konten statis yang diunggah/ diproduksi oleh aplikasi Anda tetapi tidak dapat diubah setelah pembuatannya, Anda dapat menggunakan Azure Blob Storage dan Azure CDN seperti yang dijelaskan di atas, dengan Azure Function untuk menangani unggahan dan refresh CDN. Kami telah menyediakan implementasi sampel untuk penggunaan Anda di Pengunggahan dan pramuat CDN konten statis dengan Azure Functions. Anda juga dapat langsung menyebarkan konten statis ke aplikasi dalam paket Azure Spring Apps Enterprise. Untuk informasi selengkapnya, lihat Menyebarkan file statis web.

Konten dinamis atau internal

Untuk file yang sering ditulis dan dibaca oleh aplikasi Anda (seperti file data sementara), atau file statis yang hanya terlihat oleh aplikasi Anda, Anda dapat memasang Azure Storage bersama sebagai volume persisten. Buat dan gunakan volume persisten secara dinamis dengan Azure Files di Azure Kubernetes Service.

Menentukan apakah aplikasi Anda bergantung pada pekerjaan terjadwal atau tidak

Pekerjaan terjadwal, seperti tugas Quartz Scheduler atau pekerjaan Unix cron, TIDAK boleh digunakan dengan Azure Kubernetes Service (AKS). Azure Kubernetes Service tidak akan mencegah Anda menyebarkan aplikasi yang berisi tugas terjadwal secara internal. Namun, apabila skala aplikasi Anda diperluas, pekerjaan terjadwal yang sama dapat berjalan lebih dari satu kali per periode yang dijadwalkan. Situasi ini dapat menyebabkan konsekuensi yang tidak diinginkan.

Untuk menjalankan pekerjaan terjadwal di kluster AKS Anda, tentukan Kubernetes CronJobs sesuai kebutuhan. Untuk informasi selengkapnya, lihat Menjalankan Tugas Otomatis dengan CronJob.

Menentukan apakah koneksi ke lokal diperlukan

Jika aplikasi Anda perlu mengakses salah satu layanan lokal Anda, Anda harus menyediakan salah satu layanan konektivitas Azure. Untuk informasi selengkapnya, lihat Memilih solusi untuk menyambungkan jaringan lokal ke Azure. Atau, Anda harus memfaktor ulang aplikasi untuk menggunakan API yang tersedia untuk umum yang diekspos sumber daya lokal Anda.

Menentukan apakah Antrean atau Topik Java Message Service (JMS) sedang digunakan

Jika aplikasi Anda menggunakan JMS Queues atau Topik, Anda harus memigrasikannya ke server JMS yang dihosting secara eksternal. Azure Service Bus dan Advanced Message Queuing Protocol (AMQP) dapat menjadi strategi migrasi yang bagus bagi mereka yang menggunakan JMS. Untuk informasi selengkapnya, lihat Menggunakan JMS dengan Azure Service Bus dan AMQP 1.0.

Jika penyimpanan persisten JMS telah dikonfigurasi, Anda harus menangkap konfigurasinya dan menerapkannya setelah migrasi.

Menentukan apakah aplikasi Anda menggunakan API khusus JBoss-EAP

Jika aplikasi Anda menggunakan API spesifik JBoss-EAP, Anda akan perlu melakukan refaktor pada aplikasi untuk menghapus dependensi tersebut.

Menentukan apakah aplikasi Anda menggunakan Entity Beans atau EJB 2.x-style CMP Beans

Jika aplikasi Anda menggunakan Entity Beans atau EJB 2.x style CMP beans, Anda harus merefaktor aplikasi untuk menghapus dependensi ini.

Menentukan apakah fitur Java EE Application Client sedang digunakan

Jika Anda memiliki aplikasi klien yang terhubung ke aplikasi (server) Anda menggunakan fitur Java EE Application Client, Anda harus merefaktor aplikasi klien serta aplikasi (server) Anda untuk menggunakan HTTP API.

Tentukan apakah aplikasi Anda berisi kode khusus OS

Jika aplikasi Anda berisi kode apa pun dengan dependensi pada OS host, Anda harus melakukan refaktor untuk menghapus dependensi tersebut. Misalnya, Anda mungkin perlu mengganti penggunaan / atau \ di jalur sistem file dengan File.Separator atau Paths.get.

Tentukan apakah timer EJB sedang digunakan

Jika aplikasi Anda menggunakan timer EJB, Anda harus memvalidasi bahwa kode timer EJB dapat dipicu oleh setiap instans WildFly secara independen. Validasi ini diperlukan karena, dalam skenario penyebaran Azure Kubernetes Service, setiap timer EJB akan dipicu pada instans WildFly masing-masing.

Menentukan apakah konektor JCA sedang digunakan

Jika aplikasi Anda menggunakan konektor JCA, validasi bahwa Anda dapat menggunakan konektor JCA di WildFly. Jika implementasi JCA telah dikaitkan dengan JBoss EAP, Anda harus melakukan refaktor pada aplikasi untuk menghapus dependensi tersebut. Jika Anda dapat menggunakan konektor JCA di WildFly, Anda harus menambahkan JAR ke jalur kelas server dan menempatkan file konfigurasi yang diperlukan di lokasi yang tepat di direktori server WildFly agar konektor dapat tersedia.

Menentukan apakah JAAS sedang digunakan

Jika aplikasi Anda menggunakan JAAS, Anda harus mengetahui bagaimana JAAS tersebut dikonfigurasi. Jika menggunakan database, Anda dapat mengonversinya menjadi domain JAAS di WildFly. Jika aplikasi Anda merupakan implementasi kustom, Anda harus memvalidasi bahwa aplikasi dapat digunakan di WildFly.

Menentukan apakah aplikasi Anda menggunakan Adaptor Sumber Daya

Jika aplikasi Anda memerlukan Resource Adapter (RA), aplikasi tersebut harus kompatibel dengan WildFly. Tentukan apakah RA berfungsi dengan baik pada instans WildFly yang berdiri sendiri dengan menyebarkannya ke server dan mengonfigurasinya dengan benar. Jika RA berfungsi dengan baik, Anda harus menambahkan JAR ke classpath server dari citra Docker dan menempatkan file konfigurasi yang diperlukan di lokasi yang benar pada direktori server WildFly agar tersedia.

Menentukan apakah aplikasi Anda terdiri dari beberapa WAR

Jika aplikasi Anda terdiri dari beberapa WAR, Anda harus memperlakukan masing-masing WAR tersebut sebagai aplikasi terpisah dan melalui panduan ini untuk masing-masing WAR.

Menentukan apakah aplikasi Anda dikemas sebagai EAR

Jika aplikasi Anda dikemas sebagai file EAR, pastikan untuk memeriksa file application.xml dan mengambil konfigurasi.

Catatan

Jika Anda ingin dapat menskalakan setiap aplikasi web secara independen untuk penggunaan sumber daya AKS yang lebih baik, Anda harus memecah EAR menjadi aplikasi web terpisah.

Identifikasi semua proses dan daemon luar yang berjalan di server produksi

Jika Anda memiliki proses yang berjalan di luar server aplikasi, seperti memantau daemon, Anda harus menghilangkannya atau memigrasikannya di tempat lain.

Melakukan pengujian di tempat

Sebelum membuat citra kontainer, migrasikan aplikasi Anda ke versi JDK dan WildFly yang ingin digunakan di AKS. Uji aplikasi secara menyeluruh untuk memastikan kompatibilitas dan performa.

Migration

Memprovisikan Azure Container Registry dan Azure Kubernetes Service

Gunakan perintah berikut untuk membuat registri kontainer dan kluster Azure Kubernetes dengan Perwakilan Layanan yang memiliki peran Pembaca di registri. Pastikan untuk memilih model jaringan yang sesuai untuk persyaratan jaringan kluster Anda.

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

Membuat citra Docker untuk WildFly

Untuk membuat Dockerfile, Anda memerlukan prasyarat berikut:

  • JDK yang didukung.
  • Penginstalan WildFly.
  • Opsi runtime JVM Anda.
  • Cara untuk meneruskan variabel lingkungan (jika ada).

Anda kemudian dapat melakukan langkah-langkah yang dijelaskan di bagian berikut, jika berlaku. Anda dapat menggunakan repositori WildFly Container Quickstart sebagai titik awal untuk Dockerfile dan aplikasi web Anda.

  1. Mengonfigurasikan KeyVault FlexVolume
  2. Menyiapkan sumber data
  3. Menyiapkan sumber daya JNDI
  4. Meninjau konfigurasi WildFly

Mengonfigurasikan KeyVault FlexVolume

Buat Azure KeyVault dan isi semua rahasia yang diperlukan. Untuk informasi selengkapnya, lihat Mulai Cepat: Mengatur dan mengambil rahasia dari Azure Key Vault menggunakan Azure CLI. Kemudian, konfigurasikan KeyVault FlexVolume untuk membuat rahasia tersebut dapat diakses oleh pod.

Anda juga perlu memperbarui skrip penyalaan yang digunakan untuk WildFly bootstrap. Skrip ini harus mengimpor sertifikat ke penyimpanan kunci yang digunakan oleh WildFly sebelum memulai server.

Menyiapkan sumber data

Untuk mengonfigurasi WildFly guna mengakses sumber data, Anda harus menambahkan JAR driver JDBC ke citra Docker, kemudian menjalankan perintah CLI JBoss yang sesuai. Perintah ini harus menyiapkan sumber data saat membangun citra Docker Anda.

Langkah-langkah berikut memberikan instruksi untuk PostgreSQL, MySQL dan SQL Server.

  1. Unduh driver JDBC untuk PostgreSQL, MySQL, atau SQL Server.

    Bongkar arsip yang diunduh untuk mendapatkan file .jar driver.

  2. Buat file dengan nama seperti module.xml dan tambahkan markup berikut. Ganti tempat penampung <module name> (termasuk kurung siku) dengan org.postgres untuk PostgreSQL, com.mysql untuk MySQL, atau com.microsoft untuk SQL Server. Ganti <JDBC .jar file path> dengan nama file .jar dari langkah sebelumnya, termasuk jalur lengkap ke lokasi tempat Anda akan menempatkan file di citra Docker, misalnya di /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. Buat file dengan nama seperti datasource-commands.cli dan tambahkan kode berikut. Ganti <JDBC .jar file path> dengan nilai yang sama dengan yang Anda gunakan di langkah sebelumnya. Ganti <module file path> dengan nama file dan jalur dari langkah sebelumnya, misalnya /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. Perbarui konfigurasi datasource JTA untuk aplikasi Anda:

    Buka file src/main/resources/META-INF/persistence.xml untuk aplikasi Anda dan temukan elemen <jta-data-source>. Ganti isinya seperti yang ditunjukkan di sini:

    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. Tambahkan elemen berikut ini ke Dockerfile sehingga sumber data dibuat saat membangun citra Docker Anda

    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. Tentukan DATABASE_CONNECTION_URL untuk digunakan karena mereka berbeda untuk setiap server database, dan berbeda dengan nilai di portal Microsoft Azure. Format URL yang ditampilkan di sini diperlukan untuk digunakan oleh 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. Saat membuat YAML penyebaran pada tahap selanjutnya, Anda harus meneruskan variabel lingkungan, DATABASE_CONNECTION_URL, DATABASE_SERVER_ADMIN_FULL_NAME dan DATABASE_SERVER_ADMIN_PASSWORD berikut dengan nilai yang sesuai.

Untuk info selengkapnya mengenai konfigurasi konektivitas database dengan WildFly, lihat PostgreSQL, MySQL, atau SQL Server.

Menyiapkan sumber daya JNDI

Untuk menyiapkan setiap sumber daya JNDI yang perlu Anda konfigurasikan di WildFly, Anda umumnya akan menggunakan langkah-langkah berikut:

  1. Unduh file JAR yang diperlukan dan salin ke dalam citra Docker.
  2. Buat file module.xml WildFly yang mereferensikan file JAR tersebut.
  3. Buat konfigurasi apa pun yang diperlukan oleh sumber daya JNDI tertentu.
  4. Buat skrip JBoss CLI yang akan digunakan selama pembangunan Docker untuk mendaftarkan sumber daya JNDI.
  5. Tambahkan semuanya ke Dockerfile.
  6. Teruskan variabel lingkungan yang sesuai dalam YAML penyebaran Anda.

Contoh di bawah ini menunjukkan langkah-langkah yang diperlukan untuk membuat sumber daya JNDI untuk konektivitas JMS ke Azure Service Bus.

  1. Unduh penyedia JMS Apache Qpid

    Bongkar arsip yang diunduh untuk mendapatkan file .jar.

  2. Buat file dengan nama seperti module.xml dan tambahkan markup berikut di /opt/servicebus. Pastikan nomor versi file JAR selaras dengan nama file JAR dari langkah sebelumnya.

    <?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. Buat file jndi.properties di /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. Buat file dengan nama seperti servicebus-commands.cli dan tambahkan kode berikut.

    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. Tambahkan elemen berikut ini ke Dockerfile Anda, sehingga sumber daya JNDI dibuat saat membangun citra Docker Anda

    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. Saat membuat YAML penyebaran pada tahap berikutnya, Anda harus meneruskan variabel lingkungan, MDB_CONNECTION_FACTORY, DEFAULT_SBNAMESPACE dan SB_SAS_POLICY, SB_SAS_KEY, MDB_QUEUE, SB_QUEUE, MDB_TOPIC, dan SB_TOPIC berikut dengan nilai yang sesuai.

Meninjau konfigurasi WildFly

Tinjau Panduan Admin WildFly untuk mencakup langkah-langkah pramigrasi tambahan yang tidak tercakup oleh panduan sebelumnya.

Membangun dan mendorong citra Docker ke Azure Container Registry

Setelah membuat Dockerfile, Anda harus membangun gambar Docker dan menerbitkannya ke registri kontainer Azure Anda.

Jika menggunakan Repositori GitHub Mulai Cepat Kontainer WildFly kami, proses membangun dan mendorong citra Anda ke Azure Container Registry akan setara dengan memanggil tiga perintah berikut.

Dalam contoh ini, variabel lingkungan MY_ACR menyimpan nama Azure Container Registry Anda dan variabel MY_APP_NAME menyimpan nama aplikasi web yang ingin digunakan di Azure Container Registry Anda.

Membangun file WAR:

mvn package

Masuk ke registri kontainer Azure Anda:

az acr login --name ${MY_ACR}

Membangun dan mendorong citra:

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

Atau, Anda dapat menggunakan Docker CLI untuk terlebih dulu membangun dan menguji citra secara lokal, seperti yang ditunjukkan dalam perintah berikut. Pendekatan ini dapat menyederhanakan pengujian dan penyempurnaan gambar sebelum penyebaran awal ke ACR. Namun, pendekatan ini mengharuskan Anda untuk menginstal Docker CLI dan memastikan daemon Docker berjalan.

Membangun citra:

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

Jalankan gambar secara lokal:

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

Anda sekarang dapat mengakses aplikasi Anda di http://localhost:8080.

Masuk ke registri kontainer Azure Anda:

az acr login --name ${MY_ACR}

Dorong citra tersebut ke Azure Container Registry Anda:

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

Untuk informasi lebih mendalam mengenai membangun dan menyimpan citra kontainer di Azure, lihat modul Microsoft Learn Membangun dan menyimpan citra kontainer dengan Azure Container Registry.

Memprovisikan alamat IP publik

Jika aplikasi Anda dapat diakses dari luar jaringan internal atau virtual, Anda memerlukan alamat IP statik publik. Anda harus memprovisikan alamat IP ini di dalam grup sumber daya node kluster, seperti yang ditunjukkan pada contoh berikut:

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

Sebarkan ke AKS

Buat dan terapkan file YAML Kubernetes Anda. Untuk informasi selengkapnya, lihat Mulai Cepat: Menyebarkan kluster Azure Kubernetes Service menggunakan Azure CLI. Jika Anda membuat penyeimbang beban eksternal (baik untuk aplikasi Anda atau untuk pengontrol ingress), pastikan untuk memberikan alamat IP yang diprovisikan di bagian sebelumnya sebagai LoadBalancerIP.

Sertakan parameter eksternal sebagai variabel lingkungan. Untuk informasi selengkapnya, lihat Menentukan Variabel Lingkungan untuk Kontainer. Jangan sertakan rahasia (seperti kata sandi, kunci API, dan string koneksi JDBC). Hal ini dibahas dalam bagian berikut.

Pastikan untuk menyertakan pengaturan memori dan CPU saat membuat YAML penyebaran Anda sehingga kontainer Anda memiliki ukuran yang tepat.

Mengonfigurasi penyimpanan persisten

Jika aplikasi Anda memerlukan penyimpanan non-volatile, konfigurasikan satu atau beberapa Volume Persisten.

Memigrasikan pekerjaan terjadwal

Untuk menjalankan pekerjaan terjadwal di kluster AKS Anda, tentukan Kubernetes CronJobs sesuai kebutuhan. Untuk informasi selengkapnya, lihat Menjalankan Tugas Otomatis dengan CronJob.

Pasca-migrasi

Sekarang setelah memigrasi aplikasi ke Azure Kubernetes Service, Anda harus memveriifkasi bahwa aplikasi tersebut berfungsi sesuai harapan. Setelah Anda melakukannya, kami memiliki beberapa rekomendasi untuk Anda yang dapat membuat aplikasi lebih cloud-native.

Rekomendasi