# Размещение приложения Docker Compose и PostgreSQL на VPS

[Соответствующая веб-страница](https://wisphost.com/ru/blog/docker-compose-postgresql-vps/)

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

От WispHost. Опубликовано 2026-11-03.

Тема: Инфраструктура.

## Краткий ответ

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

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

## Разделите три сервиса

Объявите HTTPS-прокси, приложение и сервис PostgreSQL с именем db. Свяжите прокси с приложением в первой сети, затем приложение с db во второй. Так у прокси нет прямого доступа к базе. Из контейнера приложения SQL-подключение направлено на db на порт 5432. Адрес localhost указывал бы на сам контейнер приложения.

## Сохраняйте базу при пересоздании контейнера

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

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

Добавьте в db проверку доступности с pg_isready. Условие service_healthy позволяет Compose дождаться этого результата перед запуском приложения. Проверьте также прерывание после запуска. Приложение должно переоткрыть соединение, когда PostgreSQL вернётся. Затем выполните чтение и запись через HTTPS, чтобы проверить весь путь.

## Выбирайте размер по собственным замерам

Wisp Spark предоставляет 2 vCPU, 4 ГБ RAM и 60 ГБ NVMe. Wisp Core предлагает 3 vCPU, 8 ГБ и 120 ГБ. Если ваш тест достигает 5 ГБ RAM для всей машины, Spark уже слишком мал для такой нагрузки. Для диска сложите данные, индексы, образы контейнеров Docker, журналы и временное место для восстановления.

## Восстановите до первого заказа клиента

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

## Решите, достаточно ли одной машины

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

## Источники и ссылки

- [Docker — сети и обнаружение сервисов в Compose](https://docs.docker.com/compose/how-tos/networking/)
- [Docker — порядок запуска и проверка доступности](https://docs.docker.com/compose/how-tos/startup-order/)
- [PostgreSQL — логический экспорт и восстановление](https://www.postgresql.org/docs/current/backup-dump.html)

## Ваш следующий шаг

[Сравнить VPS для вашего приложения Docker](https://wisphost.com/ru/vps/)

## Читайте далее

- [Сколько vCPU, RAM и хранилища предусмотреть для VPS?](https://wisphost.com/ru/blog/vps-resource-sizing/)
- [Снимок, резервное копирование и RAID: в чём различия для ваших данных?](https://wisphost.com/ru/blog/snapshots-vs-backups/)

[Все руководства WispHost](https://wisphost.com/ru/blog/)