Daftar periksa migrasi VPS: cadangan, DNS, TLS dan rollback
Urutan migrasi praktis untuk aplikasi yang dihosting sendiri: inventaris, cadangan yang konsisten, tujuan yang teruji, penulisan terkendali, peralihan DNS dan jalur pemulihan.
Sekilas
Migrasi VPS yang terkendali menginventarisasi layanan dan data, membuat cadangan yang konsisten, memverifikasi tujuan yang dipulihkan, menguji nama host dan perutean TLS, mengoordinasikan penulisan akhir dan DNS, serta mempertahankan rollback yang sadar data. Tidak ada daftar periksa yang dengan sendirinya menjamin nol downtime.
Inventarisasi aplikasi sebelum memindahkannya
Daftarkan layanan, versi, port, tugas terjadwal, basis data, file yang diunggah dan konfigurasi yang diperlukan agar aplikasi berfungsi. Identifikasi di mana penulisan terjadi dan layanan eksternal mana yang menjadi dependensinya. Direktori web yang disalin bukan migrasi yang lengkap ketika data berada di tempat lain.
Catat nama DNS saat ini, catatan IPv4 dan IPv6 yang aktif, metode pembaruan sertifikat dan jalur akses pemulihan. Simpan rahasia di alat penerapan pribadi Anda. Jangan menaruh kata sandi, kunci pribadi atau dump basis data ke dalam document root publik atau daftar periksa migrasi bersama.
Buat cadangan yang konsisten dan buktikan bahwa cadangan itu dapat dipulihkan
Gunakan mekanisme cadangan yang didukung basis data daripada menyalin file sembarangan saat penulisan berlanjut. Untuk SQLite, Online Backup API membuat snapshot basis data yang konsisten. Dalam mode WAL, file WAL berperan serta dalam status basis data yang persisten, jadi menyalin hanya file basis data utama dapat menghilangkan perubahan yang telah dikomit.
Cadangan basis data yang konsisten tidak otomatis konsisten dengan unggahan, antrean atau file yang disimpan secara terpisah. Koordinasikan penangkapannya dengan aplikasi Anda. Pulihkan ke lokasi uji terpisah dan verifikasi catatan, referensi file dan perilaku aplikasi sebelum menganggap cadangan itu dapat digunakan.
Siapkan tujuan sebelum mengubah DNS
Buat pengguna, izin, versi runtime, layanan dan direktori aplikasi yang dimaksud di server baru. Pulihkan cadangan uji ke lokasi data tujuannya, di luar document root publik jika sesuai. Periksa kepemilikan dan akses menggunakan akun layanan yang benar-benar akan menjalankan aplikasi.
Pertahankan situs yang tidak terkait di server bersama. Gunakan document root, virtual host dan runtime yang khusus, validasi konfigurasi server web dan siapkan rollback yang hanya memulihkan file dan konfigurasi yang dimiliki oleh perubahan ini.
Uji nama host dan sertifikat yang sebenarnya di server baru
Permintaan browser ke alamat IP telanjang tidak mereproduksi perutean berbasis nama host atau validasi sertifikat. curl --resolve memungkinkan pengujian menggunakan nama host yang dimaksud dan IP tujuan yang dipilih sambil mempertahankan pemeriksaan nama host dan TLS yang normal. Periksa juga status HTTP dan konten aplikasi yang diharapkan. Contoh ini menggunakan nilai khusus dokumentasi; ganti dengan domain dan tujuan Anda sendiri yang telah diverifikasi.
Sertifikat yang valid dan jalur jaringan yang diizinkan harus sudah ada agar pengujian itu berhasil. Jangan pernah menonaktifkan verifikasi sertifikat untuk menyatakan migrasi siap. Validasi ACME berbasis DNS dapat memvalidasi domain tanpa mengubah alamat server webnya; validasi berbasis HTTP memiliki persyaratan keterjangkauan yang berbeda. Uji pembaruan secara terpisah dari penerbitan awal.
curl --fail-with-body --show-error --resolve example.com:443:203.0.113.10 https://example.com/Pilih rencana kontrol penulisan dan sinkronisasi akhir
Jadwalkan periode pemeliharaan singkat atau mekanisme konsistensi lain yang sesuai dengan aplikasi. Hentikan atau alihkan penulis yang Anda identifikasi, ambil cadangan basis data final yang konsisten, sinkronkan file mutable yang sesuai dan verifikasi hasilnya. Pekerja antrean, webhook dan tugas cron dapat menulis bahkan ketika antarmuka publik terlihat sepi.
Gunakan uji coba (dry run) sebelum sinkronisasi file. Jangan menambahkan flag penghapusan atau menyalin seluruh direktori sistem sebagai jalan pintas. Pertahankan layanan lama agar dapat dipulihkan sampai Anda memeriksa aplikasi baru dan menetapkan lokasi mana yang otoritatif untuk penulisan.
Ubah DNS, lalu amati kedua keluarga alamat
Perbarui catatan yang diperlukan untuk layanan dan perhitungkan cache resolver yang ada. Periksa jawaban otoritatif dan beberapa jalur klien normal. Jika catatan AAAA yang usang tetap aktif, klien IPv6 dapat terus mencapai server lama sementara klien IPv4 mencapai server baru.
Uji masuk, baca, tulis, unggah, pekerjaan latar belakang dan callback eksternal pada layanan baru. Hindari menjalankan dua salinan aplikasi yang dapat ditulis secara independen selama transisi. Pertahankan aturan yang jelas untuk menangani lalu lintas yang masih mencapai tujuan lama.
Jadikan rollback sebagai keputusan data sekaligus keputusan DNS
Tetapkan kondisi kegagalan yang memicu rollback dan siapa yang mengendalikan peralihan. Mengembalikan DNS saja tidak cukup setelah penulisan baru mencapai tujuan: Anda harus mempertahankan atau merekonsiliasi data tersebut sebelum kembali ke salinan lama.
Simpan sumber dan cadangan untuk periode pemulihan yang sesuai. Hapus akses lama dan nonaktifkan sumber daya hanya setelah tujuan, cadangan, pembaruan dan pemantauan telah diperiksa. Retensi dan penghapusan harus mengikuti kebijakan layanan yang sebenarnya, bukan jumlah jam tetap yang generik.