Mukautettu verkkotunnus ja automaattinen TLS Dockupissa

Mukautetun verkkotunnuksen ja automaattisen TLS:n käyttöönotossa on kolme erillistä kerrosta: Dockup-palvelun on oltava toimintakunnossa, DNS:n on osoitettava hostname platformille, ja hostnamen on läpäistävä vahvistus ennen varmenteen myöntämistä. Kun käsittelet näitä kerroksia erikseen, siirtymästä tulee ennakoitava eivätkä DNS-virheet vaikuta sovellusongelmilta.

Dockup antaa jokaiselle servicelle myös *.dockup.tech-osoitteen. Pidä tämä osoite käytettävissä DNS-propagoinnin aikana, jotta voit testata sovellusta erillään mukautetusta hostnamesta.

Mitä pitää olla valmiina ennen Dockupin mukautetun verkkotunnuksen lisäämistä?

Aloita servicestä, joka on jo käynnissä ja läpäisee readiness gate -tarkistuksen:

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

Avaa tai testaa nykyinen *.dockup.tech-URL. Jos sovellus ei toimi siinä, verkkotunnuksen lisääminen ei korjaa sitä. Tarkista ensin runtime-lokit.

Kerää seuraavat tiedot:

Kohde	Esimerkki	Miksi sillä on merkitystä
Tarkka kohde	production/web	Estää verkkotunnuksen liittämisen väärään serviceen
Hostname	app.example.com	DNS-nimi, jossa käyttäjät vierailevat
DNS-käyttöoikeus	Rekisteröijä tai DNS-palveluntarjoaja	Tarvitaan tietueen luomiseen
Nykyinen TTL	300 sekuntia	Hallitsee propagointia ja palautuksen nopeutta
Sovelluksen canonical URL	https://app.example.com	Voi vaikuttaa redirecteihin ja evästeisiin
Health-reitti	/health	Vahvistaa servicen toiminnan ennen siirtymää

Pienennä nykyisen DNS-tietueen TTL-arvoa etukäteen, kun korvaat käytössä olevan providerin. Älä poista vanhaa tietuetta ennen kuin Dockup-kohde, sovelluksen konfiguraatio ja rollback-suunnitelma ovat tiedossa.

Tarkista hostnamesta riippuva sovelluksen toiminta. Authentication callbackit, CORS-allowlistit, cookie domainit, OAuth redirect URL:t, webhook-kohteet ja automaattisesti luodut absoluuttiset linkit voivat vaatia uuden HTTPS-hostnamen.

Miten verkkotunnus lisätään ja vahvistetaan?

Listaa nykyiset verkkotunnukset ensin:

dockup domain list production/web --json

Lisää hostname:

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

Vastaus sisältää DNS-kohteen, joka on määritettävä. Luo DNS-palveluntarjoajalla ilmoitettu CNAME-tietue. Älä keksi IP-osoitetta tai kopioi arvoa toisesta servicestä, vaan käytä tälle verkkotunnukselle palautettua kohdetta.

Kun DNS on propagoinut, vahvista se palautetulla domain ID:llä:

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

Vahvistus osoittaa, että julkinen DNS-tietue selvitetään vaaditulla tavalla. Epäonnistuminen johtuu yleensä yhdestä neljästä syystä:

1. Tietueen nimi on väärä.
2. CNAME-kohde on väärä.
3. Vanha ristiriitainen A-, AAAA- tai CNAME-tietue on edelleen olemassa.
4. Resolverien välimuistit eivät ole vielä saavuttaneet uutta arvoa.

Tarkista authoritative DNS sen sijaan, että poistaisit ja loisit verkkotunnuksen toistuvasti uudelleen. Propagointi on hajautettu välimuistiprosessi, ei Dockupin build-prosessi.

Miten HTTPS-varmenne myönnetään ja sitä ylläpidetään?

Kun vahvistus onnistuu, pyydä varmennetta:

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

Dockup huolehtii vahvistetun hostnamen varmenteen myöntämisestä ja tarjoaa mukautetun verkkotunnuksen HTTPS:n kautta. Platform hallitsee TLS:n elinkaaren, joten application containerin ei tarvitse tallentaa varmennetiedostoja tai suorittaa varmenteen uusimisprosessia.

Vahvista tulos platformin ulkopuolelta:

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

Varmista, että:

• Varmenne vastaa hostnamea.
• Vastaus tarjotaan HTTPS:n kautta.
• Redirectit eivät muodosta silmukkaa.
• Sovellus palauttaa odotetun statuksen.
• Authentication- ja callback-virrat käyttävät uutta originiä.
• Staattiset assetit latautuvat ilman mixed content -virheitä.

