С ростом популярности контейнеризации приложений растет спрос на приложения, способные управлять большим количеством контейнеров. На слуху прежде всего 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 же по моему большому опыту обеспечивает не только стабильную работу ваших сервисов, но и плавное обновление компонентов кластера по мере необходимости.
За квалифицированной помощью по администрированию серверов или экспертной консультацией обращайтесь сюда.