Приложение в Docker Compose должно переживать пересоздание контейнеров, обновление и потерю VPS. Для этого нужны постоянное хранилище данных, запас ресурсов и резервная копия, из которой можно восстановить весь проект. Один файл compose.yaml описывает запуск сервисов, но не сохраняет базу данных и загруженные пользователями файлы.

Ниже разобрана работа Docker Compose на одном Linux VPS: как оценить нагрузку, проверить тома, обновить сервисы и подготовить восстановление. Примеры рассчитаны на Docker Engine и современную команду docker compose.

Что подготовить перед настройкой

Понадобятся доступ по SSH, установленный Docker Engine с плагином Compose, права на управление Docker и документация приложения. Проверьте, что образы поддерживают архитектуру VPS: например, amd64 или arm64.

Храните файлы одного проекта в постоянном каталоге, например /srv/myapp. В дальнейших командах app означает приложение, db — базу данных, worker — обработчик фоновых задач. Это условные имена: замените их на названия сервисов своего проекта.

cd /srv/myapp
docker version
docker compose version
docker compose config -q
docker compose config --services

docker version должен показывать сведения о клиенте и сервере Docker. Команда config -q при успешной проверке завершается без вывода; ошибка означает, что сначала нужно исправить YAML, переменные или ссылки на файлы. Последняя команда выводит имена сервисов, которые следует использовать в командах управления.

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

Сколько CPU, RAM и диска нужно

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

• CPU. Учитывайте одновременные запросы, обработку очередей, отчёты и сборку образов. Сборка на рабочем VPS может временно занять процессор, который нужен пользователям.
• RAM. Складывайте потребление сервисов при одновременной нагрузке. Оставляйте память для Linux, Docker, файлового кеша и служебных операций.
• Диск. Считайте данные приложения, базу, образы, логи, кеш сборки и временное место для обновлений и резервных копий.
• Дисковую производительность. Для базы важны задержки и доступные операции ввода-вывода. При выборе NVMe уточняйте также ограничения хранилища выбранного VPS.

Для нагрузочной проверки небольшого API или бота с базой можно рассматривать стартовую конфигурацию с 2 vCPU и 4 ГБ RAM. Это ориентир для проверки, а не обещание вместимости. Поисковому движку, тяжёлой аналитике или обработке больших файлов может потребоваться значительно больше.

Условный расчёт памяти: приложение потребляет до 700 МБ, база — 1,1 ГБ, обработчик задач — 800 МБ, остальные контейнеры — 200 МБ. Вместе получается около 2,8 ГБ. После добавления расходов ОС и Docker сервер с 4 ГБ оставляет небольшой запас. Если пики совпадают, имеет смысл проверить конфигурацию с большим объёмом RAM или уменьшить параллелизм фоновых заданий.

Для диска используйте такой расчёт:

Рабочие данные + образы + логи + кеш сборки
+ временные файлы обновления + локальная копия перед отправкой
+ ожидаемый прирост данных

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

Как проверить, хватает ли ресурсов

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

docker stats --no-stream
free -h
df -h
df -i
docker system df -v

docker system df -v помогает найти крупные образы, контейнеры и тома, но не заменяет проверку всего диска. Данные в bind mounts, системные журналы и резервные копии нужно учитывать отдельно.

Один запуск docker stats показывает текущую ситуацию. Для подбора тарифа и обнаружения утечек памяти нужна история показателей хотя бы за характерный рабочий цикл проекта.

Как ограничить память, CPU и размер логов

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

services:
  app:
    restart: unless-stopped
    cpus: "1.0"
    mem_limit: 1g
    logging:
      driver: json-file
      options:
        max-size: "10m"
        max-file: "3"

Это дополнение к рабочему Compose-файлу, а не полный пример запуска. Значения CPU и памяти условные: сначала измерьте потребление своего приложения.

cpus: "1.0" ограничивает доступное контейнеру процессорное время примерно одним CPU. mem_limit: 1g устанавливает предел оперативной памяти. Эти параметры не резервируют дополнительные ресурсы и не увеличивают мощность VPS. Слишком низкий предел памяти может привести к завершению процессов внутри контейнера.

Настройки логирования включают ротацию: Docker будет хранить до трёх файлов с порогом ротации 10 МБ. Это относится к стандартному выводу и выводу ошибок контейнера. Файлы, которые приложение самостоятельно пишет в каталог с данными, требуют собственной ротации.

