Migrasi aplikasi Tomcat ke Tomcat di Azure App Service

  • Artikel

Panduan ini menjelaskan apa yang harus diketahui ketika Anda ingin memigrasikan aplikasi Tomcat yang ada untuk dijalankan di Azure App Service menggunakan Tomcat 9.0.

Pra-migrasi

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

Jika Anda tidak dapat memenuhi persyaratan pra-migrasi ini, lihat panduan migrasi pendamping berikut:

Beralih ke platform yang didukung

App Service menawarkan versi Tomcat tertentu pada versi Java tertentu. Untuk memastikan kompatibilitas, migrasikan aplikasi Anda ke salah satu versi Tomcat dan Java yang didukung di lingkungannya saat ini sebelum Anda melanjutkan ke salah satu langkah yang tersisa. Pastikan untuk sepenuhnya menguji konfigurasi yang dihasilkan. Gunakan rilis stabil terbaru dari distribusi Linux dalam pengujian 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

Di Azure App Service, biner untuk Java 8 disediakan dari Eclipse Temurin. Untuk Java 11, 17, dan semua rilis LTS Java di masa mendatang, App Service menyediakan Microsoft Build of OpenJDK. Biner ini tersedia untuk diunduh secara gratis di situs-situs berikut:

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

${CATALINA_HOME}/bin/version.sh

Untuk mendapatkan versi saat ini yang digunakan oleh Azure App Service, unduh Tomcat 9, tergantung pada versi mana yang ingin Anda gunakan di Azure App Service.

Sumber daya eksternal inventaris

Sumber daya eksternal, seperti sumber data, broker pesan JMS, dan lainnya disuntikkan melalui Java Naming and Directory Interface (JNDI). Beberapa sumber daya tersebut mungkin memerlukan migrasi atau konfigurasi ulang.

Di dalam aplikasi Anda

Periksa file META-INF/context.xml. Carilah elemen <Resource> dalam elemen <Context>.

Pada server aplikasi

Periksa file $CATALINA_BASE/conf/context.xml dan $CATALINA_BASE/conf/server.xml serta file .xml yang ditemukan di direktori $CATALINA_BASE/conf/[engine-name]/[host-name].

Dalam file context.xml, sumber daya JNDI akan dijelaskan oleh elemen <Resource> di dalam elemen <Context> tingkat atas.

Dalam file server.xml, sumber daya JNDI akan dijelaskan oleh elemen <Resource> di dalam elemen <GlobalNamingResources>.

Datasource

Datasource adalah sumber daya JNDI dengan atribut type yang diatur ke javax.sql.DataSource. Untuk setiap datasource, dokumentasikan informasi berikut:

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

Untuk informasi selengkapnya, lihat PANDUAN Datasource JNDI di dokumentasi Tomcat.

Semua sumber daya eksternal lainnya

Tidak memungkinkan untuk mendokumentasikan setiap kemungkinan dependensi eksternal dalam panduan ini. Tim Anda bertanggung jawab untuk memverifikasi bahwa Anda dapat memenuhi setiap dependensi eksternal aplikasi Anda setelah migrasi.

Rahasia inventaris

Kata sandi dan string aman

Periksa semua properti dan file konfigurasi di server produksi untuk adanya string rahasia dan kata sandi. Pastikan untuk memeriksa server.xml dan context.xml di $CATALINA_BASE/conf. Anda juga dapat menemukan file konfigurasi yang berisi kata sandi atau info masuk di dalam aplikasi Anda. Ini mungkin termasuk META-INF / context.xml, dan, untuk aplikasi Spring Boot, application.properties atau file application.yml.

Sertifikat inventaris

Dokumentasikan semua sertifikat yang digunakan untuk titik akhir SSL publik atau komunikasi dengan database backend dan sistem lainnya. Anda bisa melihat semua sertifikat di server produksi dengan menjalankan perintah berikut ini:

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

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. Anda dapat mengidentifikasi beberapa atau semua skenario 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 ke dalam sistem file App Service. Untuk informasi selengkapnya, lihat Menyajikan konten Azure Storage pada App Service di Linux.

