PostgreSQL gestionat pe Dockup: ghid complet

PostgreSQL gestionat oferă unei aplicații o bază de date provisionată, cu operațiuni de lifecycle separate de containerul serviciului. Dockup acceptă crearea, pornirea și oprirea, logurile, verificarea dimensiunii, backupurile, restaurarea prin intermediul platformei, utilizatorii read-only, migrarea între noduri și rețelele private.

Principiul operațional esențial este separarea: imaginea aplicației este dispensabilă, datele PostgreSQL sunt durabile, credentialele sunt secrete, iar recuperarea bazei de date trebuie testată independent de rollbackul aplicației.

Cum creezi o bază de date PostgreSQL gestionată?

Selectează workspace-ul dorit, apoi creează baza de date:

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

Listează bazele de date pentru a confirma slugul și statusul exacte:

dockup db list --json

Operațiunile asupra bazelor de date folosesc ținte project/db:

dockup db size production/main-db --json

Așteaptă finalizarea provisioningului înainte de a atașa o aplicație. Nu ghici hostname-ul, portul, numele de utilizator sau parola pe baza numelui bazei de date.

Planul Free permite trei baze de date într-un workspace și include un credit inițial de 10 $. Planurile plătite — Hobby la 5 $, Pro la 20 $ pe lună — permit un număr nelimitat de baze de date, workspace-uri și deploymenturi. Consumul de CPU, RAM și disk este măsurat pe minut și scăzut din balanța de utilizare inclusă.

Cum conectezi în siguranță o aplicație?

Obține detaliile conexiunii la baza de date din interfața bazei de date Dockup și tratează connection string-ul ca pe un secret. Nu îl introduce în repository sau în transcriptul agentului.

Setează-l pe serviciu:

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

dockup deploy production/api --wait --json

Este necesar un redeploy deoarece procesul în execuție și-a primit environment-ul la pornire. Valoarea stocată este mascată la citirea configurației de environment.

Configurează în mod deliberat connection pooling-ul aplicației. Prea mulți application workers cu pool-uri mari pot epuiza conexiunile bazei de date chiar și atunci când CPU-ul și memoria par să funcționeze normal. Stabilește dimensiunea pool-ului în funcție de workload și de capacitatea bazei de date, nu în funcție de numărul maxim acceptat de un framework.

Testează o conexiune nouă după deployment. Un health endpoint poate confirma că procesul HTTP este activ fără să demonstreze că poate fi stabilită o sesiune nouă la baza de date.

Ghidul despre variabile de environment și secrete prezintă rotația credentialelor și outputul mascat.

Cum protejează rețeaua privată traficul PostgreSQL?

Activează o rețea privată pentru proiect:

dockup network enable production --json

Serviciile și bazele de date gestionate din proiect primesc hostname-uri stabile de forma <slug>.internal. Fă redeploy aplicației pentru a primi variabilele de conexiune interne injectate.

Pentru a elimina listenerul public al bazei de date și a o face disponibilă doar în rețeaua privată:

dockup db private production/main-db --json

Restaurează accesul public și privat atunci când este necesar:

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

Transformarea bazei de date într-una disponibilă doar în rețeaua privată recreează containerul, păstrând însă datele. Planifică și verifică schimbarea ca pe o operațiune asupra bazei de date, nu ca pe o modificare DNS inofensivă.

Rețeaua privată controlează ruta, în timp ce credentialele PostgreSQL controlează identitatea și autorizarea. Păstrează-le pe ambele. Proiectele separate nu se pot accesa reciproc, deoarece fiecare proiect are propria rețea.

Articolul despre rețele private și domenii interne prezintă topologia completă.

Cum funcționează backupul și restaurarea PostgreSQL?

Listează backupurile existente:

dockup db backups production/main-db --json

Pornește un backup realizat pe server:

dockup db backup production/main-db --json

Comanda de backup creează un backup care ține cont de baza de date, nu o copie hot a volumului brut. Înregistrează ID-ul backupului, momentul creării, versiunea bazei de date și motivul.

Dockup permite restaurarea backupurilor bazelor de date gestionate prin intermediul platformei. Referința CLI actuală nu documentează o comandă dockup db restore, așa că acest ghid nu inventează una. Efectuează restaurarea din interfața Dockup acceptată, selectează backupul exact, obține aprobarea pentru producție și verifică rezultatul.

