Последнее обновление: 3 февраля 2017 г.

MongoDB Atlas, запущенный 28 июня 2016 года, представляет собой платформу база данных как услуга, созданную той же командой, которая создает MongoDB.

Здесь, в ОК РАСТИ! мы полагались на mLab и Compose для размещения наших баз данных.

С приветственным обновлением драйвера Meteor mongodb в выпуске Meteor 1.4 (25 июля 2016 г.). Теперь Meteor по умолчанию поставляет Mongo 3.2 вместе с WiredTiger Storage Engine MongoDB.

Когда мы рассмотрели возможность перехода с MMAPv1 на WiredTiger (в mLab и compose), мы были удивлены, увидев значительное увеличение стоимости. Мы решили изучить наиболее экономичную платформу база данных как услуга для Mongo 3.2+ с помощью WiredTiger.

Стоимость хостинга:

Примечание. Стоимость оценивалась на момент написания.

Атлас MongoDB:

  • MMAPv1: у MongoDB Atlas нет планов MMAPv1, Atlas поддерживает только механизм хранения WiredTiger.
  • WiredTiger: минимальное развертывание (инстанс M10, 2 ГБ ОЗУ, 10 ГБ хранилища, 3 узла передачи данных) стоит около 56,94 долларов США в месяц. Автоматическое резервное копирование увеличит ваши расходы, но вы получаете свой первый 1 ГБ на набор реплик бесплатно, а затем 2,50 доллара США за ГБ в месяц.

Compose.io:

  • MMAPv1: самый дешевый вариант начинается с $31 в месяц с (102 МБ ОЗУ, 1 ГБ для хранения). Масштабирование стоит 18 долларов США за блок хранилища объемом 1 ГБ, который поставляется с дополнительными 102 МБ ОЗУ.
  • WiredTiger: самый дешевый вариант начинается от $133 в месяц с 1 ГБ ОЗУ, 4 ГБ хранилища, 3 узлами передачи данных (1 узел скрыт и используется только для резервного копирования). Каждый дополнительный гигабайт хранилища включает 256 МБ ОЗУ и стоит 30 долларов США за масштабирование.

мЛаб:

  • MMAPv1: предлагает вариант бесплатной песочницы с одним узлом (общая память, 0,5 ГБ хранилища, без доступа к oplog).
  • WiredTiger: на момент написания не все планы mLab поддерживают WiredTiger. В настоящее время их самым дешевым производственным вариантом является Standard Line: M3 Cluster (7,5 ГБ ОЗУ, 120 ГБ хранилища, 2 узла передачи данных с 1 узлом-арбитром) по цене 720 долларов в месяц.

ПРИМЕЧАНИЕ. mLab предлагает WiredTiger за 420 долларов США в месяц на одном узле M3 (7,5 ГБ, 120 ГБ для хранения), но они подходят только для сред разработки/тестирования/постановки. Не используйте этот план для производственных развертываний.

Наши выводы:

MongoDB Atlas в настоящее время (на момент написания) является самой дешевой и наиболее привлекательной базой данных как услугой для размещения WiredTiger с Mongo 3.2+. Подробное сравнение можно найти здесь.

Это дало идеальную возможность оценить MongoDB Atlas для использования с веб-приложением Meteor 1.4+, размещенным на Meteor Galaxy.

Далее следует пошаговое руководство по началу работы с MongoDB Atlas и подключению вашего приложения Meteor (размещенного на Meteor Galaxy) к размещенной MongoDB с оплогом.

Шаг 1. Зарегистрируйтесь в Atlas

Зарегистрируйтесь для учетной записи MongoDB Atlas, заполнив свой профиль. Не волнуйтесь; процесс регистрации относительно быстрый и безболезненный.

Шаг 2: Создайте свою первую группу Atlas

Создайте имя для своей группы MongoDb Atlas. Обратите внимание на имя, которое вы установили. Вы не можете изменить имя или удалить исходную группу Atlas, которую вы создали при регистрации.

Ознакомьтесь с Что такое Atlas Group? вВопросах и ответах ниже.

Перед развертыванием первого кластера рекомендуется настроить двухфакторную аутентификацию (2FA). Вы можете найти опцию 2FA в разделе «Настройки» -> «Учетная запись».

Шаг 3: Создайте свой первый кластер

Шаг 3.1: Имя кластера

Назовите свой первый кластер. Будьте осторожны: вы не можете переименовать это!

