Skip to content

Resource nubes_mongodb · v2.1.0 · Service ID: 92 · Service Name: MongoDB

Manual · Create params · Modify params · Output params · Operations · Example

Сервис MongoDB (nubes_mongodb). См. Create params для списка параметров.

Справка (MAN)

Инструкция по развертыванию MongoDB через платформу

1. Общая информация

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

Доступные операции с кластером

  • create — создание базы
  • delete — удаление базы данных
  • suspend — остановка базы данных
  • resume — запуск базы данных
  • modify — изменение базы данных
  • create_backup — создание бэкапа вручную
  • delete_backup — удаление бэкапов
  • rollback — восстановление кластера из бэкапа

Доступные операции с пользователями

  • create_user — создание пользователя
  • modify_user — модификация пользователя
  • delete_user — удаление пользователя

2. Параметры создания базы данных

Эти параметры необходимо указать при создании базы данных.

Платформа для развертывания

Среда, в которой будет развёрнут кластер. Выбирается из предложенного списка.

Количество узлов

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

Примечание: уменьшение количества узлов после создания кластера не рекомендуется.

Квота памяти пода (MB)

Объём памяти для одного пода в мегабайтах. Пример: 2048

Квота CPU пода (mCPU)

CPU-квота для пода в миликорах (1000 mCPU = 1 vCPU). Пример: 1000

Размер диска для базы данных (GB)

Объём диска для хранения данных в гигабайтах. Пример: 20

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

Cron-выражение (5 полей), по которому автоматически создаются резервные копии. Пример: 0 0 * * * (каждый день в 00:00)

Хранить последних бэкапов

Сколько последних успешных резервных копий хранить — более старые удаляются автоматически. Пример: 7

Примечание: ротация применяется только к бэкапам, созданным по расписанию. Бэкапы, созданные вручную операцией create_backup, в неё не входят и не удаляются автоматически — их нужно убирать вручную через delete_backup.

Имя ipSpace для публикации внешнего IP

Имя ipSpace, через который будет выделен внешний IP для доступа к master-узлу. Укажите no-needed, если внешний адрес не требуется. Пример: internet-no-antiddos-v1

Список разрешённых IP-адресов

Список IP-адресов или подсетей, с которых разрешён доступ к кластеру. Если оставить пустым — доступ открыт для всех источников. Пример: ["10.0.0.0/24", "192.168.1.10/32"]

Включить TLS

Булевый параметр. Определяет режим работы TLS кластера.

  • true — TLS включён (tls.mode: allowTLS). Сертификаты сохраняются в Vault.
  • false — TLS выключен (tls.mode: disabled).

По умолчанию: false.

3. Параметры модификации базы данных

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

Количество узлов

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

Примечание: уменьшение количества узлов после создания кластера не рекомендуется.

Квота памяти пода (MB)

Объём памяти для одного пода в мегабайтах. Пример: 2048

Квота CPU пода (mCPU)

CPU-квота для пода в миликорах (1000 mCPU = 1 vCPU). Пример: 1000

Размер диска для базы данных (GB)

Объём диска для хранения данных указывается в гигабайтах. Его можно увеличить при необходимости, однако уменьшить уже выделенный размер невозможно. Пример: 20

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

Cron-выражение (5 полей), по которому автоматически создаются резервные копии. Пример: 0 0 * * * (каждый день в 00:00)

Хранить последних бэкапов

Сколько последних успешных резервных копий хранить — более старые удаляются автоматически. Пример: 7

Примечание: ротация применяется только к бэкапам, созданным по расписанию. Бэкапы, созданные вручную операцией create_backup, в неё не входят и не удаляются автоматически — их нужно убирать вручную через delete_backup.

Имя ipSpace для публикации внешнего IP

Имя ipSpace, через который будет выделен внешний IP для доступа к master-узлу. Укажите no-needed, если внешний адрес не требуется. Пример: internet-no-antiddos-v1

Список разрешённых IP-адресов

Список IP-адресов или подсетей, с которых разрешён доступ к кластеру. Если оставить пустым — доступ открыт для всех источников. Пример: ["10.0.0.0/24", "192.168.1.10/32"]

4. Параметры удаления базы данных

Удалить бакет S3 с бэкапами

Булевый параметр.

  • true — вместе с кластером также будут удалены все резервные копии и бакет S3.
  • false — бакет S3 и хранящиеся в нём бэкапы сохраняются после удаления кластера.

По умолчанию: false.

5. Параметры создания бэкапа

Имя бэкапа

Имя резервной копии, которое будет присвоено объекту бэкапа в кластере. Должно соответствовать требованиям Kubernetes к именам объектов (строчные буквы, цифры, дефисы). Пример: manual-20260904

Примечание: такой бэкап не участвует в автоматической ротации по параметру "Хранить последних бэкапов" (она применяется только к бэкапам по расписанию) и не удаляется сам — при необходимости убрать его нужно вручную операцией delete_backup.

6. Параметры восстановления из бэкапа

Имя бэкапа

Имя существующей резервной копии кластера, из которой будет выполнено восстановление. Указывается один из бэкапов в состоянии ready (созданных автоматически по расписанию или вручную через операцию create_backup).

