Brugerdefineret domæne og automatisk TLS på Dockup

En opsætning med brugerdefineret domæne og automatisk TLS består af tre separate lag: Dockup-tjenesten skal være sund, DNS skal pege værtsnavnet på platformen, og værtsnavnet skal bestå verificeringen, før der kan udstedes et certifikat. Når lagene behandles separat, bliver overgangen forudsigelig, og DNS-fejl forveksles ikke med applikationsfejl.

Dockup giver også alle tjenester en *.dockup.tech-adresse. Behold denne adresse tilgængelig under DNS-propagationen, så du kan teste applikationen uafhængigt af det brugerdefinerede værtsnavn.

Hvad skal være klar, før du tilføjer et Dockup-brugerdefineret domæne?

Start med en tjeneste, der allerede kører og består sin readiness-kontrol:

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

Åbn eller test den eksisterende *.dockup.tech-URL. Hvis applikationen fejler dér, vil et domæne ikke løse problemet. Gennemgå runtime-logs først.

Indsaml følgende oplysninger:

Element	Eksempel	Hvorfor det er vigtigt
Præcist mål	production/web	Forhindrer, at domænet knyttes til den forkerte tjeneste
Værtsnavn	app.example.com	Det DNS-navn, brugerne vil besøge
DNS-adgang	Registrar eller DNS-udbyder	Påkrævet for at oprette recorden
Aktuel TTL	300 sekunder	Styrer propagations- og rollback-hastigheden
Applikationens canonical URL	https://app.example.com	Kan påvirke redirects og cookies
Health-route	/health	Bekræfter tjenesten før overgangen

Sænk den eksisterende DNS-TTL på forhånd, når du erstatter en aktiv udbyder. Slet ikke den gamle record, før Dockup-målet, applikationskonfigurationen og rollback-planen er kendt.

Gennemgå applikationsadfærd, der afhænger af værten. Authentication callbacks, CORS-allowlists, cookie-domæner, OAuth-redirect-URL'er, webhook-destinationer og genererede absolutte links kan kræve det nye HTTPS-værtsnavn.

Hvordan tilføjer og verificerer du domænet?

Vis først de aktuelle domæner:

dockup domain list production/web --json

Tilføj værtsnavnet:

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

Svaret indeholder det DNS-mål, der skal konfigureres. Opret den angivne CNAME-record hos DNS-udbyderen. Opfind ikke en IP-adresse, og kopier ikke en værdi fra en anden tjeneste. Brug det mål, der returneres for dette domæne.

Når DNS er propagateret, skal du verificere det med det returnerede domæne-ID:

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

Verificeringen beviser, at den offentlige DNS-record resolver som krævet. En fejl skyldes normalt én af fire ting:

1. Record-navnet er forkert.
2. CNAME-målet er forkert.
3. En gammel, modstridende A-, AAAA- eller CNAME-record findes stadig.
4. Resolver-caches har endnu ikke fået den nye værdi.

Kontrollér den autoritative DNS i stedet for gentagne gange at fjerne og genoprette domænet. Propagation er en distribueret cache-proces, ikke en Dockup-build-proces.

Hvordan udstedes og vedligeholdes HTTPS-certifikatet?

Når verificeringen er gennemført, skal du anmode om certifikatet:

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

Dockup håndterer certifikatudstedelsen for det verificerede værtsnavn og leverer det brugerdefinerede domæne over HTTPS. Platformen håndterer TLS-livscyklussen, så applikationscontaineren ikke behøver at gemme certifikatfiler eller køre en proces til certifikatfornyelse.

Validér resultatet uden for platformen:

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

Bekræft, at:

• Certifikatet matcher værtsnavnet.
• Svaret leveres over HTTPS.
• Redirects ikke går i loop.
• Applikationen returnerer den forventede status.
• Authentication- og callback-flows bruger den nye origin.
• Statiske assets indlæses uden mixed-content-fejl.

Certifikatudstedelsen kan fejle, selv når selve applikationen er sund. Hold DNS- og tjenestediagnostik adskilt. Brug domain verify til DNS-ejerskab og service-logs til applikationsadfærd.

