Spravovaný PostgreSQL na Dockup: kompletní průvodce

Spravovaný PostgreSQL poskytuje aplikaci zřízenou databázi s operacemi životního cyklu, které jsou oddělené od kontejneru služby. Dockup podporuje vytváření, spouštění a zastavování, logy, kontrolu velikosti, zálohy, obnovu prostřednictvím platformy, uživatele pouze pro čtení, migraci mezi nody a privátní síťování.

Základním provozním principem je oddělení: image aplikace je postradatelný, data PostgreSQL jsou trvalá, přihlašovací údaje jsou secrets a obnovu databáze je nutné testovat nezávisle na rollbacku aplikace.

Jak vytvořit spravovanou databázi PostgreSQL?

Vyberte požadovaný workspace a poté databázi vytvořte:

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

Výpisem databází ověřte přesný slug a stav:

dockup db list --json

Operace s databázemi používají cíle ve formátu project/db:

dockup db size production/main-db --json

Před připojením aplikace počkejte na dokončení provisioningu. Název hostitele, port, uživatelské jméno ani heslo neurčujte odhadem podle názvu databáze.

Tarif Free umožňuje mít v jednom workspace tři databáze a zahrnuje počáteční kredit 10 $. Placené tarify — Hobby za 5 $, Pro za 20 $ měsíčně — umožňují neomezený počet databází, workspaceů a deploymentů. Spotřeba CPU, RAM a disku se měří po minutách a odečítá se ze zůstatku zahrnutého využití.

Jak bezpečně připojit aplikaci?

Získejte podrobnosti připojení k databázi z databázového rozhraní Dockup a s connection stringem zacházejte jako se secretem. Nevkládejte ho do repozitáře ani do transcriptu agenta.

Nastavte ho pro službu:

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

dockup deploy production/api --wait --json

Redeploy je nutný, protože běžící proces obdržel své environment při startu. Uložená hodnota se při načtení konfigurace prostředí maskuje.

Nastavte connection pooling aplikace záměrně. Příliš mnoho workerů aplikace s velkými pooly může vyčerpat databázová připojení, i když CPU a paměť vypadají v pořádku. Velikost poolu odvoďte od workloadu a kapacity databáze, nikoli od maximálního počtu, který přijímá framework.

Po deploymentu otestujte nové připojení. Health endpoint může potvrdit, že HTTP proces běží, aniž by prokázal, že lze navázat novou databázovou session.

Průvodce environment variables a secrets popisuje rotaci přihlašovacích údajů a maskovaný výstup.

Jak privátní síťování chrání provoz PostgreSQL?

Povolte privátní síť projektu:

dockup network enable production --json

Služby a spravované databáze v tomto projektu získají stabilní hostnames <slug>.internal. Proveďte redeploy aplikace, aby obdržela vložené interní connection variables.

Chcete-li odstranit veřejný listener databáze a ponechat pouze privátní přístup:

dockup db private production/main-db --json

V případě potřeby obnovte veřejný i privátní přístup:

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

Nastavení databáze pouze pro privátní přístup znovu vytvoří její kontejner, data však zachová. Tuto změnu plánujte a ověřujte jako databázovou operaci, nikoli jako neškodnou úpravu DNS.

Privátní síťování řídí trasu, zatímco credentials PostgreSQL řídí identitu a autorizaci. Používejte obojí. Oddělené projekty se navzájem nedostanou, protože každý projekt má vlastní síť.

Článek privátní síťování a interní domény popisuje celou topologii.

Jak fungují zálohy a obnova PostgreSQL?

Zobrazte existující zálohy:

dockup db backups production/main-db --json

Spusťte zálohu na straně serveru:

dockup db backup production/main-db --json

Příkaz pro zálohu vytváří zálohu s ohledem na databázi, nikoli hot copy nezpracovaného volume. Zaznamenejte ID zálohy, čas vytvoření, verzi databáze a důvod.

Dockup podporuje obnovu záloh spravovaných databází prostřednictvím platformy. Aktuální reference CLI nepopisuje příkaz dockup db restore, proto si ho tento průvodce nevymýšlí. Obnovu proveďte z podporovaného rozhraní Dockup, vyberte přesnou zálohu, získejte schválení pro produkci a ověřte výsledek.

