Republish yang Gagal Tidak Pernah Menghapus Backend yang Berfungsi

Pada 25 September, sebuah republish yang gagal menghapus backend sebuah aplikasi yang sudah live dan berfungsi sekitar dua setengah jam. Kode yang membatalkan publish yang gagal menghapus setiap aplikasi server yang disentuh publish tersebut, termasuk yang sudah melayani sebelum publish dimulai. Sekarang hanya aplikasi yang dibuat oleh sebuah publish yang boleh dihapus; aplikasi yang sudah ada dikembalikan ke versi persis yang dijalankannya sebelumnya. Dua perbaikan lanjutan di hari yang sama memastikan pembatalan juga berjalan saat alat deploy milik platform hosting gagal, dan bahwa aplikasi yang sehat tidak dinyatakan gagal hanya karena sedang tidur.

Bagaimana backend dipublikasikan

Ketika aplikasi Mythex Anda punya backend, yaitu API atau server, bukan sekadar file statis, publish membangunnya dari Dockerfile (resep untuk mengemas aplikasi menjadi image) dan menggulirkan image itu ke mesin-mesin di platform hosting kami. Lalu health check menunggu versi baru benar-benar naik dan tetap berjalan sebelum publish ditandai live.

Jika ada yang gagal di tengah jalan, rollback dijalankan untuk membatalkannya. Membuat rollback ini benar justru paling penting dalam publishing, karena ia berjalan tepat ketika ada sesuatu yang sudah salah.

Masalah 1: rollback menghapus apa yang seharusnya dipulihkan

Rollback menyimpan daftar aplikasi server yang telah di-deploy oleh sebuah publish, dan saat gagal, menghancurkan semuanya. Itu benar untuk publish pertama: aplikasinya baru dibuat beberapa saat sebelumnya, tidak ada yang bergantung padanya, dan menghapusnya membuat keadaan kembali seperti semula.

Ini justru salah untuk republish. Aplikasinya sudah ada dan melayani pengunjung sungguhan. Pada 25 September, API sebuah aplikasi yang sudah live sekitar dua setengah jam dihapus oleh republish yang gagal.

Ada mode kegagalan kedua yang tersembunyi di kode yang sama. Ketika penghapusan tidak berhasil, image baru yang rusak tetap berada di mesin-mesin, sementara kami memberi tahu pemilik bahwa situs mereka masih live. Pada saat health check bisa gagal, image baru sudah digulirkan ke setiap mesin. Tidak melakukan apa-apa tidak sama dengan membatalkan.

Perbaikan: hapus hanya yang Anda buat, pulihkan sisanya

Setiap publish sekarang mencatat, untuk setiap aplikasi server yang disentuhnya:

• apakah publish ini membuatnya, dan
• jika tidak, image mana yang dijalankannya tepat sebelum publish.

Saat gagal, setiap aplikasi mendapat salah satu dari tiga perlakuan:

1. Dibuat oleh publish ini: hapus, seperti sebelumnya.
2. Sudah ada, image sebelumnya diketahui: deploy ulang image sebelumnya dengan konfigurasi yang sama. Tanpa build; hanya image yang dikembalikan.
3. Sudah ada, image sebelumnya tidak diketahui: biarkan saja. Aplikasi yang sudah ada tidak pernah dihapus, bahkan ketika kami tidak bisa memulihkannya.

Aturan ini adalah fungsi murni kecil dengan pengujiannya sendiri, sehingga keputusan tidak bisa kembali menjadi “hapus semuanya” tanpa ada tes yang gagal.

Masalah 2: alat deploy bisa gagal sebelum kami mencatat cara membatalkannya

Tak lama setelah perbaikan itu, kami menemukan celah di dalamnya. Alat deploy milik platform hosting menjalankan smoke check sendiri: jika mesin baru crash, ia keluar dengan error. Tetapi itu terjadi setelah image baru sudah berada di mesin.

Kode kami baru mendaftarkan aplikasi untuk rollback setelah alat itu mengembalikan sukses. Ketika alatnya sendiri yang menggagalkan deploy, aplikasi belum ada di daftar rollback, sehingga tidak ada yang dipulihkan. Di lingkungan staging kami, republish yang rusak membiarkan image yang rusak tetap melayani.

Perbaikan: daftarkan cara membatalkan sebelum mulai

Aplikasi sekarang didaftarkan untuk rollback, dengan catatan apakah ia dibuat dan image apa yang dijalankannya, segera setelah ia disiapkan dan sebelum apa pun digulirkan ke sana. Apa pun yang gagal sesudahnya, rollback sudah tahu apa yang harus dikembalikan. Kami memverifikasinya secara lokal: republish yang rusak gagal di smoke check milik alat deploy, dan versi sebelumnya tetap menjawab.

Masalah 3: aplikasi yang sedang tidur dinyatakan gagal “tidak pernah mulai”

Aplikasi yang dipublikasikan di Mythex tidur saat menganggur untuk menghemat kredit Anda. Republish meninggalkan mesin yang tidur dalam keadaan berhenti, sehingga health check harus membangunkannya. Health check hanya meminta platform untuk menyalakan mesin sekali, dan mengabaikan jawabannya.

Pada 25 September, satu permintaan nyala itu tidak sampai ke mana pun. API yang sehat tetap berhenti selama lima menit penuh health check dan dinyatakan gagal dengan “1 machine never started (last state: stopped)”.

Platform memang kadang menolak permintaan nyala. Saat kami mereproduksi masalah ini, platform mengembalikan konflik “lease currently held” tanpa kami picu, dan platform menolak permintaan nyala selama mesin sedang diperbarui.

Perbaikan: terus meminta, dan ketuk pintunya

Health check sekarang:

• meminta lagi untuk menyalakan mesin yang berhenti setiap 20 detik selama menunggu,
• mencatat apa yang dijawab platform ketika menolak, dan
• mengirim satu permintaan biasa ke aplikasi, seperti yang dilakukan pengunjung; proxy platform akan membangunkan mesin yang tidur ketika permintaan masuk.

Kami mereproduksinya di platform sungguhan dengan aplikasi sekali pakai yang permintaan nyala pertamanya ditolak. Sebelum perbaikan, publish gagal setelah 91 detik. Setelah perbaikan, publish berhasil dalam 20 detik. Aplikasi yang memang crash saat boot tetap gagal, seperti seharusnya.

Yang kami pelajari

• Rollback harus tahu bedanya antara yang baru dan yang sudah ada. “Batalkan” untuk sesuatu yang Anda buat berarti hapus. “Batalkan” untuk sesuatu yang sudah ada berarti pulihkan. Memperlakukannya sama adalah cara mekanisme keselamatan menghapus aplikasi yang berfungsi.
• Catat cara membatalkan sebelum Anda bertindak. Jika pembatalan hanya dicatat setelah sebuah langkah berhasil, langkah yang gagal di tengah jalan tidak meninggalkan apa pun untuk dibatalkan.
• Jangan pernah mengabaikan jawaban atas permintaan yang Anda andalkan. Satu “tidak” yang diabaikan mengubah aplikasi yang sehat menjadi publish yang gagal.

Perbaikan terkait dari hari yang sama: menangkap aplikasi yang crash tepat setelah dipublikasikan. Untuk apa yang terjadi ketika publish gagal di sisi Anda, lihat pemecahan masalah publish di dokumentasi.