Lors de la conférence inaugurale HashiConf, qui a eu lieu à Portland, aux États-Unis, HashiCorp a annoncé la sortie d'un nouveau projet de scheduler distribué nommé Nomad qui est capable de planifier la création de conteneurs, de machines virtuelles et d'applications autonomes au sein d'un datacenter ; ainsi qu'un nouvel outil de livraison d'applications nommé Otto qui se fonde sur les principes de Vagrant en permettant la gestion des déploiements d'applications distantes.
Mitchell Hashimoto, PDG de HashiCorp, et Armon Dadgar, CTO de HashiCorp, ont présenté sur la scène de la conférence HashiConf les quatre qualités qui distinguent Nomad dans le domaine émergent des scheduler d'applications, tels que Marathon qui tourne au dessus de Mesos de Mesosphere, ECS d'Amazon et Kubernetes de Google. Ces qualités qui ont été citées sont la facilité d'utilisation, l'évolutivité, la flexibilité et l'intégration dans l'écosystème de HashiCorp.
Nomad est déployé comme un seul binaire qui gère la mise en commun des ressources, la gestion des jobs, et la planification des tâches, et aucun service de coordination ou de stockage supplémentaire n'est nécessaire (comme ZooKeeper ou etcd). Un agent Nomad est installé sur chaque hôte pour recueillir des informations sur les ressources disponibles (CPU, mémoire, disque). Cette information est envoyée aux serveurs de Nomad, qui sont ensuite chargés d'accepter des jobs, de déterminer quels hôtes ont des ressources disponibles, et enfin la planification des tâches sur ces hôtes.
Nomad est multi-datacenter et multi-région, permettant aux jobs d'être déployés dans différents datacenter et différentes régions. Nomad est conçu pour être résistant aux problèmes réseaux et aux problèmes d'infrastructure ; les serveurs Nomad effectuent une élection du leader et de la réplication d'état pour fournir une haute disponibilité et la tolérance aux pannes. Chaque serveur participe également à des décisions d'ordonnancement, ce qui, selon HashiCorp, augmente le débit total de placement des tâches.
Les jobs ou les création de tâche au sein de Nomad utilisent une spécification de haut niveau unique qui est agnostique à l'artefact de déploiement, ce qui selon HashiCorp permettra aux charges de travail d'être "virtualisées, conteneurisées ou déployées comme des applications autonomes". Nomad peut également être intégré dans l'écosystème de HashiCorp existant, y compris Atlas, la plate-forme payante de livraison d'applications.
Nomad est conçu sur les principes qui guident tous les produits de HashiCorp et se concentre sur le workflow utilisateur, en restant agnostique aux technologies sous-jacentes.
Le nouvel outil de livraison d'applications Otto se fonde sur le succès de Vagrant, premier outil open source de la société qui a été créé en 2010 par Mitchell Hashimoto afin de résoudre le problème de la gestion des environnements de développement. Otto permet le même style de workflow 'vagrant up' pour des déploiements que pour des environnements de développement avec Otto deploy (un concept similaire au modèle de Heroku 'git push heroku master' ou de Docker Compose 'compose up').
La conception des applications et de l'infrastructure sont codifiées à l'aide de l'Appfile' d'Otto. Les Appfiles sont une simple spécification de haut niveau qui permet de déclarer des applications complexes multi-couches qui peuvent être déployées sur plusieurs fournisseurs d'infrastructure en tant que machines virtuelles ou conteneurs. Otto supporte la collaboration sur les fichiers de configuration, stockant de façon sécurisée les informations d'identification, l'enregistrement des configurations, et l'application des politiques de contrôle d'accès, mais l'intégration avec le produit commercial de HashiCorp Atlas est nécessaire pour activer cette fonctionnalité.
InfoQ a récemment discuté avec Armon Dadgar, co-fondateur et CTO de HashiCorp, et posé des questions sur le nouvel ordonnanceur Nomad.
InfoQ : Bonjour Armon, merci d'accepter cette interview. Aujourd'hui, nous allons parler de votre nouveau projet nommé "Nomad". Pourriez-vous nous expliquer brièvement ce que cela est, et quels sont les objectifs que vous aviez lors de la création du projet ?
Armon : Merci de me recevoir. Nomad est un gestionnaire de cluster qui est utilisé pour mutualiser les ressources d'un cluster et simplifier le flux de travail pour l'exécution d'applications sur le cluster. L'objectif est de permettre aux utilisateurs de se concentrer sur leur application et d'abstraire les machines sous-jacentes.
Pour utiliser Nomad, les développeurs soumettent une spécification déclarative de leur job et Nomad s'assure que les contraintes sont satisfaites et que l'utilisation des ressources est maximisée. Nomad est conçu pour supporter des charges de travail, ce qui veut dire supporter Docker mais aussi des applications virtualisées, conteneurisées ou autonomes sur tous les principaux systèmes d'exploitation.
Nomad est motivé par de plus grands objectifs, de promotion des architectures microservices et des infrastructures immuables. Lorsque les entreprises passent aux microservices, ils passent d'une poignée de projets monolithiques à des dizaines, des centaines ou des milliers de microservices. Avec Nomad, chacun de ces services peuvent être gérés comme une tâche très facilement. Sans outils comme Nomad, les défis opérationnels impliqués deviennent un obstacle à l'adoption des architectures microservices.
Aujourd'hui, avec les infrastructures immuables, nous voyons généralement des déploiements faits à la granularité d'une machine, en particulier lorsqu'on utilise des outils comme Packer et Terraform. Bien que cela fonctionne, le processus est inutilement lent en raison du temps qu'il faut pour le provisionnement de nouvelles machines. Au lieu de cela, vous préférez avoir un système d'exploitation de base immuable avec des applications conteneurisées qui sont en couches sur le dessus. Cela prend du temps pour le déploiement, de quelques secondes à quelques minutes. Pour résoudre le défi de déployer ces applications, vous avez besoin d'un outil comme Nomad.
InfoQ : Nomad apparaît très similaire aux gestionnaires et planificateurs de ressources de cluster existants, tels que Borg de Google et le projet Apache Mesos. Nomad ou l'un des algorithmes utilisés dans Nomad reposent-ils sur l'un de ces outils ?
Armon : Le monde de la gestion de clusters est rempli de recherche très excitantes et nous nous sommes bien évidemment inspirés de ces recherches pour construire Nomad. La conception de Nomad a été fortement inspirée à la fois par Google Borg et Omega. Omega est moins connu mais il introduit quelques nouvelles approches pour la concurrence optimiste dans le planificateur, que nous avons adopté dans Nomad. Cela nous permet de prendre des décisions de planification en parallèle pour gérer les charges de travail exigeantes.
Alors que Nomad est un nouveau projet, il se fonde sur des technologies de base : Consul et Serf. Consul permet l'utilisation du protocole de consensus Raft, tandis que Serf est basé sur l'algorithme de gossip SWIM. Ces deux projets sont largement déployés, fonctionnent à très grande échelle, et sont éprouvés en production. Les utiliser dans Nomad a rendu le projet beaucoup plus robuste que cela l'aurait été en repartant de zéro.
InfoQ : L'annonce mentionne qu'à la fois les services persistants de longue durée et des travaux de courte durée seront possibles avec Nomad. Pensez-vous qu'il est important pour les organisations d'être en mesure d'exécuter les deux types de charges de travail côte à côte ?
Armon : En règle générale, la plupart des serveurs sont à 5-20% d'utilisation et cette inefficacité se traduit directement par un surcoût pour les organisations. Nomad permet à ces deux types de charges de travail d'être exécutées sur le même matériel, ce qui augmente l'efficacité et réduit les coûts. Nomad augmente l'agilité des équipes de développement et d'exploitation, ce qui est d'une importance primordiale, mais les augmentations de l'efficience et les économies de coûts sont également énormes, donc je pense réellement que c'est un aspect très important.
InfoQ : Nous remarquons aussi que le support pour l'exécution d'applications Windows est mentionné (en utilisant vraisemblablement des VM ?). Cela a-t-il été mis en œuvre pour soutenir le marché naissant des organisations «Entreprises» qui migrent vers les solutions de gestion cluster ?
Armon : Windows est traditionnellement mal représenté dans l'univers DevOps, mais nous le considérons comme une plateforme de premier niveau au sein de l'écosystème de HashiCorp. Bien que impopulaire parmi les startups, Windows est déployé de manière très large dans l'entreprise. Les avantages d'un gestionnaire de cluster comme Nomad sont amplifiés dans ces environnements car il résout les défis opérationnels et réduit les coûts de façon plus spectaculaire puisque les entreprises fonctionnent à grande échelle.
L'agent Nomad s'exécute directement sur Windows et utilise les pilotes de tâches extensibles, avec le but de soutenir presque toutes les applications Windows. Les charges de travail virtualisées seront prises en charge avec la technologie Hyper-V, les applications conteneurisées avec les futurs conteneurs Windows Server ainsi que C# ou Java.
InfoQ : Nomad est Multi-Datacenter et Multi-Région, ce qui en fait une offre unique. Pouvez-vous expliquer comment cela fonctionne, et discuter des limitations à la mise en œuvre avec la version actuelle ?
Armon : Nomad voit un cluster comme un groupe de datacenters qui forment ensemble une région plus vaste. Par exemple, les zones AWS "us-west-1", "us-west-2", et "us-east-1" pourraient former une région "us-aws" plus vaste. La région "us-aws" pourrait fédérer avec une région "eu-aws" pour former un cluster global.
Les clients Nomad sont configurés avec un datacenter et une région, et interagissent seulement avec leurs serveurs régionaux. Les serveurs fonctionnent au niveau de la région et peuvent prendre des décisions de planification qui couvrent les datacenters dans la région. Les demandes peuvent être faites sur toute la région et sont transmises de façon transparente par les serveurs.
La force de ce modèle est qu'il permet à des jobs de couvrir plusieurs centres de données et fournit une isolation en cas de défaillance au niveau de la région. La limitation est qu'un seul job ne peut pas couvrir plusieurs régions, mais un utilisateur peut soumettre le même job sur plusieurs régions.
La granularité d'une région est décidée par une organisation, afin qu'elle puissent choisir la configuration appropriée à ses besoins. La plupart des organisations peuvent utiliser une seule région du monde pour gérer l'ensemble de leurs datacenters, mais il est tout aussi facile d'avoir un ou plusieurs datacenters par région.
InfoQ : L'annonce met en évidence la "simplicité opérationnelle" pour installer Nomad. Était-ce une exigence essentielle, compte tenu des difficultés que beaucoup d'entre nous au sein de l'industrie ont eu avec le provisionning des applications de gestion de cluster sous-jacentes, tels que ZooKeeper et etcd ?
Armon : La simplicité opérationnelle était notre priorité dans la conception et la mise en œuvre de Nomad. Il y a beaucoup de considérations de conception lors de la construction de tout système distribué, et la plus grande question est d'assurer la coordination et le stockage. Nomad est distribué comme un binaire unique sans dépendances externes et fonctionne d'une manière hautement disponible par défaut.
Le plus grand bloqueur à l'adoption pour les managers de clusters a été leur complexité opérationnelle. Avec Nomad, je pense que nous avons résolu ce problème. Plus les composants d'un système sont mouvants, plus les cas de défaillance à venir seront complexes. Il est difficile de comprendre et maintenir un système distribué, mais obliger les utilisateurs à gérer plusieurs d'entre eux était intenable.
Pour nous, la simplicité d'utilisation se prolonge au-delà de la configuration initiale. Le modèle de Nomad est compréhensible de façon à ce que les utilisateurs puissent raisonner sur le sujet. Les développeurs qui ont besoin de travailler avec Nomad sur une base quotidienne peuvent démarrer en quelques minutes. Les APIs sont facilement consommables de sorte que l'outillage de niveau supérieur puisse être construit. La simplicité et la compréhensibilité conduit à la confiance, ce qui est absolument essentiel pour un système au cœur de votre infrastructure.
InfoQ : Merci pour votre temps aujourd'hui Armon. Y a-t-il autre chose que vous aimeriez partager avec les lecteurs d'InfoQ ?
Armon : Je suis extrêmement fier de ce que nous avons construit avec Nomad, mais nous ne faisons que commencer. Nomad fait partie d'un vaste écosystème d'outils HashiCorp. La prochaine version de Nomad s'intégrera avec Consul, qui apporte beaucoup de nouvelles fonctionnalités. Les jobs Nomad pourront enregistrer des services sur Consul et exploiter les fonctionnalités de découverte de service. Les riches fonctionnalités de Consul permettant de vérifier la santé des services seront exposées sans élargir la portée de Nomad.
Il y a des intégrations prévues pour Atlas et toute la suite de nos outils Open Source. Aider les organisations à répondre aux problématiques de scalabilité pour répondre à la demande et réduire les coûts est une priorité pour nous.
Des détails supplémentaires sur les projets Nomad et Otto sont disponibles sur leurs sites Web respectifs, ou via le site Web de HashiCorp. Plus d'informations sur la conférence HashiConf, y compris un flux en direct et des séances thématiques, sont disponibles sur le site de la conférence HashiConf.