Artiklen om zero-downtime deployments forklarer den separate readiness-gate for releases.

Hvordan skifter du trafikken uden nedetid?

En sikker overgang holder den gamle sti tilgængelig, indtil det nye værtsnavn er afprøvet.

1. Udrul og verificér Dockup-tjenesten på dens platform-URL.
2. Tilføj det brugerdefinerede domæne i Dockup.
3. Opret DNS-recorden.
4. Verificér DNS.
5. Udsted TLS.
6. Test HTTPS direkte.
7. Opdatér callbacks, canonical-URL'er og monitoring.
8. Send en lille del af den operationelle trafik, hvis DNS-opsætningen tillader det.
9. Overvåg logs og oppetid.
10. Afvikl først den gamle udbyder, når den nye sti er stabil.

Dockups uptime checks kører hvert minut og rapporterer svartidsstatistik, herunder p95:

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

Behold uafhængig ekstern monitoring for kritiske domæner. En platform-probe bekræfter offentlig tilgængelighed, mens en ekstern monitor verificerer brugerens sti fra et andet system.

Hvis det brugerdefinerede domæne erstatter en aktuel production-host, skal du gemme en rollback-record: den tidligere DNS-værdi, den tidligere TTL, status for den gamle udbyder og den betingelse, der udløser en tilbageførsel.

Hvordan fungerer domæner til ekstra porte?

En tjeneste kan eksponere en ekstra HTTP-port til et admin-UI, et metrics-endpoint eller en anden webproces. Dockup kan oprette et ekstra platform-domæne uden brugerdefineret DNS:

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

Det returnerede domæne dirigerer til den valgte container-port. Dette er separat fra det primære brugerdefinerede domæne.

Eksponér ikke en port, blot fordi en proces lytter på den. Overvej, om endpointet har authentication, om det indeholder production-data, og om det overhovedet bør være offentligt. En intern admin-grænseflade bør ikke blive tilgængelig fra internettet af bekvemmelighedshensyn.

Fjern et forældet portdomæne via den understøttede domænegrænseflade, men først efter at du har verificeret, at ingen monitor, callback eller operator-workflow stadig bruger det. Ændringer af portdomæner er mutationer og vises i audit-loggen.

Hvordan foretager du fejlfinding af DNS-, TLS- og applikationsfejl?

Brug en lagdelt diagnose:

Symptom	Første kontrol	Dockup-kommando
Domænet resolver ikke	DNS-record og propagation	domain verify
Certifikatet er ikke udstedt	Status for domæneverificering	domain list, domain ssl
HTTPS virker, men applikationen fejler	Runtime-logs	logs --json
Redirect-loop	Applikationens proxy-/host-indstillinger	env list, runtime-logs
Platform-URL virker, men brugerdefineret host fejler	DNS-/TLS-lag	Domænekommandoer
Begge URL'er fejler	Deployment og runtime	status, build-/runtime-logs
Sekundær port fejler	Port-domæne-mapping og proces	port list, runtime-logs

Undersøg tjenestens output uden at blande det sammen med DNS-konklusioner:

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

Hvis en nylig environment-ændring tilføjede den canonical URL, skal du huske, at 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 environment variables og secrets gennemgår denne livscyklus.

Fjernelse af domæne og rollback

Når Dockup-tilknytningen fjernes, påvirker det routen destruktivt. Flyt eller fjern derfor først den offentlige DNS-record, og bekræft den planlagte erstatning. Fjern derefter tilknytningen via den understøttede domænegrænseflade ved hjælp af det præcise domæne-ID.

Fjern ikke domænet under en midlertidig certifikat- eller propagationshændelse, medmindre recovery-planen kræver det. Hvis konfigurationen bevares, kan verificeringen lykkes, når caches opdateres.

Gennemgå mutationer med:

dockup audit --search domains --json

Audit-sporet bør vise, hvem der tilføjede, verificerede, sikrede eller fjernede værtsnavnet.

Tjekliste til production-overdragelse