Шаг 3.2. Регион AWS

Затем выберите свой регион AWS:

  • Если при развертывании Galaxy в Северной Америке выберите us-east-1 (Северная Вирджиния), это регион Galaxy по умолчанию.
  • При развертывании для Galaxy в Европе выберите eu-west-1 (Ирландия).

Проверьте, какие регионы поддерживаются? в вопросах и ответах ниже.

Шаг 3.3: Размер экземпляра

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

На этом этапе вы также можете выбрать шифрование томов хранилища в базе данных. Это решение остается за вами, поскольку это компромисс между производительностью и безопасностью.

Любые конфиденциальные данные, которые вы храните в своей базе данных (например, пароли), должны быть уже зашифрованы перед сохранением в вашей базе данных. Конфиденциальные данные никогда не должны храниться в незашифрованном виде (например, в виде простого текста) в вашей базе данных.

Шаг 3.4: Фактор репликации.

MongoDB Atlas заставляет вас использовать наборы реплик. Это на самом деле хорошо! Наборы реплик — это основа для обеспечения высокой доступности и избыточности в производственной среде. Это также отлично подходит для развертывания Meteor, поскольку нам не нужно выполнять дополнительную настройку, чтобы включить отслеживание оплогов Meteor.

Теперь выберите из 3, 5 или 7 узлов. Вы должны выбрать число, которое наилучшим образом соответствует требованиям вашего приложения и допускает избыточность.

Шаг 3.5: Вам нужен сегментированный кластер?

Далее: Sharding — убедитесь, что это отключено (включайте, только если вы знаете и уверены в том, что делаете).

Ознакомьтесь с разделом Что такое сегментирование? в вопросах и ответах ниже.

Шаг 3.6: Вы хотите включить резервное копирование?

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

Шаг 3.7: Имя пользователя и пароль администратора

Установите имя пользователя и пароль кластера.

  • Atlas предоставляет удобный генератор паролей. Используй это!
  • Обязательно запишите пароль в надежном месте, его невозможно будет восстановить, если вы его потеряете.
  • Важное предостережение: установка «Имени пользователя и пароля администратора» кластера доступна только при создании первого кластера в вашей группе. Важно отметить, что этот пользователь является администратором группы Atlas по умолчанию.

Шаг 3.8: Подтвердить и развернуть

Когда вы довольны настройками своего кластера, нажмите «Подтвердить и развернуть». Ваш кластер сейчас развертывается, это может занять до 8 минут.

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

Шаг 5. Безопасность — белый список IP-адресов и пиринг.

Чтобы подключиться к вашей базе данных в Atlas, вы должны создать белый список IP-адресов или диапазонов в нотации CIDR, или, если вы развернуты на AWS, вы можете использовать AWS VPC Peering.

Галактика Метеор

При развертывании с помощью Galaxy вам потребуется указать IP-адреса региона, в котором выполняется развертывание. На момент написания статьи Галактика имеет два скопления us-east-1 и eu-west-1.

IP-адреса этих кластеров можно найти здесь, в документации Galaxy. Вы должны добавить все IP-адреса в свой белый список на Atlas для региона, в котором развернуто ваше приложение Meteor (us-east-1 или/и eu-west-1).

Пользовательское развертывание

Если вы развертываете свое приложение Meteor на хостинге, который не имеет статических IP-адресов для поддержки белого списка IP-адресов, вам нужно будет внести в белый список все IP-адреса. Вы можете внести в белый список все IP-адреса с этим диапазоном: `0.0.0.0/0`. Узнать больше можно здесь.

Обратите внимание, что при добавлении всех IP-адресов в белый список ваша база данных не станет небезопасной по своей сути (Atlas требует, чтобы все соединения аутентифицировались). Белый список IP-адресов в основном делается для снижения подверженности базы данных DDoS-атаке.

Пиринг виртуальных частных клиентов AWS

Если вы развертываете приложение Meteor непосредственно на AWS, MongoDB Atlas поддерживает пиринг AWS VPC. Ознакомьтесь с их подробным руководством по настройке пиринга здесь.

Шаг 6: Безопасность — Пользователи.

Нам нужно создать как минимум двух пользователей. «Пользователь Meteor», у которого есть возможности чтения/записи, и «Пользователь оплога» для «отслеживания оплога».

Шаг 6.1: Создайте пользователя Meteor

