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

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

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

Решите, подходит ли управляемая база данных

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

До создания данных утвердите:

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

Удаление управляемой базы — разрушительная операция: вместе с экземпляром удаляется управляемый диск, образ или точка монтирования. Удаление подключения или привязки — другое действие. Явно разделите их в правах операторов и инструкциях.

1. Подготовьте ноду баз данных

Зарегистрируйте выделенную ноду баз данных и проверьте предварительную проверку хранилища. Ноды баз данных используют управляемое хранилище фиксированного размера с применением ограничений на уровне хоста. Установщик проверяет локальный Docker Engine и полный цикл loop-устройства: монтирование, запись, рост, изменение размера, размонтирование и отключение, — который используют управляемые экземпляры.

Виртуальная машина или физический хост обычно предоставляет эти возможности напрямую. Для гостевой LXC-системы внешний хост должен явно разрешать loop-устройства и монтирование; при отсутствии нужной границы Gateway не переходит на неограниченный том.

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

2. Создайте приватную базу данных

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

Дождитесь статуса Ready после подготовки и проверок состояния. Проверьте движок, ноду, ёмкость хранилища, состояние TLS и мониторинг. Не продолжайте из состояния созданного или запускающегося экземпляра.

Учётные данные владельца, доступные через Reveal credentials, предназначены для контролируемого администрирования и восстановления. Не копируйте их во все приложения.

3. Создайте привязку приложения

Откройте целевой Container, Deployment или службу Compose Project и создайте управляемую связь с базой. Выберите базу и поддерживаемые переменные или параметры подключения. Gateway создаст отдельную роль PostgreSQL, пользователя Redis ACL или пользователя ClickHouse для этой привязки.

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

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

4. Проверьте из приложения

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

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

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

Гарантии и ограничения

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

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

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

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

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

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

Симптом	Сначала проверьте	Подробная страница
Приложение не подключается	Привязку, Task и журналы приложения	Привязки баз данных
База недоступна	нода баз данных, движок и сетевой путь	Операции с базами
Нужен откат или восстановление	Резервную копию и владельца данных	Резервное копирование