Anpassad domän och automatisk TLS på Dockup
Anpassad domän och automatisk TLS på Dockup: lägg till DNS, verifiera ägarskap, utfärda HTTPS, exponera extra portar, validera övergången och felsök säkert.
En konfiguration med anpassad domän och automatisk TLS består av tre separata lager: Dockup-tjänsten måste vara frisk, DNS måste peka värdnamnet till plattformen och värdnamnet måste verifieras innan ett certifikat kan utfärdas. När du hanterar lagren separat blir övergången förutsägbar och DNS-fel misstas inte för applikationsfel.
Dockup ger också varje tjänst en *.dockup.tech-adress. Behåll den adressen tillgänglig under DNS-propageringen så att du kan testa applikationen oberoende av den anpassade värdnamnet.
Vad bör vara klart innan du lägger till en Dockup-anpassad domän?
Börja med en tjänst som redan körs och klarar sin readiness gate:
dockup status production/web --json
dockup health production/web --json
Öppna eller testa den befintliga *.dockup.tech-URL:en. Om applikationen inte fungerar där kommer en domän inte att lösa problemet. Granska runtime-loggarna först.
Samla in följande information:
| Objekt | Exempel | Varför det är viktigt |
|---|---|---|
| Exakt mål | production/web | Förhindrar att domänen kopplas till fel tjänst |
| Värdnamn | app.example.com | DNS-namnet som användarna kommer att besöka |
| DNS-åtkomst | Registrar eller DNS-leverantör | Krävs för att skapa posten |
| Aktuell TTL | 300 sekunder | Styr propageringens och rollbackens hastighet |
| Applikationens canonical URL | https://app.example.com | Kan påverka omdirigeringar och cookies |
| Health route | /health | Bekräftar tjänsten före övergången |
Sänk den befintliga DNS-TTL:en i förväg när du ersätter en aktiv leverantör. Ta inte bort den gamla posten förrän Dockup-målet, applikationskonfigurationen och rollback-planen är kända.
Granska applikationsbeteenden som beror på värdnamnet. Autentiseringscallbacks, CORS-allowlistor, cookie-domäner, OAuth-redirect-URL:er, webhook-destinationer och genererade absoluta länkar kan behöva det nya HTTPS-värdnamnet.
Hur lägger du till och verifierar domänen?
Lista aktuella domäner först:
dockup domain list production/web --json
Lägg till värdnamnet:
dockup domain add app.example.com production/web --json
Svaret innehåller det DNS-mål som måste konfigureras. Skapa den angivna CNAME-posten hos DNS-leverantören. Hitta inte på en IP-adress och kopiera inte ett värde från en annan tjänst – använd målet som returneras för den här domänen.
När DNS har propagerat verifierar du domänen med det returnerade domän-ID:t:
dockup domain verify <domainId> production/web --json
Verifieringen bevisar att den publika DNS-posten slår upp korrekt. Ett fel beror vanligtvis på en av fyra saker:
- Postnamnet är fel.
- CNAME-målet är fel.
- En gammal motstridig A-, AAAA- eller CNAME-post finns kvar.
- Resolver-cachar har ännu inte nått det nya värdet.
Kontrollera auktoritativ DNS i stället för att upprepade gånger ta bort och återskapa domänen. Propagering är en distribuerad cacheprocess, inte en Dockup-buildprocess.
Hur utfärdas och underhålls HTTPS-certifikatet?
När verifieringen lyckas begär du certifikatet:
dockup domain ssl <domainId> production/web --json
Dockup hanterar certifikatsutfärdandet för det verifierade värdnamnet och levererar den anpassade domänen över HTTPS. Plattformen hanterar TLS-livscykeln, så applikationscontainern behöver inte lagra certifikatfiler eller köra en process för certifikatförnyelse.
Validera resultatet utanför plattformen:
curl -I https://app.example.com
Bekräfta att:
- Certifikatet matchar värdnamnet.
- Svaret levereras över HTTPS.
- Omdirigeringar inte skapar loopar.
- Applikationen returnerar förväntad status.
- Autentiserings- och callback-flöden använder den nya origin.
- Statiska resurser laddas utan mixed-content-fel.
Certifikatsutfärdandet kan misslyckas även när själva applikationen är frisk. Håll DNS- och tjänstediagnostik åtskilda. Använd domain verify för DNS-ägarskap och tjänsteloggar för applikationsbeteende.
Artikeln om zero-downtime deployments förklarar den separata readiness gate för releaser.
Hur genomför du trafikövergången utan avbrott?
En säker övergång behåller den gamla sökvägen tillgänglig tills det nya värdnamnet har verifierats.
- Distribuera och verifiera Dockup-tjänsten via dess plattforms-URL.
- Lägg till den anpassade domänen i Dockup.
- Skapa DNS-posten.
- Verifiera DNS.
- Utfärda TLS.
- Testa HTTPS direkt.
- Uppdatera callbacks, canonical-URL:er och övervakning.
- Skicka en liten del av den operativa trafiken om DNS-konfigurationen tillåter det.
- Följ loggar och uptime.
- Avveckla den gamla leverantören först när den nya sökvägen är stabil.
Dockups uptime-kontroller körs varje minut och rapporterar statistik över svarstider, inklusive p95:
dockup uptime production/web --hours 24 --json
Behåll oberoende extern övervakning för kritiska domäner. En plattformskontroll bekräftar publik åtkomst, medan en extern monitor verifierar användarens sökväg från ett annat system.
Om den anpassade domänen ersätter ett aktuellt produktionsvärdnamn ska du spara ett rollback-underlag: tidigare DNS-värde, tidigare TTL, den gamla leverantörens status och villkoret som skulle utlösa en återställning.
Hur fungerar domäner för extra portar?
En tjänst kan exponera en andra HTTP-port för ett admin-UI, en metrics-endpoint eller en annan webbprocess. Dockup kan skapa ytterligare en plattformsdomän utan anpassad DNS:
dockup port list production/web --json
dockup port add 8080 production/web --name admin --json
Den returnerade domänen dirigerar trafik till den valda containerporten. Detta är separat från den huvudsakliga anpassade domänen.
Exponera inte en port enbart för att en process lyssnar på den. Fundera på om endpointen har autentisering, om den innehåller produktionsdata och om den över huvud taget bör vara publik. Ett internt admin-gränssnitt bör inte bli åtkomligt från internet bara för bekvämlighets skull.
Ta bort en föråldrad portdomän via det stödda domängränssnittet först efter att du har verifierat att ingen monitor, callback eller operatörsprocess fortfarande använder den. Ändringar av portdomäner är mutationer och visas i audit-loggen.
Hur felsöker du DNS-, TLS- och applikationsfel?
Använd en lager-för-lager-diagnos:
| Symptom | Första kontroll | Dockup-kommando |
|---|---|---|
| Domänen slår inte upp | DNS-post och propagering | domain verify |
| Certifikatet utfärdas inte | Domänens verifieringsstatus | domain list, domain ssl |
| HTTPS fungerar men applikationen ger fel | Runtime-loggar | logs --json |
| Omdirigeringsloop | Applikationens proxy-/host-inställningar | env list, runtime-loggar |
| Plattformens URL fungerar, men den anpassade hosten fungerar inte | DNS-/TLS-lagret | Domänkommandon |
| Båda URL:erna fungerar inte | Deployment och runtime | status, build-/runtime-loggar |
| Sekundär port fungerar inte | Portdomänens mapping och process | port list, runtime-loggar |
Inspektera tjänstens output utan att blanda ihop den med DNS-slutsatser:
dockup logs production/web --json
dockup status production/web --json
Om en nylig miljöändring lade till den kanoniska URL:en måste du komma ihåg att den kräver en ny deployment:
dockup env set APP_URL=https://app.example.com \
-s production/web \
--json
dockup deploy production/web --wait --json
Guiden om miljövariabler och secrets beskriver den livscykeln.
Ta bort domänen och genomföra rollback
Att ta bort Dockup-kopplingen förstör routingen, så flytta eller ta först bort den publika DNS-posten och bekräfta den avsedda ersättningen. Ta sedan bort kopplingen via det stödda domängränssnittet med det exakta domän-ID:t.
Ta inte bort domänen under en tillfällig certifikats- eller propagationsincident om inte återställningsplanen kräver det. Om konfigurationen ligger kvar kan verifieringen lyckas när cacharna uppdateras.
Granska mutationer med:
dockup audit --search domains --json
Audit-spåret bör visa vem som lade till, verifierade, säkrade eller tog bort värdnamnet.
Checklista för produktionsöverlämning
En komplett överlämning av anpassad domän och automatisk TLS innehåller tjänstemål, värdnamn, domän-ID, DNS-postens typ och mål, verifieringsresultat, certifikatsresultat, ändringar av applikationscallbacks, övervaknings-URL och DNS-värdet för rollback.
Lagra aldrig en privat certifikatnyckel i repositoryt eller containern. Dockups managed TLS-gräns finns just för att applikationsteamet ska kunna hantera värdnamnet utan att distribuera certifikatmaterial.
Använd Dockup CLI-referensen för alla aktuella flaggor. Följ Git repository to production för den första deploymenten innan domänarbetet.
Planera val av apex och subdomän
En subdomän som app.example.com är vanligtvis det enklaste applikationsvärdnamnet eftersom DNS-leverantörer kan representera den med en CNAME. En apex-domän som example.com kan kräva leverantörsspecifik flattening eller alias-funktionalitet. Följ DNS-målet som Dockup returnerar och funktionerna hos den auktoritativa DNS-leverantören.
Välj ett canonical-värdnamn och omdirigera alternativ på applikations- eller routinglagret. Om både www och apex-domänen används utan en canonical-policy kan cookies, analytics, cacheposter och sökindexering splittras.
Testa antaganden om certifikatförnyelse
Managed TLS gör att du inte behöver köra en renewal client i containern, men värdnamnet måste fortsätta slå upp korrekt. En framtida DNS-migrering, proxyändring eller borttagen post kan bryta valideringen.
Ta med domänstatus i rutinmässiga granskningar:
dockup domain list production/web --json
dockup uptime production/web --hours 24 --json
Runbooken för anpassad domän och automatisk TLS bör ange DNS-ägare, kontakt för förnyelse och datumet för den senaste externa certifikatkontrollen. Då upptäcker ni inte ägarskapet först när en certifikatsincident inträffar.
Skydda icke-produktionsvärdnamn
Staging- och preview-värdnamn kan exponera ofärdiga funktioner och produktionsliknande data. Använd applikationsautentisering där det krävs, definiera en indexeringspolicy på applikationslagret och begränsa spridningen av URL:er för icke-produktion.
Direktiv för sökmotorer är inte åtkomstkontroll. En skyddad miljö behöver fortfarande autentisering och korrekt datahantering.
Kontrollera igen efter propageringen
Upprepa externa HTTPS- och callback-tester efter att den ursprungliga DNS-TTL:en har löpt ut helt.
Börja med en verifierbar deployment
Koppla först ett icke-kritiskt värdnamn, behåll plattforms-URL:en under propageringen och dokumentera det exakta DNS-värdet som behövs för rollback.
Starta gratis på app.dockup.ai. Free-planen kostar 0 USD per månad, inkluderar 10 USD i startkredit och stöder en workspace, tre databaser och tre deploymenter.
Vanliga frågor
Vilken DNS-post behöver en Dockup-anpassad domän?
Kör dockup domain add och skapa DNS-posten som visas i svaret. Använd det returnerade målet i stället för att kopiera ett värde från en annan tjänst.
När kan Dockup utfärda TLS för en anpassad domän?
När värdnamnets DNS-post har klarat Dockups domänverifiering begär du att ett certifikat ska utfärdas med det dokumenterade kommandot domain ssl.
Behöver min container lagra TLS-certifikat?
Nej. Dockup hanterar TLS för den verifierade anpassade domänen, så applikationscontainern behöver varken certifikatfiler eller en förnyelseprocess.
Kan Dockup exponera ytterligare en containerport?
Ja. Portkommandona kan skapa en separat automatiskt genererad domän för ytterligare en publik port utan att anpassad DNS krävs.
Vad ska jag kontrollera när plattformens URL fungerar men den anpassade domänen inte gör det?
Fokusera på DNS-poster, propagering, domänverifiering och certifikatstatus. Den fungerande plattforms-URL:en visar att applikationslagret sannolikt fungerar.