Provisioning Frameworks Casual Talks vol.1に参加しました

#Chef

#AWS

大瀧隆太

2013.05.11

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

Chefの話がいっぱい聞けそうなタイムテーブルだったので、参加してきました。濃ーい話がいっぱい聞けて、お腹いっぱい。
雑感を書きたかったのですが、取り急ぎメモ書きをdumpします。随時アップデート予定。

開催概要

MySQL Casual Talkと同じく、事前登録なし先着で受付という、LINEのすたじおさん曰く革命的な勉強会募集方法でした。実際には、勉強会開始時点で定員の7割くらいの参加者数だったので、満員のため受付お断りということにはならかったようです。
定員が40名くらいの中規模以上の勉強会であれば非常に有効な手段なんじゃないかと思います。
それよりも小さい規模だと、主催者/参加者ともにリスクが大きくなってしまう気がします。

日時	2013年5月10日 19:00〜21:35
会場	LINE株式会社(旧NHN Japan)渋谷オフィスセミナールーム
URL	https://gist.github.com/studio3104/5417631
Twitter #	#pfcasual
Togetter	http://togetter.com/li/501076

新卒研修でserverspecとChefを使った話

発表者	Shunichiro Fujiwara(@fujiwara)さん
スライド	新卒研修でserverspecとChefを使った話

まずは聴講者にアンケート

Chef / Puppet触ったことがある人→ほとんど全員挙げる
serverspecは?→全然挙らない→じゃ、今回はこっちメインでお話しします

Chefとわたし

中規模サイトのお引っ越しでChef化!!
- 特にPuppetと比較してChefにした訳ではない
- Web-UI/Solrは、10台くらいの構成では"いらない"と気づくのに時間がかかった
開発マシンのビルドが大変! → Chef Soloで幸せに!
2012〜 SNG(ソシャゲ)
- Cookbookをgit branchで運用(mergeは諦めた)
- Server & ClientからSoloに切り替え
- アプリ担当も、Chefの実行くらいはやってほしい!
- デプロイは別。

で、新卒研修でChefを題材にした研修やってみました

お題が、"serverspecのspecファイル。このspecのテストが通るように環境を作りましょう!"実習環境が仮想マシンなのがミソ。

まずは、Chefなしで手作業で構築
できた人は、無慈悲にも仮想マシンを構築前の状態にロールバック!!(会場からどよめき)
再度、おなじ環境をchefレシピで実装しましょう!

serverspecの話

Cookbookのリファクタリング、Cookbookの追加時のモックとして有用なのでは
監視とテストは通じる
cronlog(こけたらメール通知とか)との組み合わせとか

参加者とのQ&A

レシピレベルではなく、振る舞いレベルのテストはどう?: コマンドの実行結果を試験できる!
ntp -qの結果を解析して*のありなしを見るとか
新卒研修の受講生のリアクションはどうでしたか?: "構築できました!"より先に"テスト通りました!"ってのが新感覚(テストファーストな感じ)

宣伝『入門Puppet』

発表者	Kentaro Kuribayashi(@kentaro あんちぽ)さん
スライド	Puppet Book // Speaker Deck

Puppetとわたし

会社でめっちゃ使ってる

本の宣伝

パブー/達人出版/Amazon Kindle(パブーが取り分多いのでオススメ)
日本初のPuppet本
Puppet本がなかった!amazonの"Puppet"の検索結果はさんさんたる状況
インフラエンジニアより、アプリエンジニアを読者に想定
Infrastructure as Codeの体現!!
アプリエンジニアとインフラエンジニアを仲介するためにコードの役割が大きくなる!
システム構築に「無精」を持ち込む

Chefとの比較

Chefは変なディレクトリに縛られる
Puppetの方が簡単!

宣伝『入門Chef Solo』

発表者	Naoya Ito(@naoya_ito)さん
スライド	入門Chef Solo落ち穂拾い // Speaker Deck

宣伝!

Kindle総合で2位!!
目標はChef Solo御殿を建てることだそうです

出版後の反応

ChefConfでFacebook事例

4人でやってる!
Opscode Private Chefの大規模事例(ベンチ、スケーラビリティがいいらしい)
やっぱりテスティングが大事!

Chefでどこまでやるん?

