Provisionnement Juju et Openstack
Je suis nouveau sur Juju et Openstack et je déploie actuellement un environnement de test openstack à deux et trois nœuds à l'aide du fournisseur manuel Juju. Lors de ma première tentative, j'ai essayé de déployer des services sur mes hôtes à l'aide de la touche --to pour le déploiement de juju.
J'ai réalisé que quelque chose allait mal lorsque Juju n'a pas réussi à créer une relation entre Keystone et MySQL déployé sur le même hôte. Pour déployer des services, j'ai utilisé la syntaxe suivante:
juju deploy keystone --to 1
juju deploy mysql --to 1
Une recherche sur Google m'a donné cette question sur askubunt et ce guide .
Donc, si je comprends bien, la bonne façon de déployer des services dans un environnement manuel consiste à utiliser des conteneurs lxc pour les services déployés sur le même hôte (si ces services peuvent fonctionner dans des conteneurs, bien sûr).
Bien que je vois de tels avantages de lxc comme l'indépendance et l'isolement des services, je ne comprends toujours pas pourquoi les services déployés par Juju DOIVENT être isolés dans des conteneurs. Est-ce un défaut de conception de Juju ou une solution temporaire?
Existe-t-il un moyen de déployer quelques services sur le même hôte sans lxc?
Je pense que cela peut être fait en spécifiant le fichier de configuration pour chaque service déployé, mais cela éliminerait presque toute la "magie" et la simplicité de Juju ...
Juju lui-même s'en moque. C'est aux charmes que vous déployez pour gérer la situation, ou non. Ce n'est donc pas du tout considéré comme un problème; c'est simplement une différence entre ce que Juju soutient, ce que les charmes soutiennent généralement et les meilleures pratiques acceptées.
Je ne pense pas que cette réponse soit spécifique au fournisseur manuel. Elle s'applique à tous les fournisseurs.
La plupart des charmes supposent qu'ils "possèdent" la machine (ou le conteneur) sur laquelle ils sont déployés, et dans le passé, c'était la seule façon de les déployer.
Cet isolement rend les charmes plus faciles à développer et à tester. Il élimine le besoin pour les développeurs de charmes de se soucier du partage des ressources avec d'autres charmes. Un déploiement modulaire facilite la gestion de la complexité. En limitant les interactions entre les charmes aux relations Juju, ils peuvent rester propres et bien compris. Les auteurs de charme n'ont pas à se soucier de faire des changements au niveau du "système" qui pourraient avoir un impact négatif sur d'autres charmes; c'est à la conteneurisation de gérer cela correctement. Cela élimine toute une classe de bogues de charme où un charme affecte négativement un autre.
Ainsi, dans la pratique, les charmes doivent être déployés au minimum dans leurs propres conteneurs, à moins qu'ils ne soient spécifiquement conçus pour fonctionner ensemble. Les conflits qui surviennent lorsque deux charmes sont déployés sur la même machine sans les placer dans des conteneurs ne seront généralement pas traités comme des bogues.
Cela ne devrait pas affecter beaucoup. LXC est léger.
Rien de tout cela ne vous empêche d'écrire vos propres charmes, ou de modifier des charmes existants, pour leur permettre d'être déployés sur la même machine ou le même conteneur. Juju le permettra, mais c'est aux charmes de s'assurer qu'ils n'entrent pas en conflit.
Est-ce un défaut de conception de Juju ou une solution temporaire?
Non - ce n'est pas du tout un Juju; il s'agit de la meilleure pratique choisie par les auteurs de charme, et se rapporte aux décisions prises sur les configurations de déploiement que les charmes devraient et ne devraient pas prendre en charge.
Il y a des cas Edge où cela est utile et pas difficile à prendre en charge (par exemple, l'interface graphique Juju s'exécutant sur le nœud bootstrap), donc Juju le permet. Je pense qu'il n'y a pas de plan pour Le soutien de Juju au changement.