DevOpsといえば、ChefやPuppetを使ってプログラマブルにインフラ、というイメージがありますが、AWSのツールでも、これだけ奥の深いことができ、導入実績もありますよ、というお話。 このDevOpsの実践にRubyの知識はいりません。

1. Elastic BeanstalkでDevOps
～ChefもPuppetも使わずにDevOpsの実践～

2. 自己紹介
 名前：多賀亮一
 得意分野：AWSベースのインフラ構築、開発環境の整備
 Facebook：https://www.facebook.com/ryoichi.taga
 Twitter： @angelndxp
 開発実績：
 Kanmu CLO (https://clo.kanmu.co.jp/)
 他、非公開案件も多数。
 OSS参加
 Redmineベースの統合開発・ソース管理環境「ALMinium」プロジェクト

3. DevOpsの解釈
 デプロイ戦略、自動運用まで、システムの
一部と考え、開発段階からデプロイから運
用までの流れをすべて組み込んでしまうこ
と。そのうえで、運用を自動化してしまう
仕組みを構築する。

4. ChefもPuppetも使いません
 DevOpsといえば、Chef, Puppet, OpsWorks(Chef互
換)を利用したプログラマブルインフラのことを意
識する人がほとんど。
 しかし、これらのツールでの構築は構築コスト・
運用(作り変え)コストが非常に高い！
 なぜインフラエンジニアにRubyの知識が必要な
の？
もっと簡単に構築できないか？

5. Elastic Beanstalkを積極的に使う
 Webサーバー、ロードバランサー、監視システム、オートスケール、
データベース(オプション)を一式まとめて整備できるシステム。Gitデ
プロイが使え、リポジトリの「ブランチごと」に環境設定ファイルを
もってデプロイできる仕組みがある。→ これだけでもDevOpsの一部が
実現する。
 ただ使うと、AWSがあらかじめ準備した範囲でしか利用できないが、
いろいろカスタマイズできるので、カスタマイズを極めるとGitデプロ
イレベルでサーバー設定値が変更できる仕組みが埋め込めたりするの
で、Chefより便利なこともある。
 インフラ用のCMSみたいな存在
 カスタマイズを極めろ！

6. カスタマイズの考え方のコツ
 カスタムAMIを作る (必ず一度EBで環境作った後のAMIをベースにカスタマイズ)
 Linuxパッケージの yum insyall, yum erase, rpmインストールが必要となる場合
 Ruby の gem install、PHP の pear install など、言語環境を整備するとき など
 システムデプロイ(eb update)レベルで変更できる (AWSコンソールでもできる)
 オートスケールのリミットを増やす
 Document Rootの変更
 監視通知用メールアドレスの変更 など
 アプリデプロイ(git aws.push)レベルで変更できる (.ebextentionsで書ける)
 PHPパラメーター(php.ini)
 apacheパラメーター、nginxパラメーター
 fluentd(td-agent)の設定、Snapshot Logの追加
 デプロイ時に実行したいコマンド(シェルスクリプトで可能な範囲) など

7. デプロイしたらサーバー再起動する仕組みを
入れてみる例 (fluentdの再起動)
files:
"/opt/elasticbeanstalk/hooks/appdeploy/enact/95_td-
agent_restart.sh":
mode: "000755"
owner: root
group: root
content: |
#!/bin/bash
# If td-agent(fluentd) is not running, then start it.
if [ ! -e /var/run/td-agent/td-agent.pid ];
then
/etc/rc.d/init.d/td-agent start
else
/etc/rc.d/init.d/td-agent restart
fi
赤いディレクトリの
位置にシェルスクリ
プトを置いておくと、
「デプロイの最後」
に自動的に走るよう
になる

8. オプション設定ファイルでVPC配置？
 Elastic BeanstalkをVPCに配置することって簡単にできないの？
 できます。ただし、事前にVPC環境を準備しておけば。
 秘密の方法を使えば、WebアプリをMyltiAZ化することも！(Elastic
Beanstalk MultiAZ with VPCと命名。次ページ構成図参照)
＜シングルゾーン配置のオプション記述例＞
[aws:autoscaling:launchconfiguration]
SecurityGroups=sg-eb52b68o
[aws:ec2:vpc]
ELBSubnets=subnet-b7c745dd
ELBScheme=public
Subnets=subnet-fdc5479r
VPCId=vpc-2f3cmf42
(注)設定値は架空のものです

9. Internet Gateway
VPC Subnet VPC Subnet
VPC Subnet VPC Subnet
EC2 Instances EC2 Instances
Elastic Load Balancing Elastic Load BalancingEC2 Instance With AMI EC2 Instance With AMI
VPC Subnet
Amazon RDS MySQL Instance
VPC Subnet
Amazon RDS MySQL Instance
Availability Zone Availability Zone
Security Group
ZoneA ZoneB
NAT Instance NAT Instance
Public
Private
Public
Private
PrivatePrivate
Elastic Beanstalk
MultiAZ with VPC
RDSはEBから制御しても、
独立で構築してもよい。
ただし、EB連動にすると、
アプリ部分を消す時にRDS
も消えてしまう。

10. 結論
 Elastic Beanstalkのカスタマイズを使い倒せば、Chef、
Puppetいりません！
 簡単にアプリケーションのMultiAZ環境も作れちゃいます。
 ある程度のサーバー設定値は、工夫をすることで「アプリ
デプロイと同じレベル」で変更可能になります。
 EC2キーがないWebサーバーの配置で、セキュリティー無
敵！ということも可能になる。
Elastic Beanstalkをもっと使おう！

11. この技術の導入実績あります。
どれだけ人が増えてもPV増えても、
サービスを落とさず自動運用する、
放置運用できるノウハウあります！
まずは相談からでも。
興味がある方はSNS等でご連絡ください。