И Marathon, и Aurora построены на Mesos и предположительно предназначены для запуска долговременных сервисов. Мои вопросы:
Спасибо!
Отказ от ответственности: я являюсь вице-президентом Apache Aurora и работаю техническим руководителем команды Aurora в Twitter около 5 лет. Мои, вероятно, предвзятые мнения являются моими собственными и не обязательно отражают точку зрения Twitter или ASF.
Эти фреймворки запускают что-нибудь, что работает в Linux? Для Marathon они заявляют, что он может запускать все, что «исполняется в оболочке», но это немного расплывчато :)
По сути, да. В конечном счете, эти системы представляют собой сложный механизм для выполнения шелл-кода где-то в кластере :-)
Каковы их различия? Я изо всех сил пытался найти какие-либо хорошие объяснения их ключевых различий.
Aurora и Marathon действительно предлагают схожие наборы функций, и оба они классифицируются как «планировщики услуг». Другими словами, вы передаете нам инструкции о том, как запускать ваши серверы приложений, и мы делаем все возможное, чтобы поддерживать их в рабочем состоянии.
Я предложу некоторые различия в общих чертах. Когда дело доходит до недостатков, упомянутых в каждом из них, я думаю, можно с уверенностью сказать, что сообщества знают о них и намерены их исправить.
Простота использования
Аврора не проста в установке. Скорее всего, вам покажется, что вы прокладываете путь во время настройки. Он предоставляет экономный API, а это означает, что вам понадобится экономный клиент для программного взаимодействия с ним (похожий на REST API приближается, но в настоящее время является бесполезным) или используйте наш клиент командной строки. У Aurora есть DSL для конфигурации. что может быть пугающим, но позволяет вам легко обмениваться шаблонами и общими шаблонами по мере того, как вы больше используете систему.
Marathon, с другой стороны, поможет вам запустить «Hello World» как можно быстрее. У него есть отличные документы, чтобы сделать это во многих средах, и для начала работы не требуется много времени. . Он имеет REST API, что упрощает адаптацию к пользовательским инструментам. Он использует JSON для конфигурации, с которого легко начать, но он более склонен к культивированию грузов.
Целевые варианты использования
Aurora всегда разрабатывалась для работы с крупной инженерной организацией. Кластеры в Twitter состоят из десятков тысяч машин и используют их сотни инженеров. Это очень важно для бизнеса Twitter. Поэтому мы очень серьезно относимся к нашим требованиям к масштабируемости, стабильности и безопасности. Мы стараемся поддерживать только те функции, которые, по нашему мнению, заслуживают доверия в масштабе производства (например, наша поддержка Docker помечена как бета-версия из-за известных проблем с самим Docker и интеграцией Mesos-Docker). У нас также есть такие функции, как вытеснение, которые делают наши кластеры подходящими для смешивания критически важных для бизнеса сервисов с прототипами и экспериментами.
Я не могу претендовать ни за, ни против масштабируемости Marathon. Что касается функций, Marathon быстро создает функции, но на практике это может показаться передовым (хорошим примером является поддержка Docker). Это не всегда связано с самим Marathon, но также и с более низкими уровнями стека. Марафон не обеспечивает упреждение.
Владение
Для некоторых важны владение и управление проектом. Кажется, что на практике это не определяет открытость проекта, но для некоторых людей/компаний юридический мелкий шрифт может стать препятствием для сделки.
Кому-то это выгодно, кому-то нет. Это означает, что вы можете платить за поддержку и функции. Это также означает, что есть что продавать, и направление проекта в конечном счете определяется интересами Мезосферы.
Это означает, что он подчиняется модели управления ASF, управляемой сообществом. У Aurora нет платных клиентов, и в настоящее время нет магазина программного обеспечения, за разработку которого можно платить.
tl;dr Если вы только начинаете работать с сервисами на Mesos, я бы посоветовал Marathon в качестве первого порта захода. Вам будет проще бегать и ковыряться в экосистеме. Если вы формируете «частную облачную стратегию» для компании, я предлагаю серьезно рассмотреть Aurora, так как она проверена и специально предназначена для этого.
Итак, я оценивал оба, и это мое резюме.
Аврора
[+] also handles recurring jobs
[+] finer grained, extensive file-based configuration
[+] has namespaces so multiple environments can co-exist
[-] read-only UI, no official API
[~] file based configuration and cli based execution brings overhead (which can be justified with more extensive feature set)
Марафон
[+] very easy to setup and use
[+] UI that provides control and extensive API (even with features missing from UI at the moment)
[+] event bus to listen in on api calls
[-] handles only long-running jobs
[-] does not have separate deployment-run-cleanup steps, these if necessary need to be combined in a script of one-liner
Несмотря на то, что Aurora обладает лучшими возможностями, я предпочитаю Marathon из-за сложности/накладных расходов Aurora и отсутствия пользовательского интерфейса (для управления) и API.
У меня больше опыта с марафоном.
Идеологический:
Технические:
Что касается вашего второго вопроса, вы можете запустить любую команду или док-контейнер, и Mesos выполнит изоляцию ресурсов за вас. Если у вас 50 % узлов CentOS и 50 % узлов Ubuntu, и вы запускаете задачу, которая выполняет apt-get, вероятность сбоя задачи будет 50 %. Mesos и Marathon ничего не знают о настоящих машинах.
Отказ от ответственности: у меня нет практического опыта работы с Aurora, только с Marathon.
ad Q1: Короче говоря, Apache Aurora способен делать то же, что и Marathon + Chronos, то есть планировать как длительные службы, так и повторяющиеся (пакетные) задания; см. также руководство пользователя Aurora.
объявление Q2: Да, что угодно. В настоящее время основан на cgroups и Docker, но вы можете создать свой собственный.
