ruby support - herokaijp/devcenter GitHub Wiki

Heroku Cedar stackは、Rubyの多種多様なランタイムに渡りRubyアプリケーションを実行することが可能であり、フレームワークに特化したワークフローをサポートします。

このドキュメントは、Rubyアプリーケーションの承認と実行に関わるCedar stackの一般的な動作について記述しています。フレームワークに特化したチュートリアルは、こちらを参照して下さい。:

• Getting Started with Ruby on Heroku/Cedar
• Getting Started with Rails 3.0 on Heroku/Cedar.

一般的なサポート

ディプロイされたRubyアプリケーションの種類を問わず、以下のサポートが提供されます。

アクティベーション

HerokuのRubyサポートは、rootディレクトリにGemfileを管理しているアプリケーションの場合にのみ適用されます。たとえ、アプリケーションがGemを一つも使っていなかったとしても、アプリケーションがGemを使っていないことを記述した空のGemfileを含める必要があります。

以降の項に記述されている個々のアクションは、ディプロイされたアプリケーションのタイプに依存し、以下のようなルールで決定されます:

• Gemfileが存在する場合、Rubyアプリケーションであることを示します。
• config.ruが存在する場合、Rackアプリケーションであることを示します。
• config/environment.rbが存在する場合、Rails 2のアプリケーションであることを示します。
• Rails::Applicationという文字列を含むconfig/application.rbが存在する場合、Rails 3のアプリケーションであることを示します。

ライブラリ

以下のライブラリがRubyのアプリケーションを管理、実行するためのプラットフォームとして使われます。他のバージョンを指定することは出来ません。

• Bundler v1.3.2: アプリケーション依存の解決と管理

環境

以下の環境変数がセットされるでしょう。:

• GEM_PATH => "vendor/bundle/1.9.1"
• LANG => "en-us"
• PATH => "bin:vendor/bundle/1.9.1/bin:/usr/local/bin:/usr/bin:/bin"

GEM_PATHは、bundlerのgem vendorディレクトリにセットされます。

プロセスタイプ

以下の2つのプロセスタイプは、常に利用可能となっています。:

rake: bundle exec rake
console: bundle exec irb

構築時の挙動

アプリケーションのディプロイ時、仮に、configディレクトリが存在し、RAILS_ENVまたは、RACK_ENVの環境変数が設定されているのであれば、供給されたデータベースを使うよう、構築フェーズでは、基礎的なRackやRailsアプリケーションを設定します。これらの状況下では、database.ymlファイルが作成されます。もし、database.ymlが既に存在するのであれば、置き換えされます。database.ymlファイルは、DATABASE_URLの環境変数をパースすることで、動的にアウトプットを作成するRubyコードとして生成されます。

Rubyのバージョン

それぞれのRubyのバージョンに対してパッチレベルで最新の利用可能な物が適応されます。もしGemfileにrubyについて書かれていない場合、MRIである2.0.0が適応されます。デフォルトのRubyは、あなたがRubyのバージョンについて明示するまでロックされます。もし前に1.9.2が適応されていたならば、引き続き1.9.2が使われます。

Rubyのバージョンの指定の仕方として、Rubyバージョンのドキュメントを確認してみてください。

Herokuは以下のRubyのバージョンとそれにひもづくRubygemsをサポートしています:

MRI:

• 1.8.7 : patchlevel 374, Rubygems : 1.8.24
• 1.9.2 : patchlevel 320, Rubygems: 1.3.7.1
• 1.9.3 : patchlevel 448, Rubygems : 1.8.23
• 2.0.0 : patchlevel 247, Rubygems : 2.0.3

JRuby:

JRubyのバージョンは1.8.7と1.9.3のrubyバージョンを含んでいます。Gemfileの中で一つを指定する必要があります。

• 1.7.1
• 1.7.2
• 1.7.3
• 1.7.4

あなたのアプリケーションが使用するルビーの実行系はあなたのスラッグに含まれ、スラッグのサイズに影響します。

Rubyアプリケーション

ヘッドレスプロセスでかつ、イベント駆動型のフレームワークであるGoliathのような、ピュアRubyアプリケーションがCedarでは完全にサポートされています。

アクティベーション

ディプロイされたアプリケーションが、ピュアRubyアプリケーションであると認識された場合、Herokuは、-----> Ruby app detectedを返します。

$ git push heroku master
-----> Ruby app detected

アドオン

Rubyアプリケーションが、Gemfile内にpgのGemを管理していた場合、シェアードデータベースのアドオンが供給されます。これは、DATABASE_URLの環境変数に格納されます。

プロセスタイプ

ピュアRubyのアプリケーションが検知された場合、デフォルトのwebプロセスタイプが生成されることはありません。

Rackアプリケーション

Rackアプリケーションは、以下に記載する通り、Rubyアプリケーションのように動作します。

