品川シーサイドから秋葉原遠い＆ATNDのリンクをボチって押してGoogle Mapが指してたところが
合ってなくて、迷ってしまい結構遅刻して参加…。
「ChefとOpsWorksでEC2楽チンクッキング！」
■ Chef, Puppetの心得
・コマンドで直接作業はしちゃダメ。
・AMIのイメージは共通の1つのものにして、
APサーバーとかDBサーバーとかは、Chef, Puppetで構築。
■ Chefの紹介
Opscode社が作っているOSS。
OpscodeとOpsWorksは特に関係ない。
・スタンドアロンタイプのChef Solo
・クライアント・サーバータイプのChef Client & Server
Chef Soloの方が簡単だけど、クライアント・サーバーでないと使えない機能が多少ある。
■ Chefの主な機能
Cookbook：Chefの設定をまとめる単位。実際はフォルダ。
Recipe：Chefで構成する内容を記述。Rubyで書く。
Template：設定ファイルのひな形
あとAttributeとかEnvironment(クラサバのみ)とか。
■ Chef Soloのデモ
・ls叩くと、、
cookbooksディレクトリ、localhost.json, solo.rbって感じ。
・cookbookディレクトリは、、
attributes, recipe, templateって感じのディレクトリ構成
・具体的なRecipe。
-packageってのでパッケージ入れる
-serviceってのでサービス立ち上げ
-templateからconfを〜って感じ。
・Attributeでの設定
ポートとかdocument_rootを外出しで設定したり。
10台にチョコチョコ設定変えて〜なんてのも出来る。
・コマンド叩くと
rpm -q nginxで入ってるし、netstatで80番ポートをリスンしてる
■ AWSのOpsWorksとは
・ドイツのPeritor社のScalariumがベースになっている。
Aamazonが買収して2013年2月から。まだベータ。
Peritor has been acquired by Amazon Web Services.
って書かれてる。
・Chef Solo + LifeCycleEvents
– Stack：OpsWorks全体の設定
– Layer：インスタンスのグループ
– Instance：EC2インスタンス
– Application：配置するアプリ
– Management Consoleとコマンドも
・非対応のAWSコンポーネント
– VPCダメ (default VPC限定)
– Auto Scalingダメ (OpsWorks独自の簡易版がある)
– RDS連携はない感じ
– ELBは昨日(5/15)対応したらしい
■ OpsWorksのデモ
シンプルで直感的なUI。
■ まとめ
・OpsWorksだと多彩なChefプラグインが使えない
・OpsWorksは今後AWSの各種コンポーネントと連携するはず。まだ発展途上。
現状だとChefでやりくりして、OpsWorksの動向をウォッチするのが良さそう。
クラスメソッドさんのブログは月35万PVらしい。スゴイ。
「Rudess（仮）を支える技術 ～ CloudFormationの活用事例と詳細解説」
■ Rudessとは？
– オンデマンドの画像リサイズサーバー。
– 画像ソースはS3、メタデータはDynamoDB、アプリはEC2上でJava。
– EC2インスタンスはAuto Scaling。負荷分散はELB。CDNはCloudFront。
– APIへのアクセスの権限はIAM Roleを使用。
通常API叩きたかったらキーをソースに。アプリの中にクレデンシャル書きたくない。
IAMとは？EC2インスタンスに対する許可。
Javaだとコンストラクタで指定しないと、アプリが走ってるサーバのIAMロールを自動で使ってくれる。
– 秘密のフレーズを含むハッシュ値をURLの中に記載してそれが一致しないと処理しないようになってる。
■ Rudessを使うには
サーバー調達、OS入れて、ミドルウエア入れて、アプリケーションデプロイして、、ってのを省略出来るけど
DynamoDBにテーブル作る〜とか、そういうのは省略出来ない。
⇒ CloudFormation
■ CloudFormationデモ
Create Stackする時に、Amazonが用意してくれているもの/自分のローカルファイル/インターネットのURL指定
という感じでテンプレートを指定出来る。JSONで記述されている。
出来上がるまでに25分くらいかかる。。
■ CloudFormationの設定
設定項目は大きくこんな感じ↓
Resource：S3〜とか。
Parameter：DynamoDBに渡すProvisionedなRead/Writeのパラメータとか。
1000とかベタっと書かないでRefってので変数を参照するような書き方が出来る。
Mapping：Availability Zoneの割り付けとか。
Output：Management Consoleに例えばAPIのURLを表示させる〜とか。ドメイン名取得してhttp://をくっつけるとか。
CloudFrontの設定とか、IAM Roleは記述がながーくなるので、設定は面倒だけどサンプルはあるとか、
AutoScalingGroup/LaunchConfigの設定とか。AMIはリージョン毎なのでMappingの仕掛けを使って〜。
↓のような事はChefとか使えばスッキリしそうだけど、、
—-
Apache入れて、Tomcat入れて、AWSに入ってるJavaは6でEOLだからとかして、chkconfigの設定とかしてから
シャットダウン後にAMI取得
—-
UserDataを使ってどこにアクセスしに行くか〜とか。
■ デモに戻る
まだ作ってるので、、プレゼンに戻る。
〜その後〜
CloudFormation上で構築が終わっても、
EC2のインスタンスが上がってロードバランサ配下に入るまでヘルスチェックが何回か〜
初回だけ処理時間かかるけど、2回目からはNot Modifiedで早い。
ハッシュ値をちょっとでも変えるとエラーになる。
実際に構築してサービス提供するとこまでイケるのはスゲー！
■ まとめ
クラスメソッドさんではAWSエンジニアや案件などを募集している
■ 質問
デバッグどうしてるの？
– JSONがvalidか
– 必須のパラメータがあるかどうかのチェックツールもある
– Stackの構築中に落ちると全部マルっとロールバックする(ロールバックしないでってチェックボックスも)
– 壊すのにも時間かかる。一個一個依存関係順に構築していくし、壊す時も一個一個。
CloudFormation使うとS3のバケット名とか覚えにくい名前がついちゃったり
– 仕方ない
– 世界で1つの名前でなければならないので
– UserDataを使って〜ってのはCloudFormationじゃなくてもイイアイデア。
—
非常に現場感のあるプラグマティックな勉強会でナイスでした。ありがとうございました！
日経BP社
売り上げランキング: 9,126
日経BP社
売り上げランキング: 7,693
コメント