Strategi penyebaran biru-hijau di Azure Spring Apps
Catatan
Azure Spring Apps adalah nama baru untuk layanan Azure Spring Cloud. Meskipun layanan memiliki nama baru, Anda akan melihat nama lama di beberapa tempat untuk sementara saat kami berupaya memperbarui aset seperti cuplikan layar, video, dan diagram.
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 menyebarkan cara ini hanya dengan mengatur bendera 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 membuat deployment2 penyebaran penahapan. Jadi, ketika alur Continuous Delivery (CD) siap dijalankan, ia menerapkan versi berikutnya dari aplikasi, versi v4, ke penyebaran penahapan deployment2.
Setelah v4 memulai deployment2, Anda dapat menjalankan pengujian otomatis dan manual terhadapnya melalui titik akhir tes privat untuk memastikan v4 memenuhi semua harapan.
Ketika Anda memiliki kepercayaan diri v4, Anda dapat menetapkan deployment2 sebagai penyebaran produksi sehingga menerima semua lalu lintas produksi. v3 akan tetap berjalan deployment1 jika Anda menemukan masalah kritis yang mengharuskan bergulir kembali.
Sekarang, deployment1 adalah penyebaran penahapan. Jadi jalan berikutnya dari penyebaran alur menyebar ke deployment1.
Anda sekarang dapat menguji V5 pada deployment1 titik akhir tes privat.
Akhirnya, setelah v5 memenuhi semua harapan, Anda menetapkan deployment1 sebagai penyebaran produksi sekali lagi, sehingga v5 menerima semua lalu lintas produksi.
Pertukaran dari pendekatan penyebaran 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 penahapan, alur penyebaran akan berjalan lagi dan menimpanya 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 perlombaan persetujuan adalah dengan menggunakan pendekatan Penyebaran Bernama yang dijelaskan di bawah ini.
Penyebaran bernama
Dalam pendekatan penyebaran bernama, penyebaran baru dibuat untuk setiap versi baru aplikasi yang sedang digunakan. Setelah aplikasi diuji pada penyebaran yang dipesan lebih dahulu, penyebaran tersebut ditetapkan 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.
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 mengatur penyebaran v6 hanya akan mencoba untuk ditetapkan 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.
Pertukaran dari pendekatan penyebaran bernama
Pendekatan penyebaran bernama memiliki manfaat berikut:
- Ini mencegah kondisi perlombaan persetujuan.
- Ini mengurangi konsumsi sumber daya dengan menghapus penyebaran penahapan ketika tidak digunakan.
Namun, ada kelemahan juga, seperti yang dijelaskan di bagian berikut.
Kegagalan alur penyebaran
Antara waktu penyebaran dimulai dan waktu penyebaran penahapan dihapus, setiap upaya tambahan untuk menjalankan alur 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 penyebaran mengalir untuk setiap versi akan tetap mengantri sampai alur selesai untuk semua versi sebelumnya.