chef -> docker
Immutable Infrastructure Conference #1
2014/3/25
自己紹介
chef
- つかってますか?
冪等性
- 良い
何度もサーバ上で実行
- 同じ。
- 同じ。
- 同じ。
出来上がる環境
- 何度も同じだ！
良かった
が、
管理の問題
- えっ
たとえば
- Vagrant boxの構築・保管
- 構築手順・保管先ドキュメントの整備・保守(wikify)
- local環境の状態維持(各人で細かい変更したらオワタ)
- chef cookbookを更新した後の確認
開発環境維持に対するモラル
- 配慮し続けないとつらい
- 処理系のバージョンが人によって異なるとか。
chefでつらいこと
- cookbook変更後のチェック
- chefバージョンアップ後のチェック
cookbook適用の保証...
- 数が多くなると管理がしんどくなる(10以上〜)
- 元にしているcookbookがバージョンアップで非互換に
つらい
test-kitchenがあるじゃん
- 毎度回すのが大変
- bentoを使ってテスト用のイメージでテスト
- Berkshelfなどの依存関係解決せな
俺たちゃ解析したい
- 解析チーム、3人しかいない
- マンパワーの限界
- 意味のある可視化に力を注ぎたい！
悶々とした日々
- docker、CentOS でも使いたいなァ...
docker v0.7
- RHELも動作対象だ！
- やっちまおう！
全とっかえはNO
- 手付けてからいつ終わるかわからない
- とにかく試したいし
どこを対象にするか
安定してるアプリをdocker化
- HRForecast
- GrowthForecast
社内テスト実施
- デ〜タが注ぎ込まれていく
- docker container安定
- きちんとグラフ出力できてる
結果
- このままproductionもいっちゃえ
dockerの社内採用OK
前と今
以前
- chef + Vagrant + Berkshelfが鉄板だよね
- 構成変更があれば毎度レシピを再ビルド
- ビルドの遅さ・手順によるやる気の遅滞(knifeとかあるけど)
今
- chef -> ansible
- ansible-playbookでdocker runという形
- tagで管理できるので環境を長期放置しても大丈夫(でしょう)
環境構築は簡単でなければ。
- 環境を気兼ねなくぶっ壊せるように
- ぶっ壊した後さり気なく再現できるように
- どんどん新しいことを試せるようにする
docker-registry
- docker imageの管理
- 保管場所を考えなくても良い
- ビルド済みの環境をダウンロードするだけで終わる
docker化
- まだ一部しか置き換えられていない
- 適用できる範囲を広げていく
進めていきたい
td-agent
- テスト用のdocker imageを作った程度
- 設定ファイルの煩雑さをcontainer分割で解決していきたい
- containerを複数のマシンに展開しやすそう
進めていきたい
BIツール
- リグレッションで壊れたら利用者こまる
- 調子のいいときのイメージをdockerによってアーカイブ
やりたいことに力を注ぎたい
- 効果測定をやりたい
- デプロイのために生きているわけじゃない
- 環境構築の時間を解析のために割きたい
- 「困ったらあの時に戻りたい」を簡単にしたい
dockerの有用性を社内に広めていく
不安点
- 運用ノウハウの不足
- dockerのβ感
- dockerに縛られることになる?
正直わかり手感ある
特にノウハウ面
- Dockerfile Best Practicesを参考にビルド
- 監視方法(dstat? docker top? fluentd?)
- 社内/社外問わず情報共有しないと...
- よろしくお願いしますm(_ _)m
