Пользовательский домен и автоматический 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 при замене работающего провайдера. Не удаляйте старую запись, пока не будут известны target Dockup, конфигурация приложения и план отката.
Проверьте поведение приложения, зависящее от host. Для нового HTTPS hostname могут потребоваться изменения в callback-адресах аутентификации, allowlist CORS, доменах cookies, URL OAuth-редиректов, адресатах webhook и генерируемых абсолютных ссылках.
Как добавить и проверить домен?
Сначала выведите список текущих доменов:
dockup domain list production/web --json
Добавьте hostname:
dockup domain add app.example.com production/web --json
В ответе будет указан DNS target, который нужно настроить. Создайте у DNS-провайдера указанную CNAME-запись. Не придумывайте IP-адрес и не копируйте значение другого сервиса — используйте target, возвращённый для этого домена.
После распространения DNS выполните проверку с помощью полученного domain ID:
dockup domain verify <domainId> production/web --json
Проверка подтверждает, что публичная DNS-запись разрешается требуемым образом. Ошибка обычно означает одно из четырёх:
- Неправильно указано имя записи.
- Неправильно указан CNAME target.
- Всё ещё существует старая конфликтующая запись A, AAAA или CNAME.
- Кэши резолверов ещё не обновились.
Проверяйте authoritative DNS, а не удаляйте и не создавайте домен повторно. Распространение DNS — это процесс распределённого кэширования, а не процесс сборки Dockup.
Как выпускается сертификат HTTPS и как он поддерживается?
После успешной проверки запросите сертификат:
dockup domain ssl <domainId> production/web --json
Dockup выполняет выпуск сертификата для проверенного hostname и обслуживает пользовательский домен по HTTPS. Платформа управляет жизненным циклом TLS, поэтому контейнеру приложения не нужно хранить файлы сертификатов или запускать процесс их обновления.
Проверьте результат за пределами платформы:
curl -I https://app.example.com
Убедитесь, что:
- Сертификат соответствует hostname.
- Ответ передаётся по HTTPS.
- Редиректы не зацикливаются.
- Приложение возвращает ожидаемый статус.
- Аутентификация и callback-процессы используют новый origin.
- Статические ресурсы загружаются без ошибок mixed content.
Выпуск сертификата может завершиться ошибкой, даже если само приложение работает корректно. Диагностируйте DNS и сервис отдельно. Используйте domain verify для проверки владения DNS, а логи сервиса — для анализа поведения приложения.
В статье деплои без простоя описана независимая проверка готовности релиза.
Как переключить трафик без простоя?
Безопасное переключение сохраняет старый путь доступным до тех пор, пока новый hostname не будет проверен.
- Разверните и проверьте сервис Dockup по его platform URL.
- Добавьте пользовательский домен в Dockup.
- Создайте DNS-запись.
- Проверьте DNS.
- Выпустите TLS.
- Напрямую проверьте HTTPS.
- Обновите callback-адреса, канонические URL и мониторинг.
- Если настройка DNS это позволяет, направьте небольшую часть рабочего трафика.
- Наблюдайте за логами и доступностью.
- Отключайте старого провайдера только после стабилизации нового пути.
Проверки доступности Dockup выполняются каждую минуту и передают статистику времени ответа, включая p95:
dockup uptime production/web --hours 24 --json
Для критически важных доменов сохраняйте независимый внешний мониторинг. Проверка платформы подтверждает публичную доступность, а внешний мониторинг проверяет пользовательский путь из другой системы.
Если пользовательский домен заменяет текущий 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 аутентификация, содержит ли он production-данные и должен ли он вообще быть публичным. Внутренний admin-интерфейс не должен становиться доступным из интернета просто ради удобства.
Удаляйте устаревший домен порта только после проверки, что его больше не используют мониторинг, callback или рабочий процесс оператора. Изменения доменов портов являются мутациями и отображаются в audit log.
Как устранить неполадки DNS, TLS и приложения?
Используйте послойную диагностику:
| Симптом | Что проверить в первую очередь | Команда Dockup |
|---|---|---|
| Домен не разрешается | DNS-запись и распространение | domain verify |
| Сертификат не выпущен | Статус проверки домена | domain list, domain ssl |
| HTTPS работает, но приложение выдаёт ошибку | Runtime-логи | logs --json |
| Цикл редиректов | Настройки proxy/host приложения | env list, runtime-логи |
| Platform URL работает, пользовательский host — нет | Уровень DNS/TLS | Команды для домена |
| Не работают оба URL | Деплой и runtime | status, build/runtime-логи |
| Не работает дополнительный порт | Сопоставление домена порта и процесс | port list, runtime-логи |
Изучайте вывод сервиса, не смешивая его с выводами о 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 ID.
Не удаляйте домен во время временного сбоя сертификата или распространения DNS, если этого не требует план восстановления. Сохранение конфигурации позволяет успешно пройти проверку после обновления кэшей.
Проверяйте мутации с помощью:
dockup audit --search domains --json
В audit trail должно быть указано, кто добавил, проверил, защитил или удалил hostname.
Чеклист передачи в production
Полный чеклист передачи пользовательского домена и автоматического TLS включает target сервиса, hostname, domain ID, тип и target DNS-записи, результат проверки, результат выпуска сертификата, изменения callback-адресов приложения, URL мониторинга и DNS-значение для отката.
Не храните приватный ключ сертификата в репозитории или контейнере. Граница управляемого TLS в Dockup существует именно для того, чтобы команда приложения могла работать с hostname без распространения материалов сертификата.
Актуальные параметры команд смотрите в справочнике Dockup CLI. Для первоначального деплоя перед настройкой домена следуйте руководству От Git-репозитория до production.
Планируйте apex и subdomain
Subdomain, например app.example.com, обычно является самым простым hostname приложения, поскольку DNS-провайдеры могут представить его в виде CNAME. Apex, например example.com, может потребовать специфичного для провайдера flattening или поведения alias. Следуйте DNS target, возвращённому Dockup, и возможностям authoritative DNS-провайдера.
Выберите один канонический host и перенаправляйте альтернативы на уровне приложения или маршрутизации. Обслуживание одновременно www и apex без канонической политики может разделить cookies, аналитику, записи кэша и поисковую индексацию.
Проверяйте предположения об обновлении сертификата
Управляемый TLS избавляет от необходимости запускать клиент обновления внутри контейнера, но hostname должен по-прежнему корректно разрешаться. Будущая миграция DNS, изменение proxy или удаление записи могут нарушить проверку.
Включайте статус доменов в регулярные проверки:
dockup domain list production/web --json
dockup uptime production/web --hours 24 --json
В runbook для пользовательского домена и автоматического TLS должны быть указаны ответственный за DNS, контакт для продления и дата последней внешней проверки сертификата. Это позволяет не выяснять владельца только после возникновения инцидента с сертификатом.
Защищайте непроизводственные hostname
Staging- и preview-hostname могут раскрывать незавершённые функции и данные, похожие на production. При необходимости используйте аутентификацию приложения, задайте политику индексации на уровне приложения и ограничьте распространение непроизводственных URL.
Директивы для поисковых систем не являются контролем доступа. Защищённому окружению по-прежнему необходимы аутентификация и корректная работа с данными.
Повторно проверяйте после распространения
Повторите внешние проверки HTTPS и callback после полного истечения исходного DNS TTL.
Начните с проверяемого деплоя
Сначала подключите некритичный hostname, сохраняйте platform URL доступным во время распространения DNS и запишите точное DNS-значение, необходимое для отката.
Начните бесплатно на app.dockup.ai. План Free стоит $0 в месяц, включает стартовый кредит $10 и поддерживает один workspace, три базы данных и три деплоя.
FAQ
Какая DNS-запись нужна пользовательскому домену Dockup?
Выполните dockup domain add и создайте DNS-запись, указанную в его ответе. Используйте возвращённый target, а не копируйте значение другого сервиса.
Когда Dockup может выпустить TLS для пользовательского домена?
После того как DNS-запись hostname пройдёт проверку домена Dockup, запросите выпуск сертификата с помощью документированной команды domain ssl.
Нужно ли контейнеру хранить TLS-сертификаты?
Нет. Dockup управляет TLS для проверенного пользовательского домена, поэтому контейнеру приложения не нужны файлы сертификатов или процесс их обновления.
Может ли Dockup открыть дополнительный порт контейнера?
Да. Команды port могут создать отдельный автоматически сгенерированный домен для дополнительного публичного порта без настройки пользовательского DNS.
Что проверить, если platform URL работает, а пользовательский домен — нет?
Сосредоточьтесь на DNS-записях, распространении, проверке домена и статусе сертификата. Работающий platform URL показывает, что уровень приложения, вероятно, функционирует корректно.