全部?
- 全部。直接変更しない!
- 大事な考え方「convergence(収束)」がキモ！自動化ツールではなく、収束させるツール。
- sshログイン禁止!
- 手作業で変更しても、chefの実行で元に戻る!→これは正しい挙動
- アプリのデプロイは例外。AWS上で同じシステムを作って、ELBの切り替えでやるとかChefだけでは面倒見切れないところがある。

Chef Soloの境目

20台くらいか100台くらいでSoloの限界が見える
echo host1 host2 host3 | xargs knife〜で十分
xargsがつらくなったらcap(capistrano)で。
Chef Serverはnode検索(ohai)がキモ!
sudo chef-client -d -i 900でデーモン化&自動更新!
Facebookは15分間隔、このプロセスが落ちないように気をつける
Chef Serverの導入が面倒
→chef-zeroとかどうよ

Fabric vs Chef

コンセプトが大きく違う!!
FabricはSSHをパラレルで実行するツール
Fabricは状態を管理しない。書かれた通りに「前進」するだけ
Fabricは、クロスプラットフォームを意識しない
Chefは、ノード(インスタンス)の"状態"をコードで管理する!

開発環境の配布方法

VMを配るべき?レシピを共有するべき?
- レシピを共有するのがオススメ!!
- 自分でconvergence!
- 開発環境に「Redis」を入れてほしい!というときレシピをpushする

Chefのテストの話

Chefのテストは2種類ある
- Before convergence
- Integration
ちょっとしたもの
- knife cookbook test
- foodcritic
chefspec
- ユニットテスト
- オフラインで実行可
strainer(動かなかった...)
定番はtest-kitchen + minitest
serverspec推し
- chefに依存しないのがポイント!
- Puppetに乗り換える事態になったときとか
- test-kitchen + serverspecの連携が良さげ!
chefspec + Integration Testは冗長かも

参加者とのQ&A

chef-clientの定期実行は正気?構成ファイルとrunning configurationとの兼ね合いは?

Chef市場動向

発表者	Naotaka Jay Hotta(@jhotta)さん Seth Vargo(@sethvargo)さん
スライド	Chef + Environments = Safer Infrastructure // Speaker Deck

Opscodeのコードはオープン!
Google HangOutsで今後の動向がわかる
入門編はJulian Dunnさんの動画がオススメ

Seth Vargoさんリモートプレゼンでenvironmentの話

environmentは、Chef-Clientを使用する場面によってグループ化する機能(例 : Development/Test/Production)
JSONで記述する

environmentのユースケース

knife searchのキーとして、Developmentのノードというように使える
例 : knife ssh "chef_environment:production" "reboot"
cookbookのバージョンを縛る(lock cookbooks)
cookbookをアップデートする対象をenvironmentで絞る&ワークフローで管理(後述のknife-sporkを活用)
開発環境ではtestフロー、テスト環境ではpromote,verifyフロー、本番ではpromote,demoteフロー

Seth Vargoさんリモートプレゼンでknifeプラグインあれこれ

knife-dwim(Do What I Mean)

knifeコマンドの補完プラグイン。
knife cookbook upload、knife data_bag from file、knife role whateverを判別してくれる

knife-spork

前半で紹介したcookbookのpromoteとかverifyをワークフローとして実装してくれるknifeプラグイン

knife-flip

複数ノードをまとめてenvironmentなど変更できるknifeプラグイン

SqaleのChefとテストの話

発表者	Hiroya Ito(@hiboma)さん

[slideshare id=21064076&doc=sqale-puppet-chef-130512213426-phpapp01]

テーマ

paperboy(ペパボ)のインフラ管理のお話
サービス名はSqale

SqaleのPaaSが今回の舞台

実装はLXC。これの構成管理!
- 土台をPuppetで、ユーザーごとに用意するchroot環境をchef-soloで管理。
- @lamanotramaさん作のPuppet+AWS自動化が動いてます。
- Chef Soloでchrootの実装
  意外と素直。Puppetでは、chrootだからホスト名ベースの管理ができない→Chef Soloで。

Chef Soloの使い道

ユーザー作成
- ユーザー名をattributeで。
- ユーザー削除のときも冪等性がいい感じ。
chef-solo -j http://hoge/node.jsonでattributeファイルを引っ張ってくるのが便利そう。Chef APIサーバー立てるとか。
仕様変更にあわせた構成変更
puppet applyでも同様のことができるかも?