Je vais orienter cette réponse comme si la question était "quels sont les avantages du chef solo", car c'est la meilleure façon que je connaisse de couvrir les différences entre les approches.
Ma recommandation récapitulative va dans le sens des autres: utilisez un chef-serveur si vous devez gérer un environnement virtualisé dynamique où vous ajouterez et supprimerez souvent des nœuds. Un serveur chef est également une bonne 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 les rôles et les recettes le seront. La taille et la complexité de votre environnement sont plus ou moins hors de propos. Les deux approches évoluent très bien.
Si vous déployez chef-solo, utilisez un travail cronjob avec rsync, 'git pull' ou un autre mécanisme de transfert de fichier non autonome pour conserver une copie complète du référentiel Chef sur chaque nœud. Le travail cron devrait être facilement configurable pour (a) ne pas s'exécuter du tout et (b) pour s'exécuter, mais sans synchroniser le référentiel local. Ajoutez un nœud / répertoire dans votre référentiel de 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 vous recommande simplement $ (hostname -s) .json. Vous pouvez également créer un compte opscode et configurer un client avec le chef hébergé, si aucune autre raison que de pouvoir utiliser un couteau pour télécharger des livres de recettes de la communauté et créer des squelettes.
Cette approche présente plusieurs avantages, outre l’évident "ne pas avoir à administrer un serveur". Votre contrôle de source sera l'arbitre final de toutes les modifications de configuration, le référentiel inclura tous les noeuds et listes de lecture, et chaque serveur étant totalement indépendant, il facilite certains scénarios de test pratiques.
Chef-server introduit un trou dans lequel vous utilisez le "téléchargement de couteau" pour mettre à jour un livre de cuisine. Vous devez corriger ce trou vous-même (par exemple avec un crochet post-commit) ou vous risquez que les modifications de site soient écrasées en silence par quelqu'un qui "télécharge un couteau". s une recette obsolète du référentiel 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 référentiel maître. 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 grande équipe, cela peut être le cas si vous ne mettez pas de bons contrôles en place.
De plus, avec chef-solo, vous pouvez stocker tous les rôles, attributs personnalisés et listes de contrôle de vos nœuds en tant que fichiers node.json dans votre référentiel principal de chef. Avec chef-server, les rôles et les listes de sélection 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 là que le conflit entre les environnements statiques et dynamiques peut être clairement vu. Si votre liste de nœuds (peu importe sa longueur) ne change pas souvent, il est très utile de disposer de ces données dans le contrôle des révisions. D'un autre côté, si vous créez fréquemment de nouveaux noeuds et en détruisez d'anciens (ne jamais voir leur nom d'hôte ou fqdn), tout garder dans le contrôle des révisions est simplement une gêne inutile, et disposer d'une API pour effectuer des modifications est très pratique. Chef-server a également de nombreuses fonctionnalités destinées à la gestion des environnements cloud dynamiques, comme l'option de nom sur "couteau d'amorçage" qui vous permet de remplacer fqdn comme moyen par défaut d'identifier un nœud. Mais dans un environnement statique, ces fonctionnalités ont une valeur limitée, en particulier si vous comparez les rôles et listes de lancement au contrôle de révision avec tout le reste.
Enfin, les environnements de test de recettes peuvent être configurés à la volée pour ne nécessiter quasiment aucun travail supplémentaire. Vous pouvez désactiver les tâches cron exécutées sur un serveur et apporter des modifications directement à son référentiel local. Vous pouvez tester les modifications 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 modifications et réactiver les tâches cron locales. Toutefois, lors de la rédaction de recettes, vous ne pourrez pas utiliser l’API "Rechercher", ce qui signifie que si vous voulez écrire des recettes dynamiques (par exemple, des équilibreurs de charge), vous devrez modifier cette limitation en collectant les données des fichiers json dans votre nœud / répertoire, ce qui risque d’être moins pratique et de manquer de certaines des données disponibles dans la CMDB complète. Encore une fois, des environnements plus dynamiques favoriseront l’approche basée sur les bases de données, les environnements moins dynamiques conviendront avec des fichiers JSON sur le disque local. Dans un environnement de serveur où un chef doit faire des appels d'API à une base de données centrale, vous devrez gérer tous les environnements de test de cette base de données.
Le dernier peut également être utilisé en cas d'urgence. Si vous résolvez un problème critique sur les serveurs de production et que vous le résolvez avec un changement de configuration, vous pouvez le modifier immédiatement sur le référentiel du serveur, puis le transférer en amont vers le maître.
Ce sont les principaux avantages du chef solo. Il y en a d'autres, comme ne pas avoir à administrer un serveur ou à payer pour un chef hébergé, mais ce sont des préoccupations relativement mineures.
Pour résumer: si vous êtes dynamique et hautement virtualisé, chef-server fournit un certain nombre de fonctionnalités intéressantes (couvertes ailleurs) et la plupart des avantages de chef-solo seront moins perceptibles. Cependant, le chef solo présente des avantages certains, souvent non mentionnés, en particulier dans des environnements plus traditionnels. Notez que le déploiement sur le cloud ne signifie pas nécessairement que vous avez un environnement dynamique. Si vous ne pouvez pas, par exemple, ajouter plus de nœuds à votre système sans publier une nouvelle version de votre logiciel, vous n'êtes probablement pas dynamique. Enfin, dans une perspective de haut niveau, une CMDB peut être utile pour un grand nombre d'éléments liés de manière tangentielle à l'administration et à la configuration du système, tels que la comptabilité et le partage d'informations entre les équipes. Utiliser chef-server pourrait en valoir la peine pour cette seule fonctionnalité.