Application Deployment on AWS

Application Deployment on AWS
Amazon Web Services Japan 篠原英治
2015年年12⽉月8⽇日

{
"Name" : "篠原英治",
"Twitter" : "@shinodogg",
"Blog" : "http://shinodogg.com",
"Proﬁle" : {
"Role" : "Solutions Architect",
"Market": "Startup",
"Subject Matter Expert" : [
"Amazon CloudSearch",
"Amazon Elasticsearch Service",
"Amazon Simple Workﬂow Service",
"AWS Elastic Beanstalk"
]
}
}

Agenda
•  AWSのデプロイメントサービス
–  AWS CodeDeploy
–  AWS Elastic Beanstalk
–  AWS OpsWorks
–  AWS CloudFormation
•  Accelerating Software Delivery on AWS
–  AWS CodePipeline

Deploy？
•  アプリケーションやア
セットの更更新をサーバ
に反映させること
•  実際には、更更新された
ファイル群を対象の
サーバ群に配布する Availability Zone
Availability Zone
v2

デプロイとビルド・プロビジョニングの違い
•  ビルド
–  ソースコードから配布すべ
き成果物を⽣生成する
•  プロビジョニング
–  サーバにソフトウェアをイ
ンストール&設定
•  オーケストレーション
–  DBやLBとのつなぎ込み
•  デプロイ
–  アセットの更更新をサーバに
反映
ソース
コード
ビルド
ex. mvn, bundle
プロビジョニング
ex. chef, puppet
オーケスト
レーション
デプロイ
Apache,
Nginx
Ruby, JDK
Conﬁg,
etc.
WEB LB
DB
Amazon
Linux

よくあるデプロイ⼿手法と課題
•  Push型 – デプロイ元からデプロイ先へ
–  FTP, rsync, git pull
–  Capistrano, Fabric
•  課題
–  ⾃自動化できていない
•  ⼈人間がサーバにログインしてコマンドを⼿手動で実⾏行行している
–  デプロイサーバの負荷、シングルポイント
–  新規サーバ構築時にデプロイ対象がわからない
–  複数⼈人でデプロイがぶつからない様に管理理するのが⾯面倒

デプロイの効率率率化・安定化
•  質の⾼高いリリースのためには、必要不不可⽋欠
•  効率率率的で安定している仕組みがあるなら、それ
を使わない⼿手はない
AWS CodeDeployが選択肢

AWS CodeDeploy
•  1台も数千台も同じやり⽅方で
•  開発環境もステージング環境もプロダクションも同じやり⽅方で
•  ダウンタイム無くデプロイ
•  中央でデプロイをコントロール・モニタリング
Staging
AWS CodeDeployv1, v2, v3
Production
Dev
⾃自動デプロイのコーディネートを、Amazonの様に
Application
revisions
Deployment groups

AWS CodeDeploy概要
•  デプロイに特化したサービス
–  指定したグループに、指定したファイ
ルを、指定した割合ずつ
–  TagやAuto Scaling Groupでグループ
指定
•  エージェントを⼊入れれば利利⽤用可能
–  Pull型のデプロイ、EC2以外でも
–  Linux & Windows対応
•  関連する処理理をフックで実⾏行行可能
–  アプリ再起動なども⾃自動化できる
Staging Production
Dev
Deployment groups
Agent Agent
Agent
Agent
Agent
Agent
Agent
AWS CodeDeployv1, v2, v3

AWS CodeDeployの動作
1.  配布物をアップロード
–  Amazon S3 / GitHub
2.  デプロイを指⽰示
–  配布物ダウンロード
–  ﬁles: 所定の場所に配置
–  hooks: 任意の処理理実⾏行行
Deployment
group
Agent
Agent Agent
…
or
Amazon
S3
Application
1. Upload
ﬁles
hooks
/dst
2. Deploy
Downloa
d
Polling

Deployment conﬁg – デプロイのスピード
v2 v1 v1 v1 v1 v1 v1 v1
v2 v2 v2 v2 v1 v1 v1 v1
v2 v2 v2 v2 v2 v2 v2 v2
OneAtATime (1台ずつ)
HalfAtATime (半分ずつ)
AllAtOnce (全て⼀一度度に)
※任意の割合のconﬁgも作成可能

