Privátní síťování a domény .internal na Dockup

Privátní síťování umožňuje službám a spravovaným databázím v rámci jednoho projektu Dockup komunikovat, aniž by provoz mezi zdroji stejného projektu procházel veřejným internetem. Každý zdroj získá stabilní hostname <slug>.internal, zatímco jednotlivé projekty zůstávají navzájem izolované.

Síťování je opt-in. Jeho aktivace propojí stávající zdroje projektu, aniž by bylo nutné okamžitě přesměrovat aplikační provoz, a služby po redeployi obdrží interní connection variables.

Jak síťování mezi službami omezuje vystavení veřejnému internetu?

Veřejný endpoint databáze je dostupný z internetu, i když authentication brání neoprávněnému použití. Privátní route toto vystavení aplikačního provozu eliminuje a poskytuje službám stabilní interní název, který nezávisí na veřejné adrese.

Stejný princip platí i pro volání mezi službami. API může volat worker, interní admin service nebo backend přes projektovou síť namísto veřejné custom domény.

Cesta provozu	Veřejná route	Privátní route
API do PostgreSQL	Veřejný host a port	main-db.internal
Web do API	Veřejná custom doména	api.internal
Worker do Redis	Veřejný host a port	app-redis.internal
Preview do produkční DB	Veřejné DB credentials	Interní uživatel pouze pro čtení
Volání mezi projekty	Vyžaduje veřejný endpoint	Blokováno izolací projektů

Privátní neznamená bez authentication. Nadále používejte database users, autorizaci služeb a secrets. Síť určuje dostupnost; credentials určují oprávnění.

Jak aktivovat privátní síťování projektu?

Aktivujte síť pro slug projektu:

dockup network enable production --json

Operace připojí služby a spravované databáze k projektové síti. Stávající veřejné listenery zůstanou ve výchozím nastavení dostupné, takže migraci lze provést postupně.

Proveďte redeploy každé aplikační služby, která má obdržet interní environment variables:

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

Dockup vloží connection data, například DATABASE_URL_INTERNAL, interní URL a host variables specifické pro databázi a hodnoty host/port služeb. Klíče service environment si můžete zobrazit bez odhalení secrets:

dockup env list -s production/api --json

URL nesestavujte ručně z display name. Hostname <slug>.internal se určuje podle slugů zdrojů.

Než změníte konfiguraci aplikace, ověřte, že každá dependency patří do stejného projektu. Samostatné projekty mají samostatné sítě a přes interní cestu se navzájem nemohou resolvovat ani kontaktovat.

Jak domény .internal mění konfiguraci služeb?

Interní DNS poskytuje stabilní název, i když se podkladové containery a nodes mění. Služba se slugem api je ze služeb stejného projektu dostupná na api.internal; databáze se slugem main-db je dostupná na main-db.internal.

Pokud jsou k dispozici injected connection variables, upřednostněte je. Obsahují správný protocol, credentials, název databáze i formát hostu. Ručně sestavený string může vynechat TLS, encoding hesla nebo parametry databáze.

Migrujte vždy jednu dependency:

1. Aktivujte síť.
2. Proveďte redeploy consuming service.
3. Ověřte, že interní variable existuje.
4. Změňte aplikaci tak, aby ji používala.
5. Proveďte deploy s --wait.
6. Ověřte nová připojení.
7. Sledujte runtime logs a response time.
8. Pokračujte další dependency.

Služba si může ponechat veřejnou custom doménu pro user traffic a současně používat privátní hostnames pro backendová volání. Veřejné a privátní cesty slouží různým trust boundaries.

Příručka environment variables a secrets vysvětluje, proč změny připojení vyžadují redeploy.

Jak nastavit spravovanou databázi pouze pro privátní přístup?

Poté, co všechny požadované consumers používají interní cestu, odstraňte veřejný listener:

dockup db private production/main-db --json

V případě potřeby obnovte veřejný i privátní přístup:

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

