Hanterad PostgreSQL på Dockup: komplett guide

Hanterad PostgreSQL ger en applikation en provisionerad databas med livscykelåtgärder som är separerade från tjänstens container. Dockup har stöd för att skapa, starta och stoppa databaser, visa loggar, granska storlek, säkerhetskopiera, återställa via plattformen, skapa skrivskyddade användare, migrera noder och använda privata nätverk.

Den viktigaste driftprincipen är separation: applikationsavbildningen är förbrukningsbar, PostgreSQL-data är beständig, autentiseringsuppgifter är hemligheter och databasåterställning måste testas separat från återställning av applikationen.

Hur skapar man en hanterad PostgreSQL-databas?

Välj den avsedda arbetsytan och skapa sedan databasen:

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

Lista databaser för att bekräfta exakt slug och status:

dockup db list --json

Databasåtgärder använder mål i formatet project/db:

dockup db size production/main-db --json

Vänta tills provisioneringen är klar innan du ansluter en applikation. Gissa inte värdnamn, port, användarnamn eller lösenord utifrån databasnamnet.

Free-planen tillåter tre databaser i en arbetsyta och inkluderar ett startkreditbelopp på 10 USD. Betalplanerna – Hobby för 5 USD, Pro för 20 USD per månad – tillåter obegränsat antal databaser, arbetsytor och driftsättningar. CPU-, RAM- och diskanvändning mäts per minut mot det inkluderade användningssaldot.

Hur ansluter man en applikation säkert?

Hämta databasens anslutningsuppgifter från Dockups databasgränssnitt och behandla anslutningssträngen som en hemlighet. Klistra inte in den i kodarkivet eller agentens transkription.

Ange den för tjänsten:

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

dockup deploy production/api --wait --json

En ny driftsättning krävs eftersom den körande processen fick sin miljö vid uppstart. Det lagrade värdet maskeras när miljökonfigurationen läses.

Konfigurera applikationens connection pooling medvetet. För många applikationsarbetare med stora pooler kan tömma databasens anslutningar även när CPU och minne verkar vara tillräckliga. Ange poolstorleken utifrån arbetsbelastning och databaskapacitet, inte utifrån det maximala antalet som ett ramverk accepterar.

Testa en ny anslutning efter driftsättningen. En health endpoint kan bekräfta att HTTP-processen körs utan att bevisa att en ny databassession kan etableras.

Guiden om miljövariabler och hemligheter beskriver hur du roterar autentiseringsuppgifter och hanterar maskerade utdata.

Hur skyddar privata nätverk PostgreSQL-trafik?

Aktivera ett privat projektnätverk:

dockup network enable production --json

Tjänster och hanterade databaser i projektet får stabila värdnamn i formatet <slug>.internal. Driftsätt applikationen igen för att få de injicerade interna anslutningsvariablerna.

Ta bort databasens publika listener och gör den tillgänglig endast privat:

dockup db private production/main-db --json

Återställ både publik och privat åtkomst när det behövs:

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

Att göra databasen tillgänglig endast privat återskapar dess container men bevarar data. Schemalägg och verifiera ändringen som en databasåtgärd, inte som en ofarlig DNS-ändring.

Privata nätverk styr rutten, medan PostgreSQL-autentiseringsuppgifter styr identitet och behörighet. Behåll båda. Separata projekt kan inte nå varandra eftersom varje projekt har sitt eget nätverk.

Artikeln om privata nätverk och interna domäner beskriver hela topologin.

Hur fungerar säkerhetskopiering och återställning av PostgreSQL?

Lista befintliga säkerhetskopior:

dockup db backups production/main-db --json

Starta en serverbaserad säkerhetskopiering:

dockup db backup production/main-db --json

Säkerhetskopieringskommandot skapar en databasmedveten säkerhetskopia i stället för en livekopia av den råa volymen. Dokumentera säkerhetskopieringens ID, skapandetid, databasversion och anledning.

Dockup har stöd för att återställa säkerhetskopior av hanterade databaser via plattformen. Den aktuella CLI-referensen dokumenterar inte något kommando dockup db restore, så den här guiden hittar inte på något. Genomför återställningen från Dockups stödda gränssnitt, välj den exakta säkerhetskopian, inhämta produktionsgodkännande och verifiera resultatet.