Un plan de restaurare ar trebui să includă:

1. Punctul de recuperare și intervalul estimat de pierderi ale scrierilor.
2. Înghețarea scrierilor aplicației sau comportamentul în timpul mentenanței.
3. Compatibilitatea bazei de date și a extensiilor.
4. Un backup nou al stării curente, atunci când este util.
5. Responsabilul pentru restaurare și aprobarea.
6. Reconectarea aplicației și un smoke test.
7. Auditul și înregistrarea incidentului.

Backupurile nu sunt validate până când un restore drill nu se finalizează cu succes. Folosește o bază de date non-production sau un recovery environment aprobat pentru a testa procedura.

Păstrează backupurile conform unei politici aprobate. Elimină punctele de recuperare învechite numai prin interfața acceptată a bazei de date, după ce verifici că nicio cerință de recuperare sau de conformitate nu mai depinde de acestea.

Cum funcționează utilizatorii PostgreSQL read-only?

Utilizatorii read-only suplimentari sunt utili pentru analytics, investigații de suport, preview deploymenturi și instrumente care trebuie să execute interogări fără să scrie.

Listează utilizatorii:

dockup db users production/main-db --json

Creează unul cu o etichetă:

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

Salvează în siguranță credentialul generat în timpul creării și nu îl reproduce într-un răspuns al agentului. Revocă utilizatorul suplimentar prin interfața acceptată de gestionare a utilizatorilor bazei de date atunci când scopul său încetează.

Read-only la nivelul permisiunilor bazei de date este mai sigur decât să-i spui unui instrument de interogare „nu scrie”. Totuși, permite accesul la date de producție care pot fi citite, astfel că se aplică regulile de confidențialitate și least privilege.

Dockup creează automat un utilizator de bază de date read-only pentru un PR sau un branch preview într-un proiect cu rețea privată. Preview-ul poate accesa aceeași bază de date de producție la <slug>.internal și poate citi date fără a primi permisiuni de scriere.

Cum monitorizezi dimensiunea, logurile și amplasarea?

Verifică dimensiunea pe disk:

dockup db size production/main-db --json

Analizează logurile runtime ale aplicației pentru erori de conexiune fără a expune parole sau connection string-uri complete:

dockup logs production/api --json

Mentenanța bazei de date poate face indisponibile serviciile dependente. Planifică operațiunile care modifică starea, solicită aprobare operațională explicită și comunică impactul înainte de a acționa.

Mută o bază de date între noduri folosind ID-ul nodului țintă:

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

Migrarea este o operațiune stateful. Confirmă statusul backupului, așteptările privind mentenanța, conexiunile la rețeaua privată și verificările aplicației după mutare.

Checklist pentru PostgreSQL gestionat în producție

Un runbook complet înregistrează:

Zonă	Dovezi necesare
Identitate	Ținta exactă project/db
Conectivitate	Connection string secret și sesiune nouă testată
Rețea	Politica publică, privată sau doar privată
Acces	Rolul aplicației și utilizatorii read-only etichetați
Capacitate	Dimensiunea curentă și analiza creșterii
Backupuri	ID-urile backupurilor recente și retenția
Recuperare	Restore drill finalizat cu succes
Operațiuni	Aprobarea pentru pornire, oprire, restart și migrare
Audit	Modificările bazei de date pot fi atribuite unui actor

Rollbackul deploymentului aplicației nu restaurează PostgreSQL. Restaurarea bazei de date nu face automat rollback la codul aplicației. Coordonează-le doar atunci când compatibilitatea schemei o impune.

Pentru decizii mai ample privind scalingul, citește strategii de scaling pentru baze de date. Pentru comenzile exacte, folosește referința CLI Dockup.

Proiectează migrările de schemă pentru deploy și rollback

Deploymentul aplicației și modificarea schemei bazei de date au loc pe timeline-uri diferite. O migrare sigură este de obicei backward compatible pentru cel puțin o fereastră de release: adaugă o coloană nullable înainte de a o face obligatorie, publică un cod care poate gestiona ambele scheme, efectuează backfill-ul într-un proces controlat și elimină ulterior structura veche.

