Memigrasikan aplikasi WebSphere ke WildFly di Azure Kubernetes Service
Artikel
Panduan ini menjelaskan apa yang harus Anda ketahui ketika Anda ingin memigrasikan aplikasi WebSphere yang ada untuk dijalankan 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.
Periksa semua properti dan file konfigurasi di server produksi untuk rahasia dan kata sandi apa pun. Pastikan untuk memeriksa ibm-web-bnd.xml di WAR Anda. File konfigurasi yang berisi kata sandi atau info masuk juga dapat ditemukan di dalam aplikasi Anda.
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 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 dengan modul WebSphere atau dengan kode aplikasi Anda. Anda dapat mengidentifikasi beberapa atau semua skenario yang dijelaskan di bagian berikut.
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. Untuk informasi selengkapnya, lihat Membuat dan menggunakan volume dengan Azure Files di Azure Kubernetes Service (AKS).
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 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 Java Message Service 1.1 dengan Standar Azure Bus Layanan dan AMQP 1.0.
Jika penyimpanan persisten JMS telah dikonfigurasi, Anda harus menangkap konfigurasinya dan menerapkannya setelah migrasi.
Tentukan apakah aplikasi Anda menggunakan API khusus WebSphere
Jika aplikasi Anda menggunakan API khusus WebSphere, Anda harus merefaktor untuk menghapus dependensi tersebut. Misalnya, jika Anda telah menggunakan kelas yang disebutkan di IBM WebSphere Application Server, Spesifikasi API Rilis 9.0, Anda telah menggunakan API khusus WebSphere di aplikasi Anda.
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, maka Anda perlu merefaktornya untuk menghapus dependensi tersebut. Misalnya, Anda mungkin perlu mengganti penggunaan / atau \ di jalur sistem file dengan File.Separator atau Paths.get jika aplikasi Anda berjalan di Windows.
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, Anda harus memvalidasi bahwa konektor JCA dapat digunakan di WildFly. Jika implementasi JCA terikat dengan WebSphere, Anda harus merefaktor aplikasi Anda untuk menghapus dependensi tersebut. Jika dapat digunakan, maka Anda harus menambahkan JAR ke classpath server dan menempatkan file konfigurasi yang diperlukan di lokasi yang benar di direktori server WildFly agar 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 application-bnd.xml serta merekam konfigurasinya.
Catatan
Jika Anda ingin dapat menskalakan setiap aplikasi web secara independen untuk penggunaan sumber daya Azure Kubernetes Service (AKS) dengan 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.
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.
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) 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.
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.
Catatan
Microsoft merekomendasikan penggunaan alur autentikasi paling aman yang tersedia. Alur autentikasi yang dijelaskan dalam prosedur ini, seperti untuk database, cache, olahpesan, atau layanan AI, memerlukan tingkat kepercayaan yang sangat tinggi dalam aplikasi dan membawa risiko yang tidak ada dalam alur lain. Gunakan alur ini hanya ketika opsi yang lebih aman, seperti identitas terkelola untuk koneksi tanpa kata sandi atau tanpa kunci, tidak layak. Untuk operasi komputer lokal, lebih suka identitas pengguna untuk koneksi tanpa kata sandi atau tanpa kunci.
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:
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:
jdbc:postgresql://<database server name>:5432/<database name>?ssl=true
jdbc:mysql://<database server name>:3306/<database name>?ssl=true\&useLegacyDatetimeCode=false\&serverTimezone=GMT
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 dan DATABASE_SERVER_ADMIN_PASSWORD berikut dengan nilai yang sesuai.
Catatan
Microsoft merekomendasikan penggunaan alur autentikasi paling aman yang tersedia. Alur autentikasi yang dijelaskan dalam prosedur ini, seperti untuk database, cache, olahpesan, atau layanan AI, memerlukan tingkat kepercayaan yang sangat tinggi dalam aplikasi dan membawa risiko yang tidak ada dalam alur lain. Gunakan alur ini hanya ketika opsi yang lebih aman, seperti identitas terkelola untuk koneksi tanpa kata sandi atau tanpa kunci, tidak layak. Untuk operasi komputer lokal, lebih suka identitas pengguna untuk koneksi tanpa kata sandi atau tanpa kunci.
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.
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.
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.
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}."
Menyebarkan ke Azure Kubernetes Service (AKS)
Buat dan terapkan file YAML Kubernetes Anda. Untuk informasi selengkapnya, lihat Mulai Cepat: Menyebarkan kluster Azure Kubernetes Service (AKS) 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 Anda memigrasikan aplikasi ke Azure Kubernetes Service, Anda harus memveriifkasi bahwa aplikasi tersebut berungsi sesuai harapan. Setelah Anda melakukannya, kami memiliki beberapa rekomendasi untuk Anda yang dapat membuat aplikasi lebih cloud-native.
Pertimbangkan untuk menambahkan bagan HELM untuk aplikasi Anda. Bagan helm memungkinkan Anda untuk membuat parameter penyebaran aplikasi untuk digunakan dan disesuaikan 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 Azure Kubernetes Service dengan Azure Pipelines.
Aktifkan Azure Monitor untuk kluster. Untuk informasi selengkapnya, lihat Mengaktifkan pemantauan untuk kluster Kubernetes. 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 Mengaktifkan Prometheus dan Grafana.
Pastikan file penyebaran Anda menentukan bagaimana pembaruan bergulir dilakukan. Untuk informasi selengkapnya, lihat Penyebaran Pembaruan Bergulir di dokumentasi Kubernetes.
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.