AppSpec File – デプロイの⼿手順書
•  ﬁles
–  どのファイルをどこに
配置するか指定
•  hooks
–  以下の⻩黄⾊色のEventで
実⾏行行する処理理を指定
version: 0.0
os: linux
files:
- source: config
destination: /etc/app
- source: target/hello.war
destination: /var/lib/tomcat6/webapps
hooks:
ApplicationStop:
- location: deploy_hooks/stop-tomcat.sh
ApplicationStart:
- location: deploy_hooks/start-tomcat.sh

Application – 成果物 + AppSpec File
•  フォルダ構成
–  appspec.yml (必須)
–  ビルド済の成果物
–  その他配布物
–  hookスクリプト
•  アップロード
–  Amazon S3のObject
•  zip/tar/tgz形式対応
–  GitHubのRepository
•  zip形式でダウンロードされる
/
!"" appspec.yml
!"" config/
#   %"" config.xml
!"" deploy_hooks/
#   !"" start-tomcat.sh
#   %"" stop-tomcat.sh
%"" target/
%"" hello.war
or
Amazon S3
注: ソースコードではなくmavenやbundle後の
ファイル群をput/pushすることをオススメ

AWS CodeDeployでやること、やらないこと
やること
•  ファイルをサーバに配る
•  hookスクリプトの実⾏行行
–  アプリ再起動
–  オーケストレーション
•  ELB付け外し等
•  これらの実⾏行行を中央管理理
–  進捗やエラーログが、ブラ
ウザやAPIで確認可能
やらないこと
•  ビルド
•  プロビジョニング
※ いずれもhookスクリプ
トで実⾏行行できなくはないが、
効率率率や安定性の⾯面で
オススメしない

AWS CodeDeployとAuto Scaling Group(ASG)
•  スケールアウト時に最新のリビ
ジョンが⾃自動でデプロイされる
–  ASGのLifecycle Hookを利利⽤用
–  追加インスタンスのみにデプロイ
•  Deployment GroupにASGを指定
するだけで利利⽤用可能デプロイに成功した最新の
リビジョンが⾃自動でデプロイ

