Provisioning Frameworks Casual Talks vol.1 に参加しました
※2013/5/12 先着順受付についての記述追記
最近弊社のプロジェクトでもchefを少しずつ導入してることもあり、
先人の知恵を拝借すべく参加いたしました。
新卒研修でserverspecとChefを使った話(@fujiwaraさん)
http://dl.dropboxusercontent.com/u/224433/pfcasual_1/index.html
KAYACさんでのchef導入秘話や研修のお話。
chef導入当時(2年ほど前？)、まだまだ情報が少なくて試行錯誤が大変だったそう。
たしかに現在はnaoyaさんのchef本もあるしwebでの情報も多くなってきていますが
当時、独自で調査するのは大変だったでしょうね…
新卒研修のお話はなかなか身につきにくい基礎的な内容を底上げするために
serverspec + 手動構築、そしてchefでサーバ構築体験をさせる、というもの。
はじめにserverspecでサーバのあるべき姿／振る舞いなどをテストとして書いておいて、
そのテストを通すためにサーバを構築していく、というのは
理にかなっているなぁと感じました。
面倒がって今までserverspecから目を背けていましたが
是非とも実戦投入したいですね。
#藤原組長研修受けたい
宣伝『入門Puppet』(@antipopさん)
https://speakerdeck.com/kentaro/puppet-book
だいぶ宣伝色が強いプレゼンでしたｗ
Puppet、自分は触れたことがないのですがシンプルに書けるようですし、
勉強のため動かしてみるのも良いかなと思いました。
そしてperlプログラマに馴染み深い「無精、短気、傲慢」という三大徳目から「無精」に注目。
chefやpuppetを学ぶのは面倒だけど、それは
「さらなる面倒を回避するための面倒な作業である」（結果的に無精する）
とのこと。
深い。
入門Puppet （ブクログのパブー）
入門Puppet （達人出版会）
入門Puppet (Amazon)
宣伝『入門Chef Solo』 (@naoya_itoさん)
https://speakerdeck.com/naoya/ru-men-chef-sololuo-tisui-shi-i
スライドのタイトルの通り「入門Chef Solo」を読んだ方からよく受ける質問についての補足、といった内容でした。
- Chefでどこまでやるのか？
- Chef solo / serverを使うべき規模は？
- 開発環境整える時、VMで渡すのかChefレシピを渡すのか？
- テストはどうするの？
といった、Chefの基礎をひと通り覚えた後に悩みどころとなるポイントがぎっしりでした。
大事な考え方として
「chefは自動化ツール」ではなく「ノードの状態を管理するツール」である
ということ。
状態がレシピと異なれば同じ状態にするし、
場合によってはgit管理を使って戻すこともある。
「Chefを実行した後は「必ず同じ状態になっていなければならない」」
ちい覚えた。
ちなみにnaoyaさん、Chef Solo本で家を建てたいとのことなのでたくさん買いましょうｗ
入門Chef Solo （達人出版会）
入門Chef Solo (Amazon)
Chef市場動向( @jhottaさん )
※資料見つからず…
最近のChef市場動向やChefConf2013まとめ的なお話。
ChefConfはyoutubeに動画が上がっているから見たほうが良いよ！とのこと。
youtubeで「chefconf」検索するとモリモリ引っかかります。
その中でも以下の動画はかなりオススメらしいです。
http://www.opscode.com/blog/chefconf-talks/beginning-chef-antipatterns-julian-dunn/
environment変数の安全な使い方（@sethvargoさん）
https://speakerdeck.com/sethvargo/chef-plus-environments-equals-safer-infrastructure
Chefspecの開発者である Seth Vargoさんの 海外リモートプレゼン。新しい。
英語苦手なのでモニョモニョ…
environmentを利用して環境ごとにcookbookのバージョン管理して事故しないように運用しよう！
という感じでしょうか？
あとknife-sporkというワークフロー管理コマンドも初めて知りました。
https://github.com/jonlives/knife-spork
割と大規模向けなのかな？後日調べよう…
http://www.slideshare.net/mrtazz/etsy-chefworkflow
SqaleのChefとテストの話(@hibomaさん)
http://www.slideshare.net/hiboma/sqale-puppet-chef
初っ端、naoya_itoさんとの兄弟愛から始まったプレゼン。
Sqaleの裏側でChefとPuppetがどのように使われているか、といったお話でした。
LXCを用いてユーザ毎のコンテナを作り*1
EC2インスタンス -> puppetの土台 -> chef-solo でchroot -> ユーザレイヤ
というようにレイヤーを分けて管理しているとのこと。
puppetの土台作りについては別資料があるようです。
http://www.slideshare.net/lamanotrama/on-aws-sqale?ref=http://d.hatena.ne.jp/lamanotrama/
ホスティングならではの悩みどころとして
出来ることはもちろん、出来ないこともテストすることが大事。
su制限出来ているか、forkbomb回避がうまく動作しているか、bind出来るポート範囲の制限が出来ているか、など。*2
余談ですが、上記のようなテストはRspecで書かれているとのことですが
これをベースにして汎用的にしたものがserverspecらしいです。
またPuppetとChefが混在していることに関しては
「本来はやらないほうがいいでしょう」
とのことｗ
Sqaleの場合は管理しているスコープが違うので問題ないそうです。
先着順受付について
従来方式（事前登録式）では
「登録しているにもかかわらず、来ない人がいる（それで補欠の人も来れない）（席も空いてしまう）」
といった大きな問題がありましたが、
これが解消されて「先着順で、しかも席が埋まる」というのがわかりやすくて良いですね。
他にも「先着順のため、遅れてくる人が少なくなる」「事前登録IDとの突き合わせの手間が省ける」
などといった点からしても運営側からすればメリットの方がかなり大きいのではないでしょうか。
ただし、参加者目線からみると
「何時くらいまでに行けば大丈夫なんだろう…」
「今から行っても間に合うのか？」
といった不安にかられることになります。
特に、遠方からお金をかけてきている人が参加できなかった時は可哀想な気もするので
そういった人達を助ける方法は考える必要はありそうです。
しかし、やはり勉強会を開催している運営側のメリットを取るほうが良いのでは？
と思いますし個人的には全然ありだと思いました。
まとめ
Casualかどうかはわからなかったのですが、だいぶ濃い内容でお腹いっぱいでした。
Chef/Puppetを使っていく上での考え方や悩みどころがとても勉強になったので
自社プロダクトにも少しずつ適用していこうかなと思いました。
あとserverspecは触っておいたほうが良いな、と気づけたのも収穫でした。
すたじおさんをはじめスタッフやスピーカーの方々、お疲れ様でした！
とても楽しかったです！
