よくわかるAWS OpsWorks: AWS OpsWorksの概要＆アップデート紹介

よくわかるAWS OpsWorks

AWS OpsWorks概要＆アップデート紹介

2015/03/26

アマゾンデータサービスジャパン株式会社

ソリューションアーキテクト舟崎健治

自己紹介

• 名前：舟崎健治（ふなさきけんじ）

• 所属：アマゾンデータサービスジャパン

• 職種：ソリューションアーキテクト

• 好きなAWSのサービス：AWS OpsWorks

AWS初心者向けWebinarの活動に取り組んでいます！

Introduction ～よく頂くご要望～

デプロイを自動化したい。

運用負荷を軽減したい。

開発者、またはシステム管理者

AWS OpsWorksとは

アプリケーションのライフサイクル管理サービス

デプロイを頻繁に、早く、セキュアに実行可能

スケーラブルで複雑なインフラストラクチャを管理、モデル化、自動化

することが可能

ビルトイン構成を使って簡単に開始可能

追加コストは不要

なぜAWS OpsWorksを使うと良いのでしょうか？

自動化できる領域が多くなる

デプロイ自動化運用タスクの自動化

運用負荷を軽減できる

EC2インスタンスの構築例

インスタンス起動

ソフトウェアインストール・構成用のスクリプトを実行

アプリケーションのデプロイ

EC2のAPIで自動化が可能

ユーザー側でインスタンス内部で起動スクリプト等を使って、自動化が可能

OpsWorksインスタンスの構築例

インスタンス起動

ソフトウェアインストール・構成用のChefレシピを実行

アプリケーションのデプロイ用のChefレシピを実行

OpsWorksのAPIで自動化が可能

なぜ、OpsWorksでインスタンス内部のChefレシピをリモートからOpsWorks APIで実行可能か？

OpsWorksインスタンス内で、OpsWorksエージェントがインストール・動作しているため

OpsWorksの基本的な仕組み(1)

EC2インスタンス上のOpsWorksエージェント

OpsWorks

talks with

OpsWorks エージェントからOpsWorks エンドポイントに対してPolling（アウトバウンド通信）

OpsWorksの基本的な仕組み(2)

OpsWorksによって発行された一連のコマンドを取得AgentがChef solo(Chef Zero)でレシピを実行

EC2インスタンス上のOpsWorks Agent

Chef 11.10ではChef Clientのlocal modeにて動作

OpsWorksの動作要件

• Amazon LinuxまたはUbuntu 12.04LTS,14.04LTSベース– AMIをカスタマイズ可能

• Chefバージョン0.9, 11.4, 11.10に対応

• VPC対応– デフォルトVPC, 自作VPC共に利用可能

• ELB、RDS、CloudFormation、CloudTrailに対応

• 起動したインスタンスからOpsWorksサービスエンドポイントへアウトバウンド通信が可能であること

OpsWorks利用の流れ

User AWS Management Console

Stack



構成情報(JSON)

①スタックの作成

Stack



Load Balancerレイヤー

App Serverレイヤー

Databaseレイヤー

構成情報(JSON)


②レイヤーの作成

Stack






レシピ

レシピ

レシピ

構成情報(JSON)



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

Stack






レシピ

レシピ

レシピ

構成情報(JSON)




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

Stack






レシピ

レシピ

レシピDB

Web/App

LB




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

⑤ライフサイクルイベントにより、レシピが自動実行される

構成情報(JSON)

Web/App

スタックとは

• OpsWorksのトップエンティティ

• 属する全インスタンスの構成を管理– OSの種類、リージョン、インスタンスのIPアドレスなど

• カスタムレシピを保存する任意のリポジトリを指定可能

• VPC内部に作成可能

• スタックをコピー可能– リージョン間でも可能

レイヤーとは

• インスタンス構築のための青写真（設計図）

レシピを指定して、パッケージインストールなどの必要な処理を定義

カスタムレシピも定義可能

