Gérez les livres de cuisine du chef dans un environnement d'équipe

J'apprends le chef et j'ai du mal à tout structurer pour travailler avec mon équipe.

Pour commencer, il semble que vous devriez créer un dossier chef-repo, où vous stockerez et modifierez les livres de recettes utilisés pour gérer vos nœuds.

Je travaille sur divers projets, et chacun d'eux est déjà sous contrôle de source git. Idéalement, je garderais un dossier chef-repo dans chacun de mes projets avec ce projet de livres de cuisine, non?

Cependant, dans le dossier chef-repo, je dois ajouter un dossier de configuration (.chef) avec ma configuration de couteau et mes validations de clés, et celles-ci sont spécifiques à moi. Est-il normal d'ajouter simplement le dossier .chef au fichier gitignore?

Je comprends que les livres de cuisine sont téléchargés sur le serveur du chef pour être ensuite déployés. Comment les autres équipes séparent-elles la mise en scène des environnements de production sans dupliquer beaucoup de travail? Nous avons une branche principale qui est notre branche de production, une branche de développement qui est notre branche de mise en scène (reçoit moins de 5% des demandes du site Web) et des branches de fonctionnalités. La plupart du temps, la branche dev lorsqu'elle est stable est fusionnée à la branche master. Comment pouvons-nous télécharger les livres de cuisine séparément pour pouvoir avoir deux environnements de manière distincte?

Merci pour l'aide!

Je travaille avec plusieurs projets, donc la solution de cjc ne fonctionnera pas pour moi. Il y a aussi un problème de configuration commune vs personnalisée (les adresses, etc. sont communes à l'entreprise, il y a aussi un peu de magie dans les configurations). Le schéma sur lequel j'ai finalement opté est un peu un hack, mais il est pratique à utiliser.

Au lieu de global ~/.chef, j'utilise le sous-répertoire '.chef' dans chef-repo, qui n'est pas stocké dans git (il est ajouté à .gitignore). J'ai également un config/knife.rbfichier qui est archivé dans Git et contient une configuration partagée. Cela commence par cet extrait:

root_dir = File.join(File.dirname(__FILE__), '..')
%w(knife-secrets.rb knife-local.rb).each do |conf_name|
  conf = File.join(root_dir, ".chef", conf_name)
  Kernel::load(conf) if File.exists? conf
end

Cela charge les fichiers .chef/knife-local.rbcontenant une configuration personnalisée (dans la version de base, c'est juste OPSCODE_USER='username'constant qui est utilisé plus tard, mais il peut contenir n'importe quelle configuration de couteau), et.chef/knife-secrets.rb qui contient des secrets partagés (clés AWS, etc.).

En dessous, il y a une configuration de couteau régulière qui utilise des constantes définies dans ces fichiers, par exemple:

client_key               "#{root_dir}/.chef/#{OPSCODE_USER}.pem"

De cette façon, j'obtiens la standardisation de la configuration des couteaux dans toute l'entreprise, ce qui signifie que tout extrait de code ou invocation de couteau partagé dans un wiki fonctionnera pour tout le monde. Il y a suffisamment de confusion et de magie dans le couteau lui-même - différentes configurations ne feraient qu'empirer les choses. De plus, tout le monde profite de petits extraits magiques, comme celui-ci pour faireknife ssh utiliser la connexion configurée dans l'utilisateur~/.ssh/config

Il y a aussi un problème de secrets partagés: clé de validation du serveur chef, clés AWS stockées dans knife-secrets.rb, clé privée SSH d'EC2, clés de sac de données chiffrées, etc. Nous ne voulons certainement pas qu'ils soient stockés dans le référentiel - ou, en fait, partout où ils ne sont pas cryptés en toute sécurité. Nous distribuons donc ces fichiers sous forme de .tar.gzfichier, qui est chiffré par GPG pour tout le monde dans l'entreprise, et partagé sur Dropbox.

La configuration de tout cela devient compliquée, et je veux que les gens de l'équipe utilisent réellement la chose, donc il y a le dernier élément: rake inittâche qui crée le .chefrépertoire, les liens symboliques config/knife.rblà, décrypte et décompresse le chef-secrets.tgzfichier, s'assure que la clé privée de la plateforme Opscode de l'utilisateur est là et.chef/knife-local.rb est correctement configurés, les liens symboliques des plugins et définissent les autorisations appropriées sur le répertoire et les fichiers à l'intérieur. Cette tâche est configurée de façon à pouvoir être exécutée plusieurs fois en toute sécurité sur un référentiel déjà initialisé (par exemple pour mettre à jour des secrets ou des plugins de couteau).

Il existe également une tâche d'assistance qui reconditionne tous les secrets, chiffre l'archive tar pour tout le monde et la copie dans la boîte de dépôt, pour faciliter l'ajout de nouveaux employés ou la modification de secrets.

Concernant plusieurs environnements: Chef a une fonctionnalité appelée environnements . Je ne l'ai pas encore utilisé, mais il devrait faire ce dont vous avez besoin. Vous pouvez également séparer strictement l'environnement de production (pour éviter que les développeurs ne disposent de clés liées à l'environnement de production) en disposant de deux organisations Hosted Chef ou serveurs Chef distincts. Cet extrait de couteau.rb montre comment configurer le couteau d'une manière différente en fonction de la branche actuellement extraite - vous pouvez l'utiliser pour définir l'environnement ainsi que l'URL du serveur chef. Il existe également un plugin couteau appelé couteau-flux , offrant un flux de travail plus complet à deux organisations.

Vous devez configurer deux serveurs Chef, un pour la production et un pour le développement. La raison en est qu'aucun serveur Chef unique ne peut prendre en charge le développement ramifié; même avec des environnements.

Ou vous pouvez abandonner le concept de serveur Chef et utiliser chef-solo. Vous pouvez conserver vos livres de cuisine dans Git. Vous pouvez créer des succursales et fusionner. Vous pouvez ignorer les problèmes liés aux informations d'identification du couteau, car vous ne les utiliserez plus.

Vous ne pourrez pas utiliser la recherche de couteau ou les sacs de données **. Mais certaines personnes n'ont pas besoin de ces fonctionnalités de toute façon.

** Eh bien, vous pouvez en quelque sorte: http://wiki.opscode.com/display/chef/Data+Bags#DataBags-UsingDataBagswithChefSolo

J'ai deux répertoires chez moi, .chef et chef-repo. Le chef-repo est en git. Le .chef est un répertoire privé par défaut pour couteau. Vous n'avez pas besoin de mettre vos secrets de .chef dans git; couteau recherchera ~ / .chef.

Votre répertoire ~ / .chef ne devrait pas être dans le dépôt git.

J'ai un répertoire ~ / projects / dans lequel je garde mon repo de chef. En cela va les configurations de mes serveurs.

Mon dernier emploi était en tant qu'ingénieur systèmes chez Ruby-on-Rails shop. Nos configurations nginx, vernis et rails (entre autres) vont dans le référentiel du chef, mais les applications Rails elles-mêmes ont été conservées dans des dépôts git séparés et ont été déployées séparément.

Notre environnement de transfert était un serveur unique qui exécutait tout l'environnement de transfert. Ce n'était pas idéal car cela ne ressemblait pas à Production où Rails amincit et la DB était sur des boîtes séparées. Ce que je recommanderais, c'est d'utiliser les environnements de Chef pour séparer la mise en scène et la production. (C'est comme ça quand je suis arrivé là-bas, et je n'ai tout simplement pas le temps de régler ça avant de partir.)