Private networking a domény .internal na Dockup

Private networking umožňuje službám a spravovaným databázam v rámci jedného projektu Dockup komunikovať bez toho, aby premávka medzi zdrojmi toho istého projektu prechádzala cez verejný internet. Každý zdroj dostane stabilný hostname <slug>.internal, pričom samostatné projekty zostávajú navzájom izolované.

Sieť je voliteľná. Jej povolením pripojíte existujúce zdroje projektu bez toho, aby aplikácie museli okamžite prejsť na internú premávku. Po redeploymente služby dostanú interné connection variables.

Ako service-to-service networking znižuje vystavenie verejnému internetu?

Verejný endpoint databázy je dostupný z internetu aj vtedy, keď autentifikácia blokuje neoprávnené použitie. Privátna route odstráni toto vystavenie pre aplikačnú premávku a poskytne službám stabilný interný názov, ktorý nezávisí od verejnej adresy.

Rovnaký princíp platí aj pre volania medzi službami. API môže volať worker, internú administrátorskú službu alebo backend cez sieť projektu namiesto verejnej custom domény.

Trasa premávky	Verejná route	Privátna route
API do PostgreSQL	Verejný host a port	main-db.internal
Web do API	Verejná custom doména	api.internal
Worker do Redis	Verejný host a port	app-redis.internal
Preview do produkčnej databázy	Verejné DB credentials	Interný používateľ iba na čítanie
Volanie medzi projektmi	Vyžaduje sa verejný endpoint	Blokované izoláciou projektov

Privátne neznamená bez autentifikácie. Naďalej používajte používateľov databázy, autorizáciu služieb a secrets. Sieť určuje dostupnosť; credentials určujú oprávnenia.

Ako povoliť private networking projektu?

Povoľte sieť pre slug projektu:

dockup network enable production --json

Operácia pripojí služby a spravované databázy k projektovej sieti. Existujúce verejné listenery zostanú predvolene dostupné, takže prechod môžete realizovať postupne.

Každú aplikačnú službu, ktorá má dostať interné environment variables, redeploynite:

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

Dockup vloží údaje na pripojenie, napríklad DATABASE_URL_INTERNAL, internú URL a host variables špecifické pre databázu a hodnoty host/port služieb. Kľúče service environment si môžete zobraziť bez odhalenia secrets:

dockup env list -s production/api --json

URL nevytvárajte manuálne zo zobrazovaného názvu. Hostname <slug>.internal sa určuje podľa slugov zdrojov.

Pred zmenou konfigurácie aplikácie overte, či sa každá závislosť nachádza v tom istom projekte. Samostatné projekty majú samostatné siete a navzájom sa cez internú cestu nedokážu preložiť ani dosiahnuť.

Ako domény .internal menia konfiguráciu služieb?

Interné DNS poskytuje stabilný názov, zatiaľ čo kontajnery a nodes sa môžu meniť. Služba API so slugom api je zo služieb v rovnakom projekte dostupná na adrese api.internal; databáza so slugom main-db je dostupná na adrese main-db.internal.

Ak sú k dispozícii, uprednostnite vložené connection variables. Obsahujú správny protokol, credentials, názov databázy aj formát hosta. Ručne zostavený string môže vynechať TLS, kódovanie hesla alebo parametre databázy.

Migrujte jednu závislosť po druhej:

1. Povoľte sieť.
2. Redeploynite službu, ktorá závislosť využíva.
3. Potvrďte, že interná variable existuje.
4. Zmeňte aplikáciu tak, aby ju používala.
5. Deploynite s --wait.
6. Overte nové connections.
7. Sledujte runtime logs a čas odozvy.
8. Pokračujte ďalšou závislosťou.

Služba si môže ponechať verejnú custom doménu pre používateľskú premávku a zároveň používať privátne hostnames na volania backendu. Verejné a privátne cesty slúžia odlišným trust boundaries.

Príručka environment variables a secrets vysvetľuje, prečo zmeny pripojenia vyžadujú redeployment.

Ako nastaviť spravovanú databázu iba na privátny prístup?

Keď všetci potrební používatelia prejdú na internú cestu, odstráňte verejný listener:

dockup db private production/main-db --json

