Rețele private și domenii .internal pe Dockup

Rețelele private permit serviciilor și bazelor de date gestionate dintr-un proiect Dockup să comunice fără ca traficul dintre resursele aceluiași proiect să treacă prin internetul public. Fiecare resursă primește un hostname stabil de forma <slug>.internal, iar proiectele separate rămân izolate unele de altele.

Rețeaua este opțională. Activarea ei conectează resursele existente ale proiectului fără să impună schimbarea imediată a traficului aplicației, iar serviciile primesc variabile interne de conectare după redeployment.

Cum reduce rețeaua service-to-service expunerea publică?

Un endpoint public al bazei de date poate fi accesat de pe internet chiar și atunci când autentificarea blochează utilizarea neautorizată. O rută privată elimină această expunere pentru traficul aplicației și oferă serviciilor un nume intern stabil, care nu depinde de o adresă publică.

Același principiu se aplică și apelurilor service-to-service. Un API poate apela un worker, un serviciu intern de administrare sau un backend prin rețeaua proiectului, în loc să folosească un domeniu public personalizat.

Rută de trafic	Rută publică	Rută privată
API către PostgreSQL	Host și port publice	main-db.internal
Web către API	Domeniu public personalizat	api.internal
Worker către Redis	Host și port publice	app-redis.internal
Preview către baza de date de producție	Credential public al bazei de date	Utilizator intern doar pentru citire
Apel între proiecte	Este necesar un endpoint public	Blocat prin izolarea proiectelor

Privat nu înseamnă fără autentificare. Continuă să folosești utilizatori ai bazei de date, autorizarea serviciilor și secrete. Rețeaua determină accesibilitatea; credentialele determină permisiunile.

Cum activezi rețeaua privată a proiectului?

Activează rețeaua pentru slug-ul proiectului:

dockup network enable production --json

Operația conectează serviciile și bazele de date gestionate la rețeaua proiectului. Listener-ele publice existente rămân disponibile în mod implicit, astfel încât adoptarea poate fi graduală.

Fă redeploy pentru fiecare serviciu de aplicație care ar trebui să primească variabile de mediu interne:

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

Dockup injectează date de conectare precum DATABASE_URL_INTERNAL, variabile interne pentru URL-ul și hostul specifice bazei de date, precum și valori pentru hostul și portul serviciilor. Inspectează cheile de mediu ale serviciului fără să expui secrete:

dockup env list -s production/api --json

Nu construi manual un URL pornind de la un nume afișat. Slug-urile resurselor determină hostname-ul <slug>.internal.

Înainte de a modifica configurația aplicației, verifică dacă fiecare dependență se află în același proiect. Proiectele separate au rețele separate și nu se pot rezolva sau accesa reciproc prin ruta internă.

Cum schimbă domeniile .internal configurația serviciilor?

DNS-ul intern oferă un nume stabil, chiar dacă în spate se schimbă containerele și nodurile. Un serviciu API cu slug-ul api este accesibil ca api.internal din serviciile aceluiași proiect; o bază de date cu slug-ul main-db este accesibilă ca main-db.internal.

Preferă variabilele de conectare injectate, atunci când sunt disponibile. Acestea includ protocolul, credentialele, numele bazei de date și formatul corect al hostului. Un string construit manual poate omite TLS, codificarea parolei sau parametrii bazei de date.

Migrează câte o dependență pe rând:

1. Activează rețeaua.
2. Fă redeploy pentru serviciul care consumă dependența.
3. Confirmă că variabila internă există.
4. Modifică aplicația pentru a o folosi.
5. Fă deploy cu --wait.
6. Verifică noile conexiuni.
7. Monitorizează logurile runtime și timpul de răspuns.
8. Continuă cu următoarea dependență.

Un serviciu își poate păstra domeniul public personalizat pentru traficul utilizatorilor și poate folosi hostname-uri private pentru apelurile backend. Rutele publice și private deservesc limite de încredere diferite.

Ghidul variabile de mediu și secrete explică de ce modificările conexiunilor necesită redeployment.

Cum faci ca o bază de date gestionată să fie accesibilă doar privat?

După ce fiecare consumator necesar folosește ruta internă, elimină listener-ul public:

dockup db private production/main-db --json

Restabilește accesul public și privat atunci când este necesar:

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

Această operație asupra bazei de date recreează containerul, păstrând datele. Planifică o fereastră de mentenanță adecvată volumului de lucru, confirmă existența unui backup recent și testează reconectarea aplicației.

Înainte de a o face accesibilă doar privat, verifică:

• Fiecare serviciu de producție care folosește baza de date se află în același proiect.
• Instrumentele operaționale nu necesită endpointul public.
• Accesul preview-urilor folosește ruta privată acceptată.
• Există un backup, iar procesul de recuperare este înțeles.
• Connection pool-urile reîncearcă în siguranță.
• Ținta exactă project/db este înregistrată.

O bază de date accesibilă doar privat nu poate fi accesată direct de pe laptopul unui operator prin internetul public. Folosește metodele de acces acceptate de platformă și diagnosticarea la nivelul aplicației, în loc să redeschizi listener-ul fără o analiză atentă.

Pentru operațiuni asupra bazelor de date, consultă ghidul despre PostgreSQL gestionat.

Cum accesează preview-urile PR datele de producție în siguranță?

Fiecare preview Dockup pentru un PR sau branch primește propriul deployment și propriul URL izolat. Într-un proiect cu rețele private, preview-ul se alătură rețelei proiectului și poate rezolva <slug>.internal.

Dockup creează automat un utilizator doar pentru citire pentru baza de date gestionată de producție folosită de preview. Preview-ul poate interoga date cu aceeași structură ca cele de producție, dar nu poate scrie folosind acel utilizator.

Acest design reduce riscul ca un feature branch să modifice înregistrările clienților, însă accesul pentru citire are în continuare consecințe:

• Date personale sau sensibile pot apărea în preview.
• Codul nou al aplicației poate înregistra datele interogate în loguri.
• Un URL de preview vulnerabil poate expune rezultatele citirilor.
• Interogările costisitoare pot afecta încărcarea producției.
• Presupunerile despre schemă pot diferi între branch și producție.

Activează deployment-ul pentru preview-uri doar în baza unei politici analizate și aprobate:

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

Folosește mediul izolat al preview-ului pentru feature flags și secrete care nu țin de baza de date. Nu înlocui credentialul automat doar pentru citire cu credentialul de producție care permite scrierea.

Cum trebuie monitorizată și depanată rețeaua privată?

Începe cu topologia și configurația, nu presupune imediat că există o problemă a platformei.

Simptom	Zonă probabilă	Verificare
Numele nu a fost găsit	Slug sau proiect greșit ori serviciul nu a fost redeployat	Lista serviciilor și cheile de mediu
Conexiunea este refuzată	Resursa este oprită sau portul este greșit	Statusul și logurile bazei de date/serviciului
Autentificarea a eșuat	Credential greșit	Rotirea secretelor și utilizatorul
Ruta publică funcționează, cea privată nu	Variabilă internă sau adoptarea rețelei	Activarea rețelei și redeployment
Preview-ul poate citi, dar nu poate scrie	Politică așteptată, doar pentru citire	Nu înlocui credentialul
Apelul între proiecte eșuează	Izolare așteptată	Folosește un API public autentificat

Inspectează logurile runtime ale aplicației:

dockup logs production/api --json

Inspectează dimensiunea bazei de date și erorile de conectare ale aplicației:

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

Nu afișa URL-uri complete de conectare interne în notele incidentului. Acestea pot include credentiale, chiar dacă hostname-ul în sine nu este secret.

Plan de migrare și rollback

Păstrează listener-ul public în prima etapă. Dacă deployment-ul intern eșuează, restaurează configurația anterioară a aplicației și fă redeploy. Fă baza de date accesibilă doar privat abia după ce ruta internă s-a dovedit stabilă.

Pentru a dezactiva întreaga rețea a proiectului:

dockup network disable production --json

Aceasta trebuie să fie o operație de rollback deliberată, nu primul pas de depanare. Dezactivarea rețelei afectează fiecare resursă conectată din proiect.

Înregistrează modificările rețelei prin audit log:

dockup audit --writes --json

Listă de verificare pentru rețele private în producție