7. Параметры удаления бэкапов

Имена бэкапов

Список имён резервных копий для удаления. Пример: ["manual-20260904", "cron-mongok8s-...-20260903020000"]

8. Параметры создания пользователя

Имя пользователя

Указывается имя пользователя (любой регистр). Пример: readApp

Примечание: имя пользователя должно быть уникальным в рамках кластера. Если пользователь с таким именем уже существует, операция завершится ошибкой — используйте modify_user для изменения прав или delete_user + create_user для пересоздания.

Имя базы данных

Название базы, в которой будет создан пользователь. Если база отсутствует, она будет создана автоматически. Пример: Apps_9392

Имя роли

  • read — доступ только на чтение
  • readWrite — чтение и изменение данных
  • dbOwner — полный контроль над базой данных
  • dbAdmin — администрирование базы данных (индексы, статистика, схема) без доступа к чтению/записи данных

9. Параметры модификации пользователя

Имя пользователя

Необходимо выбрать существующего пользователя. Если список пуст, требуется предварительно создать пользователя.

Имя базы данных

База данных, к которой относится пользователь. Если база отсутствует, она будет создана автоматически. Пример: Apps_9392

Имя роли

  • read
  • readWrite
  • dbOwner
  • dbAdmin

10. Параметры удаления пользователя

Имя пользователя

Выберите пользователя из списка для удаления.

11. Выходные параметры

После успешного развертывания базы данных платформа возвращает ключевые параметры.

internalConnect

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

externalConnect

Внешний FQDN для подключения к кластеру извне. Порт подключения — 27017.

Важно: оба эндпоинта — это Kubernetes Service на весь replset, а не адрес конкретно primary-узла. Kubernetes не отслеживает, кто из узлов сейчас primary, поэтому новое подключение без параметра replicaSet может попасть на secondary и упасть с ошибкой записи not writable primary. Обязательно указывайте replicaSet=rs0 в строке подключения (см. примеры ниже) — тогда драйвер сам обнаружит топологию кластера и всегда направит запись на актуальный primary, независимо от количества реплик и от того, происходили ли выборы.

12. Пример подключения

Перед подключением необходимо установить mongosh.

12.1 Подключение без TLS

Для внутреннего подключения из той же сети:

mongosh "mongodb://<username>:<password>@<endpoint_db>:27017/<dbName>?authSource=admin&replicaSet=rs0"

12.2 Подключение через внешний endpoint с TLS

Кластер требует клиентский TLS-сертификат (mutual TLS). Сертификаты сохраняются в Vault при создании кластера в блоке cer в полях ca, cer, key в кодировке base64.

Подготовка файлов:

# Декодировать сертификаты из Vault
echo "<ca из блока Учётные данные>" | base64 -d > ca.crt
echo "<cer из из блока Учётные данные" | base64 -d > tls.crt
echo "<key из из блока Учётные данные>" | base64 -d > tls.key

# Собрать клиентский PEM
cat tls.key tls.crt > client.pem

Подключение:

mongosh "mongodb://<username>:<password>@<external_endpoint_db>:27017/<dbName>?tls=true&tlsCAFile=ca.crt&tlsCertificateKeyFile=client.pem&authSource=admin&replicaSet=rs0"

Где:

  • <username> — имя пользователя
  • <password> — пароль
  • <endpoint_db> — internalConnect (для подключения без TLS)
  • <external_endpoint_db> — externalConnect (для внешнего подключения с TLS)
  • <dbName> — имя базы данных

13. Дополнительная информация

Режим TLS задаётся параметром mongoConfiguration.tls только при создании кластера. После создания изменение TLS через модификацию не поддерживается.

  • При true кластер разворачивается с включённым TLS (tls.mode: allowTLS). Сервер принимает как обычные, так и TLS-соединения.
  • При false TLS выключен (tls.mode: disabled).

Для внешнего подключения (externalConnect) используется сертификат, выпущенный через cert-manager, с SAN, покрывающим внешний DNS-адрес кластера — поэтому tlsAllowInvalidHostnames не требуется, хост проверяется как обычно.

Внутренние подключения TLS-сертификат не используют вообще: режим allowTLS допускает как TLS, так и обычные соединения, но для внутреннего трафика применяется обычное (не TLS) подключение — см. пример 12.1.

Почему обязателен replicaSet=rs0 в строке подключения

Percona-оператор не проставляет на поды никакого динамического лейбла роли (primary/secondary) — у всех подов replset'а полностью одинаковые лейблы, различается только имя/индекс пода. master-сервис — это обычный Kubernetes Service с фиксированным селектором на весь replset, он не знает и не может знать, какой под сейчас primary: k8s просто раздаёт новые TCP-подключения по кругу между всеми узлами. Без replicaSet=rs0 в URI подключение может закрепиться на secondary, и любая попытка записи будет падать с not writable primary — независимо от того, происходили выборы недавно или нет. Указание replicaSet=rs0 включает у драйвера обнаружение топологии реплики, и он сам направляет запись на актуальный primary при любом количестве узлов и после любых переизбраний.