Керований PostgreSQL у Dockup: повний посібник

Керований PostgreSQL надає застосунку підготовлену базу даних, життєвий цикл якої відокремлений від контейнера сервісу. Dockup підтримує створення, запуск і зупинку, перегляд логів, перевірку розміру, резервне копіювання, відновлення через платформу, користувачів лише для читання, міграцію між вузлами та приватну мережу.

Ключовий операційний принцип — розділення: образ застосунку можна безпечно замінити, дані PostgreSQL зберігаються надійно, облікові дані є секретами, а відновлення бази даних потрібно тестувати окремо від rollback застосунку.

Як створити керовану базу даних PostgreSQL?

Виберіть потрібний workspace, а потім створіть базу даних:

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

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

dockup db list --json

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

dockup db size production/main-db --json

Перш ніж підключати застосунок, дочекайтеся завершення provisioning. Не вгадуйте hostname, порт, username або password за назвою бази даних.

План Free дозволяє створити три бази даних в одному workspace і містить стартовий кредит у розмірі $10. Платні плани — Hobby за $5, Pro за $20 на місяць — дають змогу використовувати необмежену кількість баз даних, workspace і deployment. Споживання CPU, RAM і дискового простору вимірюється щохвилини та списується з доступного балансу.

Як безпечно підключити застосунок?

Отримайте дані для підключення до бази даних в інтерфейсі баз даних Dockup і ставтеся до connection string як до секрету. Не вставляйте його в repository або transcript агента.

Установіть його для сервісу:

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

dockup deploy production/api --wait --json

Повторний deployment потрібен тому, що запущений процес отримав своє оточення під час запуску. Збережене значення маскується під час читання конфігурації оточення.

Налаштовуйте connection pooling застосунку свідомо. Велика кількість application worker із великими pool може вичерпати кількість підключень до бази даних, навіть якщо CPU і пам’ять працюють у межах норми. Визначайте розмір pool на основі навантаження та можливостей бази даних, а не максимальної кількості підключень, яку приймає framework.

Після deployment перевірте нове підключення. Health endpoint може підтвердити, що HTTP-процес працює, але не доводить, що нову database session можна встановити.

У посібнику про змінні оточення та секрети описано ротацію облікових даних і маскований вивід.

Як приватна мережа захищає трафік 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.

Приватна мережа керує маршрутом, а credentials PostgreSQL — ідентифікацією та авторизацією. Потрібні обидва рівні захисту. Окремі проєкти не можуть взаємодіяти між собою, оскільки кожен проєкт має власну мережу.

У статті про приватну мережу та внутрішні домени описано повну topology.

Як працюють резервне копіювання та відновлення PostgreSQL?

Виведіть список наявних backup:

dockup db backups production/main-db --json

Запустіть backup на стороні сервера:

dockup db backup production/main-db --json

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

Dockup підтримує відновлення backup керованих баз даних через платформу. Поточна CLI-документація не описує команду dockup db restore, тому цей посібник її не вигадує. Виконайте відновлення через підтримуваний інтерфейс Dockup, виберіть точний backup, отримайте approval для production і перевірте результат.

План відновлення має містити:

1. Точку відновлення та очікуване вікно втрачених записів.
2. Заморожування запису даних застосунком або режим maintenance.
3. Сумісність бази даних і extension.
4. Свіжий backup поточного стану, якщо це доцільно.
5. Відповідального за відновлення та approval.
6. Повторне підключення застосунку й smoke test.
7. Audit та запис про інцидент.

Backup не можна вважати перевіреним, доки успішно не виконано drill з відновлення. Тестуйте процедуру на непродуктивній базі даних або в погодженому середовищі відновлення.

Зберігайте backup відповідно до затвердженої політики. Видаляйте застарілі точки відновлення лише через підтримуваний інтерфейс бази даних і тільки після перевірки, що жодна вимога щодо відновлення чи compliance більше від них не залежить.

Як працюють користувачі PostgreSQL лише для читання?

Додаткові користувачі лише для читання корисні для analytics, розслідування проблем службою підтримки, preview deployment і інструментів, яким потрібно виконувати запити без запису даних.

Виведіть список користувачів:

dockup db users production/main-db --json

Створіть користувача з label:

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

Безпечно збережіть згенеровані credentials під час створення й не відтворюйте їх у відповіді агента. Коли потреба в додатковому користувачеві зникне, відкличте його через підтримуваний інтерфейс керування користувачами бази даних.

Рівень доступу лише для читання на рівні дозволів бази даних надійніший, ніж вказівка query tool «не виконувати запис». Такий доступ усе одно дає змогу читати production-дані, тому застосовуються правила privacy та least privilege.

Dockup автоматично створює користувача бази даних лише для читання для PR або branch preview у проєкті з приватною мережею. Preview може звертатися до тієї самої production-бази даних за адресою <slug>.internal і читати дані без дозволу на запис.

Як відстежувати розмір, логи та розміщення?