AWS ElasticBeanstalk
•  特徴 (http://aws.amazon.com/jp/elasticbeanstalk/)
–  速く簡単にアプリケーションをデプロイ可能
–  インフラストラクチャの準備＆運営からアプリ
ケーションスタックの管理理まで⾃自動化
–  Auto Scaling によりコストを抑えながらスケー
ラビリティを確保
–  Java, PHP, Ruby, Python, Node.js, .NET,
Docker などに対応
•  価格体系 (http://aws.amazon.com/jp/elasticbeanstalk/pricing/)
–  追加料料⾦金金なし
–  アプリケーションの保存、実⾏行行に必要なAWSリ
ソース (EC2, S3, RDS, DynamoDB など) に対
してのみ課⾦金金
インフラ構成の構築・アプリデプロイの⾃自動化サービス

Elastic Beanstalk vs. Do It Yourself
On-‐‑‒instance conﬁguration
Your code
HTTP Server
Application Server
Language Interpreter
Operating System
Host

On-‐‑‒instance conﬁguration
Your code
HTTP Server
Application Server
Language Interpreter
Operating System
Host
アプリケーションの開発
”だけ”にフォーカス
Elastic Beanstalkにお任せ！

•  あらかじめ定義されたインフラストラクチャ
•  Single instance (開発環境, ローコスト)
•  Load balancing, Auto Scaling (本番環境)
•  Web Tier と Worker Tier
•  リソースのプロビジョニング
•  Load Balancer
•  Auto Scaling group
•  Security groups
•  Database (optional)
•  ユニークなドメイン名の提供
•  例例) yourapp.elasticbeanstalk.com
Infrastructure stack

•  アプリケーションを簡単にデプロイ
•  複数バージョンの切切り替え
•  複数環境の切切り替え
Easy Deployment

Elastic Beanstalkでアプリケーションを
デプロイするのに必要なこと
1
2
3
4
Region
Stack (container) type
Single-‐‑‒Instance
Load Balanced
w/ Autoscaling
or
Database (RDS) optional
Your code
Supported Platforms

1
2
3
4
Region
Load Balanced
w/ Autoscaling
or
Your code
■ デプロイを⾏行行う⽅方法
1. AWS Management Console を使う
2. AWS Toolkit for Eclipse/Visual Studio IDEを使う
3. EB Command Line Interface(EB CLI) を使う
$ eb deploy
Elastic Beanstalkでのデプロイ

Elastic Beanstalkでのデプロイ
1
2
3
4
Region
Load Balanced
w/ Autoscaling
or
Your code
■ デプロイを⾏行行う⽅方法
1. AWS Management Console を使う
2. AWS Toolkit for Eclipse/Visual Studio IDEを使う
3. EB Command Line Interface(EB CLI) を使う
$ eb deploy
今回は上記3.のEB CLIを使ったデプロイ⽅方法をご紹介します

サンプルアプリケーション
•  Node.js + Expressな会員登録アプリケーション
–  ソースコードは↓から⼊入⼿手可能
–  https://github.com/awslabs/eb-‐‑‒node-‐‑‒express-‐‑‒sample

サンプルアプリケーションのデプロイ
1.  EB CLIのインストール:
$ pip install -‐‑‒-‐‑‒upgrade awsebcli
2.  サンプルアプリケーションのダウンロード:
$ git clone https://github.com/awslabs/eb-‐‑‒node-‐‑‒express-‐‑‒
sample.git
3.  Elastic Beanstalk applicationの作成:
$ eb init
4.  プロンプトに従って環境の設定
5.  リソースの作成およびアプリケーションのローンチ:
$ eb create

•  eb initのプロンプト: リージョンの選択
Select a default region
1) us-‐‑‒east-‐‑‒1 : US East (N. Virginia)
2) us-‐‑‒west-‐‑‒1 : US West (N. California)
3) us-‐‑‒west-‐‑‒2 : US West (Oregon)
4) eu-‐‑‒west-‐‑‒1 : EU (Ireland)
5) eu-‐‑‒central-‐‑‒1 : EU (Frankfurt)
6) ap-‐‑‒southeast-‐‑‒1 : Asia Pacific (Singapore)
7) ap-‐‑‒southeast-‐‑‒2 : Asia Pacific (Sydney)
8) ap-‐‑‒northeast-‐‑‒1 : Asia Pacific (Tokyo)
9) sa-‐‑‒east-‐‑‒1 : South America (Sao Paulo)
10) cn-‐‑‒north-‐‑‒1 : China (Beijing)
(default is 3):

•  eb initのプロンプト: アプリ名/スタック/SSH/Keypair
Enter Application Name
(default is "eb-‐‑‒node-‐‑‒express-‐‑‒sample"):
It appears you are using Node.js. Is this correct?
(y/n): y
Do you want to set up SSH for your instances?
(y/n): y
Select a keypair.
1) oregon
2) [ Create new KeyPair ]
(default is 2): 1

•  eb initのプロンプト: スタック
Select a platform.
1) Node.js
2) PHP
3) Python
4) Ruby
5) Tomcat
6) IIS
7) Docker
8) Multi-‐‑‒container Docker
9) GlassFish
10) Go
11) Java

•  eb createのプロンプト: Environment/CNAME/Deploy
Enter Environment Name
(default is eb-‐‑‒node-‐‑‒express-‐‑‒sample):
Enter DNS CNAME preﬁx
(default is eb-‐‑‒node-‐‑‒express-‐‑‒sample):
Creating application version archive "5529".
Uploading eb-‐‑‒node-‐‑‒express-‐‑‒sample/5529.zip to S3. This
may take a while.
Upload Complete.
Environment details for: eb-‐‑‒node-‐‑‒express-‐‑‒sample
Application name: eb-‐‑‒node-‐‑‒express-‐‑‒sample
Region: us-‐‑‒west-‐‑‒2
Deployed Version: 5529
Environment ID: e-‐‑‒ufxx79fmkc

•  EB CLIを使ってブラウザで表⽰示
$ eb open

•  UIを変更更
$ vim views/index.ejs
$ git commit –am “modify UI”
$ eb deploy
$ eb open

•  サンプルアプリケーションを動かす

