Обзор баз данных

Opfield поддерживает два способа работы с базами данных: сохранить подключение к существующей внешней базе или создать управляемый экземпляр на ноде хранилища. Главное различие — зона ответственности. В первом случае базу продолжает обслуживать внешняя команда или платформа. Во втором Opfield создаёт, запускает и изменяет экземпляр, а ваша команда отвечает за данные, резервные копии и восстановление.

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

Управляемые и внешние базы данных: сравнение

Обе модели поддерживают PostgreSQL, Redis и ClickHouse и отображаются в одном списке Databases. В таблице показано, что Opfield создаёт и запускает сам, а к чему только подключается.

Возможность	Управляемая база данных	Внешнее подключение
Кто создаёт и запускает движок	Opfield — как контейнер с хранилищем фиксированного размера на ноде хранилища	Текущий владелец базы, вне Opfield
Версии движка	Проверенный каталог образов PostgreSQL, Redis и ClickHouse, закреплённых по дайджесту	Любые, которые использует владелец
Проверка подключения, состояние и метрики	Да, включая CPU, память, swap и процессы контейнера	Да, состояние и метрики движка
Explorer для схем и данных	PostgreSQL и ClickHouse	PostgreSQL и ClickHouse
Консоль SQL или консоль команд Redis	Да	Да
Расширения PostgreSQL	Включение и отключение расширений, входящих в образ	Нет
Журналы движка	Да	Нет
Pause, Unpause, Restart и повтор неудачного создания	Да	Нет
Изменение CPU, памяти, swap и хранилища	Да; хранилище можно только увеличить	Нет
Настройки движка	Параметры сохранения данных и памяти Redis, XML-конфигурация ClickHouse	Нет
Прямая публикация TCP с собственным TLS	Включается явно, можно изменить позже	Неприменимо
Как Opfield проверяет TLS	Opfield обращается к экземпляру через туннель Relay со взаимной аутентификацией; TLS PostgreSQL дополнительно проверяется по Opfield Database CA	По умолчанию проверяются цепочка сертификатов и имя хоста; можно указать собственный CA или явно отключить проверку. См. Проверка TLS-сертификатов
Учётные данные	Учётные данные владельца Opfield держит внутри; раскрытие и ротация относятся к отдельному пользователю прямого доступа опубликованного экземпляра	Сохранённые параметры подключения, зашифрованные при хранении; раскрываются с правом `databases:credentials:reveal`; раскрытый URI PostgreSQL содержит `sslmode=verify-full`, если проверка включена, и `sslmode=require`, если отключена
Приватные привязки к Containers, Deployments и службам Compose	Да, с отдельной идентичностью движка для каждой привязки	Нет; передавайте параметры подключения как секреты рабочей нагрузки
Обновление версии движка	Версию нельзя изменить на месте; данные переносятся в новый экземпляр	Отвечает владелец
Резервное копирование и восстановление	Штатные резервные копии по расписанию в подключённое хранилище; восстановление в новую управляемую базу или через API в пустую существующую базу	Так же, как для управляемых баз данных
Удаление	Удаляет движок, его хранилище и данные; запрещено, пока есть привязки	Удаляет только сохранённую запись Opfield
Тариф	Personal или выше	Personal или выше

Для Explorer и консоли, помимо databases:view, нужны отдельные права databases:query:read, databases:query:write или databases:query:admin. Opfield относит каждую инструкцию консоли к чтению, записи или администрированию и требует соответствующее право.

Проверка TLS-сертификатов для внешних подключений

Если внешнее подключение использует TLS, Opfield проверяет цепочку сертификатов сервера и то, что сертификат выпущен для указанного хоста. Для новых подключений это поведение по умолчанию. В параметрах подключения:

Verify server certificate включает или отключает проверку для этого подключения. При отключении трафик остаётся зашифрованным, но любой участник сетевого пути может выдать себя за базу данных и перехватить её учётные данные; отключайте проверку только как осознанное исключение.
CA certificate принимает набор сертификатов частного центра сертификации в формате PEM, которому Opfield доверяет вместо общедоступного набора. Принимаются только сертификаты; вставленный закрытый ключ отклоняется.

Прежде чем сохранить новое или изменённое подключение, Opfield проверяет его с новыми параметрами. Если сертификат не удаётся проверить, изменение отклоняется с кодом DATABASE_TLS_VERIFICATION_FAILED (HTTP 422), а сохранённое подключение не меняется. Чтобы отключить проверку или перевести проверяемое подключение на другой CA, нужно заново ввести пароль базы данных: иначе сохранённый пароль мог бы попасть на непроверенный сервер.

Для подключения, использующего TLS без проверки, на странице базы данных показывается предупреждение TLS certificate is not verified. Test and enable verification включает проверку после успешного теста, а Add CA certificate открывает параметры, чтобы добавить частный CA. Подключения PostgreSQL и Redis, использовавшие TLS до 2.11, начинают работу в этом непроверенном состоянии, чтобы после обновления они продолжали подключаться; подключения ClickHouse по HTTPS проверялись и раньше. Резервное копирование баз данных использует тот же параметр.

Модель ресурсов

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

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

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

Приватный доступ по умолчанию

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

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

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

Границы жизненного цикла и эксплуатации

На странице базы данных собраны состояние, метрики, настройки движка, учётные данные, сертификаты, изменение размера, Pause, Unpause, Restart, журналы и доступные функции Explorer или Console. Набор действий зависит от движка, подключения ноды, состояния экземпляра и выданных прав.

Pause сохраняет данные, но намеренно отключает вычисления движка. Пока экземпляр приостановлен, обычные данные о состоянии, метрики, Explorer и Console недоступны. Restart полезен как контролируемая эксплуатационная операция, но не исправляет нерешённые проблемы хранилища, аутентификации или ноды.

Базовая проверка готовности

До передачи базы команде приложения проверьте всю границу ответственности:

Выбранная нода хранилища подключена и сообщает о поддерживаемых возможностях хранилища.
Управляемый экземпляр имеет статус Ready, либо внешний адрес доступен с включённой проверкой TLS-сертификата.
Ответственные за резервные копии, срок хранения и свидетельства восстановления зафиксированы вне самого экземпляра.
Приложение использует идентичность отдельной привязки или другую учётную запись с минимальными правами, а не данные владельца.
Мониторинг собирается без необходимости держать страницу базы открытой.
Контролируемый Restart или повторное подключение подтверждает ожидаемое восстановление клиента.

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

Доступность и ограничения

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

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

Для операторов: приватный транспорт

Рабочая нагрузка обращается к базе данных через общий коннектор защищённых связей своей ноды Docker, в собственной небольшой приватной сети привязки; отдельного контейнера-коннектора для каждой привязки и службы приёма соединений на хосте нет. Opfield согласует связь и идентичность привязки как долговременное желаемое состояние. Транспорт и обновление до 2.11.1 описаны в разделе Привязки баз данных.

Следующие шаги

Создайте и выведите из эксплуатации управляемую базу данных
Создайте приватные привязки приложений
Наблюдайте за операциями с базами данных и восстанавливайте их
Подключите приложение к приватной базе данных от начала до конца
Привяжите базу к Container, Deployment или службе Compose
Спланируйте защиту данных с помощью раздела Обновления, резервные копии и восстановление