AWS Black Belt Tech シリーズ 2015 - AWS OpsWorks

1
AWS OpsWorks
AWS Black Belt Tech Webinar 2015
アマゾンウェブサービスジャパン株式会社
ソリューションアーキテクト舟﨑健治
2015/11/11

2
Agenda
• Introduction
• AWS OpsWorks概要のおさらい
• AWS OpsWorksアップデート
• AWS OpsWorks Tips
• お客様の事例
• まとめ

3
Agenda
• Introduction
• まとめ

4
Introduction
• アプリケーションは複数のレイヤーで構成され
ることが多い。
レイヤー使用例
プレゼンテーションフロントエンドWebサーバ
ビジネスロジックアプリケーションサーバ
ワーカーバックグラウンドのタスクを実行
データバックエンドデータストア
インテグレーションメッセージングキュー

5
Micro-Servicesアーキテクチャ
• 小さなサービスの集合で１つのアプリケーションを形成
• サービス間はインタフェースを使ってコミュニケートする
• それぞれのMicro-Serviceは、異なるフレームワーク、プログラ
ミング言語で開発可能 UI
Micro
Service
DB
Micro
Service
DB
Micro
Service
DB
Micro
Service
AWS OpsWorksでは、
それぞれのMicro-
Serviceを「レイヤー」
で定義可能

6
Agenda
• Introduction
• まとめ

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

8
AWS OpsWorksを使うメリット
自動化できる領域が多くなる
デプロイ自動化運用タスクの自動化
運用負荷を軽減できる

9
EC2インスタンスの構築例
インスタンス起動
ソフトウェアインストール・構
成用のスクリプトを実行
アプリケーションのデプロイ
EC2のAPIで自動化が可能
ユーザー側でインスタンス内部
で起動スクリプト等を使って、
自動化が可能

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

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

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

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

14
OpsWorks利用の流れ
User AWS Management
Console

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

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

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

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

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

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

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

22
ビルトインレイヤーの種類
• 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

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

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

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

26
OpsWorksで実行可能なコマンド
 以下の2種類がある
 スタックコマンド
 スタック全体の構成を変更・管理するためのコマンド
 AWSマネージメントコンソール、AWS SDK、AWS CLIでリモートから実
行可能
 エージェントコマンド
 デバッグやトラブルシューティングのために利用するコマンド
 それ以外の用途の場合は、スタックコマンドの利用を推奨
 インスタンス内部にログインして実行可能。
 sudoもしくはroot権限が必要
重要！

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

28
スタックコマンドでUpdate Custom Cookbooksを実行
• アップデートされたカスタムChef cookbooksをコード
リポジトリから指定したインスタンスに展開する
• コマンド実行時のログを確認可能
Update Custom
Cookbooksを選択
ログを確認

29
スタックコマンドでExecute Recipesを実行
• Update Custom Cookbooksを実行後に、Cookbookお
よびレシピ名を指定してレシピ単体を実行する
• コマンドのログを確認可能
Execute Recipesを
選択
Cookbook名::レシピ
名を指定
ログを確認

30
インスタンス内部でOpsWorks Agent CLIを実行
• OpsWorksで起動されたインスタンスにSSHでログイン
して、Agent CLIコマンドを実行可能。
– レシピの実行
– Chefログの表示
– スタックの構成JSONおよびデプロイメントJSONの表示

31
インスタンス内部でOpsWorks Agent CLIによる
レシピ再実行
• Agent CLIのrun_commandは、最近スタックコマンドによって実
行されたことがあるコマンドのみ再実行が可能。手順は以下。
– １．最近実行されたコマンド（のキャッシュ）を表示する
– ２．表示されたコマンドの中に、実行したいコマンドがあれば同じコマン
ドを実行可能
$ sudo opsworks-agent-cli list_commands
2014-04-07T02:55:09 setup
2014-04-07T02:58:55 configure
2014-04-07T04:38:12 execute_recipes
$ sudo opsworks-agent-cli run_command execute_recipes hello
インスタンス内部のキャッシュにあるレシピを実行する。コードリポジトリにあるレシピ
をアップデートしただけでは、最新のレシピを自動でダウンロードはしない。インスタン
ス起動後に最新のレシピをダウンロードするにはスタックコマンドでUpdate Custom
Cookbooksを実行する必要がある。