En återställningsplan bör innehålla:

1. Återställningspunkt och förväntat fönster för förlorade skrivningar.
2. Frysning av applikationsskrivningar eller planerat underhåll.
3. Kompatibilitet för databas och tillägg.
4. En färsk säkerhetskopia av det aktuella tillståndet när det är lämpligt.
5. Ansvarig för återställningen och godkännande.
6. Återanslutning av applikationen och smoke test.
7. Gransknings- och incidentdokumentation.

Säkerhetskopior är inte bevisat användbara förrän en återställningsövning har lyckats. Använd en databas som inte är i produktion eller en godkänd återställningsmiljö för att testa proceduren.

Spara säkerhetskopior enligt en godkänd policy. Ta endast bort föråldrade återställningspunkter via det stödda databasgränssnittet efter att du har verifierat att inget återställnings- eller efterlevnadskrav längre är beroende av dem.

Hur fungerar skrivskyddade PostgreSQL-användare?

Ytterligare skrivskyddade användare är användbara för analytics, supportutredningar, preview-driftsättningar och verktyg som måste kunna läsa utan att skriva.

Lista användare:

dockup db users production/main-db --json

Skapa en med en etikett:

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

Spara den genererade autentiseringsuppgiften säkert under skapandet och återge den inte i ett agentsvar. Återkalla den extra användaren via det stödda gränssnittet för användarhantering av databasen när syftet med den har upphört.

Skrivskydd på databasens behörighetsnivå är starkare än att säga till ett query-verktyg ”skriv inte”. Det tillåter fortfarande åtkomst till läsbar produktionsdata, så regler för integritet och minsta privilegium gäller.

Dockup skapar automatiskt en skrivskyddad databasanvändare för en PR- eller branch-preview i ett projekt med privat nätverk. Preview-miljön kan nå samma produktionsdatabas på <slug>.internal och läsa data utan att få skrivrättigheter.

Hur övervakar man storlek, loggar och placering?

Granska storleken på disken:

dockup db size production/main-db --json

Granska applikationens runtime-loggar efter anslutningsfel utan att exponera lösenord eller fullständiga anslutningssträngar:

dockup logs production/api --json

Databasunderhåll kan göra beroende tjänster otillgängliga. Schemalägg tillståndsändrande åtgärder, kräv uttryckligt driftgodkännande och kommunicera påverkan innan du agerar.

Flytta en databas mellan noder med ett mål-node-ID:

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

En migrering är en stateful åtgärd. Bekräfta status för säkerhetskopior, förväntat underhåll, anslutningar via privata nätverk och kontroller av applikationen efter flytten.

Checklista för hanterad PostgreSQL i produktion

En komplett runbook dokumenterar:

Område	Obligatoriskt underlag
Identitet	Exakt mål i formatet project/db
Anslutning	Hemlig anslutningssträng och testad ny session
Nätverk	Policy för publik, privat eller endast privat åtkomst
Åtkomst	Applikationsroll och etiketterade skrivskyddade användare
Kapacitet	Aktuell storlek och granskning av tillväxt
Säkerhetskopior	Nya säkerhetskopierings-ID:n och lagringstid
Återställning	Genomförd återställningsövning
Drift	Godkännande för start, stopp, omstart och migrering
Granskning	Databasändringar som kan spåras till en aktör

En rollback av applikationsdriftsättningen återställer inte PostgreSQL. En databasåterställning rullar inte automatiskt tillbaka applikationskod. Samordna båda endast när schemakompatibilitet kräver det.

För bredare beslut om skalning, läs strategier för databasskalning. Använd Dockup CLI-referensen för exakta kommandon.

Utforma schemamigreringar för driftsättning och rollback

Applikationsdriftsättning och ändringar av databasschemat sker enligt olika tidslinjer. En säker migrering är vanligtvis bakåtkompatibel under minst ett releasefönster: lägg till en nullable-kolumn innan den görs obligatorisk, driftsätt kod som kan hantera båda schemana, fyll på data i en kontrollerad process och ta bort den gamla strukturen senare.

