capistano
knife-soloの内部はrsyncで死ねる(windows)
paratrooper-chef(落下傘)
chef_rolse_auto_discovery + AWS SDK
Capistrano + cef-soloではAutoScaliingには別の仕組みが必要
- [AWS opsworksを乗りこなせ]
opsworks
コアの仕組み
aws → opsworks
← ←
cher recips スタック全体の構成情報（json)
→ chef recipeの実行結果
opsworksはchef serverではない
ELBがコンソールから出来るようになったらしい（最近）
opsworksの管理単位
スタック
最上位のエンティティレイヤ
LB AP DB 監視
アプリケーション
RailsPHP
static
スタックの管理
時間や不可に応じてscale
stackのクローン
ライフサイクル
Setup インスタンスの構築 ソフトウエアのインストール(例：PHPアプリケーションサーバ) インストールrecipeもここConfigure
依存性のアップデート （例：LB,データベース、監視） スタックの設定次第で動的に変わるもの。Deploy/Undeploy アプリケーション
shutdown
インスタンスをレイヤから削除 LBから自身を外すrecipeを書いておくなどSetupはインスタンス起動時に1回だけ実行 Configureはインスタンスの増減した際に実行 deploy アプリケーションデプロイ時に実行
アンチパターン
DBクラスタの参加処理をsetupフェーズOSのソフトウェアパッケージのインストールをdeployのフェーズで。
スタック内の情報公開はJSONで。 インスタンスにログインしてコマンド叩けば情報はとれる
opsworks-agent-cli get_jcon
カスタムレシピのテストは、Opswoksで
knife-solo
vagrant+Berkshelf
Defailt VPCなアカウントならVPCの機能も使える（既存からは無理） ただし、中からコマンドを叩けばの話
注意
Ruby1.8
chef:0.9.15
カスタムレシピのアーカイブ構造
.gitは消せ
mycookbooksという名前でトップディレクトリ
カスタムレシピのアップデートしたら、updateコマンド叩け
LTSV ログのフォーマットが綺麗
serverspecの話
zabbixは有名だけど、すばらしいと思っている人がいなかった
参考 http://blog.kenjiskywalker.org/blog/2013/07/13/serverspec-chef-cookbook/
テンプレート化による使い回し
ブラウザゲームでの活用事例
テンプレートを分割
一発にこだわらないスクリプト感覚で。
- Chef with AWS プレゼンがかっちょいい
RubyDLSをjsonに？
-
お題
-
Chef VS Puppet
-
宗教戦争はない。
-
Puppletは用語と概念が結びつかない
-
Chefは、入り易い
-
本番運用に入ってからのchefの活用は？
-
serverspecを使ってみたがCI自動化までには使えてない
-
jenkinsがVMなので、その中でvirtualboxとか嫌だし（クックパッド
-
ec2をあげてくれればー(aws)
-
Engine yardはrecipeが納品物
-
テスト（CI)はやっている。
-
最初の開発はvagrant、PRしてCIしてマージして、デプロイお客には、アップデートが有りますと通知が出る。
-
chef-soloだけではクックブックと環境の紐付けが難しい
-
Devopsの文化を作ることが難しい
-
awsで環境を作ることはCloudFormation
-
デプロイは内製のスクリプト
-
クックブックは細かくする
-
インフラのクックブックはド頭で入れるだけで、途中で変えることは滅多にない
-
アプリのversionごとにAMI作っちゃう人もいる。毎回インストールじゃ遅い。
-
ベースとなるAMIを作って、そこに適用することにしている
-
前はサーバごとに用意していたが、破綻した。
-
デプロイサーバごとに５世代分くらいAMIを用意している（クックバッド）
-
engine yardは何もしてない。vagrantとAMIの差をどうすればいいのかになる。ただ、この場合だと入れるものが多いと時間がかかる。
-
救世主がhacker？
-
機械的にAMIを作る。そこから必要なchef-soloだけが走る
-
イメージだけで運用するのは良いんだけど、中どうなっているかわからなくなっていくので破綻する
-
出来上がった環境からcookbookを作れるようにならないかなぁ。いずれ誰かやると思うんだけど。設定ファイルくらいなら取り出すくらいはできるけど・・・。
-
アクセスキーの扱いはどうするのか
-
渋谷界隈で話をしてみたけど、解はなくキーを突っ込むとこだけ手動。
-
githubにはあげない。
-
オートスケールする場合には？解はないっぽい
-
公開鍵を管理して、配ってくれるOSSを誰か
-
EMC?
-
puplet
-
extarnalほげほげが、隔離されたDBからとってくる（クックバッド)。そこにアクセスできる権限管理は、pupletのサーバだけにしぼって・・・。
-
chef serverはどうですか
-
各マシンにrecipeを飛ばすことはないので楽。（普段はchef-zero)
-
サーバの種類が十数台。これはsolo
-
chef serverのインスタンスを持てるかどうか（顧客費用だし）
-
数百台を構築するのでは、その数百台の今の状態を管理するほうが重要
-
chef serverで構築すれば管理ができるのではないか（個別でログインしてないからだろうな）
-
chefが構築ツールになっているので、運用中に変えることがない。
-
soloはあくまでsolo.サーバ間の協調運転には向かない。
-
サーバの管理をchefserverのAPIで管理できるならいいけど、そんなに違いがない 使い易さより、サーバの管理 ＜ chef server
-
だいたいみんな目で追える
-
chefを環境構築ツールとみるか、構成管理ツールを見るかで、soloとseverの適用の考え方は違う
-
CloudFormationとchefの違いを考える？（AWSの人でも統一性はないようだ）
-
CloudFormationとChefが使えるなら、Chefを使うべき
-
構成構築まではCloudFormation.
-
CloudFormationのテンプレートの作成はAWSの中の人でも大変
-
AWSに特化しないようにしている。環境に依存しない
-
監視システムとの連動は。
-
ZABIIXは2.0が勝手にやってくれる(autoDiscovery)
-
IPとホスト名の枠を決めておけば、上がってきたときに拾えるので・・・という自作
-
自動化は出来てない人が多い。サーバを立てるけど・・・。
-
awsのタグで管理（クックパッド)でも、インスタンスにtagを付けるのは人・・
-
engine yard はフルオート
-
New Relicは流行りそうな気配
-
自動化やるべき.泥臭いのあるけど、手作業よりマシ。
-
規模に関わらず、めんどくさいことは自動化はするべき
-
教室を貸してくれた専門学校では、授業でAWSを使っている。
-
AWSが８０００ドル分のチケットをくれた。