Egyéni domain és automatikus TLS a Dockupon

Az egyéni domain és automatikus TLS beállítása három külön rétegből áll: a Dockup szolgáltatásának megfelelően kell működnie, a DNS-nek a hostname-et a platformra kell irányítania, a hostname-nek pedig át kell mennie az ellenőrzésen, mielőtt tanúsítvány állítható ki hozzá. Ha ezeket a rétegeket külön kezeled, az átállás kiszámíthatóbb lesz, és a DNS-hibákat nem fogod alkalmazáshibának nézni.

A Dockup minden szolgáltatáshoz biztosít egy *.dockup.tech címet is. A DNS-propagáció alatt tartsd elérhetően ezt a címet, hogy az alkalmazást az egyéni hostnametől függetlenül tesztelhesd.

Minek kell készen állnia egy Dockup egyéni domain hozzáadása előtt?

Kezdj egy már futó szolgáltatással, amely átmegy a readiness gate ellenőrzésén:

dockup status production/web --json
dockup health production/web --json

Nyisd meg vagy teszteld a meglévő *.dockup.tech URL-t. Ha az alkalmazás ott hibásan működik, a domain hozzáadása nem fogja helyrehozni. Először vizsgáld meg a runtime logokat.

Gyűjtsd össze az alábbi információkat:

Elem	Példa	Miért fontos?
Pontos cél	production/web	Megakadályozza, hogy a domaint rossz szolgáltatáshoz csatold
Hostname	app.example.com	Ezt a DNS-nevet fogják felkeresni a felhasználók
DNS-hozzáférés	Regisztrátor vagy DNS-szolgáltató	Szükséges a rekord létrehozásához
Jelenlegi TTL	300 másodperc	A propagáció és a visszaállítás sebességét szabályozza
Az alkalmazás canonical URL-je	https://app.example.com	Hatással lehet az átirányításokra és a cookie-kra
Health route	/health	Az átállás előtt megerősíti, hogy a szolgáltatás működik

Élő szolgáltató lecserélésekor előzetesen csökkentsd a meglévő DNS TTL-értékét. Ne töröld a régi rekordot addig, amíg nem ismert a Dockup-cél, az alkalmazás konfigurációja és a rollback terve.

Tekintsd át azokat az alkalmazásfunkciókat is, amelyek a hostnametől függnek. Az authentication callbackek, a CORS allowlistek, a cookie-domain beállítások, az OAuth redirect URL-ek, a webhook-célok és a generált abszolút hivatkozások esetében szükség lehet az új HTTPS-hostname-re.

Hogyan adható hozzá és ellenőrizhető a domain?

Először listázd a jelenlegi domaineket:

dockup domain list production/web --json

Add hozzá a hostnamet:

dockup domain add app.example.com production/web --json

A válasz tartalmazza a konfigurálandó DNS-célt. A DNS-szolgáltatónál hozd létre a megadott CNAME-rekordot. Ne találj ki IP-címet, és ne másolj értéket másik szolgáltatásból; ehhez a domainhez a válaszban visszaadott célt használd.

Miután a DNS propagálódott, ellenőrizd a visszaadott domain ID-val:

dockup domain verify <domainId> production/web --json

Az ellenőrzés azt bizonyítja, hogy a nyilvános DNS-rekord az előírt módon oldódik fel. A sikert általában négy dolog valamelyike akadályozza:

1. Hibás a rekord neve.
2. Hibás a CNAME-cél.
3. Továbbra is létezik egy régi, ütköző A-, AAAA- vagy CNAME-rekord.
4. A resolver cache-ei még nem jutottak el az új értékhez.

Az authoritative DNS-t ellenőrizd ahelyett, hogy ismételten eltávolítanád és újra létrehoznád a domaint. A propagáció elosztott cache-folyamat, nem pedig Dockup build-folyamat.

Hogyan állítja ki és kezeli a rendszer a HTTPS-tanúsítványt?

Sikeres ellenőrzés után kérd a tanúsítványt:

dockup domain ssl <domainId> production/web --json

A Dockup kezeli az ellenőrzött hostname tanúsítványának kiállítását, és HTTPS-en szolgálja ki az egyéni domaint. A platform kezeli a TLS teljes életciklusát, ezért az alkalmazáskonténernek nem kell tanúsítványfájlokat tárolnia vagy tanúsítvány-megújítási folyamatot futtatnia.

A platformon kívülről ellenőrizd az eredményt:

curl -I https://app.example.com

Ellenőrizd, hogy:

• A tanúsítvány megfelel a hostname-nek.
• A válasz HTTPS-en keresztül érkezik.
• Az átirányítások nem alkotnak hurkot.
• Az alkalmazás a várt státuszt adja vissza.
• Az authentication- és callback-folyamatok az új origint használják.
• A statikus assetek mixed-content hibák nélkül töltődnek be.

A tanúsítvány kiállítása akkor is meghiúsulhat, ha maga az alkalmazás egészségesen működik. A DNS- és a szolgáltatásdiagnosztikát kezeld külön. A DNS-tulajdonjog ellenőrzéséhez használd a domain verify parancsot, az alkalmazás működését pedig a service logokban vizsgáld.

