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

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

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

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

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

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

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

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

1. Подготовьте ноду хранилища

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

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

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

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

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

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

Учётные данные владельца движка Opfield держит внутри. Reveal credentials показывает отдельного пользователя прямого доступа, и только пока включена публикация TCP; он предназначен для контролируемого внешнего администрирования. Не копируйте эти учётные данные во все приложения.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Карта диагностики

Симптом	Сначала проверьте	Подробная страница
База данных не переходит в статус Ready	Ноду хранилища, предварительную проверку хранилища, версию движка и Task подготовки	Управляемые базы данных
Привязка неработоспособна	Базу данных, обе ноды, Relay, связь привязки и идентичность движка	Привязки баз данных приложений
Приложению отказано в доступе	Параметры подключения, режим TLS и субъект конкретной привязки	Операции с базами данных
Привязка не работает после перезапуска ноды	Свежесть данных ноды и историю согласования	Обновления нод и поведение при отключении
Нужен прямой доступ	Опубликованный TLS-порт и сетевые ограничения	Порты и сетевые пути