Privát hálózat és .internal domainek a Dockupon

A privát hálózat lehetővé teszi, hogy egy Dockup-projekten belül a szolgáltatások és a kezelt adatbázisok úgy kommunikáljanak egymással, hogy az azonos projekten belüli forgalom ne a nyilvános interneten haladjon át. Minden erőforrás stabil <slug>.internal hostnevet kap, miközben a különálló projektek továbbra is el vannak különítve egymástól.

A hálózat használata opcionális. Engedélyezése összekapcsolja a projekt meglévő erőforrásait, de nem kényszeríti ki az alkalmazásforgalom azonnali átállítását, a szolgáltatások pedig újratelepítés után kapják meg a belső kapcsolati változókat.

Hogyan csökkenti a szolgáltatások közötti hálózat a nyilvános kitettséget?

A nyilvános adatbázis-végpont az internetről is elérhető, még akkor is, ha a hitelesítés megakadályozza az illetéktelen használatot. A privát útvonal megszünteti ezt a kitettséget az alkalmazásforgalom esetében, és stabil belső nevet biztosít a szolgáltatásoknak, amely nem függ nyilvános címtől.

Ugyanez az alapelv érvényes a szolgáltatások közötti hívásokra is. Egy API a projekt hálózatán keresztül is hívhat egy workert, belső adminisztrációs szolgáltatást vagy backendet, így nincs szükség nyilvános egyéni domain használatára.

Forgalmi útvonal	Nyilvános útvonal	Privát útvonal
API → PostgreSQL	Nyilvános host és port	main-db.internal
Web → API	Nyilvános egyéni domain	api.internal
Worker → Redis	Nyilvános host és port	app-redis.internal
Előnézet → éles adatbázis	Nyilvános adatbázis-hitelesítő adat	Csak olvasásra használható belső felhasználó
Projektek közötti hívás	Nyilvános végpont szükséges	A projektelkülönítés blokkolja

A privát nem jelent hitelesítés nélkülit. Továbbra is használj adatbázis-felhasználókat, szolgáltatásszintű jogosultságkezelést és secretet. A hálózat az elérhetőséget, a hitelesítő adatok pedig a jogosultságot határozzák meg.

Hogyan engedélyezhető a projekt privát hálózata?

Engedélyezd a hálózatot a projekt slugja számára:

dockup network enable production --json

A művelet csatlakoztatja a szolgáltatásokat és a kezelt adatbázisokat a projekt hálózatához. A meglévő nyilvános listenerek alapértelmezés szerint továbbra is elérhetők, így az átállás fokozatosan végezhető el.

Telepítsd újra azokat az alkalmazásszolgáltatásokat, amelyeknek meg kell kapniuk a belső környezeti változókat:

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

A Dockup olyan kapcsolati adatokat injektál, mint a DATABASE_URL_INTERNAL, az adatbázis-specifikus belső URL- és hostváltozók, valamint a szolgáltatások host- és portértékei. A secret értékek felfedése nélkül vizsgáld meg a szolgáltatás környezeti kulcsait:

dockup env list -s production/api --json

Ne állíts össze manuálisan URL-t egy megjelenített név alapján. A <slug>.internal hostname-t az erőforrások slugjai határozzák meg.

Az alkalmazás konfigurációjának módosítása előtt ellenőrizd, hogy minden függőség ugyanabban a projektben található-e. A különálló projektek külön hálózattal rendelkeznek, és a belső útvonalon keresztül nem tudják feloldani vagy elérni egymást.

Hogyan módosítják a .internal domainek a szolgáltatások konfigurációját?

A belső DNS stabil nevet biztosít, miközben a háttérben a konténerek és a node-ok változhatnak. Az api sluggal rendelkező API-szolgáltatás api.internal néven érhető el az azonos projekt szolgáltatásaiból; a main-db sluggal rendelkező adatbázis pedig main-db.internal néven érhető el.

Ha lehetséges, részesítsd előnyben az injektált kapcsolati változókat. Ezek tartalmazzák a megfelelő protokollt, hitelesítő adatokat, adatbázisnevet és hostformátumot. A kézzel összeállított karakterláncból hiányozhat a TLS, a jelszó megfelelő kódolása vagy az adatbázis-paraméterek egy része.

Egyesével migráld a függőségeket:

1. Engedélyezd a hálózatot.
2. Telepítsd újra a fogyasztó szolgáltatást.
3. Ellenőrizd, hogy létezik-e a belső változó.
4. Módosítsd az alkalmazást úgy, hogy ezt használja.
5. Telepítsd a --wait kapcsolóval.
6. Ellenőrizd az új kapcsolatok működését.
7. Figyeld a futásidejű naplókat és a válaszidőt.
8. Folytasd a következő függőséggel.

A szolgáltatás megtarthatja a nyilvános egyéni domainjét a felhasználói forgalomhoz, miközben a backendhívásokhoz privát hostneveket használ. A nyilvános és a privát útvonal eltérő bizalmi határokat szolgál.

A környezeti változókról és secretekről szóló útmutató bemutatja, miért van szükség újratelepítésre a kapcsolatok módosítása után.

