Spravovaný PostgreSQL na Dockup: kompletná príručka

Spravovaný PostgreSQL poskytuje aplikácii pripravenú databázu s operáciami životného cyklu, ktoré sú oddelené od kontajnera služby. Dockup podporuje vytváranie, spúšťanie a zastavovanie, logy, kontrolu veľkosti, zálohy, obnovu prostredníctvom platformy, používateľov iba na čítanie, migráciu medzi nódmi a privátne sieťovanie.

Základným prevádzkovým princípom je oddelenie: image aplikácie je možné zahodiť, dáta PostgreSQL sú trvalé, prihlasovacie údaje sú secrets a obnovu databázy treba testovať nezávisle od rollbacku aplikácie.

Ako vytvoríte spravovanú databázu PostgreSQL?

Vyberte požadovaný workspace a potom vytvorte databázu:

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

Vypíšte databázy a overte presný slug a stav:

dockup db list --json

Operácie s databázami používajú ciele v tvare project/db:

dockup db size production/main-db --json

Pred pripojením aplikácie počkajte na dokončenie provisioning-u. Názov databázy nepoužívajte na odhad hostname, portu, používateľského mena ani hesla.

Free plan umožňuje tri databázy v jednom workspace a zahŕňa počiatočný kredit 10 USD. Platené plány — Hobby za 5 USD, Pro za 20 USD mesačne — umožňujú neobmedzený počet databáz, workspaceov a deploymentov. Spotreba CPU, RAM a disku sa meria po minútach oproti zahrnutému zostatku využitia.

Ako bezpečne pripojíte aplikáciu?

Údaje na pripojenie k databáze získajte z databázového rozhrania Dockup a s connection stringom zaobchádzajte ako s secretom. Nevkladajte ho do repository ani do transcriptu agenta.

Nastavte ho v službe:

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

dockup deploy production/api --wait --json

Redeploy je potrebný, pretože bežiaci proces dostal svoje environment pri štarte. Pri načítaní konfigurácie environmentu sa uložená hodnota zobrazí zamaskovaná.

Connection pooling v aplikácii konfigurujte zámerne. Príliš veľa workerov aplikácie s veľkými poolmi môže vyčerpať databázové connections, aj keď CPU a pamäť vyzerajú v poriadku. Veľkosť poolu nastavujte podľa záťaže a kapacity databázy, nie podľa maximálneho počtu, ktorý akceptuje framework.

Po deploymente otestujte nové pripojenie. Health endpoint môže potvrdiť, že HTTP proces beží, no nemusí dokazovať, že možno vytvoriť novú databázovú session.

Príručka environment variables and secrets vysvetľuje rotáciu prihlasovacích údajov a maskovaný výstup.

Ako privátne sieťovanie chráni komunikáciu s PostgreSQL?

Povoľte privátnu sieť projektu:

dockup network enable production --json

Služby a spravované databázy v danom projekte dostanú stabilné hostnames v tvare <slug>.internal. Redeployujte aplikáciu, aby dostala injektované interné connection variables.

Ak chcete odstrániť verejný listener databázy a ponechať iba privátny prístup:

dockup db private production/main-db --json

V prípade potreby obnovte verejný aj privátny prístup:

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

Nastavenie databázy iba na privátny prístup znovu vytvorí jej kontajner, pričom zachová dáta. Túto zmenu naplánujte a overte ako databázovú operáciu, nie ako neškodnú úpravu DNS.

Privátne sieťovanie riadi trasu, zatiaľ čo prihlasovacie údaje PostgreSQL riadia identitu a autorizáciu. Používajte oboje. Oddelené projekty sa navzájom nedokážu dosiahnuť, pretože každý projekt má vlastnú sieť.

Článok private networking and internal domains opisuje celú topológiu.

Ako fungujú zálohy a obnova PostgreSQL?

Vypíšte existujúce zálohy:

dockup db backups production/main-db --json

Spustite server-side zálohu:

dockup db backup production/main-db --json

Príkaz na zálohovanie vytvorí databázovú zálohu, nie hot copy nespracovaného volume. Zaznamenajte ID zálohy, čas vytvorenia, verziu databázy a dôvod.

Dockup podporuje obnovu záloh spravovaných databáz prostredníctvom platformy. Aktuálna referencia CLI neuvádza príkaz dockup db restore, preto ho táto príručka nevymýšľa. Obnovu vykonajte v podporovanom rozhraní Dockup, vyberte presnú zálohu, získajte schválenie pre produkciu a overte výsledok.

