MongoDB в Docker: быстро и безопасно

Быстрые ссылки

• Запуск контейнера MongoDB
• Подключение из другого контейнера
• Сохранение данных с помощью томов
• Добавление аутентификации
• Настройка сервера
• Безопасность и бэкап
• Заключение

MongoDB — документоориентированная NoSQL СУБД с хранением в формате, похожем на JSON. Для разработчиков она часто обеспечивает более прямое отображение между кодом и хранимыми данными, что ускоряет итерации и уменьшает несовпадение структуры данных, присущее классическим SQL-системам.

Docker упаковывает приложение и зависимости в контейнеры. Контейнеризация MongoDB делает её переносимой: вы можете запускать ту же конфигурацию в разных окружениях, где доступен Docker.

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

Запуск контейнера MongoDB

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

docker run -d -p 27017:27017 --name example-mongo mongo:latest

Эта команда запустит сервер MongoDB последней версии из официального образа на Docker Hub. Флаг -d (detach) запускает контейнер в фоновом режиме.

Контейнер слушает порт 27017 по умолчанию. Флаг -p 27017:27017 пробрасывает этот порт на хост, поэтому обращаться можно по адресу localhost:27017. Чтобы использовать другой порт на хосте, измените левую часть -p, например 9000:27017 для localhost:9000.

Образ содержит клиентскую оболочку mongo. Чтобы запустить её внутри контейнера используйте:

docker exec -it example-mongo mongo

Это откроет интерактивную Mongo shell-сессию в вашем терминале — удобно для быстрых проверок.

Логи контейнера можно просмотреть и постоянно отслеживать:

docker logs example-mongo --follow

Флаг --follow выводит новые сообщения в реальном времени.

Подключение из другого контейнера

Если ваше приложение в Docker, стоит подключать его к Mongo внутри приватной сети Docker вместо проброса портов на хост. Так вы уменьшаете поверхность атаки.

Создайте сеть и подключите в неё базы и клиенты:

docker network create mongo-network

docker run -d --network mongo-network --name example-mongo mongo:latest

Контейнер-клиент также подключается к mongo-network и обращается к базе по имени контейнера, например example-mongo:27017.

Сохранение данных с помощью томов

Для реального использования обязательно применяйте Docker тома. Tom сохраняет файлы вне контейнера, поэтому при перезапуске или замене контейнера данные сохранятся.

Официальный образ MongoDB хранит данные в каталоге /data/db. Смонтируйте том в это место:

docker run -d -p 27017:27017 --name example-mongo -v mongo-data:/data/db mongo:latest

Эта команда создаст Docker том mongo-data и подключит его к /data/db в контейнере. Посмотреть тома можно командой docker volume ls.

Пример простых операций внутри Mongo:

use test-db

db.demos.save({foo: "bar"})

Перезапустите контейнер:

docker restart example-mongo

Данные сохранятся, так как том снова примонтирован. Можно удалить контейнер и запустить новый с тем же томом — Mongo пропустит инициализацию, если данные уже есть.

Томы удаляются явно командой docker volume rm или при удалении контейнера с флагом --volumes:

docker rm example-mongo --volumes

Добавление аутентификации

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

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

docker run -d -p 27017:27017 --name example-mongo -v mongo-data:/data/db -e MONGODB_INITDB_ROOT_USERNAME=example-user -e MONGODB_INITDB_ROOT_PASSWORD=example-pass mongo:latest

Пользователь example-user получит роль root в базе admin.

Хранить пароль в виде строки окружения небезопасно. Лучше передать пароль через файл:

docker run -d -p 27017:27017 --name example-mongo -v mongo-data:/data/db -e MONGODB_INITDB_ROOT_USERNAME=example-user -e MONGODB_INITDB_ROOT_PASSWORD_FILE=/run/secrets/mongo-root-pw mongo:latest

При суффиксе _FILE Mongo читает содержимое файла. Файл можно смонтировать с хоста или использовать Docker Secrets. Тогда пароль не виден в выводе docker inspect.

Настройка сервера

Самый простой способ изменить поведение mongod — передать флаги командной строки. Образ пропускает аргументы docker run дальше в mongod.

Пример смены порта:

docker run -d --name example-mongo -v mongo-data:/data/db mongo:latest --port 9000

Чтобы использовать конфигурационный файл, смонтируйте его и укажите путь через --config:

docker run -d --name example-mongo -v mongo-data:/data/db -v ./mongo.conf:/etc/mongo/mongo.conf mongo:latest --config /etc/mongo/mongo.conf

Mongo не читает конфиг автоматически по произвольному пути — нужно явно указать --config.

Механизм инициализации: любые файлы .sh и .js, помещённые в /docker-entrypoint-initdb.d, выполнятся в алфавитном порядке при первом запуске контейнера. Файлы .js выполняются как Mongo-скрипты против базы test по умолчанию. Чтобы изменить целевую базу, задайте MONGODB_INITDB_DATABASE.

Docker Compose: пример для разработки

Использование docker-compose упрощает запуск нескольких контейнеров и сетей:

version: '3.8'
services:
  mongo:
    image: mongo:5.0
    container_name: example-mongo
    volumes:
      - mongo-data:/data/db
      - ./mongo-init/:/docker-entrypoint-initdb.d/
    environment:
      MONGODB_INITDB_ROOT_USERNAME: example-user
      MONGODB_INITDB_ROOT_PASSWORD_FILE: /run/secrets/mongo-root-pw
    secrets:
      - mongo-root-pw
    restart: unless-stopped

  api:
    build: ./api
    depends_on:
      - mongo
    networks:
      - app-net

volumes:
  mongo-data:

secrets:
  mongo-root-pw:
    file: ./secrets/mongo-root-pw.txt

networks:
  app-net:
    driver: bridge

Этот пример демонстрирует: том для данных, каталог инициализации, использование Docker Secrets для пароля и простую сеть.

Резервное копирование и восстановление (SOP)

Краткий план бэкапа и восстановления:

1. Снимите снапшот тома (рекомендуется использовать средства хоста или CSI-плагин для кластеров).
2. Альтернатива — дамп через mongodump:

docker exec example-mongo sh -c 'mongodump --archive=/data/db/dump.archive --gzip'

docker cp example-mongo:/data/db/dump.archive ./dump-$(date +%F).archive

3. Для восстановления используйте mongorestore:

docker cp ./dump-2021-01-01.archive example-mongo:/data/db/dump.archive

docker exec example-mongo sh -c 'mongorestore --archive=/data/db/dump.archive --gzip'

Критерии приёмки бэкапа:

• Дамп успешно создаётся и копируется на внешний носитель.
• Процесс восстановления восстанавливает коллекции и документы без ошибок.
• Тестовые запросы возвращают ожидаемые данные.

Инцидентный план (короткая версия):

• Если контейнер недоступен, проверьте логи docker logs и состояние docker ps.
• Если данные повреждены, восстановите последнюю проверенную резервную копию в тестовом контейнере и прогоните тесты перед промоушеном в прод.
• При нехватке места проверьте размер тома и очистите старые дампы.

Безопасность и жёсткие настройки

Рекомендации для production:

• Не использовать тег latest. Указывайте конкретную версию, например mongo:5.0.
• Использовать Docker Secrets вместо переменных окружения для чувствительных данных.
• Закрыть доступ к портам из внешних сетей. Используйте внутренние Docker-сети или сетевые политики (firewall, cloud security groups).
• Включить авторизацию и создавать пользователей с минимально необходимыми ролями.
• Включить шифрование трафика (TLS) для репликации и клиентских подключений.
• Включить шифрование данных в отдыхе на уровне файловой системы или через поставщика томов, если требуется.
• Логи и метрики направлять внешне (ELK, Prometheus) для аудита и мониторинга.

Пример: запуск Mongo с TLS требует наличия сертификатов. Смонтируйте каталог с сертификатами в контейнер и добавьте флаги --sslMode, --sslPEMKeyFile и другие опции в конфиг или командную строку.

Сравнение типов томов

Выбор зависит от окружения: для локальной разработки подойдет именованный том; в продакшне — провайдерский том с поддержкой снапшотов.

Когда запуск в Docker не подходит

