Privat netværk og .internal-domæner på Dockup

Privat netværk gør det muligt for tjenester og administrerede databaser i samme Dockup-projekt at kommunikere uden at sende trafik mellem projektets ressourcer over det offentlige internet. Hver ressource får et stabilt <slug>.internal-hostname, mens separate projekter fortsat er isolerede fra hinanden.

Netværket tilvælges aktivt. Når det aktiveres, forbindes projektets eksisterende ressourcer, uden at applikationstrafikken behøver at skifte med det samme, og tjenester modtager interne forbindelsesvariabler efter en ny deployment.

Hvordan reducerer service-til-service-netværk den offentlige eksponering?

Et offentligt database-endpoint kan nås fra internettet, selv når authentication forhindrer uautoriseret brug. En privat route fjerner denne eksponering for applikationstrafik og giver tjenesterne et stabilt internt navn, som ikke afhænger af en offentlig adresse.

Det samme princip gælder for kald mellem tjenester. En API kan kalde en worker, en intern admin-tjeneste eller en backend over projektnetværket i stedet for via et offentligt custom domain.

Trafiksti	Offentlig route	Privat route
API til PostgreSQL	Offentlig host og port	main-db.internal
Web til API	Offentligt custom domain	api.internal
Worker til Redis	Offentlig host og port	app-redis.internal
Preview til produktionsdatabase	Offentlig databasecredential	Skrivebeskyttet intern bruger
Kald på tværs af projekter	Offentligt endpoint påkrævet	Blokeret af projektisolering

Privat betyder ikke uden authentication. Fortsæt med at bruge databasebrugere, service authorization og secrets. Netværket bestemmer, hvad der kan nås; credentials bestemmer tilladelserne.

Hvordan aktiverer du privat netværk for et projekt?

Aktivér netværket for projektets slug:

dockup network enable production --json

Handlingen forbinder tjenester og administrerede databaser med projektnetværket. Eksisterende offentlige listeners er som standard stadig tilgængelige, så overgangen kan ske gradvist.

Deploy hver applikationstjeneste, der skal modtage interne environment variables:

dockup deploy production/api --wait --json
dockup deploy production/worker --wait --json

Dockup injicerer forbindelsesdata som DATABASE_URL_INTERNAL, databasespecifikke interne URL- og host-variabler samt host/port-værdier for tjenester. Inspicér tjenestens environment keys uden at eksponere secrets:

dockup env list -s production/api --json

Konstruér ikke manuelt en URL ud fra et visningsnavn. Ressourcernes slugs bestemmer <slug>.internal-hostnavnet.

Før du ændrer applikationens konfiguration, skal du kontrollere, at alle dependencies ligger i samme projekt. Separate projekter har separate netværk og kan ikke resolve eller nå hinanden via den interne sti.

Hvordan ændrer .internal-domæner tjenestekonfigurationen?

Intern DNS giver et stabilt navn, mens containere og nodes ændres under overfladen. En API-tjeneste med slug api kan nås som api.internal fra tjenester i samme projekt; en database med slug main-db kan nås som main-db.internal.

Foretræk de injicerede forbindelsesvariabler, når de er tilgængelige. De indeholder den korrekte protokol, credentials, databasenavn og host-format. En manuelt opbygget streng kan mangle TLS, password encoding eller databaseparametre.

Migrér én dependency ad gangen:

1. Aktivér netværket.
2. Deploy den tjeneste, der bruger dependency'en, igen.
3. Bekræft, at den interne variabel findes.
4. Skift applikationen til at bruge den.
5. Deploy med --wait.
6. Kontrollér nye forbindelser.
7. Overvåg runtime logs og svartid.
8. Fortsæt til næste dependency.

En tjeneste kan beholde sit offentlige custom domain til brugertrafik, mens den bruger private hostnames til backend-kald. Offentlige og private stier tjener forskellige trust boundaries.

Guiden environment variables and secrets forklarer, hvorfor ændringer i forbindelser kræver en ny deployment.

