Domeniu personalizat și TLS automat pe Dockup

O configurație cu domeniu personalizat și TLS automat are trei niveluri separate: serviciul Dockup trebuie să fie funcțional, DNS-ul trebuie să direcționeze hostname-ul către platformă, iar hostname-ul trebuie să treacă verificarea înainte să poată fi emis un certificat. Tratarea separată a acestor niveluri face schimbarea previzibilă și împiedică erorile DNS să pară probleme ale aplicației.

Dockup oferă fiecărui serviciu și o adresă *.dockup.tech. Păstrați această adresă disponibilă în timpul propagării DNS, astfel încât să puteți testa aplicația independent de hostname-ul personalizat.

Ce trebuie să fie pregătit înainte de a adăuga un domeniu personalizat Dockup?

Începeți cu un serviciu care rulează deja și trece verificarea de readiness:

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

Deschideți sau testați URL-ul existent *.dockup.tech. Dacă aplicația eșuează acolo, adăugarea unui domeniu nu va remedia problema. Verificați mai întâi runtime logs.

Colectați următoarele informații:

Element	Exemplu	De ce este important
Target exact	production/web	Împiedică asocierea domeniului cu serviciul greșit
Hostname	app.example.com	Numele DNS pe care îl vor accesa utilizatorii
Acces DNS	Registrar sau furnizor DNS	Este necesar pentru crearea înregistrării
TTL curent	300 secunde	Controlează viteza propagării și a rollback-ului
URL canonical al aplicației	https://app.example.com	Poate afecta redirecturile și cookie-urile
Rută de health check	/health	Confirmă serviciul înainte de schimbare

Reduceți din timp TTL-ul DNS existent atunci când înlocuiți un provider activ. Nu ștergeți vechea înregistrare până când nu sunt cunoscute targetul Dockup, configurația aplicației și planul de rollback.

Verificați comportamentul aplicației care depinde de host. Callback-urile de autentificare, allowlist-urile CORS, domeniile cookie-urilor, URL-urile de redirect OAuth, destinațiile webhook-urilor și linkurile absolute generate pot necesita noul hostname HTTPS.

Cum adăugați și verificați domeniul?

Mai întâi, listați domeniile curente:

dockup domain list production/web --json

Adăugați hostname-ul:

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

Răspunsul furnizează targetul DNS care trebuie configurat. Creați înregistrarea CNAME indicată la furnizorul DNS. Nu inventați o adresă IP și nu copiați o valoare de la alt serviciu; folosiți targetul returnat pentru acest domeniu.

După propagarea DNS, verificați domeniul folosind ID-ul returnat:

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

Verificarea demonstrează că înregistrarea DNS publică se rezolvă conform cerințelor. O eroare indică de obicei una dintre următoarele patru situații:

1. Numele înregistrării este greșit.
2. Targetul CNAME este greșit.
3. Încă există o înregistrare A, AAAA sau CNAME veche și conflictuală.
4. Cache-urile resolverelor nu au ajuns încă la noua valoare.

Verificați DNS-ul autoritativ în loc să eliminați și să recreați domeniul în mod repetat. Propagarea este un proces distribuit de cache, nu un proces de build Dockup.

Cum este emis și administrat certificatul HTTPS?

După ce verificarea reușește, solicitați certificatul:

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

Dockup gestionează emiterea certificatului pentru hostname-ul verificat și oferă domeniul personalizat prin HTTPS. Platforma administrează ciclul de viață TLS, astfel încât containerul aplicației nu trebuie să stocheze fișiere de certificat și nici să ruleze un proces de reînnoire a certificatului.

Validați rezultatul din afara platformei:

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

Confirmați că:

• Certificatul corespunde hostname-ului.
• Răspunsul este oferit prin HTTPS.
• Redirecturile nu intră într-o buclă.
• Aplicația returnează statusul așteptat.
• Fluxurile de autentificare și callback folosesc noul origin.
• Asset-urile statice se încarcă fără erori de mixed content.

Emiterea certificatului poate eșua chiar și atunci când aplicația este funcțională. Păstrați separate diagnosticarea DNS și cea a serviciului. Folosiți domain verify pentru verificarea proprietății DNS și service logs pentru comportamentul aplicației.