Hogyan tehető egy kezelt adatbázis csak privát módon elérhetővé?

Miután minden szükséges fogyasztó a belső útvonalat használja, távolítsd el a nyilvános listenert:

dockup db private production/main-db --json

Szükség esetén állítsd vissza a nyilvános és privát hozzáférést:

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

Ez az adatbázis-művelet az adatok megőrzése mellett újra létrehozza a konténert. Tervezz a munkaterhelésnek megfelelő karbantartási időablakot, ellenőrizd, hogy készült-e friss backup, és teszteld az alkalmazás újracsatlakozását.

Mielőtt csak privát hozzáférésűvé tennéd, ellenőrizd a következőket:

• Minden, az adatbázist használó éles szolgáltatás ugyanabban a projektben található.
• Az üzemeltetési eszközöknek nincs szükségük nyilvános végpontra.
• Az előnézeti hozzáférés a támogatott privát útvonalat használja.
• Létezik backup, és ismert a helyreállítási folyamat.
• A connection poolok biztonságosan újrapróbálják a kapcsolatot.
• A pontos project/db cél rögzítve van.

A csak privát hozzáférésű adatbázis közvetlenül nem érhető el egy üzemeltető laptopjáról a nyilvános interneten keresztül. A listener alkalmi újbóli megnyitása helyett használd a támogatott platformhozzáférést és az alkalmazásszintű diagnosztikát.

Az adatbázis-műveletekről lásd a kezelt PostgreSQL-ről szóló útmutatót.

Hogyan férnek hozzá biztonságosan az egyesítési kérések előnézetei az éles adatokhoz?

Minden Dockup PR- vagy branch-előnézet saját, elkülönített telepítést és URL-t kap. Privát hálózatot használó projektben az előnézet csatlakozik a projekt hálózatához, és fel tudja oldani a <slug>.internal neveket.

A Dockup automatikusan létrehoz egy csak olvasásra használható felhasználót az előnézet által használt éles, kezelt adatbázishoz. Az előnézet az éles adatok szerkezetét tükröző adatokat lekérdezheti, de ezzel a felhasználóval nem írhat az adatbázisba.

Ez a kialakítás csökkenti annak kockázatát, hogy egy feature branch módosítsa az ügyfélrekordokat, az olvasási hozzáférésnek azonban továbbra is vannak következményei:

• Személyes vagy érzékeny adatok jelenhetnek meg az előnézetben.
• Az új alkalmazáskód naplózhatja a lekérdezett adatokat.
• Egy sérülékeny előnézeti URL felfedheti a lekérdezések eredményeit.
• A költséges lekérdezések terhelhetik az éles rendszert.
• A séma feltételezései eltérhetnek a branch és az éles környezet között.

Az előnézeti telepítést csak felülvizsgált szabályzat alapján engedélyezd:

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

A feature flagekhez és az adatbázison kívüli secretekhez használd az előnézet elkülönített környezetét. Az automatikusan létrehozott csak olvasási hitelesítő adatot ne cseréld le az éles írási hitelesítő adatra.

Hogyan figyelhető meg és hárítható el a privát hálózat hibája?

A platform leállásának feltételezése helyett először a topológiát és a konfigurációt vizsgáld meg.

Tünet	Valószínű terület	Ellenőrzés
A név nem található	Hibás slug/projekt vagy a szolgáltatást nem telepítették újra	Szolgáltatáslista és környezeti kulcsok
A kapcsolat vissza van utasítva	Leállított erőforrás vagy hibás port	Állapot, valamint az adatbázis- és szolgáltatásnaplók
Sikertelen hitelesítés	Hibás hitelesítő adat	Secretrotáció és felhasználó
A nyilvános működik, a privát nem	Belső változó vagy a hálózat használatba vétele	Hálózat engedélyezése és újratelepítés
Az előnézet olvasni tud, írni nem	Elvárt, csak olvasási szabályzat	Ne cseréld le a hitelesítő adatot
A projektek közötti hívás sikertelen	Elvárt elkülönítés	Használj nyilvános, hitelesített API-t

Vizsgáld meg az alkalmazás futásidejű naplóit:

dockup logs production/api --json

Vizsgáld meg az adatbázis méretét és az alkalmazás kapcsolati hibáit:

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

Ne írd ki a teljes belső kapcsolati URL-t az incidens feljegyzéseibe. Hitelesítő adatokat is tartalmazhatnak, még akkor is, ha maga a hostname nem titkos.

Migrációs és visszaállítási terv

Az első fázisban tartsd meg a nyilvános listenert. Ha a belső telepítés sikertelen, állítsd vissza az alkalmazás korábbi konfigurációját, majd telepítsd újra. Az adatbázist csak akkor tedd kizárólag priváttá, ha a belső útvonal már stabilan működik.

A teljes projekthálózat letiltásához:

dockup network disable production --json

Ez legyen tudatos visszaállítási lépés, ne az első hibaelhárítási próbálkozás. A hálózat letiltása a projekt minden csatlakoztatott erőforrását érinti.

A hálózati módosításokat rögzítsd az auditnaplóban:

dockup audit --writes --json