追加のEBSボリュームの指定。RAID指定も可能

ビルトインレイヤーの種類

• Load Balancer– HAProxy

– ELB（各レイヤーに個別にアタッチ可能）

• App Server– Static Web Server

– Rails App Server

– PHP App Server

– Node.js App Server

• DB– MySQL– RDS

• Other– Memcached– Ganglia– Custom

• ビルトインレイヤー以外にもカスタムレイヤーを使って任意の役割を持つレイヤーを作成可能（Jenkinsレイヤーなど）

インスタンスとは

• アプリケーションを提供するための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も使用可能

OpsWorksの 5 つのライフサイクルイベント

Setup

Configure

Deploy

Undeploy

Shutdown

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

最初のインスタンスを追加

Appサーバー

Setup Deploy Configure Execute Recipe

Shutdown

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

Appサーバーの起動

Appサーバー


Shutdown

Setupが実行された後にDeployが自動実行される


Appサーバー


Shutdown

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


Appサーバー


Shutdown

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


Appサーバー

DBサーバー


Shutdown

Setup, Deployが自動実行される


Appサーバー

DBサーバー

DBサーバーの起動


Shutdown

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


Appサーバー

DBサーバー



Shutdown

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


Appサーバー

DBサーバー

Appサーバー



Shutdown

Setup、Deployが自動実行される


Appサーバー

DBサーバー

Appサーバー



Shutdown


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


Appサーバー

DBサーバー

Appサーバー



Shutdown


手動でデプロイを実行


Appサーバー

DBサーバー

Appサーバー



Shutdown



レシピを手動で実行


Appサーバー

DBサーバー

Appサーバー



Shutdown



レシピ単体を実行

インスタンスを停止


Appサーバー

DBサーバー

Appサーバー



Shutdown




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

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


Appサーバー

DBサーバー

Appサーバー



Shutdown




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

ライフサイクルイベントに登録するレシピの例（レイヤー別）

Setup Configure Deploy Undeploy Shutdown

ロードバランサーレイヤー

ロードバランサーをインストール

アプリケーションサーバーのIPをアップデート

コネクションをDrainする

アプリケーションサーバーレイヤー

アプリケーションサーバーをインストール

DB接続先をアップデートしてリスタート

アプリケーションコードをアップデートしてリスタート

アプリケーションを削除してリスタート

ログを保存

データベースレイヤー

データベースをインストール

アプリケーションサーバーのIPのACLをアップデート

スナップショットの作成

AWS OpsWorks アップデート

AWS OpsWorksアップデート内容

• 2015/12/8

既存のEC2インスタンスとオンプレミスサーバのサポート

• 2014/12/15カスタムシャットダウンとELBのコネクションドレイン機能のサポート

• 2015/3/2Ruby 2.2サポート

AWSとオンプレミスのハイブリッド構成

• オンプレミス環境の仮想サーバ、あるいは物理サーバにOpsWorksエージェントをインストールして、管理可能

• サーバ1台あたり$0.02/hour

Instance A Instance B Instance C Instance D

オンプレミス環境 AWS Cloud

オンプレミス環境での対応オペレーティングシステム• Ubuntu 12.04 LTS• Ubuntu 14.04 LTS

2015/3/22現在

register an instanceを選択

インスタンスタイプを選択

AWS CLIのインストール

AWS CLIでインスタンス登録コマンドを実行

登録されたインスタンスをレイヤーにアサインする

レイヤーへのアサインを確認

オンプレミスのサーバの追加完了

まとめ

まとめ

• AWS OpsWorksを使って、デプロイ・運用タスクを自動化可能

• ライフサイクルイベントにより、適切なタイミングでChefレシピを自動実行可能

• オンプレとAWSのハイブリッド構成が可能

新しいDevOpsソリューションをお試しください！

ご清聴頂きありがとうございました！

Appendix

OpsWorksで実行可能なコマンド

以下の2種類がある

スタックコマンド

