普段、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台くらいだそうだ
- 全体台数もこっそり聞いたら、(想像通りの)すごい数だったので、浸透はこれからの模様
