Republish yang Gagal Tidak Pernah Memadam Backend yang Berfungsi

Pada 25 September, republish yang gagal telah memadamkan backend sesebuah aplikasi yang sudah live dan berfungsi selama kira-kira dua setengah jam. Kod yang membatalkan publish yang gagal itu memadamkan setiap aplikasi pelayan yang disentuh oleh publish tersebut, termasuk yang sudah pun berjalan sebelum publish itu bermula. Kini, hanya aplikasi yang dicipta oleh publish sahaja akan dipadam. Aplikasi yang sudah sedia ada akan dikembalikan tepat kepada versi yang dijalankannya sebelum itu. Dua pembetulan susulan pada hari yang sama memastikan pembatalan juga berjalan apabila alat deploy platform hosting itu sendiri gagal, dan memastikan aplikasi yang sihat tidak ditandakan gagal hanya kerana ia sedang tidur.

Cara backend diterbitkan

Apabila aplikasi Mythex anda mempunyai backend, iaitu API atau pelayan dan bukan sekadar fail statik, publish akan membina daripada Dockerfile (resipi untuk membungkus aplikasi ke dalam imej) dan melancarkan imej itu ke mesin di platform hosting kami. Kemudian health check menunggu versi baharu benar-benar bangkit dan kekal berjalan sebelum publish ditandakan live.

Jika apa-apa gagal di sepanjang proses itu, rollback akan dijalankan untuk membatalkannya. Membetulkan rollback ini lebih penting daripada hampir apa sahaja lain dalam penerbitan, kerana ia berjalan tepat pada saat ada sesuatu yang sudah tidak kena.

Masalah 1: rollback memadam apa yang sepatutnya dipulihkan

Rollback menyimpan senarai aplikasi pelayan yang disasarkan oleh publish, dan apabila gagal, ia memusnahkan setiap satu daripadanya. Itu betul untuk publish pertama: aplikasi itu baru sahaja dicipta, tiada apa yang bergantung padanya, dan memadamnya membiarkan keadaan seperti sediakala.

Ia betul-betul salah untuk republish. Aplikasi itu sudah wujud dan sedang melayani pelawat sebenar. Pada 25 September, API sebuah aplikasi yang sudah live selama kira-kira dua setengah jam telah dipadam oleh republish yang gagal.

Ada satu lagi mod kegagalan yang tersembunyi dalam kod yang sama. Jika pemadaman tidak berjaya, imej baharu yang rosak kekal di mesin, sedangkan kami memberitahu pemilik bahawa laman semasa mereka masih live. Pada masa health check boleh gagal, imej baharu itu sudah pun dilancarkan ke setiap mesin. Tidak membuat apa-apa tidak sama dengan membatalkan.

Pembetulan: padam hanya apa yang anda cipta, pulihkan yang lain

Setiap publish kini merekodkan, untuk setiap aplikasi pelayan yang disentuhnya:

• sama ada publish ini yang mencipta aplikasi itu, dan
• jika tidak, imej yang sedang dijalankannya sejurus sebelum itu.

Apabila gagal, setiap aplikasi menerima salah satu daripada tiga layanan:

1. Dicipta oleh publish ini: musnahkan, seperti sebelum ini.
2. Sudah wujud, imej sebelumnya diketahui: lancarkan semula imej sebelumnya dengan konfigurasi yang sama. Tiada build, hanya imej yang dikembalikan.
3. Sudah wujud, imej sebelumnya tidak diketahui: biarkan begitu sahaja. Aplikasi sedia ada tidak akan sekali-kali dipadam, walaupun kami tidak dapat memulihkannya.

Peraturan ini ialah fungsi kecil yang tulen dengan ujiannya sendiri, supaya keputusan itu tidak kembali kepada “musnahkan semua” tanpa ujian gagal.

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

