Управляемый PostgreSQL в Dockup: полное руководство

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

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

Как создать управляемую базу данных PostgreSQL?

Выберите нужное рабочее пространство и создайте базу данных:

dockup db create \
  --name main-db \
  --type postgresql \
  --json

Выведите список баз данных, чтобы проверить точный slug и статус:

dockup db list --json

В операциях с базами данных используются цели в формате project/db:

dockup db size production/main-db --json

Дождитесь завершения подготовки базы данных и только после этого подключайте приложение. Не пытайтесь угадать hostname, port, username или password по имени базы данных.

Тариф Free позволяет создать три базы данных в одном рабочем пространстве и включает стартовый кредит в размере $10. Платные тарифы — Hobby за $5, Pro за $20 в месяц — позволяют создавать неограниченное количество баз данных, рабочих пространств и deployments. Потребление CPU, RAM и дискового пространства рассчитывается поминутно и вычитается из доступного баланса.

Как безопасно подключить приложение?

Получите данные для подключения к базе данных через интерфейс базы данных Dockup и обращайтесь со строкой подключения как с секретом. Не вставляйте её в репозиторий или transcript агента.

Установите её для сервиса:

dockup env set DATABASE_URL="$DATABASE_URL" \
  --secret \
  -s production/api \
  --json

dockup deploy production/api --wait --json

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

Настройте connection pooling приложения осознанно. Слишком большое количество worker-процессов с большими pool может исчерпать число подключений к базе данных, даже если CPU и память используются нормально. Определяйте размер pool с учётом нагрузки и возможностей базы данных, а не максимального значения, которое допускает framework.

После deployment проверьте новое подключение. Health endpoint может подтвердить, что HTTP-процесс работает, но не доказать, что новая сессия базы данных действительно устанавливается.

В руководстве переменные окружения и секреты описана ротация учётных данных и маскирование вывода.

Как приватная сеть защищает трафик PostgreSQL?

Включите приватную сеть проекта:

dockup network enable production --json

Сервисы и управляемые базы данных в этом проекте получают стабильные hostname вида <slug>.internal. Выполните повторный deployment приложения, чтобы получить внедрённые внутренние переменные подключения.

Чтобы удалить публичный listener базы данных и оставить только приватный доступ:

dockup db private production/main-db --json

Чтобы при необходимости восстановить публичный и приватный доступ:

dockup db private production/main-db --off --json

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

Приватная сеть управляет маршрутом, а учётные данные PostgreSQL — идентификацией и авторизацией. Не пренебрегайте ни тем, ни другим. Разные проекты не могут обращаться друг к другу, поскольку у каждого проекта своя сеть.

В статье приватная сеть и внутренние домены описана полная топология.

Как работают резервное копирование и восстановление PostgreSQL?

Выведите список существующих резервных копий:

dockup db backups production/main-db --json

Запустите резервное копирование на стороне сервера:

dockup db backup production/main-db --json

Команда backup создаёт резервную копию с учётом структуры базы данных, а не горячую копию необработанного тома. Зафиксируйте ID резервной копии, время создания, версию базы данных и причину создания.

Dockup поддерживает восстановление управляемых баз данных из резервных копий через платформу. В текущей справке CLI команда dockup db restore не описана, поэтому в этом руководстве мы не будем её выдумывать. Выполните восстановление через поддерживаемый интерфейс Dockup, выберите нужную резервную копию, получите одобрение для production и проверьте результат.

План восстановления должен включать:

1. Точку восстановления и ожидаемое окно потери записей.
2. Заморозку записи в приложении или порядок работы в режиме обслуживания.
3. Совместимость базы данных и extensions.
4. Свежую резервную копию текущего состояния, если она необходима.
5. Ответственного за восстановление и согласование операции.
6. Повторное подключение приложения и smoke test.
7. Аудит и запись об инциденте.

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

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

Как работают пользователи PostgreSQL только для чтения?

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

Выведите список пользователей:

dockup db users production/main-db --json

Создайте пользователя с label:

dockup db user-add production/main-db \
  --label analytics \
  --json

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

Ограничение на запись на уровне разрешений базы данных надёжнее, чем указание query tool «не выполнять запись». При этом пользователь всё равно получает доступ к доступным для чтения production-данным, поэтому необходимо соблюдать требования к приватности и принцип минимальных привилегий.

Dockup автоматически создаёт пользователя базы данных только для чтения для PR или branch preview в проекте с приватной сетью. Preview может обращаться к той же production-базе данных по адресу <slug>.internal и читать данные, не получая права на запись.

Как отслеживать размер, логи и размещение?

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

dockup db size production/main-db --json

Проверьте runtime-логи приложения на наличие ошибок подключения, не раскрывая пароли или полные строки подключения:

dockup logs production/api --json

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

Перенесите базу данных между узлами, указав ID целевого узла:

dockup db migrate production/main-db \
  --node <nodeId> \
  --json

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