Articolul despre deployment-uri zero-downtime explică separat verificarea readiness pentru release.

Cum schimbați traficul fără întreruperi?

O schimbare sigură păstrează vechea rută disponibilă până când noul hostname este verificat.

1. Faceți deploy și verificați serviciul Dockup la URL-ul platformei.
2. Adăugați domeniul personalizat în Dockup.
3. Creați înregistrarea DNS.
4. Verificați DNS-ul.
5. Emiteți certificatul TLS.
6. Testați direct prin HTTPS.
7. Actualizați callback-urile, URL-urile canonical și monitorizarea.
8. Direcționați o mică parte din traficul operațional, dacă configurația DNS permite.
9. Monitorizați logurile și uptime-ul.
10. Renunțați la providerul vechi numai după ce noua rută este stabilă.

Verificările Dockup pentru uptime rulează în fiecare minut și raportează statistici privind timpul de răspuns, inclusiv p95:

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

Păstrați un sistem extern de monitoring pentru domeniile critice. O verificare a platformei confirmă accesibilitatea publică, în timp ce un monitor extern verifică traseul utilizatorului dintr-un alt sistem.

Dacă domeniul personalizat înlocuiește un host de producție actual, păstrați o evidență pentru rollback: valoarea DNS anterioară, TTL-ul anterior, statusul providerului vechi și condiția care ar declanșa revenirea.

Cum funcționează domeniile pentru porturi suplimentare?

Un serviciu poate expune un al doilea port HTTP pentru un admin UI, un endpoint de metrics sau un alt proces web. Dockup poate crea un domeniu suplimentar al platformei fără DNS personalizat:

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

Domeniul returnat direcționează traficul către portul selectat al containerului. Această configurație este separată de domeniul personalizat principal.

Nu expuneți un port doar pentru că un proces ascultă pe acesta. Întrebați-vă dacă endpoint-ul are autentificare, dacă include date de producție și dacă ar trebui să fie public. O interfață de administrare destinată exclusiv uzului intern nu ar trebui să devină accesibilă de pe internet doar pentru comoditate.

Eliminați un domeniu de port devenit inutil prin interfața de domenii acceptată numai după ce verificați că niciun monitor, callback sau flux operațional nu îl mai folosește. Modificările domeniilor de port sunt mutații și apar în audit log.

Cum depanați erorile DNS, TLS și ale aplicației?

Folosiți o diagnosticare pe niveluri:

Simptom	Prima verificare	Comandă Dockup
Domeniul nu se rezolvă	Înregistrarea DNS și propagarea	domain verify
Certificatul nu este emis	Statusul verificării domeniului	domain list, domain ssl
HTTPS funcționează, dar aplicația are erori	Runtime logs	logs --json
Buclă de redirectare	Setările application proxy/host	env list, runtime logs
URL-ul platformei funcționează, dar host-ul personalizat nu	Nivelul DNS/TLS	Comenzi pentru domeniu
Ambele URL-uri eșuează	Deployment și runtime	status, build/runtime logs
Portul secundar nu funcționează	Asocierea port-domeniu și procesul	port list, runtime logs

Inspectați output-ul serviciului fără să-l amestecați cu concluziile despre DNS:

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

Dacă o modificare recentă de mediu a adăugat URL-ul canonical, rețineți că este necesar un redeploy:

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

dockup deploy production/web --wait --json

Ghidul pentru environment variables și secrets acoperă acest ciclu de viață.

Eliminarea domeniului și rollback

Eliminarea asocierii Dockup este distructivă pentru rută, așa că mai întâi mutați sau eliminați înregistrarea DNS publică și confirmați înlocuitorul dorit. Apoi eliminați asocierea prin interfața de domenii acceptată, folosind ID-ul exact al domeniului.

Nu eliminați domeniul în timpul unui incident temporar de certificat sau propagare decât dacă planul de recuperare o impune. Păstrarea configurației permite reușita verificării atunci când cache-urile se actualizează.

Verificați mutațiile cu:

dockup audit --search domains --json

Audit trail-ul ar trebui să arate cine a adăugat, verificat, securizat sau eliminat hostname-ul.

Checklist pentru predarea către echipa de producție

