Apache Mesos + Marathon и Java EE

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 .

Клонирование следующего репо:

И просто запустите команду vagrant-up из каталога:

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

После этого вы можете проверить, правильно ли он установлен, подключившись к Mesos и Marathon Web Console. http://10.141.141.10:5050 и http://10.141.141.10:8080

Следующим шагом является установка HAProxy . Хотя это не является обязательным требованием, HAProxy является «обязательным», если вы хотите выполнять обнаружение служб и распределение нагрузки.

Запустите бродячий сш .

Установить HAProxy

Загрузите скрипт haproxy-marathon-bridge:

И это настраивает HAproxy . Чтобы избежать необходимости запускать эту команду вручную при каждом изменении топологии, вы можете выполнить:

который устанавливает сам скрипт, HAProxy и cronjob, который раз в минуту пингует один из указанных серверов Marathon и обновляет HAProxy, если что-то изменилось.

И это все, теперь у нас есть Apache Mesos с установленной Mesosphere и HAProxy . Теперь пришло время развернуть сервер приложений Java EE . В этом случае мы будем использовать Apache TomEE .

Единственное, что нам нужно сделать, это отправить документ JSON в формате POST на http://10.141.141.10:8080/v2/apps.

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