Чек-лист управляемого PostgreSQL для production

Полный runbook должен содержать:

Область	Обязательное подтверждение
Идентификация	Точная цель project/db
Подключение	Секретная строка подключения и проверенная новая сессия
Сеть	Политика публичного, приватного или только приватного доступа
Доступ	Роль приложения и пользователи только для чтения с label
Ёмкость	Текущий размер и анализ роста
Резервные копии	Недавние ID резервных копий и политика хранения
Восстановление	Успешно выполненное тестовое восстановление
Операции	Согласование запуска, остановки, перезапуска и миграции
Аудит	Изменения базы данных, привязанные к конкретному пользователю

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

Для более общих решений по масштабированию прочитайте статью стратегии масштабирования баз данных. Точные команды приведены в справке Dockup CLI.

Проектируйте миграции схемы с учётом deployment и rollback

Deployment приложения и изменение схемы базы данных происходят по разным графикам. Безопасная миграция обычно должна сохранять обратную совместимость как минимум в течение одного окна релиза: сначала добавьте nullable-колонку, затем разверните код, поддерживающий обе схемы, выполните backfill контролируемым способом и удалите старую структуру позже.

Не заставляйте health check выполнять длительную миграцию. Если приложение запускает несколько replicas, убедитесь, что только один migration runner может выполнять это изменение. Команда exec контейнера PRO может запустить одноразовую команду и передать её фактический exit code:

dockup exec "npm run migrate" \
  -s production/api \
  --json

Используйте её только после проверки migration command и при работе сервиса на поддерживаемом основном сервере. Сохраните stdout, stderr и exit code. Успешный deployment приложения не означает, что неудачную миграцию можно проигнорировать.

Выполняйте ротацию учётных данных базы данных без простоя

Создайте новые учётные данные или пользователя только для чтения, обновите секрет consuming service, выполните redeploy и проверьте новое подключение, прежде чем отзывать старые учётные данные. Существующие connection pool могут скрыть неправильный новый пароль до момента повторного подключения.

Для основных учётных данных приложения используйте поддерживаемый интерфейс Dockup и политику базы данных. Для дополнительного аналитического пользователя создайте учётную запись только для чтения с label и передайте её только одобренному consumer.

В записи о ротации должны быть указаны label пользователя, consuming services, ID deployments, verification query, время отзыва и событие аудита — но никогда не сам пароль.

Отслеживайте рост перед масштабированием

Размер базы данных — лишь один из показателей:

dockup db size production/main-db --json

Учитывайте также latency запросов приложения, количество подключений, работу cache, длительность backup и рост объёма хранилища. Увеличение выделенных CPU или памяти может не решить проблему отсутствующих индексов или неограниченных запросов.

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

Разделяйте доступность и корректность

Работающий контейнер базы данных подтверждает доступность PostgreSQL, но не корректность запросов приложения. В post-deploy проверку включите безопасное новое подключение и показательный read-запрос. Для write-теста используйте отдельную транзакцию или тестовую запись, которую можно безопасно удалить.

В runbook для управляемого PostgreSQL также следует указать, создают ли replicas, пользователи аналитики, previews или background workers дополнительную нагрузку на подключения.

Регулярно проверяйте доступ к PostgreSQL

Выведите список дополнительных пользователей, убедитесь, что за каждым label закреплён действующий владелец, и удалите устаревшие учётные записи. Такая простая проверка не позволяет доступу на чтение в управляемом PostgreSQL накапливаться после завершения работы previews, аналитических проектов или расследований службы поддержки.

Начните с deployment, который можно проверить

Создайте непроизводственную базу данных PostgreSQL, подключите тестовый сервис через замаскированный секрет, создайте резервную копию и выполните тестовое восстановление до переключения production.

Начните бесплатно на app.dockup.ai. Тариф Free стоит $0 в месяц, включает стартовый кредит в размере $10 и поддерживает одно рабочее пространство, три базы данных и три deployments.

FAQ

Какие типы управляемых баз данных поддерживает Dockup?

Dockup поддерживает управляемые базы данных PostgreSQL, MySQL, MongoDB и Redis.

Как приложение должно получать строку подключения к PostgreSQL?

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

Может ли Dockup создать пользователя PostgreSQL только для чтения?

Да. Команда добавления пользователя базы данных создаёт дополнительного пользователя только для чтения и возвращает его пароль один раз — при создании.

Существует ли документированная CLI-команда dockup db restore?

В текущей справке CLI такая команда не описана. Dockup поддерживает восстановление резервных копий через интерфейс платформы, поэтому используйте этот поддерживаемый способ, а не придумывайте flag или команду.

Восстанавливает ли откат приложения базу данных PostgreSQL?

Нет. История deployment приложения и история резервных копий базы данных — это отдельные системы восстановления. Их необходимо координировать, если изменения схемы требуют отката обоих компонентов.