Editer Cette question et cette réponse datent de plusieurs années. Les meilleures pratiques définitives sont enseignées par l'intermédiaire du Apprendre le rallye des chefs des modules de formation à son rythme produits par Chef Software, Inc. L'essentiel de la réponse originale se trouve ci-dessous.
Dans cette réponse, "Chef" ou "chef-client" fait généralement référence à Chef Infra, le produit. Opscode rebaptisé Chef Software, Inc en 2013 . En Avril 2019, Chef a ouvert le code source pour tous ses produits, ainsi que la création d'un nom de marque cohérent.
Je ne sais pas s'il est préférable de configurer les rôles en ruby DSL, en JSON, ou à partir de la console de gestion ? Pourquoi y a-t-il plusieurs façons de faire la même chose ?
Mise à jour 2019 : Les Policyfiles constituent le meilleur flux de travail à utiliser. Les rôles sont considérés comme une pratique inférieure et Chef Software, Inc. recommande de migrer vers les Policyfiles.
Il existe plusieurs façons de faire la même chose, car les flux de travail diffèrent d'une personne à l'autre. Vous choisissez le flux de travail qui convient le mieux à votre environnement. Permettez-moi de vous expliquer les différences afin que vous puissiez prendre une décision en connaissance de cause.
Le DSL Ruby pour les rôles existe pour faciliter l'écriture des rôles sans connaître la syntaxe de JSON. C'est un moyen simple de commencer à utiliser les rôles. Une fois les modifications apportées, vous les téléchargez sur le serveur Chef à l'aide de knife.
knife role from file myrole.rb
Cette opération convertit le rôle en JSON et le stocke sur le serveur. Si vous avez un environnement qui impose le référentiel Chef où vos rôles vivent comme source de vérité, cela fonctionne très bien.
JSON est ce que le serveur Chef stocke, de sorte que vous pouvez également modifier JSON directement dans la console de gestion. Il nécessite plus de champs que le DSL Ruby afin que Chef le reconnaisse correctement pour le télécharger. Ces détails sont cachés dans une certaine mesure par l'interface web.
L'inconvénient de l'utilisation de l'interface web/de la console de gestion pour l'édition des rôles est qu'ils ne se trouvent pas dans votre système de contrôle de version local, à moins que vous ne les téléchargiez depuis le serveur. Vous pouvez le faire avec knife :
knife role show myrole -Fj
En -Fj indique à knife d'"afficher au format JSON". Vous pouvez rediriger la sortie vers un fichier .json si vous le souhaitez.
Mise à jour il y a des années : Il existe des commandes supplémentaires de knife pour travailler avec les fichiers dans le dépôt local de chef. Actuellement, ces commandes ne prennent en charge que les fichiers au format JSON. A communauté RFC est ouverte, qui traitera de l'ajout d'un support pour le DSL Ruby pour ces plugins. Voici un bref résumé du déroulement des opérations.
Vérifier les différences de contenu entre le serveur et le fichier local.
knife diff roles/myrole.json
Télécharger un fichier de rôle au format JSON. Le fichier roles/ est nécessaire. Ce chemin est mappé au même point de terminaison de l'API sur le serveur.
knife upload roles/myrole.json
Télécharger le contenu du serveur en écrasant le contenu du fichier dans le référentiel.
knife download roles/myrole.json
Ces commandes proviennent de knife-essentials qui est intégré dans le paquetage client de Chef.
Pouvez-vous organiser les livres de cuisine en sous-répertoires ? Par exemple, nous avons un logiciel personnalisé pour lequel j'aimerais écrire un livre de cuisine et le placer dans : chef-repo/cookbooks/ourcompanystuff/customsoftwarecookbook, serait-ce une bonne pratique ?
Knife a une idée de l'emplacement des livres de cuisine car il utilise une API pour télécharger les livres de cuisine sur le serveur. Cette attente est définie dans la section knife.rb con cookbook_path . Dans les versions antérieures de Chef Infra, vous pouviez spécifier un tableau de chemins d'accès pour les livres de cuisine, mais cette méthode a été abandonnée car elle nécessitait davantage de maintenance et était source de confusion pour les utilisateurs.
Par convention, nous nommons les livres de cuisine spécifiques à un client ou à un site avec le nom préfixé dans le répertoire du livre de cuisine. Dans votre exemple, il s'agirait de :
chef-repo/cookbooks/ourcompany_customsoftware
Il peut y avoir plusieurs livres de cuisine différents pour "ourcompany" en fonction de ce que vous faites.
Pour plus d'informations :
Dois-je créer un livre de recettes pour chaque type de rôle qui spécifie ce qu'il fait ? Est-ce que ces livres de cuisine incluent d'autres livres de cuisine (par exemple, le livre de cuisine pour mon rôle de serveur web inclut le livre de cuisine d'apache). Je ne suis pas sûr de la manière dont les interdépendances et l'héritage des livres de cuisine sont gérés.
Il n'y a pas de relation directe ou de dépendance entre les rôles et les livres de cuisine.
Les rôles ont une liste d'exécution qui spécifie les recettes et les autres rôles qui doivent être appliqués à tout nœud ayant ce rôle. Les nœuds ont une liste d'exécution qui peut contenir des rôles ou des recettes. Lorsque Chef s'exécute sur le nœud, il développe la liste d'exécution pour tous les rôles et recettes qu'elle inclut, puis télécharge les livres de cuisine nécessaires. Dans la liste d'exécution d'un nœud :
recipe[apache2]
Le chef téléchargera le apache2 pour le nœud afin qu'il puisse appliquer cette recette.
Vous pouvez avoir un livre de recettes spécifique pour un rôle dans votre infrastructure. Plus communément, vous aurez des livres de recettes pour configurer certains types de services comme apache2, mysql, redis, haproxy, etc. Vous les placerez ensuite dans les rôles appropriés. Si vous avez des choses spécifiques à une application qui doivent se produire pour remplir un rôle, vous pouvez les écrire dans un livre de cuisine personnalisé (comme je l'ai mentionné ci-dessus).
Pour plus d'informations :
Existe-t-il quelque chose comme le classificateur de nœuds externe de Puppets pour que les nœuds déterminent automatiquement leur rôle ?
"Oui. Le serveur Chef Infra stocke automatiquement les données des nœuds (en JSON) et indexe automatiquement toutes les données des nœuds à des fins de recherche.
Pour plus d'informations :
Il semble que l'on puisse configurer des choses avec des couteaux ou dans la console de gestion, ou en éditant des fichiers JSON ? Je ne comprends pas pourquoi il y a tant de façons de faire les choses, c'est paralysant ! Il y a une raison d'utiliser l'un ou l'autre ?
Le serveur Chef Infra dispose d'une API RESTful qui envoie et reçoit des réponses JSON. Knife et la console de gestion sont des interfaces utilisateur permettant d'interagir avec l'API du point de vue de l'administration.
Vous pouvez utiliser l'outil que vous préférez, bien que la console de gestion ne dispose pas d'autant de fonctionnalités que Knife. La plupart des utilisateurs de Chef Infra préfèrent l'interface en ligne de commande pour la puissance et la souplesse qu'elle offre, même ceux qui utilisent Chef Infra sous Windows. Pour aller plus loin, knife est un outil basé sur des plugins qui vous permet de créer de nouveaux plugins pour interagir avec le serveur Chef Infra ou avec d'autres parties de votre infrastructure.
Chef Infra est un ensemble de bibliothèques, de primitives et d'API. Il vous offre la souplesse nécessaire pour créer le système de gestion de la configuration qui convient le mieux à votre infrastructure.
Pour en savoir plus :
Comment puis-je provisionner automatiquement des nœuds avec chef dans mon cluster de développement ? Avec Puppet, je lance une VM qui se connecte à Puppermatser et lance une exécution Puppet et se configure (le rôle est déterminé par le classificateur de nœud externe). Comment faire avec chef ? - Installer chef avec des fichiers pem/rb qui le lient à un serveur chef, indiquer manuellement au nœud ses rôles avec knife ou en éditant cela dans l'interface de gestion, puis lancer une exécution de chef-client pour se mettre en place ?
Vous devez utiliser le plugin knife bootstrap. Il s'agit d'un plugin intégré à knife. Vous l'invoquez comme ceci :
knife bootstrap 10.1.1.112 -x root -i ~/.ssh/root_id_rsa -r 'role[webserver]'
Il s'agit de :
- SSH au système cible (10.1.1.112) en tant que
root à l'aide d'une clé SSH (vous pouvez vous connecter en tant qu'autre utilisateur et utiliser ensuite la fonction --sudo ).
- Installer Ruby
- Installer Chef
- Créez le fichier de configuration de Chef pour votre serveur Chef, en lisant la configuration de knife (.chef/knife.rb).
- Copiez la clé privée RSA de "validation", que le nœud utilisera pour s'enregistrer automatiquement auprès du serveur Chef.
- Exécuter
chef-client en utilisant la liste d'exécutions séparées par des virgules spécifiée. Dans cet exemple, seule l'exécution webserver est appliqué.
Cela suppose que le système cible a été provisionné, qu'il dispose d'une adresse IP et que vous pouvez utiliser le SSH en tant que root. En fonction de vos politiques locales et de votre processus de provisionnement, il se peut que vous deviez ajuster la façon dont cela fonctionne. La page knife bootstrap sur le wiki décrit plus en détail comment cela fonctionne.
Knife dispose également de plugins pour un certain nombre de fournisseurs de cloud computing public tels qu'Amazon EC2 et Rackspace Cloud. Des plugins sont disponibles pour les environnements de clouds privés tels qu'Eucalyptus et OpenStack. Il existe également des plugins pour VMware, Vsphere et d'autres. Vous trouverez de plus amples informations dans la documentation.
Pour en savoir plus :
Existe-t-il d'autres bonnes ressources pour les chefs cuisiniers que je pourrais manquer dans mes recherches ?
En Documentation de Chef la première source de documentation.
En Apprendre le rallye des chefs est une série de modules autoguidés qui vous permet de découvrir les différents aspects de Chef Infra et d'autres produits Chef.
J'avais l'habitude de tenir un blog où je publiais des conseils, des astuces et des guides sur Chef Infra : http://jtimberman.housepub.org/ . J'avais une série intitulée " conseils rapides ". En raison de circonstances de la vie réelle et d'autres engagements, je n'ai plus le temps de maintenir le site, mais il se peut que je le reprenne à l'avenir.
Les clients de Chef peuvent obtenir de l'aide et du soutien sur le site d'assistance :
La communauté des utilisateurs de Chef est une excellente source d'aide supplémentaire :
Des ressources supplémentaires sont disponibles sur Site web de Chef Software, Inc. .
J'espère que cela vous aidera.
