Menyebarkan Layanan Mikro ke Azure Container Apps

Azure Container Apps

Azure Cosmos DB

Azure Service Bus

Skenario ini menunjukkan beban kerja yang ada yang awalnya dirancang untuk Kubernetes, yang direplatformasi untuk dijalankan di Azure Container Apps. Container Apps mendukung beban kerja brownfield di mana tim ingin menyederhanakan infrastruktur dan orkestrasi kontainer.

Contoh beban kerja adalah aplikasi layanan mikro kontainer. Ini menggunakan kembali beban kerja yang sama yang ditentukan dalam arsitektur Layanan Mikro pada Azure Kubernetes Service (AKS). Arsitektur ini menghosting ulang beban kerja di Container Apps sebagai platform aplikasinya.

Penting

Arsitektur ini berfokus pada meminimalkan perubahan kode aplikasi dan mendekati transisi dari AKS ke Container Apps sebagai migrasi platform. Tujuannya adalah untuk mereplikasi implementasi yang ada dan menunggak kode atau pengoptimalan infrastruktur yang dapat membahayakan migrasi.

Untuk beban kerja greenfield, lihat Menerapkan layanan mikro dengan menggunakan Aplikasi Container dan Dapr.

Petunjuk / Saran

Contoh implementasi mendukung arsitektur ini dan mengilustrasikan beberapa pilihan desain yang dijelaskan dalam artikel ini.

Sistem

Unduh file Visio arsitektur ini.

Layanan yang berbagi lingkungan yang sama mendapatkan manfaat dengan cara berikut:

ingress internal dan penemuan layanan
Satu ruang kerja Analitik Log untuk pengelogan runtime
Metode manajemen yang aman untuk rahasia dan sertifikat

Aliran Data

Layanan penerimaan: Menerima permintaan klien, menyimpannya sementara, kemudian menerbitkannya ke Azure Service Bus. Ini adalah satu-satunya titik masuk ke dalam beban kerja.
Layanan alur kerja: Mengonsumsi pesan dari Service Bus dan mengirimkannya ke layanan mikro yang mendasar.
Layanan paket: Mengelola paket. Layanan ini mempertahankan statusnya sendiri di Azure Cosmos DB.
Layanan penjadwal drone: Menjadwalkan drone dan memantau drone dalam penerbangan. Layanan ini mempertahankan statusnya sendiri di Azure Cosmos DB.
Layanan pengiriman: Mengelola pengiriman terjadwal atau dalam transit. Layanan ini mempertahankan statusnya sendiri di Azure Managed Redis.
Pengambilan kunci rahasia: Karena ini adalah beban kerja yang sudah ada, hanya beberapa komponen yang mengakses Azure Key Vault untuk mendapatkan kunci rahasia saat runtime. Layanan lain menerima rahasia tersebut dari lingkungan Container Apps.
Log dan metrik: Lingkungan dan semua aplikasi kontainer memancarkan log dan metrik yang fitur Azure Monitor lalu kumpulkan dan visualisasikan.
Gambar kontainer: Gambar kontainer ditarik dari Azure Container Registry yang ada yang sebelumnya digunakan untuk AKS dan disebarkan ke lingkungan Container Apps.

Komponen

Beban kerja menggunakan layanan Azure berikut dalam koordinasi satu sama lain:

Container Apps adalah platform kontainer tanpa server yang menyederhanakan orkestrasi dan manajemen kontainer. Dalam arsitektur ini, Container Apps berfungsi sebagai platform hosting utama untuk semua layanan mikro.