Этот пользователь будет использоваться для "MONGO_URL".

  • Выберите: «Создать нового пользователя».
  • Установите «Имя пользователя».
  • Выберите «Чтение/запись любой базы данных».
  • Придумайте пароль и сохраните его! Нам это нужно для нашего URL-адреса подключения к MongoDB.

Шаг 6.2: Создайте пользователя Oplog

Этот пользователь будет использоваться для "MONGO_OPLOG_URL".

  • Выберите: «Создать нового пользователя».
  • Нажмите «Дополнительно».
  • Установите доступ «чтение» @ «локальный».
  • Придумайте пароль и сохраните его! Нам это нужно для нашего URL-адреса подключения к MongoDB.

Примечание о пользователях и их разрешениях:

  • Пользователи назначаются группе Atlas и могут иметь доступ к любому кластеру в группе.
  • Если вы хотите ограничить доступ пользователя к другому кластеру, рекомендуется создать новую группу Atlas.
  • Подробнее о добавлении пользователя в MongoDB Atlas можно узнать здесь.

ПО ЖЕЛАНИЮ:

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

  • Нажмите кнопку «Подключиться» для вашего кластера.
  • Следуйте инструкциям под заголовком «Подключиться к оболочке Mongo».
  • Atlas по умолчанию применяет TLS/SSL. TLS/SSL нельзя отключить.
  • Если вы установили Mongo через Meteor, вам может потребоваться переустановка с бинарным пакетом -ssl.
  • В MacOS вы можете переустановить оболочку mongo с помощью следующей команды brewcommand: brew install mongodb --with-openssl. Для других ОС следуйте инструкциям Atlas.
  • Скопируйте и вставьте строку оболочки mongo из Atlas в свой терминал.
  • Убедитесь, что вы добавили правильный пароль пользователя в конец строки запроса mongo.
  • Теперь вы можете подключиться к вашей базе данных.
  • Следуйте приведенным ниже командам, чтобы проверить пользователей и их роли.

Команды оболочки Mongo в помощь:

// List all the databases on our primary node. 
show dbs
// Meteor apps will normally only have 3 dbs
admin   0.000GB // For dbs authentication
local   0.000GB // For oplog
meteor  0.000GB // To store our Meteor collections. Won't exist until it's created
// Make sure you are connected to the primary node, 
// and also on the admin database.
Use admin
db.system.users.find().pretty()
  • «Пользователь оплога» должен иметь: { “role”: “read”, “db”: “local” }
  • «Пользователь метеора» должен иметь: { "role" : "readWriteAnyDatabase", "db" : "admin" }

Предостережение, есть много команд, которые ограничены через консоль. Даже при входе в систему с полными правами администратора. Например, создание пользователя с ролями: ограничено оболочкой Mongo. Эти ограниченные команды оболочки mongo обычно доступны либо через пользовательский интерфейс Atlas, либо через их общедоступный API.

Шаг 7. Подключите приложение Meteor к Atlas

Теперь нам нужно создать наши "MONGO_URL" и "MONGO_OPLOG_URL", получив «строку подключения URI» нашего кластера из Atlas. Именно так мы свяжем наше приложение Meteor с нашей базой данных Mongo.

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

Шаг 7.1: Создайте наш «MONGO_URL»

Чтобы найти свой "MONGO_URL", нажмите кнопку «Подключение», расположенную на виджете пользовательского интерфейса вашего кластера. Скопируйте строку, расположенную под меткой «Строка подключения URI:». Эта строка станет вашим "MONGO_URL". Обязательно замените PASSWORD на пароль пользователя с ролью readWriteAnyDatabase. Это все, что нам нужно сделать для создания нашего"MONGO_URL".

Шаг 7.2: Создайте наш «MONGO_OPLOG_URL»

Мы создаем наш "MONGO_OPLOG_URL", сначала скопировав нашу строку "MONGO_URL". Теперь мы заменяем существующее имя пользователя и пароль на имя пользователя и пароль нашего пользователя oplog. Далее мы модифицируем запрос, расположенный в конце строки the"MONGO_OPLOG_URL".

Наш "MONGO_OPLOG_URL" должен содержать в конце что-то вроде этого: /meteor?authSource=admin&ssl=true&replicaSet=example-staging-shard-0. Нам нужно заменить этот конечный раздел на этот: /local?authSource=admin&ssl=true&replicaSet=example-staging-shard-0.

