AWSのOpsWorksに触れてみる
AWSのOpsWorksを少しいじってみました。
今回は触ってみただけなので最低限のことしか行っていません。
環境構築やデプロイを自動で行うサービスです。Chefも利用出来る点やAWS特有のEC2やRDSの設定を行える点が非常に魅力的だと考えられます。
それが Stack と Layer と Instance と App です。以下が構成のイメージ図です。
Stackの設定時にChefのリポジトリを登録するためStackとChefも一対一の関係になるようです。
Layerの種類としてはロードバランサーやアプリサーバ、データベースなどがあります。
AppServerのLayerに対してのInstance はEC2のInstanceとなり
DBのLayer(Mysql)に対してのInstanceはRDSのInstanceとなります。
ここで作成されたAppServerのInstanceはEC2のDashboardで確認することが出来ます。
Instanceの種類。
・24時間稼働する( 24/7 )
・時間帯による稼働(Time-based)
・負荷による稼働(Load-based)
主な設定内容。
・アプリの種類
( Ruby in Rails 、PHP、Node.jsなど)
・アプリのリポジトリ
(リポジトリのURL、ブランチなど)
・ドメインの設定
・SSLの設定
実際に設定したものを続きに書きます
今回は触ってみただけなので最低限のことしか行っていません。
OpsWorksとは
Awsが提供してるサービスの一つです。環境構築やデプロイを自動で行うサービスです。Chefも利用出来る点やAWS特有のEC2やRDSの設定を行える点が非常に魅力的だと考えられます。
イメージ図
OpsWorksには4つの要素で成り立っています。それが Stack と Layer と Instance と App です。以下が構成のイメージ図です。
Stack
一つの環境に対して一つのStackと言えるかと思われます。StackはOpsWorksで最も大きい要素になりStackの設定時にChefのリポジトリを登録するためStackとChefも一対一の関係になるようです。
Layer
LayerはStackに対して複数のLayerが存在します。Layerの種類としてはロードバランサーやアプリサーバ、データベースなどがあります。
Instance
実際に稼働するサーバですね。AppServerのLayerに対してのInstance はEC2のInstanceとなり
DBのLayer(Mysql)に対してのInstanceはRDSのInstanceとなります。
ここで作成されたAppServerのInstanceはEC2のDashboardで確認することが出来ます。
Instanceの種類。
・24時間稼働する( 24/7 )
・時間帯による稼働(Time-based)
・負荷による稼働(Load-based)
App
アプリの情報の設定を行います。主な設定内容。
・アプリの種類
( Ruby in Rails 、PHP、Node.jsなど)
・アプリのリポジトリ
(リポジトリのURL、ブランチなど)
・ドメインの設定
・SSLの設定
実際に設定したものを続きに書きます