Mengidentifikasi mekanisme persistensi sesi

Untuk mengidentifikasi manajer persistensi sesi yang digunakan, periksa file context.xml dalam konfigurasi aplikasi dan Tomcat Anda. Cari elemen <Manager>, lalu catat nilai atribut className.

Implementasi PersistentManager bawaan Tomcat, seperti StandardManager atau FileStore tidak dirancang untuk digunakan dengan platform terdistribusi berskala seperti App Service. Karena App Service dapat menyeimbangkan beban di antara beberapa instans dan memulai ulang instans apa pun secara transparan kapan saja, mempertahankan status yang dapat diubah untuk sistem file tidak direkomendasikan.

Jika persistensi sesi diperlukan, Anda harus menggunakan implementasi PersistentManager alternatif yang akan menulis ke penyimpanan data eksternal, seperti VMware Tanzu Session Manager dengan Redis Cache. Untuk informasi selengkapnya, lihat Menggunakan Redis sebagai cache sesi dengan Tomcat.

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.

Kasus khusus

Skenario produksi tertentu mungkin memerlukan perubahan tambahan atau memberlakukan batasan tambahan. Meskipun skenario seperti itu jarang terjadi, penting untuk memastikan bahwa skenario tersebut tidak berlaku pada aplikasi Anda atau telah diselesaikan dengan benar.

Tentukan apakah aplikasi bergantung pada pekerjaan terjadwal

Pekerjaan terjadwal, seperti tugas Quartz Scheduler atau pekerjaan cron, tidak dapat digunakan dengan App Service. App 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.

Inventarisasi setiap pekerjaan terjadwal, di dalam atau di luar server aplikasi.

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.

Menentukan apakah pengklusteran Tomcat digunakan

Pengklusteran Tomcat tidak didukung di Azure App Service. Sebagai gantinya, Anda dapat mengonfigurasi dan mengelola penskalaan dan penyeimbangan beban melalui Azure App Service tanpa fungsionalitas khusus Tomcat. Anda dapat mempertahankan keadaan sesi ke lokasi alternatif untuk membuatnya tersedia di seluruh replika. Untuk informasi selengkapnya, lihat Mengidentifikasi mekanisme persistensi sesi.

Untuk menentukan apakah aplikasi Anda menggunakan pengklusteran, cari elemen <Cluster> di dalam elemen <Host> atau <Engine> dalam file server.xml.

Menentukan apakah konektor non-HTTP digunakan

App Service hanya mendukung konektor HTTP tunggal. Jika aplikasi Anda memerlukan konektor tambahan, seperti konektor AJP, jangan gunakan App Service.

Untuk mengidentifikasi konektor HTTP yang digunakan oleh aplikasi Anda, cari elemen <Connector> di dalam file server.xml dalam konfigurasi Tomcat Anda.

Menentukan apakah MemoryRealm digunakan

MemoryRealm membutuhkan file XML yang dipertahankan. Di Azure AppService, Anda harus mengunggah file ini ke direktori /home atau salah satu subdirektorinya, atau ke penyimpanan yang dipasang. Anda kemudian harus memodifikasi parameter pathName secara tepat.

Untuk menentukan apakah MemoryRealm saat ini digunakan, periksa file server.xml dan context.xml dan cari elemen <Realm> tempat atribut className diatur menjadi org.apache.catalina.realm.MemoryRealm.

Menentukan apakah pelacakan sesi SSL digunakan

App Service melakukan pembongkaran sesi di luar runtime Tomcat, sehingga Anda tidak dapat menggunakan pelacakan sesi SSL. Sebagai gantinya, gunakan mode pelacakan sesi yang berbeda (COOKIE atau URL). Jika Anda memerlukan pelacakan sesi SSL, jangan gunakan App Service.

Menentukan apakah AccessLogValve digunakan

Jika menggunakan AccessLogValve, Anda harus mengatur parameter directory ke /home/LogFiles atau salah satu subdirektorinya.

Migration

