Je vais orienter cette réponse comme si la question était "quels sont les avantages de chef-solo" car c'est la meilleure façon que je connaisse pour couvrir les différences entre les approches.
En résumé, ma recommandation va dans le sens de celle des autres : utilisez un serveur de chefs si vous devez gérer un environnement dynamique et virtualisé dans lequel vous ajouterez et retirerez souvent des nœuds. Un serveur chef est également un bon CMDB si vous en avez besoin. Utilisez chef-solo si vous avez un environnement moins dynamique où les nœuds ne changeront pas trop souvent mais où les rôles et les recettes changeront. La taille et la complexité de votre environnement sont plus ou moins sans importance. Les deux approches s'adaptent très bien.
Si vous déployez chef-solo, utilisez un cronjob avec rsync, 'git pull', ou tout autre mécanisme de transfert de fichiers idempotent pour maintenir une copie complète du référentiel chef sur chaque nœud. Le cronjob doit être facilement configurable pour (a) ne pas fonctionner du tout et (b) fonctionner, mais sans synchroniser le référentiel local. Ajoutez un répertoire nodes/ dans votre référentiel chef avec un fichier json pour chaque nœud. Votre cronjob peut être aussi sophistiqué que vous le souhaitez en termes d'identification du bon fichier de nœud (bien que je recommande simplement $(hostname -s).json. Vous pouvez également créer un compte opscode et configurer un client avec hosted chef, ne serait-ce que pour pouvoir utiliser knife pour télécharger les cookbooks de la communauté et créer des squelettes.
Il y a plusieurs avantages à cette approche, en plus de l'évident "ne pas avoir à administrer un serveur". Votre contrôle de source sera l'arbitre final de tous les changements de configuration, le référentiel inclura tous les nœuds et les listes d'exécution, et le fait que chaque serveur soit totalement indépendant facilite l'élaboration de scénarios de test pratiques.
Chef-server introduit un trou lorsque vous utilisez le "knife upload" pour mettre à jour un livre de recettes, et vous devez corriger ce trou vous-même (par exemple avec un hook post-commit) ou vous risquez que les modifications du site soient écrasées silencieusement par quelqu'un qui "knife upload "s une recette obsolète à partir du dépôt local obsolète sur son ordinateur portable. Cela risque moins de se produire avec chef-solo, car toutes les modifications seront synchronisées avec les serveurs directement à partir du dépôt principal. Le problème ici est la discipline et le nombre de collaborateurs. Si vous êtes un développeur solo ou une très petite équipe, le téléchargement de livres de recettes via l'API n'est pas très risqué. Dans une équipe plus importante, cela peut l'être si vous ne mettez pas en place de bons contrôles.
En outre, avec chef-solo, vous pouvez stocker tous les rôles, attributs personnalisés et listes d'exécution de vos nœuds sous forme de fichiers node.json dans votre référentiel chef principal. Avec chef-server, les rôles et les listes d'exécution sont modifiés à la volée à l'aide de l'API. Avec chef-solo, vous pouvez suivre ces informations dans le contrôle de révision. C'est ici que l'on voit clairement le conflit entre les environnements statiques et dynamiques. Si votre liste de nœuds (quelle que soit sa longueur) ne change pas souvent, avoir ces données dans le contrôle de révision est très utile. D'un autre côté, si vous créez fréquemment de nouveaux nœuds et détruisez les anciens (pour ne plus jamais voir leur nom d'hôte ou leur fqdn), garder tout cela dans le contrôle de révision est juste un souci inutile, et avoir une API pour faire des changements est très pratique. Chef-server possède également toute une série de fonctionnalités orientées vers la gestion des environnements cloud dynamiques, comme l'option de nom sur "knife bootstrap" qui vous permet de remplacer le fqdn comme moyen par défaut d'identifier un nœud. Mais dans un environnement statique, ces fonctionnalités ont une valeur limitée, surtout si on les compare au fait d'avoir les rôles et les listes d'exécution en contrôle de révision avec tout le reste.
Enfin, les environnements de test des recettes peuvent être configurés à la volée, sans aucun travail supplémentaire. Vous pouvez désactiver les cronjobs exécutés sur un serveur et apporter des modifications directement à son référentiel local. Vous pouvez tester les changements en exécutant chef-solo et vous verrez exactement comment le serveur se configurera en production. Une fois que tout est testé, vous pouvez enregistrer les changements et réactiver les cronjobs locaux. Lors de l'écriture de recettes, cependant, vous ne pourrez pas utiliser l'API "Search", ce qui signifie que si vous voulez écrire des recettes dynamiques (par exemple des répartiteurs de charge), vous devrez contourner cette limitation, en collectant les données à partir des fichiers json dans votre répertoire nodes/, ce qui sera probablement moins pratique et manquera de certaines des données disponibles dans la CMDB complète. Une fois de plus, les environnements plus dynamiques favoriseront l'approche basée sur la base de données, les environnements moins dynamiques se contenteront de fichiers json sur le disque local. Dans un environnement de serveur où une exécution de chef doit faire des appels API à une base de données centrale, vous devrez gérer tous les environnements de test dans cette base de données.
Ce dernier peut également être utilisé en cas d'urgence. Si vous êtes en train de dépanner un problème critique sur des serveurs de production et que vous le résolvez par un changement de configuration, vous pouvez effectuer le changement immédiatement sur le dépôt du serveur puis le pousser en amont vers le maître.
Ce sont les principaux avantages de chef-solo. Il y en a d'autres, comme le fait de ne pas avoir à administrer un serveur ou à payer pour un chef hébergé, mais ce sont des préoccupations relativement mineures.
En résumé : Si vous êtes dynamique et hautement virtualisé, chef-server offre un certain nombre de fonctionnalités intéressantes (couvertes ailleurs) et la plupart des avantages de chef-solo seront moins perceptibles. Cependant, il existe des avantages certains, souvent non mentionnés, à chef-solo, en particulier dans les environnements plus traditionnels. Notez que le fait d'être déployé sur le cloud ne signifie pas nécessairement que vous disposez d'un environnement dynamique. Si vous ne pouvez pas, par exemple, ajouter des nœuds à votre système sans publier une nouvelle version de votre logiciel, vous n'êtes probablement pas dynamique. Enfin, d'un point de vue général, une CMDB peut être utile pour un certain nombre de choses qui ne sont qu'indirectement liées à l'administration et à la configuration du système, comme la comptabilité et le partage d'informations entre les équipes. L'utilisation de chef-server pourrait valoir la peine pour cette seule fonctionnalité.
