クラスメソッド開発者ブログ課外授業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月から。まだベータ。

を見ると

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

非常に現場感のあるプラグマティックな勉強会でナイスでした。ありがとうございました!
 

Amazon Web Services クラウドデザインパターン 設計ガイド
玉川 憲 片山 暁雄 鈴木 宏康
日経BP社
売り上げランキング: 9,126
Amazon Web Services クラウドデザインパターン実装ガイド
大澤 文孝
日経BP社
売り上げランキング: 7,693

コメント

タイトルとURLをコピーしました