Managed PostgreSQL på Dockup: Komplet guide

Managed PostgreSQL giver en applikation en provisioneret database med lifecycle-operationer, der er adskilt fra service-containeren. Dockup understøtter oprettelse, start og stop, logs, kontrol af størrelse, backups, gendannelse via platformen, read-only-brugere, nodemigrering og private netværk.

Det vigtigste driftsprincip er adskillelse: Applikationsimaget kan kasseres, PostgreSQL-dataene er persistente, credentials er secrets, og databasegendannelse skal testes uafhængigt af rollback af applikationen.

Hvordan opretter man en managed PostgreSQL-database?

Vælg det ønskede workspace, og opret derefter databasen:

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

Vis en liste over databaser for at bekræfte den præcise slug og status:

dockup db list --json

Databaseoperationer bruger targets i formatet project/db:

dockup db size production/main-db --json

Vent, indtil provisioneringen er fuldført, før du tilknytter en applikation. Gæt ikke hostname, port, brugernavn eller password ud fra databasenavnet.

Free-abonnementet tillader tre databaser i ét workspace og inkluderer en startkredit på $10. Betalte abonnementer—Hobby til $5, Pro til $20 om måneden—tillader et ubegrænset antal databaser, workspaces og deployments. Forbruget af CPU, RAM og disk måles pr. minut i forhold til den inkluderede forbrugsbalance.

Hvordan tilslutter man en applikation sikkert?

Hent databaseforbindelsesoplysningerne fra Dockups databaseinterface, og behandl connection string som en secret. Indsæt den ikke i repositoryet eller i agentens transcript.

Sæt den på servicen:

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

dockup deploy production/api --wait --json

Redeploy er nødvendigt, fordi den kørende proces modtog sit environment ved opstart. Den gemte værdi maskeres, når environment-konfigurationen læses.

Konfigurér applikationens connection pooling bevidst. For mange application workers med store pools kan opbruge databaseforbindelser, selv når CPU og hukommelse ser sunde ud. Fastlæg poolstørrelsen ud fra workload og databasekapacitet, ikke ud fra det maksimale antal, som et framework accepterer.

Test en ny forbindelse efter deployment. Et health endpoint kan bekræfte, at HTTP-processen er aktiv, uden at bevise, at en ny databasesession kan etableres.

Guiden om environment variables og secrets beskriver credential rotation og maskeret output.

Hvordan beskytter private netværk PostgreSQL-trafik?

Aktivér et projektspecifikt private network:

dockup network enable production --json

Services og managed databases i projektet får stabile hostnames på formen <slug>.internal. Redeploy applikationen for at modtage de injicerede interne connection variables.

Sådan fjerner du databasens offentlige listener og gør den tilgængelig udelukkende privat:

dockup db private production/main-db --json

Gendan offentlig adgang sammen med privat adgang, når det er nødvendigt:

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

Når databasen gøres tilgængelig udelukkende privat, genskabes dens container, mens dataene bevares. Planlæg og verificér ændringen som en databaseoperation, ikke som en harmløs DNS-ændring.

Private netværk styrer ruten, mens PostgreSQL-credentials styrer identitet og autorisation. Bevar begge dele. Separate projekter kan ikke nå hinanden, fordi hvert projekt har sit eget netværk.

Artiklen om private netværk og interne domæner beskriver den fulde topologi.

Hvordan fungerer PostgreSQL-backups og gendannelse?

Vis eksisterende backups:

dockup db backups production/main-db --json

Start en server-side backup:

dockup db backup production/main-db --json

Backup-kommandoen opretter en databasebevidst backup i stedet for en hot copy af det rå volume. Registrér backup-ID, oprettelsestidspunkt, databaseversion og årsag.

Dockup understøtter gendannelse af backups fra managed databases via platformen. Den aktuelle CLI-reference dokumenterer ikke en dockup db restore-kommando, så denne guide opfinder ikke en. Udfør gendannelsen fra den understøttede Dockup-grænseflade, vælg den præcise backup, indhent godkendelse fra produktionen, og verificér resultatet.