Plán obnovy by měl zahrnovat:

1. Bod obnovy a očekávané období ztracených zápisů.
2. Pozastavení zápisů aplikace nebo chování v režimu údržby.
3. Kompatibilitu databáze a extensions.
4. Novou zálohu aktuálního stavu, pokud je užitečná.
5. Odpovědnou osobu za obnovu a schválení.
6. Opětovné připojení aplikace a smoke test.
7. Auditní a incidentní záznam.

Zálohy nejsou ověřené, dokud neproběhne úspěšné cvičení obnovy. Postup testujte v neprodukční databázi nebo ve schváleném prostředí pro obnovu.

Zálohy uchovávejte podle schválené politiky. Zastaralé body obnovy odstraňujte pouze prostřednictvím podporovaného databázového rozhraní a až po ověření, že na nich již nezávisí žádný požadavek na obnovu nebo compliance.

Jak fungují uživatelé PostgreSQL pouze pro čtení?

Další uživatelé pouze pro čtení se hodí pro analytics, vyšetřování problémů podporou, preview deploymenty a nástroje, které musí dotazovat data bez zápisu.

Zobrazte uživatele:

dockup db users production/main-db --json

Vytvořte uživatele se štítkem:

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

Během vytváření bezpečně zachyťte vygenerované credentials a v odpovědi agenta je znovu neuvádějte. Jakmile účel dalšího uživatele skončí, zneplatněte ho prostřednictvím podporovaného rozhraní pro správu databázových uživatelů.

Omezení pouze na čtení na úrovni databázových oprávnění je silnější než říct query nástroji „nezapisuj“. Stále však umožňuje přístup ke čitelným produkčním datům, proto platí pravidla ochrany soukromí a nejmenších oprávnění.

Dockup automaticky vytvoří uživatele databáze pouze pro čtení pro PR nebo branch preview v projektu s privátním síťováním. Preview se může připojit ke stejné produkční databázi na <slug>.internal a číst data bez oprávnění k zápisu.

Jak monitorovat velikost, logy a umístění?

Zkontrolujte velikost na disku:

dockup db size production/main-db --json

Projděte runtime logy aplikace a hledejte chyby připojení, aniž byste zveřejnili hesla nebo celé connection stringy:

dockup logs production/api --json

Údržba databáze může znepřístupnit závislé služby. Operace měnící stav plánujte, vyžadujte výslovné provozní schválení a před provedením komunikujte jejich dopad.

Přesuňte databázi mezi nody pomocí ID cílového nodu:

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

Migrace je stateful operace. Ověřte stav záloh, očekávání ohledně údržby, připojení přes privátní síť a kontroly aplikace po přesunu.

Checklist spravovaného PostgreSQL pro produkci

Kompletní runbook zaznamenává:

Oblast	Požadované důkazy
Identita	Přesný cíl project/db
Připojení	Secret connection string a otestovaná nová session
Síť	Politika veřejného, privátního nebo pouze privátního přístupu
Přístup	Role aplikace a uživatelé pouze pro čtení se štítky
Kapacita	Aktuální velikost a kontrola růstu
Zálohy	ID nedávných záloh a retence
Obnova	Úspěšné cvičení obnovy
Provoz	Schválení spuštění, zastavení, restartu a migrace
Audit	Změny databáze dohledatelné ke konkrétnímu aktérovi

Rollback deploymentu aplikace neobnoví PostgreSQL. Obnova databáze automaticky nevrátí zpět kód aplikace. Koordinujte obojí pouze tehdy, když to vyžaduje kompatibilita schématu.

Pro širší rozhodování o škálování si přečtěte strategie škálování databází. Přesné příkazy najdete v referenci CLI Dockup.

Navrhujte migrace schématu pro deploy a rollback

Deployment aplikace a změna databázového schématu probíhají v odlišných časových rámcích. Bezpečná migrace je obvykle zpětně kompatibilní alespoň po dobu jednoho release window: nejprve přidejte nullable sloupec, poté nasaďte kód, který zvládne obě verze schématu, proveďte backfill řízeným postupem a starou strukturu odstraňte později.

