Marathon vs Aurora et leurs objectifs
Marathon et Aurora sont construits sur Mesos et sont censés être conçus pour exécuter des services de longue durée. Mes questions sont:
- Quelles sont leurs différences? J'ai eu du mal à trouver de bonnes explications concernant leurs principales différences
- Ces cadres exécutent-ils quelque chose qui fonctionne sous Linux? Pour Marathon, ils déclarent qu'il peut exécuter tout ce qui "est exécutable dans un Shell" mais c'est un peu vague :)
Merci!
Avis de non-responsabilité: je suis le vice-président d'Apache Aurora et je suis responsable technique de l'équipe Aurora sur Twitter depuis environ 5 ans. Mes opinions probablement partiales sont les miennes et ne représentent pas nécessairement celles de Twitter ou de l'ASF.
Ces cadres exécutent-ils quelque chose qui fonctionne sous Linux? Pour Marathon, ils déclarent qu'il peut exécuter tout ce qui "est exécutable dans un Shell" mais c'est un peu vague :)
Essentiellement, oui. En fin de compte, ces systèmes sont des machines sophistiquées pour exécuter du code Shell quelque part dans un cluster :-)
Quelles sont leurs différences? J'ai eu du mal à trouver de bonnes explications concernant leurs principales différences
Aurora et Marathon proposent en effet des ensembles de fonctionnalités similaires, tous deux classés comme "planificateurs de services". En d'autres termes, vous nous donnez des instructions sur la façon d'exécuter vos serveurs d'applications et nous faisons de notre mieux pour les maintenir à jour.
Je vais proposer quelques différences dans les grandes lignes. En ce qui concerne les lacunes mentionnées dans chacune, je pense qu'il est prudent de dire que les communautés sont conscientes et ont l'intention de les corriger.
Facilité d'utilisation
Aurora n'est pas facile à installer. Vous vous sentirez probablement comme un pionnier lors de la configuration. Il expose une API d'épargne, ce qui signifie que vous aurez besoin d'un client d'épargne pour interagir avec lui par programme (une API de type REST arrive, mais est actuellement un vaporware), ou utilisez notre client de ligne de commande. Aurora a une DSL pour configuration qui peut être intimidante, mais vous permet de partager facilement des modèles et des modèles communs à mesure que vous utilisez le système.
Le marathon, en revanche, vous aide à exécuter "Hello World" le plus rapidement possible. Il a une grande docs pour le faire dans de nombreux environnements et il y a peu de frais généraux pour commencer. Il a une API REST, ce qui facilite l'adaptation à des outils personnalisés. Il utilise JSON pour configuration , qui est facile à démarrer mais plus sujet à la culture de cargaison.
Cas d'utilisation ciblés
Aurora a toujours été conçu pour gérer une grande organisation d'ingénierie. Les clusters sur Twitter ont des dizaines de milliers de machines et des centaines d'ingénieurs qui les utilisent. Il est essentiel aux activités de Twitter. Par conséquent, nous prenons très au sérieux nos exigences d'échelle, de stabilité et de sécurité. Nous nous assurons de ne tolérer que les fonctionnalités que nous croyons dignes de confiance à l'échelle de la production (par exemple, notre support Docker est étiqueté en version bêta en raison de problèmes connus avec Docker lui-même et l'intégration Mesos-Docker). Nous avons également des fonctionnalités telles que la préemption qui rendent nos clusters adaptés au mélange de services critiques avec des prototypes et des expériences.
Je ne peux faire aucune réclamation pour ou contre l'évolutivité de Marathon. Sur le plan des fonctionnalités, Marathon a développé rapidement des fonctionnalités, mais cela peut sembler saigner Edge dans la pratique (le support Docker est un bon exemple). Ce n'est pas toujours dû au Marathon lui-même, mais il superpose également la pile. Marathon n'offre pas de préemption.
Propriété
Pour certains, l'appropriation et la gouvernance d'un projet sont importantes. Il a le sentiment qu'en pratique, il ne définit pas l'ouverture d'un projet, mais pour certaines personnes/entreprises, les petits caractères juridiques peuvent être une rupture.
- Marathon appartient à une entreprise (Mésosphère)
Pour certains, c'est bénéfique, pour d'autres non. Cela signifie que vous pouvez payer pour le support et les fonctionnalités. Cela signifie également qu'il y a quelque chose à vendre et que la direction du projet est finalement décidée par les intérêts de la Mésosphère.
- Aurora appartient à la Apache Software Foundation
Cela signifie qu'il est soumis au modèle de gouvernance de la FAA, piloté par la communauté. Aurora n'a pas de clients payants et il n'y a pas actuellement de magasin de logiciels que vous puissiez payer pour le développement.
tl; dr Si vous ne faites que vous mouiller les pieds avec les services de course à pied sur Mesos, je suggère Marathon comme première escale. Il vous sera plus facile de courir et de fouiner dans l'écosystème. Si vous formez la `` stratégie de cloud privé '' pour une entreprise, je suggère d'envisager sérieusement Aurora, car elle est éprouvée et spécialement conçue pour cela.
J'ai donc évalué les deux et voici mon résumé.
Aurore
[+] 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
Même si Aurora a de meilleures capacités, je préfère Marathon en raison de la complexité/surcharge d'Aurora et du manque d'interface utilisateur (pour le contrôle) et d'API
J'ai plus d'expérience avec Marathon.
Idéologique:
- Marathon est un produit relativement testé qui est utilisé en production chez AirBnB. Aurora est un des premiers projets Apache (donc YMMV).
- Les deux sont open source et actifs. N'hésitez pas à contribuer aux demandes d'extraction ou aux problèmes de fichiers!
Technique:
- Marathon ne planifie pas de tâches batch ou de tâches cron
- Marathon a une interface utilisateur conviviale et de meilleurs indicateurs de santé (en 0.8.x)
En ce qui concerne votre deuxième question, vous pouvez exécuter n'importe quelle commande ou conteneur Docker, et Mesos fera l'isolation des ressources pour vous. Si vous avez 50% de nœuds CentOS et 50% de nœuds Ubuntu et que vous exécutez une tâche qui exécute apt-get, la tâche aura 50% de chances d'échouer. Mesos et Marathon n'ont aucune connaissance des machines réelles.
Avertissement: je n'ai pas d'expérience pratique avec Aurora, seulement avec Marathon.
annonce Q1: En un mot, Apache Aurora est capable de faire ce que Marathon + Chronos peut fournir, c'est-à-dire planifier à la fois des services de longue durée et des travaux récurrents (par lots); voir aussi Aurora user guide .
annonce Q2: Oui, n'importe quoi. Actuellement basé sur cgroups et Docker mais bon, vous pouvez lancer le vôtre .