Catatan
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba masuk atau mengubah direktori.
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba mengubah direktori.
Panduan ini menjelaskan apa yang harus Anda ketahui ketika Anda ingin memigrasikan aplikasi Tomcat yang ada untuk dijalankan di Azure Container Apps (ACA).
Untuk memastikan keberhasilan migrasi, sebelum memulai, selesaikan langkah-langkah penilaian dan inventaris yang dijelaskan di bagian berikut.
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.
Periksa file META-INF/context.xml. Carilah elemen <Resource> dalam elemen <Context>.
Periksa file $CATALINA_BASE/conf/context.xml dan $CATALINA_BASE/conf/server.xml serta file .xml yang ditemukan di $CATALINA_BASE/conf/<nama mesin>/<direktori> nama host.
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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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="{password}"
/>
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}"
/>
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.
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.
Edit server.xml untuk menambahkan sumber daya yang Anda siapkan dalam langkah-langkah pramigrasi, seperti Sumber Data, seperti yang ditunjukkan dalam contoh berikut:
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.
<!-- 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:
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.
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.
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.
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:InitialCodeCacheSizedan-XX:ReservedCodeCacheSizekeJAVA_OPTSvariabel 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.