En gendannelsesplan bør omfatte:

1. Recovery point og det forventede vindue for mistede writes.
2. Frysning af writes i applikationen eller planlagt maintenance-adfærd.
3. Kompatibilitet mellem database og extensions.
4. En frisk backup af den aktuelle tilstand, når det er relevant.
5. Ansvarlig for gendannelse og godkendelse.
6. Genforbindelse af applikationen og smoke test.
7. Audit- og incident-registrering.

Backups er ikke dokumenteret som pålidelige, før en restore drill er gennemført. Brug en ikke-produktionsdatabase eller et godkendt recovery-miljø til at teste proceduren.

Opbevar backups i henhold til en godkendt politik. Fjern kun forældede recovery points via den understøttede databasegrænseflade, når du har verificeret, at ingen recovery- eller compliance-krav længere afhænger af dem.

Hvordan fungerer read-only PostgreSQL-brugere?

Ekstra read-only-brugere er nyttige til analytics, supportundersøgelser, preview-deployments og værktøjer, der skal kunne læse uden at skrive.

Vis brugere:

dockup db users production/main-db --json

Opret en bruger med en label:

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

Gem den genererede credential sikkert under oprettelsen, og gengiv den ikke i et agentsvar. Tilbagekald den ekstra bruger via den understøttede grænseflade til databasebrugeradministration, når formålet ophører.

Read-only på databasens permissions-lag er stærkere end at fortælle et query-værktøj “skriv ikke”. Det giver stadig adgang til læsbare produktionsdata, så reglerne for privacy og least privilege gælder.

Dockup opretter automatisk en read-only-databasebruger til et PR- eller branch-preview i et projekt med private netværk. Previewet kan tilgå den samme produktionsdatabase på <slug>.internal og læse data uden at få skriveadgang.

Hvordan overvåger man størrelse, logs og placering?

Kontrollér størrelse på disken:

dockup db size production/main-db --json

Gennemgå applikationens runtime-logs for forbindelsesfejl uden at eksponere passwords eller komplette connection strings:

dockup logs production/api --json

Databasevedligeholdelse kan gøre afhængige services utilgængelige. Planlæg state-changing-operationer, kræv eksplicit operationel godkendelse, og kommunikér påvirkningen, før du handler.

Flyt en database mellem noder med et target node-ID:

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

Migrering er en stateful operation. Bekræft backupstatus, forventninger til maintenance, private netværksforbindelser og applikationskontroller efter flytningen.

Tjekliste til Managed PostgreSQL i produktion

En komplet runbook registrerer:

Område	Påkrævet dokumentation
Identitet	Præcist project/db-target
Forbindelse	Secret connection string og testet ny session
Netværk	Politik for offentlig, privat eller udelukkende privat adgang
Adgang	Applikationsrolle og read-only-brugere med labels
Kapacitet	Aktuel størrelse og gennemgang af vækst
Backups	Nylige backup-ID'er og retention
Recovery	Gennemført restore drill
Drift	Godkendelse af start, stop, restart og migrering
Audit	Databaseændringer, der kan spores til en aktør

Rollback af applikationsdeployment gendanner ikke PostgreSQL. Gendannelse af databasen ruller ikke automatisk applikationskoden tilbage. Koordinér kun begge dele, når schema-kompatibilitet kræver det.

Læs strategier til databaseskalering for bredere beslutninger om skalering. Brug Dockup CLI-referencen for de præcise kommandoer.

Design schema migrations til deploy og rollback

Applikationsdeployment og ændringer i databaseschemaet sker på forskellige tidspunkter. En sikker migration er normalt backward compatible i mindst ét release-vindue: Tilføj en nullable kolonne, før den gøres påkrævet, deploy kode, der kan håndtere begge schemaer, backfill i en kontrolleret proces, og fjern den gamle struktur senere.

