Оба Marathon и Aurora построены на Mesos и, предположительно, спроектированы для запуска длинных сервисов. Мои вопросы:
Спасибо!
Отказ от ответственности: я вице-президент Apache Aurora и был техническим руководителем команды Aurora в Twitter в течение ~ 5 лет. Мои вероятные предвзятые мнения - мои собственные и не обязательно представляют интересы Twitter или ASF.
Выполняют ли эти фреймворки все, что работает в Linux? Для марафона они заявить, что он может запускать все, что "выполняется в оболочке", но это своего рода расплывчатое:)
По существу, да. В конечном итоге эти системы представляют собой сложную технику для запуска кода оболочки где-то в кластере: -)
В чем их отличия? Я изо всех сил пытался найти хорошие объяснения их ключевых различий
Aurora и Marathon действительно предлагают аналогичные наборы функций, которые классифицируются как "планировщики услуг". Другими словами, вы даете нам инструкции о том, как запускать серверы приложений, и мы делаем все возможное, чтобы поддерживать их.
Я предлагаю некоторые различия в широких штрихах. Когда дело доходит до недостатков, упомянутых в каждом, я думаю, что можно с уверенностью сказать, что сообщества знают и намерены исправить их.
Простота использования
Aurora установить нелегко. Вероятно, это будет похоже на то, что вы придумываете его. Он предоставляет привлекательный API, что означает, что вам понадобится бережливый клиент для взаимодействия с ним программным способом (наступает REST-подобный API, но на данный момент это паровое устройство) или используйте наш клиент командной строки. У Aurora есть DSL для configuration, который может быть сложным, но позволяет легко обмениваться шаблонами и общими шаблонами как вы используете систему больше.
Марафон, с другой стороны, поможет вам как можно быстрее запустить "Hello World". У этого есть большой docs, чтобы сделать это во многих средах и немного накладных расходов, чтобы идти. Он имеет REST API, что упрощает адаптацию к пользовательским инструментам. Он использует JSON для configuration, с которой легко начать, но более подвержено обработке груза.
Целевые варианты использования
Aurora всегда была разработана для работы с крупной инженерной организацией. У кластеров в Twitter есть десятки тысяч машин и сотни инженеров, использующих их. Для бизнеса Twitter важно. В результате мы очень серьезно относимся к нашим требованиям масштаба, стабильности и безопасности. Мы следим за тем, чтобы мы только одобряли функции, которые, по нашему мнению, заслуживают доверия в масштабе производства (например, у нас есть поддержка Docker, обозначенная как бета-версия, из-за известных проблем с самой Docker и интеграцией Mesos-Docker). У нас также есть функции, такие как превенция, которая делает наши кластеры подходящими для смешивания критически важных бизнес-сервисов с прототипами и экспериментами.
Я не могу претендовать на масштабируемость Marathon или против нее. На фронте функции Marathon быстро развивает функции, но на практике это может ощущаться кратковременно (поддержка Docker - хороший пример). Это происходит не всегда из-за самого марафона, но и слоев вниз по стеку. Марафон не обеспечивает превенцию.
собственности
Для некоторых важно владение и управление проектом. Он считает, что на практике он не определяет открытость проекта, но для некоторых людей/компаний законный мелкий шрифт может быть сделкой.
Для некоторых это полезно, другим - нет. Это означает, что вы можете оплачивать поддержку и функции. Это также означает, что есть что-то, что можно продать, и направление проекта в конечном итоге определяется интересами Мезосферы.
Это означает, что он подчиняется модели управления 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)
Marathon
[+] 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 есть лучшие возможности, я предпочитаю марафон из-за сложности Auroras/накладных расходов и отсутствия пользовательского интерфейса (для управления) и API
У меня больше опыта с марафоном.
Идеологический:
Технические:
Что касается второго вопроса, вы можете запустить любой контейнер команд или докеров, а Mesos сделает выделение ресурсов для вас. Если у вас есть 50% CentOS-узлов и 50% узлов Ubuntu, и вы запускаете задачу, выполняющую apt-get, задача будет иметь 50% -ный шанс на ошибку. Mesos и Marathon не знают о реальных машинах.
Отказ от ответственности: у меня нет практического опыта работы с Aurora, только с Marathon.
ad Q1: В двух словах Apache Aurora может выполнять то, что может предоставить Marathon + Chronos, то есть планировать как долгосрочные службы, так и повторяющиеся (пакетные) задания; см. также Руководство пользователя Aurora.
Объявление Q2: Да, что угодно. В настоящее время на основе групп и Docker, но эй, вы можете перевернуть свой собственный.