Memigrasikan aplikasi JBoss EAP ke WildFly di Azure Kubernetes Service.
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.
Pramigrasi
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 node Anda, jumlah memori yang akan digunakan oleh kontainer, dan berapa banyak berbagi CPU yang akan dibutuhkan kontainer.
Mengubah ukuran kumpulan simpul di AKS dapat dilakukan. 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 BOSS-web.xml dalam perang 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, lihat 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 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.
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.
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.
Tentukan apakah aplikasi Anda menggunakan API spesifik 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.
Menentukan 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
.
Menentukan 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 memahami bagaimana JAAS 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 Resource Adapter
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 dipaketkan sebagai file TELINGA, pastikan memeriksa file aplikasi.xml dan rekam konfigurasinya.
Catatan
Jika Anda ingin dapat menyesuaikan masing-masing aplikasi web Anda secara terpisah untuk penggunaan sumber daya AKS yang lebih baik, Anda harus membongkar TELINGA ke 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 -g $resourceGroup -l eastus
az acr create -g $resourceGroup -n $acrName --sku Standard
az aks create -g $resourceGroup -n $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.
- Mengonfigurasikan KeyVault FlexVolume
- Menyiapkan sumber data
- Menyiapkan sumber daya JNDI
- Meninjau konfigurasi WildFly
Mengonfigurasikan KeyVault FlexVolume
Buat Azure KeyVault dan masukkan 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.
Unduh driver JDBC untuk PostgreSQL, MySQL, atau SQL Server.
Bongkar arsip yang diunduh untuk mendapatkan file .jar driver.
Buat file dengan nama seperti
module.xml
dan tambahkan markup berikut. Ganti tempat penampung<module name>
(termasuk kurung siku) denganorg.postgres
untuk PostgreSQL,com.mysql
untuk MySQL, ataucom.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>
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
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>
Tambahkan elemen berikut ini ke
Dockerfile
sehingga sumber data dibuat saat membangun citra Docker AndaRUN /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
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;
Saat membuat YAML penyebaran pada tahap selanjutnya, Anda harus meneruskan variabel lingkungan,
DATABASE_CONNECTION_URL
,DATABASE_SERVER_ADMIN_FULL_NAME
danDATABASE_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:
- Unduh file JAR yang diperlukan dan salin ke dalam citra Docker.
- Buat file module.xml WildFly yang mereferensikan file JAR tersebut.
- Buat konfigurasi apa pun yang diperlukan oleh sumber daya JNDI tertentu.
- Buat skrip JBoss CLI yang akan digunakan selama pembangunan Docker untuk mendaftarkan sumber daya JNDI.
- Tambahkan semuanya ke Dockerfile.
- 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.
Unduh penyedia JMS Apache Qpid
Bongkar arsip yang diunduh untuk mendapatkan file .jar.
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>
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}
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
Tambahkan elemen berikut ini ke
Dockerfile
Anda, sehingga sumber daya JNDI dibuat saat membangun citra Docker AndaRUN /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
Saat membuat YAML penyebaran pada tahap selanjutnya, Anda harus meneruskan variabel lingkungan,
MDB_CONNECTION_FACTORY
,DEFAULT_SBNAMESPACE
danSB_SAS_POLICY
,SB_SAS_KEY
,MDB_QUEUE
,SB_QUEUE
,MDB_TOPIC
, danSB_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 citra Docker dan menerbitkannya ke Azure Container Registry 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 Azure Container Registry:
az acr login -n ${MY_ACR}
Membangun dan mendorong citra:
az acr build -t ${MY_ACR}.azurecr.io/${MY_APP_NAME} -f src/main/docker/Dockerfile .
Atau, Anda dapat menggunakan Docker CLI untuk terlebih dahulu membangun dan menguji citra secara lokal, seperti yang ditunjukkan dalam perintah berikut. Pendekatan ini dapat menyederhanakan pengujian dan penyempurnaan citra 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}
Menjalankan citra 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 Azure Container Registry:
az acr login -n ${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:
nodeResourceGroup=$(az aks show -g $resourceGroup -n $aksName --query 'nodeResourceGroup' -o tsv)
publicIp=$(az network public-ip create -g $nodeResourceGroup -n applicationIp --sku Standard --allocation-method Static --query 'publicIp.ipAddress' -o 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 yang tidak mudah berubah, 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
Setelah Anda memindahkan aplikasi Anda ke Layanan Azure Kunetes, Anda harus memverifikasi bahwa aplikasi ini bekerja sesuai harapan Anda. Setelah Anda melakukan itu, kami memiliki beberapa rekomendasi untuk Anda yang dapat membuat aplikasi Anda lebih cloud-native.
Rekomendasi
Pertimbangkan untuk menambahkan nama DNS ke alamat IP yang dialokasikan ke pengontrol ingress atau penyeimbang beban aplikasi Anda. Untuk informasi selengkapnya, lihat Membuat pengontrol ingress dengan alamat IP publik statik di AKS.
Pertimbangkan untuk menambahkan bagan HELM untuk aplikasi Anda. Bagan helm memungkinkan Anda untuk membuat parameter penyebaran aplikasi untuk digunakan dan dikustomisasi oleh serangkaian pelanggan yang lebih beragam.
Merancang dan menerapkan strategi DevOps. Untuk menjaga keandalan sekaligus meningkatkan kecepatan pengembangan Anda, pertimbangkan untuk mengotomatiskan penyebaran dan pengujian dengan Azure Pipelines. Untuk informasi selengkapnya, lihat Membangun dan menyebarkan ke AKS.
Aktifkan Azure Monitor untuk kluster. Untuk informasi selengkapnya, lihat Mengaktifkan pemantauan kluster AKS yang sudah disebarkan. Hal ini memungkinkan Azure monitor untuk mengumpulkan log kontainer, melacak pemanfaatan, dan sebagainya.
Pertimbangkan untuk mengekspos metrik khusus aplikasi melalui Prometheus. Prometheus adalah kerangka kerja metrik sumber terbuka yang diadopsi secara luas di komunitas Kubernetes. Anda dapat mengonfigurasi pengikisan Metrik Prometheus di Azure Monitor alih-alih menghosting server Prometheus Anda sendiri untuk mengaktifkan agregasi metrik dari aplikasi Anda dan respons otomatis atau eskalasi kondisi yang menyimpang. Untuk informasi selengkapnya, lihat Mengonfigurasi pengikisan metrik Prometheus dengan Azure Monitor untuk kontainer.
Merancang dan menerapkan strategi kelangsungan bisnis dan pemulihan bencana. Untuk aplikasi penting misi, pertimbangkan arsitektur penyebaran multi-wilayah. Untuk informasi selengkapnya, lihat Praktik terbaik untuk kelangsungan bisnis dan pemulihan bencana di AKS.
Tinjau kebijakan dukungan versi Kubernetes. Anda bertanggung jawab untuk terus memperbarui kluster AKS guna memastikan bahwa kluster AKS selalu menjalankan versi yang didukung. Untuk informasi selengkapnya, lihat Meningkatkan kluster AKS.
Mintalah semua anggota tim yang bertanggung jawab atas administrasi kluster dan pengembangan aplikasi meninjau praktik terbaik AKS yang relevan. Untuk informasi selengkapnya, lihat Praktik terbaik operator kluster dan pengembang untuk membangun dan mengelola aplikasi di AKS.
Pastikan file penyebaran Anda menentukan bagaimana pembaruan bergulir dilakukan. Untuk informasi selengkapnya, lihat Penyebaran Pembaruan Bergulir di dokumentasi Kubernetes.
Siapkan penskalaan otomatis untuk menangani beban waktu puncak. Untuk informasi selengkapnya, lihat Menskalakan kluster secara otomatis untuk memenuhi tuntutan aplikasi pada AKS.
Pertimbangkan untuk memantau ukuran cache kode dan menambahkan parameter JVM
-XX:InitialCodeCacheSize
dan-XX:ReservedCodeCacheSize
di Dockerfile untuk mengoptimalkan performa lebih jauh. Untuk informasi selengkapnya, lihat Penyetelan Codecache dalam dokumentasi Oracle.