МиграцияDevOpsДеплой

Переезд с VPS на managed-платформу: перенос приложения, базы и домена

5 мин чтения

VPS даёт полный контроль над сервером, но за этот контроль платят временем: обновления ОС, supervisor для процессов, бэкапы, продление SSL, мониторинг места — всё на разработчике. Managed-платформа снимает этот слой. Разберём, что именно нужно перенести при переезде и как переключиться без простоя.

Что переносим: инвентаризация

Перед переездом полезно выписать всё, что живёт на VPS, — иначе что-нибудь забудется:

  • код — репозиторий приложения;
  • переменные окружения и секреты — часто в .env или systemd-юните;
  • база данных — Postgres, MySQL и их содержимое;
  • загруженные файлы — пользовательские аплоады, если хранятся на диске;
  • периодические задачи — записи crontab;
  • фоновые воркеры — отдельные процессы помимо веб-приложения;
  • домен и SSL — DNS-записи и сертификаты.

Шаг 1: код в Git

Если деплой на VPS шёл через scp/rsync или правки прямо на сервере, сначала нужно привести проект к деплою по git push: завести репозиторий, убедиться, что всё нужное в нём, а сборка не зависит от файлов, которые лежали только на сервере.

Шаг 2: переменные окружения

Секреты с VPS (из .env или EnvironmentFile systemd) переносят в настройки проекта на платформе. Это хороший момент, чтобы заодно ротировать ключи, если они могли где-то засветиться. Как безопасно с ними работать — в статье про секреты и .env.

Шаг 3: база данных

База — самая ценная часть переезда. На платформе поднимают managed-базу и переносят данные. Для небольшой базы — дамп и восстановление, для боевой — логическая репликация с коротким переключением. Пошагово это разобрано в статье про перенос PostgreSQL без простоя.

Шаг 4: файлы и периодические задачи

Загруженные файлы. Если приложение хранит аплоады на диске VPS, их переносят в постоянное хранилище: объектное хранилище (S3-совместимое) или том платформы. Файлы на эфемерном диске контейнера теряются при редеплое — это частая ошибка переезда.

Cron-задачи. Записи crontab переводят в отдельный воркер-задачу или Cron Job платформы, а не оставляют на гаснущем VPS.

Шаг 5: домен и SSL

На VPS сертификат обычно выпускался вручную через certbot. На managed-платформе SSL выпускается и продлевается автоматически — отдельная настройка не нужна. Остаётся переключить домен:

  1. Заранее снизить TTL у DNS-записи (например, до 300 секунд) — за сутки до переезда, чтобы изменение разошлось быстро.
  2. Поднять приложение на платформе и проверить его по временному адресу.
  3. Переключить A/CNAME-запись домена на платформу.
  4. Дождаться, пока новый адрес разойдётся по DNS (ускоряет заранее сниженный TTL).
  5. Погасить VPS только после того, как весь трафик ушёл на новую площадку.

Переключение без простоя

Принцип — «сначала поднять новое, потом погасить старое». Новая площадка работает параллельно со старой; домен переключается, когда новая проверена; VPS остаётся включённым, пока на него ещё может идти трафик из-за DNS-кэша. Так в любой момент есть рабочая версия.

Проверка после переключения

Перед тем как гасить VPS, новую площадку прогоняют по основным сценариям:

  • приложение открывается по домену, сертификат валиден (замок в браузере, нет предупреждений);
  • ключевые действия работают: вход, запись в базу, загрузка файла;
  • фоновые воркеры и cron-задачи запустились и видны в логах;
  • бэкап базы на новой стороне действительно создаётся.

Старый VPS стоит подержать выключенным, но не удалённым ещё несколько дней — как точку отката, если проблема всплывёт уже после переключения, когда часть трафика осела на новой площадке.

Частые грабли

  • Файлы на эфемерном диске. Аплоады, оставленные на диске контейнера, исчезают при первом редеплое.
  • Высокий TTL DNS. Если не снизить TTL заранее, переключение домена растягивается на часы.
  • Забытые cron-задачи. Приложение переехало, а ночные задачи остались на выключенном VPS.
  • Не ротированы секреты. Переезд — повод сменить ключи, особенно если доступ к VPS был у нескольких людей.
  • VPS погашен слишком рано. Пока DNS не разошёлся, часть запросов всё ещё идёт на старый адрес.

Чеклист

  • Составлен список переносимого: код, секреты, база, файлы, cron, воркеры, домен.
  • Деплой переведён на git push.
  • Секреты перенесены в настройки проекта и при необходимости ротированы.
  • База перенесена и сверена.
  • Загруженные файлы — в постоянном хранилище, не на диске контейнера.
  • TTL DNS снижен заранее, домен переключён, SSL выпущен автоматически.
  • VPS погашен только после ухода всего трафика.

Managed-платформа закрывает ровно тот слой, ради которого затевался переезд: процессы, бэкапы, SSL и мониторинг — на стороне платформы. На Hostim приложение разворачивается по git push, managed-база и домен с SSL поднимаются рядом, а размещение приложений в рублях с оплатой картой РФ описано на главной.

Читать дальше