Plán obnovy by mal zahŕňať:

1. Bod obnovy a očakávané obdobie stratených zápisov.
2. Zastavenie zápisov aplikácie alebo režim údržby.
3. Kompatibilitu databázy a extensions.
4. Aktuálnu zálohu súčasného stavu, ak je užitočná.
5. Zodpovednú osobu za obnovu a schválenie.
6. Opätovné pripojenie aplikácie a smoke test.
7. Auditný a incidentový záznam.

Zálohy nie sú overené, kým úspešne neprebehne cvičná obnova. Postup otestujte na neprodukčnej databáze alebo v schválenom recovery prostredí.

Zálohy uchovávajte podľa schválenej politiky. Zastarané recovery points odstraňujte iba cez podporované databázové rozhranie a až po overení, že od nich už nezávisí žiadna požiadavka na obnovu alebo compliance.

Ako fungujú používatelia PostgreSQL iba na čítanie?

Ďalší používatelia iba na čítanie sú užitoční pre analytics, vyšetrovanie problémov podporou, preview deploymenty a nástroje, ktoré musia čítať bez zápisu.

Vypíšte používateľov:

dockup db users production/main-db --json

Vytvorte používateľa s labelom:

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

Vygenerované prihlasovacie údaje bezpečne zachyťte počas vytvárania a nezobrazujte ich v odpovedi agenta. Keď účel dodatočného používateľa skončí, odvolajte ho cez podporované rozhranie na správu databázových používateľov.

Prístup iba na čítanie na úrovni databázových oprávnení je silnejší než pokyn query nástroju „nezapisuj“. Stále však umožňuje prístup k čitateľným produkčným dátam, preto sa uplatňujú pravidlá ochrany súkromia a minimálnych oprávnení.

Dockup automaticky vytvorí databázového používateľa iba na čítanie pre PR alebo branch preview v projekte s privátnym sieťovaním. Preview môže pristupovať k tej istej produkčnej databáze na <slug>.internal a čítať dáta bez oprávnenia na zápis.

Ako monitorujete veľkosť, logy a umiestnenie?

Skontrolujte veľkosť na disku:

dockup db size production/main-db --json

Preskúmajte runtime logy aplikácie kvôli chybám pripojenia bez odhalenia hesiel alebo celých connection stringov:

dockup logs production/api --json

Údržba databázy môže zneprístupniť závislé služby. Operácie meniace stav plánujte, vyžadujte explicitné prevádzkové schválenie a pred vykonaním komunikujte ich vplyv.

Presuňte databázu medzi nodmi pomocou ID cieľového nodu:

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

Migrácia je stateful operácia. Overte stav záloh, očakávania týkajúce sa údržby, pripojenia cez privátnu sieť a kontroly aplikácie po presune.

Kontrolný zoznam spravovaného PostgreSQL pre produkciu

Kompletný runbook zaznamenáva:

Oblasť	Požadovaný dôkaz
Identita	Presný cieľ project/db
Pripojenie	Secret connection string a otestovaná nová session
Sieť	Politika verejného, privátneho alebo iba privátneho prístupu
Prístup	Rola aplikácie a označení používatelia iba na čítanie
Kapacita	Aktuálna veľkosť a kontrola rastu
Zálohy	Najnovšie ID záloh a retencia
Obnova	Úspešná cvičná obnova
Prevádzka	Schválenie spustenia, zastavenia, reštartu a migrácie
Audit	Zmeny databázy spätne priraditeľné konkrétnemu aktérovi

Rollback deploymentu aplikácie neobnoví PostgreSQL. Obnova databázy automaticky nevráti kód aplikácie na predchádzajúcu verziu. Oboje koordinujte iba vtedy, keď si kompatibilita schémy vyžaduje spoločný postup.

Pre širšie rozhodnutia o škálovaní si prečítajte database scaling strategies. Presné príkazy nájdete v referencii Dockup CLI.

Navrhujte migrácie schémy s ohľadom na deploy a rollback

Deployment aplikácie a zmena databázovej schémy prebiehajú v odlišných časoch. Bezpečná migrácia je zvyčajne spätne kompatibilná aspoň počas jedného release window: najprv pridajte nullable column, potom nasaďte kód, ktorý zvládne obe schémy, vykonajte backfill kontrolovaným procesom a starú štruktúru odstráňte neskôr.