После применения изменений через пересоздание контейнера проверьте фактические настройки:

docker inspect "$(docker compose ps -q app)" \
  --format 'RAM={{.HostConfig.Memory}} CPU={{.HostConfig.NanoCpus}} Logs={{json .HostConfig.LogConfig}}'

Для приведённого примера ожидаются RAM=1073741824, CPU=1000000000 и указанные параметры логирования. Если ограничения не применились, проверьте выбранный сервис, используемые Compose-файлы и предупреждения Docker.

При неожиданном завершении контейнера дополнительно посмотрите:

docker inspect "$(docker compose ps -a -q app)" \
  --format 'OOMKilled={{.State.OOMKilled}} ExitCode={{.State.ExitCode}}'

docker compose logs --tail=100 app

OOMKilled=true означает, что Docker зафиксировал завершение из-за нехватки памяти. Один код 137 этого не доказывает: процесс мог получить принудительный сигнал завершения по другой причине. Сопоставьте состояние контейнера, логи и показатели VPS.

Где хранить данные, чтобы они пережили обновление

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

Само наличие раздела volumes: ещё не означает, что база сохранена правильно. Если том подключён к каталогу, которым база не пользуется, реальные данные могут оказаться в другом месте. Точный путь берите из документации выбранного образа и его версии.

Посмотрите реальные подключения контейнера базы:

docker inspect "$(docker compose ps -a -q db)" \
  --format '{{json .Mounts}}'

docker volume ls

В выводе Mounts поле Destination должно совпадать с каталогом данных внутри контейнера. Source показывает источник на хосте, а Name у именованного тома — его имя. Сохраните эти сведения в инструкции по восстановлению.

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

Также сохраняйте имя Compose-проекта. По умолчанию оно связано с каталогом проекта: перенос файлов в другую папку может привести к созданию другого набора томов. Для нового проекта удобно заранее задать верхнеуровневый параметр name:. У существующего сначала проверьте имя через docker compose ls и сохраните его; учитывайте, что -p и COMPOSE_PROJECT_NAME могут его переопределять.

Для заранее созданного тома можно использовать external: true и явно указать его name:. Тогда Compose сообщит об отсутствии тома вместо автоматического создания нового. Это управление жизненным циклом тома, а не резервная копия и не защита от его ручного удаления.

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

Автозапуск и несколько проектов на одном VPS

Команда docker compose up -d оставляет сервисы работать после закрытия SSH-сессии. Политика restart: unless-stopped позволяет Docker перезапускать контейнеры, но сохраняет намеренную ручную остановку: после docker compose stop такой контейнер не начнёт работать сам только из-за перезагрузки VPS.

На обычном Linux с systemd проверьте автозапуск Docker командой systemctl is-enabled docker. Если служба отключена, включите её через sudo systemctl enable docker. Перезагрузку для проверки проводите в согласованное время, после подготовки резервной копии.

Добавьте предусмотренный разработчиком приложения healthcheck — проверку работоспособности. Для ожидания готовности базы при запуске Compose используется depends_on с условием service_healthy. Однако статус unhealthy сам по себе не заставляет обычный Docker перезапустить контейнер, а приложение всё равно должно уметь повторно подключаться к базе после сбоев.

Несколько проектов размещайте в отдельных каталогах с разными именами проектов, томами и путями данных. Не задавайте одинаковые container_name и опубликованные порты.

Для нескольких сайтов обычно используют один обратный прокси, который принимает HTTPS и направляет запросы нужному приложению по домену. Базе данных, доступной только контейнерам своей сети, публикация порта через ports: обычно не нужна.

Если прокси работает на самом VPS, порт приложения можно привязать к 127.0.0.1. Если прокси находится в контейнере, соединение обычно организуют через общую Docker-сеть и имя сервиса. Внутри контейнера localhost указывает на него самого.

Проверяйте доступность опубликованных портов с другой машины. Одних правил UFW недостаточно для уверенности: Docker настраивает собственную обработку сетевого трафика.

Как обновлять Compose-проект

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

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

Посмотреть используемые образы можно через docker compose images. Для выбранного идентификатора образа команда docker image inspect IMAGE_ID --format '{{json .RepoDigests}}' покажет доступные ссылки с digest. Вместо IMAGE_ID подставьте реальный идентификатор. У локально собранного образа список может быть пустым: такой образ нужно отдельно сохранить или разместить в своём реестре.

