ChefのCookbookのベストプラクティス
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!!
アジャイルコーチングやトレーニングを提供しています
株式会社アトラクタでは、アジャイル開発に取り組むチーム向けのコーチングや、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください。
詳細はこちら
