Управляван PostgreSQL в Dockup: пълно ръководство

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

Основният принцип при работа е разделянето: image-ът на приложението може да бъде заменен, данните в PostgreSQL са устойчиви, credentials са secrets, а възстановяването на базата данни трябва да се тества независимо от 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 и включва началeн кредит от $10. Платените планове — Hobby за $5, Pro за $20 на месец — позволяват неограничен брой бази данни, workspace-и и deployments. Потреблението на CPU, RAM и disk се измерва на минута спрямо включения баланс за използване.

Как да свържете приложение сигурно?

Извлечете данните за връзка с базата данни от интерфейса за бази данни на Dockup и третирайте connection string-а като secret. Не го поставяйте в repository-то или в transcript-а на агента.

Задайте го за услугата:

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

dockup deploy production/api --wait --json

Необходимо е redeploy-ване, защото работещият процес е получил environment-а си при стартиране. Запазената стойност се маскира при прочитане на конфигурацията на environment-а.

Конфигурирайте connection pooling-а на приложението целенасочено. Твърде много application workers с големи pools могат да изчерпят database connections, дори когато CPU и memory изглеждат в норма. Задайте размера на pool-а според натоварването и капацитета на базата данни, а не според максималния брой, който framework-ът приема.

Тествайте нова връзка след deployment-а. Health endpoint-ът може да потвърди, че HTTP процесът работи, без да доказва, че може да бъде установена нова database session.

Ръководството за environment variables и secrets разглежда ротацията на credentials и маскирания output.

Как private networking защитава PostgreSQL трафика?

Активирайте private network за проекта:

dockup network enable production --json

Услугите и управляваните бази данни в този проект получават стабилни hostname-и във формат <slug>.internal. Направете redeploy на приложението, за да получите инжектираните вътрешни connection variables.

За да премахнете публичния listener на базата данни и да я направите достъпна само през private network:

dockup db private production/main-db --json

Възстановете публичния и private достъпа, когато е необходимо:

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

Превръщането на базата данни в достъпна само през private network пресъздава контейнера ѝ, като запазва данните. Планирайте и проверете промяната като операция с база данни, а не като безобидна промяна на DNS.

Private networking контролира маршрута, докато PostgreSQL credentials контролират идентичността и оторизацията. Поддържайте и двете. Отделните проекти не могат да се достигат взаимно, защото всеки проект има собствена мрежа.

Статията за private networking и вътрешните домейни представя пълната topology.

Как работят архивирането и възстановяването на PostgreSQL?

Изведете списък със съществуващите backups:

dockup db backups production/main-db --json

Стартирайте server-side backup:

dockup db backup production/main-db --json

Командата за backup създава backup, съобразен с базата данни, а не hot copy на raw volume-а. Запишете ID на backup-а, часа на създаване, версията на базата данни и причината.

Dockup поддържа възстановяване на backups на управлявани бази данни чрез платформата. Текущата CLI reference не документира команда dockup db restore, затова това ръководство не измисля такава. Извършете възстановяването от поддържания интерфейс на Dockup, изберете точния backup, получете одобрение за production и проверете резултата.

Планът за възстановяване трябва да включва:

1. Recovery point и очаквания прозорец на загубени записи.
2. Замразяване на записите от приложението или поведение при maintenance.
3. Съвместимост на базата данни и extensions.
4. Нов backup на текущото състояние, когато е полезно.
5. Отговорник и одобрение за възстановяването.
6. Повторно свързване на приложението и smoke test.
7. Audit и запис на инцидента.

Backups не са доказано надеждни, докато не бъде успешно проведено възстановяване. Използвайте база данни извън production или одобрена recovery среда, за да тествате процедурата.

Съхранявайте backups според одобрена политика. Премахвайте остарелите recovery points само чрез поддържания интерфейс за бази данни, след като проверите, че нито едно изискване за възстановяване или compliance вече не зависи от тях.

Как работят потребителите на PostgreSQL само за четене?

Допълнителните потребители само за четене са полезни за analytics, support investigation, preview deployments и инструменти, които трябва да извършват заявки без запис.

Изведете списък с потребителите:

dockup db users production/main-db --json

Създайте потребител с label:

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

Запазете генерирания credential сигурно по време на създаването и не го възпроизвеждайте в отговор на агента. Оттеглете допълнителния потребител чрез поддържания интерфейс за управление на потребители на базата данни, когато целта му вече не е актуална.

Достъпът само за четене на ниво database permissions е по-надежден от това да кажете на query tool-а „не записвай“. Той все пак позволява достъп до данни от production, които могат да бъдат прочетени, затова се прилагат правилата за privacy и least privilege.

Dockup автоматично създава database user само за четене за PR или branch preview в проект с private networking. Preview-ът може да достигне същата production база данни чрез <slug>.internal и да чете данни без write permission.

Как да наблюдавате размера, логовете и разположението?

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

dockup db size production/main-db --json

Прегледайте runtime логовете на приложението за connection failures, без да разкривате passwords или пълни connection strings:

dockup logs production/api --json

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

Преместете база данни между nodes с целеви node ID:

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

