Home Tags Anciens articles Mon CV

Juju : le verdict

J’en ai parlé sur les réseaux sociaux, je me suis finalement décidé à tester Juju. Au départ, j’étais même très enthousiaste et je pensais faire un article-tuto sur la configuration et l’utilisation de Juju et de conjure-up.

Mais quelques heures de tests, cafouillages, scratch, d’autres tests, me voilà moins enthousiaste, disons plus mesuré. Il m’est donc apparu qu’il serait plus profitable de faire un article sur mon ressenti et mon retour, et c’est ce que je vous propose ci-dessous.

Qu’est-ce que c’est

Juju est un outil de configuration/déploiement automatique de stack logicielles. Il permet de déployer via des charms des ensembles de composants dans un cloud de votre choix parmi les suivants:

➜  ~ juju clouds
Cloud           Regions  Default          Type        Description
aws                  15  us-east-1        ec2         Amazon Web Services
aws-china             2  cn-north-1       ec2         Amazon China
aws-gov               1  us-gov-west-1    ec2         Amazon (USA Government)
azure                27  centralus        azure       Microsoft Azure
azure-china           2  chinaeast        azure       Microsoft Azure China
cloudsigma           12  dub              cloudsigma  CloudSigma Cloud
google               18  us-east1         gce         Google Cloud Platform
joyent                6  us-east-1        joyent      Joyent Cloud
oracle                4  us-phoenix-1     oci         Oracle Cloud Infrastructure
oracle-classic        5  uscom-central-1  oracle      Oracle Cloud Infrastructure Classic
rackspace             6  dfw              rackspace   Rackspace Cloud
localhost             1  localhost        lxd         LXD Container Hypervisor

Notez plusieurs choses :

  • Le petit dernier n’est pas un cloud, il permet de déployer vos Charms sur un hyperviseur LXD local.

  • Certains clouds ne peuvent être utilisés que si vous avez des credentials corrects (aws-gov par exemple).

  • Pour chaque cloud, la région indiquée est la région par défaut, vous avez le nombre de régions disponibles dans la colonne Regions.

Concrètement, les clouds affichés sont les clouds potentiels.

Et les Charms dans tout ça ? Hé bien, ce sont les recettes au format YAML que Juju lit et finalement, suit. Un peu à la manière d’un run Ansible ou d’un plan Terraform. Certains embarquent même de l’Ansible pur, d’après ce que j’ai pu voir. Ils peuvent être trouvés sur le Charms Store et sont en général accompagnés d’un README expliquant comment les exploiter.

Juju fonctionne également en mode As A Service, via une interface permettant de designer un Charm et de le déployer sur le cloud voulu, tout ça en mode putaclic. Ça peut être pratique aussi.

Enfin, pour ceux qui craindraient que JAAS (c’est le petit nom de l’interface et du workflow) créé des petits un peu partout dans leur cloud sans qu’ils aient moyen de savoir quoi supprimer après leur test, sachez qu’un bouton destroy existe sur l’interface pour faire le ménage de ce qui a été monté.

Concrètement, mon retour d’utilisation

J’ai utilisé Juju pour déployer quelques stacks, d’abord en local sur mon hyperviseur LXD. Notez au passage qu’il faut une bonne machine pour faire tourner le tout, idéalement un Core i7, 8 Go de RAM. Puis, je l’ai utilisé pour déployer des stacks genre Gitlab dans AWS, et pour finir j’ai utilisé l’interface JAAS pour déployer dans AWS.

Je ne suis pas allé jusqu’à créé des Charms, mais j’ai pu lire le code de certains pour me rendre compte de ce que c’est et apprécier le niveau de complexité.

Dans mon utilisation donc, je me suis rendu compte de deux choses principalement :

  1. En déployant des Charms développés par d’autres personnes, je ne suis pas maître du nombre de noeuds affecté par ressources, du nom et de la taille des instances lancées, des versions des softs composants la stack… C’est donc assez monolithique et plutôt boîte noire. Étonnamment, je trouve plus de souplesse dans l’interface de JAAS qui permet de choisir, pour un composant, le nombre d’instances pour une ressource et d’autres paramètres.

  2. Développer un Charm est clairement plus long et compliqué qu’un plan Terraform. Mais au delà de ça, c’est surtout beaucoup moins souple et aussi moins précis dans la granularité.

Cela n’en fait pas un mauvais outil. Je pense que ça doit convenir à certaines productions, ne serait-ce que pour un gain de temps au déploiement et pour “zapper” la configuration des clouds.

Il est certain que pour le développeur qui ne comprends rien au déploiement et qui veut tout un gitlab prémaché dans le cloud et prêt à l’utilisation, c’est idéal.

Je n’ai pas testé de scaler un environnement déjà en place, si vous avez des retours sur cette utilisation, je serais heureux de les lire.

Pour ma part, je conserve le couple Ansible / Terraform, dans lequel je trouve une granularité et une simplicité hors normes, et plus important que tout, un confort d’utilisation incomparable. Pour créer des infrastructures comme pour les faire évoluer, voire même pour les faire prendre en main à quelqu’un qui arrive dans le projet. C’est clair, c’est lisible, j’aime ça.

Il y a de nombreux outils out there, ce n’est qu’une question de besoin et de goût. Pour ma part, je n’exclue pas de re-tester Juju un jour, voire de l’utiliser en production.