Deploy Tanpa Henti untuk Aplikasi CFML

Deploy Tanpa Henti untuk Aplikasi CFML

Penulis: Thalhah · Tarikh: 16 Oktober 2026

Deploy tanpa henti bermaksud mengemas kini aplikasi CFML tanpa masa laman turun yang boleh dilihat pengguna. Kuncinya ialah mengelak memulakan semula JVM sebagai satu-satunya mekanisme deploy, dan menggantikan direktori kod secara atomik. Artikel ini menerangkan strategi, turutan deploy, dan pelan undur.

Kenapa Restart JVM Bermakna Laman Turun

Apabila JVM dimulakan semula, Lucee perlu menyusun semula template, memuatkan konfigurasi dan memanaskan semula cache sebelum ia melayan permintaan dengan pantas. Semasa tempoh itu, permintaan sama ada gagal atau perlahan dengan ketara. Lucee menyediakan pemanasan awal melalui LUCEE_ENABLE_WARMUP, yang membuat Lucee melakukan deploy sendiri termasuk memproses fail dalam folder /deploy, kemudian keluar. Imej Docker rasmi sudah dipanaskan terlebih dahulu.

Walaupun dengan pemanasan awal, memulakan semula JVM untuk setiap kemas kini kecil ialah cara yang mahal. Strategi tanpa henti bertujuan meminimumkan bilangan restart dan menjadikan setiap restart sependek mungkin, atau menghapuskannya sama sekali. Malah restart yang pantas mengambil masa beberapa saat untuk Lucee menyusun semula template, dan untuk laman dengan trafik tinggi, setiap saat turun bermakna transaksi yang hilang.

Strategi Mengurangkan Tempoh Mati

Strategi paling mudah ialah deploy ke direktori baharu, kemudian tukar pautan simbolik secara atomik. Anda menyediakan folder release baharu sepenuhnya, menjalankan sebarang penyediaan, kemudian menukar pautan current kepada release itu dalam satu operasi:

cd /var/www
cp -r release-2026-10-16.baru release-2026-10-16
ln -sfn release-2026-10-16 current

Operasi tukar pautan simbolik ialah satu arahan atomik, jadi pada bila-bila masa pautan current menunjuk kepada release yang lengkap. Untuk aplikasi berbilang pelayan, gunakan dua slot: satu slot aktif melayan trafik sementara slot lain dikemas kini, kemudian tukar pengimbang beban antara keduanya. Ini menghapuskan masa mati sepenuhnya kerana sentiasa ada satu slot yang hidup.

Deploy dengan Folder /deploy Lucee

Lucee menyediakan mekanisme kemas kini tanpa restart melalui folder /deploy di bawah /lucee-server/. Folder ini disemak pada permulaan dan setiap 60 saat oleh utas pengawal Lucee, yang mencari fail .lex (sambungan), .lco (kemas kini teras) dan .json (coretan konfigurasi). Ini ialah cara paling mudah untuk memasang sambungan atau mengemas kini konfigurasi semasa pelayan berjalan.

Import konfigurasi adalah aditif, jadi anda boleh menghantar coretan kecil tambahan seperti pemetaan atau sambungan dan bukannya keseluruhan konfigurasi. Fungsi ConfigImport() menggunakan laluan kod yang sama. Ini membolehkan anda mengemas kini tetapan tanpa menyentuh JVM, satu lagi cara mengurangkan tempoh mati. Gunakan mekanisme ini untuk perubahan kecil seperti tetapan caching atau sambungan baharu, dan simpan restart JVM untuk perubahan yang benar-benar memerlukannya.

Zero Downtime dalam Docker

Dalam Docker, strategi dua slot menjadi mudah kerana bekas boleh diganti serta-merta. Bina imej baharu, jalankan bekas baharu di samping bekas lama, sahkan ia sihat, kemudian alihkan trafik dengan memetakan semula port atau menukar sasaran proksi terbalik. Imej rasmi Lucee menyokong pemanasan awal semasa binaan melalui LUCEE_BUILD, yang menjalankan fungsi onBuild dalam Server.cfc untuk tugas persediaan seperti mengesahkan konfigurasi dan menyusun sumber. Ini memendekkan masa yang diambil bekas baharu untuk menjadi panas selepas ia mula.

Sesi dan Skop Aplikasi Semasa Deploy

Satu faedah mengelak restart JVM ialah sesi dan skop aplikasi kekal hidup. Secara lalai, pemboleh ubah sesi dan aplikasi disimpan dalam memori, jadi memulakan semula JVM memadamkannya dan memaksa semua pengguna log masuk semula. Dengan strategi tukar pautan simbolik atau dua slot, JVM tidak dimulakan semula, jadi pengguna yang sedang log masuk kekal log masuk merentasi deploy. Jika anda terpaksa restart, pindahkan penyimpanan sesi ke storan berterusan supaya sesi tidak hilang.

Mengelak Cache Stale

Selepas deploy, cache lama boleh melayan template atau query yang sudah basi. Lucee menyusun template yang berubah kepada kelas Java baharu, dan tetapan template cache mengawal bagaimana ia menyemak fail yang berubah. Selepas deploy, paksa penyemakan semula dan kosongkan cache yang berkaitan supaya pengguna tidak melihat data lama. Rujuk panduan caching dan prestasi untuk butiran cacheClear dan pagePoolClear. Uji halaman yang bergantung pada cache selepas deploy untuk memastikan pengguna melihat data baharu dan bukannya salinan lama.

