デブサミ2014「グリーにおけるChef導入事例」講演メモ #devsumi

普段、Chefを使って運用しているので、なかなか参考になる話だったというか、共感できる部分が多かったです。

「グリーにおけるChef導入事例」

  • 荒井 良太 氏
    • @ryot_a_rai
  • グリー

Chefとは

  • サーバの構築や設定更新を自動化するツール
  • サーバのあるべき姿をRubyで記述しておくと、セットアップしてくれる
  • 冪等性
  • Chef社のOSS

導入背景

運用担当者が秘伝の手順書でサーバのセットアップを手動でやっていた。

  • 非効率
  • オペレーションミスの危険
    • Chefにより自動化し、安定運用をはかる
  • リードタイム
    • Chefにより自動化し、サーバのデリバリーを素早く行う

Before Chef

  • Debianパッケージ
    • サーバの役割ごとのメタパッケージ
  • 設定ファイルはスクリプトで生成
  • 設定値
    • パッケージ内
    • サーバ管理システムに問い合わせ

サーバ管理システム

  • 社内のサーバ情報を管理しているシステム
    • サーバ名とかデータセンター、サーバの状態。どのプロダクトで利用されているか
  • 運用スクリプト・ツールが依存している
    • システムを使える状態にしておかないと、運用ツールが動かない

導入方針

  • 新規のサーバをChefで構築していく
  • 既存のサーバ管理システムを利用する
  • 既存のツール・スクリプトが動く状態で移行する

導入する

  • Chefの挙動の話。(メモは割愛)
    • Chef Overview
    • Chef Solo/Chef Server

Chef Serverを使っていたのだけど、やめてChef Soloにしました。(!)

Chef Serverをやめた理由

  • 単一障害点になる
    • 冗長構成はサポートされていない(有償版だとできる模様)
  • サーバ管理が重複する
    • 既存のサーバ管理システムと役割が重複
  • 運用
    • 多数のソフトウェアが動いていてヘビー
    • (Erlangを使える人がいない)
      • Chef Server自体がErlangで作られている

Chef Solo + α

サーバ管理システム <-> Chef Bridge(内製) <-> GREE Chef Client(内製) <-> Chef Solo

Chef Bridge

  • Railsアプリケーション
  • 内製の簡易Chef Serverみたいなもの
    • クックブックやロール、ノードの属性を管理
  • HTTP API
    • 参照のみ
  • サーバ管理システムへの問い合わせ

GREE Chef Client

  • Chef Soloのラッパー
  • Chef Bridgeから必要な情報を取得
  • Chef Soloを実行
  • 自動テストも実行

コミュニティクックブック?

  • 非常に汎用的に作られている
    • 様々なOS、環境で動くように
    • 結果、複雑になりがち
  • 基本的に自社でクックブックを作っている

Chef入門

  • Chefは最近出てきたツール
  • Chefは学習コストが高いといわれる
  • Chef使いを育てる必要がある

Chef使いを養成する

  • 入門Chef Soloを読んでもらう
  • 初心者Chefアンチパターン by Julian Dunn
  • 社内用チュートリアル
    • クックブックを1つ作る
  • 公式ドキュメント
    • 特にresources

クックブックの開発

  • テストを書く
  • GitHub / Pull Request
  • 継続的インテグレーション

これから1つずつ解説。

テスト

  • クックブックを作った人が必ずテストも書く
  • serverspec / Test Kitchen
    • ブラックボックステスト
  • chefspec
    • ホワイトボックステスト
  • Foodcritic
    • Lintツール

なぜテストを書くのか

  • 開発を後押しする
    • TDD的な
    • SSHでログインして実行して、、、みたいな手動作業が煩雑
  • リグレッションを防ぐ
  • ドキュメント代わり
    • 構築後の姿がわかりやすい
  • 本番サーバの構築テスト
    • 本番環境でChefを実行した後にもテストを実行

serverspec

  • サーバのあるべき状態を記述して(テストケース)その状態になっているかをテストするツール

Test Kitchen

  • テスト対象の環境を記述し、その環境でテストできる
    • 複数の開発者が同じ環境でテストが行える

(1)Jenkinsサーバにつながらなくなった問題

  • ある日急に疎通しなくなった
  • 原因: ネットワークのルーティングが変わった
    • Virtual BoxのHost-only network

(2)Mutable Infrastructure問題

  • 繰り返しサーバに変更を加えるインフラ
  • serverspecを本番サーバで実行している
  • レシピごとにspecファイルを作る

(3)テストに時間がかかる問題

  • 細かくテストをまわさなくなる
  • テストケースを絞ってしまう
  • デプロイに時間がかかる
        • -
  • VMの準備
    • VMのロールバック
    • LXC, Docker
  • Chefの実行に時間がかかるのは今後の課題

chefspec

  • chefspec はChef用のユニットテスティングフレームワーク
  • serverspecとかと同じテストは書かないようにしている

Foodcritic

  • クックブックのLintツール

GitHub

  • Pull Requestで変更を投げる
  • 変更に対するテストが通っているか確認
  • PullReq上で議論

継続的インテグレーション

  • Jenkinsを利用してCI
  • デプロイまで自動的に

ノードの属性

  • どのクックブックを使っているか
  • どのロールに属しているか
  • 構築サーバ対象の設定値
    • ノード設定のバリデーションも

ノード設定の共通化

  • ノード設定はYAMLで書く
  • YAMLのアンカーを使って参照

運用していく上で

構築ログが見たい時とかの話。

  • Chef以前は、script/screenコマンドのログをWikiとかにはりつけてた
  • 今は、ChefのReport Handlerを利用してログを送信
  • ログはDBへ保存(Fluentd, MongoDB)
  • ノードにログは残していない

(時間があったので終了後に質問させていただいた)

  • Chef Bridgeは冗長化している
    • 負荷分散と冗長化を同時に実現したかったので、2台たててDNS RRで運用している
    • 障害時のフェイルオーバーは、クライアント側でやっている(実行時にヘルスチェックを実施)
    • Chef Bridgeに負荷で捌けなくなることは、処理的な話とスケールできる仕組みがあるので大丈夫とのこと
  • 上記の話もあったので聞いてみたが、GREEさんでChefを使って運用している台数は50〜100台くらいだそうだ
    • 全体台数もこっそり聞いたら、(想像通りの)すごい数だったので、浸透はこれからの模様