Apache Mesos — это менеджер кластеров с открытым исходным кодом, который обеспечивает эффективную изоляцию ресурсов и совместное использование в распределенных приложениях или инфраструктурах.
Apache Mesos абстрагирует ресурсы ЦП, памяти, хранилища и других вычислительных ресурсов от машин (физических или виртуальных), что позволяет легко создавать и эффективно эксплуатировать отказоустойчивые и гибкие распределенные системы. Он использует динамическое размещение приложений внутри машин.
В итоге Apache Mesos состоит из мастера и рабов. Мастера отвечают за распределение работы между несколькими рабами и знание состояния каждого раба. У вас может быть более одного мастера для отказоустойчивого.
И затем у нас есть подчиненные, которые отвечают за выполнение приложений. Рабы изолируют исполнителей и задачи (приложения) через контейнеры (cgroups).
Таким образом, каждый подчиненный предлагает свои ресурсы, и Apache Mesos отвечает за расписание, которое подчиненное будет выполнять. Обратите внимание, что каждый ведомый может выполнять более одной задачи, если у него достаточно ресурсов для его выполнения.
Например, допустим, что подчиненный имеет 4 ЦП (для упрощения я не собираюсь принимать во внимание другие параметры), тогда он может выполнить 1 задачу из 4 ЦП, 2 задачи по 2 ЦПУ,…
Но Apache Mesos только управляет ресурсами, но для создания PaaS нам нужно нечто большее, например, функции обнаружения служб или масштабирования. И это то, что делает Марафон .
Marathon — это фреймворк, который работает поверх A pache Mesos и предлагает:
- Запуск бинарного Linux
- Общекластерный супервизор процессов
- Обнаружение службы и балансировка нагрузки (HAProxy)
- Автоматическая обработка программного и аппаратного сбоя
- Развертывание и масштабирование
- REST friendly
Но одно из главных преимуществ использования Marathon заключается в том, что он упрощает и автоматизирует все эти общие задачи.
Итак, основная задача Marathon — развернуть приложение на разных уровнях, поэтому, если один из них не работает, есть другие подчиненные для обслуживания входящих сообщений. Более того, Marathon позаботится о перераспределении приложения на другое ведомое устройство, чтобы количество подчиненных устройств на приложение поддерживалось постоянным.
Установить Apache Mesos и Marathon на компьютере разработчика так же просто, как установить VirtualBox , Vagrant и git .
Клонирование следующего репо:
1
|
git clone https: //github .com /mesosphere/playa-mesos .git |
И просто запустите команду vagrant-up из каталога:
1
2
|
cd playa-mesos vagrant up |
Первый раз это займет некоторое время, потому что для этого нужно скачать несколько компонентов.
После этого вы можете проверить, правильно ли он установлен, подключившись к Mesos и Marathon Web Console. http://10.141.141.10:5050 и http://10.141.141.10:8080
Следующим шагом является установка HAProxy . Хотя это не является обязательным требованием, HAProxy является «обязательным», если вы хотите выполнять обнаружение служб и распределение нагрузки.
Запустите бродячий сш .
Установить HAProxy
1
|
sudo apt-get install haproxy |
Загрузите скрипт haproxy-marathon-bridge:
1
2
3
4
5
|
wget https: //raw .githubusercontent.com /mesosphere/marathon/master/bin/haproxy-marathon-bridge chmod 755 haproxy-marathon-bridge . /haproxy_marathon_bridge localhost:8080 > haproxy.cfg haproxy -f haproxy.cfg -p haproxy.pid -sf $( cat haproxy.pid) |
И это настраивает HAproxy . Чтобы избежать необходимости запускать эту команду вручную при каждом изменении топологии, вы можете выполнить:
1
|
. /haproxy_marathon_bridge install_haproxy_system localhost:8080 |
который устанавливает сам скрипт, HAProxy и cronjob, который раз в минуту пингует один из указанных серверов Marathon и обновляет HAProxy, если что-то изменилось.
И это все, теперь у нас есть Apache Mesos с установленной Mesosphere и HAProxy . Теперь пришло время развернуть сервер приложений Java EE . В этом случае мы будем использовать Apache TomEE .
Единственное, что нам нужно сделать, это отправить документ JSON в формате POST на http://10.141.141.10:8080/v2/apps.
01
02
03
04
05
06
07
08
09
10
11
12
13
14
|
{ "id" : "projectdemo" , "cmd" : "cd apache-tomee-plus* && sed \"s/8080/$PORT/g\" < ./conf/server.xml > ./conf/server-mesos.xml && ./bin/catalina.sh run -config ./conf/server-mesos.xml" , "mem" : 256, "cpus" : 0.5, "instances" : 1, "ports" :[10000], "constraints" : [ [ "hostname" , "UNIQUE" ] ], "uris" : [ ] } |
Этот документ JSON заставит Marathon развернуть приложение на одном узле. Давайте объясним каждый атрибут:
id: это идентификатор приложения, здесь не секрет.
cmd : команда, которая будет выполняться, когда узел выбран готовым. В этом случае обратите внимание, что мы создаем файл server-mesos.xml, который является модифицированной версией файла server.xml, но заменяет порт 8080 на $ PORT var. Пока достаточно. Наконец, он запускает TomEE с файлом конфигурации server-mesos.xml .
mem : память, которая потребуется в узле.
cpus : ресурсы процессора , которые потребуются в узле.
случаи : количество узлов, которые мы хотим повторить это приложение. В этом случае только один, потому что мы работаем локально.
порты : какие порты будут группировать все экземпляры приложений. В основном этот порт используется
HAProxy для маршрутизации на правильный экземпляр. Мы собираемся объяснить глубоко в следующем параграфе.
ограничения : ограничения управляют тем, где запускаются приложения, чтобы оптимизировать отказоустойчивость или локальность. В этом случае мы устанавливаем, что каждое приложение должно быть в другом ведомом устройстве. При таком подходе вы можете избежать коллизии портов.
uris : Устанавливает URI для выполнения перед выполнением части cmd . В случае известного сжатого алгоритма он автоматически распаковывается. По этой причине вы можете выполнить команду cd непосредственно в cmd, не распаковывая ее вручную.
Итак, позвольте мне объяснить, что здесь происходит или что делает Месосфера :
Прежде всего читает документ JSON и проверяет, у какого ведомого есть узел, который может обрабатывать этот сервис. В этом случае нужно только найти его. (экземпляры = 1).
Когда он найден, элемент uri загружается, распаковывается и выполняет команды, указанные в
Атрибут cmd в текущем каталоге.
И это все. Но подождите, что такое порты и $ PORT ?
$ PORT — это случайный порт, который Mesosphere назначит узлу для связи. Этот порт используется, чтобы гарантировать, что никакие два приложения не могут быть запущены с использованием Marathon с перекрывающимися назначениями портов.
Но он также используется для обнаружения служб и балансировки нагрузки, запуская прокси-сервер TCP на каждом хосте в кластере и прозрачно перенаправляя статический порт на локальном хосте хостам, на которых выполняется приложение. Таким образом, клиенты просто подключаются к этому порту, и детали реализации обнаружения полностью удаляются.
Итак, первое, что нам нужно сделать, это изменить конфигурацию TomEE для запуска со случайного порта, назначенного Marathon , по этой причине мы создали новый файл server.xml и установили для порта прослушивания $ PORT .
Итак, если порт случайный, как клиент может подключиться, если он не знает, с какого порта запущен? И это цель атрибутов портов. В этом атрибуте мы устанавливаем, что при подключении к порту 10000 я хочу подключиться к приложению, определенному и развернутому на любом подчиненном устройстве, независимо от количества экземпляров.
Да, это может быть немного сложно, но позвольте мне объяснить на простом примере:
Допустим, у меня есть тот же пример, что и раньше, но с двумя экземплярами (instances = 2). Оба экземпляра TomEE будут запущены в двух разных ведомых (то есть в разных узлах) и в разных портах. Скажем, 31456 и 31457 . Итак, как мы можем подключиться к ним?
Легко. Вы можете использовать IP-адрес Marathon и произвольный порт ( http://10.141.141.10:31456/ ), к которому вы получите доступ к этому конкретному серверу, или вы можете использовать глобально определенный порт ( http://10.141.141.10:10000). / ) который в этом случае HAProxy будет маршрутизировать к одному из экземпляров (в зависимости от правил балансировки нагрузки).
Обратите внимание, что это имеет очень большое значение для того, как мы можем взаимодействовать между приложениями внутри Marathon , потому что если нам нужна внутренняя связь между приложениями, развернутыми в Marathon , нам нужно знать только этот глобальный порт, потому что хост может быть установлен на localhost как HAProxy разрешит это. Таким образом, из приложения Marathon мы можем общаться с TomEE , просто используя http: // localhost: 10000 /, поскольку HAProxy затем направит запрос на хост и порт, где фактически выполняется экземпляр службы. На следующем рисунке вы можете увидеть панель инструментов Marathon и то, как приложение развернуто. Обратите внимание, что вы можете увидеть IP и порт развернутого приложения. Вы можете получить доступ, щелкнув по нему или используя Marathon IP (такой же, как указано в этой ссылке), но используя порт 10000 . Помните, что HAProxy обновляется каждую минуту, поэтому, если он работает с использованием случайного порта и не использует порт 10000, вероятно, вам нужно подождать некоторое время, пока база данных HAProxy будет обновлена.
И это все, как вы можете видеть, Apache Mesos и Marathon не так сложны, как вы могли ожидать вначале.
Также обратите внимание, что это «Hello World» пост о Mesos и Java EE , но Mesos и Mesosphere — это гораздо больше, чем исправные проверки сервисов, запуск контейнеров Docker , хранение артефактов или определение зависимостей, но я обнаружил, что запуск этого Простой пример помогает мне прояснить понятия мезосферы, и это было хорошей отправной точкой для более сложных сценариев.
Ссылка: | Apache Mesos + Marathon и Java EE от нашего партнера JCG Алекса Сото в блоге One Jar To Rule All . |