Managed PostgreSQL a Dockupon: teljes útmutató

A Managed PostgreSQL az alkalmazás számára kiépített adatbázist biztosít, amelynek életciklus-kezelése elkülönül a szolgáltatás konténerétől. A Dockup támogatja az adatbázisok létrehozását, indítását és leállítását, a naplók megtekintését, a méret ellenőrzését, a biztonsági mentéseket, a platformon keresztüli visszaállítást, a csak olvasási jogosultságú felhasználókat, a node-ok közötti migrációt és a privát hálózatkezelést.

A legfontosabb működési alapelv az elkülönítés: az alkalmazás image-e eldobható, a PostgreSQL adatai tartósak, a hitelesítő adatok secretként kezelendők, az adatbázis helyreállítását pedig az alkalmazás rollbackjétől függetlenül kell tesztelni.

Hogyan hozhatsz létre managed PostgreSQL-adatbázist?

Válaszd ki a kívánt workspace-t, majd hozd létre az adatbázist:

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

Az adatbázisok listázásával ellenőrizd a pontos slugot és az állapotot:

dockup db list --json

Az adatbázis-műveletek project/db targeteket használnak:

dockup db size production/main-db --json

Várd meg, amíg a kiépítés befejeződik, mielőtt alkalmazást csatlakoztatnál. Ne próbáld az adatbázis nevéből kitalálni a hostnevet, a portot, a felhasználónevet vagy a jelszót.

A Free csomag workspace-enként három adatbázist engedélyez, és 10 USD kezdő kreditet tartalmaz. A fizetős csomagok — a havi 5 dolláros Hobby, a 20 dolláros Pro — korlátlan számú adatbázist, workspace-t és deploymentet tesznek lehetővé. A CPU-, RAM- és lemezhasználatot percenként mérik a rendelkezésre álló felhasználási egyenleg terhére.

Hogyan csatlakoztathatsz biztonságosan egy alkalmazást?

Kérd le a Dockup adatbázis-kezelőfelületén az adatbázis csatlakozási adatait, és a connection stringet secretként kezeld. Ne illeszd be a repository-ba vagy az agent naplójába.

Állítsd be a szolgáltatáson:

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

dockup deploy production/api --wait --json

A redeploy azért szükséges, mert a futó process az indulásakor kapta meg a környezeti változóit. A tárolt érték maszkolva jelenik meg a környezeti konfiguráció beolvasásakor.

Az alkalmazás connection pooling beállításait tudatosan konfiguráld. A túl sok, nagy méretű pool-lal dolgozó application worker akkor is kimerítheti az adatbázis-kapcsolatokat, ha a CPU- és memóriahasználat egészségesnek tűnik. A pool méretét a terhelés és az adatbázis kapacitása alapján állítsd be, ne a framework által elfogadott maximális értékből indulj ki.

A deployment után tesztelj egy új kapcsolatot. Egy health endpoint igazolhatja, hogy a HTTP process él, de önmagában nem bizonyítja, hogy új adatbázis-session hozható létre.

A környezeti változókról és secretekről szóló útmutató a hitelesítő adatok rotációját és a maszkolt kimenetet ismerteti.

Hogyan védi a privát hálózatkezelés a PostgreSQL-forgalmat?

Engedélyezz projekt-szintű privát hálózatot:

dockup network enable production --json

A projektben található szolgáltatások és managed adatbázisok stabil <slug>.internal hostname-eket kapnak. A beinjektált belső connection változók átvételéhez redeployold az alkalmazást.

Az adatbázis nyilvános listenerének eltávolításához és kizárólag privát elérés beállításához:

dockup db private production/main-db --json

Szükség esetén állítsd vissza a nyilvános és privát elérést:

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

A kizárólag privát elérésű adatbázis beállítása újra létrehozza a konténerét, az adatokat azonban megőrzi. A módosítást adatbázis-műveletként ütemezd és ellenőrizd, ne ártalmatlan DNS-módosításként kezeld.

