Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Domain teknis
Bagian ini memberikan gambaran umum tentang domain teknologi utama untuk kontainerisasi. Diagram berikut menunjukkan arsitektur aplikasi Java EE tradisional.
Diagram berikut menunjukkan arsitektur aplikasi Java EE kontainerisasi.
1. Status sesi
Dalam kebanyakan kasus, aplikasi Java EE menyimpan data sesi yang terkait dengan permintaan pengguna, seperti cookie untuk servlet dan sesi stateful Enterprise Java Beans (EJB). Kami menyarankan Anda menghindari menyimpan informasi status dalam memori mesin virtual Java (JVM) karena wadah Anda harus disimpan tanpa kewarganegaraan. Untuk informasi selengkapnya tentang prinsip sekali pakai, lihat Prinsip desain aplikasi berbasis kontainer dalam dokumentasi
Mekanisme replikasi memori mengasumsikan bahwa satu set server tertentu selalu ada di cluster, atau sejumlah kecil server bergabung atau meninggalkan cluster. Ini tidak kompatibel dengan lingkungan kontainer, jadi kami sarankan Anda menyingkirkan mekanisme replikasi memori Anda. Di lingkungan kontainer, server aplikasi di-deploy kembali saat versi baru dari image container dibuat. Artinya, semua data memori yang direplikasi juga dihapus.
2. Agen
Ada beberapa proses agen yang berjalan pada satu server fisik atau virtual yang biasanya melakukan tugas-tugas otomatisasi dan utilitas, seperti berikut ini:
-
Pemantauan — Lingkungan aplikasi Java EE tradisional sering menggunakan agen khusus untuk pemantauan. Agen ini bertanggung jawab untuk memantau CPU server, memori, penggunaan disk, penggunaan memori di dalam JVM, pesan log, dan banyak lagi. Namun, tidak mungkin menjalankan agen pemantauan secara langsung di lingkungan kontainer. Anda harus mengganti agen pemantauan dengan mekanisme pemantauan yang disediakan oleh platform kontainer, seperti Amazon CloudWatch dan Amazon CloudWatch Logs.
-
Jobs (tugas terjadwal) — Dalam lingkungan aplikasi Java EE tradisional, lingkungan eksekusi pekerjaan sering berada di server yang sama dengan server aplikasi dan bertanggung jawab untuk proses batch yang berjalan lama selain dari permintaan pengguna. Misalnya, proses batch yang dikendalikan oleh pengontrol pekerjaan mengakses database untuk mengambil data dan membuat laporan. Karena beberapa beban kerja ini tidak dapat hidup berdampingan dalam lingkungan kontainer, Anda harus membangun pekerjaan dan lingkungan eksekusi batch secara terpisah dari lingkungan kontainer.
-
Transfer file — Agen transfer file biasanya tidak umum di lingkungan aplikasi Java EE, tetapi mereka kadang-kadang berjalan pada sistem operasi yang sama dengan aplikasi Java sebagai proses independen untuk bertukar file ke atau dari aplikasi eksternal. Misalnya, data yang digunakan oleh aplikasi lain ditransfer ke file setiap hari dan tercermin dalam database. Agen transfer file tidak dapat mengesampingkan kontainer, tetapi harus berjalan di server lain yang memiliki akses ke database dan file.
3. Server aplikasi
Tantangan paling signifikan dalam containerization adalah mengubah server aplikasi. Server aplikasi tradisional yang sesuai dengan Java EE mengasumsikan lingkungan komputasi statis, sehingga mungkin tidak cocok untuk berjalan di lingkungan kontainer. Artinya, server fisik atau virtual diasumsikan sebagai entitas lingkungan komputasi untuk aplikasi Java EE. Misalnya, server aplikasi Java EE berpemilik, seperti IBM WebSphere Application Server (TWA) tradisional dan Oracle WebLogic Server, memiliki mekanisme penyebaran aplikasi mereka sendiri.
Situasinya berbeda di lingkungan kontainer. Dalam lingkungan ini, kontainer menyertakan server aplikasi dan runtime dengan paket pembuatan aplikasi (misalnya, file.war dan .jar) dan digunakan ke platform kontainer seperti Amazon ECS atau Amazon EKS. Kami menyarankan Anda menggunakan mekanisme platform kontainer untuk menyebarkan aplikasi ke lingkungan. Server aplikasi sering digunakan dengan kontainer, sehingga ukurannya harus kecil (kurang dari 500 MB) dan cepat untuk memulai. Untuk memenuhi persyaratan ini, Anda mungkin perlu mengubah server aplikasi tradisional dan bermigrasi ke server aplikasi yang lebih ramah kontainer. Ini mungkin memerlukan migrasi dari IBM WebSphere Application Server ke IBM WebSphere Liberty atau JBoss Enterprise Application Platform (EAP) ke. WildFly
Kami menyarankan Anda mempertimbangkan dampak berikut yang dapat dihasilkan dari perubahan server aplikasi:
-
Injeksi konfigurasi melalui variabel lingkungan (berbeda dengan aplikasi Java EE tradisional yang menyimpan konfigurasi dalam file, seperti web.xml)
-
Kompatibilitas dengan kemampuan Java EE
-
Versi JVM
4. Toko file
Toko file yang paling umum digunakan untuk aplikasi Java EE tradisional adalah sistem file lokal. Kasus penggunaan yang paling umum termasuk file log aplikasi, file yang dihasilkan aplikasi seperti laporan bisnis, dan konten yang diunggah pengguna. Kami menyarankan Anda menghindari menyimpan file di dalam wadah karena kontainer bersifat stateless, yang berarti penyimpanan file harus dieksternalisasi untuk containerisasi.
Pertimbangkan opsi kontainerisasi berikut:
-
Amazon Elastic File System (Amazon EFS) — Amazon EFS adalah layanan NFS terkelola yang dapat diakses dari kontainer. Amazon EFS terintegrasi dengan Amazon ECS dan Amazon EKS. Jika Anda menggunakan Amazon EFS, Anda tidak perlu menulis skrip khusus untuk memasang volume EFS ke container Anda. Langkah pertama untuk opsi ini adalah mencantumkan semua jalur sistem file di aplikasi Anda yang digunakan untuk membaca atau menulis. Setelah Anda mengidentifikasi jalur sistem file yang akan dipertahankan, Anda dapat memetakan jalur sistem file ke jalur sistem file EFS. Untuk informasi selengkapnya, lihat Tutorial: Menggunakan sistem file Amazon EFS dengan Amazon ECS dalam dokumentasi Amazon ECS. Tidak semua jalur harus dipertahankan, terutama file log aplikasi. Sebagian besar aplikasi perusahaan menulis file log ke sistem file lokal. Sebagai bagian dari proses kontainerisasi, sebaiknya Anda mempertimbangkan untuk mengubah tujuan pencatatan untuk menggunakan Standard Out dan Standard Error. Ini memungkinkan Anda untuk menangkap semua output ke CloudWatch Log tanpa mengelola ukuran dan kinerja penyimpanan log. Untuk informasi selengkapnya tentang masuk ke Amazon ECS, lihat Menggunakan driver log awslogs di dokumentasi Amazon ECS.
-
Amazon Simple Storage Service (Amazon S3) — Amazon S3 lebih murah daripada Amazon EFS dan mendukung bandwidth yang lebih luas daripada Amazon EFS, tetapi Amazon S3 memerlukan perubahan kode aplikasi yang lebih luas daripada Amazon EFS. Ini karena Amazon S3 bukan sistem file.
5. Membangun dan menyebarkan proses
Proses kontainerisasi melibatkan perubahan dan perluasan proses pengiriman aplikasi. Dalam lingkungan tradisional, proses pengiriman aplikasi terutama melibatkan artefak Java (misalnya, file.war dan .ear). Dalam lingkungan kontainer, gambar kontainer adalah unit pengiriman. Selain proses untuk membangun artefak Java yang ada, Anda harus membangun proses untuk membangun dan mengirimkan kontainer Docker. Untuk informasi selengkapnya tentang proses pipeline, lihat Membuat dan menerapkan aplikasi Java secara otomatis ke Amazon EKS menggunakan CI/CD pipeline dalam dokumentasi Panduan AWS Preskriptif.
6. Akses basis data
Kontainerisasi aplikasi tradisional sering disertai dengan migrasi database. Untuk mengurangi risiko migrasi, sebaiknya ikuti strategi migrasi untuk database relasional (Panduan AWS Preskriptif). Lingkungan kontainer memerlukan konfigurasi eksternal, termasuk string koneksi database. Anda dapat menggunakan alat seperti Spring Cloud Config