En komplet overdragelse af brugerdefineret domæne og automatisk TLS omfatter tjenestens mål, værtsnavn, domæne-ID, DNS-recordens type og mål, verificeringsresultat, certifikatresultat, ændringer af applikationens callbacks, monitoring-URL og rollback-DNS-værdi.

Gem aldrig en privat certifikatnøgle i repositoryet eller containeren. Dockups managed TLS-grænse findes netop, så applikationsteamet kan drive værtsnavnet uden at distribuere certifikatmateriale.

Brug Dockup CLI-referencen til alle aktuelle flags. Følg Git-repository til production for den indledende deployment før domænearbejdet.

Planlæg valg af apex og subdomæne

Et subdomæne som app.example.com er normalt det enkleste applikationsværtsnavn, fordi DNS-udbydere kan repræsentere det med en CNAME. Et apex som example.com kan kræve provider-specifik flattening eller alias-adfærd. Følg det DNS-mål, Dockup returnerer, samt funktionerne hos den autoritative DNS-udbyder.

Vælg én canonical host, og redirect alternativer på applikations- eller routing-laget. Hvis både www og apex serveres uden en canonical-politik, kan cookies, analytics, cache entries og søgeindeksering blive splittet.

Test antagelser om certifikatfornyelse

Managed TLS fjerner behovet for at køre en renewal-klient i containeren, men værtsnavnet skal fortsat resolve korrekt. En fremtidig DNS-migrering, proxyændring eller slettet record kan ødelægge valideringen.

Medtag domænestatus i de løbende gennemgange:

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

Runbooken for brugerdefineret domæne og automatisk TLS bør angive DNS-ejeren, kontaktpersonen for fornyelse og datoen for den seneste eksterne certifikatkontrol. Det forhindrer, at ejerskab først bliver afklaret, når der opstår en certifikathændelse.

Beskyt ikke-produktionsværtsnavne

Staging- og preview-værtsnavne kan eksponere ufærdige funktioner og data, der ligner production-data. Brug applikationsauthentication, hvor det er nødvendigt, definér en indekseringspolitik på applikationslaget, og begræns distributionen af ikke-produktions-URL'er.

Direktiver til søgemaskiner er ikke adgangskontrol. Et beskyttet miljø har stadig brug for authentication og korrekt datahåndtering.

Kontrollér igen efter propagation

Gentag eksterne HTTPS- og callback-tests, når den oprindelige DNS-TTL er udløbet helt.

Start med en deployment, der kan verificeres

Tilknyt først et ikke-kritisk værtsnavn, behold platform-URL'en under propagation, og notér den præcise DNS-værdi, der skal bruges til rollback.

Kom gratis i gang på app.dockup.ai. Free-planen koster $0 om måneden, inkluderer $10 i startkredit og understøtter ét workspace, tre databaser og tre deployments.

FAQ

Hvilken DNS-record kræver et Dockup-brugerdefineret domæne?

Kør dockup domain add, og opret den DNS-record, der vises i svaret. Brug det returnerede mål i stedet for at kopiere en værdi fra en anden tjeneste.

Hvornår kan Dockup udstede TLS til et brugerdefineret domæne?

Når værtsnavnets DNS-record har bestået Dockup-domæneverificeringen, kan du anmode om certifikatudstedelse med den dokumenterede domain ssl-kommando.

Skal min container gemme TLS-certifikater?

Nej. Dockup håndterer TLS for det verificerede brugerdefinerede domæne, så applikationscontaineren ikke behøver certifikatfiler eller en fornyelsesproces.

Kan Dockup eksponere en ekstra container-port?

Ja. Portkommandoerne kan oprette et separat, automatisk genereret domæne til en ekstra offentlig port uden krav om brugerdefineret DNS.

Hvad skal jeg kontrollere, når platform-URL'en virker, men det brugerdefinerede domæne fejler?

Fokusér på DNS-records, propagation, domæneverificering og certifikatstatus. Den fungerende platform-URL viser, at applikationslaget sandsynligvis fungerer.