fbpx

[和訳] Berkshelf Workflow #opschef_ja #getchef_ja

Chef

この記事は1年以上前に投稿されました。情報が古い可能性がありますので、ご注意ください。

本項は Berkshelf Workflow (2014/05/27) の和訳です。

この記事(訳注:原文)は https://sethvargo.com/berkshelf-workflow/ からのクロスポストです。

Berkshelfは2つの基本的な仮定に基いて動作します。

  1. それぞれの Cookbook は個別にパッケージ化されてバージョン付けされた構成物である。
  2. 依存関係APIを公開および、または Berkshelf API によってインデックス化できる中央集権的な構成物ストアを持つ。

それぞれの Cookbook はインフラストラクチャの個々の単位であり、そのように扱われるべきです。
2つ以上の Cookbook を繰り返し実行する必要のある状況が連続してあるとしても、それらの状況はとても稀なものでしょう。
この記事では、BerkshelfとGitHubのフローを用いるような状況を、我々のチームがどう扱っているかという手法を述べます。

Chef社のリリースエンジニアリングチームの内部では、継続的インテグレーション(CI)環境においてこの種の問題をよく体験しています。

我々はCIの設定ビルダーとして コミュニティ omnibus Cookbook を利用していますが、Cookbook をラップしたり Attribute を調整したりする opscode-ci という内部の Cookbook を持っています。
opscode-ci Cookbook は次のような metadata.rb を持っています。


name 'opscode-ci'
depends 'omnibus', '~> 3.0'

見ての通り、この metadata のエントリは Berkshelf に、~> 3.0 バージョン制約を満足する omnibus Cookbook の最新の構成物を Chef コミュニティサイトから取得するよう伝えます。
omnibus Cookbook を変更したいなら、opscode-ci Cookbook がアップデートするのと同時にアップデートすることを期待するでしょう。
まず、omnibus Cookbook の最新の master ブランチから新しいブランチを作成します。


~/cookbooks/omnibus | $ git checkout -b sethvargo/add_new_feature

我々のワークフローでは、GitHubユーザ名にブランチを前につけています。
コミットの山に飛び込むことなく、ブランチの持ち主を見つけ出すのに非常に役立っています。
これは Berkshelf ワークフローとは関係ない脇道でした。

次に、ブランチに適切な変更を行い、GitHubにコードをプッシュして、Pull Requestによるコラボレーションを行います。
我々はこのプロセスの個々の段階で omnibus Cookbook に含まれている自動テストスイートを実行し、必要ならばより多くのテストカバレッジを追加します。


~/cookbooks/omnibus | $ git add .
~/cookbooks/omnibus | $ git commit -m "Make awesome changes"
~/cookbooks/omnibus | $ git push

すばらしい変更がなされたら、マスターにマージしたり新バージョンをリリースする前に、opscode-ci に対して変更をテストすることを期待するでしょう。
それを達成するために、Berkshelfを用いている GitHub ロケーションに対して一時的なポイントを指し示すように Berkshelf を使用します。


source 'https://api.berkshelf.com'
metadata
+
+cookbook 'omnibus', github: 'opscode-cookbooks/omnibus', branch: 'sethvargo/add_new_feature'

既存のmetadata.rbをそのままにしておいて、Cookbook 内の既存の Berksfile の終わりにこのエントリを追加することに注意してください。
次に、我々の omnibus Cookbook のブランチをプルするように Berkshelf に伝えます。


~/cookbooks/opscode-ci | $ berks update omnibus

これはバージョン管理システムにチェックインした Berkshelf.lock を更新し、GitHub から Cookbook を Cookbook の保管場所にダウンロードします。
次にテスト Node を収束するために Test Kitchen を使用します。
Test Kitchen は Berksfile の存在を自動的に検出して、omnibus Cookbook の GitHub バーションをプルします。
次にすべてのテストを行います。
opscode-ci Cookbook の特別な例のうち、自動テストスイートと手動のスモークテストの両方があります。

もしテスト中に捕まえられなかった omnibus Cookbook の変更点のバグを見つけるなら、次のようにします。

  1. より早い段階で捕まえるために、新しいテストを omnibus Cookbook に追加する。
  2. omnibus Cookbook のマスターにコミット、プッシュする。
  3. GitHub からより新しいバージョンをプルするため opscode-ci で berks update omnibus を実行する。
  4. 必要に応じて、これらを繰り返す。

早いうちにバグがなくなることが理想ですが、我々は人間なので、間違いは起こります。
そのような困難なケースはまれであることを望みます。
omnibus Cookbookに対する変更に満足したら、semver に基いた新しいバーションをタグ付けして、GitHubにタグをプッシュして、コミュニティサイトにパッケージングされた構成物を公開します。

opscode-ci Cookbookに戻って、Berksfileから一時的な行を取り除きます。


-
- cookbook 'omnibus', github: 'opscode-cookbooks/omnibus'

必要があれば metadata.rb で要求する最少バーション制約を更新して、berks update omnibus を実行します。
これによって、コミュニティサイトにある omnibus Cookbook の正しいバーションを指すように Berksfile.lock が更新されます。


~/cookbooks/opscode-ci | $ berks update omnibus

バージョン管理システムに Berksfile.lock をチェックインします。


~/cookbooks/opscode-ci | $ git add Berksfile.lock
~/cookbooks/opscode-ci | $ git commit -m "Update omnibus to vX.Y"

最後に、opscode-ci Cookbook を新しくリリースして、我々の内部にあるプライベートな構成物ストアにプッシュします。
この時点で、単純に berks upload によってデプロイするか、より大きなチェンジセットを待つかします。

重要

  • 完了していない構成物を公開しない。
  • SCM ロケーションに依存した Cookbook を公開しない。
  • ローカルテストのために Test Kitchen と VMware Fusion を大いに活用する。

参考文献

新規CTA