Как перенести проект на другой сервер: план миграции

Сначала разберите, из чего состоит проект

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

Одного сервера может быть недостаточно. У проекта бывают отдельная база, очередь, фоновые задачи, почтовый сервис, объектное хранилище и платёжная система. Всё это должно попасть в план. Запишите для каждого компонента источник, новую площадку, способ переноса и проверку готовности.

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

Подготовьте новую среду до переноса данных

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

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

При использовании Docker учитывайте, где действительно лежат данные. Образ приложения не содержит содержимое подключённых томов. Том и bind mount нужно переносить отдельно, с учётом требований самого приложения. Это устройство хранения описано в документации Docker.

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

Перенесите базу и пользовательские файлы

Выберите способ переноса по размеру базы, допустимому перерыву и доступным инструментам. Для небольшого проекта это может быть дамп и восстановление. Для большой базы с активной записью — репликация или другой механизм синхронизации. Универсальной команды для всех проектов нет.

У PostgreSQL дамп одной базы не включает роли и табличные пространства. Их нужно учитывать отдельно, как и расширения и права приложения. Подробности — в официальном руководстве по SQL Dump. Копирование файлов работающей базы без предусмотренного для неё механизма резервирования не заменяет корректную копию.

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

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

Проверьте действия пользователя

Главная страница с ответом 200 ещё ничего не доказывает. Проверьте вход, поиск, создание и изменение записи, загрузку и скачивание файла, отправку письма и выполнение фоновой задачи. Для оплат используйте тестовый режим провайдера.

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

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

Переключите трафик и контролируйте запись

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

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

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

Продумайте откат до начала работ

Вернуть DNS на старый сервер просто. Вернуть новые заказы, появившиеся после переезда, гораздо сложнее. Если новая среда уже принимает запись, старые данные больше не являются актуальными.

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

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

Как отработать перенос на своём проекте

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

Сохраните порядок действий, список зависимостей и результаты проверки в репозитории проекта. На собесе такой разбор полезнее фразы «умею Docker». Для начала пригодятся деплой на VPS и проверка восстановления из копии.

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

Можно ли перенести проект без простоя?

Иногда можно, но это зависит от приложения, способа синхронизации данных и переключения трафика. Возможность и ограничения нужно проверить до начала работ.

Достаточно ли скопировать Docker Compose?

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

Когда можно удалить старый сервер?

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