アクティベーション

rootレベルのconfig.ruファイルは、Rackアプリケーションの存在を明確にします。Rackアプリであると認識されたアプリケーションは、ディプロイ時に、-----> Ruby/Rack app detectedと明示されます。

$ git push heroku master
-----> Ruby/Rack app detected

環境

以下の環境変数が追加でセットされます。:

• RACK_ENV => "production"

アドオン

Rackアプリケーションが、Gemfile内にpgのGemを管理していた場合、シェアードデータベースのアドオンが供給されます。これは、DATABASE_URLの環境変数に格納されます。

プロセスタイプ

もしProcfileを含めていなかった場合、Rackアプリケーションはデプロイ時にwebプロセスを定義します :

web: bundle exec rackup config.ru -p $PORT

callout Cedarでは、UnicornをWebサーバとして推奨します。あなたの選んだウェブサーバに関係なく、いつでもプロダクション環境のアプリケーションではProcfile内に明示的にWebサーバを指定するべきです。

Bambooからの移行をしやすくするための特別なケースとして、thin Gemを含んでいるRubyのアプリケーションはこのWebプロセスタイプが適応されます:

web: bundle exec thin start -R config.ru -e $RACK_ENV -p $PORT

Rails 2.x アプリケーション

アクティベーション

config/environment.rbファイルを含むアプリケーションは、Rails 2のwebアプリとして扱われます。Rails 2.xのアプリとして認識されたアプリケーションは、ディプロイ時に、-----> Ruby/Rails app detectedと明示されます。

$ git push heroku master
-----> Ruby/Rails app detected

環境

以下の環境変数が追加でセットされます。:

• RAILS_ENV => "production"
• RACK_ENV => "production"

アドオン

シェアードデータベースのアドオンが供給されます。これは、DATABASE_URLの環境変数に格納されます。

プロセスタイプ

もしProcfileを含めていなかった場合、Rails2アプリケーションはデプロイ時にwebプロセスを定義します :

web: bundle exec ruby script/server -p $PORT

callout Cedarでは、UnicornをWebサーバとして推奨します。あなたの選んだウェブサーバに関係なく、いつでもプロダクション環境のアプリケーションではProcfile内に明示的にWebサーバを指定するべきです。

Bambooからの移行をしやすくするための特別なケースとして、thin Gemを含んでいるRubyのアプリケーションはこのWebプロセスタイプが適応されます:

web: bundle exec thin start -e $RAILS_ENV -p $PORT

追加で二つのプロセスタイプがRails2向けに宣言されます :

worker: bundle exec rake jobs:work
console: bundle exec script/console

Rails 2 アプリケーションに対するプラグインの追加

• Rails標準出力plugin が追加されます.

Rails 3.x アプリケーション

アクティベーション

Gemfile.lockファイルがrailtiesGemを含んでおり、そしてGemのバージョンが3.0.0以上、4.0.0未満だった場合にアプリケーションは Rails 3.xアプリケーションとして検出されます。Rails 3.x系として認識されたアプリは、ディプロイ時に、-----> Ruby/Rails app detectedと明示されます。

$ git push heroku master
-----> Ruby/Rails app detected

環境

以下の環境変数が追加でセットされます :

• RAILS_ENV => "production"
• RACK_ENV => "production"

アドオン

シェアードデータベースのアドオンが供給されます。これは、DATABASE_URLの環境変数に格納されます。

プロセスタイプ

もしProcfileを含めていなかった場合、Rails3アプリケーションはデプロイ時にwebプロセスタイプとconsoleプロセスタイプを定義します :

web: bundle exec rails server -p $PORT
console: bundle exec rails console

callout Cedarでは、UnicornをWebサーバとして推奨します。あなたの選んだウェブサーバに関係なく、いつでもプロダクション環境のアプリケーションではProcfile内に明示的にWebサーバを指定するべきです。

Bambooからの移行をしやすくするための特別なケースとして、thin Gemを含んでいるRubyのアプリケーションはこのWebプロセスタイプが適応されます:

web: bundle exec thin start -R config.ru -e $RACK_ENV -p $PORT

コンパイルのフェーズ

コンパイルフェーズの最終タスクとして、assets:precompileのRakeタスクが実行されます。これは、全てのアセットをコンパイルし、publicディレクトリへ格納します。より詳細な情報は、こちらを参照して下さい。Rails Asset Pipeline on Heroku Cedar

Rails3アプリケーションに対するプラグインの追加

• A Rails標準出力plugin が追加されます。
• A 静的アセットプラグイン が自動的に追加されます。

もしrails_12factorGemを含めているならば、プラグインの追加は発生しません。すべての設定はGemを経由して行われます。

Rails 4.x アプリケーション

アクティベーション