Parameterisasi konfigurasi

Dalam langkah-langkah pra-migrasi, Anda mungkin mengidentifikasi beberapa rahasia dan dependensi eksternal, seperti datasource, dalam file server.xml dan context.xml. Untuk setiap item yang Anda identifikasi, ganti nama pengguna, kata sandi, string koneksi, atau URL dengan variabel lingkungan.

Misalnya, file context.xml berisi elemen berikut:

<Resource
    name="jdbc/dbconnection"
    type="javax.sql.DataSource"
    url="jdbc:postgresql://postgresdb.contoso.com/wickedsecret?ssl=true"
    driverClassName="org.postgresql.Driver"
    username="postgres"
    password="t00secure2gue$$"
/>

Dalam hal ini, Anda dapat mengubahnya seperti yang ditunjukkan dalam contoh berikut:

<Resource
    name="jdbc/dbconnection"
    type="javax.sql.DataSource"
    url="${postgresdb.connectionString}"
    driverClassName="org.postgresql.Driver"
    username="${postgresdb.username}"
    password="${postgresdb.password}"
/>

Untuk memastikan bahwa substitusi parameter terjadi untuk file context.xml apa pun dalam folder META-INF di dalam file .war yang disebarkan, pastikan untuk mengatur CATALINA_OPTS variabel lingkungan seperti yang ditunjukkan dalam contoh berikut:

export CATALINA_OPTS="-Dorg.apache.tomcat.util.digester.PROPERTY_SOURCE=org.apache.tomcat.util.digester.EnvironmentPropertySource"

Menyediakan paket App Service

Dari daftar paket layanan yang tersedia di harga App Service, pilih paket yang spesifikasinya memenuhi atau melebihi perangkat keras produksi saat ini.

Catatan

Jika Anda berencana untuk menjalankan penyebaran pementasan/kenari atau menggunakan slot penyebaran, paket App Service harus menyertakan kapasitas tambahan tersebut. Sebaiknya gunakan paket Premium atau yang lebih tinggi untuk aplikasi Java. Untuk informasi selengkapnya, lihat Menyiapkan staging environment dalam Azure App Service.

Kemudian, buat paket App Service. Untuk informasi selengkapnya, lihat Mengelola paket Layanan Aplikasi di Azure.

Membuat dan menyebarkan Aplikasi Web

Anda harus membuat Aplikasi Web di Paket App Service (memilih versi Tomcat sebagai tumpukan runtime) untuk setiap file WAR yang disebarkan ke server Tomcat Anda.

Catatan

Meskipun dimungkinkan untuk menyebarkan beberapa file WAR ke satu aplikasi web, tindakan ini sangat tidak diinginkan. Menyebarkan beberapa file WAR ke satu aplikasi web mencegah setiap aplikasi menskalakan sesuai dengan tuntutan penggunaannya sendiri. Tindakan ini juga menambah kerumitan pada jalur penyebaran berikutnya. Jika beberapa aplikasi harus tersedia di satu URL, pertimbangkan untuk menggunakan solusi perutean seperti Azure Application Gateway.

Aplikasi Maven

Jika aplikasi Anda dibangun dari file POM Maven, gunakan plugin Webapp untuk Maven untuk membuat Aplikasi Web dan menyebarkan aplikasi Anda.

Aplikasi Non-Maven

Jika Anda tidak dapat menggunakan plugin Maven, Anda harus memprovisikan Aplikasi Web melalui mekanisme lain, seperti:

Setelah Aplikasi Web dibuat, gunakan salah satu mekanisme penyebaran yang tersedia untuk menyebarkan aplikasi Anda.

Memigrasikan opsi runtime JVM

Jika aplikasi Anda memerlukan opsi runtime tertentu, gunakan mekanisme yang paling tepat untuk menentukannya.

Mengisi rahasia

Gunakan Pengaturan Aplikasi guna menyimpan rahasia khusus untuk aplikasi Anda. Jika Anda berniat menggunakan rahasia yang sama di antara beberapa aplikasi atau memerlukan kebijakan akses dan kemampuan audit yang mendetail, gunakan Azure Key Vault sebagai gantinya.

