View
6.724
Download
5
Category
Preview:
Citation preview
2
Agenda
• Introduction
• AWS OpsWorks概要のおさらい
• AWS OpsWorksアップデート
• AWS OpsWorks Tips
• お客様の事例
• まとめ
3
Agenda
• Introduction
• AWS OpsWorks概要のおさらい
• AWS OpsWorksアップデート
• AWS OpsWorks Tips
• お客様の事例
• まとめ
4
Introduction
• アプリケーションは複数のレイヤーで構成されることが多い。
レイヤー 使用例
プレゼンテーション フロントエンドWebサーバ
ビジネスロジック アプリケーションサーバ
ワーカー バックグラウンドのタスクを実行
データ バックエンドデータストア
インテグレーション メッセージングキュー
5
Micro-Servicesアーキテクチャ
• 小さなサービスの集合で1つのアプリケーションを形成• サービス間はインタフェースを使ってコミュニケートする• それぞれのMicro-Serviceは、異なるフレームワーク、プログラ
ミング言語で開発可能 UI
Micro
Service
DB
Micro
Service
DB
Micro
Service
DB
Micro
Service
AWS OpsWorksでは、それぞれのMicro-Serviceを「レイヤー」で定義可能
6
Agenda
• Introduction
• AWS OpsWorks概要のおさらい
• AWS OpsWorksアップデート
• AWS OpsWorks Tips
• お客様の事例
• まとめ
7
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のレシピの作成に集中可能
16
Stack
OpsWorks利用の流れ
User AWS Management Console
Load Balancerレイヤー
App Serverレイヤー
Databaseレイヤー
構成情報(JSON)
①スタックの作成
②レイヤーの作成
17
Stack
OpsWorks利用の流れ
User AWS Management Console
Load Balancerレイヤー
App Serverレイヤー
Databaseレイヤー
レシピ
レシピ
レシピ
構成情報(JSON)
①スタックの作成
②レイヤーの作成
③レシピの設定(Appの設定)
18
Stack
OpsWorks利用の流れ
User AWS Management Console
Load Balancerレイヤー
App Serverレイヤー
Databaseレイヤー
レシピ
レシピ
レシピ
構成情報(JSON)
①スタックの作成
②レイヤーの作成
③レシピの設定(Appの設定)
④レイヤーにインスタンス追加・起動
19
Stack
OpsWorks利用の流れ
User AWS Management Console
Load Balancerレイヤー
App Serverレイヤー
Databaseレイヤー
レシピ
レシピ
レシピDB
Web/App
LB
①スタックの作成
②レイヤーの作成
③レシピの設定(Appの設定)
④レイヤーにインスタンス追加・起動
⑤ライフサイクルイベントにより、レシピが自動実行される
構成情報(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は、最近スタックコマンドによって実行されたことがあるコマンドのみ再実行が可能。手順は以下。– 1.最近実行されたコマンド(のキャッシュ)を表示する
– 2.表示されたコマンドの中に、実行したいコマンドがあれば同じコマンドを実行可能
$ 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から
パラメータを取得するときの参考として活用可能
38
インスタンスがonlineになるとConfigureが自動実行される
Appサーバーの起動
App
サーバー
Setup Deploy Configure Execute Recipe Shutdown
40
Setup, Deployが自動実行される
Appサーバーの起動
App
サーバー
DB
サーバー
DBサーバーの起動
Setup Deploy Configure Execute Recipe Shutdown
41
DBサーバーがonlineになるとスタック内の全インスタンスでConfigureが自動実行される
Appサーバーの起動
App
サーバー
DB
サーバー
DBサーバーの起動
Setup Deploy Configure Execute Recipe Shutdown
42
さらにインスタンスを追加
Appサーバーの起動
App
サーバー
DB
サーバー
App
サーバー
DBサーバーの起動
Setup Deploy Configure Execute Recipe Shutdown
43
Setup、Deployが自動実行される
Appサーバーの起動
App
サーバー
DB
サーバー
App
サーバー
DBサーバーの起動
Setup Deploy Configure Execute Recipe Shutdown
Appサーバーの起動
44
インスタンスがonlineになるとスタック内の全インスタンスでconfigureが自動実行される
Appサーバーの起動
App
サーバー
DB
サーバー
App
サーバー
DBサーバーの起動
Setup Deploy Configure Execute Recipe Shutdown
Appサーバーの起動
45
手動でデプロイを実行
Appサーバーの起動
App
サーバー
DB
サーバー
App
サーバー
DBサーバーの起動
Setup Deploy Configure Execute Recipe Shutdown
Appサーバーの起動
手動でデプロイを実行
46
レシピを手動で実行
Appサーバーの起動
App
サーバー
DB
サーバー
App
サーバー
DBサーバーの起動
Setup Deploy Configure Execute Recipe Shutdown
Appサーバーの起動
手動でデプロイを実行
レシピ単体を実行
47
インスタンスを停止
Appサーバーの起動
App
サーバー
DB
サーバー
App
サーバー
DBサーバーの起動
Setup Deploy Configure Execute Recipe Shutdown
Appサーバーの起動
手動でデプロイを実行
レシピ単体を実行
Appサーバーのシャットダウン
48
インスタンスがonlineでなくなると、Configureが自動実行される
Appサーバーの起動
App
サーバー
DB
サーバー
App
サーバー
DBサーバーの起動
Setup Deploy Configure Execute Recipe Shutdown
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
• AWS OpsWorks概要のおさらい
• AWS OpsWorksアップデート
• AWS OpsWorks Tips
• お客様の事例
• まとめ
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スタックに追加する方法• 1.インスタンスの準備• 2.AWS CLIのインストールおよび設定• 3.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
※1つのスタック内に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年5月に導入– 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
• AWS OpsWorks概要のおさらい
• AWS OpsWorksアップデート
• AWS OpsWorks Tips
• お客様の事例
• まとめ
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の設定を書き換えるだけで
レシピの使い回しが可能
• 使い方– 1.カスタムJSONにdata_bagsの
情報を追加する– 2.以下のようにレシピ内で検索する
{ "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の使用方法• 1.スタックの設定で、カスタムcookbooksの利用が可能である
ことを確認して、Berkshelfの設定を有効にする
• 2.スタックの設定で指定したカスタムcookbooksのリポジトリの最上位ディレクトリにBerkfileという名前のファイルを配置。その中身の例は以下
• 3.スタックのコマンドでUpdate Custom Cookbooksを実行– インスタンス内の/opt/aws/opsworks/current/berkshelf-cookbooksに、該当する
cookbookが配置される。
• 4.スタックのコマンドで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の作成方法
• 1.レイヤーにインスタンスを追加• 2.インスタンスを起動してSSHでログイン、以下の処理を行う
※OpsWorksで起動したインスタンスはユニークなIDの情報を含んでいるため、IDが重複しないように、AMI保存する前に上記作業により削除しておく必要がある。
• 3.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のシステム、アプリケーション、およびカスタムログ
84
OpsWorksのユーザーアクセス管理
• 以下の2通りの方法で実現可能– OpsWorksのPermissionsページの機能(あるいはそれ相応の
API, CLI)を使う方法
– 適切なIAMアクセスポリシーを使う方法
• 両方を組み合わせて利用可能
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
インスタンスが予期せずに再起動する(1)
• 問題– 停止されたインスタンスが予期せずに再起動する
• 原因– インスタンスの自動ヒーリングを有効にしていると、異常なインス
タンスを再起動する。EC2コンソールやEC2のAPI, CLIを使ってインスタンスを停止すると、OpsWorksにはそれが通知されない。そのため、そのインスタンスをOpsWorksは異常とみなし再起動する
• 解決方法– OpsWorksのコンソール、API、CLIを使ってのみインスタンスを
管理することを推奨(自動ヒーリングを無効化も可能)
90
Agenda
• Introduction
• AWS OpsWorks概要のおさらい
• AWS OpsWorksアップデート
• AWS OpsWorks Tips
• お客様の事例
• まとめ
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
• AWS OpsWorks概要のおさらい
• AWS OpsWorksアップデート
• AWS OpsWorks Tips
• お客様の事例
• まとめ
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
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/FacebookAWSの最新情報をお届けします
@awscloud_jp
検索
最新技術情報、イベント情報、お役立ち情報、お得なキャンペーン情報などを日々更新しています!
もしくはhttp://on.fb.me/1vR8yWm
Recommended