Varmenteen myöntäminen voi epäonnistua, vaikka itse sovellus olisi kunnossa. Pidä DNS- ja service-diagnostiikka erillään. Käytä domain verify -komentoa DNS-omistajuuden vahvistamiseen ja service-lokeja sovelluksen toiminnan tutkimiseen.

Artikkelissa zero-downtime deploymentit kuvataan erillinen release readiness gate.

Miten liikenne siirretään ilman käyttökatkoa?

Turvallisessa siirtymässä vanha reitti pidetään käytettävissä, kunnes uusi hostname on todistettu toimivaksi.

1. Julkaise ja vahvista Dockup-service sen platform-URL:ssa.
2. Lisää mukautettu verkkotunnus Dockupissa.
3. Luo DNS-tietue.
4. Vahvista DNS.
5. Ota TLS käyttöön.
6. Testaa HTTPS suoraan.
7. Päivitä callbackit, canonical URL:t ja monitoring.
8. Ohjaa pieni osa operatiivisesta liikenteestä uuteen kohteeseen, jos DNS-asetukset sallivat sen.
9. Seuraa lokeja ja käytettävyyttä.
10. Poista vanha provider käytöstä vasta, kun uusi reitti on vakaa.

Dockupin uptime-tarkistukset suoritetaan minuutin välein, ja ne raportoivat response time -tilastoja, mukaan lukien p95-arvon:

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

Pidä kriittisillä verkkotunnuksilla käytössä erillinen ulkoinen monitoring. Platformin probe vahvistaa julkisen saavutettavuuden, kun taas ulkoinen monitor tarkistaa käyttäjän reitin toisesta järjestelmästä käsin.

Jos mukautettu verkkotunnus korvaa nykyisen production-hostin, säilytä rollback-tiedot: edellinen DNS-arvo, edellinen TTL, vanhan providerin tila ja ehto, joka käynnistää palautuksen.

Miten lisäporttien verkkotunnukset toimivat?

Service voi julkaista toisen HTTP-portin esimerkiksi admin UI:ta, metrics endpointia tai muuta web-prosessia varten. Dockup voi luoda ylimääräisen platform-verkkotunnuksen ilman mukautettua DNS:ää:

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

Palautettu verkkotunnus reitittää valittuun container-porttiin. Tämä on erillinen pääasiallisesta mukautetusta verkkotunnuksesta.

Älä julkaise porttia vain siksi, että jokin prosessi kuuntelee sitä. Selvitä, onko endpointissa authentication, sisältääkö se production-dataa ja pitäisikö sen ylipäätään olla julkinen. Internal-only admin interfacea ei pidä tehdä internetin kautta saavutettavaksi vain helppouden vuoksi.

Poista vanhentunut porttiverkkotunnus tuetun domain interfacen kautta vasta, kun olet varmistanut, ettei yksikään monitor, callback tai operator workflow enää käytä sitä. Port-domain-muutokset ovat mutaatioita, ja ne näkyvät audit-logissa.

Miten DNS-, TLS- ja sovellusvirheitä selvitetään?

Etene kerros kerrallaan:

Oire	Ensimmäinen tarkistus	Dockup-komento
Verkkotunnus ei ratkea	DNS-tietue ja propagointi	domain verify
Varmennetta ei myönnetä	Verkkotunnuksen vahvistustila	domain list, domain ssl
HTTPS toimii, mutta sovellus antaa virheen	Runtime-lokit	logs --json
Redirect-silmukka	Sovelluksen proxy-/host-asetukset	env list, runtime-lokit
Platform-URL toimii, mukautettu host ei	DNS-/TLS-kerros	Domain-komennot
Kumpikaan URL ei toimi	Deployment ja runtime	status, build/runtime-lokit
Toissijainen portti ei toimi	Port-domain-määritys ja prosessi	port list, runtime-lokit

Tarkastele servicen tulostetta sekoittamatta sitä DNS-päätelmiin:

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

Jos äskettäinen environment-muutos lisäsi canonical URL:n, muista, että se edellyttää redeployta:

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

dockup deploy production/web --wait --json

Environment variables and secrets -opas käsittelee tätä elinkaarta.

Verkkotunnuksen poisto ja rollback

Dockup-liitoksen poistaminen rikkoo reitin, joten siirrä tai poista ensin julkinen DNS-tietue ja vahvista aiottu korvaava ratkaisu. Poista liitos sen jälkeen tuetun domain interfacen kautta käyttämällä täsmällistä domain ID:tä.

Älä poista verkkotunnusta tilapäisen varmenne- tai propagointiongelman aikana, ellei palautussuunnitelma sitä edellytä. Kun konfiguraatio säilytetään, vahvistus voi onnistua välimuistien päivittyessä.

Tarkista mutaatiot komennolla:

dockup audit --search domains --json

