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

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

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

また、コミュニティー用のクックブック（include_recipe）も用意しています。

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

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

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

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

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

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

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

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

-更新-

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

5. ANSIBLE INSTEADを使用する

2つの問題があります。

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

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

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