Blog

ChefのCookbookのベストプラクティス

 2013/06/22
このエントリーをはてなブックマークに追加

OpsCode社のシニアコンサルタントであるJulianさんがChefConf2013で話された内容が参考になるので、簡単に紹介します。 スライドはこちらに公開されています。 また動画はこちらです。

ここで出てこない話として僕がやるべきだと思うことは「テストを書くこと」です。 test-kitchenとserverspecの組み合わせがおすすめです。

ばかでかいレポジトリをつくらない

いろいろなものをまぜこぜにしない たくさんのレポジトリに分割するのを怖がらない (opscodeも昨年opscode/cookbooksの巨大構成から、opscode-cookbooks/個別cookbookに構成を変えています) 個々のCookbookの連携はBerkshelf使えば大丈夫

全員が共用するような会社用Cookbookをつくらない

関係ないプロジェクトのものが含まれると見通しが悪くなる 大きすぎると変化に弱くなって何かの変更が他所に影響を及ぼしやすくなる

物理クラスタ名などの環境名ではなくChefのEnvironmentを使う

物理クラスタ名やデータセンター名などは使わずEnvironmentを使って抽象化する。 じゃないとクラスタ名やDC名が増えると困ることになる

Community Cookbookをforkしてはいけない

一度Forkして自分で修正してしまうとバグ修正に追随できない 修正したい場合は、そのCookbookとは別のCookbookを作って必要な処理を上書きする(ラッパーを作る)

Roleの設定でたくさんのRun Listを設定しない

議論の余地があるがRoleはバージョン管理できないので、当該Roleで動作させるためのCookbook(単にinclude_recipeしているだけ)を作った方が管理しやすくなる

無秩序なData Bagを作らない

事前に計画する。巨大なData Bagを避ける

Chef Shellを使う

デバッグに有効

LWRPを使いこなす

別に怖くない

NIH症候群()をさける

他人が作ったCookbookやライブラリも使えばよい。車輪の再発明を避ける 自分で書きたいと思うのを我慢して、まず最良のものがないかを調べる

一匹狼Chefをさける

全員が本番環境の準備に責任をもつ。 開発者もCookbookのコードを書いたりメンテナンスしたりする必要がある

Happy Cooking!!

 2013/06/22
このエントリーをはてなブックマークに追加