Как перенести Docker-проект на другой сервер

MAATRIX

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

Что именно нужно перенести

Прежде чем копировать, разложите проект на составные части — тогда ничего не забудется. В типовом Docker-проекте переезжают четыре вещи. Первое — описание инфраструктуры: файлы docker-compose.yml, Dockerfile, конфиги. Это код, он обычно в git и переносится легко. Второе — образы: их можно либо пересобрать на новом сервере из исходников, либо перенести готовыми. Третье и самое важное — данные в томах (volumes): содержимое баз, загруженные файлы, состояние приложений. Именно их теряют чаще всего. Четвёртое — секреты и переменные окружения: файлы .env, пароли, ключи, которые не хранятся в git.

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

Отдельно стоит заранее выписать все нюансы, которые легко упустить в разгар переезда. Проверьте, не привязано ли что-то к конкретным путям на старом сервере — bind-mount на директории хоста переносятся не как именованные тома, а обычным копированием этих папок, и про них часто забывают. Посмотрите на проброс портов и сети: если старый сервер отдавал сервис на определённом внешнем адресе или в связке с другими контейнерами, эту топологию нужно воспроизвести. Учтите и внешние зависимости — задачи в кроне на хосте, сертификаты, права на файлы внутри томов. Полезно составить короткий чек-лист всего, что относится к проекту вне самих контейнеров, и пройтись по нему на новом сервере. Такой список из десятка пунктов экономит часы отладки, потому что переезд ломается обычно не на контейнерах, а именно на этих мелочах вокруг них.

Подготовка на старом сервере

Начните с фиксации состояния. Посмотрите, какие контейнеры и тома есть в проекте, чтобы точно знать, что переносить:

docker compose ps
docker volume ls

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

docker compose down

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

Перенос данных из томов

Самый надёжный способ перенести том — упаковать его содержимое в архив. Запустите временный контейнер, который примонтирует нужный том и заархивирует его в файл:

docker run --rm -v ИМЯ_ТОМА:/data -v $(pwd):/backup alpine \
    tar czf /backup/volume.tar.gz -C /data .

Эта команда монтирует том в контейнер, упаковывает его содержимое в архив в текущей директории и удаляет временный контейнер. Повторите для каждого тома с данными. Затем перенесите архивы, compose-файлы и .env на новый сервер через scp или rsync:

rsync -avz ./ user@новый-сервер:/opt/myproject/

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

Разворачивание на новом сервере

На новом сервере установите Docker и Docker Compose, если их ещё нет, и перейдите в папку проекта. Сначала восстановите тома из архивов — создайте том и распакуйте в него данные тем же приёмом с временным контейнером:

docker volume create ИМЯ_ТОМА
docker run --rm -v ИМЯ_ТОМА:/data -v $(pwd):/backup alpine \
    tar xzf /backup/volume.tar.gz -C /data

После восстановления данных проверьте, что на месте .env со всеми переменными и секретами, и поднимите проект. Docker сам скачает или пересоберёт образы по compose-файлу:

docker compose up -d

Если образы вы решили не пересобирать, а перенести готовыми, используйте docker save для экспорта в архив на старом сервере и docker load для импорта на новом — это полезно, когда сборка долгая или исходников под рукой нет. У пересборки и переноса готового образа есть тонкая разница: при пересборке на новом сервере теги базовых образов могут подтянуться свежее, и поведение слегка изменится, а перенос готового образа гарантирует ровно тот же бинарник, что работал раньше. Для критичных продакшн-переездов чаще выбирают перенос готового образа именно ради предсказуемости, а пересборку оставляют для проектов, где хочется заодно обновить зависимости.

Проверка после переезда

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

docker compose ps
docker compose logs --tail=50

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

Типовые грабли переезда

Несколько ошибок встречаются постоянно, и о них лучше знать заранее. Первая — забыть про тома и перенести только compose-файлы: проект поднимается, но с пустой базой. Вторая — копировать данные работающей базы без остановки, получая повреждённый или несогласованный дамп. Третья — потерять .env, после чего контейнеры падают из-за отсутствующих переменных. Четвёртая — разница версий Docker или образов, из-за которой формат данных не совпадает; поэтому логический дамп базы надёжнее сырого копирования тома. Аккуратный перенос Docker-проекта — штатная часть эксплуатации сервера, и если делать его по шагам с проверкой, переезд проходит без потерь. Для нового места удобно взять VPS у MAATRIX в нужной локации, с оплатой из России картой или криптой и полным root-доступом под Docker.

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