A zero-downtime telepítésekről szóló cikk bemutatja a független release readiness gate-et.

Hogyan állítható át a forgalom leállás nélkül?

A biztonságos átállás során a régi útvonal addig elérhető marad, amíg az új hostname-et nem ellenőrizted.

1. Telepítsd és ellenőrizd a Dockup-szolgáltatást a platform URL-jén.
2. Add hozzá az egyéni domaint a Dockupban.
3. Hozd létre a DNS-rekordot.
4. Ellenőrizd a DNS-t.
5. Állítsd ki a TLS-tanúsítványt.
6. Teszteld közvetlenül a HTTPS-kapcsolatot.
7. Frissítsd a callbackeket, a canonical URL-eket és a monitoringot.
8. Ha a DNS-beállítás ezt lehetővé teszi, irányítsd az éles forgalom kis részét az új útvonalra.
9. Figyeld a logokat és az uptime-ot.
10. A régi szolgáltatót csak akkor szüntesd meg, amikor az új útvonal már stabil.

A Dockup uptime-ellenőrzései percenként futnak, és többek között p95 válaszidő-statisztikát jelentenek:

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

Kritikus domainekhez tarts fenn független külső monitoringot is. A platform probe a nyilvános elérhetőséget ellenőrzi, míg egy külső monitor egy másik rendszerből validálja a felhasználói útvonalat.

Ha az egyéni domain egy jelenlegi production hostot vált le, őrizz meg rollback-rekordot: a korábbi DNS-értéket, a korábbi TTL-t, a régi szolgáltató állapotát és azt a feltételt, amely a visszaállítást kiváltja.

Hogyan működnek a további portdomainek?

Egy szolgáltatás egy második HTTP-portot is közzétehet admin UI, metrics endpoint vagy másik webes folyamat számára. A Dockup további platformdomaint tud létrehozni egyéni DNS nélkül:

dockup port list production/web --json
dockup port add 8080 production/web --name admin --json

A visszaadott domain a kiválasztott konténerportra irányítja a forgalmat. Ez elkülönül a fő egyéni domaintől.

Ne tegyél közzé egy portot pusztán azért, mert egy folyamat figyel rajta. Vizsgáld meg, hogy az endpoint rendelkezik-e authenticationnel, tartalmaz-e production adatokat, és egyáltalán nyilvánosnak kell-e lennie. Egy csak belső használatra szánt adminfelület ne váljon kényelmi okokból internet felől elérhetővé.

Egy elavult portdomaint csak a támogatott domaininterfészen keresztül távolíts el, és csak azt követően, hogy meggyőződtél róla: már egyetlen monitor, callback vagy operátori munkafolyamat sem használja. A portdomain módosításai mutációk, és megjelennek az audit logban.

Hogyan háríthatók el a DNS-, TLS- és alkalmazáshibák?

Rétegenként végezd a diagnosztikát:

Tünet	Első ellenőrzés	Dockup-parancs
A domain nem oldódik fel	DNS-rekord és propagáció	domain verify
Nem állítható ki a tanúsítvány	Domain-ellenőrzési állapot	domain list, domain ssl
A HTTPS működik, de az alkalmazás hibázik	Runtime logok	logs --json
Redirect loop	Alkalmazás proxy-/hostbeállításai	env list, runtime logok
A platform URL működik, az egyéni host nem	DNS/TLS-réteg	Domain-parancsok
Egyik URL sem működik	Deployment és runtime	status, build/runtime logok
A másodlagos port nem működik	Portdomain-leképezés és folyamat	port list, runtime logok

Vizsgáld meg a szolgáltatás kimenetét anélkül, hogy összekevernéd a DNS-re vonatkozó következtetésekkel:

dockup logs production/web --json
dockup status production/web --json

Ha egy friss környezeti módosítás hozzáadta a canonical URL-t, ne feledd, hogy ehhez újra kell deployolni:

dockup env set APP_URL=https://app.example.com \
  -s production/web \
  --json

dockup deploy production/web --wait --json

Az environment változókról és secretekről szóló útmutató részletesen bemutatja ezt az életciklust.

Domain eltávolítása és rollback

A Dockup-asszociáció eltávolítása megszünteti az útvonalat, ezért először helyezd át vagy távolítsd el a nyilvános DNS-rekordot, és erősítsd meg, hogy mi legyen a kívánt csere. Ezután a támogatott domaininterfészen keresztül, a pontos domain ID használatával távolítsd el az asszociációt.

Ideiglenes tanúsítvány- vagy propagációs incidens alatt ne távolítsd el a domaint, kivéve, ha a helyreállítási terv ezt megköveteli. A konfiguráció megtartása lehetővé teszi, hogy az ellenőrzés sikeres legyen a cache-ek frissülésekor.

A mutációkat az alábbi paranccsal tekintheted át:

dockup audit --search domains --json