Gemfile.lockファイルがrailtiesGemを含んでおり、そしてGemのバージョンが4.0.0.beta以上、5.0.0未満だった場合にアプリケーションは Rails 4.xアプリケーションとして検出されます。Rails 4.x系として認識されたアプリは、ディプロイ時に、-----> Ruby/Rails app detectedと明示されます。

$ git push heroku master
-----> Ruby/Rails app detected

環境

以下の環境変数が追加でセットされます :

• RAILS_ENV => "production"
• RACK_ENV => "production"

アドオン

データベースのアドオンが供給されます。これは、DATABASE_URLの環境変数に格納されます。

プロセスタイプ

もしProcfileを含めていなかった場合、Rails4アプリケーションはデプロイ時にwebプロセスタイプとconsoleプロセスタイプを定義します :

web: bundle exec bin/rails server -p $PORT -e $RAILS_ENV
console: bundle exec bin/rails console

callout Cedarでは、UnicornをWebサーバとして推奨します。あなたの選んだウェブサーバに関係なく、いつでもプロダクション環境のアプリケーションではProcfile内に明示的にWebサーバを指定するべきです。

コンパイルのフェーズ

コンパイルフェーズの最終タスクとして、もしassets:precompileRakeタスクを定義していて、public/assets/manifest-*.jsonファイルがない場合にassets:precompileのRakeタスクが実行されます。これは、全てのアセットをコンパイルし、publicディレクトリへ格納します。もしアセットコンパイルが失敗した場合、デプロイも同じように失敗します。より詳細な情報は、こちらを参照して下さい。Rails Asset Pipeline on Heroku Cedar

Rails4に対するプラグインの追加

Rails4はプラグイン機能をサポートしておりません、そしてまたHerokuのRails4では今後も何も追加しません。しかしながら、もしrails_12factorGemを含めていない場合は、警告が表示されます。このGemはプラグインで必要としていたことの代わりとなり、Rails4が最適化されてHeroku上で実行される事を確かにします。

追加されるプラグイン

デフォルトでは、HerokuはRails 3.xに対してプラグインを追加し、Herokuプラットフォーム外のほとんどのものを確かにします。ドキュメントの以下に書かれている二つのプラグインが追加されます。この追加をRails3でさける場合には、rails_12factorGemをあなたのアプリケーション内に含めてください。 Gemfileは以下のようになります :

gem 'rails_12factor'

Stdout

rails_stdout_logging Gemはあなたのログが標準出力に送られる事を確かにします。

Herokuはログをファイルとしてでなく、イベントのストリームとして扱います。標準出力へログをつなげる事によって、ログはLogplexを使って複数のDynoをわたって細くされ、固められます。Logplexはコマンドラインから、 $ heroku logs --tail や ログのアドオンから利用可能です。

Static assets

rails3_serve_static_assets GemはWebプロセスが静的なアセットを提供できるようにします。

デフォルトのRailsの開発環境では、アセットはsprocketsと呼ばれるミドルウェアを通して提供されます。プロダクション環境でしかしながら、HerokuでないほとんどのRailsアプリケーションのデプロイでは、それらをNginxの様な、ロードバランサとなりならが、静的なファイルを直接提供できるリバースプロキシサーバの後ろに置かれます。Nginxが/assets/rails.pngのようなアセットに対するリクエストを見たとき、ディスクの/public/assets/rails.pngからこれを取得し、提供します。Railsサーバは一切このリクエストについて知る事はありません。

Herokuでは、Nginxがあなたのアプリケーションで走る必要がありません。私たちのルーティングレイヤが横にスケールしている間もロードバランシングの面倒をみてくれます。アプリケーションが静的なアセットをエッジキャッシングCDNを通して提供している場合、Nginxのキャッシュの振る舞いは必要ありません。

デフォルトではRails4は、アセットがNginxのような外部プロキシを経由して管理されていない場合に404を返します。このデフォルトの振る舞いがNginxの設定のデバッグをやりやすくしてくれると同時に、Heroku上ではRailsアプリケーションのアセットを利用出来ない物にしてしまいます。これを直すために、私たちはrails_serve_static_assetsGemをリリースしました。

このrails_serve_static_assetsGemはあなたのRailsサーバがあなたのアセットを404を返してしまう代わりに、提供できるようにしてくれます。エッジキャッシュCDNを生成したり、あなたのWebアプリケーションからファイルディレクトリを提供するのにこれを使う事が出来ます。これはあなたのアプリケーションに対して完全なコントロールを与え、リダイレクトやヘッダの設定をRubyのコード内で行えるようにしています。この振る舞いを、あなたのアプリケーション内で使えるようにするために、この一つのオプションを設定する必要があります :

config.serve_static_assets = true

このGemがする事がこれであるため、このオプションを設定する必要はありません。今これで、あなたのアプリケーションはどうやってアセットを提供するかという事についてコントロールできるようになりました。