Memperbarui dan menyebarkan perubahan di Azure Container Apps
Manajemen perubahan bisa menjadi tantangan saat Anda mengembangkan aplikasi kontainer di cloud. Pada akhirnya, Anda memerlukan dukungan untuk melacak perubahan, memastikan waktu aktif, dan memiliki mekanisme untuk menangani pemutaran kembali yang lancar.
Manajemen perubahan di Azure Container Apps didukung oleh revisi, yang merupakan rekam jepret dari setiap versi aplikasi kontainer Anda.
Karakteristik utama revisi meliputi:
Tidak dapat diubah: Setelah ditetapkan, revisi tetap tidak dapat diubah.
Versi: Revisi bertindak sebagai catatan versi aplikasi kontainer, menangkap statusnya pada berbagai tahap.
Disediakan secara otomatis: Saat Anda menyebarkan aplikasi kontainer untuk pertama kalinya, revisi awal dibuat secara otomatis.
Perubahan tercakup: Meskipun revisi tetap statis, perubahan cakupan aplikasi dapat memengaruhi semua revisi, sementara perubahan cakupan revisi membuat revisi baru.
Catatan historis: Secara default, Anda memiliki akses ke 100 revisi tidak aktif, tetapi Anda dapat menyesuaikan ambang batas ini secara manual.
Beberapa revisi: Anda dapat menjalankan beberapa revisi secara bersamaan. Fitur ini sangat bermanfaat ketika Anda perlu mengelola versi aplikasi yang berbeda secara bersamaan.
Siklus Hidup
Setiap revisi menjalani status tertentu, dipengaruhi oleh status dan ketersediaannya. Selama siklus hidupnya, aplikasi kontainer melewati provisi, berjalan, dan status tidak aktif yang berbeda.
Status provisi
Saat Anda membuat revisi baru, aplikasi kontainer mengalami pemeriksaan startup dan kesiapan. Selama fase ini, status provisi berfungsi sebagai panduan untuk melacak kemajuan aplikasi kontainer.
| Keadaan | Deskripsi |
|---|---|
| Penyediaan | Revisi sedang dalam proses verifikasi. |
| Tersedia | Revisi telah berhasil melewati semua pemeriksaan. |
| Provisi gagal | Revisi mengalami masalah selama verifikasi. |
Status berjalan
Setelah aplikasi kontainer berhasil disediakan, revisi memasuki fase operasinya. Status berjalan membantu memantau kesehatan dan fungsionalitas aplikasi kontainer.
| Keadaan | Deskripsi |
|---|---|
| Penyediaan | Revisi sedang dalam proses verifikasi. |
| Skalakan ke 0 | Tidak ada replika yang berjalan, dan tidak menyediakan replika baru apa pun. Aplikasi kontainer dapat membuat replika baru jika aturan skala dipicu. |
| Mengaktifkan | Tidak ada replika yang berjalan, satu replika sedang disediakan. |
| Aktivasi gagal | Replika pertama gagal disediakan. |
| Penskalakan / Pemrosesan | Penskalaan masuk atau keluar terjadi. Satu atau beberapa replika sedang berjalan, sementara replika lain sedang disediakan. |
| Sedang berjalan | Satu atau beberapa replika sedang berjalan. Tidak ada masalah untuk dilaporkan. |
| Berjalan (maksimal) | Jumlah maksimum replika (sesuai dengan aturan skala revisi) sedang berjalan. Tidak ada masalah untuk dilaporkan. |
| Pencabutan Akses | Revisi beralih dari aktif ke tidak aktif, dan menghapus sumber daya apa pun yang telah dibuatnya. |
| Diturunkan | Setidaknya satu replika dalam revisi dalam keadaan gagal. Lihat detail status yang sedang berjalan untuk masalah tertentu. |
| Gagal | Kesalahan kritis menyebabkan revisi gagal. Status berjalan memberikan detail. Penyebab umumnya meliputi: •Penghentian • Kode keluar 137 |
Status tidak aktif
Revisi juga dapat memasuki status tidak aktif. Revisi ini tidak memiliki provisi atau status berjalan. Namun, Azure Container Apps mempertahankan daftar revisi ini, mengakomodasi hingga 100 entri yang tidak aktif. Anda dapat mengaktifkan revisi kapan saja.
Mengubah batas revisi yang tidak aktif
Anda dapat menggunakan --max-inactive-revisions parameter dengan containerapp create perintah atau containerapp update untuk mengontrol jumlah revisi tidak aktif yang dilacak oleh Container Apps.
Contoh ini menunjukkan cara membuat aplikasi kontainer baru yang melacak 50 revisi tidak aktif:
az containerapp create --max-inactive-revisions 50
Mode revisi
Azure Container Apps mendukung dua mode revisi. Pilihan mode Anda menentukan berapa banyak revisi aplikasi Anda yang aktif secara bersamaan.
| Mode revisi | Deskripsi | Default |
|---|---|---|
| Tunggal | Revisi baru secara otomatis disediakan, diaktifkan, dan diskalakan ke ukuran yang diinginkan. Setelah semua replika berjalan seperti yang didefinisikan oleh aturan skala, lalu lintas dialihkan dari versi lama ke yang baru. Jika pembaruan gagal, lalu lintas tetap mengarah ke revisi lama. Revisi lama secara otomatis dideprovisi. | Ya |
| Beberapa | Anda dapat memiliki beberapa revisi aktif, membagi lalu lintas antar revisi, dan memilih kapan harus membatalkan provisi revisi lama. Tingkat kontrol ini berguna untuk menguji beberapa versi aplikasi, pengujian biru-hijau, atau mengambil kontrol penuh atas pembaruan aplikasi. Lihat pemisahan lalu lintas untuk detail selengkapnya. |
Label
Untuk aplikasi kontainer dengan lalu lintas HTTP eksternal, label mengarahkan lalu lintas ke revisi tertentu. Label menyediakan URL unik yang dapat Anda gunakan untuk merutekan lalu lintas ke revisi yang ditetapkan label.
Untuk mengalihkan lalu lintas antar revisi, Anda dapat memindahkan label dari satu revisi ke revisi lainnya.
- Label menyimpan URL yang sama saat dipindahkan dari satu revisi ke revisi lainnya.
- Label hanya dapat diterapkan ke satu revisi pada satu waktu.
- Alokasi untuk pemisahan lalu lintas tidak diperlukan untuk revisi dengan label.
- Label paling berguna saat aplikasi berada dalam beberapa mode revisi.
- Anda dapat mengaktifkan label, pemisahan lalu lintas, atau keduanya.
Label berguna untuk menguji revisi baru. Misalnya, ketika Anda ingin memberikan akses ke set pengguna uji, Anda dapat memberi mereka URL label. Kemudian ketika Anda ingin memindahkan pengguna Anda ke revisi yang berbeda, Anda dapat memindahkan label ke revisi tersebut.
Label bekerja secara independen dari pemisahan lalu lintas. Pemisahan lalu lintas mendistribusikan lalu lintas yang masuk ke URL aplikasi dari aplikasi kontainer untuk revisi berdasarkan persentase lalu lintas. Saat lalu lintas diarahkan ke URL label, lalu lintas dirutekan ke satu revisi tertentu.
Nama label harus:
- Terdiri dari karakter alfanumerik huruf kecil atau tanda hubung (
-) - Mulai dengan karakter alfabet
- Akhiri dengan karakter alfanumerik
Label tidak boleh:
- Memiliki dua garis putus-putus berturut-turut (
--) - Lebih dari 64 karakter
Anda dapat mengelola label dari halaman Pengelolaan revisi aplikasi penampung di portal Azure.
URL label tersedia di panel detail revisi.
Penyebaran waktu henti nol
Dalam mode revisi tunggal, Container Apps memastikan aplikasi Anda tidak mengalami waktu henti saat membuat revisi baru. Revisi aktif yang ada tidak dinonaktifkan sampai revisi baru siap.
Jika ingress diaktifkan, revisi yang ada terus menerima 100% lalu lintas hingga revisi baru siap.
Revisi baru dianggap siap ketika:
- Revisi telah berhasil disediakan
- Revisi telah ditingkatkan skalanya agar sesuai dengan jumlah replika revisi sebelumnya (sehubungan dengan jumlah replika min dan maks revisi baru)
- Semua replika telah melewati startup dan pemeriksaan kesiapan mereka
Dalam beberapa mode revisi , Anda dapat mengontrol kapan revisi diaktifkan atau dinonaktifkan dan revisi mana yang menerima lalu lintas masuk. Jika aturan pemisahan lalu lintas dikonfigurasi dengan latestRevision diatur ke true, lalu lintas tidak beralih ke revisi terbaru hingga siap.
Bekerja dengan beberapa revisi
Meskipun mode revisi tunggal adalah default, terkadang Anda mungkin ingin memiliki kontrol penuh atas bagaimana revisi Anda dikelola.
Beberapa mode revisi memberi Anda fleksibilitas untuk mengelola revisi Anda secara manual. Misalnya, menggunakan beberapa mode revisi memungkinkan Anda memutuskan dengan tepat berapa banyak lalu lintas yang dialokasikan untuk setiap revisi.
Pemisahan lalu lintas
Diagram berikut menunjukkan aplikasi kontainer dengan dua revisi.
Skenario ini berasumsi aplikasi kontainer berada dalam status berikut:
- Ingress diaktifkan, membuat aplikasi kontainer tersedia melalui HTTP atau TCP.
- Revisi pertama disebarkan sebagai Revisi 1.
- Setelah kontainer diperbarui, revisi baru diaktifkan sebagai Revision 2.
- Aturan Pemisahan lalu lintas dikonfigurasi sehingga Revisi 1 menerima 80% permintaan, dan Revisi 2 menerima 20% sisanya.
Akses revisi langsung
Daripada menggunakan aturan perutean untuk mengalihkan lalu lintas ke revisi, Anda mungkin ingin membuat revisi tersedia untuk permintaan URL tertentu. Beberapa mode revisi dapat memungkinkan Anda mengirim semua permintaan yang masuk ke domain Anda ke revisi terbaru, sementara permintaan untuk revisi yang lebih lama tersedia melalui label untuk akses langsung.
Status aktivasi
Dalam beberapa mode revisi, Anda dapat mengaktifkan atau menonaktifkan revisi sesuai kebutuhan. Revisi aktif beroperasi dan dapat menangani permintaan, sementara revisi yang tidak aktif tetap tidak aktif.
Aplikasi Kontainer tidak mengenakan biaya untuk revisi yang tidak aktif. Namun, ada batas jumlah total revisi yang tersedia, dengan revisi tertua dibersihkan setelah Anda melebihi hitungan 100.
Ubah tipe
Perubahan pada aplikasi penampung termasuk dalam dua kategori: perubahan revisi-lingkup atau aplikasi-lingkup. Perubahan cakupan revisi memicu revisi baru saat Anda menyebarkan aplikasi, sementara perubahan cakupan aplikasi tidak.
Perubahan cakupan revisi
Revisi baru dibuat saat aplikasi penampung diperbarui dengan perubahan cakupan revisi. Perubahan terbatas pada revisi tempat mereka disebarkan, dan tidak memengaruhi revisi lain.
Perubahan cakupan revisi adalah perubahan apa pun pada parameter di bagian properties.template template sumber daya aplikasi kontainer.
Parameter ini meliputi:
- Akhiran revisi
- Konfigurasi dan gambar kontainer
- Aturan skala untuk aplikasi kontainer
Perubahan cakupan aplikasi
Saat Anda menyebarkan aplikasi kontainer dengan perubahan cakupan aplikasi:
- Perubahan diterapkan secara global ke semua revisi.
- Revisi baru tidak dibuat.
Perubahan cakupan aplikasi didefinisikan sebagai perubahan apa pun pada parameter di bagian properties.configuration template sumber daya aplikasi kontainer.
Parameter ini meliputi:
- Nilai rahasia (revisi harus dimulai ulang sebelum kontainer mengenali nilai rahasia baru)
- Mode revisi
- Konfigurasi Ingress termasuk:
- Mengaktifkan atau menonaktifkan ingress
- Aturan pemisahan lalu lintas
- Label
- Kredensial untuk registri kontainer privat
- Pengaturan Dapr
Menyesuaikan revisi
Anda dapat menyesuaikan nama dan label revisi agar lebih selaras dengan konvensi penamaan atau strategi penerapan versi Anda.
Akhiran nama
Setiap revisi di Container Apps diberi pengidentifikasi unik. Saat nama dibuat secara otomatis, Anda dapat mempersonalisasi nama revisi.
Format umum untuk nama revisi adalah:
<CONTAINER_APP_NAME>-<REVISION_SUFFIX>
Misalnya, jika Anda memiliki aplikasi kontainer bernama album-api dan memutuskan akhiran revisi pertama, nama revisi lengkap menjadi album-api-first-revisi.
Nama akhiran revisi harus:
- Hanya terdiri dari karakter alfanumerik huruf kecil atau tanda hubung (
-) - Mulai dengan karakter alfabet
- Akhiri dengan karakter alfanumerik
Nama tidak boleh memiliki:
- Dua tanda hudah berturut-turut (
--) - Lebih dari 64 karakter
Anda dapat mengatur akhiran revisi di template ARM, melalui Azure CLI az containerapp create dan az containerapp update perintah, atau saat membuat revisi melalui portal Azure.
Kasus penggunaan
Berikut ini adalah kasus penggunaan umum untuk menggunakan revisi di aplikasi kontainer. Daftar ini bukan daftar lengkap tujuan atau kemampuan menggunakan revisi Container Apps.
Pengelolaan rilis
Revisi menyederhanakan proses memperkenalkan versi baru aplikasi Anda. Saat Anda siap untuk meluncurkan pembaruan atau fitur baru, Anda dapat membuat revisi baru tanpa memengaruhi versi langsung saat ini. Pendekatan ini memastikan transisi yang lancar dan meminimalkan gangguan bagi pengguna akhir.
Kembali ke versi sebelumnya
Terkadang Anda perlu dengan cepat kembali ke versi aplikasi yang stabil sebelumnya. Anda dapat mengembalikan ke revisi sebelumnya dari aplikasi kontainer Anda jika perlu.
Pengujian A/B
Saat Anda ingin menguji berbagai versi aplikasi, revisi dapat mendukung pengujian A/B. Anda dapat merutekan subset pengguna Anda ke revisi baru, mengumpulkan umpan balik, dan membuat keputusan berdasarkan data dunia nyata.
Penyebaran biru-hijau
Revisi mendukung strategi penyebaran biru-hijau. Dengan memiliki dua revisi paralel (biru untuk versi langsung dan hijau untuk yang baru), Anda dapat secara bertahap fase dalam revisi baru. Setelah yakin dengan stabilitas dan performa versi baru, Anda dapat mengalihkan lalu lintas sepenuhnya ke lingkungan hijau.