O predare completă pentru domeniu personalizat și TLS automat include targetul serviciului, hostname-ul, ID-ul domeniului, tipul și targetul înregistrării DNS, rezultatul verificării, rezultatul emiterii certificatului, modificările callback-urilor aplicației, URL-ul pentru monitoring și valoarea DNS pentru rollback.

Nu stocați cheia privată a certificatului în repository sau în container. Limita TLS administrată de Dockup există tocmai pentru ca echipa aplicației să poată opera hostname-ul fără a distribui materialul certificatului.

Pentru toate flag-urile curente, folosiți referința Dockup CLI. Pentru deployment-ul inițial, înainte de configurarea domeniului, urmați ghidul De la repository Git la producție.

Planificați alegerile pentru apex și subdomeniu

Un subdomeniu precum app.example.com este de obicei cel mai simplu hostname pentru aplicație, deoarece furnizorii DNS îl pot reprezenta printr-un CNAME. Un apex precum example.com poate necesita flattening sau alias behavior specific furnizorului. Urmați targetul DNS returnat de Dockup și capabilitățile furnizorului DNS autoritativ.

Alegeți un singur host canonical și redirecționați alternativele la nivelul aplicației sau al routing-ului. Servirea atât a www, cât și a apex-ului fără o politică canonicală poate separa cookie-urile, analytics, intrările de cache și indexarea în motoarele de căutare.

Testați presupunerile privind reînnoirea certificatului

TLS administrat elimină necesitatea de a rula un client de reînnoire în container, însă hostname-ul trebuie să continue să se rezolve corect. O migrare DNS ulterioară, o modificare de proxy sau o înregistrare ștearsă pot întrerupe validarea.

Includeți statusul domeniului în verificările de rutină:

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

Runbook-ul pentru domeniu personalizat și TLS automat ar trebui să precizeze responsabilul DNS, contactul pentru reînnoire și data ultimei verificări externe a certificatului. Astfel, responsabilitatea nu va fi descoperită abia atunci când apare un incident legat de certificat.

Protejați hostname-urile non-production

Hostname-urile de staging și preview pot expune funcționalități neterminate și date cu structură similară celor de producție. Folosiți autentificarea aplicației acolo unde este necesar, definiți politica de indexare la nivelul aplicației și limitați distribuirea URL-urilor non-production.

Directivele pentru motoarele de căutare nu reprezintă un mecanism de control al accesului. Un mediu protejat are în continuare nevoie de autentificare și de gestionarea adecvată a datelor.

Verificați din nou după propagare

Repetați testele externe HTTPS și callback după ce a expirat complet TTL-ul DNS inițial.

Începeți cu un deployment verificabil

Asociați mai întâi un hostname care nu este critic, păstrați URL-ul platformei pe durata propagării și notați valoarea DNS exactă necesară pentru rollback.

Începeți gratuit pe app.dockup.ai. Planul Free costă 0 USD pe lună, include un credit inițial de 10 USD și oferă suport pentru un workspace, trei baze de date și trei deployment-uri.

Întrebări frecvente

De ce înregistrare DNS are nevoie un domeniu personalizat Dockup?

Rulați dockup domain add și creați înregistrarea DNS afișată în răspuns. Folosiți targetul returnat în loc să copiați o valoare de la alt serviciu.

Când poate Dockup emite TLS pentru un domeniu personalizat?

După ce înregistrarea DNS a hostname-ului trece verificarea domeniului Dockup, solicitați emiterea certificatului cu comanda documentată domain ssl.

Trebuie ca containerul meu să stocheze certificate TLS?

Nu. Dockup gestionează TLS pentru domeniul personalizat verificat, astfel încât containerul aplicației nu are nevoie de fișiere de certificat sau de un proces de reînnoire.

Poate Dockup să expună un port suplimentar al containerului?

Da. Comenzile pentru porturi pot crea un domeniu separat, generat automat, pentru un port public suplimentar, fără a necesita DNS personalizat.

Ce ar trebui să verific atunci când URL-ul platformei funcționează, dar domeniul personalizat nu?

Concentrați-vă pe înregistrările DNS, propagare, verificarea domeniului și statusul certificatului. URL-ul funcțional al platformei arată că nivelul aplicației funcționează probabil corect.