L'orchestration par Hashicorp - Nomad
Mise à jour :
Nomad est un orchestrateur qui permet d’utiliser d’autres ressources que les containers, comme les GPU Nvidia, les applications JAVA, les outils de virtualisation QEMU, firecrackers, …
Nomad intègre Consul, un autre outil d’HashiCorp qui offre des fonctionnalités de découverte et de configuration de services d’une infrastructure. Il permet aussi de stocker des données de type Clé/Valeur.
De la même manière Vault, aussi autre outil d’HashiCorp qui permet entre de stocker des secrets de manière sécurisé est facilement intégrable à Nomad.
Grâce à sa conception Nomad peut être déployé sur plusieurs datacenters et régions lui permettant d’être hautement disponible et tolérant aux pannes.
Nomad est fourni sous la forme d’un seul binaire permettant de configurer soit des masters nodes (3 ou 5), soit des workers nodes (les masters nodes peuvent aussi assurer la fonction de worker). Ce binaire est donc installé sur toutes les machines du cluster et recueille les informations sur les ressources disponibles (CPU, mémoire, disque) pour les envoyer au controller du cluster Nomad. C’est aussi ce même binaire qui permet de charger les workloards via des manifests écrits en HCL (comme pour Terraform )
Je pense que cela suffit pour vous convaincre que Nomad système semble bien plus simple à mettre en œuvre qu’un cluster Kubernetes. Et cela, sans pour autant faire l’impasse sur les fonctionnalités. En effet, on retrouve les mêmes fonctions que celles offertes par un cluster Kubernetes “from scratch”.
Installation d’un cluster Nomad
Je vais comme d’habitude utiliser une stack Vagrant pour déployer un master
node et un worker node sur une machine Linux avec Libvirt comme
hyperviseur. Vous pouvez adapter le VagrantFile
pour qu’il fonctionne avec
d’autres hyperviseurs comme VirtualBox. Vous pouvez vous inspirer du
playbook pour l’installer sur d’autres plateformes comme AWS, GCP,
Azure, …
Le code source se trouve ici ↗. Commençons par le récupérer :
Le contenu du VagrantFile
:
Le playbook Ansible :
On commence par installer les repository Docker et Hashicorp pour installer docker, consul et nomad sur tous les noeuds. Docker est démarré sur tous les noeuds.
Ensuite vient la partie configuration des masters nodes avec le
démarrage du service Consul et Nomad. Pour le cluster Nomad il copie le fichier
de configuration nomad.hcl
dans le répertoire /etc/nomad.d/
.
On indique bien que nous attendons qu’un seul noeud master et que ce noeud peut
aussi faire office de worker node client enabled = true
.
La configuration des workers nodes est un peu différente puisque nous devons lui indiquer l’adresse des masters nodes :
hcldata_dir = “/opt/nomad/data” datacenter = “dc1”
client { enabled = true servers = [“10.240.0.10”] }
Présentation du dashboard Nomad
Le dashboard ↗ est disponible sur le port 4646 du master node.
Ce dashboard permet de retrouver toutes les informations des objets du cluster Nomad mais aussi de les gérer. On peut ainsi gérer les masters et workers nodes, les jobs et la partie stockage.
La vue Topology offre une vue synthétique du cluster :
Présentation du dashboard Consul
Pour rappel, Consul est un outil de découverte et de configuration de services et offre également une base de données Clés/Valeurs. Dans le cluster Nomad c’est lui qui s’interfacera avec un load balancer.
Utilisation de la CLI Nomad
Comme dis plus haut, le binaire nomad
permet de gérer le cluster Nomad et
ses ressources. Pour accéder à un cluster depuis une machine distante il
suffit d’indiquer son adresse via la variable NOMAD_ADDR
:
Vous l’aurez compris, cette première commande permet d’installer la partie auto-completion (vérifiez votre fichier .bashrc et .zshrc).
Pour connaitre le status d’un cluster, on utilise la commande agent-info
:
Pour afficher le status des masters nodes :
Pour les workers nodes :
Lancer vos premiers workloads
Avant de lancer un premier job, quelques définitions des objets Nomad :
job : Un job est l’object de plus haut niveau qui définit un ou plusieurs groupes de tasks qui contient une ou plusieurs tasks.
task group : Un groupe de tasks est un ensemble de tasks qui doivent être exécutées ensemble. Un groupe de tasks est l’unité de planification, ce qui signifie que le groupe entier doit s’exécuter sur le même nœud client et ne peut pas être divisé.
task : Une task est la plus petite unité de travail dans Nomad. Les tasks sont exécutées par des task drivers.
task driver : Un pilote de task indique le type de ressource qui est utilisé
evaluation : Les évaluations sont les mécanismes par lequel Nomad prend des décisions de planification. Comme pour kubernetes, Nomad, se charge de réconcilier l’état actuel du cluster avec celui déclaré dans les manifests.
Création de nombre premier job
Je vais utiliser un exemple que j’ai trouvé sur le site medium ↗. C’est le déploiement d’un jeu de 2048 fournit sous la forme d’une application web.
Voici la spécification du job :
Quelques explications : On déploie le job qui est du type service
sur
le datacenter dc1
. Ce job est composé d’un groupe game
dont le
nombre d’instance est fixé à 1
. Ce groupe expose le port 80
et est
composé d’une task. Cette task utilise le driver docker
et fait appel
à une image “alexwhen/docker-2048”. Les limites de ressources sont fixés à
500Mhz pour le CPU et 256MB pour la mémoire.
Vous voyez nous sommes très proches de ce que l’on retrouve sur du Kubernetes.
Lançons le job :
Notre premier Job est déployé. Pour accéder à l’application depuis votre
navigateur, il faut indiquer l’adresse ip du node où est déployé le job.
Par exemple : http://192.168.121.235
. Je ne maitrise pas encore la partie
ingress. Cela fera l’objet de prochains billets.
Pour stopper un job :
Le Job reste au plan, mais n’utilise plus de ressources. Vous pouvez la
redémarrer à tout moment avec la commande start
. Si vous souhaitez le faire
disparaître il suffit d’utiliser la commande suivante (comme avec Docker) :