Контрольний список міграції VPS: резервні копії, DNS, TLS і відкат
Практична послідовність міграції для власноруч розміщеної програми: інвентаризація, узгоджені резервні копії, перевірене призначення, контрольовані записи, перемикання DNS і шлях відновлення.
Короткий огляд
Контрольована міграція VPS інвентаризує сервіси й дані, створює узгоджену резервну копію, перевіряє відновлене призначення, тестує маршрутизацію імені хоста та TLS, координує фінальні записи та DNS, а також зберігає відкат із урахуванням даних. Жоден контрольний список сам по собі не гарантує нульового простою.
Інвентаризуйте програму перед переміщенням
Перелічіть сервіси, версії, порти, заплановані завдання, бази даних, завантажені файли та конфігурацію, потрібні для роботи програми. Визначте, де відбуваються записи та від яких зовнішніх сервісів вона залежить. Скопійований вебкаталог не є повною міграцією, коли дані зберігаються деінде.
Запишіть поточні назви DNS, активні записи IPv4 і IPv6, способи поновлення сертифікатів і шлях доступу для відновлення. Зберігайте секрети у приватних інструментах розгортання. Не додавайте паролі, приватні ключі чи дампи баз даних до публічного кореня документів або спільного контрольного списку міграції.
Створіть узгоджену резервну копію та доведіть, що вона відновлюється
Використовуйте підтримуваний базою даних механізм резервного копіювання, а не копіюйте довільні файли, поки записи тривають. Для SQLite, Online Backup API створює узгоджений знімок бази даних. У режимі WAL файл WAL бере участь у постійному стані бази даних, тому копіювання лише головного файлу бази даних може пропустити зафіксовані зміни.
Узгоджена резервна копія бази даних не є автоматично узгодженою з окремо збереженими завантаженнями, чергами чи файлами. Узгодьте їхній захват із вашою програмою. Відновіть у окремому тестовому розташуванні та перевірте записи, посилання на файли й поведінку програми, перш ніж вважати резервну копію придатною.
Підготуйте призначення перед зміною DNS
Створіть потрібних користувачів, дозволи, версії середовища виконання, сервіси та каталоги програм на новому сервері. Відновіть тестову резервну копію в її цільове розташування даних, за потреби поза публічним вебкоренем. Перевірте власність і доступ за допомогою службового облікового запису, який фактично запускатиме програму.
Збережіть не пов'язані сайти на спільному сервері. Використовуйте окремий корінь документів, віртуальний хост і середовище виконання, перевірте конфігурацію вебсервера та підготуйте відкат, який відновлює лише файли й конфігурацію, що належать цій зміні.
Перевірте справжнє ім'я хоста та сертифікат на новому сервері
Запит браузера до голої IP-адреси не відтворює маршрутизацію за іменем хоста чи перевірку сертифіката. curl --resolve дозволяє тесту використовувати потрібне ім'я хоста та вибрану IP-адресу призначення, зберігаючи звичайні перевірки імені хоста й TLS. Також перевірте статус HTTP і очікуваний вміст програми. Приклад використовує значення лише для документації; замініть їх власним перевіреним доменом і призначенням.
Для успішного проходження цього тесту мають уже існувати чинний сертифікат і дозволений мережевий шлях. Ніколи не вимикайте перевірку сертифіката, щоб назвати міграцію готовою. Валідація DNS на основі ACME може перевірити домен без зміни адреси його вебсервера; валідація на основі HTTP має інші вимоги до досяжності. Перевіряйте поновлення окремо від початкового випуску.
curl --fail-with-body --show-error --resolve example.com:443:203.0.113.10 https://example.com/Виберіть план контролю записів і фінальної синхронізації
Заплануйте короткий період обслуговування або інший відповідний програмі механізм узгодженості. Зупиніть або перенаправте виявлених вами авторів записів, зробіть фінальну узгоджену резервну копію бази даних, синхронізуйте відповідні змінні файли та перевірте результат. Обробники черг, вебхуки та завдання cron можуть писати навіть тоді, коли публічний інтерфейс виглядає тихим.
Виконайте пробний запуск перед синхронізацією файлів. Не додавайте прапорці видалення і не копіюйте цілі системні каталоги як скорочення. Зберігайте старий сервіс відновлюваним, доки не перевірите нову програму та не встановите, яке розташування є авторитетним для записів.
Змініть DNS, потім спостерігайте за обома сімействами адрес
Оновіть записи, потрібні для сервісу, та врахуйте наявні кеші резолверів. Перевірте авторитетні відповіді та кілька звичайних шляхів клієнтів. Якщо застарілий запис AAAA залишається активним, клієнти IPv6 можуть і далі досягати старого сервера, тоді як клієнти IPv4 досягають нового.
Перевірте вхід, читання, записи, завантаження, фонові завдання та зовнішні зворотні виклики на новому сервісі. Уникайте запуску двох незалежних копій тієї самої програми з правом запису під час переходу. Тримайте чітке правило для трафіку, що все ще досягає старого призначення.
Зробіть відкат рішенням щодо даних, а не лише рішенням щодо DNS
Визначте умови збою, що запускають відкат, і хто контролює перемикання. Повернення лише DNS недостатньо після того, як нові записи досягли призначення: потрібно зберегти або узгодити ці дані, перш ніж повертатися до старішої копії.
Зберігайте джерело та резервні копії протягом належного періоду відновлення. Видаляйте старий доступ і виводите з експлуатації ресурси лише після перевірки призначення, резервних копій, поновлення та моніторингу. Зберігання та видалення мають відповідати фактичній політиці сервісу, а не загальній фіксованій кількості годин.