A privát hálózatkezelés az útvonalat szabályozza, míg a PostgreSQL hitelesítő adatai az identitást és a jogosultságokat. Mindkettőt tartsd meg. Az elkülönített projektek nem érik el egymást, mert minden projekt saját hálózattal rendelkezik.

A privát hálózatkezelésről és a belső domainekről szóló cikk a teljes topológiát bemutatja.

Hogyan működik a PostgreSQL biztonsági mentése és visszaállítása?

A meglévő biztonsági mentések listázása:

dockup db backups production/main-db --json

Szerveroldali biztonsági mentés indítása:

dockup db backup production/main-db --json

A backup parancs adatbázis-tudatos mentést hoz létre, nem a nyers volume hot copy-ját. Jegyezd fel a backup ID-ját, létrehozási idejét, az adatbázis verzióját és a mentés okát.

A Dockup támogatja a managed adatbázisok biztonsági mentéseinek platformon keresztüli visszaállítását. A jelenlegi CLI-referencia nem dokumentál dockup db restore parancsot, ezért ez az útmutató nem talál ki ilyet. A visszaállítást a támogatott Dockup-felületen hajtsd végre, válaszd ki a pontos backupot, szerezd be a production jóváhagyását, majd ellenőrizd az eredményt.

A visszaállítási tervnek tartalmaznia kell:

1. A helyreállítási pontot és a várható elvesző írások időablakát.
2. Az alkalmazás írási műveleteinek leállítását vagy a karbantartási működést.
3. Az adatbázis- és extension-kompatibilitást.
4. A jelenlegi állapot friss biztonsági mentését, ha az hasznos.
5. A visszaállítás felelősét és a jóváhagyást.
6. Az alkalmazás újracsatlakoztatását és a smoke tesztet.
7. Az audit- és incidensrekordot.

A backupok csak akkor tekinthetők bizonyítottnak, ha egy restore drill sikeresen lefutott. Az eljárás teszteléséhez használj nem production adatbázist vagy jóváhagyott helyreállítási környezetet.

A backupokat jóváhagyott szabályzat szerint őrizd meg. Az elavult helyreállítási pontokat csak a támogatott adatbázis-felületen keresztül töröld, miután ellenőrizted, hogy sem helyreállítási, sem megfelelőségi követelmény nem függ már tőlük.

Hogyan működnek a csak olvasási jogosultságú PostgreSQL-felhasználók?

A további, csak olvasási jogosultságú felhasználók hasznosak analyticshez, support jellegű vizsgálatokhoz, preview deploymentekhez és olyan eszközökhöz, amelyeknek lekérdezéseket kell futtatniuk írás nélkül.

Felhasználók listázása:

dockup db users production/main-db --json

Hozz létre egyet labellel:

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

A létrehozás során generált hitelesítő adatot biztonságosan mentsd el, és ne jelenítsd meg agent-válaszban. Amikor megszűnik a célja, vond vissza a további felhasználót a támogatott adatbázis-felhasználó-kezelőfelületen.

Az adatbázis jogosultsági rétegében beállított csak olvasási jogosultság erősebb annál, mint amikor egy query toolnak azt mondod, hogy „ne írjon”. Ez továbbra is hozzáférést biztosít az olvasható production adatokhoz, ezért az adatvédelmi és least-privilege szabályok érvényesek.

A Dockup automatikusan létrehoz egy csak olvasási jogosultságú adatbázis-felhasználót egy PR- vagy branch-preview számára privát hálózatot használó projektben. A preview ugyanazt a production adatbázist érheti el a <slug>.internal címen, és olvashatja az adatokat, írási jogosultságot azonban nem kap.

Hogyan figyelheted a méretet, a naplókat és az elhelyezést?

A lemezen elfoglalt méret ellenőrzése:

dockup db size production/main-db --json

