AWS OpsWorksでEC-CUBEをインストールしてみる。

#AWS OpsWorks

#AWS

とくがみ

2013.02.20

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

AWS BeanstalkでEC-CUBEという記事を書きかけてました。

こんにちは。頭にAWSが付くサービスは、頭にAmazonが付くサービスのオーケストレーション系のサービスだと思ってるあけりです。

2013年2月19日 AWS OpsWorksというサービスがリリースされました。このサービスはなんか良い感じにサービスの運用を手助けしてくれる、サービスのようです。

実は今AWS BeanstalkでEC-CUBEという記事を書きかけていたのですが、HostManagerの辺りをどうわかりやすく（ブログを読んだ人が実践できるように）説明しようかと悩んでいた所だったのですが、それは無かったことにします。

まさにこの悩みを解決してくれそうなサービスAWS OpsWorksが登場したからです。

AWS OpsWorksでEC−CUBE

改めまして、AWS OpsWorksでEC-CUBEを運用することを考えインストールするところをまでをやってみます。

AWS OpsWorksとは

AWS OpsWorksとは Amazon CTO のDr.Werner Vogelsのブログを意訳すると、「アプリケーションとそれが動くインフラをモデル化して自動化と制御ができるだぜ。例えば、負荷に応じてEC2を増やしたり減らしたり、インフラの構成も管理できるし、アプリケーションのデプロイ、ミドルウェアのアップデート、監視、アクセス制御などアプリケーションを運用するのに必要な機能がOpsWorks一つで管理できるんだ。」そんな感じです。

同じエントリにあったこの図が凄くわかりやすいと思いました。 app-svcs-comparison-graphic

All Things Distributed: Expanding the Cloud - Introducing AWS OpsWorks, a Powerful Application Management Solution

Stackの作成

まずはStackを作るところから始まります。 mc-top ManagementConsoleから作ることが出来ます。

addStack 名前を設定したり、リージョンを決めたり色々デフォルトはどうするみたいなことを決めます。ここで、今までAWSには無かった不思議な設定項目が出て来ました。色の選択です。この色はあとでManagementConsoleで見分けがつきやすい用になっているのでしょう。 Stackを間違えるというミスを少なくしてくれようとする辺り運用に力を入れているのが伝わってきます。が、、私はもっとパステルカラーが好きです。

stack

できました。

Layerの作成

Stackができたら次はLayerを作ります。

addLayer

Layerは役割毎に作ります。今回は、EC-CUBEを運用したいので、LoadBalancerのLayerとWebサーバ(PHP)のLayer、データベース（mysql）のLayerの3つを作ります。

LayerPHP Webサーバ（PHP）のLayer

LayerDB データベースのLayer

LayerLB ロードバランサーのLayer

Layers

3つのレイヤーが出来ました。

アプリケーションの設定

次にAppsという所でアプリケーションを設定します。

createApp

ここではRepositoryにアクセスするための鍵や、SSL,ドメイン、DocumentRootなどを設定します。 WebServerとか、LoadBalancerのLayerで設定しないのが不思議です。

instanceの起動

ここまで来たらインスタンスを起動します。各レイヤーでとりあえず、インスタンスを一個ずつ追加してみます。 addInstance ScalingTypeが、時間で起動する、負荷で起動する、起動しっぱなしから選べるようです。インスタンスを作ると各レイヤー毎にインスタンスの一覧が表示されています。 instances

今回は使いませんが、バッチ用のサーバなんかもLayerで管理すると便利そうだなと思いました。

すべてのLayerで一括でインスタンスを起動する便利ボタンがあるのでポチッとします。

startInstance-all

[番外編]インスタンスがSetupに失敗！

PHPのLayerのインスタンスがsetupに失敗したようです。インスタンスのsetupに失敗すると、このような表示になっており、ログを確認する事が出来ます。

failStart

ログを確認する事ができるらしいので、見てみます。ログを確認するためのインターフェイスもManagementConsoleにあるのが、運用を意識したサービスです。 Stacke,Layer,Instanceで絞り込んで表示する事ができそうです。 showLog おそらくここに表示があるのでしょうが、見れない。。。。 Download the plain text versionというところをクリックするとS3に保存されたログを見れるようなのですが、AccessDeniedでした。

SSHで接続すると正常にうごいていそうなのと、S3にログが保存されていない事から、おそらくIAMRoleがうまくいってないのかなと思いIAMRoleにPolicyを設定した所無事に起動するようになりました。もし、インスタンスが起動しているのにAWS OpsWorksからは起動していないように見られている場合はIAMRoleを確認してみて下さい。

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

DeployApp

デプロイはものすごく簡単で、githubなどのリポジトリにpush しておけば、そこから取ってきてくれ（るように設定でき）ます。

EC-CUBEのインストール

アプリケーションのデプロイが終わったら次はEC-CUBEのインストールをします。

一つ注意点として、OpsWorksにデプロイする時になぜか空のディレクトリが削除されてしまうようなので、 repositoryにpushする前に、

touch data/cache/dummy 
touch data/config/dummy 
touch data/logs/dummy 
touch data/upload/dummy 
touch data/Smarty/templates_c/dummy 
touch html/plugin/dummy 
touch html/install/temp/dummy

しておくと良いと思います。

eccube インストーラにしたがって行けば大丈夫ですので、ここでは割愛します。データベースの設定はMySQLのLayerを作った時のユーザとパスワード、インスタンスのIPアドレスで接続する事が出来ます。

EC-CUBEインストール後

cubetop EC-CUBEインストールが終わったら、一度SSHでログインし、git push しておくと、インストーラーが生成・変更したファイルをリポジトリに反映する事が出来ます。今後の運用を考えると、リポジトリとサーバで動いているコードを合せておきたいなと

さいごに

今回はインストールだけで終わってしまったので、EC2、RDS立ちあげてよりも面倒でした。しかし、今後も運用を続けることを考えると、何かしら管理の機構があると安心です。

AWS Beanstalkという選択肢もあるのですが、冒頭で書いた通り、少し無茶しないと行けない所があったので、運用を考えると少し面倒だったところでした。そこにAWS OpsWorksというまさにBeanstalkでちょっと大変な思いをしなくてはの部分がやりやすくなったサービスの登場は嬉しいですね。

今後のアップデートでVPC、t1.micro、Cost Allocationなタグが付いてくれたりすることを期待してます。

CloudFormationとくらべてもすべてがブラウザからグラフィカルに作れ、一度作ったStackを複製することもできるようなので、案件毎にStackを作って管理するなんてのにも向いているかもしれません。

AWSは既にインフラコストを大幅に下げましたが、AWS OpsWorks運用のコストを下げてくれそうです。 AWSユーザとしては積極的に運用のコストを下げられる事がものすごく嬉しいです。

ほんとうにさいごに。。。。。。。。MySQLのLayerはInstance増やしたら一体どうなるんだろう。。。。