AWS OpsWorksって何？ から、運用しやすくなる下準備のポイントまで：AWS OpsWorksアプリケーション運用の勘所（1）（1/5 ページ）

ChefをベースにしたAWS OpsWorks。実際に使ってみるとどんな感じ？ 筆者が体当たりで検証。運用面でのハウツーも紹介していきます。

[あけり，＠IT]

はじめに

　2013年2月にリリースされたAWS OpsWorks。筆者が試しにいじっているうちに、どう使うと便利なのか、気を付けないと逆に運用が大変になるポイントなどが見えて来ました。

　本連載では、何回かに分けてAWS OpsWorksの便利な点、不便な点をおさらいしながら使い勝手を紹介して行きたいと思います。題材として、「EC-CUBE」というAWS OpsWorksに最適化されていないオープンソースのパッケージを使ってみました。

　AWS OpsWorksは、Amazon Web Servicesが提供するChefをベースにしたサービスです。Chefのレシピを使ってシステムの構成などを一元的に設定できます。また、アプリケーションのデプロイ方法、スケーリング方法、保守方法なども事前設定することで自動化を図ります。本稿執筆時点ではまだβ版提供の段階ですが、今後正式リリースされれば開発環境として非常に有効な選択肢となるでしょう。

　本稿では、実際に利用する場合に注意すべきポイントにフォーカスして解説を進めますので、AWS OpsWorks自体の使い方については、Amazon Web Servicesのブログ記事を参照してください。サービスを紹介する動画もYouTubeで公開されています。

　本稿で使用したEC-CUBEは、E-コマースサイト構築のためのOSSパッケージで、ロックオン社が提供しています。商用版と無償版があり、無償版は、GNU GENERAL PUBLIC LICENSE v.2（例外条項付き）で配布されており、メンバー登録を行うと誰でもダウンロード、カスタマイズ可能です。

運用も考えたAWS OpsWorks

　OpsWorksで運用するためにはEC-CUBEをインストールする段階で、あらかじめ幾つかの下準備をしておいた方が良いことに気付きます。ごく大まかにいうと、以下の項目は下準備をしておくと良いでしょう。

ポイント1：カスタムレシピの準備

　AWS OpsWorksはChefを使っていますので、Recipeを使うことができます。よっぽどAWS OpsWorksでの運用に最適化されたアプリケーションでもない限り、スマートな運用はできません。例えば、今回使うEC-CUBEもAWS OpsWorksで運用されることは考慮していないので、ビルドインのRecipeを使うだけでは運用が楽になる気がしません。ですから、ApacheのインストールやPHPのインストールなど、おおまかな部分はビルドインに任せつつ、アプリケーション特有の部分はカスタムレシピを作って対応しましょう。

　これをやらないと「AWS OpsWorksを使うよりも普通に運用した方が楽じゃん！」ということにもなりかねません。

ポイント2：ディレクトリのパーミッション設定

　AWS OpsWorksではデフォルトのディレクトリ所有者がdeploy:rootになっています。アプリケーション書き込みができませんので、ここも変更しておく必要があります。

ポイント3：データベースの設定はハードコーディングしない

　AWS OpsWorks上でDevOps環境を構築する場合は、データベースそのものに設定をハードコーティングしないようにします。その代わり、AWS OpsWorks用の設定ファイルで接続方法などを指定しておくようにします。

ポイント4：インストール後の状態をリポジトリと同期する

　アプリケーションをAWS側にデプロイすると、ローカルにブランチが生成されます。このブランチの同期をとっておきます。

　それでは、AWS OpsWorksを使って運用しやすいようにインストールしてみましょう。