Chef とかChef-Solo とかを最近触っていて、知見を広めたいというモチベーションがあったので、
Provisioning Frameworks Casual Talks vol.1 に参加してきました。
講演の内容としては以下の通りです。
@fujiwara さん - 新卒研修でserverspecとChefを使った話
http://dl.dropboxusercontent.com/u/224433/pfcasual_1/index.html@sethvargo さん - “chef-plus-environments-equals-safer-infrastructure”
https://speakerdeck.com/sethvargo/chef-plus-environments-equals-safer-infrastructure@hiboma さん - SqaleのChefとテストの話
(資料がみつかりませんでした……)以下、メモ書きです。
なんか間違ってたら指摘して下さると助かります。
(@naoya_ito さんのトークの終わりあたりからメールの対応をせざるを
得ない状況に陥ったので、メモの量が少なくなってます……すみません)
メモ
- @fujiwara さん - 新卒研修でserverspecとChefを使った話
- 手作業でのセットアップはだるい
- シェルスクリプトを書くよりもChef で書いた方が良いのでは無いか
- Chef が出始めのころ
- 当時はPuppet の情報を知らなかったので、特別比較して採用した訳ではない
- Chef 全般の話
- Chef-Solo はサーバー代数が増えてくると意味が無い
- WebUI とか実際使わない
- 開発者向けのVM 構築にsolo を採用
- Cookbook 運用の話
- 各サービスで大本のCookbook を個別でカスタマイズして使っている
- → 完全に共通化は出来ない
- Cookbook のリポジトリを作って、サービスごとにブランチを切って運用している
- Merge はしない。難しいから。
- よさげなCommit をCherry-Pick で取り込むスタイル
- 各サービスで大本のCookbook を個別でカスタマイズして使っている
- Chef-Server vs Chef-Solo
- 各サービスごとにChef-Server を用意したくない
- 強力なChef-Server (一元管理できるような) を立てる方法も有るには有るが……
- solo + sh で運用、後にsolo + capistrano に移行
- Solo でやるよりもChef-Server で運用する方が良いのか？
- 台数がそこまで無いのならsolo でも良いのでは
- インフラ管理者とアプリ開発者が分離してしまう
- Chef はインフラ、デベロッパはアプリデプロイ
- アプリのデプロイをChef でやるつもりはないが、互いにやってる事を理解したい
- AWS の台数をカジュアルに増やすときにChef を触る必要がある
- この時にいちいちインフラ管理者を呼ぶ必要が無いようにしたい
- 新卒研修の話
- serverspec
- サーバーが要件を満たしているかどうかをテストできる
- recipe とspec は対応している
- spec を書いてからcookbook を書いてやると良いのでは無いか
- serverspec ではコマンドの実行結果もテスト出来るので、振る舞いレベルのテストもできる
- cron とテストスクリプトを組み合わせて監視すると、人的なオペレーションミスも検出できる
- まとめ
- 手作業からバージョン管理されたコードへ
- 「コードを書いてテストを書く」これをインフラでもやらなければならない
- 監視 = 継続的なテスト
- @antipop さん - 宣伝 入門Puppet
- 以下から出版中
- パブー (←一番利益率がよいとのこと。是非)
- 達人出版会
- Amazon
- 入門Puppet Tシャツもある
- 日本初のPuppet 本
- Puppet を使っていると苦労する
- 日本語の資料が少ない
- 日本語の資料、有るには有るし内容は良いが、情報が古かったりする
- 結局、英語の厚いドキュメントを読まないとやってられないのでつらい
- オペレーションの専門家だったらできる（やる）けれど、カジュアルに使ってみたい人にはきつい
- 入門Puppet の読者層はオペレーションエンジニアよりもアプリケーションデベロッパを装丁している
- 基礎編
- Vagrant を使って、ハンズオン形式で学べる
- 本当に必要な事のみに絞って書かれている
- 応用編
- class/module などの大規模なmanifest を書くために必要な事が書かれている
- td-agent を作成するといった、実践的な内容を取り扱っている
- 人工的な例だと不自然で分かりにくいので現実に即したお題を
- テスト・デプロイについても言及している
- Learnning Puppet は良いリファレンスだが、入門に使うには難しい
- Chef で出来る事はPuppet でもできる
- エンジニアの共通語はコードである
- システムの状態をコードで記述し、ソーシャルシステム構築を行う
- 秘伝のタレ的なものを無くす
- プルリクでレビューも出来る
- システムの状態をコードで記述し、ソーシャルシステム構築を行う
- プラットフォーム固有のアセンブラ→高級言語
- プラットフォーム固有の手作業→Puppet/Chef
- システム構築に無精を持ち込む
- サーバー立てるにあたって、面倒な事が多すぎる
- 一見、プロビジョニングツールは面倒だが、面倒を回避するために面倒をこなして勉強する
- これぞ無精
- Infrastructure as code
- Chef vs Puppet
- Puppet: 外部DSL、ディレクトリ構成は比較的自由
- Chef: 内部DSL、ディレクトリ構成が固定されている
- DSL が外部か内部かは問題ではない
- やること、やれることは同じ
- Puppet はファイル1枚から始められるので導入障壁が低くて良いのではないか
- 以下から出版中
- @naoya_ito さん - 入門 Chef Solo 落ち穂拾い
- 実際の電子書籍の売れ行きに関して
- 現時点で合計2409部出ている
- 週に80 くらいのペースで出ている
- 電子書籍の売り上げで家を建てたい
- Facebook の話
- Chef-Server かChef-Solo か
- →Opscode がホスティングしてるやつをそのまま使う
- クライアントが途方もない数存在する
- それに対してサーバーが少ないと通信量の問題やら計算量の問題とかで大変なことになる
- テストはとても便利だし、必須
- 折角Chef とかで自動化しているのに、立ち上がっているかどうかを目視で確かめるとかナンセンス
- Chef-Server かChef-Solo か
- Chef でどこまでやるのか
- どこまでも
- 基本的にはChef だけでやる
- インスタンス起動後の構成変更は全てChef で行う
- 直接触ってはならない。外部からの変更が加えられると、Chef は元の状態に戻そうとする。
- アプリケーションのデプロイは例外。capistrano など
- Chef は自動化ツールではない
- Chef はノードの状態を管理するものである
- Convergence (収束)
- Chef はノードを有るべき状態に収束させる
- ノードの状態は全てChef のrecipe に書かれていなければならない。
- ssh で構成を変更するとChef の預かり知らない領域が出来てしまう。
- アプリケーションのデプロイは例外
- rollback とかがあるから
- ブルーグリーンデプロイとかもあるから
- Chef-Solo でどこまでやるのか、できるのか
- 数百台〜 Chef-Server 一択
- 数十台くらいまで Solo でも頑張れる、Server を導入するかどうか迷うところ
- 数台だったら xargs + knife solo でよいのでは
- xargs につらくなってきたらcapistrano の出番
- Chef-Server はノードの検索が出来る
- 莫大な数のノードがあると、どんなノードがあるかとか把握しきれない
- 検索があると便利
- 莫大な数のノードがあると、どんなノードがあるかとか把握しきれない
- Chef-Server ではClient が自立更新できる
- Chef-Server は導入が面倒
- chef-zero がある
- 未確認情報
- Chef vs Fabric
- Fabric (with シェルスクリプト) とChef はコンセプトが大きく異なる
- Chef は状態を管理する
- レシピとは異なる状態を、レシピに書かれた状態にする
- 場合によっては戻す
- 何度実行しても収束するので安心できる
- Fabric は状態を管理しない
- 書かれたとおりに実行する
- 前進あるのみ、収束しない
- Git でレシピを管理すればノードの「状態」をバージョン管理する事が出来る
- 開発環境の構築にChef を使う
- VM イメージを配るのか、レシピを配るのか
- レシピ
- VMイメージが古くなったら悲しい
- 折角レシピがあるのだから、自前で適用するべき
- ソーシャルコーディングもできる
- VM イメージを配るのか、レシピを配るのか
- テストはどうするのか
- serverspec: インテグレーションテスト
- before convergence なテスト
- knife cookbook test - シンタックスチェック
- foodcritic - LINTER みたいなもの
- chefspec - ユニットテスト的なもの
- strainer - 上に挙げたツールの実行を補助する
- エディタの保存時をフックしてテストを自動で走らせるとか
- インテグレーションテスト
- minitest-chef-handler
- serverspec
- Test Kitchen - 複数環境のVagrant を立ち上げて、minitest を走らせる
- 定番はTest-Kitchen + minitest
- Test-Kitchen + serverspec が良いのでは
- 処理系に依存しない、将来的に何かに乗り換えるときもそのままテストを流用できる
- 実際の電子書籍の売れ行きに関して
- @jhotta さん - Chef市場動向
- Opscode のDocs の通信量の10% は日本人
- 10人に1人は日本人（！）
- Chef だのPuppet だのは関係無い
- いずれ使う
- 早くしたほうが良い
- 大きいデプロイメントにいきなり使わないこと
- 小さいデプロイメントからこつこつと
- プロビジョニングツールはもはやギークのおもちゃではない
- ビジネスツールになりつつある
- Opscode のDocs の通信量の10% は日本人
- @sethvargo さん - “chef-plus-environments-equals-safer-infrastructure”
- すみません、メモ取れてないです……
- ざっくり聞いてる感じだと、環境のマイグレーションとかアップグレードの話題に触れている感じでした
- 他の人のブログが詳しいと思うので、そちらで……
- @hiboma さん - SqaleのChefとテストの話
- Sqale はコンテナというユーザーの領域がある
- EC2のインスタンスの上にPuppet で土台作ってChef-solo でchroot 環境を構築、その上にコンテナが動いている
- chroot 環境をchef-solo で作る
- ユーザーごとの環境も作る
- ユーザー追加するたびに同じような環境を作成する必要がある
- ユーザー削除する時も同じように削除する必要がある
- puppet とchef、普通は混ぜない (Sqale では混在している)
- 管理しているスコープが違うので今回はオッケー
- 特殊事例
- テスト
- ビヘイビアテスト
- 数年サービス続けてもサービスがデグレしないように
- 「◯◯出来ないこと」もテスト出来ないとだめ
- Jenkins で毎日テスト、yum update も毎日
- 収束するので安心
雑感
Chef、Chef-Solo を触ってからまだ日が浅いので、情報に追いついていくのがやっとの状態でしたが非常に勉強になりました。「Chef-Server とChef-Solo をどういった基準で使い分けるのかの判断」といった話題はやはり経験が物を言うと思うので、
経験豊富な先駆者の皆様から貴重な情報を聞く事が出来て良かったです。
あと、テストの話題が多く出ていて大変参考になりました。
実際にどうやってテストをすれば良いのかがいまいちピンと来ていなかったのですが、
とりあえずserverspec が良い感じだ！！！！ という事が分かったのは収穫でした。
「調べようにも、それを調べる為のワードを知らないが為に詰む」というケース、結構あると思うんですよ。
そういう場合には人に聞くのが一番なんだけれど、周りに聞ける人がいないしインターネッツでも誰も相手してくれない！！ 本格的に詰んだ！！ という時に、
こういう勉強会に参加して情報仕入れて、ググリングワードを獲得する、みたいな流れは本当に重要だと感じているんですよね。
今回は「テストしたいけどどうすりゃいいんだろう、ググっても良い感じに引っかからない……」という軽く詰んだ感じの所に、
「serverspec」という検索ワードを手に入れられたのは本当に良かったです。それだけでも儲けものみたいな。
なので、プロヴィジョニングフレームワークに話題を絞った勉強会を開催して下さった@studio3104 さんと発表者の皆様には大変感謝しております。
次回もよろしくお願いします！！！
(付録) 事前登録不可/先着順受付というシステムに関して
僕みたいな小心者は「会場、入れるのかな……定員オーバーして入れなかったらどうしよう……わざわざシヴヤとかいう怖い所まで来てるのに……ｳｯ、胃が」みたいな感じになっちゃうので、メンタルに良くない感じはしています！！！ 1日中そわそわしてしまう！
事前登録不可/先着順受付システムって、事前登録制に於いてドタキャンしたりカジュアルに遅刻してきたりする人があまりに多すぎる為に出来たシステムだと思うんで、
それは良いと思うし画期的だと思うんです。
ですが、それって今までちゃんとやってきた人達 (遅刻とかしない人達) が割を食ってる印象が拭いきれないんですよね。僕だけかもしんないですけど。
個人的には事前登録方式の方が安心感があって良いなーと思っています。
とかなんとか言ってますけど、主催側の一番楽な方法が良いと思います！！！ 我々は開催して頂いている側なので！！