Privát hálózati éles környezeti ellenőrzőlista

A teljes privát hálózati runbook tartalmazza a projekt slugját, a szolgáltatások és adatbázisok slugjait, a belső hostneveket, az injektált változók neveit, a nyilvános listenerre vonatkozó szabályzatot, az előnézeti hozzáférés szabályait, a backup állapotát, az újratelepítés sorrendjét és a visszaállítási útvonalat.

A CPU-, RAM- és lemezhasználat továbbra is használatalapú, percenkénti mérés szerint kerül elszámolásra; a privát routing architekturális döntés, nem pedig rögzített instance-osztály. A költségmodellezéshez használd a PaaS-árazás magyarázatát.

A Dockup CLI-referencia tartalmazza az aktuális hálózati és adatbázis-parancsokat. Az általános telepítési elkülönítésről lásd a biztonsági bevált gyakorlatokat.

A szolgáltatás-jogosultságokat kezeld külön az elérhetőségtől

A belső hostname csak azt bizonyítja, hogy a hívó a projekt hálózatán van. Nem bizonyítja, hogy melyik szolgáltatás küldte a kérést, illetve hogy az adott szolgáltatás végrehajthatja-e a műveletet. Az érzékeny belső API-khoz továbbra is használj alkalmazásszintű hitelesítést, az adatokhoz való hozzáféréshez pedig adatbázis-hitelesítő adatokat.

Szolgáltatásonként külön secretet használj egyetlen közös belső token helyett. Ha egy előnézet csak olvasási hozzáférést kap az adatbázishoz, ne adj neki olyan éles szolgáltatási tokent is, amellyel egy API-n keresztül írási műveleteket indíthat.

Mérd az átállás hatását

Hasonlítsd össze a kapcsolati késleltetést, a hibaarányt és a p95 válaszidőt a belső végpontokra való átállás előtt és után. A cél elsősorban az elkülönítés és a stabil privát útvonal; az esetleges késleltetéscsökkenést mérni kell, nem pedig előre megígérni.

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

Őrizd meg a megfigyelési időablakot és a telepítés azonosítóját. Így a privát hálózati módosításnak mérhető befejezési feltétele lesz, és nem ér véget annyival, hogy „a DNS feloldódott”.

Dokumentáld a nyilvános útvonal kivételeit

Előfordulhat, hogy egy külső integrációnak, üzemeltetési eszköznek vagy projektek közötti szolgáltatásnak továbbra is szüksége van nyilvános végpontra. Sorold fel az összes kivételt, a hozzájuk tartozó hitelesítést, felelőst és megszüntetési feltételt. Így nem marad bekapcsolva határozatlan ideig a nyilvános listener csak azért, mert senki sem emlékszik, miért van rá szükség.

Egy teljes privát hálózati bevezetés lehet részleges, de minden nyilvános útvonalnak tudatos döntésen kell alapulnia.

Nevek átnevezése után vizsgáld felül a belső függőségeket

Egy erőforrás átnevezése vagy lecserélése módosíthatja a .internal címzéshez használt slugot. A nevek módosítása előtt készíts leltárt a fogyasztókról, telepítsd őket újra a frissített injektált változókkal, és ellenőrizd minden privát kapcsolat működését.

Így a privát hálózat a projekt fejlődése közben is stabil marad.

Kezdd ellenőrizhető telepítéssel

Engedélyezd a hálózatot egy nem éles projektben, migrálj egy függőséget a .internal végpontjára, és bizonyítsd a visszaállítási útvonal működését, mielőtt eltávolítanád valamelyik nyilvános listenert.

Indíts ingyenesen az app.dockup.ai oldalon. A Free csomag havi 0 dollárba kerül, 10 dollár kezdő kreditet tartalmaz, és egy workspace-et, három adatbázist, valamint három telepítést támogat.

GYIK

Milyen hostnevet használnak a Dockup erőforrásai a privát hálózaton?

Minden azonos projektben található szolgáltatás és kezelt adatbázis stabil, <slug>.internal formátumú hostnéven érhető el.

A privát hálózat engedélyezése megszünteti a nyilvános adatbázis-hozzáférést?

Nem. A hálózat alapértelmezés szerint kiegészítő lehetőség. A nyilvános listener eltávolításához, miután a fogyasztók átálltak a belső útvonalra, használd a különálló adatbázis-private parancsot.

Elérhetik egymást különböző Dockup-projektek privát módon?

Nem. Minden projekt elkülönített hálózattal rendelkezik, ezért a projektek közötti kommunikációhoz megfelelő nyilvános és hitelesített interfészt kell használni.

Írhat egy PR-előnézet az éles adatbázisba?

Privát hálózatot használó projektben a Dockup automatikusan létrehoz egy csak olvasásra használható adatbázis-felhasználót az előnézet számára. Ez lehetővé teszi az olvasást, de a hitelesítő adattal nem végezhető írás.

Miért kell újratelepíteni a szolgáltatásokat a hálózat engedélyezése után?

Az újratelepítés biztosítja, hogy az új konténer megkapja a belső kapcsolati változókat, és az alkalmazás már a privát végpont konfigurációjával induljon.