クラスメソッド開発者ブログ課外授業8日目｢AWS管理を自動化する奥義｣にいってきました。

品川シーサイドから秋葉原遠い＆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月から。まだベータ。 http://www.scalarium.com/ を見ると

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じゃなくてもイイアイデア。