V prípade potreby obnovte verejný aj privátny prístup:

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

Táto operácia databázy znovu vytvorí kontajner, pričom zachová dáta. Naplánujte maintenance window zodpovedajúce workloadu, overte aktuálnosť poslednej zálohy a otestujte opätovné pripojenie aplikácie.

Pred nastavením databázy iba na privátny prístup skontrolujte:

• Každá production služba používajúca databázu je v rovnakom projekte.
• Operational tools nevyžadujú verejný endpoint.
• Preview prístup používa podporovanú privátnu cestu.
• Existuje záloha a rozumiete procesu obnovy.
• Connection pools bezpečne opakujú pokusy.
• Je zaznamenaný presný target project/db.

Databáza dostupná iba privátne sa nedá priamo dosiahnuť z notebooku operátora cez verejný internet. Používajte podporovaný prístup platformy a diagnostiku na úrovni aplikácie namiesto bezdôvodného opätovného otvorenia listenera.

Operácie s databázami opisuje príručka spravovaný PostgreSQL.

Ako PR previews bezpečne pristupujú k produkčným dátam?

Každé PR alebo branch preview v Dockup dostane vlastný izolovaný deployment a URL. V projekte s private networking sa preview pripojí k projektovej sieti a dokáže preložiť <slug>.internal.

Dockup automaticky vytvorí používateľa iba na čítanie pre spravovanú produkčnú databázu používanú preview prostredím. Preview môže načítavať dáta v tvare produkčnej schémy, ale prostredníctvom tohto používateľa do nich nemôže zapisovať.

Tento návrh znižuje riziko, že feature branch upraví záznamy zákazníkov, no prístup na čítanie má stále dôsledky:

• V preview sa môžu zobraziť osobné alebo citlivé údaje.
• Nový kód aplikácie môže logovať načítané dáta.
• Zraniteľná preview URL môže odhaliť výsledky dotazov.
• Náročné queries môžu ovplyvniť produkčnú záťaž.
• Predpoklady schémy sa môžu medzi branchom a produkciou líšiť.

Deployment preview povoľujte iba na základe schválenej politiky:

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

Izolované environment preview používajte pre feature flags a secrets, ktoré nie sú databázové. Automaticky vytvorené read-only credentials nenahrádzajte produkčnými write credentials.

Ako sledovať a riešiť problémy v private networking?

Začnite topológiou a konfiguráciou, nie predpokladom výpadku platformy.

Symptóm	Pravdepodobná oblasť	Kontrola
Názov sa nenašiel	Nesprávny slug/projekt alebo služba nebola redeploynutá	Zoznam služieb a env keys
Pripojenie odmietnuté	Zdroj je zastavený alebo je nesprávny port	Status a DB/service logs
Autentifikácia zlyhala	Nesprávne credentials	Rotácia secretu a používateľ
Verejná cesta funguje, privátna nie	Interná variable alebo prijatie sieťovej konfigurácie	Povolenie siete, redeployment
Preview môže čítať, ale nie zapisovať	Očakávaná read-only politika	Credentials nenahrádzajte
Volanie medzi projektmi zlyháva	Očakávaná izolácia	Použite verejné autentifikované API

Skontrolujte runtime logs aplikácie:

dockup logs production/api --json

Skontrolujte veľkosť databázy a chyby pripojenia aplikácie:

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

Do incident notes nevypisujte celé interné connection URLs. Môžu obsahovať credentials, hoci samotný hostname nie je secret.

Plán migrácie a rollbacku

V prvej fáze ponechajte verejný listener. Ak interný deployment zlyhá, obnovte predchádzajúcu konfiguráciu aplikácie a vykonajte redeployment. Databázu nastavte iba na privátny prístup až po stabilizácii internej cesty.

Ak chcete vypnúť celú projektovú sieť:

dockup network disable production --json

Ide o zámerný rollback, nie o prvý krok pri riešení problémov. Vypnutie siete ovplyvní každý pripojený zdroj v projekte.

Zmeny siete zaznamenávajte prostredníctvom audit logu:

dockup audit --writes --json

Production checklist pre private networking