Az audit trailnek meg kell mutatnia, hogy ki adta hozzá, ellenőrizte, biztosította vagy távolította el a hostnamet.

Production átadási ellenőrzőlista

A teljes egyéni domain és automatikus TLS átadás tartalmazza a szolgáltatás célját, a hostnamet, a domain ID-t, a DNS-rekord típusát és célját, az ellenőrzés eredményét, a tanúsítvány eredményét, az alkalmazás callback-módosításait, a monitoring URL-jét és a rollbackhez szükséges DNS-értéket.

Ne tárolj tanúsítványhoz tartozó privát kulcsot a repositoryban vagy a konténerben. A Dockup által kezelt TLS-határ éppen azért létezik, hogy az alkalmazáscsapat tanúsítványanyag terjesztése nélkül üzemeltethesse a hostnamet.

Az aktuális flagekhez használd a Dockup CLI-referenciát. A domainbeállítások előtti kezdeti telepítéshez kövesd a Git repositorytól a productionig útmutatót.

Apex- és subdomain-választási lehetőségek megtervezése

Az olyan subdomain, mint az app.example.com, általában a legegyszerűbb alkalmazás-hostname, mert a DNS-szolgáltatók CNAME-mel tudják reprezentálni. Az apex, például az example.com, szolgáltatóspecifikus flatteninget vagy alias-viselkedést igényelhet. Kövesd a Dockup által visszaadott DNS-célt, valamint az authoritative DNS-szolgáltató képességeit.

Válassz egy canonical hostot, és az alternatív hostokat az alkalmazás- vagy routingrétegben irányítsd át. Ha a www és az apex egyaránt kiszolgálásra kerül canonical policy nélkül, az feloszthatja a cookie-kat, az analitikai adatokat, a cache-bejegyzéseket és a keresőindexelést.

A tanúsítvány-megújítással kapcsolatos feltételezések tesztelése

A managed TLS megszünteti annak szükségességét, hogy a konténerben renewal client fusson, a hostname-nek azonban továbbra is helyesen kell feloldódnia. Egy későbbi DNS-migráció, proxyváltás vagy törölt rekord megszakíthatja a validációt.

A rutinellenőrzésekbe foglald bele a domain állapotát is:

dockup domain list production/web --json
dockup uptime production/web --hours 24 --json

Az egyéni domain és automatikus TLS runbookban szerepeljen a DNS felelőse, a megújításért felelős kapcsolattartó és az utolsó külső tanúsítvány-ellenőrzés dátuma. Így nem csak egy tanúsítványincidens bekövetkezésekor derül ki, hogy ki a felelős.

A nem production hostname-ek védelme

A staging- és preview-hostname-ek készülő funkciókat és productionhöz hasonló adatokat tehetnek közzé. Használj szükség esetén alkalmazásszintű authenticationt, határozz meg indexing policy-t az alkalmazásrétegben, és korlátozd a nem production URL-ek megosztását.

A keresőmotoroknak szóló direktívák nem jelentenek hozzáférés-vezérlést. A védett környezethez továbbra is authenticationre és megfelelő adatkezelésre van szükség.

Újraellenőrzés a propagáció után

Az eredeti DNS TTL teljes letelte után ismételd meg a külső HTTPS- és callback-teszteket.

Ellenőrizhető telepítéssel kezdd

Először egy nem kritikus hostnamet csatolj, a propagáció alatt tartsd meg a platform URL-jét, és rögzítsd a rollbackhez szükséges pontos DNS-értéket.

Kezdd el ingyen az app.dockup.ai oldalon. A Free csomag havi 0 dollárba kerül, 10 dollár kezdő kreditet tartalmaz, és egy workspace-t, három adatbázist, valamint három deploymentet támogat.

Gyakori kérdések

Milyen DNS-rekordra van szüksége egy Dockup egyéni domainnek?

Futtasd a dockup domain add parancsot, és hozd létre a válaszban megjelenő DNS-rekordot. A visszaadott célt használd, ne egy másik szolgáltatás értékét másold át.

Mikor állíthat ki a Dockup TLS-t egyéni domainhez?

Miután a hostname DNS-rekordja átment a Dockup domain verification ellenőrzésén, kérd a tanúsítvány kiállítását a dokumentált domain ssl paranccsal.

A konténeremnek tárolnia kell a TLS-tanúsítványokat?

Nem. A Dockup kezeli az ellenőrzött egyéni domain TLS-ét, ezért az alkalmazáskonténernek nincs szüksége tanúsítványfájlokra vagy megújítási folyamatra.

A Dockup közzé tud tenni egy további konténerportot?

Igen. A portparancsok külön, automatikusan generált domaint hozhatnak létre egy további nyilvános porthoz, egyéni DNS konfigurálása nélkül.

Mit ellenőrizzek, ha a platform URL-je működik, de az egyéni domain nem?

A DNS-rekordokra, a propagációra, a domain-ellenőrzésre és a tanúsítvány állapotára összpontosíts. A működő platform URL azt jelzi, hogy az alkalmazásréteg valószínűleg rendben van.