13-b-2 グリーにおけるChef導入事例～既存の資産を活かし新しい技術を導入する～

同一チームでChefベースで構築されているImmutableなインフラがあるが、
自分が担当している方にも展開できるようにまずは基礎知識として蓄えたいと思った

Chef is Infrastracture as a Code
冪等性が担保されている(何も入っていない別のサーバに対して実行する場合の話のはず)
- altertableとかまでChefで行う場合は別テーブルに回避して、importするとかの処理を入れないといけない)
Mutable-Infrastractureと相性良い(Immutable-Infrastractureであっても十分有用性はある)

GreeではDebianを使用
サーバ別のメタパッケージがそれぞれ存在し設定ファイルはスクリプトで生成していた
- 各設定値パッケージ内部 or サーバ管理システムに問い合わせ
既存のサーバ管理システムをそのまま使いたい
- 上記の様な制限があるとchefを導入する際の障壁になることがあるので注意
- 運用スクリプトがサーバ管理システムに依存しているため、構築済みのサーバはいままで通り運用
  - 既存サーバに関しては臨機応変さが必要。(JUnitなどと同じく管理対象外のものに対していきなり全展開をするのは厳しさがあるようで、追加分から始める方が良さそうに感じた)



chef

 |- role

      |- cookbookA

      |- cookbookB

      |- nodeの属性

ChefSoloとChefServerの選択について
- サーバ量が多いとSoloは厳しいがServerには問題がある -> ChefSolo+α = "ChefBridge"なるものを内製して使用
  - 有償版でしか冗長構成がサポートされない（OSS版はサポートなし※デブサミ2014時点）
  - 既にあったサーバ管理システムとChefServerの機能が重複している
  - ChefServerはErlangなので、使える人がいないと厳しい
内製したChefBridgeについて
- nginxがstaticなファイルを提供
- GreeChefClient = ChefSoloのラッパーも準備している
- 自動テスト機能付き
  - 汎用的につくられているだけあり、複雑
  - 自社でCookbookを作成(以下により使える人を育成)
    - 学習コストが高いが、Chef使える人を増やしていった(入門ChefSoloと初心者Chefアンチパターンは必読)
      - 入門Chef Solo - Infrastructure as Code
      - [和訳] 初心者Chefアンチパターン by Julian Dunn #opschef_ja « CREATIONLINE, INC.
      - 社内用チュートリアル ... これはさすがに見つからない…
      - 公式 docs.opscode.com 特にResources and Providers Reference — Chef Single-page Topics らしい

テストの方法
- Serverspec/TestKitchen : ブラックボックステスト
- chefspec : ホワイトボックステスト
- FoodCrinic : Lintツール
テストを書く理由
- TDD的な開発の後押し
- リグレッションを防ぐ
- ドキュメント代わり
- 本番サーバの構築テスト
TestKitchen
- 単体test環境みたいなもの？
[WIP](=進行中の作業)でPullRequestを投げる
- github - jenkins - ChefBridge で自動テスト
共通node設定はYAMLでjsonに変換して使用

何かしら障害があり、構築logが見たい場合
- 以前：screenコマンドで手動保存したものを検索
- Chef導入後 : 実行logはDBに保存(Chefのレポートハンドラ -> fluentd -> DB)

(ただ、その環境を使ってアプリの単体試験をするとなると、ローカルPCのスペックが要求される)

エンジニアの独り言