Mengonfigurasi domain dan SSL kustom

Jika aplikasi Anda akan terlihat di domain kustom, Anda harus memetakan aplikasi web Anda ke sana. Untuk informasi, lihat Tutorial: Memetakan nama DNS kustom yang sudah ada ke Azure App Service.

Kemudian, Anda harus mengikat sertifikat SSL untuk domain tersebut ke Aplikasi Web App Service Anda. Untuk informasi selengkapnya, lihat Mengamankan nama DNS kustom dengan pengikatan data TLS/SSL di Azure App Service.

Mengimpor sertifikat backend

Semua sertifikat untuk berkomunikasi dengan sistem backend, seperti database, harus tersedia untuk App Service. Untuk informasi selengkapnya, lihat Menambahkan sertifikat TLS/SSL di Azure App Service.

Memigrasikan sumber data, pustaka, dan sumber daya JNDI

Untuk langkah-langkah konfigurasi sumber data, lihat bagian Sumber data dari Mengonfigurasi aplikasi Java Linux untuk Azure App Service.

Untuk petunjuk sumber data tambahan, lihat bagian berikut JNDI Datasource How-To dalam dokumentasi Tomcat:

Migrasikan dependensi classpath tingkat server tambahan dengan mengikuti langkah yang sama untuk file JAR sumber data.

Migrasikan Sumber daya JDNI tingkat server bersama tambahan.

Catatan

Jika Anda mengikuti arsitektur satu WAR per aplikasi web yang direkomendasikan, pertimbangkan untuk memigrasikan pustaka classpath tingkat server dan sumber daya JNDI ke dalam aplikasi Anda. Hal ini akan secara signifikan menyederhanakan pemerintahan komponen dan manajemen perubahan.

Memigrasikan konfigurasi yang tersisa

Saat menyelesaikan bagian sebelumnya, Anda akan memiliki konfigurasi server yang dapat dikustomisasi di /home/tomcat/conf.

Selesaikan migrasi dengan menyalin konfigurasi tambahan apa pun (seperti realm dan JASPIC)

Memigrasikan pekerjaan terjadwal

Untuk menjalankan pekerjaan terjadwal di Azure, pertimbangkan untuk menggunakan Pemicu Timer untuk Azure Functions. Anda tidak perlu memigrasikan kode pekerjaan itu sendiri ke dalam suatu fungsi. Fungsi ini cukup memanggil URL di aplikasi Anda untuk memicu pekerjaan. Jika eksekusi pekerjaan tersebut harus dipanggil secara dinamis dan/atau dilacak secara terpusat, pertimbangkan untuk menggunakan Spring Batch.

Atau, Anda dapat membuat aplikasi Logika dengan pemicu Pengulangan untuk memanggil URL tanpa menulis kode apa pun di luar aplikasi Anda. Untuk informasi selengkapnya, lihat Gambaran Umum - Apa itu Azure Logic Apps? dan Buat, jadwalkan, dan jalankan tugas dan alur kerja berulang dengan pemicu Pengulangan di Azure Logic Apps.

Catatan

Untuk mencegah penggunaan berbahaya, Anda mungkin perlu memastikan bahwa titik akhir pemanggilan pekerjaan memerlukan info masuk. Dalam hal ini, fungsi pemicu perlu memberikan info masuk.

Mulai ulang dan pengujian awal

Terakhir, Anda harus memulai ulang Aplikasi Web untuk menerapkan semua perubahan konfigurasi. Setelah selesai memulai ulang, verifikasi bahwa aplikasi Anda berjalan dengan benar.

Pasca-migrasi

Sekarang setelah memigrasikan aplikasi Anda ke Azure App Service, Anda harus memverifikasi bahwa aplikasi tersebut berfungsi sesuai harapan. Setelah melakukannya, kami memiliki beberapa rekomendasi untuk Anda yang dapat membuat aplikasi Anda lebih bersifat Cloud native.

Rekomendasi