この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
ども、大瀧です。
本日、AWS OpsWorksのRDSサポートが追加されました。...とAWSブログのタイトルにあるのですが、実は従来からOpsWorksのインスタンスからRDS(データベース)へのアクセスはサポートされていました。しかしそれは、同じVPC内に配置すれば接続できるという要件での話で、RDSの接続情報をコピーしOpsWorksのカスタムJSONに貼付けてChef Soloでアプリケーションの設定ファイルに流しこむという、プリミティブな方法でした。
今回のアップデートにより、OpsWorksからRDSを認識しOpsWorksの作法でデータベース構成情報をインスタンスに注入する仕組み(node[:deploy][:database]以下)が用意され、OpsWorksとRDSの連携と胸を張って言えるようになったのではと思います。
構成例 : WordPress Cookbook
今回はサンプルとして、PHP+MySQLのWebアプリの代表格であるWordpressで試してみます。
ただし、ただ普通にCookbookを使って———とやっても面白くないので、以下のブログで紹介されている従来のOpsWorks向けCookbookをそのまま使ってみます。
上記CookbookはPHPレイヤーとMySQLレイヤーをそれぞれ構成するMySQL on EC2前提のCookbookなんですが、そのMySQLレイヤーをCookbookの変更無しでそのままRDSに置き換えできるというのがポイントです。
1. スタック、レイヤーの作成
OpsWorksスタックとPHP App Serverレイヤーの作成は、元のブログ記事と特に変わりません。OpsWorksの管理画面を表示し、[Add Stack]から以下のように新規スタックを作成します。
[Repository URL]には「https://github.com/chriselsen/opsworks-cookbooks.git」(GitHubのリポジトリ)と入力し、[Custom Chef JSON]には以下(元のブログ記事のコピペ)を入力します。
{
"opsworks" : {
"deploy_user" : {
"user" : "www-data"
}
},
"apache" : {
"timeout" : 40,
"keepalive" : "On",
"keepaliverequests" : 200,
"keepalivetimeout" : 2,
"prefork" : {
"startservers" : 3,
"minspareservers" : 3,
"maxspareservers" : 10,
"serverlimit" : 32,
"maxclients" : 32,
"maxrequestsperchild" : 2000
}
}
}続いて、[Add a layer]をクリックし「PHP App Server」レイヤーを選択、[Add Layer]で追加します。
続いてRDSを追加するために[+ Layer]をクリックし再度レイヤー追加画面を表示します。引用元のブログ記事では、ここでMySQLレイヤーを追加していますが、今回は新しく追加された[RDS]タブを選択します。初回の場合は、OpsWorksの管理サーバーからAWSの各サービスにアクセスするためのIAMロール(aws-opsworks-service-role)にRDSの管理権限が付与されていないため、権限のアップデートが指示されます。[Update]ボタンをクリックすると追加されます。
ちなみに、アップデート後のaws-opsworks-service-roleロールの権限は以下になります。
{
"Statement": [{
"Action": [
"ec2:*",
"iam:PassRole",
"cloudwatch:GetMetricStatistics",
"elasticloadbalancing:*",
"rds:*"
],
"Effect": "Allow",
"Resource": ["*"]
}]
}ちゃんとRDSの権限が付与されていますね。続いて[Add an RDS DB Instance]をクリックします。
新規ウィンドウが立ち上がり、RDSのDBインスタンス作成画面が表示されるので、DBインスタンスを作成します。OpsWorks向けの特別な操作は特にありません。
作成後OpsWorksの画面に戻り一度ページをリロードすると、作成したRDSのDBインスタンスが表示され[Connection Details for <DBインスタンス名>]という、OpsWorksのアプリケーションからRDSに接続するときの認証情報の入力画面が表示されます。ここに入力したものが自動的にnode[:deploy][:database][:username](ユーザー名)およびnode[:deploy][:database][:password](パスワード)にセットされ、Cookbookレシピから参照できるようになります。今回の連携のキモと言える部分です。
ここに入力するユーザー名は、RDSで事前に作成済みのものを入力する必要があります。この操作によってRDSにユーザーが自動追加されるわけではないことに注意してください。
今回はお試しなので、DBインスタンス作成時にセットしたマスターユーザーを入れました。[Register with Stack]をクリックし、完了です。
続いて、PHP App ServerレイヤーのCookbookレシピ設定を変更します。GitHubのCookbookに倣い、PHP App Serverレイヤーの[Custom Chef Recipe]設定の[Configure]に「wordpress::configure」を追加します。
これでレイヤーの設定は完了です。
2. インスタンス、アプリケーションの追加
続いて、WordPressを実行するPHP App Serverレイヤーにインスタンスを追加します。画面上部のドロップダウン、もしくは左のメニューから[Instaces]を選択し、[Add a instance]をクリックします。
好みのインスタンスタイプを選択(最近デフォルトがc3.largeに変わったようです)、[Add Instance]をクリックしインスタンスを追加します。
次は、PHPインスタンスにデプロイするWordPressのアプリケーションを定義します。画面上部のドロップダウン、もしくは左のメニューから[Apps]を選択し、[Add an app]をクリックします。
以下のように[Data source type]で「RDS」を選び、作成したRDS DBインスタンスのホスト名を選択、DBインスタンス作成時に指定したDB名を入力します。これらは、ユーザー/パスワードと同じくnode[:deploy][:database][:host](ホスト名)とnode[:deploy][:database][:database](DB名)としてレシピから参照されます。また、WordPressのアーカイブファイルを[Repository type]および[Repository URL]で指定し、[Add App]で作成します。
これで準備OKです！
3. 動作確認
では、インスタンスを起動しWordPressが動作するか確認してみます。[Instances]メニューをクリックし、作成したインスタンスの右にある[start]でインスタンスを起動します。
しばらく待ち、[online]になったらセットアップ完了です。今回はELBがないので、[Public IP]列のリンクをクリックし直接インスタンスにアクセスします。
WordPressのセットアップ画面が表示されました！しかも、データベースのセットアップ画面がスキップされているため、既にRDSへの接続設定が完了していることがわかります。試しに残りの項目を入力し、ブログのトップページを表示してみます。
ちゃんと動作していますね！
また、念のためインスタンスにSSHで接続し、WordPressの設定ファイルを見てみました。
/srv/www/wordpress/current/wp-config.php
ちゃんと入ってますね！
まとめ
OpsWorksとRDSの連携ということでWordPressでのセットアップ手順をご紹介してみました。CloudFormationなどの完全自動化の仕組みと比べると手順が多いように見えますが、CookbookおよびカスタムJSONの設定で自在に構成変更できるので、OpsWorksを使うことでより柔軟性の高いWebアプリケーション管理ができると思います。
6