Låt inte en health check utföra en lång migrering. Om applikationen startar flera repliker måste du se till att endast en migration runner kan äga ändringen. PRO-containerns exec-kommando kan köra ett engångskommando och vidarebefordra dess verkliga exit code:

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

Använd det endast när migreringskommandot är granskat och tjänsten körs på den stödda huvudservern. Samla in stdout, stderr och exit code. En lyckad applikationsdriftsättning innebär inte att en misslyckad migrering kan ignoreras.

Rotera databasautentiseringsuppgifter utan driftstopp

Skapa den nya autentiseringsuppgiften eller skrivskyddade användaren, uppdatera den konsumerande tjänstens secret, driftsätt igen och verifiera en ny anslutning innan du återkallar den gamla autentiseringsuppgiften. Befintliga connection pools kan dölja ett felaktigt nytt lösenord tills de ansluter igen.

För applikationens primära autentiseringsuppgift använder du Dockups stödda gränssnitt och databasens policy. För en extra analytisk användare skapar du ett etiketterat skrivskyddat konto och distribuerar det endast till den godkända konsumenten.

Rotationsloggen ska ange användarens etikett, konsumerande tjänster, driftsättnings-ID:n, verifieringsfråga, tidpunkt för återkallande och granskningshändelse – aldrig lösenordet.

Observera tillväxt innan du skalar

Databasstorlek är en signal:

dockup db size production/main-db --json

Kombinera den med applikationens query latency, antal anslutningar, cachebeteende, säkerhetskopieringens varaktighet och lagringens tillväxt. En större CPU- eller minnesallokering behöver inte lösa saknade index eller obegränsade frågor.

Läs strategier för databasskalning innan du flyttar noder eller ökar resurserna. Hanterad PostgreSQL minskar arbetet med provisionering, men schema- och querydesign är fortfarande applikationens ansvar.

Separera tillgänglighet från korrekthet

En körande databascontainer bevisar att PostgreSQL är tillgängligt, inte att applikationens frågor är korrekta. Inkludera en riskfri ny anslutning och en representativ läsning i verifieringen efter driftsättning. För ett skrivtest använder du en dedikerad transaktion eller testpost som kan tas bort på ett säkert sätt.

Runbooken för hanterad PostgreSQL bör också ange om repliker, analytics-användare, preview-miljöer eller bakgrundsarbetare skapar ytterligare anslutningsbelastning.

Granska PostgreSQL-åtkomst regelbundet

Lista extra användare, bekräfta att varje etikett har en aktiv ägare och ta bort föråldrade konton. Den här enkla granskningen förhindrar att hanterad PostgreSQL samlar på sig läsåtkomst efter att preview-miljöer, analytics-projekt eller supportutredningar har avslutats.

Börja med en verifierbar driftsättning

Skapa en PostgreSQL-databas som inte är i produktion, anslut en testtjänst via en maskerad secret, ta en säkerhetskopia och genomför en återställningsövning före övergången till produktion.

Kom igång gratis på app.dockup.ai. Free-planen kostar 0 USD per månad, inkluderar ett startkreditbelopp på 10 USD och har stöd för en arbetsyta, tre databaser och tre driftsättningar.

Vanliga frågor

Vilka typer av hanterade databaser har Dockup stöd för?

Dockup har stöd för hanterade databaser med PostgreSQL, MySQL, MongoDB och Redis.

Hur bör en applikation ta emot sin PostgreSQL-anslutningssträng?

Behandla anslutningssträngen som en hemlig miljövariabel, ange den för exakt rätt tjänst och driftsätt igen så att den nya containern får den.

Kan Dockup skapa en skrivskyddad PostgreSQL-användare?

Ja. Kommandot database user-add skapar en extra skrivskyddad användare och returnerar lösenordet en gång när användaren skapas.

Finns det ett dokumenterat CLI-kommando för dockup db restore?

Den aktuella CLI-referensen dokumenterar inte något sådant. Dockup har stöd för återställning av säkerhetskopior via plattformens gränssnitt, så använd den stödda vägen i stället för att hitta på en flagga eller ett kommando.

Återställer en rollback av applikationen PostgreSQL-databasen?

Nej. Historiken för applikationsdriftsättningar och historiken för databassäkerhetskopior är separata återställningssystem och måste samordnas när schemändringar kräver båda.