Как перенести Docker Compose на новый VPS без даунтайма

В большинстве случаев переезд на новый VPS происходит по какой-то серьёзной и практичной причине, например ваш проект вырос и перестал помещаться в текущие ресурсы или для вашего проекта требуется более производительное оборудование, меняется дата-центр или приходит время обновить инфраструктуру. Если приложение работает в Docker Compose, то эта задача на первый взгляд кажется достаточно простой, ведь нужно всего лишь скопировать файлы, запустить контейнеры - и всё готово.

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

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

В этой статье рассмотрим последовательность действий, которая позволяет перенести ваш Docker Compose проект на новый VPS с минимальным временем простоя или вовсе без него.

 

 

 

Подготовьте новый сервер заранее

Как это не контринтуитивно, но одна из самых частых ошибок, допускаемых при миграции - это выключить старый VPS и только потом начать настраивать новый. Такой подход напрямую приводит к простою. Очевидно, что единственным правильным вариантом является держать оба сервера в работе на время миграции и отключать старый сервер только после полной подготовки новой площадки и переключения проекта на неё.

Перед переносом проекта на новый сервер на нём необходимо проделать несколько подготовительных шагов:

• обновить операционную систему;
• установить Docker Engine;
• установить Docker Compose Plugin;
• настроить файервол;
• подготовить каталоги для постоянных данных;
• убедиться, что ресурсов VPS хватит для работы проекта с запасом.

 

Проверить установленные версии Docker можно такими командами:

docker --version
docker compose version
docker info

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

Есть ещё один момент, который очень легко упустить. Проверьте архитектуру нового сервера. Если старый VPS работал на x86_64 (amd64), а новый использует ARM, то часть образов может просто не запуститься. Особенно это касается собственных сборок или проектов, где используются редко обновляемые образы сторонних разработчиков.

После того, как вы обновили сервер и провели необходимые проверки - можно переходить к пошаговому переносу проекта.

 

 

 

 

Перенесите инфраструктуру, а не только приложение

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

• docker-compose.yml;
• .env;
• пользовательских Dockerfile;
• конфигурациях Nginx, Apache или Traefik;
• SSL-сертификатах;
• файлах конфигурации самого приложения;
• пользовательских скриптах;
• заданиях cron;
• резервных копиях.

 

Если инфраструктура хранится вместе с исходным кодом, например в Git-репозитории, то подготовка нового сервера обычно занимает всего несколько минут. Именно по этой причине подход Infrastructure as Code получил такое широкое распространение в последние годы, так как он позволяет быстро воспроизводить рабочее окружение практически на любом сервере.

Отдельное внимание стоит уделить секретам и конфигурации. Файл .env нельзя хранить в публичном репозитории, но его актуальная копия должна быть подготовлена ещё до начала миграции.

Кстати, именно отсутствие .env - это одна из самых распространённых причин неудачного переноса Docker Compose. Контейнеры могут успешно запуститься, но приложение начнёт работать с ошибками или вовсе не сможет стартовать из-за отсутствия необходимых переменных окружения.

 

 

 

 

Контейнеры переносить не нужно

Во время первой миграции многие пытаются перенести сами контейнеры. Для этого используют docker commit, экспортируют образы или вообще копируют каталог /var/lib/docker целиком. На первый взгляд идея кажется логичной, но это не правильный путь.

Контейнер - это расходный элемент системы. Он создаётся из образа, запускается, выполняет свою задачу и при необходимости пересоздаётся за считанные секунды. В этом вся суть работы Docker. Поэтому переносить нужно не контейнеры, а всё, что находится за их пределами и должно сохраниться после перезапуска. Обычно это:

• исходный код приложения;
• файл docker-compose.yml и остальные конфигурации;
• Docker-образы (или доступ к Registry, из которого они будут загружены);
• Docker Volumes;
• базы данных;
• пользовательские файлы;
• SSL-сертификаты;
• секреты и переменные окружения.

 

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

 

 

 

 

Что делать с Docker Images

Если проект использует образы из Docker Hub, GitHub Container Registry или собственного Registry, то никаких сложностей обычно не возникает. Достаточно просто скачать нужные версии и запустить контейнеры.

docker compose pull
docker compose up -d

Docker Compose сам загрузит все образы, которые указанны в конфигурации.

 

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

Первый - это пересобрать их уже на новом VPS:

docker compose build
docker compose up -d

 

Второй - сохранить готовый образ в архив, перенести его на новый сервер и там уже импортировать.

docker save my-image:latest -o my-image.tar

После копирования файла выполните:

docker load -i my-image.tar

 

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

 

 

 

 

Самый ответственный этап - перенос данных

Во время миграции Docker Compose основное внимание стоит уделить данным. Контейнеры всегда можно пересоздать, а вот потеря содержимого базы данных или Docker Volumes почти всегда превращается в серьёзную проблему, так как большинство современных приложений хранит своё состояние именно там. Поэтому перенос нужно выполнять максимально аккуратно.

Если проект использует PostgreSQL, MySQL, MariaDB или другую СУБД, не стоит копировать каталог с файлами базы данных, пока она продолжает принимать запросы. Даже если кажется, что всё прошло успешно, то после восстановления можно столкнуться с повреждёнными таблицами или неконсистентными данными.

Надёжнее будет использовать штатные инструменты резервного копирования.

Для PostgreSQL это стандартная утилита pg_dump:

pg_dump -U postgres mydb > backup.sql

 

Для MySQL, соответственно, mysqldump:

mysqldump -u root -p mydb > backup.sql

 

Полученный дамп переносится на новый VPS, после чего база данных восстанавливается уже на новом сервере.

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

 

 

 

 

Перенос Docker Volumes

Если приложение хранит данные в Docker Volumes, то их тоже нужно будет перенести на новый сервер. Именно там часто находятся пользовательские файлы, загруженный контент, кеш, служебные данные и другая информация, которая также должна сохраниться после миграции.

Сначала просмотрите список существующих томов:

docker volume ls

 

Один из самых простых способов переноса - это создать архив с помощью временного контейнера, например:

docker run --rm \
-v app_data:/from \
-v $(pwd):/backup \
alpine tar czf /backup/app_data.tar.gz -C /from .

 

Получившийся архив достаточно скопировать на новый VPS сервер. Затем создайте новый Docker Volume и распакуйте в него сохранённые данные тем же способом, используя временный контейнер.

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

 

 

 

 

Синхронизация пользовательских файлов

Перенос пользовательских файлов обычно проходит намного проще, чем миграция баз данных или Docker Volumes. Поэтому если речь идёт об изображениях, документах, резервных копиях или других загружаемых данных, то чаще всего достаточно воспользоваться утилитой для инкрементальной синхронизации файлов rsync.

Например:

rsync -avz /var/www/uploads/ user@new-server:/var/www/uploads/

 

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

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

 

 

 

 

Как сократить время простоя практически до нуля

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

Обычно процесс выглядит так:

1. Выполняется первая синхронизация пользовательских файлов с помощью rsync, пока приложение продолжает работать;
2. Создаётся и переносится резервная копия базы данных;
3. На новом сервере запускаются контейнеры, после чего проверяется работа приложения;
4. На старом VPS включается режим обслуживания (maintenance mode) или временно запрещается запись новых данных;
5. Выполняется повторная синхронизация через rsync, которая переносит только изменения, появившиеся после первого запуска команды;
6. При необходимости переносится актуальное состояние базы данных или применяются последние изменения;
7. DNS-записи переключаются на новый сервер.

 

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

Одно из главных преимуществ Docker Compose заключается в том, что приложение можно полностью развернуть ещё до того, как пользователи начнут обращаться к новому серверу.

После переноса данных достаточно выполнить запуск:

docker compose up -d

 

Если используются свежие образы из Registry, перед этим желательно обновить их:

docker compose pull
docker compose up -d

 

После запуска следует убедиться, что все сервисы успешно стартовали:

docker ps

 

Также стоит проверить журналы контейнеров:

docker compose logs

или журнал отдельного сервиса:

docker compose logs nginx

 

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

 

 

 

 

Проверьте работу приложения перед переключением DNS

Прежде чем менять DNS-записи и переводить пользователей на новый VPS, стоит убедиться, что проект полностью готов к работе. Лучше потратить несколько минут на проверку сейчас, чем разбираться с ошибками уже после завершения миграции.

Для начала откройте приложение через временный домен, локальную запись в файле hosts или напрямую по IP-адресу нового сервера. После этого проверьте несколько ключевых моментов:

• приложение запускается без ошибок;
• все контейнеры находятся в состоянии Up;
• база данных отвечает на запросы;
• пользовательские файлы доступны;
• авторизация и административная панель работают корректно;
• SSL-сертификаты установлены и используются;
• журналы Docker не содержат ошибок.

Если проект работает через обратный прокси (Nginx, Traefik или Caddy), убедитесь, что запросы корректно маршрутизируются между всеми сервисами.

После такой проверки можно обновлять DNS и переключать пользователей на новый сервер.

 

 

 

Переключите трафик и наблюдайте за работой проекта

Когда новый VPS полностью проверен, можно переключать пользователей на него. Обычно для этого достаточно изменить A- или AAAA-запись домена.

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

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

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

Для быстрого контроля пригодятся несколько стандартных команд:

docker stats
docker compose logs -f
docker events

 

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

 

 

 

План отката и самые частые ошибки при миграции

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

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

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

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

Ошибка	Последствие
Не перенесён файл .env	Приложение не запускается или работает с неверными настройками
Не скопированы SSL-сертификаты	Сайт перестаёт открываться по HTTPS
Изменились пути к Docker Volumes	Приложение теряет доступ к данным
Закрыты нужные порты в файрволе	Контейнеры работают, но сервис недоступен извне
База данных скопирована во время активной записи	Повреждение или потеря данных
DNS переключён до завершения проверки	Пользователи начинают получать ошибки
Не перенесены задания cron	Перестают работать резервное копирование, уведомления и фоновые задачи
Не проверены права доступа к каталогам	Возникают ошибки записи файлов и журналов

 

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

 

 

 

 

Что переносить, а что нет

Итак, подведём итог и соберём всё в одном месте. Во время миграции Docker Compose далеко не всё содержимое сервера нужно переносить на новый VPS. Одни компоненты необходимо сохранить в обязательном порядке, другие Docker без проблем создаст заново.

Компонент	Нужно переносить
docker-compose.yml	Да
.env	Да
Docker Volumes	Да
Базы данных	Да
Пользовательские файлы	Да
SSL-сертификаты	Да
Docker Images	При необходимости
Контейнеры	Нет
Кэш контейнеров	Нет
Временные файлы	Нет

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

 

 

 

 

Автоматизируйте будущие миграции

Если перенос Docker Compose выполняется регулярно - например, между тестовой, staging- и production-средами, то многие рутинные операции со временем лучше автоматизировать. Это сокращает время миграции и заметно снижает вероятность ошибок.

Для таких задач чаще всего используют:

• Ansible - для настройки серверов и автоматического развёртывания Docker Compose;
• GitHub Actions или GitLab CI/CD - для сборки образов и автоматического деплоя;
• rsync по SSH - для синхронизации пользовательских файлов;
• Docker Registry - для хранения собственных Docker-образов;
• Watchtower и аналогичные инструменты - для автоматического обновления контейнеров, если такой подход используется в инфраструктуре.

 

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

 

 

 

 

FAQ

Нужно ли переносить сами контейнеры Docker?

Нет. Контейнеры считаются одноразовыми объектами и в большинстве случаев их проще и правильнее создать заново с помощью Docker Compose.

 

Можно ли просто скопировать каталог /var/lib/docker?

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

 

Нужно ли переносить Docker Images?

Если образы доступны в Docker Hub или собственном Registry, то достаточно выполнить docker compose pull. Экспортировать их имеет смысл только в тех случаях, когда используются локально собранные или недоступные извне образы.

 

Как долго обновляется DNS после смены сервера?

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

 

Можно ли полностью избежать даунтайма?

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

 

Что делать с SSL-сертификатами?

Если используются собственные сертификаты, их необходимо перенести вместе с закрытыми ключами. При использовании Let's Encrypt можно либо перенести существующие сертификаты, либо повторно выпустить их уже на новом сервере после завершения миграции.

 

 

 

Вывод

Итак, мы выяснили, что перенести проект с Docker Compose на новый VPS сервер без даунтайма вполне реально. И для этого не нужны сложные инструменты или нестандартные решения, а достаточно правильно организовать сам процесс миграции.

Главная мысль, которую стоит запомнить, проста: переносить нужно не контейнеры, а инфраструктуру вокруг них. Конфигурацию, базы данных, Docker Volumes, пользовательские файлы, сертификаты, переменные окружения и остальные компоненты, без которых приложение не сможет работать - переносим, а сами контейнеры при необходимости всегда можно создать заново.

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