スタック全体の構成を変更・管理するためのコマンド

AWSマネージメントコンソール、AWS SDK、AWS CLIでリモートから実行可能

エージェントコマンド

デバッグやトラブルシューティングのために利用するコマンド

それ以外の用途の場合は、スタックコマンドの利用を推奨

インスタンス内部にログインして実行可能。

sudoもしくはroot権限が必要

OpsWorksインスタンスに対してリモートからChefレシピ実行コマンドを発行

実行するスタックコマンドを選択

実行するCookbook/レシピ名を選択

実行するインスタンスを選択

スタックコマンドを使ってリモートから任意のタイミングでインスタンスにコマンドを実行可能

スタックコマンド内容

Install Dependencies 全てのパッケージをインストールする

Update Dependencies 全てのパッケージをアップデートする

Update Custom Cookbooks

リポジトリにある更新されたCookbookをそれぞれのインスタンスに展開する

Execute Recipes 指定したレシピを指定したインスタンス上で実行する

Setup Setupのレシピを実行する（Setupを実行するとDeployもその後で実行される）

Configure Configureのレシピを実行する。

AWS Management Console

管理者Instances

インスタンスからのPollingのタイミングでExecute Recipesを実行

OpsWorksエージェントがChefレシピを実行Execute Recipes

実行リクエスト

レシピを自動で実行させるには？

• Execute Recipesのスタックコマンドをcron等のタスクスケジューラを使って自動実行

• OpsWorksのライフサイクルイベントにレシピを登録して、適切なタイミングで自動実行

さらに、AWS OpsWorksでは継続的な構成管理が可能です。

構成情報の管理

（途中省略）"instance": {

"id": "b29e44ed-6245-40a6-9575-eaa97a3a3d49","hostname": "custom12","instance_type": "t2.micro","public_dns_name": "ec2-54-65-253-240.ap-northeast-1.compute.amazonaws.com","private_dns_name": "ip-10-0-0-15.ap-northeast-1.compute.internal","ip": "54.65.253.240","private_ip": "10.0.0.15","architecture": "x86_64","layers": [

"custom1","php-app"

], （以下省略）

OpsWorks

構成情報をキャッシュとして保持

構成情報(JSON)

スタック内のインスタンス

構成情報をJSON形式で保持

ホスト名IPレイヤー等

構成情報(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]

deploy JSONの例

Chefレシピから取得する例

取得した値をApp ServerインスタンスのローカルにDB接続用の設定ファイルとして保持しておく。configureが実行されるたびに上記値を更新する

ElastiCacheとの連携例

スタック


ElastiCache Redis

構成情報(JSON)

{"deploy": {

"elasticacheredisexample": {"redis": {

"host": "mycluster.XXX.amazonaws.com", "port": "6379"

}}

}}

ElastiCacheRedisを事前に作成

Chefレシピから上記パラメータを取得する詳細http://aws.amazon.com/blogs/aws/using-aws-elasticache-for-redis-with-aws-opsworks/

ElastiCache以外のデータストアを利用する場合も上記方法と同様に連携が可能

• OpsWorksではElastiCacheは未サポートだが、スタックJSONに接続情報を追加することで連携可能

http://aws.amazon.com/blogs/aws/using-aws-elasticache-for-redis-with-aws-opsworks/

プライベートサブネット内にOpsWorksインスタンスを配置可能

VPC Public Subnet

VPC Private Subnet

Internet Gateway

NAT

App Code Repository

• OpsWorksにより起動されたインスタンスはOpsWorksサービスエンドポイントと接続が必須（Privateサブネット利用時はNAT必須）

• プライベートサブネット内のコードリポジトリを利用可能

OpsWorks

instances

アウトバウンド通信が必要

よくわかるAWS OpsWorks: AWS OpsWorksの概要＆アップデート紹介

Technology

Transcript of よくわかるAWS OpsWorks: AWS OpsWorksの概要＆アップデート紹介