Audit trail -lokin pitäisi osoittaa, kuka lisäsi, vahvisti, suojasi tai poisti hostnamen.

Production-handoverin tarkistuslista

Täydellinen mukautetun verkkotunnuksen ja automaattisen TLS:n handover sisältää service-kohteen, hostnamen, domain ID:n, DNS-tietueen tyypin ja kohteen, vahvistustuloksen, varmennetuloksen, sovelluksen callback-muutokset, monitoring-URL:n ja rollback-DNS-arvon.

Älä tallenna varmenteen private keytä repositoryyn tai containeriin. Dockupin hallinnoitu TLS-rajaus on olemassa juuri siksi, että application team voi käyttää hostnamea jakelematta varmennemateriaalia.

Käytä nykyisten flagien tarkistamiseen Dockup CLI referencea. Tee domain-työtä edeltävä ensimmäinen deployment ohjeen Git repository to production mukaan.

Suunnittele apex- ja subdomain-valinnat

Subdomain, kuten app.example.com, on yleensä yksinkertaisin sovelluksen hostname, koska DNS-palveluntarjoajat voivat esittää sen CNAME-tietueella. Apex, kuten example.com, voi edellyttää provider-kohtaista flattening- tai alias-toimintoa. Noudata Dockupin palauttamaa DNS-kohdetta ja authoritative DNS providerin ominaisuuksia.

Valitse yksi canonical host ja ohjaa vaihtoehdot application- tai routing layerilla. Sekä www- että apex-hostin tarjoaminen ilman canonical policyä voi hajauttaa evästeet, analytiikan, cache-merkinnät ja hakukoneindeksoinnin.

Testaa varmenteen uusimista koskevat oletukset

Managed TLS poistaa tarpeen ajaa renewal clientia containerissa, mutta hostnamen on jatkossakin selviydyttävä oikein. Tuleva DNS-migraatio, proxy-muutos tai poistettu tietue voi rikkoa validoinnin.

Sisällytä domain status säännöllisiin tarkistuksiin:

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

Mukautetun verkkotunnuksen ja automaattisen TLS:n runbookissa tulee nimetä DNS-omistaja, renewal contact ja viimeisimmän ulkoisen certificate checkin päivämäärä. Näin omistajuutta ei tarvitse selvittää vasta varmenneincidentin aikana.

Suojaa non-production-hostnamet

Staging- ja preview-hostnamet voivat paljastaa keskeneräisiä ominaisuuksia ja production-muotoista dataa. Käytä tarvittaessa application authenticationia, määritä indexing policy application layerilla ja rajoita non-production-URL:ien jakelua.

Hakukoneohjeet eivät ole access controlia. Suojattu ympäristö tarvitsee edelleen authenticationin ja asianmukaisen data handlingin.

Tarkista uudelleen propagoinnin jälkeen

Toista ulkoiset HTTPS- ja callback-testit, kun alkuperäinen DNS TTL on kulunut kokonaan.

Aloita todennettavasta deploymentista

Liitä ensin ei-kriittinen hostname, säilytä platform-URL propagoinnin aikana ja kirjaa tarkka rollbackiin tarvittava DNS-arvo.

Aloita ilmaiseksi osoitteessa app.dockup.ai. Free-plan maksaa 0 $ kuukaudessa, sisältää 10 $:n aloitussaldon ja tukee yhtä workspacea, kolmea databasea ja kolmea deploymentia.

Usein kysytyt kysymykset

Mitä DNS-tietuetta Dockupin mukautettu verkkotunnus tarvitsee?

Suorita dockup domain add ja luo vastauksessa ilmoitettu DNS-tietue. Käytä palautettua kohdetta sen sijaan, että kopioisit arvon toisesta servicestä.

Milloin Dockup voi myöntää TLS:n mukautetulle verkkotunnukselle?

Kun hostnamen DNS-tietue läpäisee Dockupin domain verificationin, pyydä varmenteen myöntämistä dokumentoidulla domain ssl -komennolla.

Pitääkö containerini tallentaa TLS-varmenteita?

Ei. Dockup hallitsee vahvistetun mukautetun verkkotunnuksen TLS:ää, joten application container ei tarvitse varmennetiedostoja tai uusimisprosessia.

Voiko Dockup julkaista ylimääräisen container-portin?

Kyllä. Port-komennot voivat luoda ylimääräiselle julkiselle portille erillisen automaattisesti luodun verkkotunnuksen ilman mukautettua DNS:ää.

Mitä pitäisi tarkistaa, jos platform-URL toimii mutta mukautettu verkkotunnus ei?

Keskity DNS-tietueisiin, propagointiin, domain verificationiin ja varmenteen tilaan. Toimiva platform-URL osoittaa, että application layer todennäköisesti toimii.