Memigrasikan aplikasi Tomcat ke Azure Container Apps

Artikel
10/23/2023

Panduan ini menjelaskan apa yang harus Anda ketahui ketika Anda ingin memigrasikan aplikasi Tomcat yang ada untuk dijalankan di Azure Container Apps (ACA).

Pra-migrasi

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

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.

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.

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 dan berskala seperti ACA. ACA dapat memuat keseimbangan di antara beberapa instans dan menghidupkan ulang instans apa pun secara transparan kapan saja, sehingga status tetap dapat diubah ke sistem file tidak disarankan.

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.

Kasus khusus

Skenario produksi tertentu mungkin memerlukan lebih banyak perubahan atau memberlakukan lebih banyak batasan. 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 tugas cron, tidak dapat digunakan dengan penyebaran Tomcat dalam kontainer. Jika aplikasi Anda ditingkatkan, satu pekerjaan terjadwal dapat berjalan lebih dari sekali 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 MemoryRealm digunakan

MemoryRealm membutuhkan file XML yang dipertahankan. Di ACA, Anda harus menambahkan file ini ke gambar kontainer atau mengunggahnya ke penyimpanan bersama yang tersedia untuk kontainer. (Untuk informasi selengkapnya, lihat Identifikasi bagian mekanisme persistensi sesi.) Parameter pathName harus dimodifikasi sesuai.

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.

Pengujian lokal

Sebelum Anda membuat gambar kontainer, migrasikan aplikasi Anda ke JDK dan Tomcat yang ingin Anda gunakan di ACA. Uji aplikasi Anda secara menyeluruh untuk memastikan kompatibilitas dan performa.

Parameterisasi konfigurasi

Dalam pra-migrasi, Anda mungkin akan mengidentifikasi rahasia dan dependensi eksternal, seperti datasources, dalam server.xml dan filecontext.xml. Untuk setiap item yang diidentifikasi, ganti nama pengguna, kata sandi, string koneksi, atau URL apa pun 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}"
/>

Migration

Catatan

Beberapa penyebaran Tomcat mungkin memiliki beberapa aplikasi yang berjalan pada satu server Tomcat. Jika ini masalahnya dalam penyebaran Anda, kami sangat menyarankan untuk menjalankan setiap aplikasi dalam pod terpisah. Tindakan ini memungkinkan Anda untuk mengoptimalkan pemanfaatan sumber daya untuk setiap aplikasi sambil meminimalkan kompleksitas dan sambungan.

Menyiapkan artefak penyebaran

Kloning repositori GitHub Mulai Cepat Tomcat di Kontainer. Repositori ini berisi file konfigurasi Dockerfile dan Tomcat dengan banyak pengoptimalan yang direkomendasikan. Dalam langkah-langkah di bawah ini, kami menguraikan modifikasi yang mungkin perlu Anda lakukan pada file-file ini sebelum membangun gambar kontainer dan menyebarkan ke ACA.

Menambahkan sumber daya JNDI

Edit server.xml untuk menambahkan sumber daya yang Anda siapkan dalam langkah-langkah pramigrasi, seperti Sumber Data, seperti yang diperlihatkan dalam contoh berikut:

<!-- Global JNDI resources
      Documentation at /docs/jndi-resources-howto.html
-->
<GlobalNamingResources>
    <!-- Editable user database that can also be used by
         UserDatabaseRealm to authenticate users
    -->
    <Resource name="UserDatabase" auth="Container"
              type="org.apache.catalina.UserDatabase"
              description="User database that can be updated and saved"
              factory="org.apache.catalina.users.MemoryUserDatabaseFactory"
              pathname="conf/tomcat-users.xml"
               />

    <!-- Migrated datasources here: -->
    <Resource
        name="jdbc/dbconnection"
        type="javax.sql.DataSource"
        url="${postgresdb.connectionString}"
        driverClassName="org.postgresql.Driver"
        username="${postgresdb.username}"
        password="${postgresdb.password}"
    />
    <!-- End of migrated datasources -->
</GlobalNamingResources>

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

Membuat dan mendorong gambar

Cara paling sederhana untuk membangun dan mengunggah gambar ke Azure Container Registry (ACR) untuk digunakan oleh ACA adalah dengan menggunakan az acr build perintah . Perintah ini tidak mengharuskan Docker diinstal di komputer Anda. Misalnya, jika Anda memiliki Dockerfile dari repositori tomcat-container-quickstart dan paket aplikasi petclinic.war di direktori saat ini, Anda dapat membangun gambar kontainer di ACR dengan perintah berikut:

az acr build \
    --registry $acrName \
    --image "${acrName}.azurecr.io/petclinic:{{.Run.ID}}" 
    --build-arg APP_FILE=petclinic.war \
    --build-arg SERVER_XML=prod.server.xml .

Anda dapat menghilangkan parameter --build-arg APP_FILE... jika file WAR Anda bernama ROOT.war. Anda dapat menghilangkan parameter --build-arg SERVER_XML... jika file XML server Anda diberi nama server.xml. Kedua file harus berada di direktori yang sama dengan Dockerfile.

Atau, Anda dapat menggunakan Docker CLI untuk membangun gambar secara lokal dengan menggunakan perintah berikut. Pendekatan ini dapat menyederhanakan pengujian dan penyempurnaan gambar sebelum penyebaran awal ke ACR. Namun, tindakan itu membutuhkan Docker CLI untuk diinstal dan daemon Docker untuk dijalankan.

# Build the image locally.
sudo docker build . --build-arg APP_FILE=petclinic.war -t "${acrName}.azurecr.io/petclinic:1"

# Run the image locally.
sudo docker run -d -p 8080:8080 "${acrName}.azurecr.io/petclinic:1"

# You can now access your application with a browser at http://localhost:8080.

# Sign in to ACR.
sudo az acr login --name $acrName

# Push the image to ACR.
sudo docker push "${acrName}.azurecr.io/petclinic:1"

Untuk informasi selengkapnya, lihat Membuat dan menyimpan gambar kontainer dengan Azure Container Registry.

Menyebarkan ke Azure Container Apps

Perintah berikut menunjukkan contoh penyebaran:

az containerapp create \
    --resource-group <RESOURCE_GROUP> \
    --name <APP_NAME> \
    --environment <ENVIRONMENT_NAME> \
    --image <IMAGE_NAME> \
    --target-port 8080 \
    --ingress 'external' \
    --registry-server <REGISTRY_SERVER> \
    --min-replicas 1

Untuk mulai cepat yang lebih mendalam, lihat Mulai Cepat: Menyebarkan aplikasi kontainer pertama Anda.

Pasca-migrasi

Setelah memigrasikan aplikasi ke ACA, Anda harus memverifikasi bahwa aplikasi berfungsi seperti yang Anda harapkan. Setelah Anda melakukannya, kami memiliki beberapa rekomendasi untuk Anda yang dapat membuat aplikasi Anda lebih Cloud native.

Rekomendasi

Merancang dan menerapkan strategi kelangsungan bisnis dan pemulihan bencana. Untuk aplikasi yang sangat penting, pertimbangkan arsitektur penyebaran multi-wilayah. Untuk informasi selengkapnya, lihat Praktik terbaik untuk kelangsungan bisnis dan pemulihan bencana di Azure Kubernetes Service (AKS).
Evaluasi item dalam file logging.properties. Pertimbangkan untuk menghilangkan atau mengurangi beberapa output pengelogan untuk meningkatkan performa.
Pertimbangkan untuk memantau ukuran cache kode dan menambahkan parameter -XX:InitialCodeCacheSize dan -XX:ReservedCodeCacheSize ke JAVA_OPTS variabel di Dockerfile untuk mengoptimalkan performa lebih lanjut. Untuk informasi selengkapnya, lihat Penyetelan Codecache dalam dokumentasi Oracle.
Pertimbangkan untuk menambahkan aturan peringatan Azure Monitor dan grup tindakan untuk mendeteksi dan menangani kondisi menyimpang dengan cepat.
Pertimbangkan untuk mereplikasi penyebaran Azure Container Apps di wilayah lain untuk latensi yang lebih rendah dan keandalan dan toleransi kesalahan yang lebih tinggi. Gunakan Azure Traffic Manager untuk menyeimbangkan muatan di antara penyebaran atau gunakan Azure Front Door untuk menambahkan pembongkaran SSL dan Web Application Firewall dengan perlindungan DDoS.
Jika replikasi geografis tidak diperlukan, pertimbangkan untuk menambahkan Azure Application Gateway untuk menambahkan pembongkaran SSL dan Web Application Firewall dengan perlindungan DDoS.