Tato databázová operace znovu vytvoří container a zachová data. Naplánujte maintenance window odpovídající workloadu, ověřte aktuální backup a otestujte opětovné připojení aplikace.

Než databázi nastavíte pouze pro privátní přístup, zkontrolujte:

• Každá production service používající databázi je ve stejném projektu.
• Operational tools nepotřebují veřejný endpoint.
• Přístup preview prostředí používá podporovanou privátní cestu.
• Existuje backup a postup obnovy je známý.
• Connection pools bezpečně opakují neúspěšná připojení.
• Je zaznamenán přesný target project/db.

K databázi dostupné pouze privátně se nelze přímo připojit z notebooku operátora přes veřejný internet. Používejte podporovaný přístup platformy a diagnostiku na úrovni aplikace, místo abyste listener bez rozmyslu znovu otevírali.

Informace o databázových operacích najdete v příručce spravovaný PostgreSQL.

Jak PR previews bezpečně přistupují k produkčním datům?

Každé Dockup PR nebo branch preview získá vlastní izolovaný deployment a URL. V projektu s privátním síťováním se preview připojí k projektové síti a může resolvovat <slug>.internal.

Dockup automaticky vytvoří uživatele pouze pro čtení pro produkční spravovanou databázi používanou preview prostředím. Preview může dotazovat data ve tvaru odpovídajícím produkci, ale prostřednictvím tohoto uživatele do nich nemůže zapisovat.

Tento návrh snižuje riziko, že feature branch změní zákaznické záznamy, ale přístup pro čtení má stále důsledky:

• V preview prostředí se mohou objevit osobní nebo citlivá data.
• Nový aplikační kód může dotazovaná data zapisovat do logs.
• Zranitelná preview URL může vystavit výsledky dotazů.
• Náročné dotazy mohou ovlivnit zátěž produkce.
• Předpoklady ohledně schématu se mohou mezi branchem a produkcí lišit.

Deployment preview povolujte pouze podle schválené policy:

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

Pro feature flags a secrets nesouvisející s databází používejte izolované environment preview prostředí. Automaticky vytvořené credentials pouze pro čtení nenahrazujte produkčními credentials pro zápis.

Jak sledovat a řešit problémy s privátním síťováním?

Začněte topologií a konfigurací, místo abyste automaticky předpokládali výpadek platformy.

Příznak	Pravděpodobná oblast	Kontrola
Název nebyl nalezen	Nesprávný slug/projekt nebo neprovedený redeploy služby	Seznam služeb a klíče env
Připojení odmítnuto	Zdroj je zastavený nebo je použit nesprávný port	Status a DB/service logs
Authentication selhala	Nesprávné credentials	Rotace secretu a uživatel
Veřejná cesta funguje, privátní ne	Interní variable nebo adopce sítě	Aktivace sítě, redeploy
Preview může číst, ale ne zapisovat	Očekávaná read-only policy	Credentials nenahrazujte
Volání mezi projekty selhává	Očekávaná izolace	Použijte veřejné authenticated API

Prohlédněte runtime logs aplikace:

dockup logs production/api --json

Zkontrolujte velikost databáze a chyby připojení aplikace:

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

Do incident notes nevypisujte celé interní connection URLs. Mohou obsahovat credentials, přestože samotný hostname není secret.

Plán migrace a rollbacku

V první fázi ponechte veřejný listener. Pokud interní deployment selže, obnovte předchozí konfiguraci aplikace a proveďte redeploy. Databázi nastavte pouze pro privátní přístup až poté, co bude interní cesta stabilní.

Chcete-li zakázat síť celého projektu:

dockup network disable production --json

Mělo by jít o záměrný rollback, nikoli první krok při řešení problémů. Zakázání sítě ovlivní každý připojený zdroj v projektu.

Změny sítě zaznamenávejte prostřednictvím audit logu:

dockup audit --writes --json

Checklist pro privátní síťování v produkci

