読者です 読者をやめる 読者になる 読者になる

smallpalace's blog

鯖缶主婦の日々の記録です

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、Ldapnagiosとかカーネルも管理

サーバ構築自動化

chrootしてからchef-soloを流すだけ。

レシピはmount --bindしてホストOSを参照している

chreootだとホスト名ベースでレシピを当てられないのでchef-soloした

さしみたんぽぽ作業なのでchef-soloでやっちゃおうと。

ユーザ名を変えるだけで同じような環境がぽこぽこできるのがいいかなと

attributeで変数を注入する

削除するときにも冪等性がきいてくる

消すときも冪等性で心理的に安心

仕様変更したい場合もChef-soloする

ユーザ名に依存しちゃうような仕様を変えるときに便利

 

いとうなおやさんいわく

ユーザー名とかドメインスペシフィックなデータはData Bags、リソースに紐づく属性にはAttributes と使い分けるといいみたい 

だそうです。

 

振る舞いテスト=動く仕様

これを使えばPuppetやChefのリファクタリングも容易になる。

 

なにをテストするかうちの環境の場合

chef-soloでLinuxコンテナ作成、プロセス起動テスト、ミドルウェアテスト、SSH、コンテナでRSpecを作成

 

RSpecの中身

ユーザーさんの行動模擬テスト

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時頃というね。乳吸って満足げにニヤニヤしてるのちょっとかわいいけどね。

 

f:id:smallpalace:20130511052046j:plain 

 ではどうもご覧いただいてありがとうございました。