Eget domene og automatisk TLS på Dockup

Et oppsett med eget domene og automatisk TLS består av tre separate lag: Dockup-tjenesten må være frisk, DNS må peke vertsnavnet til plattformen, og vertsnavnet må bestå verifiseringen før et sertifikat kan utstedes. Når du behandler lagene separat, blir byttet forutsigbart, og DNS-feil blir ikke forvekslet med applikasjonsfeil.

Dockup gir også hver tjeneste en *.dockup.tech-adresse. Behold denne adressen tilgjengelig mens DNS-propageringen pågår, slik at du kan teste applikasjonen uavhengig av det egendefinerte vertsnavnet.

Hva bør være klart før du legger til et eget Dockup-domene?

Start med en tjeneste som allerede kjører og består readiness-sjekken:

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

Åpne eller test den eksisterende *.dockup.tech-URL-en. Hvis applikasjonen feiler der, vil det ikke løse problemet å legge til et domene. Se først gjennom runtime-loggene.

Samle inn følgende informasjon:

Element	Eksempel	Hvorfor det er viktig
Nøyaktig mål	production/web	Hindrer at domenet kobles til feil tjeneste
Vertsnavn	app.example.com	DNS-navnet brukerne skal besøke
DNS-tilgang	Registrar eller DNS-leverandør	Kreves for å opprette posten
Gjeldende TTL	300 sekunder	Styrer propagerings- og rollback-hastigheten
Applikasjonens kanoniske URL	https://app.example.com	Kan påvirke redirects og cookies
Health-endepunkt	/health	Bekrefter tjenesten før byttet

Reduser den eksisterende DNS-TTL-en på forhånd når du erstatter en aktiv leverandør. Ikke slett den gamle posten før Dockup-målet, applikasjonskonfigurasjonen og rollback-planen er avklart.

Gå gjennom applikasjonsatferd som avhenger av vertsnavnet. Authentication callbacks, CORS-allowlister, cookiedomener, OAuth redirect-URL-er, webhook-destinasjoner og genererte absolutte lenker kan trenge det nye HTTPS-vertsnavnet.

Hvordan legger du til og verifiserer domenet?

List opp gjeldende domener først:

dockup domain list production/web --json

Legg til vertsnavnet:

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

Responsen inneholder DNS-målet som må konfigureres. Opprett den angitte CNAME-posten hos DNS-leverandøren. Ikke finn på en IP-adresse eller kopier en verdi fra en annen tjeneste. Bruk målet som returneres for dette domenet.

Når DNS er propagert, verifiserer du domenet med den returnerte domene-ID-en:

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

Verifisering bekrefter at den offentlige DNS-posten løses som forventet. En feil skyldes vanligvis én av fire ting:

1. Postnavnet er feil.
2. CNAME-målet er feil.
3. En gammel, motstridende A-, AAAA- eller CNAME-post fortsatt finnes.
4. Resolver-cacher har ikke fått den nye verdien ennå.

Sjekk autoritativ DNS i stedet for å fjerne og opprette domenet på nytt gjentatte ganger. Propagering er en distribuert cache-prosess, ikke en Dockup-byggprosess.

Hvordan utstedes og vedlikeholdes HTTPS-sertifikatet?

Når verifiseringen er fullført, ber du om sertifikatet:

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

Dockup håndterer sertifikatutstedelse for det verifiserte vertsnavnet og leverer det egendefinerte domenet over HTTPS. Plattformen håndterer TLS-livssyklusen, så applikasjonscontaineren trenger ikke å lagre sertifikatfiler eller kjøre en prosess for sertifikatfornyelse.

Valider resultatet utenfra plattformen:

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

Bekreft at:

• Sertifikatet samsvarer med vertsnavnet.
• Responsen leveres over HTTPS.
• Redirects ikke går i loop.
• Applikasjonen returnerer forventet status.
• Authentication- og callback-flyter bruker den nye origin-en.
• Statiske ressurser lastes uten mixed-content-feil.

Sertifikatutstedelse kan mislykkes selv om selve applikasjonen er frisk. Hold DNS- og tjenestediagnostikk adskilt. Bruk domain verify for DNS-eierskap og tjenestelogger for applikasjonsatferd.

