Developers Summit2014[13-B-2] グリーにおけるChef導入事例 〜既存の資産を活かし新しい技術を導入する〜
[13-B-2] グリーにおけるChef導入事例 〜既存の資産を活かし新しい技術を導入する〜
荒井良太
Chefとはなにか
- サーバ構築・設定更新を自動化するツール
- あるべき姿をRubyで記述しておくと、その姿にセットアップしてくれる
- 重要な特徴として、冪等性(何度実行しても同じ)が挙げられる
導入背景
よくある光景
プロダクト担当者は運用担当者が手動で用意するサーバを利用するしかなかった。
手順書があるならばルーチンワークである→非効率。自動化したい
- 非効率を自動化して効率化
- オペレーションミスの危険を減らし、安定運用を目指す。
- サーバのデリバリを素早く行うことでリードタイムを得る。
導入前
Chefを導入するが、サーバ管理システムはそのまま利用したい。
サーバ管理システム
社内サーバ情報を管理しているシステム。サーバ名、データセンター、サーバの状態などを記録
導入方針
- 新規のサーバをChefで構築していく
- 構築済みサーバは状態不明なのでChefで更新するのは危険と判断
- 既存のサーバもChefで並行運用する
- 既存のツール・スクリプトが動く状態で移行する。
Chefサーバをやめた理由
- 単一障害点になる
- 冗長構成はサポートされていない(有償だとできる)
- サーバ管理が重複する
- Chef Serverはサーバ管理の役割を担う。
- 既存のサーバ管理システムと役割が重複する
- 運用
- 多数のソフトウェアを使っている(結構ヘビー)
- Erlangを使える人がいない。
Cheff Solo + αで運用をすることに
Cheff Solo + αの構成
ノード(構築対象サーバ)とサーバ管理システムを連携させる。
Chefサーバ代わりの内作Chef Bridge、ノード側にGREE Chef Clientを作成。
サーバ管理システム→Chef Bridge→GREE Chef Client(Chef Soloラッパー)という構成にした。
Chef Bridge
Chef Client
- Soloのラッパー
- Chef Bridgeから必要な物を取得
- Chef Solo実行
- 自動テスト
開発編
作る必要があるモノ
クックブック
- オープンソースなクックブック
- 非常に汎用的に作られている
- 汎用的な結果複雑になりがち、使いこなすのは難しい
- 異本的に自社でクックブックを作成している。
Chefは学習コストがタック、Chef使いを育てる必要がある。
Chef使いを育てる
クックブックの開発手順
テストを書く
- クックブックにはテストを必ず書く
- serverspec/Test Kitchen
- chefspec
- Foodcritic
なぜテストを書くのか
- 開発を後押しする
- TDD的な
- リグレッションを防ぐ
- ドキュメント代わり
- 構築後の姿がわかりやすい
- 本番サーバの構築テスト
問題1 Jenkinsに繋がらなくなった
原因:ネットワークのルーティングが変わった。。。VBのHostOnlyNetwork
VMだけのネットワークが作れたら。。。
問題2 Mutable Infrasturucture
ゼロからChefでセットアップしたサーバと同じ保証はない。
serverspecを本番用サーバにも実行している。
問題3 テストに時間が掛かる
- 細かくテストを回さなくなる
- テストケースを絞るようになる
- デプロイに時間が掛かる
VMの準備はロールバックで対応。ただCheffの実行部分が一番時間がかかっているので、今後の課題。。。
Chefspec
- ユニットテスティングフレームワーク
- serverspecと重複する部分はかかない。
Foodcritic
- クックブックのLintツール
- クックブックに統一感を持たせる
GitHub/Pull Req
- 変更に対するテストをパスしていることを確認
- プルリク上でレビュー
CI
Jenkins上でテスト、デプロイまで自動で実施。
ノードの属性
バリデーションすることで必要なノードの設定値を検証している。
共通化をして、共通部分を一箇所に賭けるようにしている。
ノード設定はYAMLで書くようにいしている
Github Push→Jenkins→Chef Bridge→cheff soloという運用フローができる。
障害対応
Chef実行時のログは自動でDB保存、CheffのReportHandlerを利用してFluentdに投げている。