Перенос хостинга с планом возврата

Перенос на другой сервер отличается от обычной публикации: меняются не только файлы, но и путь запросов, сертификаты, доступ и наблюдение. Завершим серию планом такого изменения для release-lab. Основной домен example.com сохраняется. Условный старый узел имеет адрес 198.51.100.20, новый — 203.0.113.10; оба адреса документационные, действия на них не выполнялись.

Сначала рассмотрим статический сайт, затем добавим прикладные данные. Опыт ProfessorWeb здесь задаёт главный критерий: смена устройства не должна сама по себе менять важные адреса. В репозитории его переносимого статического результата сохранение старых маршрутов является отдельной задачей. Наш пример не выдаёт запланированный перенос за выполненную работу на настоящем домене.

Не смешивать переезд с новым содержимым

Для начала размещаем на новом узле тот же принятый артефакт, который работает на старом. Если одновременно изменить шаблоны, генератор, путь статей и сервер, станет сложнее понять причину несовпадения. Это не запрет на развитие сайта, а удобная граница одного изменения: сейчас проверяем эквивалентность обслуживания. Новое содержимое можно выпустить после принятия переноса обычным способом.

На новом сервере готовят виртуальный сайт, права, обработку статических .php, страницу 404 и журналы. Переносят необходимые ресурсы, паспорт и сведения о конфигурации. Если переезд идёт с Beget на VPS, системные настройки не копируются буквально: .htaccess не заменяет конфигурацию Nginx. Важно воспроизвести наблюдаемое поведение адресов подходящим механизмом новой площадки.

Подготовить сертификат до основного потока

Новый узел должен обслуживать TLS для example.com до изменения основной записи. Для этого подходит согласованный DNS-01 или иной допустимый способ подтверждения, не зависящий от уже переключённого HTTP-потока. Закрытый ключ и доступ к зоне передают только по установленным правилам. Сертификат тестового поддомена не подходит для проверки основного имени. Первичная документация способов подтверждения Let's Encrypt.

Если новый сервер ещё не имеет корректного сертификата, нельзя считать успешным просмотр с отключённой проверкой доверия. Такая попытка может помочь узкой диагностике, но не подтверждает будущий доступ посетителя. План принятия требует обычного проверенного соединения. Для размещения за CDN отдельно готовят соединение между внешним слоем и origin, не ограничиваясь внешним сертификатом CDN.

Проверить имя на выбранном адресе

Открытие IP не воспроизводит выбор виртуального сайта и имя TLS. Для будущей проверки используем curl --resolve: URL остаётся https://example.com, но соединение направляется на выбранный новый адрес. Это позволяет до DNS проверить нужное имя без отключения сертификатной проверки. Официальное описание curl --resolve.

curl --resolve example.com:443:203.0.113.10 \
  --dump-header new-old.headers --output new-old.html \
  https://example.com/my/legacy/first.php

curl --resolve example.com:443:203.0.113.10 \
  --dump-header new-missing.headers --output new-missing.html \
  https://example.com/missing-for-move

Команды не запускались. У будущего стенда ожидаются 200 и HTML старой статьи, а для отсутствующего пути — 404 с оформлением. Таким же способом проверяют каталог, стили, индикатор и перенаправление дополнительных имён. Если запрос переходит на другое имя, его разрешение тоже нужно учесть отдельно: одна запись --resolve не покрывает автоматически любые последующие домены.

Оба узла могут показывать одинаковый номер выпуска, поскольку переезжает один артефакт. Поэтому для проверки выбранного сервера дополнительно фиксируют направленный адрес и запись нового журнала. Индикатор версии сообщает содержание, а не идентичность машины. Это полезное различие: не нужно специально менять файлы выпуска только ради имени узла, если адрес соединения уже известен.

Подготовить DNS и окно наблюдения

Перед переключением сохраняют текущие значения записей и заранее уменьшают TTL, если это соответствует плану. Уменьшение непосредственно в момент переезда не отменяет прежние кеши. Проверяют A и AAAA: забытая IPv6-запись способна продолжать направлять часть посетителей на старый узел. Смена сервера сайта не должна случайно удалить почтовые записи или подтверждения других сервисов.

После изменения наблюдают авторитетные ответы, выбранные резолверы и внешние HTTP-результаты. Не обещают один универсальный момент, когда «DNS обновился у всех». Некоторое время запросы могут идти на оба узла. Для статики это допустимо, если они показывают одно принятое содержимое. Старый сервер сохраняют работающим и наблюдаемым до конца согласованного переходного периода.

Учебное условие принятия
Новый узел обслуживает тот же артефакт и старые пути.
Внешние HTTPS-запросы соответствуют ожидаемым ответам.
Существенного роста ошибок в выбранном наблюдении нет.
Копия и старое размещение доступны для согласованного возврата.

Сравнение ошибок требует источника и периода, а не вымышленной цифры. На своём стенде читатель запишет дату, число запросов и границы наблюдения. Отсутствие ошибки в двух ручных запросах не доказывает поведение всего трафика. При большой библиотеке значимые маршруты берут из её реестра, а не ограничиваются главной страницей.

Возврат статического размещения

Если новый сервер не принят, возвращают согласованные DNS-значения или маршрут CDN, а старый узел остаётся готовым обслуживать запросы. Но уже сохранённые новые ответы DNS могут какое-то время продолжать вести посетителей на новый сервер. Поэтому его не отключают сразу после решения о возврате. По возможности оба узла сохраняют пригодное содержимое на переходный период и продолжают внешнее наблюдение.

Причина возврата фиксируется вместе с выбранным артефактом и настройками. Если проблема в MIME старого адреса, исправляют новый обработчик и повторяют проверку до следующей попытки. Если в сертификате — корректируют TLS. Не следует считать перенос завершённым только по оплате сервера и загрузке файлов. Принятие связано с наблюдаемым поведением основного имени и сохранением нужных адресов.

Если приложение принимает новые данные

У динамической ветки возникает главный вопрос: какой узел является единственным источником записи? Простое копирование базы утром и переключение вечером теряет действия между этими моментами. Для небольшого проекта можно выбрать короткое окно ограничения записи, получить согласованный набор базы и uploads, восстановить его и открыть запись на новом узле. Более сложная схема требует репликации или направленного доступа к общему источнику с отдельным планом совместимости.

После открытия записи на новом узле возврат DNS к старой базе не возвращает новые записи автоматически. Нужен способ перенести их назад, временно ограничить запись или направить старый узел к принятому источнику. Этот способ заранее проверяют на учебных данных. Восстановление старого дампа без такого решения способно уничтожить полезные действия посетителей. Поэтому для динамики план возврата описывает код и данные отдельно.

Серия завершается управляемой моделью изменения: известный результат, подготовленное окружение, проверка до выбора, наблюдение после выбора и осознанный возврат. Все примеры остались локальными черновиками. Реальный запуск потребует выбранного стенда и выполнения описанных проверок; он будет отдельной работой после редакционного принятия уроков.