Привязки баз данных приложений

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

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

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

Для операторов: транспорт и модель владения

Для каждой привязки целевой Docker-демон управляет TCP-службой приёма соединений в выделенной bridge-сети. Gateway согласует эту службу как часть желаемого состояния привязки. Поэтому приватный адрес остаётся связанным со средой рабочей нагрузки, а не реализуется отдельным процессом для каждой привязки.

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

Коннектор Secure Link между nginx и рабочей нагрузкой — отдельный реальный компонент. Он обслуживает путь Ingress и Relay и не реализует транспорт управляемых привязок баз данных. Диагностируйте состояние службы приёма соединений привязки и готовность базы отдельно от Secure Link, если только записанная операция явно не указывает на проблему Ingress или Relay.

Создайте привязку

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

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

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

Привязка может указывать на подходящий автономный Container, Deployment или службу Compose Project. Gateway передаёт выбранной рабочей нагрузке URI подключения и, если настроено, отдельные значения host, port, database, user и password. Считайте секретом каждое переданное значение, даже если сама служба приёма соединений приватна. Не копируйте URI в исходный код Compose, слои образа, снимки экрана, журналы или конфигурацию среды выполнения Pages.

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

Критерии успешной привязки

После создания или пересоздания рабочей нагрузки проверьте:

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

Раскрытие учётных данных — исключительное диагностическое действие. Оно требует явных прав и соблюдения обычных правил обращения с секретами. Не раскрывайте данные только ради проверки, если реальный запрос приложения и телеметрия дают более безопасное доказательство.

Согласование и обработка сбоев

Желаемое состояние привязки сохраняется после пересоздания рабочей нагрузки, перезапуска Docker-демона, повторного подключения ноды и перезапуска Relay. Согласование восстанавливает принадлежащую демону службу приёма соединений и подтверждает идентичность движка, не создавая новую идентичность для каждой временной среды выполнения. Так обычные перезапуски и пересоздания не оставляют осиротевшие роли.

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

Удаление и восстановление

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

Если удаление прервалось, оставьте долговременную запись привязки и используйте состояние её операции для восстановления. Ручное удаление роли — исключительная процедура, поскольку оно может нарушить следующее согласование. Применяйте его только по явному согласованному плану восстановления.

Для операторов: обновления и совместимость

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

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

Симптом	Сначала проверьте	Следующий безопасный шаг
Привязка не готова	Task, состояние обеих нод и Relay	Дождитесь или повторите поддерживаемое согласование, не создавая второй Container
Приложение получает отказ	Идентичность привязки и конфигурацию приложения	Сверьте права и строку подключения; не используйте учётную запись владельца базы
Привязка пропала после перезапуска	Docker-демон, службу приёма соединений и фактический запрос	Дайте ноде переподключиться и проверьте операции с базами