1. Сохраните текущие Compose-файлы, переменные, версии образов и необходимые конфигурационные файлы.
2. Сделайте согласованную резервную копию данных. Для значимого обновления заранее проверьте восстановление.
3. Измените тег или digest только тех образов, которые планируете обновить.
4. Проверьте конфигурацию, скачайте образы и примените изменения.
5. Проверьте приложение и данные до завершения работ.

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

docker compose config -q
docker compose pull
docker compose up -d --wait --wait-timeout 120
docker compose ps -a
docker compose logs --tail=100

Время ожидания 120 секунд приведено как пример. Если приложение запускается дольше, задайте подходящий срок. При наличии healthcheck Compose ждёт его успешного результата; без него проверяет состояние запуска. Это не заменяет вход в приложение, чтение старых данных и тестовую запись.

Если приложение собирается через build:, одного pull недостаточно: нужен новый образ, например после docker compose build app, и затем его запуск. На нагруженном VPS удобнее собирать образ отдельно. Исключайте секреты, пользовательские данные и резервные копии из контекста сборки через .dockerignore.

При пересоздании единственного экземпляра приложения возможен перерыв в обслуживании. Сам по себе Compose на одном VPS не обеспечивает обновления без простоя.

Что делать, если обновление не удалось

Сначала посмотрите docker compose ps -a и логи проблемного сервиса. Ошибка скачивания образа, неправильная переменная, недоступная база и неудачная миграция требуют разных действий.

Если данные не менялись и предыдущая версия совместима с текущей схемой базы, верните сохранённые настройки и прежний образ, затем выполните docker compose up -d. Проверьте результат теми же действиями, что и после обновления.

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

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

Что должно входить в резервную копию

Файл .env не становится резервной копией только потому, что лежит рядом с Compose. Он также не передаёт автоматически все свои переменные внутрь каждого контейнера: передачу определяют environment:, env_file: и настройки сервисов.

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

Том на том же VPS не защищает от потери сервера. Команда docker export тоже не заменяет бэкап проекта: подключённые volumes в экспорт не входят.

Не архивируйте файлы работающей базы обычным tar в расчёте на гарантированное восстановление. Используйте поддерживаемый СУБД механизм резервного копирования. Копирование файлов полностью остановленной базы и согласованные снимки допустимы при соблюдении требований конкретной СУБД.

SQL-файл, подключённый к /docker-entrypoint-initdb.d, у распространённых официальных образов баз используется для первоначальной инициализации. Он не обновляется автоматически при изменении базы и не становится свежим дампом при остановке контейнера.

Пример: копия PostgreSQL и загруженных файлов

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

Условия примера:

• проект находится в /srv/myapp и использует compose.yaml и .env без дополнительных конфигурационных файлов;
• сервис PostgreSQL называется db, база — appdb, роль с необходимыми правами — appuser;
• пользовательские файлы находятся в bind mount /srv/myapp/uploads;
• запись выполняют app и worker; другие источники записи на время копии отключены;
• у администратора есть доступ к Docker, файлам проекта и каталогу резервных копий.

Сначала проверьте подключение к базе:

docker compose exec -T db psql -w -U appuser -d appdb -c 'SELECT 1;'

Ожидается одна строка со значением 1. Если требуется пароль, заранее настройте штатную аутентификацию, например защищённый файл .pgpass в контейнере. Параметр -w запрещает интерактивный запрос пароля, поэтому ошибка доступа будет видна сразу.

Переведите приложение в режим обслуживания, дождитесь завершения текущих операций и остановите процессы записи:

docker compose stop app worker
docker compose ps -a

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

(
  set -eu
  umask 077
  cd /srv/myapp
  mkdir -p /srv/backups
  bkp_dir=$(mktemp -d /srv/backups/myapp-XXXXXXXX)

  cp compose.yaml .env "$bkp_dir/"
  docker compose images > "$bkp_dir/images.txt"
  docker compose exec -T db pg_dump -w -U appuser -d appdb -Fc > "$bkp_dir/appdb.dump.part"
  test -s "$bkp_dir/appdb.dump.part"
  mv "$bkp_dir/appdb.dump.part" "$bkp_dir/appdb.dump"
  docker compose exec -T db pg_restore --list < "$bkp_dir/appdb.dump" > /dev/null
  tar -czf "$bkp_dir/uploads.tar.gz" -C /srv/myapp uploads

  (
    cd "$bkp_dir"
    sha256sum compose.yaml .env images.txt appdb.dump uploads.tar.gz > SHA256SUMS
  )
  printf 'Backup directory: %s\n' "$bkp_dir"
)

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