.ebextensions を活⽤用した環境のカスタマイズ
–  Elastic Beanstalkの定義されたテンプレートのカスタマイズ
–  例例えば、”サーバー監視のサービスをインストールしたい”
本番運⽤用の際はバージョンを明記しま
しょう
http://www.slideshare.net/shotaumeda1/aws-‐‑‒startuptechsummer2015/15
Retty 梅⽥田さんのスライド
.ebextensionsでMackerelの
⾃自動インストールを実現

デプロイしたサンプルアプリケーションの詳細
•  resources.conﬁg – 追加のリソース定義
しょう
Resources:
StartupSignupsTable:
Type: AWS::DynamoDB::Table
Properties:
KeySchema:
HashKeyElement: {AttributeName: email, AttributeType: S}
ProvisionedThroughput: {ReadCapacityUnits: 1, WriteCapacityUnits: 1}
NewSignupQueue:
Type: AWS::SQS::Queue
NewSignupTopic:
Type: AWS::SNS::Topic
Properties:
Subscription:
-‐‑‒ Endpoint:
Fn::GetOptionSetting: {DefaultValue: xxx@xxx.com, OptionName: NewSignupEmail}
Protocol: email
-‐‑‒ Endpoint:
Fn::GetAtt: [NewSignupQueue, Arn]
Protocol: sqs

.ebextensions
•  .ebextensions を活⽤用してElastic Beanstalkに集約
–  option_̲settings セクション
•  環境内のAWSリソース、アプリケーションを実⾏行行するソフトウエアの
設定
–  resources セクション
•  CloudFormationがサポートするあらゆるリソースの追加および設定
–  環境を起動する際に使うCloudFormationテンプレートに追加
–  その他のセクション
•  packages、sources、ﬁles、users、groups、commands、
container_̲commands、services
•  起動されるEC2インスタンスの設定
•  セクション毎にファイルを分割するのを推奨
※ 設定ファイルはアルファベット順に処理理される

•  packages
–  yum/rpm/rubygems等を利利⽤用したパッケージのインストール
–  例例) yumから最新、rpmでURL指定、rubygemsでchef 0.10.2
.ebextensions
packages:
yum:
libmemcached: []
ruby-‐‑‒devel: []
gcc: []
rpm:
epel: http://download.fedoraproject.org/pub/epel/5/i386/
epel-‐‑‒release-‐‑‒5-‐‑‒4.noarch.rpm
rubygems:
chef: '0.10.2'

•  sources
–  外部からのアーカイブをダウンロードして指定した場所に展開
•  tar、tar+gzip、tar+bz2、zip をサポート
–  例例) S3にあるアーカイブファイルを指定したディレクトリに展開
.ebextensions
sources:
/etc/myapp: http://s3.amazonaws.com/mybucket/my.tgz

•  files
–  EC2上にファイルを作成。外部からファイルを取得することも可能
–  例例) ファイルをコピーしてrootだけ書き込める権限で配置
–  例例) シンボリックリンク myfile1.txt を参照する myfile2.txt
.ebextensions
files:
"/home/ec2-‐‑‒user/myfile" :
mode: "000755"
owner: root
group: root
source: http://foo.bar/myfile
files:
"/tmp/myfile2.txt" :
mode: "120400"
content: "/tmp/myfile1.txt"

•  groups
–  グループを作成
–  例例) groupOneはグループIDなし、groupTwoのグループIDは45
.ebextensions
groups:
groupOne:
groupTwo:
gid: "45"

•  users
–  ユーザーを作成
–  例例) ユーザーID、グループ名、ホームディレクトリの設定
.ebextensions
users:
myuser:
groups:
-‐‑‒ group1
-‐‑‒ group2
uid: "50"
homeDir: "/home/myuser"

•  commands
–  サーバー設定後、バージョンファイルが抽出される前に実⾏行行されるコマンド
–  例例) pythonスクリプトを実⾏行行
.ebextensions
commands:
python_̲install:
command: myscript.py
cwd: /home/ec2-‐‑‒user
env:
myvarname: myvarvalue
test: '[ ! /usr/bin/python ] && echo "python not installed"'

