Власний домен і автоматичний TLS у Dockup
Власний домен і автоматичний TLS у Dockup: додайте DNS-запис, підтвердьте право власності, підключіть HTTPS, відкрийте додаткові порти, перевірте перемикання та безпечно усувайте проблеми.
Налаштування власного домену й автоматичного TLS складається з трьох окремих рівнів: сервіс Dockup має працювати стабільно, DNS має вказувати hostname на платформу, а hostname має пройти перевірку перед випуском сертифіката. Якщо розглядати ці рівні окремо, перемикання стає передбачуваним, а помилки DNS не виглядають як збої застосунку.
Dockup також надає кожному сервісу адресу *.dockup.tech. Зберігайте цю адресу доступною під час поширення DNS-змін, щоб тестувати застосунок незалежно від власного hostname.
Що потрібно підготувати перед додаванням власного домену Dockup?
Почніть із сервісу, який уже працює та проходить перевірку готовності:
dockup status production/web --json
dockup health production/web --json
Відкрийте або перевірте наявну URL-адресу *.dockup.tech. Якщо застосунок не працює за цією адресою, додавання домену не вирішить проблему. Спочатку перевірте runtime-логи.
Зберіть таку інформацію:
| Елемент | Приклад | Чому це важливо |
|---|---|---|
| Точна ціль | production/web | Запобігає підключенню домену до неправильного сервісу |
| Hostname | app.example.com | DNS-ім’я, яке використовуватимуть користувачі |
| Доступ до DNS | Реєстратор або DNS-провайдер | Потрібен для створення запису |
| Поточний TTL | 300 секунд | Визначає швидкість поширення змін і відкату |
| Канонічна URL-адреса застосунку | https://app.example.com | Може впливати на редиректи та cookies |
| Health route | /health | Підтверджує працездатність сервісу перед перемиканням |
Заздалегідь зменште поточний TTL DNS, якщо замінюєте активного провайдера. Не видаляйте старий запис, доки не будуть відомі ціль Dockup, конфігурація застосунку та план відкату.
Перевірте поведінку застосунку, яка залежить від host. Для нового HTTPS hostname можуть знадобитися зміни в authentication callbacks, CORS allowlist, cookie domains, OAuth redirect URLs, адресах webhook-ів і згенерованих абсолютних посиланнях.
Як додати та підтвердити домен?
Спочатку перегляньте поточні домени:
dockup domain list production/web --json
Додайте hostname:
dockup domain add app.example.com production/web --json
У відповіді буде DNS-ціль, яку потрібно налаштувати. Створіть вказаний CNAME-запис у DNS-провайдера. Не вигадуйте IP-адресу й не копіюйте значення з іншого сервісу — використовуйте ціль, яку повернуто саме для цього домену.
Після поширення DNS-змін підтвердьте домен за допомогою повернутого ідентифікатора домену:
dockup domain verify <domainId> production/web --json
Перевірка підтверджує, що публічний DNS-запис резолвиться належним чином. Помилка зазвичай має одну з чотирьох причин:
- Неправильне ім’я запису.
- Неправильна CNAME-ціль.
- Залишився старий конфліктний запис A, AAAA або CNAME.
- Кеші resolver-ів ще не оновилися до нового значення.
Перевіряйте authoritative DNS, а не видаляйте та створюйте домен повторно. Поширення змін — це процес розподіленого кешування, а не процес збірки Dockup.
Як випускається та підтримується сертифікат HTTPS?
Після успішної перевірки замовте сертифікат:
dockup domain ssl <domainId> production/web --json
Dockup обробляє випуск сертифіката для перевіреного hostname і обслуговує власний домен через HTTPS. Платформа керує життєвим циклом TLS, тому контейнеру застосунку не потрібно зберігати файли сертифікатів або запускати процес їх поновлення.
Перевірте результат ззовні платформи:
curl -I https://app.example.com
Переконайтеся, що:
- Сертифікат відповідає hostname.
- Відповідь надходить через HTTPS.
- Редиректи не зациклюються.
- Застосунок повертає очікуваний статус.
- Authentication flows і callback-и використовують новий origin.
- Статичні ресурси завантажуються без помилок mixed content.
Випуск сертифіката може завершитися помилкою, навіть якщо сам застосунок працює належним чином. Розділяйте діагностику DNS і сервісу. Використовуйте domain verify для підтвердження права власності через DNS, а service logs — для перевірки поведінки застосунку.
У статті про розгортання без простою пояснюється незалежна перевірка готовності релізу.
Як перемкнути трафік без простою?
Безпечне перемикання передбачає, що старий маршрут залишається доступним, доки новий hostname не буде перевірено.
- Розгорніть і перевірте сервіс Dockup за його platform URL.
- Додайте власний домен у Dockup.
- Створіть DNS-запис.
- Перевірте DNS.
- Випустіть TLS.
- Напряму перевірте HTTPS.
- Оновіть callbacks, канонічні URL і monitoring.
- Якщо конфігурація DNS це дає змогу, спрямуйте невелику частину робочого трафіку.
- Спостерігайте за логами та доступністю.
- Відмовляйтеся від старого провайдера лише після стабілізації нового маршруту.
Перевірки доступності Dockup виконуються щохвилини та надають статистику часу відповіді, зокрема p95:
dockup uptime production/web --hours 24 --json
Для критичних доменів зберігайте незалежний external monitoring. Перевірка платформи підтверджує публічну доступність, а зовнішній monitor перевіряє шлях користувача з іншої системи.
Якщо власний домен замінює поточний production host, збережіть дані для відкату: попереднє значення DNS, попередній TTL, статус старого провайдера та умову, за якої потрібно виконати відкат.
Як працюють домени для додаткових портів?
Сервіс може відкривати другий HTTP-порт для admin UI, endpoint-а метрик або іншого web-процесу. Dockup може створити додатковий platform domain без власного DNS:
dockup port list production/web --json
dockup port add 8080 production/web --name admin --json
Повернутий домен спрямовує трафік на вибраний порт контейнера. Це окремий маршрут, незалежний від основного власного домену.
Не відкривайте порт лише тому, що процес на ньому слухає. З’ясуйте, чи має endpoint authentication, чи містить production-дані та чи повинен бути публічним узагалі. Внутрішній admin interface не має ставати доступним з інтернету лише задля зручності.
Видаляйте застарілий домен порту через підтримуваний domain interface лише після перевірки, що його більше не використовують monitor, callback або робочий процес оператора. Зміни доменів портів є mutations і відображаються в audit log.
Як усувати проблеми з DNS, TLS і застосунком?
Використовуйте пошарову діагностику:
| Симптом | Що перевірити спочатку | Команда Dockup |
|---|---|---|
| Домен не резолвиться | DNS-запис і поширення змін | domain verify |
| Сертифікат не випущено | Статус перевірки домену | domain list, domain ssl |
| HTTPS працює, але застосунок повертає помилку | Runtime logs | logs --json |
| Циклічний редирект | Налаштування proxy/host у застосунку | env list, runtime logs |
| Platform URL працює, а власний host — ні | Рівень DNS/TLS | Domain commands |
| Не працюють обидві URL-адреси | Deployment і runtime | status, build/runtime logs |
| Не працює додатковий порт | Прив’язка port-domain і процес | port list, runtime logs |
Переглядайте вивід сервісу, не змішуючи його з висновками щодо DNS:
dockup logs production/web --json
dockup status production/web --json
Якщо нещодавня зміна середовища додала канонічну URL-адресу, пам’ятайте, що для неї потрібен redeploy:
dockup env set APP_URL=https://app.example.com \
-s production/web \
--json
dockup deploy production/web --wait --json
У посібнику зі змінних середовища та секретів описано цей життєвий цикл.
Видалення домену та відкат
Видалення прив’язки Dockup є руйнівною операцією для маршруту, тому спочатку перемістіть або видаліть публічний DNS-запис і підтвердьте заплановану заміну. Потім видаліть прив’язку через підтримуваний domain interface, використовуючи точний ідентифікатор домену.
Не видаляйте домен під час тимчасової проблеми із сертифікатом або поширенням DNS, якщо цього не вимагає план відновлення. Збережена конфігурація дасть змогу успішно пройти перевірку після оновлення кешів.
Переглядайте mutations за допомогою:
dockup audit --search domains --json
В audit trail має бути видно, хто додав, підтвердив, захистив або видалив hostname.
Чекліст передачі в production
Повна передача власного домену й автоматичного TLS має містити ціль сервісу, hostname, ідентифікатор домену, тип і ціль DNS-запису, результат перевірки, результат випуску сертифіката, зміни application callback-ів, URL моніторингу та значення DNS для відкату.
Не зберігайте приватний ключ сертифіката в repository або контейнері. Керована TLS-границя Dockup існує саме для того, щоб команда застосунку могла працювати з hostname без поширення матеріалів сертифіката.
Щоб дізнатися про всі поточні flags, скористайтеся довідником Dockup CLI. Щоб виконати початкове розгортання перед роботою з доменом, дотримуйтеся інструкцій у статті Від Git repository до production.
Планування apex і subdomain
Subdomain на кшталт app.example.com зазвичай є найпростішим hostname для застосунку, оскільки DNS-провайдери можуть представити його за допомогою CNAME. Apex на кшталт example.com може вимагати специфічної для провайдера flattening- або alias-поведінки. Дотримуйтеся DNS-цілі, яку повертає Dockup, і можливостей authoritative DNS-провайдера.
Оберіть один canonical host і налаштуйте redirect альтернатив на рівні застосунку або routing. Обслуговування одночасно www та apex без canonical policy може розділити cookies, аналітику, cache entries і пошукове індексування.
Перевірка припущень щодо поновлення сертифіката
Керований TLS усуває потребу запускати renewal client у контейнері, але hostname має й надалі коректно резолвитися. Майбутня міграція DNS, зміна proxy або видалений запис можуть зламати валідацію.
Додавайте статус доменів до регулярних перевірок:
dockup domain list production/web --json
dockup uptime production/web --hours 24 --json
У runbook для власного домену й автоматичного TLS потрібно вказати відповідального за DNS, контакт для питань поновлення та дату останньої зовнішньої перевірки сертифіката. Це допоможе не з’ясовувати відповідальних лише під час інциденту із сертифікатом.
Захист non-production hostname
Staging- і preview-hostname можуть розкривати незавершені функції та дані, схожі на production. За потреби використовуйте authentication на рівні застосунку, визначте policy індексації на рівні застосунку та обмежте поширення non-production URL.
Директиви для пошукових систем не є access control. Захищене середовище все одно потребує authentication і належного поводження з даними.
Повторна перевірка після поширення змін
Повторіть зовнішні HTTPS- і callback-тести після повного завершення початкового DNS TTL.
Почніть із deployment, який можна перевірити
Спочатку підключіть некритичний hostname, збережіть platform URL на час поширення DNS-змін і зафіксуйте точне значення DNS, потрібне для відкату.
Почніть безкоштовно на app.dockup.ai. План Free коштує $0 на місяць, включає початковий кредит $10 і підтримує один workspace, три databases та три deployments.
FAQ
Який DNS-запис потрібен власному домену Dockup?
Виконайте dockup domain add і створіть DNS-запис, указаний у відповіді команди. Використовуйте повернуту ціль, а не копіюйте значення з іншого сервісу.
Коли Dockup може випустити TLS для власного домену?
Після того як DNS-запис hostname пройде перевірку домену в Dockup, замовте випуск сертифіката за допомогою задокументованої команди domain ssl.
Чи потрібно контейнеру зберігати TLS-сертифікати?
Ні. Dockup керує TLS для перевіреного власного домену, тому контейнеру застосунку не потрібні файли сертифіката або процес поновлення.
Чи може Dockup відкрити додатковий порт контейнера?
Так. Команди port можуть створити окремий автоматично згенерований домен для додаткового публічного порту без потреби у власному DNS.
Що перевірити, якщо platform URL працює, а власний домен — ні?
Зосередьтеся на DNS-записах, поширенні змін, перевірці домену та статусі сертифіката. Справна platform URL свідчить, що рівень застосунку, імовірно, працює.