Вы могли заметить, что мы поменяли местами /admin? на /local?. Эта строка является именем базы данных, в которой хранятся ваши коллекции и документы. В случае с /local? мы хотим подключиться к «локальной» базе данных, из которой Meteor считывает поток oplog. Ниже приведено объяснение остальной части строки подключения:

  • authSource: это база данных, с которой мы хотим аутентифицировать наше имя пользователя: пароль. По умолчанию это обычно будет база данных администратора.
  • ssl: укажите, осуществляется ли подключение к базе данных через TLS/SSL. Atlas не разрешает подключения без SSL.
  • replicaSet: указывает имя набора реплик, к которому необходимо подключиться.

ПРИМЕЧАНИЕ. Значение, присвоенное replicaSet, приведено в качестве примера. Ваше имя будет другим и зависит от имени, которое вы задали для своего кластера. Вы можете узнать больше о формате строки подключения URL и параметрах здесь.

Вот и все! Теперь у нас есть два URL-адреса, необходимые для подключения нашего приложения Meteor к нашей базе данных.

Последнее замечание по "MONGO_OPLOG_URL". До Meteor 1.4 параметр "MONGO_OPLOG_URL" не содержал параметра replicaSet=replicaSetName. Чтобы 'oplog tailing' функционировал в Meteor 1.4+, thereplicaSet=replicaSetName должен быть включен.

Для развертывания в Galaxy вам необходимо установить "MONGO_URL" и "MONGO_OPLOG_URL" в файле settings.json, как показано ниже. Как только ваш новый файл settings.json будет сохранен, вы будете готовы к повторному развертыванию в Galaxy и подключению вашего приложения Meteor к вашей базе данных.

Пример файла Meteor settings.json для Galaxy.

{
  "galaxy.meteor.com": {
    "env": {
      "ENV": "staging",
      "MONGO_URL": "mongodb://okgrow-staging-meteor:[email protected]:27017,okgrow-staging-shard-00-01-fxnj9.mongodb.net:27017,okgrow-staging-shard-00-02-fxnj9.mongodb.net:27017/meteor?authSource=admin&ssl=true&replicaSet=okgrow-staging-shard-0",
      "MONGO_OPLOG_URL": "mongodb://okgrow-staging-oplog:[email protected]:27017,okgrow-staging-shard-00-01-fxnj9.mongodb.net:27017,okgrow-staging-shard-00-02-fxnj9.mongodb.net:27017/local?authSource=admin&ssl=true&replicaSet=okgrow-staging-shard-0",
    }
  }
}

ПРИМЕЧАНИЕ. При развертывании на другой платформе у вас обычно есть возможность установить "MONGO_URL" и "MONGO_OPLOG_URL" в качестве переменных среды.

Поздравляю! Теперь мы закончили. Наше приложение Meteor (с хвостом oplog) теперь подключено к нашему кластеру, размещенному на MongoDB Atlas. Я надеюсь, что процесс прошел относительно безболезненно, как и было обещано.

Мы используем MongoDB Atlas с августа 2016 года и до сих пор очень довольны своим опытом.

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

Вопросы и ответы:

Что такое группа Атлас?

MongoDB Atlas Group — это виртуальное частное облако (VPC) AWS для конкретного региона. Вы можете создать столько VPC, сколько захотите. Развертывания MongoDB или «кластеры» находятся внутри группы Atlas, что обеспечивает способ управления и безопасного доступа к вашим кластерам MongoDb.

Все кластеры для Atlas Group будут развернуты внутри этого регионального VPC. Первый кластер, добавленный в группу, определяет регион VPC.

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

Какие регионы поддерживаются?

На момент написания (обновлено 3 февраля 2017 г.) Atlas поддерживает 5 регионов AWS:

  • us-east-1 (Северная Вирджиния)
  • сша-восток-2 (Огайо)
  • us-west-2 (Орегон)
  • eu-west-1 (Дублин)
  • ap-юго-восток-2 (Сидней)

Что такое Шардинг?

Sharding — это способ MongoDb обеспечить горизонтальное масштабирование.

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

Вы должны рассматривать сегментирование только тогда, когда ваша БД стала узким местом вашего приложения, и вертикальное масштабирование больше невозможно.

Две основные причины шардинга:

  • Операции с высокой пропускной способностью и/или,
  • Наборы данных больше, чем доступная оперативная память на вашем сервере.

Первоначально опубликовано на www.okgrow.com.