Skip to content

Инструкция из личного кабинета Это руководство по сервису из личного кабинета Nubes (ЛК). Текст приведён без изменений, «как есть».

Инструкция по развертыванию 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 при любом количестве узлов и после любых переизбраний.