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

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のテストが通るように環境を作りましょう!"実習環境が仮想マシンなのがミソ。

  1. まずは、Chefなしで手作業で構築
  2. できた人は、無慈悲にも仮想マシンを構築前の状態にロールバック!!(会場からどよめき)
  3. 再度、おなじ環境を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 uploadknife data_bag from fileknife 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でも同様のことができるかも?

ChefとPuppetは混ぜるな!

  • 今回は、レイヤーが違ったので成り立っているが、レアケース。

テストの話

  • やっぱりテストは大事!(本日3回目)
  • 振る舞いをテスト

テスト対象どうする?

ホスティングなので、ユーザーの行動をテストモデルに。Rspecで実装

以下の4ステップ

  1. Chef SoloでLXC作成
  2. SSHでログイン
  3. Rspecの中身

    • ユーザーの想定される行動をテストケースに。
    • system()``でコマンド叩いて、結果を評価
  4. Chef SoloでLXC削除
  • お問い合わせ→確認→テストケースにする→デグレード防止!!
  • 「できない」テスト
    例 :

    • su,sudoできない
    • /var/log/messagesが見れない
    • forkbombできない
  • で、JenkinsでCI