Secure Links

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

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

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

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

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

Привязки баз данных

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

Целевой Docker-демон отвечает за TCP-службу приёма соединений в выделенной приватной bridge-сети и согласует её как часть желаемого состояния привязки. Отдельного Container-коннектора базы данных для каждой привязки не существует, поэтому перезапускать, проверять или заменять такой Container не нужно. Служба приёма соединений и идентичность движка хранятся отдельно, но изменяются согласованно: ротация учётных данных, изменение прав или удаление одной рабочей нагрузки не должны незаметно затронуть другую привязку.

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

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

Связи Ingress с целевыми службами

Routes и Additional Routes могут направлять трафик к поддерживаемым Docker-ресурсам через Secure Link. Gateway проверяет выбранный ресурс и порт приложения, создаёт связь и согласует принадлежащий Gateway коннектор через Relay. Коннектор для трафика от nginx к рабочей нагрузке — реальный компонент среды выполнения, но он недоступен через обычные пользовательские API жизненного цикла.

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

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

Обычный процесс и проверка

Для целевой службы Ingress откройте редактор Route или Additional Route, выберите управляемый ресурс, службу или порт приложения и протокол. Сохраните изменения и дождитесь согласования Secure Link и успешной валидации конфигурации nginx. Затем проверьте идентичность цели, состояние коннектора, состояние Route и выполните реальный внешний запрос.

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

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

Что Secure Links не делают

• Это не универсальный VPN и не overlay-сеть.
• Они не обеспечивают произвольную переадресацию TCP или SSH.
• Они не открывают межсетевые экраны хостов автоматически.
• Они не отменяют аутентификацию на уровне приложения, если её требует протокол целевой системы.

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

Сбой и безопасное восстановление

Если Ingress Route сохраняется, но трафик не проходит, используйте сам запрос как сигнал и проверяйте уровни по порядку: Route включён и не находится в режиме обслуживания, последняя ревизия nginx применена, Relay доступен, ноды Ingress и Docker подключены, целевая среда выполнения и выбранный порт работоспособны, а допуск коннектора не завершился ошибкой. Затем сопоставьте Task и состояние Link Runtime с журналами приложения и поведением протокола. Не публикуйте внутренний порт рабочей нагрузки как недокументированный обход.

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