この記事について
私が AWS OpsWorks を実際に利用するうえで、最初に知っておけたら良かったということをまとめています。
フィードバックはお気軽にいただけると嬉しいです！
紹介ムービー
AWS OpsWorks のご紹介（日本語字幕）
https://www.youtube.com/watch?v=T76k-QR39LI
内部で利用されている主なオープンソース技術
- Git
- Chef
- Capistrano
- Monit
OpsWorks の勘所
設計の方針
冪等性(Immutable Infrastructure)を意識して構築します。いつでもボタンをポチるだけでインスタンスが入れ替え可能な状態。そこで次のような方針をとります。
保存すべきデータや複雑な設定は EC2 から切り離す、減らす。
そうすると具体的には次のような組み立て方をしていけば良いことがわかります。
- データベースは MySQL レイヤーは使わず RDS を使う。
- ロードバランサーのレイヤーも使わず ELB を使う。
- Instance Store を採用し、EBS への依存を排除。
- アセットファイル、アップロードファイルは S3 へ投げる。
- セッション、キャッシュは Memcached や Redids を利用。
- キューイングは Redis や AWS SQS を利用。
- メールは AWS SES や SendGrid を利用。
- ログは fluentd で S3 へ投げる。
設定、運用について
- リポジトリに含めたくない情報は環境変数(App の設定)を利用して渡す。
- Custom Cookbook は 本家の Cookbook を複製して独自のブランチをきり、Rebase をしながら本家に追従させる運用をとる。
- EC2インスタンスから S3 や SES などの AWS の各リソースへのアクセス制御には IAM Role を使う。鍵の設置/設定なしでリソースが利用できるためシンプルになる。
- Staging 環境や検証用環境構築は Stack の複製機能を使うと楽。
Custom Cookbook 利用タイミングの例
- 標準で用意されてい設定ファイルに設定ファイルに大きな変更が必要(設定値変更ならCustom JSONでOK)。
- Sidekiq や fluentd(td-agent) など標準で用意されていないツールの導入。
- Cronジョブの追加。
注意点
- AWS オートスケールは使えない(っぽいのはある)。
- Cookbook のカスタマイズは割と普通に発生する。
- RDS は1スタックにつき1つという考え方。
最後に
naoya 氏のコメントが的を得てますのでそのまま引用させていただきます。
例えば顧客毎にアプリケーションの実行環境を用意するようなビジネスのモデルなんかでも大活躍ですね。グループウェアとか。むしろビジネス的には、そこが一番重要なところなのかもしれない。
参考
AWS OpsWorks とは何ですか? - OpsWorks ユーザーガイド
https://docs.aws.amazon.com/ja_jp/opsworks/latest/userguide/welcome.html
aws/opsworks-cookbooks - Github
https://github.com/aws/opsworks-cookbooks
AWS OpsWorksハンズオン - SlideShare
http://www.slideshare.net/AmazonWebServicesJapan/aws-opsworks
AWS OpsWorks(™)のCustom Cookbooksレシピ開発役立ちメモ - Qiita sawanobolyさん
http://qiita.com/sawanoboly/items/147f550878477ff7723e