Presentation Title Hered0.awsstatic.com/.../jp/pdf/services/20151111_aws-blackbelt-opswor… · OpsWorksの基本的な仕組み(2) 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



構成情報(JSON)

①スタックの作成

16

Stack



Load Balancerレイヤー

App Serverレイヤー

Databaseレイヤー

構成情報(JSON)


②レイヤーの作成

17

Stack






レシピ

レシピ

レシピ

構成情報(JSON)



③レシピの設定（Appの設定）

18

Stack






レシピ

レシピ

レシピ

構成情報(JSON)




④レイヤーにインスタンス追加・起動

19

Stack






レシピ

レシピ

レシピ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内の場合はサブネット）を指定

• インスタンス内部にOpsWorksAgentが動作している

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,

"rails_env": 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

サーバー


38

インスタンスがonlineになるとConfigureが自動実行される


App

サーバー


39

データベースインスタンスの追加


App

サーバー

DB

サーバー


40

Setup, Deployが自動実行される


App

サーバー

DB

サーバー

DBサーバーの起動


41

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


App

サーバー

DB

サーバー



42

さらにインスタンスを追加


App

サーバー

DB

サーバー

App

サーバー



43

Setup、Deployが自動実行される


App

サーバー

DB

サーバー

App

サーバー




44

インスタンスがonlineになるとスタック内の全インスタンスでconfigureが自動実行される


App

サーバー

DB

サーバー

App

サーバー




45

手動でデプロイを実行


App

サーバー

DB

サーバー

App

サーバー





46

レシピを手動で実行


App

サーバー

DB

サーバー

App

サーバー





レシピ単体を実行

47

インスタンスを停止


App

サーバー

DB

サーバー

App

サーバー






Appサーバーのシャットダウン

48

インスタンスがonlineでなくなると、Configureが自動実行される


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

RepositoryApp 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スタック

AmazonLinux

Ubuntu RHEL 7

WindowsServer

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など

のライフサイクルイベントに、登録することで自動実行させることが可能

http://aws.typepad.com/sajp/2014/05/opsworks-custom-recipe.html

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

https://docs.chef.io/chef/resources.html#powershell-script

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の指定は未対応

https://s3.amazonaws.com/cloudformation-templates-us-east-1/OpsWorks.template

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/

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

http://www.slideshare.net/s2-nakano/lets-join-in-opsworks-world

https://speakerdeck.com/koid/yokuwakaru-aws-opsworks

http://www.slideshare.net/mayuhamazaki90/20150326-opsworkspublic-fix

http://www.slideshare.net/tetsuyachiba/20150326-aws-opsworks

http://www.slideshare.net/fumihikoshiroyama/ops-works

http://www.slideshare.net/matsukaz/brain-warsopsworks

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/aws-opsworks

http://www.slideshare.net/AmazonWebServicesJapan/aws-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

http://docs.aws.amazon.com/ja_jp/opsworks/latest/userguide/welcome.html

https://d0.awsstatic.com/whitepapers/managing-multi-tiered-web-applications-with-opsworks.pdf

https://blogs.aws.amazon.com/application-management

http://www.slideshare.net/AmazonWebServices/dvo301-aws-opsworks-under-the-hood

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/

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/

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/

http://aws.amazon.com/jp/about-aws/events/

100

Webinar資料の配置場所

• AWS クラウドサービス活用資料集– http://aws.amazon.com/jp/aws-jp-introduction/

http://aws.amazon.com/jp/aws-jp-introduction/

101

公式Twitter/FacebookAWSの最新情報をお届けします

@awscloud_jp

検索

最新技術情報、イベント情報、お役立ち情報、お得なキャンペーン情報などを日々更新しています！

もしくはhttp://on.fb.me/1vR8yWm

102

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

Documents

Presentation Title Hered0.awsstatic.com/.../jp/pdf/services/20151111_aws-blackbelt-opswor… · OpsWorksの基本的な仕組み(2) OpsWorksによって発行された一連の コマンドを取得

Presentation Title Hered0.awsstatic.com/.../jp/pdf/services/20151111_aws-blackbelt-opswor… · OpsWorksの基本的な仕組み(2) OpsWorksによって発行された一連のコマンドを取得