32
インスタンス内部でOpsWorks Agent CLIによる
スタック構成JSONの表示
• インスタンス内部で以下のコマンドを実行
• スタック構成およびデプロイメントJSONを取得する
sudo opsworks-agent-cli get_json
{
"deploy": {
"hello": {
"deploy_to": "/srv/www/hello",
"application": "hello",
"deploying_user": "arn:aws:iam::111111111111:root",
"domains": [
"hello"
],
"application_type": "php",
"mounted_at": null,
カスタムChefレシピ作成時に、JSONから
パラメータを取得するときの参考として活用
可能

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

34
どのタイミングで
ライフサイクルイベントが
実行されるか？

35
最初のインスタンスを追加
App
サーバー
Setup Deploy Configure Execute Recipe Shutdown

36
最初のインスタンスを起動すると、Setupが
自動実行されるAppサーバー
の起動
App
サーバー

37
Setupが実行された後にDeployが自動実行
されるAppサーバー
の起動
App
サーバー

38
インスタンスがonlineになるとConfigure
が自動実行されるAppサーバー
の起動
App
サーバー

39
データベースインスタンスの追加
Appサーバー
の起動
App
サーバー
DB
サーバー

40
Setup, Deployが自動実行される
Appサーバー
の起動
App
サーバー
DB
サーバー
DBサーバー
の起動

41
DBサーバーがonlineになるとスタック内の全イン
スタンスでConfigureが自動実行される
Appサーバー
の起動
App
サーバー
DB
サーバー
DBサーバー
の起動

42
さらにインスタンスを追加
Appサーバー
の起動
App
サーバー
DB
サーバー
App
サーバー
DBサーバー
の起動

43
Setup、Deployが自動実行される
Appサーバー
の起動
App
サーバー
DB
サーバー
App
サーバー
DBサーバー
の起動
Appサーバー
の起動

44
インスタンスがonlineになるとスタック内の全イ
ンスタンスでconfigureが自動実行される
Appサーバー
の起動
App
サーバー
DB
サーバー
App
サーバー
DBサーバー
の起動
Appサーバー
の起動

45
手動でデプロイを実行
Appサーバー
の起動
App
サーバー
DB
サーバー
App
サーバー
DBサーバー
の起動
Appサーバー
の起動
手動で
デプロイを
実行

46
レシピを手動で実行
Appサーバー
の起動
App
サーバー
DB
サーバー
App
サーバー
DBサーバー
の起動
Appサーバー
の起動
手動で
デプロイを
実行
レシピ単体を
実行

47
インスタンスを停止
Appサーバー
の起動
App
サーバー
DB
サーバー
App
サーバー
DBサーバー
の起動
Appサーバー
の起動
手動で
デプロイを
実行
レシピ単体を
実行
Appサーバーの
シャットダウン

48
インスタンスがonlineでなくなると、Configure
が自動実行される
Appサーバー
の起動
App
サーバー
DB
サーバー
App
サーバー
DBサーバー
の起動
Appサーバー
の起動
手動で
デプロイを
実行
レシピ単体を
実行
Appサーバーの
シャットダウン

49
ライフサイクルイベントに登録するレシピの
例（レイヤー別）
Setup Configure Deploy Undeploy Shutdown
ロードバラン
サーレイヤー
ロードバラン
サーをインス
トール
アプリケーション
サーバーのIPを
アップデート
コネクションを
Drainする
アプリケーショ
ンサーバーレ
イヤー
アプリケー
ションサー
バーをインス
トール
DB接続先をアッ
プデートしてリス
タート
コードをアップ
デートしてリス
タート
アプリケー
ションを削除
してリスタート
ログを保存
データベース
レイヤー
データベー
スをインス
トール
サーバーのIPの
ACLをアップデー
ト
スナップショット
の作成

50
Elastic Load Balancer
レイヤー
VPC内に構築する例
Virtual Private Cloud
VPC Public Subnet
VPC Private Subnet
Internet
Gateway
NAT
PHP App Server
レイヤー
MySQL DB レイヤー Github
Recipe
Repository
App Code
Repository
• OpsWorksにより起動された
インスタンスはOpsWorks
サービスエンドポイントと接
続が必須
（Privateサブネット利用時は
NAT必須）
• プライベートサブネット内の
コードリポジトリを利用可能

51
Agenda
• Introduction
• まとめ

52
サポートされるオペレーティングシステム
• Amazon Linux
• Ubuntu 12.04 LTS
• Ubuntu 14.04 LTS
• Red Hat Enterprise Linux 7
• Windows Server 2012 R2
NEW
NEW

53
Amazon Linux
• AWSによって提供、サポート、管理されるLinux
– EC2内でのみ利用可能
• 多数のAWS APIツールやCloudInitがインストール済み
• 64ビットバージョンのAmazon Linuxをサポート
• 約6か月おきに新しいバージョンをリリース
• カスタムAMIを利用可能

54
Ubuntu
• 約2年ごとに新しいUbuntu LTSがリリース
• 各リリースは約5年間サポートされる
• OpsWorksでは64ビットバージョンのUbuntu 12.04 LTSおよ
び14.04 LTSをサポート
• カスタムAMIを利用可能
• 既存のUbuntu 12.04インスタンスを14.04インスタンスへ更
新することは不可
– 新しいUbuntu 14.04インスタンスを作成する必要あり

55
Redhat Enterprise Linux 7 (RHEL 7)
• 64ビットバージョンをサポート
• 最初にサポートされるマイナーバージョンはRHEL 7.1
• Red Hatは約9か月おきにマイナーバージョンをリリース
• 新しいインスタンスを作成すると、OpsWorksは現在のRHEL 7
のバージョンが使用される
• 新しいマイナーバージョンがリリースされても、OpsWorksが既
存の起動中のインスタンスを自動的に更新することはない
NEW

56
Linuxのバージョンアップグレードについて
• Amazon Linux / Red Hat Enterprise Linux 7でアップグレー
ドが可能
• オンラインインスタンスの場合
– インスタンスを指定して、Upgrade Operating Systemスタックコマンドを実行
• オフラインのEBS backedインスタンスの場合
– インスタンスを起動して、Upgrade Operating Systemスタックコマンドを実行
• 時間ベース、負荷ベースのインスタンスを含めた、オフラインの
Instance Store backedインスタンスの場合
– インスタンスのOperating Systemの設定を編集、その後インスタンス再起動時に新
しいバージョンに更新される

57
Windows Server
• 以下の64ビットバージョンをサポート
– Microsoft Windows Server 2012 R2(Standard)
– Microsoft Windows Server 2012 R2およびSQL Server Express
– Microsoft Windows Server 2012 R2およびSQL Server Standard
– Microsoft Windows Server 2012 R2およびSQL Server Web
• Windows PowerShellスクリプトをChefレシピから実
行可能
• カスタムAMIを使用可能
• Linuxインスタンス同様に使用可能だが、いくつか注意
事項がある。
NEW

58
Windows Serverの注意事項
• Windows Stackの場合、Chef 12.2を利用
• OpsWorksの外部で作成されたWindowsインス
タンスをStackへ登録することは不可
• Berkshelfは利用不可
• カスタムレイヤーを利用する
– 組み込み（ビルトイン）レイヤーは未サポート
• EBS-backedルートボリュームを利用

59
オンプレミスインスタンスのサポート
• オンプレミスの物理サーバおよび仮想サーバをOpsWorksスタッ
クに追加可能
• Linuxスタックのみサポート
– オンプレミスのUbuntu, Red Hat Enterprise Linux 7を利用可能
• 通常のAWS OpsWorksインスタンス同様に管理が可能
– レイヤーへの追加が可能
• オンプレミスインスタンスからOpsWorksサービスに対してアウ
トバウンド通信が許可されている必要がある
– OpsWorksサービスへの通信はインターネット経由でのアクセスとなるため、イン
ターネットへアウトバウンド通信を許可する
NEW

60
オンプレミスインスタンスをOpsWorksスタックに追
加する方法
• １．インスタンスの準備
• ２．AWS CLIのインストールおよび設定
• ３．aws opsworks registerコマンドを実行
※registerコマンドの実行は以下2通りの方法がある

61
aws opsworks registerコマンド
• スタックに追加するインスタンス内でAWS CLIを実行す
る場合
• 別のリモートワークステーションでAWS CLIを実行する
場合
aws opsworks register --infrastructure-class on-premises
--region ap-northeast-1 --stack-id <stack-id> --local
aws opsworks register --infrastructure-class on-premises
--region ap-northeast-1 --stack-id <stack-id>
--ssh-username [username] --ssh-private-key [key-path] [host-address]

62
既存のAmazon EC2インスタンスのスタックへ追加
• オンプレミスインスタンス同様にOpsWorksス
タックの外部にあるAmazon EC2インスタンス
をスタックへ追加・管理が可能
– 以下は追加するEC2インスタンス内でAWS CLIを実行する例
NEW
aws opsworks register --infrastructure-class ec2
--region ap-northeast-1 --stack-id <stack-id> --local

63
OpsWorks管理下でさまざまなオペレーティングシス
テムを混在させた構成の例
virtual private cloud オンプレミス
OpsWorks Linuxスタック
OpsWorks Windowsスタック
Amazon
Linux
Ubuntu RHEL 7
Windows
Server
Ubuntu RHEL 7
※１つのスタック内にLinuxと
Windowsの混在は不可
OpsWorks
VPNまたは
専用線

64
Amazon ECS(EC2 Container Service)レイヤーの
サポート
• Chef 11.10スタックで利用可能
• ECSレイヤーのインスタンスはAmazon Linux 2015.03以
降あるいはUbuntu 14.04 LTSで利用可能
• OpsWorksはECSクラスタのコンテナインスタンスの起動
と管理を簡素化する
– ECSタスクのようなECSの他のエンティティを作成・起動するには、ECSのマ
ネージメントコンソール、API、またはCLIを利用する必要がある。
• Elastic Load BalancingをECSレイヤーにアタッチ可能
NEW

65
Chefのバージョン
• Chef 11.4
– 2013年3月に導入
– Linuxスタックでのみ利用可能
– Ruby 1.8.7
– Chef-soloを利用
– Chef searchやData Bagsは未サポート
• Chef 0.9
– サポートが終了されているため、非推奨
– Linuxスタックでのみサポート
• Chef 12.2
– 2015年５月に導入
– Windowsスタックでのみサポート
– Ruby 2.0.0で動作
– Chef Clientのローカルモードで動作
– Chef searchやData Bagsを利用可能
• Chef 11.10
– 2014年3月に導入
– Linuxスタックでのみサポート
– Ruby 2.0.0で動作
– Chef Clientのローカルモードで動作
– Chef searchやData Bagsを利用可能
NEW

66
OpsWorksエージェントのバージョン指定
• 新しいバージョンが使用可能になったときに、自動
的に更新するか、手動で更新するかを指定可能
– デフォルトでは自動更新
• Chef 11.10スタックでのみ使用可能
• スタックごと、およびインスタンスごとに設定可能
NEW

67
Agenda
• Introduction
• まとめ

68
OpsWorksでカスタムChefレシピを実行する方法
1. コードリポジトリを用意（GitHubなど）
2. コードリポジトリに作成したCookbookおよびレシピをpush
3. スタックを作成
カスタムCookbookの利用をYesにして、該当するコードリポジトリを設定
4. レイヤーを作成
5. レイヤーにインスタンスを追加、起動
6. インスタンスがonlineになったことを確認
7. スタックコマンドでUpdate Custom Cookbooksを実行
8. スタックコマンドでExecute Recipesにより指定したレシピをインスタンスに実行させる。
参照：AWS OpsWorksでカスタムChefレシピを実行する方法
http://aws.typepad.com/sajp/2014/05/opsworks-custom-recipe.html
動作確認ができたレシピを
Setup,Deploy,Configureなど
のライフサイクルイベントに、
登録することで自動実行させ
ることが可能

69
Windows PowerShellスクリプトの実行
• Chefのpowershell_scriptリソースによって
Windows PowershellコマンドレットをOpsWorks
インスタンスで実行可能
– https://docs.chef.io/chef/resources.html#powershell-script
Chef::Log.info("******Installing XPS.******")
powershell_script "Install XPS Viewer" do
code <<-EOH
Install-WindowsFeature XPS-Viewer
EOH
guard_interpreter :powershell_script
not_if "(Get-WindowsFeature -Name XPS-Viewer).installed"
end

70
Chef Search
• Chefのsearchメソッドを使って、以下に含まれるス
タックの構成情報をレシピ内で検索することが可能
– スタック構成およびデプロイメントJSON
– ビルトインおよびカスタムのcookbookのattributeファイル
• 多くの場合は、コミュニティのレシピで使われている
searchをそのまま使用可能
– ただし、Chefサーバーに対して検索をするのではなく、インスタンスの内
部にある上記構成情報のキャッシュデータに対して検索する。
– こちらのキャッシュデータは、OpsWorksのライフサイクルイベントによ
り更新される
• Chef 11.10のスタックで使用可能

71
Chef Searchの使用例
• 以下はレシピ内で、php-appサーバーレイヤー
に属するインスタンスを検索している例
– searchの引数でレイヤーを指定するときには、layerではなく
roleを指定する
appserver = search(:node, "role:php-app").first
Chef::Log.info("The private IP is '#{appserver[:private_ip]}'")

72
Data Bags
• Chefのdata_bag_itemメソッド使って、data bagにあ
る情報を検索可能
• Chefのレシピには作業内容を書くのに対して、設定情
報をData Bagsに入れる。
– Data Bagsの設定を書き換えるだけで
レシピの使い回しが可能
• 使い方
– １．カスタムJSONにdata_bagsの
情報を追加する
– ２．以下のようにレシピ内で検索する
{ "opsworks": {
"data_bags": {
"myapp": {
"mysql": {
"username": "default-user",
"password": "default-pass"
}
}
}
}
}
mything = data_bag_item("myapp", "mysql")
Chef::Log.info("The username is '#{mything['username']}' ")
カスタムJSONへの追加例

73
Berkshelfのサポート
• Berkshelfとはcookbookとその依存関係を管理して
くれるもの
• Berkshelfを使うことで、複数の異なるリポジトリ
にあるcookbooksを使用可能
• Chef 11.10のスタックでのみ使用可能
• サポートされるBerkshelfのバージョンはオペレー
ティングシステムによって異なる

74
Berkshelfの使用方法
• １．スタックの設定で、カスタムcookbooksの利用が可能である
ことを確認して、Berkshelfの設定を有効にする
• ２．スタックの設定で指定したカスタムcookbooksのリポジトリ
の最上位ディレクトリにBerkfileという名前のファイルを配置。
その中身の例は以下
• ３．スタックのコマンドでUpdate Custom Cookbooksを実行
– インスタンス内の/opt/aws/opsworks/current/berkshelf-cookbooksに、該当する
cookbookが配置される。
• ４．スタックのコマンドでExecute Recipesでレシピ実行
site :opscode
cookbook 'ark', git: 'git://github.com/opscode-cookbooks/ark.git'

75
Chefレシピのデバッグに有効な手法
Execute Recipes
スタックコマンドを実行
OpsWorksマネージメントコンソール、API、CLIでリ
モートからChefレシピを実行可能
インスタンスへログイン SSHキーペアを割り当てている場合は、Linux /
Windowsともにログイン可能
Chefログ OpsWorksマネージメントコンソール、API、CLIで
Chefログを表示可能
AWS OpsWorksエー
ジェントCLIの使用
run_commandを使って、以前実行したコマンドを再
実行可能

76
データベースとの接続
• スタックごとにカスタムJSONを設定可能
• カスタムJSONにデータベースとの接続情報を入れることで、
Chefレシピからその情報を取得可能
"deploy": {
“appname": {
（途中省略）
"database": {
"host": “xxx.ap-northeast-1.rds.amazonaws.com",
"database": "test",
"port": 3306,
"username": "awsuser",
"password": "mypassword",
"reconnect": true,
"data_source_provider": "rds",
"type": "mysql"
},
（以下省略）
dbname = node[:deploy][:appname][:database][:database]
dbuser = node[:deploy][:appname][:database][:username]
dbpass = node[:deploy][:appname][:database][:password]
dbhost = node[:deploy][:appname][:database][:host]
Chefレシピから取得する例
取得した値をApp Serverインスタンスのローカル
にDB接続用の設定ファイルとして保持しておく。
configureが実行されるたびに上記値を更新する

77
AWS OpsWorksの環境変数
• それぞれのアプリケーションごとに20個の環境変
数を定義可能
• アプリケーションサーバインスタンスのセット
アップ時に渡される
• パスワードなどをProtected valueとして、コン
ソール上で値を非表示にすることが可能

78
同じ役割のレイヤーを複数個作る
• カスタムレイヤーを作成して、同じレシピ
を登録することで同じ役割のレイヤーを作
成可能
• RDSやELBのレイヤーを複数個追加する場
合は事前にRDSやELBを複数個作成する必
要あり
• どのAppが、どのRDSを使うかを指定可能

79
カスタムAMIの利用
• カスタムAMIの利用目的の例
– ブート時ではなく、事前に特定のパッケージをインストールしておき
たい。
– インスタンスの起動時間を高速化したい（特に負荷ベースのインスタ
ンスの場合）
• 以下のOSをベースのものに対応
– Amazon Linux
– Ubuntu 12.04 LTS, or Ubuntu 14.04 LTS
– Redhat Enterprise Linux 7
– Windows Server 2012

80
カスタムAMIの作成方法
• １．レイヤーにインスタンスを追加
• ２．インスタンスを起動してSSHでログイン、以下の処理を行う
※OpsWorksで起動したインスタンスはユニークなIDの情報を含んでいるため、ID
が重複しないように、AMI保存する前に上記作業により削除しておく必要がある。
• ３．EBSベースのインスタンスの場合は停止してAMI作成（EC2の管理
コンソール画面を使用）、インスタンスストアベースの場合は、停止せ
ずにAMI作成
sudo /etc/init.d/monit stop
sudo /etc/init.d/opsworks-agent stop
sudo rm -rf /etc/aws/opsworks/ /opt/aws/opsworks/ /var/log/aws/opsworks/
/var/lib/aws/opsworks/ /etc/monit.d/opsworks-agent.monitrc
/etc/monit/conf.d/opsworks-agent.monitrc /var/lib/cloud/

81
CloudFormationを使ったOpsWorksリソースの自動
作成
• CloudFormationテンプレート(JSON)を使ってOpsWorksの以下の
リソースを自動作成可能
– AWS::OpsWorks::Stack
– AWS::OpsWorks::Layer
– AWS::OpsWorks::Instance
– AWS::OpsWorks::App
– AWS::OpsWorks::ElasticLoadBalancerAttachment
• 構成サンプル：OpsWorks PHPアプリケーションをプロビジョニン
グする
– https://s3.amazonaws.com/cloudformation-templates-us-east-
1/OpsWorks.template
※CloudFormationテンプレートでは、時間ベースおよび負荷ベースのScaling Typeの指定は
未対応

82
監視
• Amazon CloudWatchを使った13種のカスタム
メトリクス
• AWS CloudTrailを使ったAWS OpsWorksのAPI
呼び出しのログへの記録
• Amazon CloudWatch Logsを使ったStackのシ
ステム、アプリケーション、およびカスタムロ
グ

83
Amazon CloudWatchカスタムメトリクスの例

84
OpsWorksのユーザーアクセス管理
• 以下の2通りの方法で実現可能
– OpsWorksのPermissionsページの機能（あるいはそれ相応の
API, CLI)を使う方法
– 適切なIAMアクセスポリシーを使う方法
• 両方を組み合わせて利用可能

85
OpsWorksのPermissionsを使ったアクセス権限の設定

86
OpsWorksのトラブルシューティング
• インスタンスが起動中のプロセスでスタックす
る（オンラインにならない）
• カスタムCookbookが更新されない
• インスタンスが予期せずに再起動する

87
インスタンスが起動中のプロセスでスタックする
（オンラインにならない）
• 問題
– OpsWorksで起動したインスタンスが、bootingのステータスのまま変わらない
• 原因
– インスタンスは、常にAWS OpsWorksサービス、Amazon S3、およびパッケー
ジ、Cookbook、アプリケーションのリポジトリと通信ができる必要がある。こ
れらと通信ができないためにbootingステータスから先に進むことができない
• 解決方法
– 上記通信ができるようにVPCを設定する。
（Public IPでインスタンスが通信することを許可する場合は、OpsWorksレイ
ヤーのネットワーク設定でPublic IPをアサインを有効に設定後にそのレイヤーの
インスタンスを起動する）

88
カスタムCookbookが更新されない
• 問題
– リポジトリ上のカスタムCookbookを更新したが、インスタンスは古いレ
シピを実行している
• 原因
– OpsWorksでは各インスタンスはローカルにCookbookをキャッシュし、
キャッシュからレシピを実行する。自動的にキャッシュを更新はしない。
• 解決方法
– Update Custom Cookbooksスタックコマンドを実行する
AWS Management
Console
管理者 AWS OpsWorks
Update Custom
Cookbooksコマンド
を実行
インスタンス

89
インスタンスが予期せずに再起動する（１）
• 問題
– 停止されたインスタンスが予期せずに再起動する
• 原因
– インスタンスの自動ヒーリングを有効にしていると、異常なインス
タンスを再起動する。EC2コンソールやEC2のAPI, CLIを使ってイ
ンスタンスを停止すると、OpsWorksにはそれが通知されない。そ
のため、そのインスタンスをOpsWorksは異常とみなし再起動する
• 解決方法
– OpsWorksのコンソール、API、CLIを使ってのみインスタンスを
管理することを推奨
（自動ヒーリングを無効化も可能）

90
Agenda
• Introduction
• まとめ

91
バンダイナムコスタジオ様の事例
• 「ドリフトスピリッツプ
ロジェクト」にてAWS
OpsWorksを活用
• AWS OpsWorksを使っ
て、開発環境・本番環境
のサーバの構築・運用を
自動化することで、運用
コストを削減
詳細： https://aws.amazon.com/jp/solutions/case-studies/bns/

92
2015/3/26 よくわかるAWS OpsWorksセミナーに
ご登壇頂いたユーザー様の資料リンク
• バンダイナムコスタジオ様「Let’s join in OpsWorks world」
– http://www.slideshare.net/s2-nakano/lets-join-in-opsworks-world
• Gunosy様「GunosyのMicroServicesとOpsWorks」
– https://speakerdeck.com/koid/yokuwakaru-aws-opsworks
• バスキュール様 / スタジオ・アルカナ様「テレビ連動システムを支える
OpsWorks」
– http://www.slideshare.net/mayuhamazaki90/20150326-opsworkspublic-fix
• サーバーワークス様：「SimpleWorkflowとOpsWorksでサービスを構築
して解ったこと」
– http://www.slideshare.net/tetsuyachiba/20150326-aws-opsworks
• マナボ様「OpsWorksに今後期待するところ」
– http://www.slideshare.net/fumihikoshiroyama/ops-works
• BrainWars様「BrainWarsのOpsWorks活用事例」
– http://www.slideshare.net/matsukaz/brain-warsopsworks
AWS SAブログ：「よくわかるAWS OpsWorks」セミナー資料公開
http://aws.typepad.com/sajp/2015/04/opsworks-seminar-material.html

93
Agenda
• Introduction
• まとめ

94
まとめ
• AWS OpsWorksを使うことで、デプロイおよび
運用タスクを自動化可能
• Windows Server, Redhat Enterprise Linux,
オンプレミスインスタンス、Amazon ECS等で
も動作が可能となり、さらに利用シーンが拡大
AWS OpsWorksを使った新しいDevOpsソリューションを
是非お試しください！

95
AWS OpsWorksのハンズオン資料が公開されています
• OpsWorksを使ってWordpressを構築するハン
ズオンを是非お試しください！
– http://www.slideshare.net/AmazonWebServicesJapan/aw
s-opsworks

96
参考資料
• AWS OpsWorksユーザーガイド
– http://docs.aws.amazon.com/ja_jp/opsworks/latest/userguide/welcome.html
• OpsWorksによる多階層アプリケーションの管理
– https://d0.awsstatic.com/whitepapers/managing-multi-tiered-web-applications-with-opsworks.pdf
• Application Management Blog
– https://blogs.aws.amazon.com/application-management
• AWS reInvent 2015: OpsWorks Under The Hood
– http://www.slideshare.net/AmazonWebServices/dvo301-aws-opsworks-under-the-hood
• AWS reinvent 2015: Benefit from DevOps when moving to AWS
for Windows
– http://www.slideshare.net/AmazonWebServices/dvo310-benefit-from-devops-when-moving-to-aws-for-
windows

97
Q&A
次回Webinarのお申し込み
http://aws.amazon.com/jp/event_schedule/

98
AWS Black Belt Tech Webinar 2015
AWSのサービスをディープにご紹介
• 今後の配信予定デプロイ&プロビジョニング月間!
– 11月18日(水)18:00〜 AWS CloudFormation
– 11月25日(水)18:00〜 AWS Elastic Beanstalk
• 申し込みサイト
– http://aws.amazon.com/jp/about-aws/events/

99
AWS初心者向けWebinar
• AWSをこれからご使用になる向けのソリュー
ションカットのオンラインセミナー
– 11/17(火) AWSを活用したモバイルアプリの開発と運用
– 11/24(火) AWSではじめてみよう、IoTシステム構築
• 申し込みサイト
– http://aws.amazon.com/jp/about-aws/events/

100
Webinar資料の配置場所
• AWS クラウドサービス活用資料集
– http://aws.amazon.com/jp/aws-jp-introduction/

101
公式Twitter/Facebook
AWSの最新情報をお届けします
@awscloud_jp
検索
最新技術情報、イベント情報、お役立ち情報、お得なキャンペーン情報などを
日々更新しています！
もしくは
http://on.fb.me/1vR8yWm

102
ご参加ありがとうございました。

AWS Black Belt Tech シリーズ 2015 - AWS OpsWorks

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to AWS Black Belt Tech シリーズ 2015 - AWS OpsWorks

Similar to AWS Black Belt Tech シリーズ 2015 - AWS OpsWorks (20)

More from Amazon Web Services Japan

More from Amazon Web Services Japan (20)

Recently uploaded

Recently uploaded (10)

AWS Black Belt Tech シリーズ 2015 - AWS OpsWorks