Hvordan gør du en administreret database udelukkende privat?

Når alle nødvendige consumers bruger den interne sti, kan du fjerne den offentlige listener:

dockup db private production/main-db --json

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

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

Denne databasehandling genskaber containeren, mens data bevares. Planlæg et passende maintenance window, bekræft, at der findes en nylig backup, og test, at applikationen kan oprette forbindelse igen.

Før du gør databasen udelukkende privat, skal du kontrollere:

• Alle produktionstjenester, der bruger databasen, ligger i samme projekt.
• Operational tools ikke kræver det offentlige endpoint.
• Preview-adgang bruger den understøttede private sti.
• Der findes en backup, og recovery-processen er forstået.
• Connection pools forsøger sikkert igen.
• Det nøjagtige project/db-target er dokumenteret.

En database, der kun er privat, kan ikke nås direkte fra en operatørs laptop via det offentlige internet. Brug platformens understøttede adgang og diagnostics på applikationsniveau i stedet for ukritisk at genåbne listeneren.

Se managed PostgreSQL for databaseoperationer.

Hvordan får PR-previews sikker adgang til produktionsdata?

Hvert Dockup-PR- eller branch-preview får sin egen isolerede deployment og URL. I et projekt med privat netværk tilsluttes previewet projektnetværket og kan resolve <slug>.internal.

Dockup opretter automatisk en skrivebeskyttet bruger til den administrerede produktionsdatabase, som previewet bruger. Previewet kan forespørge data med produktionsstruktur, men kan ikke skrive med denne bruger.

Dette design mindsker risikoen for, at en feature branch ændrer kundeoplysninger, men læseadgang har stadig konsekvenser:

• Personlige eller følsomme data kan blive vist i previewet.
• Ny applikationskode kan logge forespurgte data.
• En sårbar preview-URL kan eksponere resultater fra forespørgsler.
• Dyre queries kan påvirke belastningen på produktionen.
• Schema-forudsætninger kan være forskellige mellem branch og produktion.

Aktivér kun preview-deployment under en gennemgået policy:

dockup pr-preview production/api --on --json
dockup preview branch feature/search production/api --json

Brug previewets isolerede environment til feature flags og secrets, der ikke er databaseafhængige. Erstat ikke den automatiske skrivebeskyttede credential med produktionens write credential.

Hvordan overvåger og fejlsøger du privat netværk?

Start med topologi og konfiguration i stedet for at antage, at platformen er nede.

Symptom	Sandsynligt område	Kontrol
Navn ikke fundet	Forkert slug/projekt, eller tjenesten er ikke deployet igen	Tjenesteliste og environment keys
Connection refused	Ressource er stoppet, eller porten er forkert	Status og logs for database/tjeneste
Authentication failed	Forkert credential	Secret rotation og bruger
Offentlig adgang virker, privat adgang fejler	Intern variabel eller netværket er ikke taget i brug	Aktivér netværk, deploy igen
Preview kan læse, men ikke skrive	Forventet skrivebeskyttet policy	Erstat ikke credential
Kald på tværs af projekter fejler	Forventet isolation	Brug en offentlig, authenticated API

Inspicér applikationens runtime logs:

dockup logs production/api --json

Undersøg databasens størrelse og applikationens forbindelsesfejl:

dockup db size production/main-db --json
dockup logs production/api --json

Udskriv ikke komplette interne forbindelses-URL'er i incident-noter. De kan indeholde credentials, selv om selve hostnavnet ikke er en secret.

Plan for migration og rollback

Behold den offentlige listener i den første fase. Hvis den interne deployment fejler, skal du gendanne applikationens tidligere konfiguration og deploye igen. Gør først databasen udelukkende privat, når den interne sti har været stabil.

Deaktivér hele projektnetværket med:

dockup network disable production --json

Dette bør være en bevidst rollback og ikke det første fejlsøgningstrin. Deaktivering af netværket påvirker alle tilsluttede ressourcer i projektet.

