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.
Catatan
Paket Basic, Standard, dan Enterprise memasuki periode pensiun pada 17 Maret 2025. Untuk informasi selengkapnya, lihat pengumuman penghentian Azure Spring Apps.
Artikel ini berlaku untuk:✅ Basic/Standard ✅ Enterprise
Artikel ini menjelaskan dukungan penyebaran biru-hijau di Azure Spring Apps.
Azure Spring Apps (paket Standar dan yang lebih tinggi) mengizinkan dua penyebaran untuk setiap aplikasi, hanya satu di antaranya yang menerima lalu lintas produksi. Pola ini umumnya dikenal sebagai penyebaran biru-hijau. Dukungan Azure Spring Apps untuk penyebaran biru-hijau, bersama dengan alur Pengiriman Berkelanjutan (CD) dan pengujian otomatis yang ketat, memungkinkan penyebaran aplikasi yang tangkas dengan kepercayaan diri tinggi.
Penyebaran bergantian
Cara paling sederhana untuk menerapkan penyebaran biru-hijau dengan Azure Spring Apps adalah dengan membuat dua penyebaran tetap dan selalu sebarkan ke penyebaran yang tidak menerima lalu lintas produksi. Dengan tugas Azure Spring Apps untuk Azure Pipelines, Anda dapat melakukan penerapan dengan cara ini hanya dengan mengatur parameter UseStagingDeployment ke true.
Berikut cara kerja pendekatan penyebaran bergantian dalam praktik:
Misalkan aplikasi Anda memiliki dua penyebaran: deployment1 dan deployment2. Saat ini, deployment1 ditetapkan sebagai penyebaran produksi, dan menjalankan versi v3 aplikasi.
Ini menjadikan deployment2 sebagai tahap deploy. Jadi, ketika alur Continuous Delivery (CD) siap dijalankan, sistem tersebut akan menerapkan versi berikutnya dari aplikasi, versi v4, ke lingkungan staging deployment2.
Setelah v4 diaktifkan di deployment2, Anda dapat menjalankan pengujian otomatis dan manual terhadapnya melalui titik akhir tes privat untuk memastikan v4 memenuhi semua harapan.
Ketika Anda memiliki keyakinan terhadap v4, Anda dapat menetapkan deployment2 sebagai penyebaran produksi sehingga menerima semua trafik produksi.
v3 akan tetap berjalan di deployment1 apabila Anda menemukan masalah kritis yang mengharuskan mengembalikan.
Diagram yang menunjukkan V4 pada deployment2 menerima lalu lintas produksi.
Sekarang, deployment1 adalah penyebaran tahap pengujian. Jadi jalan berikutnya dari penyebaran alur menyebar ke deployment1.
Anda sekarang dapat menguji V5 pada titik akhir privat untuk pengujian deployment1.
Akhirnya, setelah v5 memenuhi semua harapan, Anda menetapkan deployment1 sebagai penyebaran produksi sekali lagi, sehingga v5 menerima semua lalu lintas produksi.
Kompromi dari pendekatan penerapan secara bergantian
Pendekatan penyebaran bergantian sederhana dan cepat, karena tidak memerlukan pembuatan penyebaran baru. Namun, itu memang menyajikan beberapa kelemahan, seperti yang dijelaskan di bagian berikut.
Penyebaran penahapan persisten
Penyebaran penahapan selalu tetap berjalan, sehingga mengonsumsi sumber daya instans Azure Spring Apps. Ini secara efektif menggandakan persyaratan sumber daya dari setiap aplikasi di Azure Spring Apps.
Kondisi perlombaan persetujuan
Misalkan dalam aplikasi di atas, alur rilis memerlukan persetujuan manual sebelum setiap versi baru aplikasi dapat menerima lalu lintas produksi. Ini menciptakan risiko bahwa sementara satu versi (v6) menunggu persetujuan manual pada penyebaran tahap, pipeline penyebaran akan berjalan lagi dan menggantinya dengan versi yang lebih baru (v7). Kemudian, ketika persetujuan v6 diberikan, alur yang digunakan v6 akan menetapkan penyebaran penahapan sebagai produksi. Tapi sekarang akan menjadi yang tidak disetujui v7, bukan disetujui v6, yang digunakan pada penyebaran itu dan menerima lalu lintas.
Anda mungkin dapat mencegah kondisi balapan dengan memastikan bahwa aliran penyebaran untuk satu versi tidak dapat dimulai hingga alur penyebaran untuk semua versi sebelumnya selesai atau dibatalkan. Cara lain untuk mencegah kondisi balapan persetujuan adalah dengan menggunakan pendekatan "Named Deployments" yang dijelaskan di bawah ini.
Penamaan Penyebaran
Dalam pendekatan penyebaran bernama, penyebaran baru dibuat untuk setiap versi baru aplikasi yang sedang digunakan. Setelah aplikasi diuji pada penyebaran khusus, penyebaran tersebut diset sebagai penyebaran produksi. Penyebaran yang berisi versi sebelumnya dapat diizinkan untuk bertahan cukup lama untuk yakin bahwa pembatalan tidak akan diperlukan.
Dalam ilustrasi di bawah ini, versi v5 berjalan pada penyebaran deployment-v5. Nama penyebaran sekarang berisi versi karena penyebaran dibuat khusus untuk versi ini. Tidak ada penyebaran lain pada awalnya. Sekarang, untuk menerapkan versiv6, alur penyebaran membuat penyebaran barudeployment-v6 dan menerapkan versi aplikasi v6 di sana.
Diagram yang memperlihatkan penerapan versi baru pada penempatan yang telah diberi nama seperti yang dijelaskan di bagian ini.
Tidak ada risiko versi lain yang digunakan secara paralel. Pertama, Azure Spring Apps tidak mengizinkan pembuatan penyebaran ketiga sementara dua penyebaran sudah ada. Kedua, bahkan jika mungkin memiliki lebih dari dua penyebaran, setiap penyebaran diidentifikasi oleh versi aplikasi yang dikandungnya. Dengan demikian, alur yang mengorkestrasi penyebaran v6 hanya akan berupaya menetapkan deployment-v6 sebagai penyebaran produksi.
Setelah penyebaran yang dibuat untuk versi baru menerima lalu lintas produksi, Anda harus menghapus penyebaran yang berisi versi sebelumnya untuk memberi ruang bagi penyebaran di masa mendatang. Anda mungkin ingin menunda dengan beberapa menit atau jam sehingga Anda dapat kembali ke versi sebelumnya jika Anda menemukan masalah penting dalam versi baru.
Kompromi dari pendekatan penyebaran teridentifikasi
Pendekatan penyebaran bernama memiliki manfaat berikut:
- Ini mencegah kondisi persaingan persetujuan.
- Ini mengurangi konsumsi sumber daya dengan menghapus penyebaran penahapan ketika tidak digunakan.
Namun, ada kelemahan juga, seperti yang dijelaskan di bagian berikut.
Kegagalan jalur proses penyebaran
Antara waktu penyebaran dimulai hingga saat penahapan penyebaran dihapus, setiap upaya tambahan untuk menjalankan pipeline penyebaran akan gagal. Alur akan mencoba membuat penyebaran baru, yang akan mengakibatkan kesalahan karena hanya dua penyebaran yang diizinkan per aplikasi di Azure Spring Apps.
Oleh karena itu, orkestrasi penyebaran harus memiliki sarana untuk mencoba kembali proses penyebaran yang gagal di lain waktu, atau sarana untuk memastikan bahwa aliran penyebaran untuk setiap versi akan terus mengantri hingga alur selesai untuk semua versi sebelumnya.