Fitur berikut menggantikan banyak kemampuan arsitektur AKS sebelumnya:
- Penemuan layanan bawaan
- Titik akhir HTTP dan HTTP/2 yang dikelola
- Penyeimbangan beban terintegrasi
- Pengelogan dan pemantauan
- Autoscaling berdasarkan lalu lintas HTTP atau peristiwa yang didukung oleh Event Driven Autoscaling (KEDA) berbasis Kubernetes
- Peningkatan dan penerapan versi aplikasi
Container Registry adalah layanan registri terkelola untuk menyimpan dan mengelola gambar kontainer privat. Dalam arsitektur ini, ini adalah sumber dari semua gambar kontainer yang disebarkan ke lingkungan Container Apps. Registri sama dengan yang digunakan dalam implementasi AKS.
Azure Cosmos DB adalah layanan database multi-model yang didistribusikan secara global. Dalam arsitektur ini, layanan penjadwal drone menggunakan Azure Cosmos DB sebagai penyimpanan datanya.
Azure DocumentDB adalah layanan database yang kompatibel dengan MongoDB yang dikelola sepenuhnya untuk membangun aplikasi modern. Dalam arsitektur ini, layanan paket menggunakan Azure DocumentDB sebagai penyimpanan datanya.
Service Bus adalah layanan olahpesan cloud yang menyediakan kemampuan komunikasi asinkron dan integrasi hibrid. Dalam arsitektur ini, ia menangani pesan asinkron antara layanan penyerapan data dan layanan mikro beban kerja berbasis tugas. Layanan lainnya dalam aplikasi yang ada dirancang sehingga layanan lain dapat memanggilnya dengan permintaan HTTP.
Azure Managed Redis adalah layanan cache dalam memori. Dalam arsitektur ini, ini mengurangi latensi dan meningkatkan throughput untuk data pengiriman drone yang sering diakses.
Key Vault adalah layanan cloud untuk menyimpan dan mengakses rahasia dengan aman seperti kunci API, kata sandi, dan sertifikat. Dalam arsitektur ini, penjadwal drone dan layanan pengiriman menggunakan identitas terkelola yang ditetapkan pengguna untuk mengautentikasi dengan Key Vault dan mengambil rahasia yang diperlukan untuk persyaratan runtime mereka.
Azure Monitor adalah solusi pemantauan komprehensif yang mengumpulkan dan menganalisis data telemetri. Dalam arsitektur ini, ia mengumpulkan dan menyimpan metrik dan log dari semua komponen aplikasi melalui ruang kerja Analitik Log. Anda menggunakan data ini untuk memantau aplikasi, menyiapkan pemberitahuan dan dasbor, dan melakukan analisis akar penyebab kegagalan.
- Application Insights adalah layanan manajemen performa aplikasi yang menyediakan kemampuan pemantauan yang dapat diperluas. Dalam arsitektur ini, setiap layanan diinstrumentasikan dengan Application Insights SDK untuk memantau performa aplikasi.

Alternatif

Arsitektur layanan mikro AKS tingkat lanjut menjelaskan skenario alternatif dari contoh ini yang menggunakan Kubernetes.

Detail skenario

Anda dapat menyederhanakan penyebaran dan manajemen kontainer layanan mikro dengan menggunakan Container Apps, lingkungan tanpa server untuk menghosting aplikasi kontainer.

Fabrikam, Inc., perusahaan fiktif, menerapkan beban kerja pengiriman drone di mana pengguna meminta drone untuk mengambil barang untuk pengiriman. Ketika pelanggan menjadwalkan penjemputan, sistem back-end menetapkan drone dan memberi tahu pengguna dengan perkiraan waktu penjemputan.

Aplikasi layanan mikro disebarkan ke kluster AKS. Tetapi tim Fabrikam tidak memanfaatkan fitur AKS canggih atau khusus platform. Mereka memigrasikan aplikasi ke Container Apps, yang memungkinkan mereka untuk melakukan tindakan berikut:

Gunakan perubahan kode minimal saat memindahkan aplikasi dari AKS ke Aplikasi Kontainer. Perubahan kode terkait dengan pustaka observabilitas yang memperkaya log dan metrik dengan informasi simpul Kubernetes, yang tidak relevan di lingkungan baru.
Menyebarkan infrastruktur dan beban kerja dengan templat Bicep: Tidak ada manifes YAML Kubernetes yang diperlukan untuk menyebarkan kontainer aplikasi mereka.
Mengekspos aplikasi melalui ingress terkelola. Dukungan bawaan untuk ingress eksternal berbasis HTTPS yang mengekspos layanan ingestion menghilangkan kebutuhan untuk mengonfigurasi ingress mereka sendiri.
Tarik gambar kontainer dari Container Registry. Container Apps kompatibel dengan gambar dasar Linux apa pun yang disimpan di repositori apa pun yang tersedia.
Gunakan fitur revisi untuk mendukung kebutuhan siklus hidup aplikasi. Mereka dapat menjalankan beberapa revisi aplikasi kontainer tertentu dan pemisahan lalu lintas di seluruh aplikasi tersebut untuk pengujian A/B atau skenario penyebaran biru/hijau.
Gunakan identitas terkelola untuk mengautentikasi dengan Key Vault dan Container Registry.

Kemungkinan kasus penggunaan

Sebarkan aplikasi berbasis layanan mikro brownfield ke dalam platform as a service (PaaS) untuk menyederhanakan manajemen dan menghindari kompleksitas menjalankan orkestrator kontainer. Beban kerja brownfield menghemat uang dengan menggunakan arsitektur ini dibandingkan penyebaran Kubernetes mereka karena alasan berikut:

Pilihan profil beban kerja
Lebih sedikit waktu yang dihabiskan untuk tugas operasional hari ke-2 untuk tim operasi
Kemampuan untuk menghindari provisi berlebih

Nota

Tidak semua beban kerja menghasilkan penghematan biaya tersebut.

Pertimbangkan penggunaan umum Aplikasi Kontainer lainnya:

Jalankan beban kerja dalam kontainer pada platform berbasis konsumsi tanpa server.
Aplikasi skala otomatis berdasarkan lalu lintas HTTP atau HTTPS dan pemicu berbasis peristiwa yang didukung oleh KEDA.
Minimalkan overhead pemeliharaan untuk aplikasi kontainer.
Menyebarkan titik akhir API.
Aplikasi pemrosesan latar belakang host.
Menangani pemrosesan berbasis peristiwa.

Optimizations

Tujuan tim beban kerja adalah untuk memigrasikan beban kerja yang ada ke Container Apps dengan perubahan kode minimal. Tetapi Anda harus membuat beberapa pengoptimalan untuk meningkatkan arsitektur dan implementasi beban kerja setelah migrasi.

Meningkatkan manajemen rahasia

Beban kerja menggunakan pendekatan hibrid untuk mengelola rahasia. Identitas terkelola hanya berlaku untuk layanan di mana beralih ke identitas terkelola tidak memerlukan modifikasi kode. Penjadwal drone dan layanan pengiriman menggunakan identitas terkelola yang ditetapkan pengguna dengan Key Vault untuk mengakses rahasia yang disimpan. Layanan yang tersisa memerlukan perubahan kode untuk mengadopsi identitas terkelola, sehingga layanan tersebut menggunakan rahasia yang disediakan lingkungan Container Apps.

Pendekatan yang lebih baik adalah memperbarui semua kode untuk mendukung identitas terkelola dengan menggunakan aplikasi atau identitas pekerjaan alih-alih rahasia yang disediakan lingkungan. Untuk informasi selengkapnya tentang identitas beban kerja, lihat Identitas terkelola di Aplikasi Kontainer.

Hindari desain yang memerlukan mode revisi tunggal

Aplikasi kontainer layanan alur kerja berjalan dalam mode revisi tunggal. Dalam mode revisi tunggal, aplikasi memiliki satu revisi yang didukung oleh nol atau lebih replika. Replika terdiri dari kontainer aplikasi dan sidecar yang diperlukan. Contoh ini tidak menggunakan sidecar, sehingga setiap replika adalah satu kontainer. Layanan alur kerja tidak dirancang untuk kompatibilitas ke depan dengan skema pesan. Dua versi layanan yang berbeda tidak boleh berjalan secara bersamaan.

