Что проверить перед переходом на другую облачную платформу: чек-лист

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

Мы делаем DADA Cloud, а чек-лист годится для любого направления: на DADA Cloud, с неё и между другими платформами. Там, где важны детали нашей платформы, они названы отдельно. Если вы уходите с Vercel, у нас есть отдельное руководство по миграции с Vercel.

Шаг 1 - Инвентаризация

Выпишите всё, что нужно перенести, и сопоставьте каждой строке то, чем она станет на новой платформе. Пустая ячейка означает блокер переезда.

Шаг 2 - Переменные окружения и секреты

Составьте список переменных с областью действия: нужна ли переменная при сборке, при запуске или в обоих случаях. Отметьте секреты. В DADA Cloud есть области build, runtime и both и флаг секретности. Значение секретной переменной после сохранения прочитать обратно нельзя, а listEnvVars показывает его замаскированным. Если вы уходите с DADA Cloud, возьмите значения из своего менеджера секретов или из места, где вы их генерировали.

Когда вы создаёте базу в DADA Cloud и привязываете её к приложению, DATABASE_URL записывается в окружение приложения автоматически, с Redis так же работает REDIS_URL. При переезде замените старые адреса и проверьте логи старта на пустые значения.

Шаг 3 - Базы данных

Выясните версию, расширения, размер и допустимое окно простоя. Путь переноса PostgreSQL в обе стороны один: pg_dump на старой стороне и psql на новой.

pg_dump --no-owner --no-privileges "$OLD_DATABASE_URL" > dump.sql
psql -v ON_ERROR_STOP=1 "$NEW_DATABASE_URL" -f dump.sql

Версия pg_dump не должна быть старше сервера-источника (см. документацию PostgreSQL по резервному копированию). Время простоя примерно равно времени дампа плюс загрузки, поэтому измерьте его на копии.

Что важно знать про DADA Cloud. Это управляемый PostgreSQL 17.5 без выбора версии и без суперпользователя, расширения включает платформа, поэтому сверьте свой список до переезда. Параметры подключения есть в консоли или в ответе getDatabaseCredentials с reveal=true, просмотр записывается в аудит. Адрес выглядит как postgresql://...@db.pv.dada-tuda.ru:5432/<база>?sslmode=require, хост отвечает из публичной сети. Подключение из конкретной страны мы не проверяли, поэтому заранее запустите psql с той машины, откуда будете грузить дамп. Отдельного метода импорта нет, загрузка идёт через psql. Для выгрузки в другую сторону подойдёт тот же pg_dump или скачивание дампа готовой резервной копии в консоли по ссылке на 5 минут. Redis не имеет копий и инструмента запросов, считайте его данные кешем. Подробнее про базы в материале про облачные базы данных и на странице PostgreSQL.

Файлы томов DADA Cloud выгружаются в архив tar.gz по ссылке на 15 минут. Расписания копий томов в консоли нет, выгрузку нужно делать самим.

Шаг 4 - Домены и DNS

За сутки до переезда снизьте TTL записей, чтобы переключение и откат дошли до пользователей быстро. Сохраните полную копию зоны, особенно записи почты.

В DADA Cloud домен подтверждается TXT-записью на корневое имя, после чего имена привязываются к приложениям. Сертификаты Let's Encrypt выпускаются проверкой HTTP-01 и продлеваются автоматически. Эта проверка обычно требует, чтобы имя уже вело на платформу, поэтому заложите короткое окно между сменой DNS и появлением сертификата. Есть и управляемый DNS: вы делегируете зону через NS, редактируете записи A, AAAA, CNAME, MX, TXT, NS, SRV, CAA и можете импортировать зону целиком. Импортируйте её до смены NS. IP-адрес для записи A берите из консоли и сверяйте перед сменой DNS: старые инструкции могли устареть.

Шаг 5 - План отката

Заранее решите, при каких признаках вы откатываетесь: рост ошибок, сбой оплаты, недоступность базы. Откат в простом случае означает возврат DNS на старую платформу, поэтому не выключайте её, пока не убедитесь в новой.

Сложнее с базой. После переключения новые записи попадают в новую базу, и возврат на старую потеряет их. Выберите один из вариантов: окно, в которое записи остановлены, или обратный дамп новой базы. В DADA Cloud откат версии приложения поднимает один из прежних образов без новой сборки, контейнерные приложения откатываются через консоль и API развёртываний. Проверьте откат на тестовой копии: непроверенный откат ненадёжен.

Шаг 6 - Тестовый деплой

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

На DADA Cloud такую репетицию можно сделать без пополнения: аккаунт получает 72 часа пробного периода с одним приложением минимального размера и одной базой, после чего приложения останавливаются до пополнения, а данные сохраняются. Порядок выкладки описан в руководстве по деплою из GitHub, цены на странице цен.

Шаг 7 - Переключение

Порядок такой: объявите окно, остановите запись в старую базу, снимите финальный дамп и загрузите его, сверьте число строк в основных таблицах, переключите DNS, следите за логами и метриками, верните вебхуки. Старую платформу оставьте работающей на срок вашего самого длинного рабочего цикла, например неделю или месяц, и только потом отключайте. Удаление базы в DADA Cloud выполняется через консоль или API. Если вам нужны гарантии уничтожения данных, запросите их письменно.

Частые вопросы

Сколько простоя неизбежно при переносе базы?

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

Что делать, если секрет нельзя прочитать обратно?

Сгенерируйте новое значение у источника, например перевыпустите ключ API у сервиса, и обновите переменную на обеих сторонах. В DADA Cloud значения секретных переменных после сохранения не читаются, поэтому исходники ключей держите в менеджере секретов.

Как проверить, что база перенеслась полностью?

Сравните число строк в основных таблицах, суммы по важным столбцам и результат прогона приложения на копии. При загрузке через psql ключ ON_ERROR_STOP=1 остановит процесс на первой ошибке.

Что делать, если на новой платформе нет расписаний?

Запускайте задачи внутри приложения планировщиком или вызывайте их из внешнего сервиса. В DADA Cloud запуска по расписанию нет, фоновый процесс работает непрерывно.

Источники

• PostgreSQL: резервное копирование
• 12-factor app