Tidak lama selepas pembetulan itu, kami menemui jurang di dalamnya. Alat deploy platform hosting menjalankan semakan asapnya sendiri: jika mesin baharu ranap, ia keluar dengan ralat. Tetapi ia melakukannya selepas imej baharu sudah pun berada di mesin.

Kod kami hanya mendaftarkan aplikasi untuk rollback selepas alat itu memulangkan kejayaan. Apabila alat itu sendiri yang menggagalkan deploy, aplikasi belum berada dalam senarai rollback, jadi tiada apa yang dipulihkan. Di persekitaran staging kami, republish yang rosak meninggalkan imej yang rosak terus melayani pelawat.

Pembetulan: daftarkan cara membatalkan sebelum bermula

Aplikasi kini didaftarkan untuk rollback, dengan maklumat sama ada ia dicipta dan imej apa yang dijalankannya, sebaik sahaja ia disediakan dan sebelum apa-apa dilancarkan ke atasnya. Apa sahaja yang gagal selepas itu, rollback sudah tahu apa yang perlu dikembalikan. Kami mengesahkannya secara tempatan: republish yang rosak gagal dalam semakan asap alat deploy itu sendiri, dan versi sebelumnya terus menjawab permintaan.

Masalah 3: aplikasi yang sedang tidur ditandakan gagal sebagai “tidak pernah bermula”

Aplikasi terbit di Mythex tidur apabila tidak digunakan untuk menjimatkan kredit anda. Republish meninggalkan mesin yang tidur dalam keadaan berhenti, jadi health check perlu mengejutkannya. Ia meminta platform memulakan mesin itu sekali sahaja, dan mengabaikan jawapannya.

Pada 25 September, permintaan mula tunggal itu tidak sampai ke mana-mana. API yang sihat kekal berhenti sepanjang health check lima minit penuh, lalu ditandakan gagal dengan mesej “1 machine never started (last state: stopped)”.

Platform kadang-kadang menolak permintaan mula. Semasa mengulang semula masalah ini, ia memulangkan konflik “lease currently held” tanpa kami mencetuskannya, dan ia menolak permulaan apabila mesin sedang dikemas kini.

Pembetulan: terus meminta, dan ketuk pintu

Health check kini:

• meminta semula supaya mesin yang berhenti dimulakan setiap 20 saat semasa ia menunggu,
• mencatat apa yang dijawab oleh platform apabila ia menolak, dan
• menghantar satu permintaan biasa kepada aplikasi, sama seperti yang dilakukan pelawat. Proksi platform akan mengejutkan mesin yang tidur apabila permintaan tiba.

Kami mengulang semula ini pada platform sebenar dengan aplikasi ujian sementara yang permulaan pertamanya ditolak. Sebelum pembetulan, publish gagal selepas 91 saat. Selepas pembetulan, ia diterbitkan dalam 20 saat. Aplikasi yang benar-benar ranap semasa boot tetap akan gagal, seperti yang sepatutnya.

Apa yang kami pelajari daripadanya

• Rollback mesti tahu beza antara yang baharu dan yang sedia ada. “Batal” untuk sesuatu yang anda cipta bermaksud padam. “Batal” untuk sesuatu yang sudah sedia ada bermaksud pulihkan. Melayan kedua-duanya sama ialah cara mekanisme keselamatan memadam aplikasi yang berfungsi.
• Tulis cara membatalkan sebelum bertindak. Jika pembatalan hanya direkodkan selepas satu langkah berjaya, langkah yang gagal di tengah jalan tidak meninggalkan apa-apa untuk dibatalkan.
• Jangan sekali-kali abaikan jawapan kepada permintaan yang anda bergantung padanya. Satu “tidak” yang diabaikan telah menukar aplikasi yang sihat menjadi publish yang gagal.

Pembetulan berkaitan dari hari yang sama: menangkap aplikasi yang ranap sejurus selepas publish. Untuk apa yang berlaku apabila publish gagal di pihak anda, lihat penyelesaian masalah publish dalam dokumentasi.