Artikkelen om zero-downtime deployments forklarer den separate readiness-sjekken for release.

Hvordan bytter du trafikken uten driftsavbrudd?

Et trygt bytte lar den gamle banen være tilgjengelig til det nye vertsnavnet er bekreftet.

1. Deploy og verifiser Dockup-tjenesten på plattform-URL-en.
2. Legg til det egendefinerte domenet i Dockup.
3. Opprett DNS-posten.
4. Verifiser DNS.
5. Utsted TLS.
6. Test HTTPS direkte.
7. Oppdater callbacks, kanoniske URL-er og overvåking.
8. Send en liten del av trafikken dersom DNS-oppsettet tillater det.
9. Følg med på logger og oppetid.
10. Avvikle den gamle leverandøren først når den nye banen er stabil.

Dockup-oppetidssjekker kjører hvert minutt og rapporterer statistikk for responstid, inkludert p95:

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

Behold uavhengig ekstern overvåking for kritiske domener. En plattformprobe bekrefter offentlig tilgjengelighet, mens en ekstern monitor verifiserer brukerbanen fra et annet system.

Hvis det egendefinerte domenet erstatter en nåværende produksjonsvert, må du ta vare på en rollback-oppføring: tidligere DNS-verdi, tidligere TTL, status hos den gamle leverandøren og betingelsen som skal utløse en reversering.

Hvordan fungerer portdomener for ekstra porter?

En tjeneste kan eksponere en ekstra HTTP-port for et admin-grensesnitt, et metrics-endepunkt eller en annen web-prosess. Dockup kan opprette et ekstra plattformdomene uten egendefinert DNS:

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

Det returnerte domenet ruter til den valgte container-porten. Dette er separat fra hoveddomenet.

Ikke eksponer en port bare fordi en prosess lytter på den. Vurder om endepunktet har authentication, om det inneholder produksjonsdata, og om det i det hele tatt bør være offentlig. Et internt admin-grensesnitt bør ikke bli tilgjengelig fra internett bare fordi det er praktisk.

Fjern et foreldet portdomene gjennom det støttede domenegrensesnittet først etter at du har bekreftet at ingen monitor, callback eller operatørarbeidsflyt fortsatt bruker det. Endringer i portdomener er mutasjoner og vises i audit-loggen.

Hvordan feilsøker du DNS-, TLS- og applikasjonsfeil?

Bruk en lagvis diagnose:

Symptom	Første kontroll	Dockup-kommando
Domenet løses ikke	DNS-post og propagering	domain verify
Sertifikatet blir ikke utstedt	Status for domeneverifisering	domain list, domain ssl
HTTPS fungerer, men applikasjonen feiler	Runtime-logger	logs --json
Redirect-loop	Proxy-/vertsinnstillinger i applikasjonen	env list, runtime-logger
Plattform-URL fungerer, men egendefinert vert feiler	DNS-/TLS-laget	Domenekommandoer
Begge URL-ene feiler	Deployment og runtime	status, build-/runtime-logger
Sekundærporten feiler	Portdomene-mapping og prosess	port list, runtime-logger

Inspiser tjenesteoutput uten å blande den med DNS-konklusjoner:

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

Hvis en nylig miljøendring la til den kanoniske URL-en, må du huske at den krever en ny deploy:

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

dockup deploy production/web --wait --json

Veiledningen for environment variables and secrets beskriver denne livssyklusen.

Fjerning av domene og rollback

Fjerning av Dockup-koblingen er destruktivt for ruten. Flytt eller fjern derfor først den offentlige DNS-posten, og bekreft den tiltenkte erstatningen. Fjern deretter koblingen gjennom det støttede domenegrensesnittet ved hjelp av den nøyaktige domene-ID-en.

Ikke fjern domenet under en midlertidig sertifikat- eller propageringshendelse med mindre gjenopprettingsplanen krever det. Hvis konfigurasjonen blir stående, kan verifiseringen lykkes når cachene oppdateres.

Gå gjennom mutasjoner med:

dockup audit --search domains --json

Audit-sporet bør vise hvem som la til, verifiserte, sikret eller fjernet vertsnavnet.

