Docker Compose на новом VPS: перенос контейнеров, томов и окружения

Найдите источник каждого постоянного файла

Сначала сопоставьте сервисы из compose-файла с местом хранения их данных. Named volume управляется Docker, bind mount указывает на конкретный путь хоста, а запись только в writable layer контейнера может исчезнуть при пересоздании контейнера. Проверьте `volumes`, `binds`, точки монтирования, tmpfs и локальные каталоги приложения. Для каждого пути укажите владельца данных и способ создать проверяемую копию.

Запишите также имя проекта Compose, пользовательскую сеть, порты, healthcheck, restart policy и зависимости между сервисами. Не включайте в общую копию файлы `.env` и секреты без отдельной защиты. Изучите, где приложение ожидает сертификаты, конфигурации и локальные логи. Для базы данных предпочтителен её штатный backup, а не копирование файлов живого контейнера без гарантии согласованности.

• Разделите данные БД, загрузки, кэш и временные файлы.
• Определите named volumes и bind mounts.
• Найдите локальные файлы конфигурации и сертификатов.
• Проверьте архитектуру образов и платформу нового VPS.

Подготовьте compose-проект на новой площадке

Перенесите исходный код, Compose-файл, Dockerfile, lock-файлы зависимостей и декларативные конфигурации. Образы можно получить из закрытого registry или собрать на целевом VPS, если у вас есть исходники и сборочная среда. Проверьте, что тег образа закреплён версией или digest, а не `latest`, иначе на новой машине можно незаметно запустить более свежую версию, чем на источнике.

Сверьте версии Docker Engine и Compose, используемые параметры и доступность registry. Если сборка требует секретов, подключайте их безопасно в момент build или запуска; не добавляйте ключи в image layer и репозиторий. До теста не назначайте контейнеру production-домен и не разрешайте внешним пользователям менять состояние. Отдельно убедитесь, что диска хватит и для образов, и для томов, и для временной распаковки резервов.

• Зафиксируйте конкретные версии образов.
• Проверьте права на каталоги bind mounts.
• Создайте внешние сети и нужные volumes заранее.
• Убедитесь, что registry доступен из нового дата-центра.

Скопируйте volumes и базу без потери целостности

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

Для больших каталогов сначала выполните предварительную синхронизацию, затем организуйте финальный дельта-копирующий проход после паузы записи. После восстановления проверьте владельца и права файлов внутри контейнера: UID/GID образа могут отличаться от старого сервера. Compose может автоматически создать пустой volume с новым именем, поэтому проверьте фактическую привязку через `docker inspect`, прежде чем запускать сервисы, которые пишут в хранилище.

• Сохраните содержимое каждого volume отдельно.
• Проверьте права с UID/GID внутри образа.
• Сверьте размер и хеш выборочных резервов.
• Перед стартом БД убедитесь, что подключён нужный восстановленный том.

Проведите запуск без production-пользователей

Запустите проект на тестовом порту или внутреннем имени и проверяйте по очереди: контейнеры healthy, приложение видит базу, файлы доступны, фоновые jobs не повторяют production-операции. Проверяйте не только `docker compose ps`, но и журналы каждого важного сервиса и короткий пользовательский путь. С тестовой копии выключите отправку реальных уведомлений, выполнение платежей и интеграции, которые могут повторно выполнить внешнее действие.

Если сервис зависит от домена, протестируйте его через временную запись или локальный hosts-файл, сохранив тот же Host-заголовок и TLS-сценарий, когда это необходимо. Не меняйте рабочие DNS для первого запуска. Проверьте автоматический перезапуск после контролируемого перезапуска одного контейнера в тесте; этим проверяется порядок старта, но не поведение всего VPS при отказе.

• Проверьте healthchecks и последовательность зависимостей.
• Сверьте чтение/запись в базе и файловом томе.
• Убедитесь, что worker не обрабатывает старую очередь параллельно.
• Отключите побочные production-интеграции на тесте.

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

В короткое окно перехода остановите фоновые процессы на старой машине, дождитесь завершения текущих задач и сделайте финальную копию изменяемых данных. Затем запустите новый Compose-проект, проверьте внутреннюю готовность и поменяйте DNS или upstream прокси. Для сервиса с очередью важны блокировки и idempotency: если старый и новый worker одновременно получают одно событие, один и тот же заказ может обработаться дважды.

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

• Остановите старые workers прежде, чем запустить новые.
• Проверьте DNS, TLS, прокси и внешние callback-адреса.
• Сверьте свежие записи и очередь задач.
• Не удаляйте старые volumes до окончания проверки.

Какой VPS подходит для Compose-проекта

Составьте список сервисов и измерьте ресурсы на рабочем проекте: память каждого контейнера, пиковую нагрузку CPU, дисковый объём, интенсивность чтения/записи и сетевой обмен. При переносе временно понадобятся место для образов, архивов и восстановленных томов. Уточните у провайдера ограничения по исходящему трафику, способу увеличения диска и доступу к snapshot. Не считайте набор vCPU единственным критерием: медленный диск способен задержать восстановление базы и обработку файлов.

Рейтинг ниже сохраняет порядок провайдеров из <a href="https://impossible-studio.com/vps-vds/vps-vds-dlya-proekta-s-vebhukami-kak-ne-teryat-vhodyashhie-sobytiya-i-obrabatyvat-ih-bez-zaderzhek/">обзора VPS/VDS для проекта с вебхуками</a>. Для Docker Compose сопоставьте тарифы по нужному объёму диска, возможности отдельной копии, сетевым ограничениям и удобству восстановления. Проверяйте актуальные параметры конкретного плана перед заказом, не выводя их из названия провайдера.

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

Переменные окружения и секреты: отдельный план переноса

Составьте перечень конфигурации по приложениям: переменные окружения, секреты CI/CD, параметры контейнеров, пользовательские файлы и DNS. Разделите обычные настройки и учётные данные. Не отправляйте `.env` в общий чат, не храните секреты в git и не оставляйте их в каталоге, доступном веб-серверу. На новом хосте создайте новые ключи там, где это допустимо, и отзовите старые после проверки переключения.

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

• Разделите настройки и секреты.
• Проверьте владельца, права и путь к каждому файлу.
• Обновите allowlist IP и callback URL у интеграций.
• Отзовите старые секреты после успешной проверки.

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

Нужно ли переносить образы контейнеров вместе с VPS?

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

Исчезнут ли данные, если удалить контейнер?

Named volume обычно живёт независимо от контейнера, но запись в writable layer может потеряться при удалении. Перед переносом проверьте реальные mounts.

Можно ли сначала запустить новый Compose параллельно старому?

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

Документация и полезные источники

• Docker Docs: volumes
• Docker Docs: storage

Материал проверен 12 ноября 2026 года. Условия провайдеров, версии программ и DNS-настройки могут меняться — сверяйте актуальные данные перед выполнением переноса.