Prilagođena domena i automatski TLS na platformi Dockup

Postavljanje prilagođene domene i automatskog TLS-a sastoji se od tri zasebna sloja: usluga na platformi Dockup mora ispravno raditi, DNS mora usmjeravati hostname na platformu, a hostname mora proći verifikaciju prije izdavanja certifikata. Odvojeno promatranje tih slojeva čini prebacivanje predvidljivim i sprječava da DNS pogreške izgledaju kao problemi aplikacije.

Dockup svakoj usluzi dodjeljuje i adresu *.dockup.tech. Zadržite tu adresu dostupnom tijekom propagacije DNS-a kako biste mogli testirati aplikaciju neovisno o prilagođenom hostnameu.

Što treba biti spremno prije dodavanja prilagođene domene na platformu Dockup?

Započnite s uslugom koja je već pokrenuta i prolazi provjeru spremnosti:

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

Otvorite ili testirajte postojeći URL *.dockup.tech. Ako aplikacija tamo ne radi, dodavanje domene neće riješiti problem. Najprije pregledajte runtime logove.

Prikupite sljedeće informacije:

Stavka	Primjer	Zašto je važna
Točno odredište	production/web	Sprječava povezivanje domene s pogrešnom uslugom
Hostname	app.example.com	DNS naziv koji će korisnici posjećivati
DNS pristup	Registrar ili DNS provider	Potreban za izradu zapisa
Trenutačni TTL	300 sekundi	Kontrolira brzinu propagacije i rollbacka
Kanonski URL aplikacije	https://app.example.com	Može utjecati na redirekcije i cookies
Health ruta	/health	Potvrđuje ispravnost usluge prije prebacivanja

Unaprijed smanjite postojeći DNS TTL kada zamjenjujete aktivnog providera. Nemojte brisati stari zapis dok nisu poznati Dockup target, konfiguracija aplikacije i plan rollbacka.

Provjerite ponašanje aplikacije koje ovisi o hostu. Authentication callbackovi, CORS allowliste, domene cookieja, OAuth redirect URL-ovi, odredišta webhookova i generirani apsolutni linkovi možda će trebati novi HTTPS hostname.

Kako dodati i verificirati domenu?

Najprije izlistajte trenutačne domene:

dockup domain list production/web --json

Dodajte hostname:

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

Odgovor sadrži DNS target koji treba konfigurirati. Izradite navedeni CNAME zapis kod DNS providera. Nemojte izmišljati IP adresu ni kopirati vrijednost s druge usluge; upotrijebite target koji je vraćen za ovu domenu.

Nakon propagacije DNS-a verificirajte domenu pomoću vraćenog ID-ja domene:

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

Verifikacija potvrđuje da se javni DNS zapis razrješava na potreban način. Neuspjeh obično znači jedno od četvero:

1. Naziv zapisa nije točan.
2. CNAME target nije točan.
3. I dalje postoji stari konfliktni A, AAAA ili CNAME zapis.
4. Resolver cacheovi još nisu preuzeli novu vrijednost.

Provjerite authoritative DNS umjesto da domenu neprestano uklanjate i ponovno izrađujete. Propagacija je distribuirani cache proces, a ne Dockup build proces.

Kako se HTTPS certifikat izdaje i održava?

Nakon uspješne verifikacije zatražite certifikat:

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

Dockup upravlja izdavanjem certifikata za verificirani hostname i poslužuje prilagođenu domenu putem HTTPS-a. Platforma upravlja životnim ciklusom TLS-a, pa application container ne treba pohranjivati datoteke certifikata ni pokretati proces obnove certifikata.

Rezultat provjerite izvan platforme:

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

Potvrdite sljedeće:

• Certifikat odgovara hostnameu.
• Odgovor se poslužuje putem HTTPS-a.
• Redirekcije ne ulaze u petlju.
• Aplikacija vraća očekivani status.
• Authentication i callback tokovi upotrebljavaju novi origin.
• Statička sredstva učitavaju se bez mixed-content pogrešaka.