Aturan Turutan Deploy

Turutan deploy penting kerana kod dan pangkalan data mesti serasi pada setiap saat. Deploy kod dahulu, kemudian jalankan migrasi pangkalan data, kemudian muat semula cache atau konfigurasi. Migrasi pangkalan data yang mengubah skema mesti serasi dengan kod lama dan baharu pada masa yang sama, kerana permintaan lama mungkin masih berjalan semasa migrasi. Pendekatan selamat ialah menjalankan migrasi yang aditif dahulu, deploy kod baharu, kemudian buang lajur atau jadual lama dalam migrasi susulan.

Migrasi Pangkalan Data Tanpa Mengunci Aplikasi

Migrasi yang mengunci jadual menghentikan aplikasi sama seperti restart. Gunakan migrasi berperingkat: tambah lajur baharu dahulu tanpa mengubah jadual sedia ada, deploy kod yang membaca kedua-dua skema, kemudian buang lajur lama dalam langkah berasingan. Ini membolehkan kod lama dan baharu wujud serentak tanpa konflik, dan menjadikan undur lebih selamat kerana tiada langkah yang memusnahkan data yang tidak boleh dibatalkan.

Menguji di Pementasan Sebelum Pengeluaran

Jangan uji deploy buat kali pertama pada pengeluaran. Jalankan keseluruhan urutan deploy pada persekitaran pementasan yang menyerupai pengeluaran, termasuk migrasi pangkalan data dan pemanasan cache. Ini mendedahkan masalah seperti kod yang bergantung pada konfigurasi yang belum dikemas kini, atau migrasi yang mengambil masa terlalu lama. Hanya selepas urutan berjaya pada pementasan, jalankan pada pengeluaran dengan keyakinan bahawa pelan undur anda berfungsi. Pementasan yang berbeza daripada pengeluaran memberi keyakinan palsu, jadi usahakan persekitaran pementasan sehampir mungkin dengan pengeluaran dari segi data dan konfigurasi.

Deploy Berperingkat (Canary)

Untuk aplikasi kritikal, pertimbangkan deploy berperingkat: alihkan hanya sebahagian kecil trafik kepada release baharu, pantau kadar ralat dan masa respons, kemudian tingkatkan peratusan secara beransur-ansur. Ini mengehadkan kerosakan jika release baharu bermasalah kepada sebahagian kecil pengguna dan bukannya semua. Ia memerlukan proksi terbalik yang mampu menimbang trafik, tetapi kosnya berbaloi untuk aplikasi yang tidak boleh turun langsung.

Ujian Asap Automatik Selepas Deploy

Senarai semak manual mudah terlepas pada tengah malam, jadi automatikkan ujian asap. Selepas pautan ditukar, jalankan skrip yang meminta halaman kritikal dan semak kod respons serta kandungan yang dijangka. Jika ujian gagal, skrip itu sendiri boleh mencetuskan undur automatik dengan menukar pautan kembali. Ini menukar deploy daripada acara yang memerlukan perhatian manusia penuh kepada proses yang mengesahkan dirinya sendiri dalam beberapa saat.

Pelan Undur

Setiap deploy perlu pelan undur yang boleh dilaksanakan dalam beberapa minit. Dengan strategi direktori dan pautan simbolik, undur bermakna menukar pautan kembali ke release sebelumnya:

ln -sfn release-2026-10-15 current

Simpan sekurang-kurangnya satu release sebelumnya, dan pastikan migrasi pangkalan data boleh diputar balik atau sekurang-kurangnya tidak mematahkan versi lama. Uji pelan undur sebelum ia diperlukan, bukan semasa insiden. Sandaran penuh sebelum deploy dibincangkan dalam panduan sandaran dan pemulihan.

Senarai Semak Selepas Deploy

Selepas setiap deploy, sahkan kesihatan aplikasi sebelum mengisytiharkan kejayaan:

Sambungkan strategi ini dengan panduan Git untuk projek CFML supaya release boleh dijejak, dan panduan NGINX di hadapan Lucee untuk pengimbangan beban antara slot.

Soalan Lazim (FAQ)

Kenapa restart JVM menyebabkan laman turun?

Kerana Lucee perlu menyusun semula template dan memanaskan cache selepas restart, jadi permintaan gagal atau perlahan semasa tempoh itu.

Bagaimana cara deploy tanpa restart JVM?

Deploy kod ke direktori baharu dan tukar pautan simbolik secara atomik, atau gunakan dua slot dengan pengimbang beban.

Bagaimana cara mengelak cache basi selepas deploy?

Paksa penyemakan semula template dan kosongkan cache yang berkaitan selepas deploy supaya data lama tidak dilayan.

Apakah turutan deploy yang betul?

Deploy kod dahulu, kemudian migrasi pangkalan data, kemudian muat semula cache atau konfigurasi.

Bagaimana cara undur jika deploy gagal?

Tukar pautan simbolik kembali ke release sebelumnya, dan pastikan migrasi pangkalan data boleh diputar balik.

Sumber

• Deploying Lucee, docs.lucee.org
• Configuration - CFConfig.json, docs.lucee.org
• Docker, docs.lucee.org
• Template Performance / Caching, docs.lucee.org