Контрольный список миграции 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 недостаточно после того, как новые записи достигли пункта назначения: вы должны сохранить или согласовать эти данные перед возвратом к более старой копии.
Сохраняйте источник и резервные копии в течение подходящего периода восстановления. Удаляйте старый доступ и выводите из эксплуатации ресурсы только после проверки пункта назначения, резервных копий, продления и мониторинга. Хранение и удаление должны следовать фактической политике сервиса, а не обобщённому фиксированному числу часов.