Lad ikke et health check udføre en lang migration. Hvis applikationen starter flere replicas, skal du sikre, at kun én migration runner kan eje ændringen. PRO-containerens exec-kommando kan køre en one-shot-kommando og videreføre dens reelle exit code:

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

Brug den kun, når migrationskommandoen er gennemgået, og servicen kører på den understøttede main-server. Registrér stdout, stderr og exit code. Et vellykket application deploy betyder ikke, at en mislykket migration kan ignoreres.

Rotér databasecredentials uden nedetid

Opret den nye credential eller read-only-bruger, opdatér den forbrugende services secret, deploy igen, og verificér en ny forbindelse, før du tilbagekalder den gamle credential. Eksisterende connection pools kan skjule en forkert ny adgangskode, indtil de genopretter forbindelsen.

For den primære applikationscredential skal du bruge den understøttede Dockup-grænseflade og databasepolitikken. For en ekstra analytisk bruger skal du oprette en read-only-konto med en label og kun distribuere den til den godkendte forbruger.

Rotationsregistreringen bør angive brugerens label, forbrugende services, deployment-ID'er, verification query, tidspunkt for tilbagekaldelse og audit-event—aldrig passwordet.

Overvåg vækst, før du skalerer

Databasestørrelse er ét signal:

dockup db size production/main-db --json

Sammenhold den med applikationens query latency, antal forbindelser, cache-adfærd, backupvarighed og vækst i storage. En større CPU- eller memory-allokering løser ikke nødvendigvis manglende indexes eller queries uden begrænsning.

Gennemgå strategier til databaseskalering, før du flytter noder eller øger ressourcerne. Managed PostgreSQL reducerer arbejdet med provisionering, men schema- og querydesign er fortsat applikationens ansvar.

Adskil tilgængelighed fra korrekthed

En kørende databasecontainer beviser, at PostgreSQL er tilgængelig, ikke at applikationens queries er korrekte. Inkludér en risikofattig ny forbindelse og en repræsentativ read i verifikationen efter deployment. Ved en writetest skal du bruge en dedikeret transaction eller testrecord, der kan fjernes sikkert.

Runbooken for managed PostgreSQL bør også angive, om replicas, analytics-brugere, previews eller background workers skaber yderligere pres på antallet af forbindelser.

Gennemgå PostgreSQL-adgang regelmæssigt

Vis ekstra brugere, bekræft, at hver label har en aktiv ejer, og fjern forældede konti. Denne enkle gennemgang forhindrer, at read-adgang til managed PostgreSQL ophobes, efter at previews, analytics-projekter eller supportundersøgelser er afsluttet.

Start med et deployment, der kan verificeres

Opret en PostgreSQL-database til ikke-produktion, tilslut en testservice via en maskeret secret, tag en backup, og gennemfør en restore drill, før du skifter til produktion.

Kom gratis i gang på app.dockup.ai. Free-abonnementet koster $0 om måneden, inkluderer $10 i startkredit og understøtter ét workspace, tre databaser og tre deployments.

FAQ

Hvilke managed database-typer understøtter Dockup?

Dockup understøtter managed databases med PostgreSQL, MySQL, MongoDB og Redis.

Hvordan bør en applikation modtage sin PostgreSQL-connection string?

Behandl connection string som en secret environment variable, sæt den på den præcise service, og deploy igen, så den nye container modtager den.

Kan Dockup oprette en read-only PostgreSQL-bruger?

Ja. Databasekommandoen user-add opretter en ekstra read-only-bruger og returnerer dens password én gang ved oprettelsen.

Findes der en dokumenteret dockup db restore CLI-kommando?

Den aktuelle CLI-reference dokumenterer ikke en sådan. Dockup understøtter gendannelse af backups via platformens grænseflade, så brug den understøttede vej i stedet for at opfinde et flag eller en kommando.

Gendanner rollback af applikationen PostgreSQL-databasen?

Nej. Applikationens deploymenthistorik og databasens backuphistorik er separate recovery-systemer og skal koordineres, når schemaændringer kræver begge dele.