Миграцията е stateful операция. Потвърдете статуса на backup-а, очакванията за maintenance, private-network връзките и проверките на приложението след преместването.

Production checklist за управляван PostgreSQL

Пълният runbook записва:

Област	Задължително доказателство
Идентичност	Точна цел project/db
Свързаност	Secret connection string и тествана нова session
Мрежа	Политика за public, private или private-only достъп
Достъп	Роля на приложението и labeled users само за четене
Капацитет	Текущ размер и преглед на растежа
Backups	Последни backup IDs и retention
Възстановяване	Успешно проведен restore drill
Операции	Одобрение за start, stop, restart и migration
Audit	Промените в базата данни могат да бъдат проследени до конкретен actor

Rollback-ът на deployment-а на приложението не възстановява PostgreSQL. Възстановяването на базата данни не връща автоматично application code-а назад. Координирайте двете само когато съвместимостта на schema-та го изисква.

За по-широки решения за scaling прочетете стратегии за scaling на бази данни. За точните команди използвайте Dockup CLI reference.

Проектирайте schema migrations за deploy и rollback

Deployment-ът на приложението и промяната на database schema-та се случват в различни моменти. Безопасната migration обикновено е backward compatible поне за един release window: добавете nullable column, преди да го направите задължителен, deploy-нете code, който може да работи и с двете schema версии, изпълнете backfill по контролиран процес и премахнете старата структура по-късно.

Не карайте health check-а да изпълнява дълга migration. Ако приложението стартира няколко replicas, уверете се, че само един migration runner може да притежава промяната. PRO container exec command може да изпълни еднократна команда и да предаде реалния ѝ exit code:

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

Използвайте я само когато migration command-ът е прегледан и услугата работи на поддържания main server. Запишете stdout, stderr и exit code. Успешният application deploy не означава, че неуспешна migration може да бъде пренебрегната.

Ротирайте database credentials без прекъсване

Създайте новия credential или потребител само за четене, обновете secret-а на услугата, която го използва, направете redeploy и проверете нова връзка, преди да оттеглите стария credential. Съществуващите connection pools могат да скрият неправилна нова password стойност, докато не се свържат отново.

За основния credential на приложението използвайте поддържания интерфейс на Dockup и политиката за базата данни. За допълнителен аналитичен потребител създайте labeled account само за четене и го предоставете единствено на одобрения consumer.

Записът за rotation трябва да посочва label-а на потребителя, услугите, които го използват, deployment IDs, verification query, часа на оттегляне и audit event-а — никога password-а.

Наблюдавайте растежа, преди да мащабирате

Размерът на базата данни е един от сигналите:

dockup db size production/main-db --json

Съчетайте го с query latency на приложението, броя на connections, поведението на cache-а, продължителността на backups и растежа на storage-а. По-голямото CPU или memory allocation може да не реши проблема с липсващи indexes или queries без ограничение.

Прегледайте стратегии за scaling на бази данни, преди да премествате nodes или да увеличавате ресурсите. Управляваният PostgreSQL намалява работата по provisioning-а, но проектирането на schema и queries остава отговорност на приложението.

Разделяйте наличността от коректността

Работещият database container доказва, че PostgreSQL е наличен, но не и че queries на приложението са коректни. Включете безопасна проверка на нова връзка и представителен read в post-deploy verification. За write test използвайте отделна transaction или test record, който може да бъде безопасно премахнат.

Runbook-ът за управляван PostgreSQL трябва също да посочва дали replicas, analytics users, previews или background workers създават допълнително натоварване върху connections.

Преглеждайте редовно достъпа до PostgreSQL

Изведете списък с допълнителните потребители, потвърдете, че всеки label има активен owner, и премахнете остарелите accounts. Този прост преглед не позволява на достъпа за четене до управлявания PostgreSQL да се натрупва след приключването на previews, analytics projects или support investigations.

Започнете с deployment, който може да бъде проверен

Създайте PostgreSQL база данни извън production, свържете test service чрез masked secret, направете backup и завършете restore drill преди преминаването към production.

Започнете безплатно в app.dockup.ai. Планът Free е $0 на месец, включва началeн кредит от $10 и поддържа едно workspace, три бази данни и три deployments.

Често задавани въпроси

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

Dockup поддържа управлявани бази данни PostgreSQL, MySQL, MongoDB и Redis.

Как приложението трябва да получи своя PostgreSQL connection string?

Третирайте connection string-а като secret environment variable, задайте го за точната услуга и направете redeploy, така че новият контейнер да го получи.

Може ли Dockup да създаде потребител на PostgreSQL само за четене?

Да. Командата за database user-add създава допълнителен потребител само за четене и връща password-а му веднъж при създаването.

Има ли документирана CLI команда dockup db restore?

Текущата CLI reference не документира такава. Dockup поддържа възстановяване на backups чрез интерфейса на платформата, затова използвайте този поддържан път, вместо да измисляте flag или команда.

Възстановява ли rollback-ът на приложението PostgreSQL базата данни?

Не. Историята на application deployments и историята на database backups са отделни recovery системи и трябва да бъдат координирани, когато промените в schema-та изискват и двете.