Jika skema pesan Bus Layanan harus diubah, Anda harus mengosongkan bus sebelum menerapkan versi layanan alur kerja yang baru. Pendekatan yang lebih baik adalah memperbarui kode layanan untuk kompatibilitas ke depan dan menggunakan mode multi-revisi untuk mengurangi waktu henti yang terkait dengan pengosongan antrean.

Pertimbangkan pekerjaan berbasis pekerjaan

Layanan alur kerja diimplementasikan sebagai aplikasi kontainer yang beroperasi dalam jangka panjang. Tetapi juga dapat berjalan sebagai pekerjaan di Aplikasi Kontainer. Pekerjaan adalah aplikasi kontainer yang dimulai sesuai permintaan, berjalan hingga selesai berdasarkan pekerjaan yang tersedia, lalu mematikan dan membebaskan sumber daya. Pekerjaan bisa lebih ekonomis daripada menjalankan replika secara terus-menerus. Memigrasikan layanan untuk dijalankan sebagai pekerjaan di Container Apps berdasarkan beban kerja yang tersedia dalam antrean mungkin merupakan opsi praktis. Ini tergantung pada volume antrean yang biasa dan seberapa terbatasnya, dapat diparalelkan, dan dioptimalkannya sumber daya layanan alur kerja ini ditulis. Lakukan eksperimen dan verifikasi untuk menentukan pendekatan terbaik.

Menerapkan kontrol lalu lintas masuk

Beban kerja menggunakan fitur ingress eksternal bawaan dari Container Apps untuk mengekspos layanan ingestion. Pendekatan kontrol ingress tidak menyediakan kemampuan untuk sepenuhnya memposisikan titik masuk Anda di belakang firewall aplikasi web (WAF) atau untuk menyertakannya dalam paket Azure DDoS Protection. Anda perlu mem-front semua beban kerja yang menghadap web dengan WAF. Untuk mencapai konfigurasi ini di lingkungan Aplikasi Kontainer, Anda harus menonaktifkan ingress publik bawaan dan menambahkan Application Gateway atau Azure Front Door.

Nota

Gateway memerlukan pemeriksaan kesehatan yang bermakna, yang menjaga layanan masuk tetap hidup dan mencegahnya menskalakan ke nol.

Modernisasi dengan Dapr

Anda dapat memodernisasi beban kerja lebih lanjut dengan mengintegrasikan dengan Distributed Application Runtime (Dapr). Ini menambahkan abstraksi antara kode beban kerja dan penyimpanan status, sistem olahpesan, dan mekanisme penemuan layanan. Untuk informasi selengkapnya, lihat Menyebarkan layanan mikro dengan Aplikasi Kontainer dan Dapr. Jika beban kerja Anda di Kubernetes sudah menggunakan Dapr atau scaler KEDA umum, migrasi ke Container Apps sering kali mudah dan dapat mempertahankan kemampuan tersebut.

Migrasi ke autentikasi dan otorisasi pengguna

Beban kerja tidak mendelegasikan otorisasi ke gateway. Layanan penyerapan menangani otorisasi kliennya. Pendekatan yang lebih baik adalah membongkar tanggung jawab ini ke fitur autentikasi dan otorisasi bawaan, sering disebut sebagai Easy Auth. Perubahan ini memanfaatkan kemampuan platform dan mengurangi kode kustom dalam layanan mikro penyerapan.

Pertimbangan

Pertimbangan berikut mengimplementasikan pilar Microsoft Azure Well-Architected Framework, yang merupakan serangkaian tenet panduan yang dapat Anda gunakan untuk meningkatkan kualitas beban kerja. Untuk informasi selengkapnya, lihat Azure Well-Architected Framework.

Keandalan

