Опубликуйте первый Route

Route соединяет публичное доменное имя с приложением через ноду Ingress. В простом случае вам нужно выбрать домен, приложение и порт, включить TLS и сохранить Route. Gateway подготовит конфигурацию nginx и применит её на выбранной ноде Ingress.

Публикация завершена, когда пользователь открывает HTTPS-адрес, получает правильный сертификат и видит нужное приложение. Одного сохранения формы недостаточно: после него обязательно выполните проверку из браузера или curl.

Какие ресурсы участвуют

В публикации участвуют четыре ресурса:

Domain хранит доменное имя и назначенную ноду Ingress.
SSL Certificate обеспечивает TLS и показывает, кто отвечает за продление сертификата.
Route определяет, куда направлять запросы, кто имеет доступ и как проверять состояние приложения.
Целевое приложение получает запрос. Это может быть введённый вручную адрес, Docker-ресурс через Secure Link или развёртывание Pages, выбранное по Tag.

Благодаря этому новую версию приложения можно выпустить без пересоздания DNS и сертификата. Перед публикацией в рабочей среде проверьте все четыре части цепочки.

До создания Route

Убедитесь, что:

нода Ingress находится Online, имеет нужный публичный адрес и может принимать соединения на портах 80 и 443;
приложение запущено и отвечает по выбранному протоколу и порту;
доменное имя подготовлено, а DNS-запись можно изменить;
подходящий сертификат активен или может быть выпущен;
у оператора есть права создать Domain, выбрать сертификат и создать Route;
известны адрес проверки состояния, ожидаемый код ответа, необходимость WebSocket, ограничения запросов и правила доступа.

Если приложение находится в приватной сети, используйте Secure Link. Управляемая нода сама устанавливает защищённое исходящее соединение с Relay, поэтому открывать порт приложения в интернет только ради Ingress не требуется. Secure Link обеспечивает связь, но не запускает остановленное приложение и не исправляет его конфигурацию.

Опубликуйте Route

Откройте Ingress > Domains и добавьте доменное имя.
Назначьте ноду Ingress, которая будет принимать публичный трафик.
Настройте DNS через интеграцию Cloudflare или создайте запись вручную. Дождитесь, пока доменное имя начнёт указывать на публичный адрес ноды Ingress.
Откройте Ingress > SSL Certificates и выпустите, импортируйте или выберите сертификат для точного доменного имени или подходящий wildcard-сертификат.
Откройте Ingress > Routes и выберите Add Route.
Выберите Domain и целевое приложение. Для Docker-ресурса укажите сам ресурс и порт приложения; соединением Secure Link управляет Gateway.
Выберите HTTP или HTTPS в соответствии с тем, как само приложение принимает запросы. Это отдельная настройка от публичного TLS на Route.
Включите публичный TLS и выберите сертификат. Включите Force HTTPS, если запросы по HTTP должны перенаправляться на HTTPS.
Включайте поддержку WebSocket только для приложений, которым она действительно нужна. Access List, ограничение частоты запросов и собственный шаблон nginx добавляйте после того, как базовая публикация уже работает.
Сохраните Route и дождитесь, пока Gateway проверит и применит конфигурацию nginx.

Диалог создания Route с Docker-целью, портом приложения и настройками TLS

Проверьте результат

Пользовательские проверки

Публичный DNS указывает на назначенную ноду Ingress.
HTTPS-ответ содержит доверенный сертификат для нужного доменного имени.
Открывается ожидаемая страница приложения или возвращается ожидаемый ответ API.
HTTP перенаправляется на HTTPS, если включён Force HTTPS.
Вход через браузер, возвраты после аутентификации, потоковые ответы и WebSocket работают, если приложение их использует.

Проверки Gateway

Route включён, а показанное состояние совпадает с прямой проверкой приложения.
В качестве цели указаны нужный ресурс и порт, а не старый контейнер или прежний ручной адрес.
нода Ingress сообщает о корректной применённой конфигурации nginx.
В журналах доступа и ошибок виден тестовый запрос без повторяющихся ошибок соединения с приложением.
Secure Link работает, если Route использует приватную цель.
Access List и ограничения частоты запросов пропускают разрешённых клиентов и отклоняют запрещённых.

Зелёного состояния приложения недостаточно для проверки правил доступа. Если они включены, выполните один разрешённый и один запрещённый запрос. Для WebSocket проверьте полноценное соединение, а не только начальный HTTP-запрос.

Сбои и восстановление

DNS указывает не туда: исправьте DNS-запись и дождитесь обновления кэша. Не меняйте целевое приложение Route, пытаясь компенсировать ошибку DNS.

Сертификат отклоняется: проверьте, покрывает ли он доменное имя, полна ли цепочка доверия, не истёк ли срок и назначен ли сертификат нужной ноде Ingress. Не отключайте проверку TLS в клиенте: это скроет проблему, а не исправит её.

Gateway не применяет конфигурацию nginx: прочитайте сообщение проверки до повторной попытки. Причиной могут быть несовместимый пользовательский шаблон, противоречащие друг другу настройки, повторяющееся доменное имя или недоступная управляемая цель. Исправляйте настройки Route, а не сгенерированные файлы nginx: Gateway перезапишет ручные изменения.

Цель через Secure Link недоступна: проверьте приложение, соответствующую ноду и Relay. Временная публикация порта контейнера в интернет меняет модель безопасности и не должна быть первым способом диагностики.

Опубликована неудачная версия: при необходимости включите режим обслуживания Route или верните цель к последнему рабочему развёртыванию, образу, версии Compose Project или Pages Tag. Для отката приложения обычно не требуется удалять Route и сертификат.

Подробнее о приватных целях см. в разделе Приватные цели через Secure Link. Полный путь от приложения до публичного URL описан в статье Публикация приложения.