Vizsgáld meg az alkalmazás runtime naplóiban a kapcsolódási hibákat anélkül, hogy jelszavakat vagy teljes connection stringeket tennél közzé:

dockup logs production/api --json

Az adatbázis-karbantartás elérhetetlenné teheti a függő szolgáltatásokat. Az állapotot módosító műveleteket ütemezd, kérj kifejezett üzemeltetési jóváhagyást, és a végrehajtás előtt kommunikáld a hatást.

Adatbázis node-ok közötti áthelyezése cél node ID-jával:

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

A migráció stateful művelet. Ellenőrizd a backup állapotát, a karbantartással kapcsolatos elvárásokat, a privát hálózati kapcsolatokat és az áthelyezés utáni alkalmazás-ellenőrzéseket.

Managed PostgreSQL production ellenőrzőlista

A teljes runbook a következőket rögzíti:

Terület	Szükséges bizonyíték
Identitás	Pontos project/db target
Kapcsolat	Titkos connection string és tesztelt új session
Hálózat	Nyilvános, privát vagy kizárólag privát hozzáférési szabályzat
Hozzáférés	Alkalmazásszerepkör és labellel ellátott, csak olvasási jogosultságú felhasználók
Kapacitás	Aktuális méret és növekedési áttekintés
Backupok	Friss backup ID-k és megőrzési szabály
Helyreállítás	Sikeres restore drill
Üzemeltetés	Indítási, leállítási, újraindítási és migrációs jóváhagyás
Audit	Az adatbázis-módosítások visszakövethetők egy végrehajtóhoz

Az alkalmazás deployment rollbackje nem állítja vissza a PostgreSQL-t. Az adatbázis visszaállítása nem görgeti vissza automatikusan az alkalmazáskódot. Csak akkor hangold össze a kettőt, ha a séma kompatibilitása ezt megköveteli.

Átfogóbb scaling-döntésekhez olvasd el az adatbázis-scaling stratégiákról szóló útmutatót. A pontos parancsokért használd a Dockup CLI-referenciát.

Tervezz sémamigrációkat a deployhez és a rollbackhez

Az alkalmazás deploymentje és az adatbázisséma módosítása eltérő ütemezés szerint történik. A biztonságos migráció általában legalább egy release-ablakon keresztül visszafelé kompatibilis: előbb adj hozzá nullable oszlopot, majd telepíts olyan kódot, amely mindkét sémával képes működni, végezd el kontrolláltan a backfillt, és csak később távolítsd el a régi struktúrát.

Ne végeztess hosszú migrációt health checkben. Ha az alkalmazás több replikát indít, biztosítsd, hogy a módosítást csak egy migration runner hajthassa végre. A PRO konténer exec parancsával egyszeri parancs futtatható, és továbbítja annak valódi exit code-ját:

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

Csak akkor használd, ha a migrációs parancsot felülvizsgálták, és a szolgáltatás a támogatott main serveren fut. Mentsd el a stdoutot, a stderrt és az exit code-ot. A sikeres application deploy nem jelenti azt, hogy egy sikertelen migráció figyelmen kívül hagyható.

Rotáld az adatbázis hitelesítő adatait leállás nélkül

Hozd létre az új hitelesítő adatot vagy csak olvasási jogosultságú felhasználót, frissítsd a felhasználó szolgáltatás secretjét, redeployold a szolgáltatást, majd ellenőrizz egy új kapcsolatot, mielőtt visszavonnád a régi hitelesítő adatot. A meglévő connection poolok elrejthetik az új jelszó hibáját, amíg újra nem csatlakoznak.

Az elsődleges alkalmazás-hitelesítő adathoz használd a támogatott Dockup-felületet és az adatbázis szabályzatát. További analytics-felhasználó esetén hozz létre labellel ellátott, csak olvasási jogosultságú accountot, és csak a jóváhagyott fogyasztóhoz juttasd el.

