トップ > Engine Yard > すごいぜChef！イカスぜEngine Yard！

すごいぜChef！イカスぜEngine Yard！

Engine Yard Cloud Automator データベース
記事タイトルとURLをコピーする
こんにちは、サービス開発グループの千葉(@kachina_t)です。 現在、Elastic BeanstalkとEngine Yardの検証を実施しています。
今回は、Engine Yard にRailsアプリをデプロイしてみたので
備忘録がてら投稿したいと思います。 Engine Yardの紹介と、他PaaSとの比較についてはHerokuとEngine YardとElastic Beanstalk をご覧ください。 まず、弊社のサービスのCloudworksは、現在Herokuで稼働しています。 私達は、現在CloudworksDE(Dedicated Edition)なるサービスを開発しています。
これは、Cloudworksがお客さまのVPC上で動作する専有版であり
既存の機能に加えて、企業でのAWS利用にて求められる
組織での利用に配慮した機能拡張や、ELB対応等の機能拡張をおこなっています。 さて、そんなCloudworksDEなのですが、AWSのVPC上に環境を構築するので
データベースにはRDSを利用しています。
Herokuで利用するDBMSは、基本的にPostgreSQLとなっているのですが
RDSで利用できるDBMSは以下のとおりです。
  • MySQL
  • Oracle Database
  • Microsoft SQL Server
変なコードさえ書いて無ければ、ORMが上手い事やってくれて
プログラマは裏で動いているDBMSが何だろうが意識しなくて良い。 なんて言われてはいますが、まだ複数列インデクスの挙動に差異があったりするので
裏で動いているDBMSを意識する必要があります。 そんな訳で、PostgreSQLとMySQLが混在している状況は
なんだかちょっと好ましくありません。 DBだけRDSを使うってのも考えたのですが、せっかくPaaSを使ってるのに
イケてない感じがしてイヤなので別の方法を…と さて、前置きが長くなりましたが、そんなワケで
Elastic BeanstalkとEngine Yardにチャレンジした次第です。
(Engine Yardでは東京リージョンが使えるってのもgoodです)
ちなみに、Engine Yardで利用できるDBMSは以下のとおりです。
  • MySQL
  • PostgreSQL
それではアプリケーションをデプロイしていきましょう。

SignUp,Application/Environmentの作成

サインアップは超簡単！こちら にアクセスして
『名前』『メールアドレス』『パスワード』を入力するダケ SignUp その後、ブラウザからログインして『Add an Application』から構築します。
ガイダンスに従っていけばOKなので説明は省きます。
今回はアプリケーション名を『cloudworks_de』、環境名を『development』としました。
Application | cloudworks_de Environment | development
途中で、Engine YardのSSH公開鍵が表示されるので
指示のとおり【GitHub】 → 【対象リポジトリ】 → 【Settings】 → 【Deploy Keys】に追加してください。

eyコマンドのインストール、初期設定

Engine YardはCLIからの操作が可能です。 
$ sudo gem install engineyard
プロンプトが表示されたら、Engine Yard アカウントのパスワードを入力します。
その後、Railsアプリケーションのconfigディレクトリ以下にey.ymlファイルを作成します。
(ファイルの内容はこちらを参照ください)

chef実行環境の構築

eyコマンドでは、とても簡単にchefのレシピが実行できます。
詳細はこちらを参考にして欲しいのですが
ここでは、実行したコマンドと簡単な説明の記載までとします。 参考ページでは、GitHubにForkする様に書かれていますが
今回は検証なのでローカルリポジトリのみとしています。 
$ cd ~/
$ git clone git@github.com:engineyard/ey-cloud-recipes.git
$ cd ey-cloud-recipes
$ rake new_cookbook COOKBOOK=cwde_app
これによって、cookbooks/cwde_app/recipes/default.rb ファイルが作成されます。
同ファイルを以下に様に編集します。 
#
# Cookbook Name:: cwde_app
# Recipe:: default
#
timezone = "Japan"
service "vixie-cron"
service "sysklogd"
service "nginx"

link "/etc/localtime" do
  to "/usr/share/zoneinfo/#{timezone}"
  notifies :restart, resources(:service => ["vixie-cron", "sysklogd", "nginx"]), :delayed
  not_if "readlink /etc/localtime | grep -q '#{timezone}$'"
end
内容としては、システムタイムゾーンをJapanに変更し
タイムゾーンの変更で影響を受けるサービスを再起動しています。 編集が終わったら、コミットしておきましょう。 
$ git add .
$ git commit -m "システムのタイムゾーンをJapanに変更します"
それでは、recipeの内容をアップロード → サーバーに適用しましょう。 
$ ey recipes upload -e development
$ ey recipes apply -e development
これでレシピが実行され、サーバのタイムゾーンが変更されました。

アプリケーションをデプロイする

これで環境は整ったので、アプリケーションをデプロイしてみましょう。
Railsアプリケーションディレクトリで以下のコマンドを実行します。 
$ ey deploy -a cloudworks_de -e development --ref develop --migrate "rake db:migrate"
(developの部分は、GitHubのブランチ名を指しています)

アプリケーションを開く

デプロイが終了したら、以下のコマンドでアプリケーションにアクセスしてみましょう。 
$ ey launch
ブラウザからアプリケーションへアクセスします。

まとめ

ここまで来るのに、何度か詰まって調べていたら
なんの前触れもナシにナカの人がチャットで声をかけてきてくれて
そこから一緒にデバッグして頂きました。 その品質はもちろんですが、サポートはユーザの問い合せから
やり取りが始まると思っていた僕には
逆のアプローチで問題が解決したコトにトテモ感動しました。 実際にアプリケーションをサービスとして利用するには、非同期処理のプロセスを起動したり
スケジューラを設定したり、メールの送信処理を見なおしたり…etc
とゴール(スタート？)は近くはありませんが
今回はサービスのトップページが表示されたってコトで
ここまでを、ひと区切りさせて頂きます。 僕の次回作にご期待ください。