Kompletní runbook pro privátní síťování zahrnuje slug projektu, slugy služeb a databází, interní hostnames, názvy injected variables, policy veřejných listenerů, policy přístupu preview prostředí, stav backupů, pořadí redeployů a rollback path.

CPU, RAM a disk se nadále účtují podle využití a měří po minutách; privátní routing je architektonické rozhodnutí, nikoli pevně daná instance class. Pro modelování nákladů použijte vysvětlení PaaS pricingu.

Aktuální network a database commands obsahuje reference Dockup CLI. Obecné informace o izolaci deploymentů najdete v security best practices.

Modelujte autorizaci služeb odděleně od dostupnosti

Interní hostname pouze potvrzuje, že caller je v projektové síti. Neříká, která služba požadavek odeslala ani zda tato služba smí danou akci provést. Pro citlivá interní API zachovejte aplikační authentication a pro přístup k datům database credentials.

Používejte secrets specifické pro jednotlivé služby namísto jednoho sdíleného interního tokenu. Pokud preview obdrží přístup k databázi pouze pro čtení, neposkytujte mu zároveň produkční service token, který může přes API spouštět zápisy.

Změřte dopad přepnutí

Porovnejte latenci připojení, error rate a p95 response time před přepnutím na interní endpointy a po něm. Hlavním cílem je izolace a stabilní privátní cesta; případné zlepšení latence měřte, místo abyste ho slibovali.

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

Uchovejte observation window a deployment ID. Změna privátního síťování tak získá měřitelné kritérium dokončení namísto ukončení ve chvíli, kdy „DNS resolvovalo“.

Zdokumentujte výjimky pro veřejnou cestu

Některá externí integrace, operator tool nebo služba z jiného projektu může stále vyžadovat veřejný endpoint. U každé výjimky uveďte authentication, vlastníka a podmínku odstranění. Zabráníte tak tomu, aby veřejný listener zůstal aktivní neomezeně dlouho jen proto, že si nikdo nepamatuje důvod jeho existence.

Kompletní rollout privátního síťování může být částečný, ale každá veřejná cesta musí být záměrná.

Po přejmenování zkontrolujte interní dependencies

Přejmenování nebo nahrazení zdroje může změnit slug používaný pro adresování přes .internal. Před změnou názvů zmapujte consumers, proveďte jejich redeploy s aktualizovanými injected variables a ověřte každé privátní připojení.

Díky tomu zůstane privátní síťování stabilní i při vývoji projektu.

Začněte ověřitelným deploymentem

Aktivujte síťování v neprodukčním projektu, migrujte jednu dependency na její .internal endpoint a před odstraněním veřejného listeneru ověřte možnost rollbacku.

Začněte zdarma na app.dockup.ai. Free plan stojí 0 $ měsíčně, zahrnuje počáteční kredit 10 $ a podporuje jeden workspace, tři databáze a tři deploymenty.

FAQ

Jaký hostname používají zdroje Dockup v privátní síti?

Každá služba a spravovaná databáze ve stejném projektu je dostupná prostřednictvím stabilního hostname ve tvaru <slug>.internal.

Odstraní aktivace privátního síťování veřejný přístup k databázi?

Ne. Síť se ve výchozím nastavení přidává. Veřejný listener odstraňte samostatným database private commandem až poté, co consumers používají interní cestu.

Mohou se různé Dockup projekty navzájem privátně kontaktovat?

Ne. Každý projekt má izolovanou síť, takže komunikace mezi projekty musí používat vhodné veřejné a authenticated rozhraní.

Může PR preview zapisovat do produkční databáze?

V projektu s privátním síťováním Dockup automaticky vytvoří pro preview database usera pouze pro čtení, který umožňuje čtení, ale prostřednictvím těchto credentials zabraňuje zápisu.

Proč se služby musí po aktivaci síťování znovu nasadit?

Redeploy poskytne novému containeru interní connection variables a umožní aplikaci spustit se s konfigurací privátního endpointu.