Un runbook complet pentru rețele private include slug-ul proiectului, slug-urile serviciilor și bazelor de date, hostname-urile interne, numele variabilelor injectate, politica listener-ului public, politica de acces a preview-urilor, statusul backupului, ordinea redeployment-urilor și calea de rollback.

CPU, RAM și discul continuă să fie tarifate în funcție de utilizare și măsurate pe minut; rutarea privată este o alegere de arhitectură, nu o clasă fixă de instanță. Folosește explicația prețurilor PaaS pentru modelarea costurilor.

Referința CLI Dockup conține comenzile actuale pentru rețea și baze de date. Pentru izolarea generală a deployment-urilor, consultă cele mai bune practici de securitate.

Modelează separat autorizarea serviciilor și accesibilitatea

Un hostname intern dovedește doar că apelantul se află în rețeaua proiectului. Nu dovedește ce serviciu a făcut cererea sau dacă acel serviciu are voie să efectueze acțiunea. Păstrează autentificarea aplicației pentru API-urile interne sensibile și credentialele bazei de date pentru accesul la date.

Folosește secrete specifice fiecărui serviciu, nu un singur token intern partajat. Dacă un preview primește acces doar pentru citire la baza de date, nu îi oferi și un token de producție al serviciului care poate declanșa scrieri printr-un API.

Măsoară efectul tranziției

Compară latența conexiunilor, rata erorilor și timpul de răspuns p95 înainte și după trecerea la endpointuri interne. Scopul principal este izolarea și o rută privată stabilă; orice îmbunătățire a latenței trebuie măsurată, nu promisă.

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

Păstrează fereastra de observație și ID-ul deployment-ului. Astfel, modificarea de rețele private are un criteriu de finalizare măsurabil, în loc să se încheie cu „DNS-ul s-a rezolvat”.

Documentează excepția de la ruta publică

Unele integrări externe, instrumente pentru operatori sau servicii din alte proiecte pot necesita în continuare un endpoint public. Enumeră fiecare excepție, metoda de autentificare, responsabilul și condiția de eliminare. Astfel, previi menținerea listener-ului public pe termen nedefinit doar pentru că nimeni nu își mai amintește de ce există.

Un rollout complet pentru rețele private poate fi parțial, dar fiecare rută publică trebuie să fie intenționată.

Revizuiește dependențele interne după redenumiri

Redenumirea sau înlocuirea unei resurse poate schimba slug-ul folosit pentru adresarea .internal. Inventariază consumatorii înainte de a schimba numele, fă redeploy cu variabilele injectate actualizate și verifică fiecare conexiune privată.

Astfel, rețelele private rămân stabile pe măsură ce proiectul evoluează.

Începe cu un deployment verificabil

Activează rețeaua într-un proiect non-production, migrează o dependență către endpointul său .internal și demonstrează calea de rollback înainte de a elimina orice listener public.

Începe gratuit pe app.dockup.ai. Planul Free costă $0 pe lună, include un credit inițial de $10 și permite un workspace, trei baze de date și trei deployment-uri.

Întrebări frecvente

Ce hostname folosesc resursele Dockup în rețeaua privată?

Fiecare serviciu și bază de date gestionată din același proiect este accesibilă printr-un hostname stabil, în forma <slug>.internal.

Activarea rețelei private elimină accesul public la baza de date?

Nu. În mod implicit, rețeaua se adaugă peste configurația existentă. Folosește comanda separată pentru a face baza de date privată și a elimina listener-ul public după ce consumatorii folosesc ruta internă.

Pot proiecte Dockup diferite să se acceseze privat?

Nu. Fiecare proiect are o rețea izolată, astfel încât comunicarea între proiecte trebuie să folosească o interfață publică adecvată și autentificată.

Poate un preview PR să scrie în baza de date de producție?

Într-un proiect cu rețea privată, Dockup creează automat un utilizator al bazei de date doar pentru citire pentru preview, permițând citirile, dar împiedicând scrierile folosind acel credential.

De ce trebuie serviciile să facă redeploy după activarea rețelei?

Redeployment-ul oferă noului container variabilele interne de conectare și permite aplicației să pornească folosind configurația endpointului privat.