Apache Mesos. Знакомимся с конкурентом Kubernetes и Docker Swarm
5 (100%) 2 votes

С ростом популярности контейнеризации приложений растет спрос на приложения, способные управлять большим количеством контейнеров. На слуху прежде всего Kubernetes и Docker Swarm. Однако у них есть и другие достойные открытые конкуренты. В этой статье мы рассмотрим Mesos, развиваемый фондом Apache.

Начавшись как исследовательский проект в одной из лабораторий университета Калифорнии в Беркли, Mesos был впервые представлен в 2009 году под именем Nexus. Некоторое время проект находился в ранге исследовательских, а версия «1» была выпущена только в 2016 году под крылом Apache Software Foundation.

Впрочем, к этому времени Apache Mesos уже использовался в Twitter, Airbnb, eBay и даже в сервисе Apple Siri. Однако, несмотря на таких серьезных пользователей, открытость и покровительство Apache, обзоров Mesos в сети в настоящее время не так уж и много. И пользователей, судя по всему, тоже. Тем не менее Apache Mesos заслуживает внимания не только ради расширения кругозора, но и с целью практического применения благодаря стабильной работе и относительной простоте развертывания и настройки.

В данной статье мы рассмотрим процесс создания кластера Mesos на машинах под управлением Virtuozzo Linux и его интеграцию с фреймворком Jenkins с целью динамического создания контейнеров для выполнения задач непрерывной интеграции.

Распределенная природа дает Apache Mesos ряд принципиально новых возможностей — например, способность переживать потерю части «железных» ресурсов с сохранением всех работающих процессов

Суть работы Apache Mesos сводится к объединению физических ресурсов нескольких серверов в единый виртуальный пул, из которого они будут выделяться для выполнения конкретных задач. Можно сравнить Mesos с планировщиком ресурсов традиционных ОС — с той разницей, что физически подвластные ему ресурсы расположены на разных серверах, Однако распределенная природа дает Mesos ряд принципиально новых возможностей — например, способность переживать потерю части «железных» ресурсов с сохранением всех работающих процессов.

Управляемые Mesos машины объединяются в кластер, ядром которого являются управляющие (master) серверы. В кластере может быть (и должно быть для обеспечения отказоустойчивости) несколько мастер-серверов. В любой момент активным является только один из них. Координация мастеров и выбор активного осуществляются с помощью сервиса ZooKeeper.

Сервисные машины-узлы (slaves) предоставляют мощности для выполнения задач. Задачи выполняются в отдельных контейнерах — поддерживается как Docker, так и собственная контейнеризация Mesos, также основанная на штатных механизмах Linux (cgroups).

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

Наиболее известными являются:

  • Marathon, предназначенный для одноразового запуска задач (например, тех или иных сервисов, которые должны работать без перебоев), — этот фреймворк часто рассматривают в статьях про Mesos;
  • Chronos — служит для запуска задач по расписанию, поддерживает зависимости между разными задачами;
  • Aurora — разработка Twitter, выпущенная под открытой лицензией в 2013 году. Подходит как для запуска сервисов, которые должны работать непрерывно, так и для выполнения задач по расписанию. Однако по признанию самих разработчиков этот фреймворк отнюдь не прост в развертывании и обслуживании (неудивительно, что большинство обзоров Mesos рассматривают Marathon, а не Aurora), хотя и обладает отличной масштабируемостью.

Mesos обеспечивает не только стабильную работу сервисов, но и плавное обновление компонентов кластера

В виде фреймворков реализован плагин для Jenkins, позволяющий запускать машины-узлы Jenkins (Jenkins slaves) на кластере Mesos. При этом осуществляется динамический мониторинг количества запущенных машин, при необходимости добавляются новые, а при длительном простое удаляются излишние. Аналогичным образом реализованы плагины для Hadoop, Apache Spark и Apache Torque.

Рассмотрим использование Mesos совместно с Jenkins, основанное на опыте работы с этой комбинацией. Но для начала давайте создадим кластер Mesos. В нашем примере кластер будет состоять из трех мастер-серверов с адресами 10.0.3.2, 10.0.3.3 и 10.0.3.4 и одного вычислительного узла (slave) с адресом 10.0.3.5.

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

Установка master-сервера

В данной статье мы будем устанавливать все компоненты Mesos на машины под управлением Virtuozzo Linux 7. Все инструкции могут быть без изменения использованы для машин под управлением CentOS 7 и ее производных.

