Yksityinen verkko ja .internal-verkkotunnukset Dockupissa

Yksityisen verkon avulla yhden Dockup-projektin palvelut ja hallitut tietokannat voivat viestiä keskenään ilman, että saman projektin liikenne kulkee julkisen internetin kautta. Jokainen resurssi saa pysyvän <slug>.internal-isäntänimen, ja erilliset projektit pysyvät eristettyinä toisistaan.

Verkko otetaan käyttöön erikseen. Sen käyttöönotto yhdistää projektin nykyiset resurssit ilman, että sovellusten liikennettä tarvitsee heti siirtää käyttämään sitä, ja palvelut saavat sisäiset yhteysmuuttujat uudelleendeployn jälkeen.

Miten palveluiden välinen verkko vähentää julkista näkyvyyttä?

Julkinen tietokannan endpoint on internetin kautta saavutettavissa, vaikka autentikointi estäisi luvattoman käytön. Yksityinen reitti poistaa tämän altistumisen sovelluksen liikenteeltä ja antaa palveluille pysyvän sisäisen nimen, joka ei riipu julkisesta osoitteesta.

Sama periaate koskee palveluiden välisiä kutsuja. API voi kutsua workeria, sisäistä ylläpitopalvelua tai backendia projektiverkon kautta sen sijaan, että kutsu kulkisi julkisen custom domainin kautta.

Liikennereitti	Julkinen reitti	Yksityinen reitti
API → PostgreSQL	Julkinen host ja portti	main-db.internal
Web → API	Julkinen custom domain	api.internal
Worker → Redis	Julkinen host ja portti	app-redis.internal
Preview → tuotantotietokanta	Julkinen tietokantatunnus	Vain lukuoikeuden tarjoava sisäinen käyttäjä
Projektien välinen kutsu	Julkinen endpoint vaaditaan	Projektien eristys estää

Yksityinen ei tarkoita autentikoimatonta. Käytä edelleen tietokantakäyttäjiä, palveluiden valtuutusta ja salaisuuksia. Verkko määrittää saavutettavuuden, kun taas tunnistetiedot määrittävät käyttöoikeudet.

Miten projektin yksityinen verkko otetaan käyttöön?

Ota verkko käyttöön projektin slugilla:

dockup network enable production --json

Toiminto yhdistää palvelut ja hallitut tietokannat projektiverkkoon. Nykyiset julkiset listenerit ovat oletusarvoisesti edelleen käytettävissä, joten käyttöönotto voidaan tehdä vaiheittain.

Deployaa jokainen sovelluspalvelu uudelleen, jonka tulee saada sisäiset ympäristömuuttujat:

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

Dockup lisää ympäristöön yhteystietoja, kuten DATABASE_URL_INTERNAL-muuttujan, tietokantakohtaiset sisäiset URL- ja host-muuttujat sekä palveluiden host- ja porttiarvot. Tarkastele palvelun ympäristömuuttujien nimiä paljastamatta salaisuuksia:

dockup env list -s production/api --json

Älä muodosta URL-osoitetta itse näyttönimen perusteella. Resurssien slug-arvot määrittävät <slug>.internal-isäntänimen.

Ennen sovelluksen asetusten muuttamista varmista, että kaikki riippuvuudet sijaitsevat samassa projektissa. Erillisillä projekteilla on erilliset verkot, eivätkä ne voi selvittää toistensa nimiä tai saavuttaa toisiaan sisäistä reittiä pitkin.

Miten .internal-verkkotunnukset muuttavat palveluiden määrityksiä?

Sisäinen DNS tarjoaa pysyvän nimen, vaikka taustalla olevat containerit ja nodet vaihtuvat. Slugilla api varustettu API-palvelu on saavutettavissa saman projektin palveluista osoitteessa api.internal, ja slugilla main-db varustettu tietokanta osoitteessa main-db.internal.

Suosi injektoituja yhteysmuuttujia aina, kun niitä on saatavilla. Ne sisältävät oikean protokollan, tunnistetiedot, tietokannan nimen ja host-muodon. Itse rakennettu merkkijono saattaa jättää TLS:n, salasanan koodauksen tai tietokantaparametrit huomioimatta.

Siirrä yksi riippuvuus kerrallaan:

1. Ota verkko käyttöön.
2. Deployaa yhteyttä käyttävä palvelu uudelleen.
3. Varmista, että sisäinen muuttuja on olemassa.
4. Muuta sovellus käyttämään sitä.
5. Deployaa komennolla --wait.
6. Varmista uudet yhteydet.
7. Seuraa ajonaikaisia lokeja ja vasteaikaa.
8. Siirry seuraavaan riippuvuuteen.

Palvelu voi säilyttää julkisen custom domainin käyttäjäliikennettä varten ja käyttää yksityisiä hostnimiä backend-kutsuissa. Julkiset ja yksityiset reitit palvelevat eri luottamusrajoja.

Environment variables and secrets -opas selittää, miksi yhteysmuutokset edellyttävät uutta deployta.

Miten hallittu tietokanta tehdään vain yksityiseksi?