Kompletný runbook pre private networking zahŕňa slug projektu, slugy služieb a databáz, interné hostnames, názvy vložených variables, politiku verejných listenerov, politiku prístupu preview prostredí, stav záloh, poradie redeploymentov a rollback path.

CPU, RAM a disk sa naďalej účtujú podľa využitia a merajú sa po minútach; privátne routovanie je architektonické rozhodnutie, nie pevná trieda inštancie. Na modelovanie nákladov použite Vysvetlenie cien PaaS.

Aktuálna referencia Dockup CLI obsahuje súčasné príkazy pre sieť a databázy. Všeobecnú izoláciu deploymentov opisujú osvedčené bezpečnostné postupy.

Autorizáciu služieb modelujte oddelene od dostupnosti

Interný hostname dokazuje iba to, že volajúci je v projektovej sieti. Nedokazuje, ktorá služba požiadavku odoslala ani či má oprávnenie vykonať danú operáciu. Pre citlivé interné API naďalej používajte autentifikáciu na úrovni aplikácie a pre prístup k dátam credentials databázy.

Používajte secrets špecifické pre jednotlivé služby namiesto jedného zdieľaného interného tokenu. Ak preview dostane prístup k databáze iba na čítanie, neposkytujte mu zároveň produkčný service token, pomocou ktorého by mohol cez API spúšťať zápisy.

Zmerajte vplyv prechodu

Porovnajte latenciu pripojenia, mieru chýb a čas odozvy p95 pred prechodom na interné endpointy a po ňom. Hlavným cieľom je izolácia a stabilná privátna cesta; prípadné zlepšenie latencie treba zmerať, nie sľubovať.

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

Uchovajte observation window a ID deploymentu. Zmena private networking tak dostane merateľné kritérium dokončenia namiesto ukončenia pri konštatovaní „DNS sa preložilo“.

Zdokumentujte výnimku pre verejnú cestu

Niektorá externá integrácia, operator tool alebo služba z iného projektu môže stále vyžadovať verejný endpoint. Uveďte každú výnimku, jej autentifikáciu, vlastníka a podmienku odstránenia. Verejný listener tak nezostane zapnutý neobmedzene dlho len preto, že si nikto nepamätá dôvod jeho existencie.

Kompletný rollout private networking môže byť čiastočný, ale každá verejná cesta musí byť zámerná.

Po premenovaní skontrolujte interné závislosti

Premenovanie alebo nahradenie zdroja môže zmeniť slug používaný pri adresovaní cez .internal. Pred zmenou názvov zistite všetkých používateľov, redeploynite ich s aktualizovanými vloženými variables a overte každé privátne pripojenie.

Takto zostane private networking stabilné aj počas vývoja projektu.

Začnite overiteľným deploymentom

Povoľte networking v neprodukčnom projekte, migrujte jednu závislosť na jej .internal endpointe a ešte pred odstránením verejného listenera overte rollback path.

Začnite bezplatne na app.dockup.ai. Free plan stojí 0 $ mesačne, zahŕňa úvodný kredit 10 $ a podporuje jeden workspace, tri databázy a tri deploymenty.

Často kladené otázky

Aký hostname používajú zdroje Dockup v privátnej sieti?

Každá služba a spravovaná databáza v rovnakom projekte je dostupná cez stabilný hostname v tvare <slug>.internal.

Odstráni povolenie private networking verejný prístup k databáze?

Nie. Sieť je predvolene aditívna. Po prechode používateľov na internú cestu použite samostatný príkaz na nastavenie databázy ako privátnej a odstráňte verejný listener.

Môžu sa rôzne projekty Dockup navzájom privátne dosiahnuť?

Nie. Každý projekt má izolovanú sieť, takže komunikácia medzi projektmi musí používať vhodné verejné a autentifikované rozhranie.

Môže PR preview zapisovať do produkčnej databázy?

V projekte s private networking Dockup automaticky vytvorí pre preview používateľa databázy iba na čítanie. Ten umožňuje čítanie, ale prostredníctvom daných credentials zabraňuje zápisu.

Prečo sa služby po povolení networkingu musia redeploynúť?

Redeployment poskytne novému kontajneru interné connection variables a umožní aplikácii spustiť sa s konfiguráciou privátneho endpointu.