Izdavanje certifikata može ne uspjeti čak i kada sama aplikacija ispravno radi. DNS dijagnostiku i dijagnostiku usluge držite odvojenima. Za vlasništvo nad DNS-om upotrijebite domain verify, a za ponašanje aplikacije service logove.

Članak deployments bez prekida rada objašnjava neovisnu provjeru spremnosti za release.

Kako prebaciti promet bez prekida rada?

Sigurno prebacivanje zadržava stari put dostupnim dok se ne potvrdi da novi hostname radi.

1. Deployajte i verificirajte Dockup uslugu na njezinu platformskom URL-u.
2. Dodajte prilagođenu domenu u Dockupu.
3. Izradite DNS zapis.
4. Verificirajte DNS.
5. Izdajte TLS.
6. Izravno testirajte HTTPS.
7. Ažurirajte callbackove, kanonske URL-ove i monitoring.
8. Pošaljite manji dio operativnog prometa ako DNS postavke to dopuštaju.
9. Pratite logove i dostupnost.
10. Uklonite starog providera tek nakon što je novi put stabilan.

Dockup uptime provjere pokreću se svake minute i prijavljuju statistiku vremena odziva, uključujući p95:

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

Za kritične domene zadržite neovisni external monitoring. Platform probe potvrđuje javnu dostupnost, dok external monitor provjerava korisnički put iz drugog sustava.

Ako prilagođena domena zamjenjuje trenutačni production host, sačuvajte rollback zapis: prethodnu DNS vrijednost, prethodni TTL, status starog providera i uvjet koji bi pokrenuo vraćanje na staro stanje.

Kako funkcioniraju domene za dodatne portove?

Usluga može izložiti drugi HTTP port za admin UI, metrics endpoint ili drugi web proces. Dockup može izraditi dodatnu platformsku domenu bez prilagođenog DNS-a:

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

Vraćena domena usmjerava promet na odabrani container port. To je odvojeno od glavne prilagođene domene.

Nemojte izložiti port samo zato što proces na njemu sluša. Provjerite ima li endpoint authentication, sadrži li production podatke i treba li uopće biti javan. Interni admin interface ne bi smio postati dostupan na internetu samo zato što je to praktično.

Uklonite zastarjelu domenu porta putem podržanog sučelja za domene tek nakon što provjerite da je više ne upotrebljavaju monitor, callback ni operatorski workflow. Promjene domena portova su mutacije i pojavljuju se u audit logu.

Kako otkloniti poteškoće s DNS-om, TLS-om i pogreškama aplikacije?

Dijagnosticirajte problem sloj po sloj:

Simptom	Prva provjera	Dockup naredba
Domena se ne razrješava	DNS zapis i propagacija	domain verify
Certifikat nije izdan	Status verifikacije domene	domain list, domain ssl
HTTPS radi, ali aplikacija javlja pogrešku	Runtime logovi	logs --json
Petlja redirekcija	Postavke application proxya/hosta	env list, runtime logovi
Platformsko URL radi, prilagođeni host ne radi	DNS/TLS sloj	Naredbe za domene
Oba URL-a ne rade	Deployment i runtime	status, build/runtime logovi
Sekundarni port ne radi	Mapiranje domene porta i proces	port list, runtime logovi

Pregledajte izlaz usluge bez miješanja zaključaka o aplikaciji sa zaključcima o DNS-u:

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

Ako je nedavna promjena environmenta dodala kanonski URL, imajte na umu da je potreban redeploy:

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

dockup deploy production/web --wait --json

U vodiču o environment varijablama i secretsima objašnjen je taj životni ciklus.

Uklanjanje domene i rollback

Uklanjanje Dockup poveznice destruktivno je za rutu, stoga najprije premjestite ili uklonite javni DNS zapis i potvrdite željenu zamjenu. Zatim uklonite poveznicu putem podržanog sučelja za domene, koristeći točan ID domene.

Nemojte uklanjati domenu tijekom privremenog incidenta s certifikatom ili propagacijom, osim ako to zahtijeva plan oporavka. Zadržavanje konfiguracije omogućuje uspješnu verifikaciju kada se cacheovi ažuriraju.

Pregledajte mutacije pomoću:

dockup audit --search domains --json