Kun kaikki tarvittavat käyttäjät käyttävät sisäistä reittiä, poista julkinen listener:

dockup db private production/main-db --json

Palauta julkinen ja yksityinen käyttö tarvittaessa:

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

Tietokantaoperaatio luo containerin uudelleen ja säilyttää samalla tiedot. Varaa työkuormaan sopiva huoltoikkuna, varmista tuore varmuuskopio ja testaa sovelluksen uudelleenyhdistäminen.

Ennen kuin teet tietokannasta vain yksityisen, tarkista seuraavat asiat:

• Kaikki tietokantaa käyttävät tuotantopalvelut ovat samassa projektissa.
• Ylläpitotyökalut eivät tarvitse julkista endpointia.
• Preview-käyttö hyödyntää tuettua yksityistä reittiä.
• Varmuuskopio on olemassa ja palautusprosessi tunnetaan.
• Yhteyspoolit yrittävät uudelleen turvallisesti.
• Tarkka project/db-kohde on kirjattu.

Vain yksityistä tietokantaa ei voi saavuttaa suoraan ylläpitäjän kannettavalta julkisen internetin kautta. Käytä tuettua alustan kautta tapahtuvaa käyttöä ja sovellustason diagnostiikkaa sen sijaan, että avaisit listenerin varomattomasti uudelleen.

Tietokantaoperaatioita käsitellään oppaassa managed PostgreSQL.

Miten PR-previewt käyttävät tuotantodataa turvallisesti?

Jokainen Dockupin PR- tai branch-preview saa oman eristetyn deploymentin ja URL-osoitteen. Yksityistä verkkoa käyttävässä projektissa preview liittyy projektiverkkoon ja voi selvittää osoitteen <slug>.internal.

Dockup luo automaattisesti vain lukuoikeuden omaavan käyttäjän previewn käyttämää tuotannon hallittua tietokantaa varten. Preview voi tehdä kyselyitä tuotannon rakennetta vastaavaan dataan, mutta käyttäjä ei voi kirjoittaa sen kautta.

Tämä rakenne pienentää riskiä, että feature branch muuttaa asiakastietoja, mutta lukuoikeuteen liittyy silti seurauksia:

• Previewssä voi näkyä henkilökohtaisia tai arkaluonteisia tietoja.
• Uusi sovelluskoodi saattaa kirjoittaa kyselytuloksia lokiin.
• Haavoittuva preview-URL voi paljastaa kyselyiden tuloksia.
• Raskaat kyselyt voivat vaikuttaa tuotannon kuormaan.
• Branchin ja tuotannon skeemaoletukset voivat poiketa toisistaan.

Ota preview-deployment käyttöön vain tarkistetun käytännön mukaisesti:

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

Käytä previewn eristettyä ympäristöä feature flagien ja muiden kuin tietokantaan liittyvien salaisuuksien hallintaan. Älä korvaa automaattisesti luotua vain lukuoikeuden tunnistetta tuotannon kirjoitusoikeuden tunnisteella.

Miten yksityistä verkkoa seurataan ja vianmääritystä tehdään?

Aloita topologiasta ja määrityksistä sen sijaan, että olettaisit alustavian.

Oire	Todennäköinen alue	Tarkistus
Nimeä ei löydy	Väärä slug tai projekti, tai palvelua ei ole redeployattu	Palvelulista ja ympäristömuuttujien nimet
Yhteys evätty	Resurssi on pysähtynyt tai portti on väärä	Tila sekä tietokannan/palvelun lokit
Autentikointi epäonnistui	Väärä tunnistetieto	Salaisuuden kierrätys ja käyttäjä
Julkinen toimii, yksityinen ei	Sisäinen muuttuja tai verkon käyttöönotto	Verkon käyttöönotto ja redeploy
Preview voi lukea mutta ei kirjoittaa	Odotettu vain lukuoikeuden käytäntö	Älä korvaa tunnistetta
Projektien välinen kutsu epäonnistuu	Odotettu eristys	Käytä julkista, autentikoitua APIa

Tarkastele sovelluksen ajonaikaisia lokeja:

dockup logs production/api --json

Tarkastele tietokannan kokoa ja sovelluksen yhteysvirheitä:

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

Älä tulosta kokonaisia sisäisiä yhteys-URL-osoitteita häiriömerkintöihin. Ne voivat sisältää tunnistetietoja, vaikka itse hostname ei ole salainen.

Migraatio- ja palautussuunnitelma

Pidä julkinen listener käytössä ensimmäisen vaiheen ajan. Jos sisäinen deployment epäonnistuu, palauta sovelluksen aiemmat asetukset ja deployaa uudelleen. Tee tietokannasta vain yksityinen vasta, kun sisäinen reitti on toiminut vakaasti.

Voit poistaa koko projektiverkon käytöstä seuraavasti:

dockup network disable production --json

Tämän tulee olla harkittu palautustoimi, ei ensimmäinen vianmääritysvaihe. Verkon poistaminen käytöstä vaikuttaa kaikkiin projektin yhdistettyihin resursseihin.

Kirjaa verkkomuutokset audit-lokiin:

dockup audit --writes --json

Yksityisen verkon tuotantotarkistuslista

Kattava yksityisen verkon runbook sisältää projektin slug-arvon, palveluiden ja tietokantojen slug-arvot, sisäiset hostnamet, injektoitujen muuttujien nimet, julkisten listenerien käytännön, preview-käytännön, varmuuskopioiden tilan, redeploy-järjestyksen ja palautuspolun.

CPU, RAM ja levy perustuvat edelleen käyttöön, ja kulutus mitataan minuutti kerrallaan. Yksityinen reititys on arkkitehtuurivalinta, ei kiinteä instanssiluokka. Käytä kustannusmallinnukseen opasta PaaS pricing explained.

Dockup CLI reference sisältää ajantasaiset verkko- ja tietokantakomennot. Yleistä deployment-eristystä käsitellään oppaassa security best practices.

Mallinna palveluiden valtuutus erikseen saavutettavuudesta

Sisäinen hostname osoittaa vain, että kutsuja on projektiverkossa. Se ei osoita, mikä palvelu pyynnön teki tai saako kyseinen palvelu suorittaa toiminnon. Säilytä sovellustason autentikointi arkaluonteisille sisäisille API-rajapinnoille ja tietokantatunnistetiedot tietojen käyttöä varten.

Käytä palvelukohtaisia salaisuuksia yhden jaetun sisäisen tokenin sijaan. Jos preview saa vain lukuoikeuden tietokantaan, älä anna sille lisäksi tuotannon palvelutokenia, jolla se voisi käynnistää kirjoituksia API:n kautta.

Mittaa siirtymän vaikutus

Vertaa yhteyden latenssia, virhemäärää ja p95-vasteaikaa ennen sisäisiin endpointteihin siirtymistä ja sen jälkeen. Tavoitteena on ensisijaisesti eristys ja vakaa yksityinen reitti. Mahdollinen latenssiparannus tulee mitata, ei luvata.

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

Säilytä seurantaikkuna ja deployment ID. Näin yksityisen verkon muutokselle saadaan mitattava valmistumiskriteeri sen sijaan, että prosessi päättyisi ilmoitukseen ”DNS ratkaistiin”.

Dokumentoi julkisen reitin poikkeukset

Jokin ulkoinen integraatio, ylläpitotyökalu tai projektien välinen palvelu saattaa edelleen tarvita julkista endpointia. Luettele jokainen poikkeus sekä sen autentikointi, omistaja ja poistamisen ehto. Näin julkinen listener ei jää pysyvästi käyttöön vain siksi, ettei kukaan muista sen olemassaolon syytä.

Kattava yksityisen verkon käyttöönotto voi olla osittainen, mutta jokaisen julkisen reitin tulee olla tarkoituksellinen.

Tarkista sisäiset riippuvuudet nimien muuttamisen jälkeen

Resurssin nimeäminen uudelleen tai korvaaminen voi muuttaa .internal-osoitteissa käytettävää slug-arvoa. Luetteloi käyttäjät ennen nimien muuttamista, deployaa ne uudelleen päivitetyillä injektoiduilla muuttujilla ja varmista kaikki yksityiset yhteydet.

Näin yksityinen verkko pysyy vakaana projektin kehittyessä.

Aloita varmennettavasta deploymentista

Ota verkko käyttöön muussa kuin tuotantoprojektissa, siirrä yksi riippuvuus käyttämään sen .internal-endpointia ja varmista palautuspolku ennen julkisten listenerien poistamista.

Aloita maksutta osoitteessa app.dockup.ai. Free-paketti maksaa 0 $ kuukaudessa, sisältää 10 $ aloitussaldoa ja tukee yhtä workspacea, kolmea tietokantaa ja kolmea deploymentia.

Usein kysyttyä

Mitä hostnamea Dockupin resurssit käyttävät yksityisessä verkossa?

Jokainen saman projektin palvelu ja hallittu tietokanta on saavutettavissa pysyvällä hostnamella muodossa <slug>.internal.

Poistaako yksityisen verkon käyttöönotto julkisen tietokantakäytön?

Ei. Verkko on oletusarvoisesti täydentävä. Poista julkinen listener erillisellä tietokannan private-komennolla sen jälkeen, kun käyttäjät käyttävät sisäistä reittiä.

Voivatko eri Dockup-projektit saavuttaa toisensa yksityisesti?

Eivät. Jokaisella projektilla on eristetty verkko, joten projektien välisessä viestinnässä on käytettävä asianmukaista julkista ja autentikoitua rajapintaa.

Voiko PR-preview kirjoittaa tuotantotietokantaan?

Yksityistä verkkoa käyttävässä projektissa Dockup luo previewlle automaattisesti vain lukuoikeuden tietokantakäyttäjän, joka sallii lukemisen mutta estää kirjoittamisen kyseisillä tunnistetiedoilla.

Miksi palvelut on redeployattava verkon käyttöönoton jälkeen?

Redeploy antaa uudelle containerille sisäiset yhteysmuuttujat ja mahdollistaa sovelluksen käynnistymisen yksityisen endpointin määrityksillä.