•  container_̲commands
–  サーバー設定後、バージョンファイルが抽出された後に実⾏行行されるコマンド
•  AWSセキュリティ認証情報などの環境変数にもアクセス可能
•  leader_̲only(option): AutoScalingグループのリーダーにするインスタンスのみ
–  例例) Djangoの管理理タスクを実⾏行行
.ebextensions
container_̲commands:
01collectstatic:
command: "django-‐‑‒admin.py collectstatic -‐‑‒-‐‑‒noinput”
02syncdb:
command: "django-‐‑‒admin.py syncdb -‐‑‒-‐‑‒noinput"
leader_̲only: true
03migrate:
command: "django-‐‑‒admin.py migrate"
leader_̲only: true

•  services
–  インスタンス起動時に開始/停⽌止する必要のあるサービスを定義
–  例例) 起動時にサービスサービスが⾃自動的に開始される
.ebextensions
services:
sysvinit:
myservice:
enabled: true

Elastic Beanstalkにおけるデプロイの選択肢
•  Rolling Deploy
現現現現

現現現現

新現現現

新新現現

新新新現

–  Batch type: Auto Scaling グループ内のインスタンスの割合もしくは⼀一定数
–  Batch size: 割合(%)もしくはインスタンス数(AutoScaling設定の最⼤大数まで)
–  2台ずつデプロイする場合の設定は Batch type: Fixed, Batch size: 2
–  例例) 30%ずつRolling Deploy

Elastic Beanstalkにおけるインスタンス置換え
•  Rolling Updates
–  アプリケーションデプロイではなくインスタンスの置換え
•  内部的にはCloudFromationのUpdate Policyを利利⽤用
–  VPC設定やAuto ScalingのLaunch Conﬁgurationの設定変更更
⼀一度度に⼊入れ替えるインスタンスの最⼤大数
最低限維持すべきインスタンス数
各Update操作間のPause時間

•  Blue/Green Deploy
現現現現

現現現現新新新新

新新新新

v1.1 v1.1
v1.1 v1.1
v1.1 v1.1
v1.1 v1.1
v1.2
v1.2
v1.2.1
v1.2.1
v1.2.2
v1.2.2
DNS
(Amazon route 53)
Webサーバー群
(Amazon EC2)
データベースサーバ群
(Amazon RDS)
ロードバランサー
90% 5% 3% 2%

•  Rolling Deploy? Blue/Green Deploy?
–  Rolling Deploy
•  新しくサーバーを⽴立立てるわけではないのでデプロイにかかる時
間が短い
•  新しいバージョンにバグ等があった場合にRollbackに⼿手間がか
かる
–  Blue/Green
•  新しくサーバーを⽴立立てるので環境作成に時間がかかる
•  Rollbackが容易易
•  Elastic BeanstalkのDNSのTTLはデフォルト60秒であるが、
接続元のデバイスによってDNSがキャッシュされてしまうよう
な場合デプロイが反映されない場合がある

Elastic Beanstalkにおけるモニタリング
•  EB CLIでモニタリング
$ eb health -‐‑‒-‐‑‒refresh

•  マネージメントコンソール上でモニタリング

•  マネージメントコンソール上でモニタリング
カスタマイズ可能！

•  マネージメントコンソールでの拡張ヘルスレポート

–  メトリクス
•  EnvironmentHealth
–  OK
–  Warning
–  Degraded
–  Severe
–  Info
–  Pending
–  Unknown
http://docs.aws.amazon.com/ja_̲jp/elasticbeanstalk/latest/dg/health-‐‑‒enhanced-‐‑‒cloudwatch.html#health-‐‑‒
enhanced-‐‑‒cloudwatch-‐‑‒metrics

–  メトリクス: 該当のインスタンスの数を表⽰示
•  InstancesSevere
•  InstancesDegraded
•  InstancesWarning
•  InstancesInfo
•  InstancesOk
•  InstancesPending
•  InstancesUnknown
•  InstancesNoData

–  メトリクス: リクエスト総数および各レスポンスコード毎の数
•  ApplicationRequestsTotal
•  ApplicationRequests5xx

–  メトリクス: xパーセントの完了了にかかった平均時間
•  ApplicationLatencyP10
•  ApplicationLatencyP99.9

–  メトリクス
•  LoadAverage1min: 1分間のLoad値の平均値
•  InstanceHealth: 現在のインスタンスのヘルスステータス
•  RootFilesystemUtil: 使⽤用ディスク容量量の割合

