チーム環境でシェフの料理本を管理する

私はシェフを学んでおり、チームと連携するためにすべてを構築するのに問題があります。

手始めに、ノードの管理に使用するクックブックを保存および変更するchef-repoフォルダーを作成する必要があるようです。

私はさまざまなプロジェクトに取り組んでおり、それぞれがすでにgitソース管理下にあります。理想的には、各プロジェクトに1つのchef-repoフォルダーを保持し、そのプロジェクトのクックブックを正しく使用しますか？

ただし、chef-repoフォルダーには、ナイフ構成とキー検証を含む構成フォルダー（.chef）を追加する必要があり、これらは私に固有のものです。.chefフォルダをgitignoreファイルに追加するのは普通ですか？

クックブックがchefサーバーにアップロードされてデプロイされることを理解しています。他のチームは、多くの作業を重複させることなく、本番環境からステージングをどのように分離しますか？運用ブランチであるマスターブランチ、ステージングブランチであるdevブランチ（Webサイトのリクエストの5％未満を受け取る）、および機能ブランチがあります。ほとんどの場合、安定版のdevブランチはmasterブランチにマージされます。クックブックを個別にアップロードして、2つの環境を別々の方法で使用できるようにするにはどうすればよいですか？

助けてくれてありがとう！

私は複数のプロジェクトで仕事をしているので、cjcのソリューションはうまくいきません。また、一般的な構成とカスタム構成の問題もあります（アドレスなどは会社に共通です。構成にはちょっとした魔法もあります）。私が最終的に決めたスキームは、ちょっとしたハックですが、使いやすいものです。

globalの代わりに~/.chef、gitに保存されていないchef-repo内の '.chef'サブディレクトリを使用します（これはに追加されます.gitignore）。config/knife.rbGitにチェックインされ、共有構成を含むファイルfile もあります。このスニペットで始まります：

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

これにより、.chef/knife-local.rbカスタム構成を含むファイル（基本バージョンでOPSCODE_USER='username'は後で使用される定数ですが、ナイフ構成を含むことができます）、および.chef/knife-secrets.rb共有秘密（AWSキーなど）を含むファイルがロードされます。

その下には、これらのファイルで定義された定数を使用する通常のナイフ設定があります。例：

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

このようにして、私は会社全体でナイフ構成の標準化を実現します。これは、Wikiで共有されるコードスニペットまたはナイフ呼び出しがすべての人に機能することを意味します。ナイフ自体には十分な混乱と魔法があります-異なる構成はそれを悪化させるだけです。また、誰もが同じように、小さな魔法スニペットの利益を取得し、この1メイクにknife ssh、ユーザーの中に構成された使用ログイン~/.ssh/config

共有シークレットの問題もあります。chefサーバーの検証キー、AWSキーknife-secrets.rb、EC2のSSHプライベートキー、暗号化されたデータバッグキーなどです。リポジトリに保存することは絶対に望ましくありません。実際には、安全に暗号化されていない場所には保存しないでください。そのため、これらのファイルをファイルとして配布し.tar.gzます。このファイルは社内のすべてのユーザーにGPG暗号化され、Dropboxで共有されます。

すべての設定は複雑になり、チームの人々に実際に使用してもらいたいので、最後の要素がrake initあります：.chefディレクトリを作成し、config/knife.rbそこにシンボリックリンクを作成し、chef-secrets.tgzファイルを復号化および展開し、ユーザーのプライベートOpscodeプラットフォームキーが存在し、.chef/knife-local.rb適切にあることを確認するタスク設定され、knifeプラグインをシンボリックリンクし、内部のディレクトリとファイルに適切な権限を設定します。このタスクは、すでに初期化されたリポジトリで何度も実行しても安全であるように設定されています（たとえば、シークレットまたはナイフプラグインを更新するため）。

また、すべての秘密を再パックし、全員にtarballを暗号化し、Dropboxにコピーして、新しい従業員の追加や秘密の変更を容易にするヘルパータスクもあります。

複数の環境について：Chefには、環境と呼ばれる機能があります。まだ使用していませんが、必要なことを行う必要があります。また、2つの別個のHosted Chef組織またはChefサーバーを使用することで、（開発者が本番環境に何らかの形で関連するキーを持たないように）本番環境を厳密に分離することもできます。このknife.rbスニペットは、現在チェックアウトされているブランチに基づいてナイフを別の方法で構成する方法を示しています。これを使用して、環境とシェフサーバーのURLを設定できます。knife-flowと呼ばれるknifeプラグインもあり 、より完全な2組織のワークフローを提供します。

実稼働用と開発用の2つのChefサーバーをセットアップする必要があります。その理由は、単一のChefサーバーが分岐開発をサポートできないためです。環境でも。

または、Chefサーバーの概念を放棄してchef-soloを使用できます。Gitでクックブックを維持できます。分岐してマージできます。ナイフクレデンシャルに関する問題は、今後使用しないため無視できます。

ナイフ検索またはデータバッグを使用することはできません**。しかし、とにかくこれらの機能を必要としない人もいます。

**さて、次のことができます：http : //wiki.opscode.com/display/chef/Data+Bags#DataBags-UsingDataBagswithChefSolo

私の家には、.chefとchef-repoの2つのディレクトリがあります。chef-repoはgitにあります。.chefは、knifeのデフォルトのプライベートディレクトリです。.chefの秘密をgitに入れる必要はありません。ナイフは〜/ .chefを探します。

〜/ .chefディレクトリはgitリポジトリにあるべきではありません。

〜/ projects /ディレクトリがあり、その下にシェフリポジトリを保持しています。これには、サーバーの構成が含まれます。

私の最後の仕事は、Ruby-on-Railsショップのシステムエンジニアとしてでした。nginx、ニス、およびrailsの設定（とりわけ）はシェフリポジトリにありますが、Railsアプリ自体は別々のgitリポジトリに保持され、別々にデプロイされました。

ステージング環境は、ステージング環境全体を実行する単一のサーバーでした。これは、Railsが薄く、DBが別々のボックスにあるプロダクションに似ていないため、理想的ではありませんでした。私がお勧めするのは、Chefの環境を使用してステージングと実稼働を分離することです。（それが私がそこに着いたときの方法であり、私は去る前にそれを修正する時間がありません。）