Приватные целевые службы

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

Используйте эту модель, если приложение должно быть публично доступно только через Ingress Gateway. Владелец приложения по-прежнему отвечает за его аутентификацию и состояние, а владелец платформы — за выбор Route, подключение нод и Relay и восстановление пути. Настройка успешна, когда у нагрузки нет ненужного публичного порта, Secure Link готов и реальный запрос проходит через каноническое имя хоста.

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

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

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

Не обходите отказ связи публикацией внутреннего порта рабочей нагрузки, пока не определили причину. Сначала проверьте состояние Relay, подключения обеих нод, идентичность цели, права области доступа и журналы коннектора.

Предварительные условия

• ноды Ingress и Docker подключены и совместимы с текущим контрактом Relay.
• Целевой Container, Deployment или служба Compose принадлежит Gateway и имеет стабильную идентичность ресурса.
• Выбран порт, на котором приложение действительно принимает соединения, а не посторонний опубликованный порт хоста.
• Пользователь может просматривать целевой ресурс и изменять Route.
• Relay работоспособен, и обе ноды имеют доступ к назначенному адресу Relay.

Создайте управляемую целевую службу

1. Откройте редактор Route или Additional Route.
2. Выберите тип управляемой Docker-цели.
3. Выберите ноду и ресурс вместо ввода временного адреса Container.
4. Выберите службу или порт приложения и протокол.
5. Сохраните Route и дождитесь согласования Secure Link и валидации конфигурации nginx.
6. Проверьте индикатор цели, телеметрию Link Runtime, состояние Route и внешний запрос.

Container коннектора для трафика от nginx к рабочей нагрузке принадлежит Gateway. Он скрыт от обычных операций жизненного цикла и освобождается вместе с Relay. Пересоздание рабочей нагрузки приложения не должно передавать владение коннектором или требовать создания нового Route.

Поведение жизненного цикла

• Перезапуск или пересоздание рабочей нагрузки сохраняет связь, потому что Route указывает на стабильный ресурс Gateway.
• Продвижение Deployment обновляет активную рабочую нагрузку за той же идентичностью Deployment.
• Применение Compose выбирает указанную службу из активной ревизии проекта.
• Отключение Route прекращает его обслуживание, но сохраняет конфигурацию и принадлежащую ему связь.
• Удаление Route после согласования выводит принадлежащую ему привязку из эксплуатации.
• Дополнительная пользовательская привязка имеет независимый жизненный цикл и удаляется явно.

Диагностика сбоев

Если Route сохраняется, но трафик не проходит, проверяйте сигнал по уровням в таком порядке:

1. на странице Route убедитесь, что он включён и не находится в режиме обслуживания;
2. проверьте, что последняя ревизия конфигурации nginx применена;
3. проверьте доступность Relay;
4. убедитесь, что ноды Ingress и Docker подключены;
5. проверьте фактическое состояние целевого ресурса и выбранный порт;
6. откройте состояние коннектора Secure Link, ошибки допуска и последнюю Task;
7. сопоставьте журналы приложения с поведением протокола.

Публикуйте порт хоста только тогда, когда публичный или прямой доступ сам по себе является требованием продукта, а не как недокументированный способ восстановления.

Последствия для безопасности и владения

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

Созданный коннектор и его учётные данные принадлежат Gateway. Операторы не должны пересоздавать, переименовывать, подключать или использовать этот коннектор через обычные API жизненного цикла Docker. Доступ к ресурсу рабочей нагрузки не передаёт владение транспортным ресурсом. Такое разделение не позволяет оператору нагрузки подменить образ коннектора или прочитать транспортные данные контура управления.

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

Процедура изменения и восстановления

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

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