デブサミ2014 「グリーにおけるChef導入事例～既存の資産を活かし新しい技術を導入する～」のメモ #devsumi

Advent Calendar を社内ブログで執筆したので今回はそれ + α
Chef の重要な特徴 -> 冪等性: 何度実行しても同じ状態になる
導入背景
- 秘伝の手順書を使ってサーバセットアップの繰り返しだった
- 非効率さの解消、オペレーションミスの防止、リードタイムの短縮
- Debian パッケージを手動インストールしていた
  - 設定ファイルは postinst スクリプトで作られていて非常に難解だった
  - 設定値はサーバ管理システムから引っ張ってきている
    - サーバ管理システム : 社内のサーバ情報を管理しているシステム
      - サーバ名、データセンター、どのプロダクトで利用されているかなどを管理
      - 運用スクリプト・ツールが依存していた
刷新するにあたって : 新規のサーバを Chef で構築して、構築済みサーバは対象外とする・既存のサーバ管理システムを利用する
- Chef で構築していないサーバも平行運用
- 運用スクリプト、運用手順がサーバ管理システムに依存しているのでそこはケアする
Chef Solo でそれぞれのサーバーに cookbook を入れるのは煩雑になるだろうと思って server を使ったが結局 solo になった
- サーバーだと SPOF になってしまう（有償だとできる模様）
- 既存にすでに持っていたサーバ管理機能と重複してしまう
- 運用に多数のソフトを使っているので結構ヘビー
- Chef Server は Erlang なのでそれを使える必要がある
Chef solo + α のアプローチ
- Chef Bridge/GREE Chef client というものを内製した
- サーバ管理システム -> ChefBridge -> ノード（GREE Chef Client, Chef solo の薄いラッパー）
  - Chef solo では node['gree']['data_center'] などと参照できる
  - Chef Bridge から必要なものを取得し、Chef solo を実行、テストまで行う
オープンなクックブックは汎用的に作られすぎていて複雑になってしまっているのでほぼ自社開発している
Chef は学習コストが高いと言われる。Chef 使いを育てる必要がある
初心者 Chef アンチパターン by Julian Dunn
クックブックの開発
- テストを書く : serverspec / Test Kitchen, chefspec, Foodclitic (Lint ツール)
  - TDD 的な開発を後押しする
  - リグレッションを防ぐ
  - ドキュメント代わり（構築後の姿がわかりやすい）
  - 本番サーバの構築テスト
  - NW 周りの設定不備で Jenkins につながらなくなったことがある
- chefspec は VM を使わないので早い
- Foodcritic : クックブックの Lint ツール、コードに統一感を持たせる
- Github x Jenkins
  - GitHub に push -> Jenkins がテスト -> Jenkins でデプロイ
運用中の障害、サーバ不具合 -> 構築ログが見たい
- script コマンドや screen でログをとる
- 実行ログは自動的に DB に入るようにした

所感

IP 周り、どことどこをつなげるとかロールの先のノード依存の属性の管理とか Chef server だとやりやすかったりするんだろうか。内省されたツールの話でもあったのでそのまま参考になる感じでもなかったけど chefspec とか Foodcritic あたりのツールを知れたというのと、やはり Chef のレシピ書くのって結構コストかかるよねというのは同じなんだと認識できたのは良かった。

Opscode の cookbook、複雑すぎて使ってないという話だったけど信頼性としても自分で書けるなら書いてしまった方が安心だよねという気も。

べにやまぶろぐ

技術寄りの話を書くつもり

デブサミ2014 「グリーにおけるChef導入事例～既存の資産を活かし新しい技術を導入する～」のメモ #devsumi

所感