pg_dump делает согласованный дамп базы. Остановка процессов записи нужна здесь для согласования базы с файлами загрузок. Проверка pg_restore --list подтверждает чтение каталога дампа, но полноценное восстановление ещё предстоит проверить.

После успешного копирования возобновите работу:

docker compose start app worker
docker compose ps -a

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

Если у проекта есть дополнительные тома, конфигурационные файлы или внешнее хранилище, добавьте их в комплект. Для пользовательских файлов в named volume используйте резервное копирование этого тома через отдельный контейнер с подключением источника только для чтения. Путь /srv/myapp/uploads в таком случае неприменим.

Один pg_dump не сохраняет глобальные роли и табличные пространства PostgreSQL. Если они нужны для восстановления, предусмотрите отдельный экспорт через pg_dumpall --globals-only с подходящими административными правами. Для большой рабочей базы или восстановления на конкретный момент времени нужна отдельная схема физических копий и архивирования журнала WAL.

Где хранить копии и как часто их делать

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

После передачи перейдите в каталог полученного комплекта и выполните:

sha256sum -c SHA256SUMS

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

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

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

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

В бюджет включайте внешний объём хранения, передачу данных, временный сервер для проверки и работу администратора. Для размещения проекта можно подобрать VPS HSTQ по измеренным потребностям CPU, RAM и диска. Если нужно поручить настройку обновлений, мониторинга и бэкапов инженеру, согласуйте состав работ в рамках администрирования HSTQ. Базовая поддержка VPS не включает постоянное сопровождение приложений.

Как проверить восстановление после потери VPS

Проверяйте восстановление на отдельном VPS. Если используете тот же сервер, одного нового имени проекта недостаточно: явно именованные и external volumes, абсолютные bind mounts и опубликованные порты могут остаться общими с рабочей системой.

1. Получите копию и проверьте контрольные суммы. Сохраните исходный архив неизменным.
2. Восстановите конфигурацию и доступ к образам. Для первой проверки используйте те же версии приложения и СУБД. Обновление проводите отдельно.
3. Подготовьте отдельные тома и каталоги. Проверьте все Source, Destination и имена хранилищ.
4. Отключите реальные внешние действия. Тестовая копия не должна отправлять письма и SMS, проводить платежи, принимать рабочие вебхуки или запускать боевые задания по расписанию.
5. Восстановите базу и файлы до запуска приложения. Не позволяйте приложению заранее заполнить новую базу своей схемой.

Для приведённого примера разместите полученный комплект в /srv/restore-copy, а рабочую конфигурацию тестового проекта — в /srv/myapp. Запустите только базу:

cd /srv/myapp
docker compose config -q
docker compose up -d db

Дождитесь готовности PostgreSQL по его журналу или healthcheck. Перед импортом должны существовать роль appuser и пустая база appdb с необходимыми правами. Их создают исходные параметры инициализации образа либо администратор. Если используются дополнительные роли или расширения, подготовьте их до восстановления.

Только в эту отдельную пустую базу импортируйте дамп, затем распакуйте загрузки в новый каталог проекта:

docker compose exec -T db pg_restore -w -U appuser -d appdb \
  --exit-on-error --single-transaction < /srv/restore-copy/appdb.dump

tar --numeric-owner -xzf /srv/restore-copy/uploads.tar.gz -C /srv/myapp

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

Проверьте владельцев и права распакованных файлов. Процесс приложения должен иметь нужный доступ по своим UID и GID. Не исправляйте ошибки доступа общим chmod 777.

После подготовки данных запустите приложение с тестовой конфигурацией:

docker compose up -d app
docker compose ps -a
docker compose logs --tail=100 app db

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

docker compose up -d --no-deps --force-recreate app

Повторно откройте старые и только что созданные данные. Так проверяется, что они действительно находятся в постоянном хранилище.

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

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