Vous utilisez Juju avec un déploiement cloud privé Openstack?
Je constate un certain nombre de problèmes lors de l'utilisation de Juju avec notre cloud Openstack déployé en interne. La plupart de ces problèmes semblent être centrés sur la résolution de l'hôte DNS ainsi que sur la nécessité de traiter avec les mandataires HTTP internes de notre entreprise.
Notre déploiement Openstack repose sur un bloc d'adresses 172.16.0.0/12 non routable pour l'allocation VLAN à chaque projet (locataire) hébergé sur notre cloud interne. L'utilisateur a la possibilité d'attribuer une ou plusieurs adresses flottantes aux instances, attribuées à partir d'un bloc d'adresses routables sur le réseau local de nos sociétés internes.
Actuellement, Openstack n'enregistre pas les noms d'instance avec autre chose que le service DNSMASQ exécuté sur le contrôleur cloud. En tant que tel, il n'y a aucun moyen de résoudre cette adresse via notre hiérarchie DNS interne (ce problème a déjà été signalé comme bogue n ° 945505). En tant que tel, même si je peux bootstrap mon nœud de serveur Juju, je ne peux pas me connecter avec le client Juju, car il ne peut pas résoudre le nom du réseau local (privé). Je suis capable de ssh vers le nœud, une fois que je lui ai attribué une adresse routable en interne (c'est-à-dire flottante), ce qui conduit au problème suivant.
Ensuite, pour installer un logiciel sur une instance exécutée dans notre cloud, il doit avoir notre adresse proxy interne définie - soit dans le fichier apt.conf, soit via des variables d'environnement. Malheureusement, lors du démarrage du nœud de serveur, il n'est pas prévu de passer ces informations dans une instance via le fichier JuJu environment.yaml (si c'est même le meilleur moyen de gérer ce problème). Par conséquent, le nœud bootstrap n'est pas en mesure d'installer les packages requis.
Je suppose (dangereux, je sais) que la façon dont j'ai déployé Openstack dans notre environnement interne n'est probablement pas unique. Quelqu'un d'autre a-t-il rencontré ces problèmes? Et plus important encore, des solutions de contournement sont-elles disponibles?
Après le déploiement/amorçage, Juju tentera de se connecter à l'environnement via l'adresse publique des instances. AFAIK, il obtient cette adresse directement à partir de l'appel decrire_instance (s) de l'API EC2. Dans votre environnement, de nouvelles instances apparaissent avec une adresse interne/privée et aucune IP publique (flottante) associée. Le résultat est une adresse privée dans les champs d'adresse privée et publique de describe_instances. Après avoir associé une IP flottante à l'instance, le champ d'adresse publique doit maintenant afficher la nouvelle adresse associée.
Une fois associé, Juju devrait pouvoir se connecter correctement via SSH (tout comme vous le pouvez). Ainsi, vous devriez pouvoir "juju bootstrap", associer l'IP à bootstrap node, "juju status". Vous devrez également associer des IP flottantes à toutes les autres machines déployées. Une option est pour ajouter le '--auto_assign_floating_ip' à nova.conf, afin que l'association IP flottante se produise automatiquement lors de la génération d'instance.
En ce qui concerne le problème du proxy vers apt, ce serait formidable si Juju permettait aux utilisateurs de personnaliser la configuration cloud qui est transmise à de nouveaux nœuds pour démarrer les agents Juju. Si cela était possible, vous pouvez configurer vos proxys apt avec la configuration cloud spécifique à juju. Comme ce n'est pas actuellement pris en charge, une option serait de publier une image cloud personnalisée dans Glance qui contient un apt.conf pour votre environnement, et de définir default-image-id dans environnement.yaml à cet ID AMI.