web-dev-qa-db-ja.com

シェフのクックブックのバージョンを管理するための最善の戦略

シェフのクックブックのバージョン管理に関するアイデアを探しています。環境内の特定のバージョンを固定していることは承知していますが、どうすればよいかわかりません。

サードパーティのコミュニティブックをクックブックフォルダにインストールするlibrarian-chefを使用します。私たちはそれらの本に触れることはなく、時々より新しいバージョンに更新するだけです。

また、コミュニティー用のクックブック(include_recipe)。

理論的には、カスタムブックが依存するコミュニティブックの特定のバージョンを指定して、環境設定でクックブックのバージョンを設定できますが、問題は、これらのコミュニティブックがバージョンを指定しない他のブックに依存する可能性があることです。そして、その深くネストされた依存関係は続くかもしれません。

そのため、クックブックをchefサーバーにアップロードしても、依存するクックブックも変更される可能性があるため、製品が壊れないという保証はありません。

現時点で確認できる唯一の解決策は、コミュニティやカスタムなど、環境設定で使用するすべてのクックブックバージョンを指定することです。しかし、それから私は各クックブックを調べて、それらのバージョンを理解する必要があります。

また、librarian-chefの更新を随時行っています。変更されたバージョンを追跡するのが難しくなり、環境のバージョンを更新するのを忘れないようにするのは難しいと思います。

あなたの経験とベストプラクティスを共有してください。きっと他の人にも重宝すると思います。

10
gansbrest

Chefを本格的に使い始めて間もなく、同じ問題に直面しました。 4つのことを運用的に始めたとき、私は正気の感覚にたどり着きました。これらはChefコミュニティの一部の人にとって「ベストプラクティス」と見なされない場合があることに注意してください。それにもかかわらず、これが私の正気、再現性、秩序を私の世界にもたらした方法です。

  1. 独自のレシピを作成します。コミュニティのクックブックの使用を完全に停止し、仕様に合わせて独自のレシピを作成しました。この方法で、自分の依存関係を管理および制御します。多くの人がこれに反対しますが、正直に言えば、もし私がOpscodeとコミュニティレシピのいくつかを最初に読んだとしたら、おそらく最初にChefを私のソリューションとして選択しなかったでしょう。私は自分のレシピをシンプルに保ち、自分の仕事のやり方に沿っています。私のリポジトリには、コミュニティクックブックがまったくありません。
  2. アップグレードについては注意が必要です。レシピを更新する場合は、すべての場所で機能することを確認し、たとえどこであっても、展開する手間を追加します。ワークフローを混乱させ、摩擦を加えます。長期的には、これがシェフの正気の鍵です。極端な場合、テスト環境と本番環境など、一部のホストのバリエーションが必要な場合は、クックブックにコーディングします。しかし、私の哲学は、すべてのクックブックの最新バージョンが、必要なすべての場所で安全に適用できることです。
  3. すべてに対してChef Soloを使用します。数か月ごとに、どういうわけか、Chef Serverをもう一度使用してみる必要があると思います。コミュニティ版は改善されていますが、パラダイム全体が私の世界に合わないようです。そして、私が試みるたびに、私はfacepalmと自分自身を蹴ります。 Chef Serverパラダイムは、頻繁なシステム変更を必要とする長期サーバーのある世界に適しています。私はシステムの変更をめったに行わないので、サーバーが常に更新のためにchefサーバーにチェックインするのはばかげています。また、ホストが正常であることを確認するためのはるかに優れたツールがあります。私の仕事は使い捨ての仮想マシンの世界で、1つまたは2つの構成変更にしか耐えられない可能性があります。現在、Chef Soloを排他的に使用しており、変更をホストにプッシュすると同時に、それらを必要とするすべてのホストにまったく同じクックブックをプッシュしています。
  4. Chefの実行中にソフトウェアをコンパイルしないでください。私にとって最も極端な(つまり、愚かな)ケースでは、新しいブートストラップを実行するたびにソースからRuby-1.9.3をコンパイルする必要がありました。ボックス。しかし、カスタムパッケージを作成することは、多くの場合、お尻の痛みになる可能性があります。優れたツール fpm を見つけた後、自分のrpm、deb、gemをパッケージ化するのは簡単になり、私の人生ははるかに効率的で簡単になりました。

これが誰かを助けることを願っています!

-更新-

ほぼ3年後、これらの原則は引き続き私に役立ちました。しかし、もう1つアドバイスを追加します。これは、シェフよりもシェフソロを好んだのと同じ理由です。

  1. ANSIBLE INSTEADを使用
11
platforms

2つの問題があります。

  1. 管理クックブックのバージョン異なる環境オブジェクトで
  2. 管理レシピバージョンノードrun_list内。

記事 クックブックバージョンのエッセンシャル はクックブックバージョンの最良のリファレンスです。 #1によると、異なるバージョンのクックブックを管理して異なる構成セットを提供するのは難しい仕事であり、特にクックブックサイトのほとんどのクックブックがこの仕事をうまくこなさないクックブックの依存関係が混在しているためです。そのため、設定が壊れる可能性があります。また、コンポーネントの実行時の動作をテストしてバージョンを管理しなかった場合は、機能しなくなります。そのため、環境オブジェクトでバージョン番号を指定せずにクックブックをアップロードすることはお勧めできません。したがって、クックブックのバージョンを環境オブジェクトで管理し、新しいクックブックのバージョンをプロモートするときに慎重にテストしてください。私は通常、SCMで環境オブジェクトを管理し、変更されたクックブックが他の既存のコンポーネントで適切に機能するまで、自動化ジョブを介してchefサーバーにアップロードしませんでした。

#2によると、これは実際のレシピ依存関係が各ノードで機能する場所であるため、トリッキーなトピックです。簡単に言えば、重要なノードの場合、ノード/ロール実行リストでレシピのバージョンを指定することで、レシピの依存関係をより適切に制御できます。それは細かいグリットの制御であり、テストや宣伝のコストが高いので、私はほとんどこれをしません。ただし、重要な役割/ノードの場合、これは悪い考えではありませんが、構成の変更に対する保険を提供します。

3
shawmzhu