Sjekkliste for produksjonsoverlevering

En komplett overlevering av eget domene og automatisk TLS omfatter tjenestemål, vertsnavn, domene-ID, DNS-posttype og -mål, verifiseringsresultat, sertifikatresultat, endringer i application callbacks, monitor-URL og DNS-verdien for rollback.

Ikke lagre private sertifikatnøkler i repositoryet eller containeren. Dockups administrerte TLS-grense finnes nettopp for at applikasjonsteamet skal kunne drifte vertsnavnet uten å distribuere sertifikatmateriale.

Bruk Dockup CLI-referansen for alle gjeldende flagg. Følg Git repository to production for den første deploymenten før du arbeider med domenet.

Planlegg valg av apex og subdomene

Et subdomene som app.example.com er vanligvis det enkleste applikasjonsvertsnavnet fordi DNS-leverandører kan representere det med en CNAME. Et apex-domene som example.com kan kreve leverandørspesifikk flattening eller alias-funksjonalitet. Følg DNS-målet som Dockup returnerer, samt funksjonene hos den autoritative DNS-leverandøren.

Velg én kanonisk vert og redirect alternativer på applikasjons- eller routing-laget. Hvis du leverer både www og apex uten en kanonisk policy, kan cookies, analytics, cache-oppføringer og søkeindeksering bli splittet.

Test forutsetninger for sertifikatfornyelse

Administrert TLS fjerner behovet for å kjøre en fornyelsesklient inne i containeren, men vertsnavnet må fortsatt løses korrekt. En fremtidig DNS-migrering, proxy-endring eller slettet post kan ødelegge valideringen.

Ta med domenestatus i rutinemessige gjennomganger:

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

Runbooken for eget domene og automatisk TLS bør angi DNS-eier, kontakt for fornyelse og datoen for siste eksterne sertifikatkontroll. Da unngår du å oppdage eierskapet først når det oppstår en sertifikathendelse.

Beskytt vertsnavn utenfor produksjon

Staging- og preview-vertsnavn kan eksponere uferdige funksjoner og produksjonslignende data. Bruk applikasjonsautentisering ved behov, definer en policy for indeksering på applikasjonslaget, og begrens distribusjonen av URL-er utenfor produksjon.

Direktiver for søkemotorer er ikke tilgangskontroll. Et beskyttet miljø trenger fortsatt authentication og riktig håndtering av data.

Kontroller på nytt etter propagering

Gjenta eksterne HTTPS- og callback-tester etter at den opprinnelige DNS-TTL-en har utløpt fullstendig.

Start med en deployment som kan verifiseres

Koble først til et ikke-kritisk vertsnavn, behold plattform-URL-en under propageringen, og noter den nøyaktige DNS-verdien som trengs for rollback.

Start gratis på app.dockup.ai. Free-planen koster 0 USD per måned, inkluderer 10 USD i startkreditt og støtter ett workspace, tre databaser og tre deployments.

Vanlige spørsmål

Hvilken DNS-post trenger et eget Dockup-domene?

Kjør dockup domain add og opprett DNS-posten som vises i responsen. Bruk målet som returneres, i stedet for å kopiere en verdi fra en annen tjeneste.

Når kan Dockup utstede TLS for et eget domene?

Når vertsnavnets DNS-post har bestått Dockup-domeneverifiseringen, kan du be om sertifikatutstedelse med den dokumenterte domain ssl-kommandoen.

Må containeren min lagre TLS-sertifikater?

Nei. Dockup håndterer TLS for det verifiserte egendefinerte domenet, så applikasjonscontaineren trenger verken sertifikatfiler eller en fornyelsesprosess.

Kan Dockup eksponere en ekstra container-port?

Ja. Port-kommandoene kan opprette et separat, automatisk generert domene for en ekstra offentlig port uten at du trenger egendefinert DNS.

Hva bør jeg kontrollere når plattform-URL-en fungerer, men det egendefinerte domenet feiler?

Fokuser på DNS-poster, propagering, domeneverifisering og sertifikatstatus. Den friske plattform-URL-en viser at applikasjonslaget sannsynligvis fungerer.