翻訳者からの序文
同僚がソース記事へのリンクを私に投げると。 最初は彼女を真剣に受け止めませんでした。 しかし、その後、たくさんの熊手を踏み、いくつかのコーンを詰めると、私は何が起こっているのかを理解しました。
カットの下には、いくつかの一般的な間違いがあります。 同時に、Chefのインフラストラクチャコードを記述して使用するための正しいアプローチが示され、将来の問題を回避するのに役立ちます。
この記事は、ベテランの「料理人」と初心者の両方に役立ちます。
アンチパターン：クッキングコミュニティクックブック
たぶんあなたも。 それはすべて非常に無邪気に始まり、悪いことの前兆とはなりません。 いくつかの属性を追加し、
metadata.rb
変更します。 すぐに、独自のレシピ、さらにはLWRPを追加する必要があります。 特に、クックブックがGitHubで活発に開発されている場合は、変更とコードのコミュニティが混乱しています。 遅かれ早かれ、競合を修正する必要があります。 元のクックブックと変更の両方がほぼ同じ場合、論理エラーを強調表示することは困難です。 そして、このフランケンシュタインをどのようにバージョン管理しますか？ アップストリームと同じバージョンを使用しますか？ 要するに、それは修正するのが難しいアンチパターンです。
「クックブックコミュニティをフォークしない」ルールの唯一の例外は、変更をコミュニティに戻す場合です。 次に、gitでフィッシャーブランチを作成し、プルリクエストを送信する必要があります。 これは、変更がメインブランチにマージされるまで、生きているブランチでなければなりません。
パターン：独自の属性とレシピを使用して独自のラッパークックブックを作成する
コミュニティCookieをフォークする代わりに、Cookieラッパーで「そのまま」使用することをお勧めします。 metadata.rbのこのクックブックラッパーでは、このCookieへの依存関係を登録し、
include_recipe
を使用してCookieコミュニティからレシピを実行する必要があります。 デフォルトの属性を変更する必要がありますか？ 次に、クックブックラッパーでそれらを書き換える必要があります。
gem Chef-Rewindはこのパターンに役立ちます。
アンチパターン：ロールでの属性の使用
ロール内の属性のリストは、プロダクションを破壊する危険なアンチパターンです。 次のシナリオを提示します。 このサーバーにインストールする必要がある2つのサイトの名前と設定の属性を持つ
web_server
ロールがあります。 ここで、これらのサイトを
app_server
と
blog_server
2つのロールに分割する必要があると想像してください。 さて、開発環境でこれをどのようにテストしますか？ チャンスをつかんで、すべてが正常であることを期待するか、Chef Environments（最初はdev、次にqaなど）の属性を上書きし、本番環境に入った後にそれらをクリーンアップすることを忘れないでください。 最良の選択肢ではありません。
クックブックラッパーで属性を使用することをお勧めします。
パターン：クックブックラッパーでの属性の設定
シェフはバージョンアップの方法を知りませんが、kukbuki-はい。 クックブックラッパーで必要な属性を設定し、Chef Environmentでクックブックの目的のバージョンを指定することにより、変更を開発環境から本番環境にプッシュできます。
理想的には、これはテストと変更の段階的なプッシュを伴うCIプロセスの一部である必要があります。 しかし、これは別の話です。
アンチパターン：ロールに実行リストを設定する
シェフの役割は、実行中のレシピのリストを保存するのに理想的なようです。 ただし、このアプローチには、以前のアンチパターンと同じ欠点があります。 ロールの
run_list
でレシピを追加または削除すると、これらの変更は、本番サーバーを含むこのロールを持つすべてのサーバーに適用されます。
これを行う必要はありません：
name "web_server" description "Role for web servers" run_list( "recipe[base_server::disk_configuration]", "recipe[base_server::dhcp_reservation]", "recipe[base_server::pagefile]", "recipe[utility::install_tools]", "recipe[web_server::web_sites]", "recipe[base_server::ssl_certs]" )
パターン：このために特別に作成されたクックブックe（いわゆるrole-cookbookまたはapplication-cookbook）のデフォルトのレシピで実行リストを指定します
役割のレシピの最小リストを保持します。 レシピの完全なリストは、application-cookbookに保存する必要があります。 たとえば、web_serverロールは次のようになります。
name "web_server" description "Role for web servers" run_list( "role[base]", "recipe{web_server]" )
クックブックアプリケーションのデフォルトのレシピは次のようになります。
# web_server cookbook recipes/default.rb include_recipe "base_server::disk_configuration", include_recipe "base_server::dhcp_reservation", include_recipe "base_server::pagefile", include_recipe "utility::install_tools", include_recipe "web_server::web_sites", include_recipe "base_server::ssl_certs"
繰り返しになりますが、これにより、クックブックのバージョンを簡単に管理し、開発環境でバージョン2.1.0への変更をテストできる一方で、本番環境では安定した1.5.0を使用できます。
おわりに
上記のパターンに従うことで、労力と時間を大幅に節約できます。 すべての変更はラッパークックブックに保存されるため、複雑なマージを行う必要はありません。
ロールではなくCookieで必要な属性と
run_list
設定することで、環境のバージョン管理と分離に関する問題が発生しなくなります。