Comment Juju "coexiste-t-il" avec Chef, poussant le processus d'automatisation "plus loin"?

Question

Il ressort clairement de this post que Juju se situe sur une couche différente de celle de Chef Server. Juju se trouve au niveau de la couche orchestration ou service, tandis que Chef occupe davantage au niveau du serveur individuel ou de la couche configuration.

Dans ne des pages principales de Juju de Canonical , il est indiqué que Juju est conçu pour "coexister" avec des outils tels que Chef et Puppet, ce qui "accélère le processus". J'ai parcouru Internet pendant plusieurs semaines à ce sujet et je ne trouve pas une bonne explication de comment , cependant, un outil comme Chef sera coexistent avec Juju.

Donc, pour décomposer la question globale dans le titre: (intérêt particulier pour Juju travaillant avec un serveur Chef)

Qu'est-ce qu'un exemple de charme "écrit dans Chef"? Est-ce simplement un charme écrit en bash qui appelle ensuite la commande chef-solo? Si tel est le cas, un charme peut-il appeler la commande chef-client pour travailler de concert avec un serveur Chef?
Où se trouve le chevauchement entre Juju et Chef? Par exemple, le charme Apache2 a son crochet config-changed où il apporte des modifications de configuration qui, dans le monde de Chef, auraient lieu dans une recette en appliquant un fichier de modèle. Si un charme Juju devait fonctionner avec un livre de recettes de chef pour le déploiement d'un service Apache2 (cluster), il semblerait presque qu'un charme "Apache2-chef" devrait être écrit pour que vous puissiez séparer les tâches. Dans ce cas, le charme Apache2 dans Charm Store serait moins utile.
Si des rôles de chef sont appliqués aux nœuds (unités de service) déployés/gérés par Juju et que votre administrateur système décide de modifier les règles de pare-feu pour un rôle de serveur particulier, Juju va-t-il écraser ces modifications à un moment donné?
Plus simplement, Juju peut-il être un wrapper Chef Server, comme Ironfan ?

Je considère Chef Server comme comment alors que Juju peut faire le comment, mais apporte également quoi à la table. Cela signifie que l’état actuel des services et des machines peut être interrogé et traité. Vous ne pouvez pas faire cela dans Chef Server. Mon objectif est d'intégrer les capacités de Juju en matière de notoriété et d'orchestration des services dans une infrastructure gérée par le serveur Chef.

Il semble presque qu'il faille écrire un ensemble de charmes où toutes les informations de tâches/config gérées par le chef sont omises.

J'adorerais entendre des pesées de quelqu'un chez Canonical (comme Jorge Castro) et d'Opscode (comme A. Jacob ou J. Timberman).

m_3 · Accepted Answer

questions géniales!

le tl; dr

J'aimerais décomposer votre (vos) question (s) en quelques commentaires ... Tout d'abord, voici quelques approches générales de l'intégration du chef et du juju:

les crochets d'attelage peuvent utiliser les recettes de chef existantes qui fonctionnent en mode solo sur des unités de service (recommandé)
les unités de service juju s'enregistrent auprès d'un chef-serveur existant via un service subordonné chef-nœud

Ces idées n'ont pas été mises en œuvre/sont encore testées pour le chef, mais les équivalents de marionnettes existent.

le ... euh .. réponse pas si courte

Voici un peu plus de détails sur deux approches d'intégration du chef et du juju:

Juju comme chien de tête

Ici juju dirige le spectacle. La plus grande valeur apportée par juju est la coordination des événements lors de la gestion de configuration distribuée ... d'où le surnom de "service d'orchestration". Les breloques Juju se composent de crochets appelés par juju au "bon moment" lors de la coordination de la gestion des services. La mise en œuvre de ces crochets est quasiment ouverte. Ce sont des scripts Shell, du code source, des manifestes de marionnettes ou ... des recettes de chefs.

Juju divise des morceaux de n'importe quel service config en:

"installation" .. les bits spécifiques à l'installation d'un service particulier sur un nœud
"relation" .. les bits de config nécessaires pour relier ce service à un autre service

La clé pour utiliser les recettes de chef comme implémentation de hook est exactement cela ... vous devez vous assurer que les recettes que vous utilisez respectent cette séparation des préoccupations. Sinon, rien n'empêche d'utiliser des livres de cuisine disponibles dans le commerce. Vous pouvez exploiter les recettes existantes que vous avez dépensées en temps/argent pour développer ... Vous devez simplement vous assurer que vous pouvez appeler les éléments spécifiques à la relation séparément des éléments spécifiques à l'installation.

Nous avons besoin de quelques exemples de cela, mais je pense que ce sera populaire car le chef a un excellent dsl, un excellent outil de templates, et est beaucoup plus agréable à utiliser que Bash lors de l’écriture de configurations complexes. Pour une configuration simple, les recettes de chef sont un peu exagérées, alors cette méthode d'intégration est à peu près le meilleur des deux mondes ... et a des jambes sérieuses pour l'avenir.

Chef comme top-dog

L'idée ici est d'intégrer les services juju dans une infrastructure gérée existante serveur-chef. Pour ce faire, vous devez écrire un charme subordonné chef-noeud. Ce service subordonné serait associé aux services juju principaux et enregistrerait effectivement ces services en tant que nœuds (dans des rôles particuliers) avec le serveur chef. Les abonnés peuvent être connectés au démarrage du service juju ou à tout moment plus tard au cours du cycle de vie de chaque service.

Je pense que ce serait assez similaire au sous-nœud marionnette. Toutes les clés, rôles, etc. nécessaires seraient spécifiés via la configuration du charme subordonné chef-noeud. Je commencerais par là. Une approche plus sophistiquée consisterait pour le sous-chef chef-nœud à interroger à la fois le service principal auquel il est attaché et son chef-serveur pour déterminer de manière dynamique les rôles, mais ce serait un peu plus difficile que de simplement les spécifier dans la configuration pour le sous-mandataire.

Des avis

Je recommanderais certainement la méthode 1 ci-dessus, si possible. Avoir la couche de coordination sur haut des outils de configuration fonctionnera probablement bien à long terme. Inutile de dire que les infrastructures du monde réel peuvent être une combinaison ou une variation des deux approches sur une période donnée… en particulier pendant la migration. La coexistence planifiée à l'aide de la méthode 2 ne fonctionnerait probablement que si les composants gérés par les deux outils étaient quelque peu orthogonaux. Je ne sais pas exactement à quoi cela ressemblerait. Juju et le chef peuvent-ils gérer des services séparés relativement découplés? Je pense que cela pourrait bien fonctionner de laisser juju gérer les services primaires et de laisser le chef gérer davantage d’infrastructures. Dunno. C'est un peu une discussion plus longue cependant :)

Remarque secondaire ... vous pouvez également utiliser juju pour gérer le serveur chef lui-même ... même les grandes installations complexes à plusieurs niveaux. Je n'ai pas examiné le charme chef-serveur ces derniers temps, mais s'il ne gère pas actuellement la hiérarchisation et la séparation des services, vous pouvez le faire.

J'adorerais voir plus d'exemples des deux types d'intégration de chefs mentionnés ci-dessus ... c'est sur ma liste de souhaits/choses à faire depuis un moment, mais n'a pas encore annoncé suffisamment de priorités pour être terminé ... aidez-moi si vous êtes intéressé!

ok, c'est un morceau décent de randonnée:) ... commençons par là, ensuite nous pourrons entrer plus en détail dans les blocs de commentaires suivants.