Перевірте розмір на диску:

dockup db size production/main-db --json

Переглядайте runtime-логи застосунку, щоб знаходити помилки підключення, не розкриваючи паролі або повні connection string:

dockup logs production/api --json

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

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

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

Migration — це stateful operation. Перевірте статус backup, очікування щодо maintenance, підключення через приватну мережу та post-move перевірки застосунку.

Чекліст для production керованого PostgreSQL

Повний runbook фіксує:

Область	Обов’язкове підтвердження
Identity	Точна ціль project/db
Connectivity	Secret connection string і перевірена нова session
Network	Політика public, private або private-only
Access	Роль застосунку та користувачі лише для читання з label
Capacity	Поточний розмір і аналіз зростання
Backups	Нещодавні ID backup і строк зберігання
Recovery	Успішний restore drill
Operations	Approval для start, stop, restart і migration
Audit	Зміни бази даних можна пов’язати з конкретним actor

Rollback deployment застосунку не відновлює PostgreSQL. Відновлення бази даних автоматично не виконує rollback коду застосунку. Координуйте обидві операції лише тоді, коли цього вимагає сумісність схеми.

Щоб отримати ширший контекст щодо масштабування, прочитайте про стратегії масштабування баз даних. Для точних команд скористайтеся довідником Dockup CLI.

Проєктуйте міграції схеми з урахуванням deployment і rollback

Deployment застосунку та зміна схеми бази даних відбуваються за різними timeline. Безпечна migration зазвичай має бути backward compatible щонайменше протягом одного release window: спочатку додайте nullable column, не роблячи його обов’язковим, розгорніть код, здатний працювати з обома схемами, виконайте контрольований backfill, а стару структуру видаліть пізніше.

Не змушуйте health check виконувати довгу migration. Якщо застосунок запускає кілька replica, переконайтеся, що лише один migration runner може володіти цією зміною. Команда exec контейнера PRO може виконати одноразову команду й передати її фактичний exit code:

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

Використовуйте її лише тоді, коли команда migration перевірена, а сервіс працює на підтримуваному main server. Збережіть stdout, stderr і exit code. Успішний deployment застосунку не означає, що невдалу migration можна проігнорувати.

Виконуйте ротацію credentials бази даних без простою

Створіть нові credentials або користувача лише для читання, оновіть secret сервісу-споживача, виконайте redeploy і перевірте нове підключення перед відкликанням старих credentials. Наявні connection pool можуть приховувати неправильний новий пароль, доки не буде встановлено повторне підключення.

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

У записі про ротацію потрібно вказати label користувача, сервіси-споживачі, ID deployment, verification query, час відкликання та audit event — але ніколи не пароль.

Відстежуйте зростання перед масштабуванням

Розмір бази даних — лише один із сигналів:

dockup db size production/main-db --json

Доповнюйте цей показник даними про latency запитів застосунку, кількість підключень, поведінку cache, тривалість backup і зростання обсягу сховища. Збільшення CPU або пам’яті може не вирішити проблему відсутніх index чи необмежених запитів.

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

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

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

У runbook керованого PostgreSQL також потрібно зазначити, чи створюють replica, аналітичні користувачі, preview або background worker додаткове навантаження на підключення.

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

Виводьте список додаткових користувачів, перевіряйте, що для кожного label є активний owner, і видаляйте неактуальні облікові записи. Така проста перевірка не дає доступу керованого PostgreSQL лише для читання накопичуватися після завершення preview, аналітичних проєктів або розслідувань служби підтримки.

Почніть із deployment, який можна перевірити

Створіть непродуктивну базу даних PostgreSQL, підключіть тестовий сервіс через замаскований secret, створіть backup і виконайте restore drill до переходу в production.

Почніть безкоштовно на app.dockup.ai. План Free коштує $0 на місяць, містить стартовий кредит у розмірі $10 і підтримує один workspace, три бази даних і три deployment.

FAQ

Які типи керованих баз даних підтримує Dockup?

Dockup підтримує керовані бази даних PostgreSQL, MySQL, MongoDB і Redis.

Як застосунок має отримувати connection string PostgreSQL?

Ставтеся до connection string як до secret environment variable, установіть її для точного сервісу й виконайте redeploy, щоб новий контейнер отримав це значення.

Чи може Dockup створити користувача PostgreSQL лише для читання?

Так. Команда database user-add створює додаткового користувача лише для читання та повертає його пароль один раз під час створення.

Чи існує документована CLI-команда dockup db restore?

Поточна CLI-документація її не описує. Dockup підтримує відновлення backup через інтерфейс платформи, тому використовуйте цей підтримуваний шлях, а не вигадуйте flag або команду.

Чи відновлює rollback застосунку базу даних PostgreSQL?

Ні. Історія deployment застосунку та історія backup бази даних — це окремі системи відновлення, які потрібно координувати, якщо зміни схеми вимагають обох операцій.