Registrér ændringer af netværket i audit loggen:

dockup audit --writes --json

Produktionscheckliste for privat netværk

En komplet privat netværk-runbook indeholder projektets slug, tjeneste- og databaseslugs, interne hostnames, navne på injicerede variabler, policy for public listener, policy for preview-adgang, backupstatus, rækkefølgen for redeployments og rollback-stien.

CPU, RAM og disk er fortsat usage-based og måles pr. minut; privat routing er et arkitekturvalg og ikke en fast instance class. Brug PaaS pricing explained til cost modeling.

Dockup CLI reference indeholder de aktuelle kommandoer til netværk og databaser. Se security best practices for generel deployment-isolation.

Modellér service authorization separat fra reachability

Et internt hostname beviser kun, at kaldet kommer fra projektnetværket. Det beviser ikke, hvilken tjeneste der foretog kaldet, eller om tjenesten må udføre handlingen. Behold application authentication til følsomme interne API'er og databasecredentials til dataadgang.

Brug servicespecifikke secrets i stedet for ét fælles internt token. Hvis et preview modtager skrivebeskyttet databaseadgang, skal det heller ikke have et produktions-service-token, der kan udløse writes via en API.

Mål effekten af cutover

Sammenlign connection latency, error rate og p95-svartid før og efter skiftet til interne endpoints. Det primære mål er isolation og en stabil privat sti; enhver forbedring af latency bør måles i stedet for at blive lovet.

dockup uptime production/api --hours 24 --json

Bevar observationsvinduet og deployment-ID'et. Det giver ændringen til privat netværk et målbart afslutningskriterium i stedet for at slutte ved “DNS resolved”.

Dokumentér undtagelser fra den offentlige sti

En ekstern integration, et operator tool eller en tjeneste på tværs af projekter kan stadig kræve et offentligt endpoint. Angiv hver undtagelse samt authentication, ejer og betingelse for fjernelse. Det forhindrer, at den offentlige listener bliver stående på ubestemt tid, fordi ingen husker, hvorfor den findes.

En komplet udrulning af privat netværk kan være delvis, men alle offentlige stier bør være tilsigtede.

Gennemgå interne dependencies efter omdøbninger

En omdøbning eller udskiftning af en ressource kan ændre den slug, der bruges til .internal-adressering. Kortlæg consumers, før du ændrer navne, deploy dem igen med opdaterede injicerede variabler, og verificér alle private forbindelser.

Det holder privat netværk stabilt, efterhånden som projektet udvikler sig.

Start med en deployment, der kan verificeres

Aktivér netværk i et non-production-projekt, migrér én dependency til dens .internal-endpoint, og dokumentér rollback-stien, før du fjerner en offentlig listener.

Start gratis på app.dockup.ai. Free-planen koster $0 pr. måned, inkluderer $10 i startkredit og understøtter ét workspace, tre databaser og tre deployments.

FAQ

Hvilket hostname bruger Dockup-ressourcer på det private netværk?

Hver tjeneste og administrerede database i samme projekt kan nås via et stabilt hostname i formatet <slug>.internal.

Fjerner aktivering af privat netværk offentlig databaseadgang?

Nej. Netværket tilføjes som standard. Brug den separate database private-kommando til at fjerne den offentlige listener, når consumers bruger den interne sti.

Kan forskellige Dockup-projekter nå hinanden privat?

Nej. Hvert projekt har et isoleret netværk, så kommunikation på tværs af projekter skal bruge et passende offentligt og authenticated interface.

Kan et PR-preview skrive til produktionsdatabasen?

I et projekt med privat netværk opretter Dockup automatisk en skrivebeskyttet databasebruger til previewet, som tillader læsning, men forhindrer writes med denne credential.

Hvorfor skal tjenester deployes igen, efter at netværk er aktiveret?

En ny deployment giver den nye container de interne forbindelsesvariabler og lader applikationen starte med konfigurationen til det private endpoint.