この記事は、
Opscode Chef構成管理システムの使用を開始または計画している人を対象としています。
Chef 、
Puppet、またはその他の構成管理システムを実装する主なタスクは、ソフトウェア開発で使用されるすべての環境（dev、CI、QA、stage、production）の環境を繰り返し更新することです。 したがって、構成の説明自体を明確に保存および更新する必要があります。 残念ながら、Chefのバージョン管理オプションは非常に限られています。 そのため、シェフと共同で最近
Librarianを積極的に使用し始めました。 しかし、それについて話す前に、料理の本について少し話しましょう。
クックブック（詳細については、
ここで読むことができ
ます ）は、3つのタイプに分類できます。
- community.opscode.comのクックブック
- GitHubやその他の場所の料理本。
- 独自のプロジェクトクックブック。
プロジェクトでは、バージョン管理システムの制御下で、すべてのCookieをクックブックフォルダーに入れることができます。 そして、これがあなた自身のクックブックにとって唯一の合理的な方法である場合、最初の2種類のクックブックでは、このソリューションはかなり奇妙に思えます。 更新を確認し、依存関係を管理し、そのようなCookieを「手動」モードで更新する必要があるという単純な理由から。 特に、クックブックを取り、それをクックブックフォルダーに追加するだけでは、後でそれをどこから取得したかを覚えることは非常に困難です。 GitHub cookieはgitサブモジュールとして保存できますが、ここにリストされている問題のほとんどは解決しません。
さらに、使用するクックブックのいずれかに依存関係がある場合（クックブックのmetadata.rbファイルに登録されている場合）、プロジェクトに依存関係を手動で追加する必要があります。
Librarianを使用すると、これらの問題をすべて回避できます。 これは、Cookieの依存関係とバージョンを管理するのに役立つツールです。
ほぼ同じことを行う同様のプロジェクト、
Berkshelfがまだあります。 Librarianよりも遅く登場し、多くの依存関係をもたらし、インストールが2倍少なくなります（
rubygemsで判断 ）が、文書化の方が若干優れています。 それらのいずれかの選択は、専ら好みの問題です。 依存関係記述ファイルは同一であるため、いつでも別のツールに切り替えることができます。 Librarianを使用しますが、以下に書かれていることはBerkshelfにほぼ完全に関連しています。
クックブックをほとんど使用しない非常にシンプルなプロジェクトを想像してください。 最初の
Cheffileファイルを作成する
initコマンドでライブラリアンの使用を開始しましょう。使用するCookieの説明が保存されます。
$ librarian-chef init create Cheffile $ cat Cheffile site 'http://community.opscode.com/api/v1'
ファイルに1行追加して、
librarian-chef installを実行します
$ cat Cheffile site 'http://community.opscode.com/api/v1' cookbook 'lvm' $ librarian-chef install Installing lvm (0.8.6)
このコマンドは、必要なすべてのCookieをクックブックフォルダーに入れ、
Cheffile.lockファイルを作成します。
$ ls cookbooks lvm $ cat Cheffile.lock SITE remote: http://community.opscode.com/api/v1 specs: lvm (0.8.6) DEPENDENCIES lvm (>= 0)
プロジェクトのローカルCookieをinhouse-cookbooksフォルダーに保存します。 これらは、このプロジェクトに固有のCookieです。
Cheffileに次を追加します。
cookbook 'project42', :path => 'inhouse-cookbooks/project42'
Cheffileは、gitのクックブックの特定のリビジョンも
Cheffileます。
cookbook "postgresql", :git => "git@github.com:express42-cookbooks/postgresql.git", :ref => "0.1.4" cookbook "newrelic", :git => "git@github.com:heavywater/chef-newrelic.git", :ref => "b2309495b367da4bfe6f1761876b5d58e2455d6a"
この機能の組み合わせにより、常に同じCookieをクックブックフォルダーに収集することが簡単かつ便利になります。
すべてのCookieの現在の「スライス」はCheffile.lockファイルに保存されており、CheffileファイルはCheffile.lockをアセンブルする方法の「ヒント」に過ぎず、それだけではCookieをバージョン管理するには不十分であることを明確に理解する必要があります。 Cheffile.lockがない場合
librarian-chef installコマンドを
librarian-chef install時間に応じて、Cheffile.lockは異なる結果になります。 Cheffileで使用されているCookieのすべてのバージョンを明示的にコミットした場合（厳密には推奨されません）、依存関係に従ってアセンブルされるCookieは異なる場合があります。
さらに、必要なCookieのバージョンを明示的に指定すると、Cookieの更新がはるかに複雑になります。
しかし、何らかのクックブックを更新する必要がある場合はどうでしょうか？ たとえば、lvm cookieのバージョンがリリースされ、必要な変更が加えられていることがわかりました。 その後、次のことを行います。
$ librarian-chef update lvm
このコマンドは、lvmクックブックを利用可能な最後のものに更新します。 さらに、必要に応じてlvmクックブックのすべての依存関係を更新します。 この後に
git diff Cheffile.lockを実行して、必要なものが正確に変更されたことを確認することをお勧めします。 ところで、lvmが依存するある種のCookieのCheffileバージョンを記述する場合、lvmは更新されない可能性があり、なぜこれが起こっているのかと長い間考える必要があります。
これは次のように理解できます。Cheffileは現時点でクックブックのバージョンに必要な要件の説明であり、Cheffile.lockは現時点でこれらの要件を満たすスライスです。
そして、司書と仕事をする際に覚えておくべきもう一つのこと。 レシピをchef-serverにアップロードする前に、毎回
git pullと
librarian-chef installを実行する必要があります。 誰かが最新のレシピをアップロードした場合、ローカルのクックブックフォルダーでは何も自動的に変更されないためです。
おそらく、このアプローチは少し複雑に見えるかもしれませんが、それだけの価値はあります。 結局のところ、常に最新のクックブックスライス、自動依存関係管理、ローカルCookie、Opscode WebサイトのCookie、およびgithubを含むさまざまなgitリポジトリのCookieを使用する柔軟性を保証します。