Keandalan membantu memastikan bahwa aplikasi Anda dapat memenuhi komitmen yang Anda buat kepada pelanggan Anda. Untuk informasi selengkapnya, lihat daftar periksa tinjauan desain untukKeandalan .

Container Apps membantu Anda menyebarkan, mengelola, memelihara, dan memantau aplikasi dalam beban kerja. Anda dapat meningkatkan keandalan dengan mengikuti rekomendasi inti. Beberapa rekomendasi diimplementasikan selama migrasi dari Kubernetes.

Revisi membantu Anda menyebarkan pembaruan aplikasi tanpa waktu henti. Anda dapat menggunakan revisi untuk mengelola penyebaran pembaruan aplikasi dan membagi lalu lintas antara revisi untuk mendukung penyebaran biru/hijau dan pengujian A/B.
Dengan fitur observabilitas Container Apps, Anda memiliki wawasan tentang komponen yang berjalan dalam lingkungan. Aplikasi Kontainer terintegrasi dengan Application Insights dan Log Analytics. Anda menggunakan data ini untuk melacak operasi dan mengatur pemberitahuan berdasarkan metrik dan peristiwa sebagai bagian dari sistem pengamatan Anda.

Pemantauan performa membantu Anda mengevaluasi aplikasi di bawah beban. Metrik dan log menyediakan data untuk mengenali tren, menyelidiki kegagalan, dan melakukan analisis akar penyebab.
Gunakan pemeriksaan kesehatan dan kesiapan untuk menangani kontainer yang dimulai lambat dan menghindari pengiriman lalu lintas sebelum siap. Implementasi Kubernetes mencakup titik akhir ini. Terus gunakan mereka jika memberikan sinyal yang efektif.
Saat layanan tiba-tiba dihentikan, Aplikasi Kontainer secara otomatis memulai ulang. Penemuan layanan diaktifkan sehingga layanan alur kerja dapat menemukan layanan mikro hilirnya. Gunakan kebijakan ketahanan untuk menangani batas waktu dan memperkenalkan logika pemutus arus tanpa perlu menyesuaikan kode lebih lanjut.
Aktifkan aturan penskalaan otomatis untuk memenuhi permintaan saat lalu lintas dan beban kerja meningkat.
Gunakan fitur penyeimbangan beban dinamis dan penskalaan Aplikasi Kontainer untuk meningkatkan ketersediaan. Siapkan subnet di lingkungan Anda agar selalu memiliki cukup alamat IP yang tersedia untuk replika atau tugas di masa mendatang.
Hindari menyimpan status langsung dalam lingkungan Container Apps, karena semua status hilang saat replika dimatikan. Eksternalisasi status ke penyimpanan status khusus untuk setiap layanan mikro. Arsitektur ini mendistribusikan status di tiga penyimpanan berbeda: Azure Managed Redis, Azure Cosmos DB untuk NoSQL, dan Azure DocumentDB.
Sebarkan semua sumber daya, termasuk Container Apps, dengan menggunakan topologi multi-zona. Untuk informasi selengkapnya, lihat Dukungan zona ketersediaan di Aplikasi Kontainer.

Atur jumlah replika minimum untuk aplikasi nontransient ke setidaknya satu replika untuk setiap zona ketersediaan. Selama kondisi operasi normal, replika dengan andal didistribusikan dan diseimbangkan di seluruh zona ketersediaan di wilayah tersebut.

Keamanan

Keamanan memberikan jaminan terhadap serangan yang disukai dan penyalahgunaan data dan sistem berharga Anda. Untuk informasi selengkapnya, lihat daftar periksa tinjauan desain untuk Keamanan.

Rahasia