• Если вам нужна нативная высокая доступность с управляемой репликацией и резервированием из коробки на уровне провайдера, возможно лучшим решением будет управляемый сервис (см. альтернативы).
• Для очень тяжёлых нагрузок на диск и IO возможно выгоднее запускать Mongo напрямую на апаратуре с настроенным SSD и RAID.
• Если ваша организация требует сертифицированных платформ с определёнными SLA, Docker в чистом виде может потребовать дополнительных слоёв управления.

Альтернативные подходы

• Управляемые сервисы: MongoDB Atlas, облачные managed-сервисы от AWS/Google/Azure. Плюсы: автоматические бэкапы, обновления, мониторинг и SLA. Минусы: стоимость и возможные ограничения на настройки.
• Виртуальные машины: запуск Mongo на VM даёт больше контроля над окружением, но требует администрирования.
• Kubernetes: для масштабируемых кластеров используйте StatefulSet с контроллерами томов и операторами MongoDB.

Ментальные модели и эвристики

• Контейнер = единица развертывания и изоляции, но не долговременного хранения. Для хранения используйте внешние тома.
• Отделяйте конфигурацию (файлы, secrets) от образа: образ должен быть воспроизводимым и минимальным.
• Пробрасывайте порты только там, где это необходимо; внутри инфраструктуры используйте приватные сети.

Минимальный чек-лист для ролей

Разработчик:

• Убедиться, что версия образа зафиксирована.
• Добавить инициализационные скрипты в /docker-entrypoint-initdb.d.
• Тестировать с локальным томом.

Операции/инфраструктура:

• Настроить мониторинг и резервное копирование томов.
• Обеспечить сеть и firewall для контейнеров.
• Настроить секреты и управление ими.

Информационная безопасность:

• Проверить права пользователей и роли в Mongo.
• Включить TLS и аудит.
• Проводить регулярные проверки уязвимостей образов.

Тесты и критерии приёмки

Тесты для проверки окружения:

• Запуск контейнера с указанной версией образа.
• Создание, чтение, обновление и удаление документов (CRUD) в тестовой коллекции.
• Перезапуск контейнера и проверка сохранности данных.
• Восстановление дампа в тестовом окружении.

Критерии приёмки:

• Все CRUD-операции выполняются успешно.
• После перезапуска данные остаются.
• Бэкап создаётся и восстанавливается без ошибок.

Примеры полезных сниппетов

Мониторинг размера тома (на хосте Linux):

docker run --rm -v mongo-data:/data alpine du -sh /data

Простой скрипт бэкапа с mongodump (демонстрационный):

#!/bin/bash
CONTAINER=example-mongo
BACKUP_PATH=./backups
mkdir -p "$BACKUP_PATH"
FNAME="$BACKUP_PATH/mongo-$(date +%F-%H%M).archive"
docker exec "$CONTAINER" sh -c 'mongodump --archive=/tmp/dump.archive --gzip'
docker cp "$CONTAINER":/tmp/dump.archive "$FNAME"
echo "Backup saved to $FNAME"

Заключение

Запуск MongoDB в Docker — удобный способ обеспечить портируемость и изоляцию для разработки и для многих продакшн-сценариев. Всегда используйте монтируемые тома для сохранения данных, вводите авторизацию и секреты для безопасности, фиксируйте версии образов и внедряйте регулярные бэкапы и мониторинг. Для крупных распределённых кластеров и строгих SLA рассмотрите управляемые сервисы или Kubernetes-операторы.

Факты и ключевые значения:

• Порт по умолчанию: 27017
• Каталог данных в образе: /data/db
• Примеры поддерживаемых версий: 4.4, 5.0 (тег latest указывает на текущий релиз)

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

Часто задаваемые вопросы

Нужно ли использовать latest для образа Mongo?

Нет. Тег latest может указывать на мажорное обновление, которое ломает совместимость. Для стабильности указывайте конкретную версию, например mongo:5.0.

Как безопасно передать пароль в контейнер?

Используйте Docker Secrets или монтируйте файл и передавайте переменную с суффиксом _FILE, чтобы Mongo прочитал пароль из файла.

Подходит ли Docker для продакшна?

Да, при правильной архитектуре: зафиксированные версии, тома с бэкапами, TLS, мониторинг и управление секретами. Для сложных кластеров рассмотрите Kubernetes или управляемые сервисы.