Для развертывания мастер-серверов на каждом из них необходимо добавить RPM-репозитории Mesos:

и установить соответствующие пакеты:

Для идентификации в ZooKeeper каждому мастеру (ниже мы будем в качестве примера использовать 10.0.3.4) надо вручную выбрать и прописать уникальный числовой идентификатор в диапазоне от 1 до 255:

явно прописать IP-адрес, по которому он будут доступен:

и имя машины (hostname). Если разрешимого через DNS имени у машины нет, в этот файл надо также прописать IP-адрес, пустовать он не должен:

В отдельном файле настроек Mesos необходимо указать адреса всех мастер-нод:

(2181 — это порт, который по умолчанию слушает ZooKeeper).

Для самого ZooKeeper необходимо в файл /etc/zookeeper/ conf/zoo.cfg добавить адреса мастер-нод в следующем виде:

Здесь 1, 2,3 — не порядковые номера, а идентификаторы, которые указаны в файле /var/lib/zookeeper/myid каждого сервера.

Порт 2888 используется для взаимодействия с активным мастером, 3888 — для выбора нового мастера при необходимости.

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

Поэтому минимальна конфигурация кластера Mesos при условии, что вы заботитесь о его отказоустойчивости -это три мастер-сервера и значение кворума, равное двум. Такая конфигурация позволяет пережить потерю одного мастера. Достаточно типичной является конфигурация 5:3, при которой можно потерять два узла из пяти (напомним, что исходя из схожих соображений выбираются рекомендуемые настройки Virtuozzo Storage).

Значение кворума указывается в отдельном файле настроек:

В завершение отключаем сервис mesos-slave и рестарту-ем mesos и zookeeper (при установке пакетов все эти сервисы добавляются в набор загружаемых при старте системы, но не стартуют сразу ввиду отсутствия конфигурации):

После установки веб-интерфейс Mesos будет доступен по адресу любого из мастеров на порту 5050.

По нашему опыту этот веб-интерфейс Apache Mesos удобно использовать для мониторинга происходящих в кластере событий (особенно если что-то пошло не так; впрочем, в таких случаях иногда полезнее посмотреть в журналы в директории /var/log/mesos на мастер-узлах либо на вычислительном узле, где произошла ошибка). Управлять же кластером особой необходимости не возникает; настройка и контроль реальных задач осуществляется в используемом у вас фреймворке (например, Marathon имеет свой веб-интерфейс, а конфигурация плагина Jenkins осуществляется в самом Jenkins).

Установка Slave

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

Из этих репозиториев достаточно установить пакет Mesos:

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

Аналогично мастер-нодам необходимо для каждой машины прописать IP-адрес и имя машины:

Если на данной машине установлен только slave, то надо отключить запуск сервиса mesos-master

Все мастер-серверы необходимо указать в /etc/mesos/zk

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

Изначально в Mesos для запуска задач использовались собственные контейнеры, но в соответствии с веянием времени была добавлена поддержка Docker. Что именно будет использоваться, зависит от конкретного фреймворка и его настроек.

Например, плагин Jenkins по-прежнему создает Mesos-контейнеры, а вот Marathon (входящий в официальные репозитории Mesos) использует Docker. Несмотря на последний факт, по умолчанию Docker-контейнеризация на вычислительных узлах недоступна, требуется выполнить ряд действий, чтобы ее включить.

Во-первых, необходимо установить сам Docker:

А затем добавить его в список доступных типов контейнеризации:

При использовании Docker рекомендуется увеличить тайм-аут регистрации нового контейнера — надо закладываться на ситуацию, когда нужного docker-образа нет в локальном кэше и его надо сначала скачать по сети:

Наконец запустим сервис mesos-slave:

Если все прошло успешно, новый сервисный узел появится на вкладке Agents в веб-интерфейсе Mesos.

Использование Apache Mesos совместно с Jenkins

В данной статье мы рассмотрим настройку Jenkins на использование Mesos для размещения вычислительных узлов (Jenkins slaves). Данный функционал реализован с помощью плагина mesos, однако перед его установкой в Jenkins необходимо выполнить ряд подготовительных действий (не считая развертывания самого Jenkins — далее мы предполагаем, что он уже установлен и работает на машине, не входящей в кластер Mesos).

Во-первых, на каждой машине с Mesos slave необходимо завести пользователя с именем jenkins, установить java (мы использовали стандартный пакет java-1.8.O-openjdk из репозиториев Virtuozzo Linux) и прописать экспорт переменной JAVA_HOME в профиль пользователя.