Aplikasi kontainer Anda dapat menyimpan dan mengambil nilai sensitif sebagai rahasia. Setelah Anda menentukan rahasia untuk aplikasi kontainer, rahasia tersebut tersedia untuk digunakan oleh aplikasi dan aturan skala terkait. Jika Anda menjalankan dalam mode multi-revisi, semua revisi memiliki rahasia yang sama. Karena rahasia dianggap sebagai perubahan cakupan aplikasi, jika Anda mengubah nilai rahasia, revisi baru tidak dibuat. Tetapi untuk setiap revisi yang sedang berjalan untuk memuat nilai rahasia baru, Anda perlu memulai ulang. Dalam skenario ini, nilai variabel aplikasi dan lingkungan digunakan.
Tulis ulang kode layanan untuk menggunakan identitas terkelola aplikasi sendiri untuk mengautentikasi ke dependensi alih-alih rahasia yang telah dibagikan sebelumnya. Semua dependensi memiliki SDK yang mendukung autentikasi identitas terkelola.
Anda dapat menyimpan nilai sensitif dengan aman dalam variabel lingkungan di tingkat aplikasi. Saat variabel lingkungan berubah, aplikasi kontainer membuat revisi baru.

Keamanan jaringan

Untuk membatasi akses eksternal, hanya layanan ingest yang dikonfigurasi untuk akses eksternal. Layanan back-end hanya dapat diakses melalui jaringan virtual internal di lingkungan Container Apps dan dikonfigurasi sebagai mode internal. Hanya mengekspos layanan ke internet jika diperlukan.

Karena arsitektur ini menggunakan fitur ingress eksternal bawaan, solusi ini tidak menyediakan kemampuan untuk sepenuhnya memposisikan titik masuk Anda di belakang WAF atau untuk menyertakannya dalam paket DDoS Protection. Hadapkan semua beban kerja yang terkait web dengan firewall aplikasi web. Untuk informasi selengkapnya tentang peningkatan ingress, lihat Menerapkan kontrol ingress.
Saat membuat lingkungan, Anda dapat menyediakan jaringan virtual kustom. Jika tidak, Microsoft secara otomatis menghasilkan dan mengelola jaringan virtual. Anda tidak dapat memanipulasi jaringan virtual yang dikelola Microsoft ini, seperti dengan menambahkan kelompok keamanan jaringan (NSG) atau memaksa lalu lintas penerowongan paksa ke firewall keluar. Contohnya menggunakan jaringan virtual yang dihasilkan secara otomatis, tetapi jaringan virtual kustom meningkatkan kontrol keamanan. Jaringan kustom memungkinkan Anda menerapkan perutean berbasis NSG dan rute yang ditentukan pengguna (UDR) melalui Azure Firewall.

Untuk informasi selengkapnya tentang opsi topologi jaringan, termasuk dukungan endpoint privat untuk ingress, lihat Arsitektur Jaringan di Container Apps.

Identitas beban kerja

Container Apps mendukung identitas terkelola Microsoft Entra yang memungkinkan aplikasi Anda mengautentikasi dirinya ke sumber daya lain yang dilindungi oleh ID Microsoft Entra, seperti Key Vault, tanpa mengelola kredensial di aplikasi kontainer Anda. Aplikasi kontainer dapat menggunakan identitas yang ditetapkan sistem, identitas yang ditetapkan pengguna, atau keduanya. Untuk layanan yang tidak mendukung autentikasi ID Microsoft Entra, simpan rahasia di Key Vault dan gunakan identitas terkelola untuk mengakses rahasia.
Gunakan satu identitas terkelola khusus yang ditetapkan pengguna untuk akses Container Registry. Container Apps mendukung penggunaan identitas terkelola yang berbeda untuk operasi beban kerja daripada untuk akses registri kontainer. Pendekatan ini menyediakan kontrol akses terperinci. Jika beban kerja Anda memiliki beberapa lingkungan Container Apps, jangan gunakan identitas yang sama di seluruh instansi.
Gunakan identitas terkelola yang ditetapkan sistem untuk identitas beban kerja untuk mengikat siklus hidup identitas ke siklus hidup komponen beban kerja.

Rekomendasi keamanan lainnya