Nu face health check-ul să execute o migrare lungă. Dacă aplicația pornește mai multe replici, asigură-te că un singur migration runner poate deține schimbarea. Comanda exec a containerului PRO poate rula o comandă one-shot și poate transmite codul real de exit:

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

Folosește-o numai atunci când comanda de migrare a fost verificată, iar serviciul rulează pe main server-ul acceptat. Capturează stdout, stderr și codul de exit. Un deployment reușit al aplicației nu înseamnă că o migrare eșuată poate fi ignorată.

Rotește credentialele bazei de date fără downtime

Creează noul credential sau utilizatorul read-only, actualizează secretul serviciului care îl consumă, fă redeploy și verifică o conexiune nouă înainte de a revoca vechiul credential. Pool-urile de conexiuni existente pot ascunde o parolă nouă incorectă până când se reconectează.

Pentru credentialul principal al aplicației, folosește interfața Dockup acceptată și politica bazei de date. Pentru un utilizator analitic suplimentar, creează un cont read-only etichetat și distribuie-l numai consumatorului aprobat.

Înregistrarea rotației ar trebui să enumere eticheta utilizatorului, serviciile consumatoare, ID-urile deploymenturilor, interogarea de verificare, momentul revocării și evenimentul de audit — niciodată parola.

Monitorizează creșterea înainte de scaling

Dimensiunea bazei de date este un indicator:

dockup db size production/main-db --json

Coreleaz-o cu latența interogărilor aplicației, numărul de conexiuni, comportamentul cache-ului, durata backupului și creșterea spațiului de stocare. O alocare mai mare de CPU sau memorie poate să nu rezolve lipsa indexurilor sau interogările fără limite.

Consultă strategii de scaling pentru baze de date înainte de a muta noduri sau de a crește resursele. PostgreSQL gestionat reduce efortul de provisioning, însă schema și designul interogărilor rămân responsabilități ale aplicației.

Separă disponibilitatea de corectitudine

Un container de bază de date care rulează demonstrează că PostgreSQL este disponibil, nu că interogările aplicației sunt corecte. Include în verificarea de după deployment o conexiune nouă cu risc redus și o citire reprezentativă. Pentru un test de scriere, folosește o tranzacție dedicată sau o înregistrare de test care poate fi eliminată în siguranță.

Runbookul pentru PostgreSQL gestionat ar trebui să precizeze și dacă replicile, utilizatorii pentru analytics, preview-urile sau workerii de fundal creează presiune suplimentară asupra conexiunilor.

Revizuiește periodic accesul PostgreSQL

Listează utilizatorii suplimentari, confirmă că fiecare etichetă are un owner activ și elimină conturile învechite. Această verificare simplă împiedică acumularea accesului read-only la PostgreSQL gestionat după încheierea preview-urilor, proiectelor de analytics sau investigațiilor de suport.

Începe cu un deployment verificabil

Creează o bază de date PostgreSQL non-production, conectează un serviciu de test printr-un secret mascat, fă un backup și finalizează un restore drill înainte de trecerea în producție.

Începe gratuit la app.dockup.ai. Planul Free costă 0 $ pe lună, include un credit inițial de 10 $ și acceptă un workspace, trei baze de date și trei deploymenturi.

Întrebări frecvente

Ce tipuri de baze de date gestionate acceptă Dockup?

Dockup acceptă baze de date gestionate PostgreSQL, MySQL, MongoDB și Redis.

Cum ar trebui să primească o aplicație connection string-ul PostgreSQL?

Tratează connection string-ul ca pe o variabilă de environment secretă, setează-l pe serviciul exact și fă redeploy pentru ca noul container să îl primească.

Poate Dockup să creeze un utilizator PostgreSQL read-only?

Da. Comanda database user-add creează un utilizator read-only suplimentar și îi returnează parola o singură dată, la creare.

Există o comandă CLI documentată dockup db restore?

Referința CLI actuală nu documentează una. Dockup acceptă restaurarea backupurilor prin interfața platformei, așa că folosește calea acceptată în loc să inventezi un flag sau o comandă.

Rollbackul aplicației restaurează baza de date PostgreSQL?

Nu. Istoricul deploymenturilor aplicației și istoricul backupurilor bazei de date sunt sisteme separate de recuperare și trebuie coordonate atunci când modificările de schemă le impun pe ambele.