ProvisioningFrameworksCasualTalks1に参加した話
どうもこんにちは。smallpalaceです。ご覧いただいてありがとうございます。
Provisioning Frameworks Casual Talks vol.1というのに参加してまいりましたのでその備忘録を。
https://gist.github.com/studio3104/5417631
ハッシュタグ： #pfcasual
結構豪華な登壇者の皆様でした。事前登録なしで集まれる人が集まるという方式で気軽に参加できました。
以下登壇者様ごとに---で区切りでメモ。一生懸命メモりましたが間に合ってなくて歯抜けな情報もあるかと。
-------
fujiwaraさん
新人研修にChefとServerSpecつかったはなし
http://tech.kayac.com/archive/2013training.html
ServerSpecでのテストをかいて通るようにクックブックをかいてもらう
describe 'ntp' do
it { should be_installed ｝
end
というようなインストールされているべきというのを書いてくそうです。
監視とは継続的なテストであるという。名言。
手作業（手順書）構築→バージョン管理されたコードで構築
コードかく→テストもかく
継続的なテスト==監視
QA
Q.振る舞いに関するテストは？
A.スクリプトのテストで、ntpq -pの結果の標準出力にアスタリスクがついてるとかを確認するとかできる
Q.無慈悲なロールバックされた新卒たちの反応とか便利なことは？
A.動いてるかどうかコマンドで確認せずにテスト通っただけで動きましたといってきたので新人類だと思った
------------
あんちぽさん
入門Puppetの人。ぺぱぼのひと
スタジオさんにおまえはPuppetのはなしでもしてろといわれた。（lwrdというのをしゃべろうとおもってたのに）
Puppetの本は英語オンリーだったので日本語初なので買ってくださいですって。アプリの人向けに作ったそうです。
どういう本なのか
キソ（一通りのリソースを使えるようになるまで）12章まで、応用13章から。
構成に気をつかってかいてる（バリバリサーバエンジニア向けでなくアプリエンジニア向け）
ハンズオンや新卒研修にも使えるように書いた。
LerningPuppetだけでは学べないmanifest構成のノウハウまでかきました
Vagrantローカル環境(VagrantはVBoxのrubyフロントエンド）
maglica開発環境（KVMのラッパ)
EC2本番環境
それぞれの環境でPuppetつかうそうです。
エンジニアの共通言語としてのコードの役割はますます大きい
プログラマの3大美徳 無精(laziness)、短気(impatience)、傲慢(hubris)
めんどうくさいのぱっぱとコードにして俺のコードすごい的な。
手順書作成・更新スクリプトか・スクリプト保守・冪統制担保とかとにかく面倒。
一見面倒なChefやPuppetを学ぶのは面倒を回避するためならいくらでも面倒をこなすという無精の発露。
ChefとPuppetのちがい
記述の自由度はChefが上でディレクトリ構成の自由度はPuppetが上らしい
クラウド時代の共通語をこの本で学べます。
どっちつかってもいいけど入門Puppetの本にかいてあることは知った上で選んでね。かってね。
http://tatsu-zine.com/books/puppet
実はServerSpecのことが書いてあるみたいなので買ったんですがまだたどりついてないです。
--------
いとうなおやさん
入門Chefの人（大変おせわになってます）
http://www.amazon.co.jp/dp/B00BSPH158/ref=cm_sw_r_tw_dp_.8vJrb047KWPP
「インフラを Github とかで Social コーディング」というフレーズにピクッときたらこの資料をどうぞ、とつぶやかれてました。
https://speakerdeck.com/naoya/chef-and-devops
kindleの総合2位になったらしい。技術カテゴリでなくて。すごい。本で家建てたいので皆もっと買ってねですって。
出版後の反応から落穂ひろい
facebookのなかのひとの発表の紹介
#ChefConf2013
4人で1万システム管理、、FBはOpscodeがやってるホステドシェフらしい。規模的にChefClientからChefServerへの通信量とかそんなにClientが多いとコストとかも気にしなくちゃいけないけどHostedChefは結構スケーラブルらしいです。
クライアント1万5千台とかで
テストを実際のシステムに行うこと重要とかかれてた
つ #pfcasual / “個人的#ChefConf2013まとめ。 - tkak's tech blog” http://htn.to/Qk5L3v
Chefでどこまでやるの？
自分たちでつくったのもChefで？みたいなの
基本全部Chefで。アプリのデプロイは例外として扱うのが皆がやってるやりかた
大事な考えかた
convergence(収束)
NG：自動化ツール
OK：ノードの状態管理
rollbackとかブルーグリーンデプロイとか複雑なのはそれ専用のツールにまかせるのがいい。
Chef-soloはどのレベルまで？
大規模：数百～1万台：Chef-server一択
中規模:数十台までchef-soloでもがんばれるけどそろそろ百いきそうならserverつかってもいいかも
20台までならsoloでいける
数台ならxargsでつらくなったらcap provision(capstorano)とか
Chef-serverはnodeを検索できる。
数万台とかだと有象無象から探してきてこういう条件のやつらにパッチをあてるとかそんな
ChefServerではClientが自律更新できる
導入が大変。ChefServerを運用するためのPostgresqlをどう管理するかとかめんどい
Chef-zeroってのが出たそうです。DBや認証がないので楽らしい
FabricVsChef
Fabricとシェルスクリプトでできるよね
頭冷やせ
Fabricとshはただのツールで状態を管理するものではない
Chefは場合によっては戻す。
書いてはアップロード必ずレシピに書いてあるとおりに状態を収束してくれる。
Fablicは状態は管理しない。書かれたとおりに「前進」するだけ
比較の軸がことなるもの
レシピをGitで管理すれば「ノードの状態」をバージョン管理することができる。
管理しているのは単なるコードではなく「状態」
開発環境の標準化にChefを使おう
出来上がったVMイメージを共有すべきか、レシピを共有すべきか
レシピを共有しよう！
自分でconvergenceしてもらう
コードで状態を外部化したのだから
れっつSocialCoding！
テストどうするの？
before convergfenceなテスト（ユニットテスト的な）
Integrationテスト（serverspec)
の2種類。前者は以下。
knife cookbook testシンタックスチェックとか
foodcriteicLinterみたいなの
chefspecユニットテスト
strainer以上のツールの実行を補助するもの
内部でChefのシンタックスチェックしてくれる
Integrationテスト
minitest-chef-handler
sererspec
定番はtest-kitchen+ninitest(opscode公式なので)
個人的にはSercerspec推し
Integrationテストは処理系に依存しないほうがいい。Chefからpuppetにしたいときとか
悩ましいところ
Chefspec+integrationtestは結構冗長で同じようなのが多い
Chef盛り上がってる
QA。
Q.継続的定期実行とか正気の沙汰とは思えない、テストを継続的にやってくのがいいのでは
A.こういうもんだってなってくのでは。ほとんどの人は確認しながらがいいが、サーバが10万台とかなってくると考え方を変えなきゃいけないのかも。
今日の資料
https://speakerdeck.com/naoya/ru-men-chef-sololuo-tisui-shi-i
--------
ほったさん
@jhotta
直哉さんとぜんぶかぶっちゃったよーといいつつ。
PuppetかChefか、と言う議論は意味がない(どうせどっちか使うことになる
ちっちゃいところからちょっとずつ。
上の人も巻き込みましょう
JulianDunn/beginner-chef-antipattern
おすすめスライド
つ #pfcasual / “Beginning Chef Antipatterns ? Julian Dunn | Opscode Blog” http://htn.to/67qzkZ
おぷすコードの人でてくる
Skypeを通じて @sethvargo のお話に移る。内容は「environment変数の安全な使い方」。
英語。わかんないです。
environments で各 cookbook のバージョン指定ができるので、"development" 環境で作った cookbook は "qa" や "production" 環境に影響は与えない。ざっくり訳 #pfcasual
environmentsをぐぐったら、、
Environmentは、環境名を定義してNodeに割り当てる事ができます。RailsのEnvironmentと同じ概念ですね。環境毎にAttributesの値を変えたり、使用するCookbookのバージョンを指定・固定したり出来ます。本番環境とステージング環境ではデータベースのアドレスが違うだけなんて構成はよくあると思いますが、そういう時にこのEnvironmentが活躍します。EnvironmentとRoleを制する者はChefを制す（大げさ）
http://firn.jp/2011/12/05/chef-introduction
だそうです
以下関連ツイート。
environmentでcookbookのversionを適切に管理してれば、「変更したばっかりのrecipeいきなり本番に適用されて事故ったらどうするの！？」みたいなケースは防げるわけですね。これがちゃんとできればfbのようにクライアントを自動更新できるか？
environmentでの分岐のときは、descriptionと言った形で、明確に本番かどうかを示してあげたほうがいいってことなのかな。
environmentなー、便利に使わせてもらってはいますが、テストを充実させはじめたところ、chef-soloでsupportされていない問題ががが。 http://docs.opscode.com/chef_solo.html
本人のツイートでスライド紹介されてた：https://speakerdeck.com/sethvargo
Etsy が knife-spork 使ってる資料 #pfcasual / “Etsy chef-workflow” http://htn.to/Tk8wdt
--------
Hiroya Ito ( @hiboma )
SqaleのChefとテストの話
ホスティングの開発にかかわってる
ホスティングではリソースを切り売りする
Sqaleというサービスの宣伝（PaaS）
コンテナの実態
プロセスレベルでの仮想化
LXC（Linuxコンテナ)
chrootでやるので構成管理しようみたいな
基本puppet管理
EC2の上にpuppetで土台をつくりChef-soloでchroot環境をつくるなどしているらしい
Puppetレイヤはmunin、Ldapとnagiosとかカーネルも管理
サーバ構築自動化
chrootしてからchef-soloを流すだけ。
レシピはmount --bindしてホストOSを参照している
chreootだとホスト名ベースでレシピを当てられないのでchef-soloした
さしみたんぽぽ作業なのでchef-soloでやっちゃおうと。
ユーザ名を変えるだけで同じような環境がぽこぽこできるのがいいかなと
attributeで変数を注入する
削除するときにも冪等性がきいてくる
消すときも冪等性で心理的に安心
仕様変更したい場合もChef-soloする
ユーザ名に依存しちゃうような仕様を変えるときに便利
いとうなおやさんいわく
ユーザー名とかドメインスペシフィックなデータはData Bags、リソースに紐づく属性にはAttributes と使い分けるといいみたい
だそうです。
振る舞いテスト＝動く仕様
これを使えばPuppetやChefのリファクタリングも容易になる。
なにをテストするかうちの環境の場合
chef-soloでLinuxコンテナ作成、プロセス起動テスト、ミドルウェアテスト、SSH、コンテナでRSpecを作成
RSpeｃの中身
ユーザーさんの行動模擬テスト
sshログイン、ミドルの操作、Railsとシナトラアプリ動くか、シェルコマンドつかえる、ログ見れる等々
バンドルインストール済みのをtarでまとめて展開し起動するかテスト
rbenvでいろんなバージョンつかえるか泥臭くテストしている
ライブラリが実際読めるかテストなど
sudoできないとかrebootできないとかもテストしてる
ホスティングのように多ユーザが使うような環境では、できないことをテストするのも大事。suできないとか、読めちゃいけないログが読めないとか、特定ポートをbindできないとか。
パッチを当てたカーネルとその制限もテストしてる
Jenkinsとかもつかってるみたい
hiboma がサーバのテストを RSpec でやってるのがかっこよくて、それを汎用的に使えるようにしたのが serverspec
だそうです
資料はこちら。
http://www.slideshare.net/lamanotrama/on-aws-sqale?ref=http://d.hatena.ne.jp/lamanotrama/
-------
#hbstudyも追ってみた。面白そうなスライドが載ってるサイトのつぶやきを追いました。
http://connpass.com/event/2366/?disp_content=presentation#tabs
http://yosuke-furukawa.hatenablog.com/entry/2012/08/12/094802
正しいベンチマークをするための10のポイント
http://opendatabaselife.blogspot.jp/2009/08/10.html
#hbstudy で紹介されてた、Windows GUIをBASICライクな文法のスクリプトで操作を自動化できるAutoIt。ほほー / “ AutoIt | AutoItScript” http://htn.to/gSZACWqZsqb
勉強会の形式についてもブログに書いてねだって。
入り口に一定時間受付の人いるならなんでもいいんじゃないのと思いますし、予約なしだと気が楽で参加しやすいと思いました。
受付で「さんかしたいです！」といったらいぶかしそうに「Chefの勉強会にですか？」とかいわれましたけども。女性参加はたぶん私だけだったぽいからかな。おかっぱの人とか長髪のひといたけどたぶん男性だったとおもう。でも面白かったです。音声ファイル期待してた人もいるんじゃないかしら。録音忘れたみたいで残念。
とりあえずこんなところで。追加情報があれば追記するかもしれません。
行きがけに買った母の日のお花、帰って娘さんを面倒見てくれたばあちゃんにあげたらだいぶ喜んでました。よかった。娘さんは0時ちょい前に起きて散々乳吸ったあげくニヤニヤしだしてなかなか寝ず、ブログを書くために離脱できたのが5時頃というね。乳吸って満足げにニヤニヤしてるのちょっとかわいいけどね。
ではどうもご覧いただいてありがとうございました。