Implementasi Kubernetes dari beban kerja ini memberikan perlindungan dengan menggunakan kemampuan Pertahanan Microsoft untuk Kontainer. Dalam arsitektur ini, Defender for Containers hanya menilai kerentanan kontainer di Container Registry Anda. Defender untuk Kontainer tidak memberikan perlindungan runtime untuk Aplikasi Kontainer. Evaluasi pelengkap dengan solusi keamanan non-Microsoft jika perlindungan runtime adalah persyaratan.
Jangan jalankan beban kerja di lingkungan Container Apps terbagi. Segmentasikan dari beban kerja atau komponen lain yang tidak memerlukan akses ke layanan mikro ini. Buat lingkungan Container Apps terpisah. Aplikasi dan pekerjaan yang berjalan di lingkungan Container Apps dapat menemukan dan menjangkau layanan apa pun yang berjalan di lingkungan dengan ingress internal diaktifkan.

Pengoptimalan Biaya

Pengoptimalan Biaya berfokus pada cara untuk mengurangi pengeluaran yang tidak perlu dan meningkatkan efisiensi operasional. Untuk informasi selengkapnya, lihat daftar periksa Design review untuk Pengoptimalan Biaya.

Tinjau contoh perkiraan harga untuk beban kerja. Gunakan kalkulator harga Azure. Konfigurasi bervariasi, jadi sesuaikan agar sesuai dengan skenario Anda.
Dalam skenario ini, Azure Cosmos DB, Azure Managed Redis, dan Service Bus Premium adalah pengandar biaya utama.
Untuk kontainer yang biasanya menggunakan CPU rendah dan jumlah memori, evaluasi profil beban kerja konsumsi terlebih dahulu. Perkirakan biaya profil konsumsi berdasarkan penggunaan Anda untuk membantu mengumpulkan data biaya dasar dan mengevaluasi profil lain. Misalnya, Anda dapat menggunakan profil beban kerja khusus untuk komponen yang memiliki penggunaan yang sangat dapat diprediksi dan stabil dan dapat berbagi simpul khusus. Untuk pengoptimalan biaya, pertahankan jumlah simpul sebagai kelipatan tiga untuk setiap profil yang ditentukan guna memastikan ketersediaan host komputasi dan distribusi replika yang memadai di seluruh zona ketersediaan.
Hilangkan biaya komputasi selama periode tidak aktif dengan memastikan komponen dapat menskalakan ke nol sehingga Anda hanya membayar jika diperlukan. Pendekatan ini mengurangi pengeluaran untuk aplikasi yang memiliki variabel atau penggunaan yang jarang. Pemeriksaan kesehatan biasanya mencegah pengurangan skala sepenuhnya menjadi nol. Pada arsitektur, Anda dapat mengimplementasikan kembali layanan alur kerja sebagai tugas untuk memanfaatkan pengaturan skala ke nol saat periode tidak aktif. Pendekatan ini berpasangan dengan baik dengan beban kerja yang dapat menggunakan rencana konsumsi.
Untuk menghindari biaya jaringan lintas wilayah, sebarkan semua komponen, seperti penyimpanan status dan registri kontainer, di wilayah yang sama.

Keunggulan Operasional

Keunggulan Operasional mencakup proses operasi yang menyebarkan aplikasi dan membuatnya tetap berjalan dalam produksi. Untuk informasi selengkapnya, lihat daftar periksa tinjauan desain untukKeunggulan Operasional.