–  メトリクス: 過去1分間のCPU使⽤用状況
•  CPUIrq
•  CPUUser
•  CPUIdle
•  CPUSystem
•  CPUSoftirq
•  CPUIowait
•  CPUNice

時間指定のスケーリング
•  Time-‐‑‒based Scaling
–  時間設定でスケールアウト/インを制御
しょう

Environment間リンク機能
•  SQSのキューを介して疎結合なアーキテクチャを実現
–  Environment Manifest (env.yaml)
しょう
AWSConﬁgurationTemplateVersion: 1.1.0.0
EnvironmentLinks:
"WORKERQUEUE": "worker"

AWS OpsWorks
•  特徴 (http://aws.amazon.com/jp/opsworks/)
–  Chefのレシピを使って、デプロイや運⽤用タス
クを⾃自動化可能
–  ライフサイクルイベントにより動的な構成変
更更への対応が可能
–  継続的な構成管理理
•  価格体系 (http://aws.amazon.com/jp/elasticloadbalancing/pricing/)
–  AWS OpsWorks⾃自体の利利⽤用は無料料
–  （OpsWorksエージェントをオンプレミス
サーバで利利⽤用する場合はその起動時間）
アプリケーションのデプロイ・管理理サービス
AWS OpsWorks
スタック
LBレイヤー
Webレイヤー
DBレイヤー
EC2インスタンス上の
OpsWorksエージェント

AWS OpsWorks
§  アプリケーションのライフサイクル管理理サービス
§  デプロイを頻繁に、早く、セキュアに実⾏行行可能
§  スケーラブルで複雑なインフラストラクチャの構成を管理理、モデル化、
⾃自動化することが可能
§  ビルトイン構成を使って簡単に開始可能
§  追加コストは不不要

OpsWorksインスタンスの構築例例
インスタンス起動
ソフトウェアインストール・構
成⽤用のChefレシピを実⾏行行
アプリケーションのデプロイ⽤用
のChefレシピを実⾏行行
OpsWorksのAPIで
⾃自動化が可能

なぜ、OpsWorksでインスタンス内部のChefレシピをリ
モートからOpsWorks APIで実⾏行行可能か？
OpsWorksインスタンス内で、
OpsWorksエージェントがインストール・動作
しているため

OpsWorksの基本的な仕組み(1)
OpsWorksエージェント
OpsWorks
talks with
OpsWorks エージェントから
OpsWorks エンドポイントに対して
Polling（アウトバウンド通信）

OpsWorksの基本的な仕組み(2)
OpsWorksによって発⾏行行された⼀一連の
コマンドを取得
AgentがChef Clientのローカルモード
でレシピを実⾏行行
OpsWorks Agent
インスタンスにSSH / RDPログインも可能
Chef Server / Chef Clientの構築は不不要
お客様はChefのレシピの作成に集中可能

OpsWorks利利⽤用の流流れ
User AWS Management
Console

Stack
User AWS Management
Console
構成情報
(JSON)
①スタックの作成

Stack
User AWS Management
Console
Load Balancerレイヤー
App Serverレイヤー
Databaseレイヤー
構成情報
(JSON)
②レイヤーの作成

Stack
User AWS Management
Console
レシピ
レシピ
レシピ
構成情報
(JSON)
③レシピの設定（Appの設定）

Stack
User AWS Management
Console
レシピ
レシピ
レシピ
構成情報
(JSON)
④レイヤーに
　インスタンス追加・起動

Stack
User AWS Management
Console
レシピ
レシピ
レシピ
DB
Web
/App
LB
④レイヤーに
　インスタンス追加・起動
⑤ライフサイクルイベントによ
り、レシピが⾃自動実⾏行行される
構成情報
(JSON)
Web
/App

スタックとは
•  OpsWorksのトップエンティティ
•  属する全インスタンスの構成を管理理
–  OSの種類、リージョン、インスタンスのIPアドレスなど
•  カスタムレシピを保存する任意のリポジトリを指定可能
•  VPC内部に作成可能
•  スタックごとに構成情報をJSON形式で保持
–  構成変更更のたびにJSONが更更新される
–  ChefレシピからJSON内の変数を読み込み可能
•  スタックをコピー可能
–  リージョン間でも可能

レイヤーとは
•  インスタンス構築のための⻘青写真（設計図）
レシピを指定して、パッケージインストール
などの必要な処理理を定義
カスタムレシピも定義可能
追加のEBSボリュームの指
定。RAID指定も可能

ビルトインレイヤーの種類
•  Load Balancer
–  HAProxy
(ELBは各レイヤーに個別に
アタッチ可能）
•  App Server
–  Static Web Server
–  Rails App Server
–  PHP App Server
–  Node.js App Server
–  Java App Server
–  AWS Flow (Ruby)
•  DB
–  MySQL
–  RDS
•  ECS(EC2 Container
Service) Cluster
•  Other
–  Memcached
–  Ganglia
–  Custom
ビルトインレイヤー以外にもカスタムレイヤーを使って任意の
役割を持つレイヤーを作成可能（Jenkinsレイヤーなど）
NEW

インスタンスとは
•  アプリケーションを提供するための
EC2インスタンスのこと
•  起動時にインスタンスサイズや
AZ（VPC内の場合はサブネット）
を指定
•  インスタンス内部にOpsWorks
Agentが動作している

インスタンスのスケーリングタイプ
•  インスタンスを（⾃自動）追加起動・終了了する⽅方
法として以下の3パターンがある
–  24/7 インスタンス
•  常時稼働
–  負荷ベースのインスタンス
–  時間ベースのインスタンス

Appとは
•  アプリケーションサーバーにデプロイする
アプリケーションのこと
•  利利⽤用可能なアプリケーションの種類（標準
のアプリケーションサーバーレイヤーに相
当する）
–  Ruby on Rails / PHP / Node.js(JavaScript) /
Static(HTML) / Java / AWS Flow(Ruby) / Other
•  サポートするリポジトリ
–  Git / Subversion / HTTP archive / S3 Archive / Other
–  GithubやBitBucketも使⽤用可能

スタックコマンドを使ってリモートから任意のタイミング
でインスタンスにコマンドを実⾏行行可能
スタックコマンド内容
Install Dependencies 全てのパッケージをインストールする
Update Dependencies 全てのパッケージをアップデートする
Update Custom
Cookbooks
リポジトリにある更更新されたCookbookをそれぞれのインスタンスに展開する
Execute Recipes 指定したレシピを指定したインスタンス上で実⾏行行する
Setup Setupのレシピを実⾏行行する。（Setupを実⾏行行するとDeployもその後で実⾏行行さ
れる）
Conﬁgure Conﬁgureのレシピを実⾏行行する。
AWS Management
Console
管理理者 AWS OpsWorks Instances
Execute Recipes
コマンド等を実⾏行行
OpsWorksエージェ
ントがChefレシピを
実⾏行行

OpsWorksの 5 つのライフサイクルイベント
Setup
Configure
Deploy
Undeploy
Shutdown

OpsWorks
　Auroraの接続先をClusterエンドポイントへ

AWS CloudFormation
•  EC2やELBといったAWSリソースの環境構築を、設定ファイル（テン
プレート）を元に⾃自動化できるサービス
•  テンプレートを⾃自由に作成できるため、⾃自分好みのシステム構成を⾃自
動的に構築できる
•  テンプレートには起動すべきリソースの情報をJSONフォーマットのテ
キスト形式で記述する
テンプレートベースの
プロビジョニング
インフラを
コード化
宣⾔言・柔軟性簡単に利利⽤用可能

スタック
S3
CloudWatch
Elastic Load Balancing
EC2 EC2
Auto Scaling
SNS
テンプレート
Cloud
Formation
テンプレートに基づき
各リソースが起動
AWS CloudFormationのイメージ

AWS CloudFormationがサポートする主なサービス
Ø  Amazon EC2
Ø  Amazon EC2 Container Service
Ø  AWS Lambda (including event sources – New)
Ø  Auto Scaling (including Spot Fleet -‐‑‒ New)
Ø  Amazon VPC
Ø  Elastic Load Balancing
Ø  Amazon Route 53
Ø  Amazon CloudFront
Ø  Amazon RDS
Ø  Amazon Redshift
Ø  Amazon DynamoDB
Ø  Amazon ElastiCache
Ø  Amazon RDS for Aurora (New)
Ø  Amazon S3
Ø  AWS IAM (including managed policies)
Ø  Simple AD (New)
Ø  Amazon Kinesis
Ø  Amazon SNS
Ø  Amazon SQS
Ø  AWS CloudFormation
Ø  AWS CloudTrail
Ø  Amazon CloudWatch
Ø  AWS Data Pipeline
Ø  AWS Elastic Beanstalk
Ø  AWS OpsWorks
Ø  AWS CodeDeploy (New)
Ø  Amazon WorkSpaces (New)
http://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/aws-template-resource-type-ref.html

AWS CloudFormation
テンプレートの例例①
{
"AWSTemplateFormatVersion" : "2010-‐‑‒09-‐‑‒09",
"Resources" : {
"HelloBucket" : {
"Type" : "AWS::S3::Bucket"
}
}
}
HelloBucketというAmazon S3バ
ケットを作るテンプレート

AWS CloudFormation
テンプレートの例例②
{
"Resources" : {
"HelloBucket" : {
"Type" : "AWS::S3::Bucket",
"Properties" : {
"AccessControl" : "PublicRead"
}
}
}
}
　　↓
AccessControlに「PublicRead」
を指定。

AWS CloudFormation
テンプレートの例例③
{
"Resources" : {
"HelloBucket" : {
"Type" : "AWS::S3::Bucket",
"Properties" : {
"AccessControl" : "PublicRead",
"WebsiteConﬁguration" : {
"IndexDocument" : "index.html",
"ErrorDocument" : "error.html"
}
}
}
}
}
　　↓
AccessControlに「PublicRead」
を指定。
　　↓
Webサイトとして公開するために、
index.htmlと、ErrorDocumentの
設定を⾏行行う。

では、どういう時に何を使えば良良いの？？

"Lean Startupメソッドにおいて鍵となるのは、適切切な機能を持った適切切なプロ
ダクトを、build-‐‑‒measure-‐‑‒learnフィードバックループと共にイテレーティブ
なプロセスで開発し続けることで、このプロセスの中⼼心はminimum viable
product(MVP)である"
"限られた機能しかもたいなプロダクトでも、それをShipすることで、アーリーア
ダプターの元に届き、少なくとも何⼈人かのユーザーからは共鳴を受け、ユーザー
はお⾦金金を払い、ユーザーからのフィードバックを受け取れるようになる"
⾃自動化＋素早いデリバリ！

•  パイプラインの⾃自動化

•  パイプラインの⾃自動化
–  Githubにコミットされたらパイプラインをキック
–  Jenkinsを使ってビルド
–  Staging環境にデプロイしてUAT、Stressテスト
–  Production環境へRolling Deploy

開発のスタイルにあったワークフローを⾃自由に
例例えば
ソースコード
ビルド
ユニット
テスト
ステージ
デプロイ
本番
デプロイ
A機能画⾯面
テスト
CodePipeline
ステージ
デプロイ
B機能画⾯面
テスト

開発のスタイルにあったワークフローを⾃自由に

AWS CodePipeline パートナー連携

Custom Action
開発者が
コミット
CodePipeline S3
カスタムアクションリソース
カスタムジョブワーカーカスタムビルドアクション
1. エージェントでポーリング
2. ジョブの詳細
4. ビルドの実⾏行行
3. ジョブのAck
5. ジョブの成功

AWS CodePipeline
•  Source -‐‑‒> Build -‐‑‒> Load Testing

AWS CodePipeline
•  Load Testing w/ Apica

AWS CodePipelineとの連携
•  Elastic Beanstalk
–  ビルトインサポート
–  プロビジョニングも含めてお任せ
•  CodeDeploy
–  ビルトインサポート
–  プロビジョニングは⾃自分で
•  OpsWorks
–  EBのスタックに合わない場合など
–  ビルトインサポート無いのでcustom action

Application Deployment on AWS

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (6)

Similaire à Application Deployment on AWS

Similaire à Application Deployment on AWS (20)

Plus de Eiji Shinohara

Plus de Eiji Shinohara (20)

Dernier

Dernier (9)

Application Deployment on AWS