Персонализиран домейн и автоматичен TLS в Dockup

Настройката на персонализиран домейн и автоматичен TLS има три отделни слоя: услугата в Dockup трябва да работи нормално, DNS трябва да насочва hostname-а към платформата, а hostname-ът трябва да премине проверка, преди да бъде издаден сертификат. Разграничаването на тези слоеве прави преминаването предвидимо и предотвратява DNS грешките да изглеждат като проблеми в приложението.

Dockup предоставя на всяка услуга и адрес *.dockup.tech. Запазете този адрес достъпен по време на DNS propagation, за да можете да тествате приложението независимо от персонализирания hostname.

Какво трябва да е готово, преди да добавите персонализиран домейн в Dockup?

Започнете с услуга, която вече работи и преминава readiness проверката:

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

Отворете или тествайте съществуващия URL *.dockup.tech. Ако приложението не работи там, добавянето на домейн няма да го поправи. Първо прегледайте runtime логовете.

Съберете следната информация:

Елемент	Пример	Защо е важен
Точен target	production/web	Предотвратява прикачването на домейна към грешната услуга
Hostname	app.example.com	DNS името, което потребителите ще посещават
DNS достъп	Регистратор или DNS доставчик	Необходим за създаване на записа
Текущ TTL	300 секунди	Определя скоростта на propagation и rollback
Каноничен URL на приложението	https://app.example.com	Може да повлияе на redirects и cookies
Health route	/health	Потвърждава работата на услугата преди преминаването

Намалете предварително съществуващия DNS TTL, когато заменяте активен доставчик. Не изтривайте стария запис, преди да са ясни Dockup target-ът, конфигурацията на приложението и rollback планът.

Прегледайте поведението на приложението, което зависи от host-а. Authentication callbacks, CORS allowlists, cookie domains, OAuth redirect URLs, webhook destinations и генерираните абсолютни link-ове може да изискват новия HTTPS hostname.

Как добавяте и проверявате домейна?

Първо изведете списък на текущите домейни:

dockup domain list production/web --json

Добавете hostname-а:

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

Отговорът предоставя DNS target-а, който трябва да бъде конфигуриран. Създайте посочения CNAME запис при DNS доставчика. Не измисляйте IP адрес и не копирайте стойност от друга услуга; използвайте target-а, върнат за този домейн.

След като DNS propagation приключи, проверете домейна с върнатия domain ID:

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

Проверката доказва, че публичният DNS запис се резолвира по необходимия начин. Неуспехът обикновено се дължи на една от четири причини:

1. Името на записа е грешно.
2. CNAME target-ът е грешен.
3. Все още съществува стар конфликтен A, AAAA или CNAME запис.
4. Кешовете на resolver-ите още не са достигнали новата стойност.

Проверете authoritative DNS, вместо многократно да премахвате и създавате домейна отново. Propagation е разпределен cache процес, а не build процес на Dockup.

Как се издава и поддържа HTTPS сертификатът?

След успешна проверка поискайте сертификата:

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

Dockup управлява издаването на сертификат за проверения hostname и обслужва персонализирания домейн през HTTPS. Платформата управлява TLS lifecycle-а, така че application container-ът не трябва да съхранява certificate файлове или да изпълнява renewal процес.

Валидирайте резултата извън платформата:

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

Потвърдете, че:

• Сертификатът съвпада с hostname-а.
• Отговорът се обслужва през HTTPS.
• Redirect-ите не образуват loop.
• Приложението връща очаквания status.
• Authentication и callback flow-овете използват новия origin.
• Static assets се зареждат без mixed-content грешки.

Издаването на сертификат може да се провали дори когато самото приложение работи нормално. Разглеждайте DNS и service diagnostics отделно. Използвайте domain verify за проверка на собствеността чрез DNS, а service логовете — за поведението на приложението.

Статията deployment-и без прекъсване обяснява независимия readiness gate за release.

Как преминавате трафика без прекъсване?

Безопасното преминаване запазва стария път достъпен, докато новият hostname не бъде доказано работещ.

1. Deploy-нете и проверете услугата в Dockup чрез нейния platform URL.
2. Добавете персонализирания домейн в Dockup.
3. Създайте DNS записа.
4. Проверете DNS.
5. Издайте TLS.
6. Тествайте директно HTTPS.
7. Актуализирайте callbacks, canonical URLs и monitoring-а.
8. Насочете малка част от оперативния трафик, ако DNS настройката го позволява.
9. Наблюдавайте логовете и uptime-а.
10. Изключете стария доставчик едва след като новият път работи стабилно.

Dockup uptime проверките се изпълняват всяка минута и отчитат статистика за response time, включително p95:

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

Поддържайте независимо external monitoring за критични домейни. Platform probe потвърждава публичната достъпност, а external monitor проверява user path-а от друга система.

Ако персонализираният домейн заменя текущ production host, запазете rollback запис: предишната DNS стойност, предишния TTL, статуса на стария доставчик и условието, което би задействало връщане назад.

Как работят домейните за допълнителни портове?

Една услуга може да предоставя втори HTTP порт за admin UI, metrics endpoint или друг web процес. Dockup може да създаде допълнителен platform domain без custom DNS:

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

Върнатият domain насочва към избрания container port. Това е отделно от основния персонализиран домейн.

Не отваряйте порт само защото даден процес слуша на него. Преценете дали endpoint-ът има authentication, дали съдържа production данни и дали изобщо трябва да бъде публичен. Internal-only admin интерфейсът не бива да става достъпен от интернет само за удобство.