Выполним настройку Jenkins на использование Mesos для размещения вычислительных узлов (Jenkins slaves)

На сервер Jenkins необходимо добавить библиотеку libmesos для взаимодействия с кластером. В нашей конфигурации Jenkins также работает на машине с Virtuozzo Linux, поэтому взять библиотеку можно из RPM-пакета mesos либо непосредственно с одной из машин Mesos-кластера — она располагается в директории /usr/lib. имя ее начинается на libmesos (например, libmesos-1.5.0.SO). Обратите внимание, что в этой директории также есть файл /usr/lib/libmesos.so, но он является символьной ссылкой на реальную библиотеку.

Положить файл с библиотекой необходимо на сервер Jenkins в любое место, доступное фреймворку, — например, в /usr/local/lib/. Путь к ней необходимо будет указать при настройке плагина.

Теперь можно идти в веб-интерфейс Jenkins и искать плагин mesos в списке секции Manage Plugins. Вместе с ним необходимо установить плагин metrics — хотя он и отмечен в документации как опциональный, без него в нашем Jenkins плагин mesos работать отказался, попытка его использовать приводила к генерации исключения Java.

После установки плагинов переходим в секцию настроек Jenkins (Configure). Внизу этой секции у вас должна появиться кнопка Add a new cloud, при нажатии на которую в качестве одного из вариантов должна быть доступна опция Mesos cloud.

При ее выборе обязательно надо указать путь к библиотеке mesos на сервере Jenkins (параметре Mesos native library path), URL самого Jenkins, а также адреса мастер-узлов Mesos. В последнем поле можно указать адрес конкретного мастера, а можно сразу ссылку Zookeer (zkJ/10.0.3.4: 2181,10.0.3.3:2181,10.0.32:2181/mesos).

Тут же можно нажать кнопку Test connection для проверки соединения с кластером.

Обратите внимание, что если вы указали адрес в формате ZooKeeper, то сначала необходимо нажать кнопку Save

В расширенных (Advanced) настройках можно указать, следует ли создавать контейнеры в кластере по мере необходимости (On-demand framework registration) либо вы будете создавать их вручную. Нам интересен вариант, когда контейнеры создаются автоматически — если на Jenkins будет запущено слишком много задач и им не станет хватать машин для выполнения, автоматически будет создан новый контейнер в кластере Mesos (естественно при наличии ресурсов).

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

При желании можно указать метку (Label), которая будет присваиваться всем вычислительным узлам Jenkins, создаваемым в кластере Mesos. Это позволит вам регулировать, какие задачи можно запускать на таких узлах, а какие — нет.

Наконец, вместо «родных» контейнеров Mesos можно использовать Docker. Главным преимуществом такого выбора является возможность запускать контейнер из произвольного образа, который вы укажете, так что можно подготовить образ под свои нужды, с теми программами, которые вам нужны.

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

Но если вы запускаете свои собственные скрипты, то с большой вероятностью вам надо переключаться на Docker. В таком случае вам надо будет указать, какой контейнер запускать и с какими параметрами.

Проверить, как ведет себя связка Jenkins и Mesos, достаточно легко — просто запустите несколько «долгих» задач, общее количество которых будет превышать число имеющихся у вас в данный момент узлов Jenkins. При этом помните, что плагин mesos создает новый контейнер не сразу по мере появления новых нераспределенных задач в очереди, а только если узлов для выполнения задач не хватает уже в течение нескольких минут.

В таком поведении, безусловно, есть логика, ведь создание контейнера происходит не мгновенно (так что вы вполне можете наблюдать за появлением нового узла непосредственно в веб-интерфейсе Jenkins).

Заключение

С точки зрения производительности и отказоустойчивости Apache Mesos показывает вполне достойные характеристики и по праву считается конкурентом Kubernetes и Docker Swarm.

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

Например, для развертывания кластера Mesos по-прежнему предлагается заходить на каждую машину и выполнять на ней установку пакетов и конфигурацию, в то время как для того же Kubernetes активно развиваются средства автоматического развертывания кластера.

Также можно отметить более гибкий подход Kubernetes к обеспечению устойчивости кластера к исчезновению мастер-узлов.

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

Apache Mesos же по моему большому опыту обеспечивает не только стабильную работу ваших сервисов, но и плавное обновление компонентов кластера по мере необходимости.

За квалифицированной помощью по администрированию серверов или экспертной консультацией обращайтесь сюда.