A rotációs rekordban szerepeljen a felhasználó labelje, a felhasználó szolgáltatások, a deployment ID-k, az ellenőrző lekérdezés, a visszavonás időpontja és az audit-esemény — a jelszó soha.

Figyeld a növekedést, mielőtt skálázol

Az adatbázis mérete az egyik jelzőszám:

dockup db size production/main-db --json

Vesd össze az alkalmazás lekérdezési késleltetésével, a kapcsolatok számával, a cache működésével, a backup időtartamával és a storage növekedésével. A nagyobb CPU- vagy memóriaallokáció nem feltétlenül oldja meg a hiányzó indexek vagy a korlátlan lekérdezések problémáját.

Node-ok áthelyezése vagy az erőforrások növelése előtt tekintsd át az adatbázis-scaling stratégiákat. A Managed PostgreSQL csökkenti a kiépítéssel járó munkát, a séma- és lekérdezéstervezés azonban továbbra is az alkalmazás felelőssége.

Válaszd külön a rendelkezésre állást és a helyességet

A futó adatbázis-konténer azt bizonyítja, hogy a PostgreSQL elérhető, nem pedig azt, hogy az alkalmazás lekérdezései helyesek. A post-deploy ellenőrzés részeként végezz alacsony kockázatú új kapcsolattesztet és reprezentatív olvasási műveletet. Írási teszthez használj dedikált tranzakciót vagy olyan tesztrekordot, amely biztonságosan eltávolítható.

A managed PostgreSQL runbookjának azt is rögzítenie kell, hogy a replikák, az analytics-felhasználók, a preview-k vagy a háttérben futó workerek okoznak-e további kapcsolati terhelést.

Vizsgáld felül rendszeresen a PostgreSQL-hozzáférést

Listázd a további felhasználókat, ellenőrizd, hogy minden labelhez tartozik-e aktív felelős, és távolítsd el az elavult accountokat. Ez az egyszerű felülvizsgálat megakadályozza, hogy a managed PostgreSQL olvasási hozzáférése felhalmozódjon a preview-k, analytics-projektek vagy supportvizsgálatok lezárása után.

Kezdd ellenőrizhető deploymenttel

Hozz létre egy nem production PostgreSQL-adatbázist, csatlakoztass egy tesztszolgáltatást maszkolt secreten keresztül, készíts backupot, és végezz el egy restore drillet a production átállás előtt.

Indítsd el ingyen az app.dockup.ai oldalon. A Free csomag havi 0 dollárba kerül, 10 USD kezdő kreditet tartalmaz, és egy workspace-t, három adatbázist, valamint három deploymentet támogat.

GYIK

Milyen managed adatbázistípusokat támogat a Dockup?

A Dockup managed adatbázisként a PostgreSQL, a MySQL, a MongoDB és a Redis használatát támogatja.

Hogyan kapja meg az alkalmazás a PostgreSQL connection stringet?

A connection stringet secret környezeti változóként kezeld, állítsd be a pontos szolgáltatáson, majd redeployolj, hogy az új konténer megkapja.

Létrehozhat a Dockup csak olvasási jogosultságú PostgreSQL-felhasználót?

Igen. A database user-add parancs további, csak olvasási jogosultságú felhasználót hoz létre, és a jelszavát a létrehozáskor egyszer adja vissza.

Létezik dokumentált dockup db restore CLI-parancs?

A jelenlegi CLI-referencia nem dokumentál ilyet. A Dockup támogatja a backupok visszaállítását a platform felületén keresztül, ezért használd ezt a támogatott utat ahelyett, hogy flaget vagy parancsot találnál ki.

Visszaállítja az application rollback a PostgreSQL-adatbázist?

Nem. Az alkalmazás deploymentelőzményei és az adatbázis backupelőzményei külön helyreállítási rendszerek, és össze kell hangolni őket, ha a séma módosításai mindkettőt szükségessé teszik.