Audit trag trebao bi pokazivati tko je dodao, verificirao, osigurao ili uklonio hostname.

Kontrolni popis za predaju u production

Potpuna primopredaja prilagođene domene i automatskog TLS-a uključuje target usluge, hostname, ID domene, vrstu i target DNS zapisa, rezultat verifikacije, rezultat certifikata, promjene application callbackova, URL monitoringa i DNS vrijednost za rollback.

Ne pohranjujte privatni ključ certifikata u repository ili container. Dockupova granica upravljanog TLS-a postoji upravo zato da application team može upravljati hostnameom bez distribuiranja materijala certifikata.

Za sve trenutačne flagove koristite Dockup CLI reference. Za početni deployment prije rada s domenom slijedite vodič Od Git repositoryja do production deploymenta.

Planirajte izbor apex domene i subdomene

Subdomena poput app.example.com obično je najjednostavniji hostname aplikacije jer je DNS provideri mogu predstaviti CNAME zapisom. Apex domena poput example.com može zahtijevati provider-specific flattening ili alias ponašanje. Slijedite DNS target koji vraća Dockup i mogućnosti authoritative DNS providera.

Odaberite jedan kanonski host i preusmjerite alternative na application ili routing sloju. Posluživanje i www i apex domene bez kanonske politike može razdvojiti cookies, analytics, cache unose i indeksiranje u tražilicama.

Testirajte pretpostavke o obnovi certifikata

Managed TLS uklanja potrebu za pokretanjem renewal klijenta unutar containera, ali hostname se i dalje mora ispravno razrješavati. Buduća migracija DNS-a, promjena proxya ili obrisani zapis mogu prekinuti validaciju.

U redovite provjere uključite status domene:

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

Runbook za prilagođenu domenu i automatski TLS trebao bi navesti vlasnika DNS-a, kontakt za obnovu i datum posljednje vanjske provjere certifikata. Tako ćete izbjeći otkrivanje vlasništva tek kada dođe do incidenta s certifikatom.

Zaštitite hostnameove koji nisu u productionu

Staging i preview hostnameovi mogu izložiti nedovršene značajke i podatke oblikovane prema productionu. Prema potrebi upotrijebite application authentication, definirajte indexing policy na application sloju i ograničite distribuciju URL-ova koji nisu u productionu.

Direktive za tražilice nisu access control. Zaštićeno okruženje i dalje treba authentication i odgovarajuće postupanje s podacima.

Ponovno provjerite nakon propagacije

Ponovite vanjske HTTPS i callback testove nakon što u potpunosti istekne izvorni DNS TTL.

Započnite deploymentom koji se može verificirati

Najprije povežite nekritični hostname, zadržite platformski URL tijekom propagacije i zabilježite točnu DNS vrijednost potrebnu za rollback.

Započnite besplatno na app.dockup.ai. Free plan iznosi 0 USD mjesečno, uključuje početni kredit od 10 USD te podržava jedan workspace, tri baze podataka i tri deploymenta.

Često postavljana pitanja

Koji DNS zapis treba prilagođena domena na platformi Dockup?

Pokrenite dockup domain add i izradite DNS zapis prikazan u njegovu odgovoru. Upotrijebite vraćeni target umjesto kopiranja vrijednosti s druge usluge.

Kada Dockup može izdati TLS za prilagođenu domenu?

Nakon što DNS zapis hostnamea prođe Dockup verifikaciju domene, zatražite izdavanje certifikata pomoću dokumentirane naredbe domain ssl.

Mora li moj container pohranjivati TLS certifikate?

Ne. Dockup upravlja TLS-om za verificiranu prilagođenu domenu, pa application container ne treba datoteke certifikata ni proces obnove.

Može li Dockup izložiti dodatni container port?

Da. Naredbe za port mogu izraditi zasebnu automatski generiranu domenu za dodatni javni port bez potrebe za prilagođenim DNS-om.

Što trebam provjeriti kada platformski URL radi, a prilagođena domena ne radi?

Usredotočite se na DNS zapise, propagaciju, verifikaciju domene i status certifikata. Ispravan platformski URL pokazuje da application sloj vjerojatno radi.