Nenechávajte health check vykonávať dlhú migráciu. Ak aplikácia spúšťa niekoľko replík, zaistite, aby zmenu mohol vykonať iba jeden migration runner. Príkaz exec PRO kontajnera dokáže spustiť jednorazový príkaz a odovzdať jeho skutočný exit code:

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

Použite ho iba vtedy, keď je migračný príkaz skontrolovaný a služba beží na podporovanom main serveri. Zachyťte stdout, stderr a exit code. Úspešný application deploy neznamená, že možno ignorovať zlyhanú migráciu.

Rotujte prihlasovacie údaje databázy bez výpadku

Vytvorte nové prihlasovacie údaje alebo používateľa iba na čítanie, aktualizujte secret konzumujúcej služby, vykonajte redeploy a pred odvolaním starých prihlasovacích údajov overte nové pripojenie. Existujúce connection pooly môžu skryť nesprávne nové heslo, kým sa znova nepripoja.

Pri hlavnom prihlasovacom údaji aplikácie použite podporované rozhranie Dockup a databázovú politiku. Pri dodatočnom analytickom používateľovi vytvorte označený účet iba na čítanie a distribuujte ho iba schválenému konzumentovi.

Záznam o rotácii by mal obsahovať label používateľa, konzumujúce služby, ID deploymentov, overovací query, čas odvolania a auditnú udalosť — nikdy nie heslo.

Sledujte rast ešte pred škálovaním

Veľkosť databázy je jedným zo signálov:

dockup db size production/main-db --json

Kombinujte ju s latenciou query aplikácie, počtom connections, správaním cache, trvaním zálohovania a rastom storage. Väčšia pridelená kapacita CPU alebo pamäte nemusí vyriešiť chýbajúce indexy ani neobmedzené queries.

Pred presunom nodov alebo zvýšením resources si prečítajte database scaling strategies. Spravovaný PostgreSQL znižuje náročnosť provisioning-u, no návrh schémy a queries zostávajú zodpovednosťou aplikácie.

Oddeľte dostupnosť od správnosti

Bežiaci databázový kontajner dokazuje, že PostgreSQL je dostupný, nie že query aplikácie fungujú správne. Do overenia po deploymente zahrňte nové pripojenie s nízkym rizikom a reprezentatívne čítanie. Pri teste zápisu použite vyhradenú transakciu alebo testovací záznam, ktorý možno bezpečne odstrániť.

Runbook pre spravovaný PostgreSQL by mal tiež uvádzať, či repliky, analytickí používatelia, previews alebo background workeri vytvárajú dodatočný tlak na počet connections.

Pravidelne kontrolujte prístup k PostgreSQL

Vypíšte ďalších používateľov, overte, že každý label má aktívneho vlastníka, a odstráňte zastarané účty. Táto jednoduchá kontrola zabráni hromadeniu prístupu na čítanie v spravovanom PostgreSQL po skončení previews, analytických projektov alebo vyšetrovaní podpory.

Začnite s overiteľným deploymentom

Vytvorte neprodukčnú databázu PostgreSQL, pripojte testovaciu službu pomocou zamaskovaného secretu, vytvorte zálohu a pred prechodom do produkcie dokončite cvičnú obnovu.

Začnite bezplatne na app.dockup.ai. Free plan stojí 0 USD mesačne, zahŕňa počiatočný kredit 10 USD a podporuje jeden workspace, tri databázy a tri deploymenty.

FAQ

Ktoré typy spravovaných databáz Dockup podporuje?

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

Ako má aplikácia dostať connection string PostgreSQL?

S connection stringom zaobchádzajte ako s secret environment variable, nastavte ho v presnej službe a vykonajte redeploy, aby ho nový kontajner dostal.

Dokáže Dockup vytvoriť používateľa PostgreSQL iba na čítanie?

Áno. Príkaz database user-add vytvorí ďalšieho používateľa iba na čítanie a pri vytvorení raz vráti jeho heslo.

Existuje zdokumentovaný CLI príkaz dockup db restore?

Aktuálna referencia CLI taký príkaz neuvádza. Dockup podporuje obnovu záloh prostredníctvom rozhrania platformy, preto použite túto podporovanú cestu namiesto vymýšľania flagu alebo príkazu.

Obnoví rollback aplikácie databázu PostgreSQL?

Nie. História deploymentov aplikácie a história záloh databázy sú oddelené recovery systémy a pri zmenách schémy, ktoré vyžadujú oboje, ich treba koordinovať.