Премахнете остарелия port domain чрез поддържания domain interface едва след като проверите, че нито един monitor, callback или operator workflow вече не го използва. Промените по port domain-ите са mutations и се записват в audit log-а.

Как отстранявате DNS, TLS и application грешки?

Използвайте диагностика слой по слой:

Симптом	Първа проверка	Dockup команда
Domain не се резолвира	DNS запис и propagation	domain verify
Сертификатът не е издаден	Статусът на domain verification	domain list, domain ssl
HTTPS работи, но приложението дава грешка	Runtime логове	logs --json
Redirect loop	Proxy/host настройките на приложението	env list, runtime логове
Platform URL работи, но custom host не работи	DNS/TLS слой	Domain команди
И двата URL-а не работят	Deployment и runtime	status, build/runtime логове
Вторичният порт не работи	Port-domain mapping и процесът	port list, runtime логове

Проверявайте изхода на услугата, без да го смесвате с DNS изводи:

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

Ако скорошна промяна в environment е добавила canonical URL, не забравяйте, че е необходим redeploy:

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

dockup deploy production/web --wait --json

Ръководството за environment variables и secrets обхваща този lifecycle.

Премахване на домейн и rollback

Премахването на Dockup асоциацията е destructive промяна за route-а, затова първо преместете или премахнете публичния DNS запис и потвърдете планираната замяна. След това премахнете асоциацията чрез поддържания domain interface, като използвате точния domain ID.

Не премахвайте домейна при временен проблем със сертификата или propagation, освен ако recovery планът не го изисква. Запазването на конфигурацията позволява проверката да завърши успешно, когато кешовете се актуализират.

Преглеждайте mutations чрез:

dockup audit --search domains --json

Audit trail-ът трябва да показва кой е добавил, проверил, защитил или премахнал hostname-а.

Checklist за предаване към production

Пълното предаване на персонализиран домейн и автоматичен TLS включва target-а на услугата, hostname-а, domain ID, типа и target-а на DNS записа, резултата от проверката, резултата от издаването на сертификата, промените по application callbacks, monitoring URL-а и rollback DNS стойността.

Не съхранявайте private key на сертификата в repository-то или container-а. Управляваната TLS граница на Dockup съществува именно за да може application екипът да управлява hostname-а, без да разпространява certificate material.

За всички текущи flags използвайте Dockup CLI reference. За първоначалния deployment преди работата по домейна следвайте От Git repository до production.

Планирайте избора между apex и subdomain

Subdomain като app.example.com обикновено е най-лесният application hostname, защото DNS доставчиците могат да го представят чрез CNAME. Apex като example.com може да изисква специфично за доставчика flattening или alias поведение. Следвайте DNS target-а, върнат от Dockup, и възможностите на authoritative DNS доставчика.

Изберете един canonical host и redirect-вайте алтернативите на application или routing layer. Обслужването едновременно на www и apex без canonical policy може да раздели cookies, analytics, cache entries и search indexing.

Тествайте предположенията за certificate renewal

Managed TLS премахва необходимостта да изпълнявате renewal client в container-а, но hostname-ът трябва да продължи да се резолвира коректно. Бъдеща DNS миграция, proxy промяна или изтрит запис могат да прекъснат validation.

Включете domain status в рутинните прегледи:

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

Runbook-ът за персонализиран домейн и автоматичен TLS трябва да посочва DNS owner-а, renewal contact-а и датата на последната external certificate проверка. Това предотвратява откриването на проблема със собствеността едва при certificate incident.

Защитете non-production hostname-ите

Staging и preview hostname-ите могат да разкрият незавършени функции и данни със структура, подобна на production. Използвайте application authentication, когато е необходимо, дефинирайте indexing policy на application layer и ограничете разпространението на non-production URL-ите.

Директивите за search engine не са access control. Защитената среда все още се нуждае от authentication и подходяща обработка на данните.

Проверете отново след propagation

Повторете external HTTPS и callback тестовете, след като изтече целият първоначален DNS TTL.

Започнете с deployment, който може да бъде проверен

Първо прикачете некритичен hostname, запазете platform URL-а по време на propagation и запишете точната DNS стойност, необходима за rollback.

Започнете безплатно в app.dockup.ai. Free планът е $0 на месец, включва начални $10 кредит и поддържа един workspace, три databases и три deployments.

Често задавани въпроси

Какъв DNS запис е необходим за персонализиран домейн в Dockup?

Изпълнете dockup domain add и създайте DNS записа, показан в отговора му. Използвайте върнатия target, вместо да копирате стойност от друга услуга.

Кога Dockup може да издаде TLS за персонализиран домейн?

След като DNS записът на hostname-а премине domain verification в Dockup, поискайте издаване на сертификат с описаната команда domain ssl.

Трябва ли container-ът ми да съхранява TLS сертификати?

Не. Dockup управлява TLS за проверения персонализиран домейн, така че application container-ът не се нуждае от certificate файлове или renewal процес.

Може ли Dockup да отвори допълнителен container порт?

Да. Port командите могат да създадат отделен автоматично генериран domain за допълнителен публичен порт, без да е необходим custom DNS.

Какво трябва да проверя, когато platform URL-ът работи, но custom domain-ът не работи?

Фокусирайте се върху DNS записите, propagation, domain verification и certificate status. Работещият platform URL показва, че application layer-ът вероятно функционира.