L'autre jour, je suis tombé sur un outil Canonical Juju.
Les notes provenant d'Internet prétendent qu'il s'agit d'un outil de gestion de configuration comme Chef, Ansible ou Puppet.
J'ai lu en oblique les quais dessus, j'ai regardé dans les dépôts avec des modules de charmes (analogiques des livres de cuisine ou des playbooks) et je soutiens que ce n'est pas le cas.
Juju ressemble plus à un orchestre VM-agnostique (comme Nomad ou Kubernetes). Sur celui-ci, vous pouvez décrire de manière déclarative la configuration de l'infrastructure de l'application: quelles applications nous exécutons, sur quelles machines, en combien de copies, comment elles sont connectées à d'autres services.
Mais contrairement à Kubernetes, il peut fonctionner non seulement avec Docker, mais aussi avec tout type de machines virtuelles.
Ils disent que le noyau, l'agent et le client sont écrits en Golang - et je ne les ai pas regardés.
La partie liée à la configuration elle-même est généralement décrite en combinaison avec YAML et Python (les docks disent que vous pouvez utiliser d'autres langages en plus de python).
Comment tout cela fonctionne-t-il?
Avertissement : cet article ne prétend pas être une description complète et précise, je le vois plutôt comme un moyen d'abaisser le seuil d'entrée pour ceux qui veulent jeter un œil à Juju et aider à naviguer dans la documentation.
La documentation complète est ici: https://docs.jujucharms.com/
Comme déjà écrit ci-dessus, à Juju il y a plusieurs composants:
- Le contrôleur est la partie serveur qui alloue les machines virtuelles. Chaque fournisseur [cloud] a son propre contrôleur (y compris pour les fournisseurs pas tout à fait cloud tels que LXD local ou Metal as a Service ).
Le contrôleur est une application monolithique à partir d'un composant. Au moins une copie du contrôleur doit être exécutée dans chaque fournisseur. Il y a de l'AH, mais je n'y ai pas plongé. - Agent - installez chaque machine virtuelle. Il existe deux types d'agents - pour la machine et pour l'unité. Il semble que l'un d'eux soit placé sur la machine hôte, et l'un d'eux sur la machine virtuelle - je n'ai pas non plus exploré cela en détail.
- Le client est un outil CLI pour gérer toute cette économie.
- GUI
- Une description déclarative de tous les composants utilisateurs (applications, machines, etc.)
- Code personnalisé pour configurer une machine virtuelle distincte, il s'appelle Charms
(En fait, il y a un plus grand arbre de composants, mais pour cette histoire, nous allons le simplifier pour qu'il soit plus facile de comprendre ce qui est quoi)
Sur une description déclarative, vous pouvez construire approximativement les structures de composants suivantes (les graphiques sont dessinés automatiquement par l'interface graphique):
La partie serveur crée en quelque sorte des machines virtuelles là-bas, tire des dépendances, établit des relations entre elles, surveille les signaux qui se produisent - tout semble être assez standard là-bas, comme pour d'autres orchestrateurs.
Et voici les modules de configuration des machines virtuelles appelés charms (unit - charm), regardons de plus près.
Il semblerait que je connaisse Chef, Ansible et Puppet, il n'y a probablement rien de nouveau ici, mais ce n'est pas le cas. Les créateurs de Juju n'ont pas créé de DSL pour décrire de manière déclarative les ressources du système. Au lieu de cela, ils ont créé un cadre qui permettrait au code Python ou Bash complètement normal d'être idempotent et de l'associer à un contrôleur Juju.
Dispositif de charme
Les charmes eux-mêmes ne sont pas très simples. Par complexité structurelle, ils rappellent les livres de cuisine du chef ou les rôles d'ansible. Et en fait, ils sont plus probablement un analogue des ressources, plutôt que des livres de cuisine.
Ils se composent de métadonnées / partie déclarative, de crochets péremptoires (réaction aux événements) et de toutes sortes de fichiers de données tels que des scripts supplémentaires, de la documentation ou des configurations typiques.
La partie déclarative décrit les interfaces de dépendance de charme (par exemple, le charme wordpress dépend de mysql, et le charme mysql fournit cette interface), la compatibilité du système, les balises, les paramètres de configuration (tels que les attributs de cookie) et les couches de programme en fonction d'autres charmes ( par exemple, la plupart des charms incluent une layer:basic ).
Dans les crochets impératifs, une réaction à toutes sortes d'événements externes est décrite. Par exemple, nous install package nécessaire sur l'événement d' install , le configure sur l'événement configure et start service sur l'événement de start .
Tout est écrit sur un python ordinaire avec des décorateurs (quelque part, j'ai lu la déclaration que vous pouvez écrire sur n'importe quoi, même sur un bash, mais je n'ai vu aucun exemple).
Un exemple léger classique est NTP: https://github.com/lampkicking/charm-ntp
Fait intéressant, apparemment, lors de la compilation du charme, une application complètement autonome est obtenue qui peut être exécutée sur le serveur sans dépendances supplémentaires - dans la version compilée, j'ai vu qu'elle incluait le contenu de toutes les couches utilisées, ainsi que les tarballs de tous les modules Python utilisés.
Exemple pour NTP: https://jaas.ai/ntp/32 (voir la liste des fichiers sur le côté droit de la page).
Résumé
Juju a une approche très intéressante et inhabituelle pour décrire et mettre en place l'infrastructure.
Très probablement, le juju a un seuil d'entrée supérieur à celui du chef, les charmes sont probablement plus lents à développer que les livres de cuisine et les livres de jeu et nécessitent plus de compétences en programmation.
D'un autre côté, je suppose qu'un modèle avec des hooks d'événements vous encourage à écrire du code plus correct.
Il me semblait que Juju s'adresse davantage aux programmeurs d'infrastructure (ceux qui ont écrit de nombreux outils CLI sur python sous Linux il y a 5-7 ans), qui doivent maintenant configurer les serveurs, tandis que Chef / Ansible - aux administrateurs, qui au lieu d'un -Deux maintenant vous devez configurer une centaine ou deux serveurs.
Dois-je utiliser Juju en 2019?
Pas sûr:
- Vous allez envelopper de nouvelles applications (natives du cloud) dans docker dans docker et les lancer sur le cuber ou ECS
- Pour les "anciennes" applications, vous avez probablement déjà des scripts de déploiement écrits sur l'ensemble ou le boss
- Pour de nouveaux projets avec une "ancienne" architecture - peut-être. MAIS :
- Presque personne ne connaît Juju dans RuNet, c'est le premier article en russe qui décrit un peu ce que c'est
Si vous travaillez avec Juju, écrivez dans les commentaires où j'ai fait une erreur - après tout, je n'y lis que les quais pendant 2-3 heures.