Gunakan integrasi GitHub Actions atau Azure Pipelines untuk menyiapkan alur integrasi berkelanjutan dan penyebaran berkelanjutan (CI/CD) otomatis.
Gunakan mode multi-revisi dengan pemisahan lalu lintas untuk menguji perubahan pada kode beban kerja dan aturan skala Anda.
Integrasikan dengan Application Insights dan Log Analytics untuk memberikan wawasan tentang beban kerja Anda. Gunakan ruang kerja Analitik Log yang sama dengan komponen beban kerja Anda lainnya untuk menyatukan semua wawasan beban kerja.
Gunakan infrastruktur sebagai kode (IaC), seperti Bicep atau Terraform, untuk mengelola semua penyebaran infrastruktur. Penyebaran termasuk lingkungan Container Apps, registri kontainer, dan penyimpanan status layanan mikro. Pisahkan alur penyebaran layanan mikro dari alur infrastruktur karena sering kali tidak berbagi siklus hidup yang sama. Alur deklaratif Anda untuk infrastruktur Azure harus menyebarkan semua sumber daya kecuali sumber daya aplikasi kontainer.
Gunakan pendekatan penting untuk membuat, memperbarui, dan menghapus aplikasi kontainer dari lingkungan. Sangat penting jika Anda secara dinamis mengatur logika pergeseran lalu lintas di antara revisi. Gunakan tindakan GitHub atau tugas Azure Pipelines dalam alur kerja penyebaran Anda. Pendekatan imperatif ini dapat didasarkan pada definisi aplikasi YAML . Untuk meminimalkan kegagalan pemeriksaan kesehatan, selalu pastikan alur Anda mengisi registri kontainer Anda dengan gambar kontainer baru sebelum menyebarkan aplikasi kontainer.

Perubahan penting dari implementasi Kubernetes adalah pergeseran dari pengelolaan file manifes Kubernetes, seperti menentukan Deployment objek Kubernetes. Kubernetes menyediakan pendekatan berhasil bersama-sama atau gagal bersama-sama secara atomic untuk penyebaran layanan mikro, melalui objek manifes ini. Di Container Apps, setiap layanan mikro disebarkan secara independen. Alur penyebaran Anda menjadi bertanggung jawab untuk mengatur urutan dan strategi pembatalan yang diperlukan untuk memiliki penyebaran yang aman.

Efisiensi Performa

Efisiensi Performa mengacu pada kemampuan beban kerja Anda untuk menskalakan untuk memenuhi tuntutan pengguna secara efisien. Untuk informasi selengkapnya, lihat daftar periksa tinjauan Desain untukEfisiensi Performa .

Beban kerja didistribusikan di antara beberapa aplikasi layanan mikro.
Setiap layanan mikro bersifat independen dan tidak berbagi status dengan layanan mikro lainnya, yang memungkinkan penskalaan independen.
Gunakan tugas Container Apps untuk menjalankan proses terbatas, menerapkan runtime sementara dan mengurangi konsumsi sumber daya untuk layanan yang tidak aktif. Evaluasi implikasi performa dari mengaktifkan dan menonaktifkan pekerjaan dibandingkan dengan menjaga komponen siap dan dalam kondisi siaga.
Autoscaling diaktifkan. Lebih suka penskalakan berbasis peristiwa daripada penskalakan berbasis metrik jika memungkinkan. Misalnya, layanan alur kerja, jika dirancang untuk mendukungnya, dapat diskalakan berdasarkan kedalaman antrean Service Bus. Penskala otomatis default didasarkan pada permintaan HTTP. Selama replatforming, penting untuk memulai dengan pendekatan penskalaan yang sama, lalu mengevaluasi pengoptimalan penskalaan nanti.
Permintaan secara dinamis dimuat seimbang ke replika revisi yang tersedia.
Metrik, termasuk pemanfaatan CPU, memori, informasi bandwidth, dan penyimpanan, tersedia melalui Azure Monitor.

Menyebarkan skenario ini

Ikuti langkah-langkah dalam README.md di contoh repositori skenario Container Apps.

Kontributor

Microsoft mempertahankan artikel ini. Kontributor berikut menulis artikel ini.

Kontributor:

Julien Strebler | Arsitek Solusi Cloud
Steve Caravajal | Arsitek Solusi Cloud
Simon Kurtz | Arsitek Solusi Cloud

Langkah berikutnya

Dokumentasi Container Apps

Saran dan Komentar

Apakah halaman ini membantu?