Nenechte health check provádět dlouhou migraci. Pokud aplikace spouští několik replik, zajistěte, aby změnu mohl vlastnit pouze jeden migration runner. Příkaz exec kontejneru PRO může spustit jednorázový příkaz a předat jeho skutečný exit code:

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

Použijte ho pouze tehdy, když je migrační příkaz zkontrolovaný a služba běží na podporovaném main serveru. Zachyťte stdout, stderr a exit code. Úspěšný deploy aplikace neznamená, že lze neúspěšnou migraci ignorovat.

Rotujte credentials databáze bez výpadku

Vytvořte nové credentials nebo uživatele pouze pro čtení, aktualizujte secret konzumentské služby, proveďte redeploy a před zneplatněním starých credentials ověřte nové připojení. Existující connection pooly mohou skrýt nesprávné nové heslo, dokud se znovu nepřipojí.

U primárních credentials aplikace použijte podporované rozhraní Dockup a databázovou politiku. U dalšího analytického uživatele vytvořte účet pouze pro čtení se štítkem a distribuujte ho pouze schválenému konzumentovi.

Záznam o rotaci by měl obsahovat štítek uživatele, konzumentské služby, ID deploymentů, ověřovací dotaz, čas zneplatnění a auditní událost — nikdy heslo.

Sledujte růst před škálováním

Velikost databáze je jedním ze signálů:

dockup db size production/main-db --json

Kombinujte ji s latencí dotazů aplikace, počtem připojení, chováním cache, délkou zálohování a růstem úložiště. Větší přidělení CPU nebo paměti nemusí vyřešit chybějící indexy ani neomezené dotazy.

Před přesunem nodů nebo navýšením prostředků si projděte strategie škálování databází. Spravovaný PostgreSQL omezuje práci s provisioningem, návrh schématu a dotazů však zůstává odpovědností aplikace.

Oddělte dostupnost od správnosti

Běžící databázový kontejner dokazuje, že je PostgreSQL dostupný, nikoli že jsou dotazy aplikace správné. Do ověření po deploymentu zahrňte bezpečné nové připojení a reprezentativní čtení. Pro test zápisu použijte dedikovanou transakci nebo testovací záznam, který lze bezpečně odstranit.

Runbook pro spravovaný PostgreSQL by měl také uvádět, zda repliky, analytické účty, previews nebo background workeři vytvářejí další tlak na počet připojení.

Pravidelně kontrolujte přístup k PostgreSQL

Zobrazte další uživatele, ověřte, že každý štítek má aktivního vlastníka, a odstraňte zastaralé účty. Tato jednoduchá kontrola brání hromadění přístupu spravovaného PostgreSQL pouze pro čtení po skončení preview, analytických projektů nebo vyšetřování problémů podporou.

Začněte s ověřitelným deploymentem

Vytvořte neprodukční databázi PostgreSQL, připojte testovací službu prostřednictvím maskovaného secretu, vytvořte zálohu a před přechodem do produkce dokončete cvičení obnovy.

Začněte zdarma na app.dockup.ai. Tarif Free stojí 0 $ měsíčně, zahrnuje počáteční kredit 10 $ a podporuje jeden workspace, tři databáze a tři deploymenty.

Časté dotazy

Které typy spravovaných databází Dockup podporuje?

Dockup podporuje spravované databáze PostgreSQL, MySQL, MongoDB a Redis.

Jak má aplikace získat connection string k PostgreSQL?

S connection stringem zacházejte jako s tajnou environment variable, nastavte ho pro přesnou službu a proveďte redeploy, aby ho nový kontejner obdržel.

Může Dockup vytvořit uživatele PostgreSQL pouze pro čtení?

Ano. Příkaz database user-add vytvoří dalšího uživatele pouze pro čtení a při vytvoření jednou vrátí jeho heslo.

Existuje dokumentovaný CLI příkaz dockup db restore?

Aktuální reference CLI žádný takový příkaz nepopisuje. Dockup podporuje obnovu záloh prostřednictvím rozhraní platformy, proto použijte tuto podporovanou cestu místo vymýšlení flagu nebo příkazu.

Obnoví rollback aplikace databázi PostgreSQL?

Ne. Historie deploymentů aplikace a historie záloh databáze jsou oddělené systémy obnovy a při změnách schématu, které vyžadují obojí, je nutné je koordinovat.