Heroku の Ruby サポート

この記事の英語版に更新があります。ご覧の翻訳には含まれていない変更点があるかもしれません。

最終更新日 2024年05月31日(金)

Heroku は Ruby のさまざまな実装で Ruby アプリケーションを実行でき、フレームワーク固有のワークフローのためのサポートを備えています。

このドキュメントでは、Ruby アプリケーションの認識と実行に関連した Heroku の一般的な動作について説明します。フレームワーク固有のチュートリアルについては、次を参照してください。

全般的なサポート

デプロイされるすべての Ruby アプリケーションの種類に対して、次のサポートが提供されます。

アクティベーション

Heroku の Ruby サポートがアプリケーションに適用されるのは、アプリケーションのルートディレクトリに Gemfile​ がある場合だけです。アプリケーションに gem 依存関係がない場合であっても、アプリに gem 依存関係がないことを記載した空の Gemfile​ を含む必要があります。

デプロイされているアプリケーションの種類に応じて、次のセクションに記載されている特定のアクションが実行され、この動作は次の規則によって決定されます。

  • Gemfile​ がある場合は Ruby アプリケーションを示します
  • config.ru​ がある場合は Rack アプリケーションを示します
  • config/environment.rb​ がある場合は Rails 2 アプリケーションを示します
  • 文字列 Rails::Application​ を含む config/application.rb​ がある場合は Rails 3 アプリケーションを示します

ライブラリ

次のライブラリは Ruby アプリケーションを管理および実行するためのプラットフォームによって使用され、指定できません。アプリケーションの依存関係の解決および管理のために、Gemfile.lock​ の内容に基づいて Bundler がインストールされます。Gemfile.lock​内に BUNDLED WITH​ がある場合、別のバージョンの Bundler を受け取ります。

  • BUNDLED WITH​ 1.x は Bundler 1.17.3​ を受け取ります。
  • BUNDLED WITH​ 2.0.x ～ 2.3.x は Bundler 2.3.25​ を受け取ります。
  • BUNDLED WITH​ 2.4.x は Bundler 2.4.22​ を受け取ります。
  • BUNDLED WITH​ 2.5.x 以降は Bundler 2.5.6​ を受け取ります。

使用可能な設定について詳しくは、Bundler 設定​を参照してください。特定の Bundler バージョンのセットのみサポートする理由について詳しくは、Bundler のバージョン​に関する記事を参照してください。

環境

次の環境変数が設定されます。

  • GEM_PATH​ => vendor/bundle/#{RUBY_ENGINE}/#{RUBY_ABI_VERSION}
  • LANG​ => en-us
  • PATH​ => bin:vendor/bundle/#{RUBY_ENGINE}/#{RUBY_ABI_VERSION}/bin:/usr/local/bin:/usr/bin:/bin
  • DISABLE_SPRING​ => 1

GEM_PATH​ は bundler gem vendor ディレクトリに設定されます。

プロセスタイプ

次の 2 つのプロセスタイプはいつでも使用できます。

rake: bundle exec rake
console: bundle exec irb

ビルド動作

アプリケーションがデプロイされるとき、config​ ディレクトリと環境変数 RAILS_ENV​ または RACK_ENV​ が存在する場合、ビルドフェーズによって、基盤の Rack または Rail アプリケーションがプロビジョニング済みデータベースを使用するように設定されます。 Rails 4.1+ で使われる ActiveRecord 4.1 より前では、database.yml​ ファイルが作成されます。 database.yml​ファイルが存在する場合、ActiveRecord 4.1 でファイルが置換されます。 database.yml​ファイルは、DATABASE_URL​ 環境変数を構文解析することによって出力を動的に作成する Ruby コードとして作成されます。ActiveRecord 4.1+ では、DATABASE_URL​ サポートが組み込まれています。詳しくは、データベース接続の設定​ およびDATABASE_URL サポートを追加したプルリクエスト​を参照してください

ビルドの最後に、アプリケーションは rails runner​ インターフェースを使用して、潜在的に問題のあるアプリケーション設定がないかチェックされます。

JRuby

JRuby の場合、環境変数 JRUBY_BUILD_OPTS​ を設定することによってビルド中に JVM に渡されるオプションをカスタマイズできます。一般的な値は --dev​ で、これは Bundler および Rake によって実行されるもののような短いプロセスのランタイムを最適化します。

Ruby バージョン

Heroku では多数の異なる Ruby 実装を使用できます。特定のランタイムを選択するようアプリを設定できます。

新しいアプリについての Ruby のデフォルトバージョン

Gemfile​ に ruby​ エントリがない場合、MRI 3.1.4​ が取得されます。

Ruby のバージョンを指定しない限り、デフォルトの Ruby がアプリに組み込まれています。 たとえば、アプリでデフォルトの Ruby バージョン 3.0.3​ を使用している場合、3.0.3​ が維持されます。

Gemfile で Ruby バージョンを指定し、デフォルトの Ruby バージョンに依存しないようにすることを強くお勧めします。

サポートされているランタイム

Heroku では、次の Ruby バージョンおよび関連する Rubygem がサポートされています。サポートされているバージョンとは、Heroku のツールおよびプラットフォームが所定のバージョンと連動することを期待できることを意味します。また、技術サポートを受けられることも意味します。サポートされている Ruby のバージョンは次のとおりです。

MRI:

  • 3.1.6​、Rubygems: ​3.3.27
  • 3.2.4​、Rubygems: ​3.4.19
  • 3.3.2​、Rubygems: ​3.5.9

ある Ruby のバージョンが EOL を迎えると、セキュリティパッチが入手できなくなります。Ruby のコアによって積極的にサポートされている Ruby のバージョンを実行することを強くお勧めします。

JRuby:

  • 9.1.17.0​、Ruby のバージョン: [2.3.3​]
  • 9.2.21.0​、Ruby のバージョン: [2.5.8​]
  • 9.3.14.0​、Ruby のバージョン: [2.6.8​]
  • 9.4.7.0​、Ruby のバージョン: [3.1.4​]

JRuby バージョンは、一覧で示す複数の Ruby バージョンをサポートしています。Gemfile でバージョンを指定する必要があります。JRuby は、JRuby と一緒にインストールされている JVM 上で実行します。サポートされている Java バージョンの一覧および特定のバージョンを設定する方法については、Java サポート記事​を参照してください。

JVM 環境および使用可能な JVM オプション (JAVA_TOOL_OPTIONS​ など) について詳しくは、Heroku の Dev Center の Java サポート​を参照してください。

Zulu JDK の使用や jmap​ の実行などの高度な JDK オプションについては、アプリの最初の buildpack として heroku/jvm​ buildpack を追加する​必要があります。

ランタイムの選択

Ruby バージョンを指定する方法についての説明は、Ruby バージョン​を参照してください。

アプリが使用する Ruby ランタイム は slug​ に含められ、slug のサイズ​に影響します。

Ruby JIT のサポート

JIT は「Just in Time (実行時)」コンパイラの略です。JIT インプリの目的は、より効率的なコードを提供してプログラムの実行を高速化することです。通常は Ruby コードをマシンコードにコンパイルします。JIT を使用するとメモリ消費量が増加します。また、すべてのプログラムが必ず高速化するわけではありません。使用する JIT インプリがアプリコードに適していない場合、JIT を使用するとアプリケーションの速度が低下する可能性があります。

MJIT

Ruby では、Ruby 2.6 で MJIT が導入され、Ruby 3.1 で YJIT が導入されました。MJIT は Heroku で動作しますが、多くの実際のアプリケーションでは速度が向上しないため、推奨されません。

YJIT

YJIT のほうがアプリケーションを高速化できる可能性が高くなっています。Ruby アプリケーションで YJIT を有効にするには、次のコマンドを実行します。

$ heroku config:set RUBYOPT="--enable-yjit"

次に、以下を実行して機能したことを確認します。

$ heroku run bash
~ $ irb
irb(main):001:0> puts RubyVM::YJIT.runtime_stats
{:inline_code_size=>488880, :outlined_code_size=>404622}

サポートされていない Ruby バージョン

以下に、スタックごとに存在するランタイムバージョンの一覧を示します。EOL バージョンは Ruby コアから更新を受け取らなくなったので、Heroku Ruby サポートポリシーの対象ではありません。

  • heroku-20​ スタック上:

    • 2.5.x (EOL): ​2.5.7​ ～ 2.5.9
    • 2.6.x (EOL): ​2.6.6​ ～ 2.6.9
    • 2.7.x (EOL): ​2.7.1​ ～ 2.7.8
    • 3.0.x (EOL): ​3.0.0​ ～ 3.0.7
    • 3.1.x: ​3.1.0​ ～ 3.1.4
    • 3.2.x: ​3.2.0​ ～ 3.2.3
    • 3.3.x: ​3.3.0

  • heroku-22​ スタック上:

    • 3.1.x: ​3.1.0​ ～ 3.1.4
    • 3.2.x: ​3.2.0​ ～ 3.2.3
    • 3.3.x: ​3.3.0

つまり、2.5.9 は Heroku-20 スタックでは「サポート対象外」ですが、ご自身の責任で引き続き使用できることを意味します。Heroku では、サポートされている Ruby バージョンを使用することを常にお勧めします。

Rails などのライブラリのバージョンが、サポートされている Ruby バージョンで機能しない場合、Rails LTS​ などのサービスを使用できます。Rails LTS は、古いリリースの維持管理されたバージョンを有料で提供します。Rails LTS プロジェクトは Heroku や Rails Core​ と提携していません。

Rails バージョンのサポート

Heroku での Rails バージョンのサポートには、Rails Core バージョンのサポート​が反映されています。Heroku では、古い Rails バージョンの利用を停止していません。つまり、プラットフォームに今までデプロイ可能だったすべての Rails バージョンが、現在のプラットフォームでも引き続き使用できることを意味します。1 つの制限事項として、ある特定のスタックで使用可能な最も古い Ruby バージョン​上で、古いバージョンの Rails が動作することを約束できないということがあります。

たとえば、Rails 3.2 が Ruby 2.4.10 以上で実行できない場合、Rails 3.2 アプリケーションを Heroku-18 スタックで実行することはできません。Heroku は、Ruby と Rails 間のバージョン互換性情報を維持管理していません。

Rails などのライブラリのバージョンが、サポートされている Ruby バージョンで機能しない場合、Rails LTS​ などのサービスを使用できます。Rails LTS は、古いリリースの維持管理されたバージョンを有料で提供します。Rails LTS プロジェクトは Heroku や Rails Core​ と提携していません。

Rails Core の正式にサポートされているバージョンや、LTS のサポートされているバージョンを使用していない場合、アプリケーションにはパッチが適用されておらずセキュリティ上の脆弱性​がある可能性があります。正式にサポートされている Rails バージョンを常に使用することをお勧めします。

Ruby アプリケーション

純粋な Ruby アプリケーション (headless プロセスや Goliath などのイベント型 Web フレームワーク) は Heroku で完全にサポートされています。

アクティベーション

デプロイされたアプリケーションが純粋な Ruby アプリケーションとして認識された場合、Heroku は -----> Ruby app detected​ と応答します。

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

アドオン

2023 年 5 月 15 日​より前にアカウントを作成した場合または、Heroku サポートに、アカウントの Heroku Postgres 自動プロビジョニングを有効にするように依頼した​場合は、「Ruby データベースの自動プロビジョニング​.」を参照してください。

プロセスタイプ

純粋な Ruby アプリケーションが検出された場合、デフォルトの web​ プロセスタイプは作成されません。

Rack アプリケーション

Rack アプリケーションは Ruby アプリケーションのように動作することに加えて次のような動作があります。

アクティベーション

ルートレベルの config.ru​ ファイルは Rack アプリケーションの存在を指定します。Rack アプリとして認識されるアプリケーションには、デプロイ時に -----> Ruby/Rack app detected​ が表記されます。

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

環境

次の追加の環境変数が設定されます。

  • RACK_ENV​ => “production”

アドオン

純粋な Ruby アプリ​と同じアドオンを追加します。

プロセスタイプ

Procfile​ を含めない場合、Rack アプリはデプロイ時に Web プロセスタイプを定義します。

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

Heroku の場合、Web サーバーには Puma をお勧めします​。選択した Web サーバーには関係なく、常に本番環境のアプリでは Procfile​ に明示的に Web サーバーを指定します。

Bamboo から移行する特殊な場合として、thin​ gem をバンドルする Ruby アプリは次の Web プロセスタイプを取得します。

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

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

アクティベーション

Gemfile.lock​ ファイルに rails​ gem が含まれており、gem のバージョンが 2.0.0 以上かつ 3.0.0 未満の場合、アプリは Rails 2.x として検出されます。 Rails 2.x アプリとして認識されるアプリには、デプロイ時に -----> Ruby/Rails app detected​ が表記されます。

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

環境

次の追加の環境変数が設定されます。

  • RAILS_ENV​ => “production”
  • RACK_ENV​ => “production”

アドオン

純粋な Ruby アプリ​と同じアドオンを追加します。

プロセスタイプ

Procfile​ を含めない場合、Rails 2 アプリはデプロイ時に Web プロセスタイプを定義します。

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

Heroku の場合、Web サーバーには Puma をお勧めします​。選択した Web サーバーには関係なく、常に本番環境のアプリでは Procfile​ に明示的に Web サーバーを指定します。

Bamboo から移行する特殊な場合として、thin​ gem をバンドルする Ruby アプリは次の Web プロセスタイプを取得します。

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

Rails 2 についての追加のプロセスタイプが宣言されます。

console: bundle exec script/console

さらにアプリに jobs:work​ Rake タスクがある場合は、次が指定されます。

worker: bundle exec rake jobs:work

Rails 2 のプラグインインジェクション

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

アクティベーション

Gemfile.lock​ ファイルに railties​ gem が含まれており、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”

アドオン

純粋な Ruby アプリ​と同じアドオンを追加します。

プロセスタイプ

Procfile​ を含めない場合、Rails 3 アプリはデプロイ時に Web およびコンソールのプロセスタイプを定義します。

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

Heroku の場合、Web サーバーには Puma をお勧めします​。選択した Web サーバーには関係なく、常に本番環境のアプリでは Procfile​ に明示的に Web サーバーを指定します。

Bamboo から移行する特殊な場合として、thin​ gem をバンドルする Ruby アプリは次の Web プロセスタイプを取得します。

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

コンパイルフェーズ

コンパイルフェーズの最後のタスクとして、assets:precompile​ Rake タスクが実行されます。このタスクはすべてのアセットをコンパイルして公開ディレクトリに配置します。詳細については、「Heroku での Rails アセットパイプライン​」を参照してください。

Rails 3 のプラグインインジェクション

rails_12factor​ gem を含めた場合、プラグインインジェクションはまったく実行されません。すべての設定は gem を介して行われます。重複するログが表示される原因となる開発環境でのバグを避けるために、この gem を :production​ グループに配置します。このバグは後のバージョンの Rails で修正されています​。

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

アクティベーション

Gemfile.lock​ ファイルに railties​ gem が含まれており、gem のバージョンが 4.0.0 ベータ以上かつ 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”

アドオン

純粋な Ruby アプリ​と同じアドオンを追加します。

プロセスタイプ

Procfile​ を含めない場合、Rails 4 アプリはデプロイ時に Web およびコンソールのプロセスタイプを定義します。

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

Heroku の場合、Web サーバーには Puma をお勧めします​。選択した Web サーバーには関係なく、常に本番環境のアプリでは Procfile​ に明示的に Web サーバーを指定します。

コンパイルフェーズ

assets:precompile​ Rake タスクが定義されていて、public/assets/manifest-*.json​ ファイルがない場合、コンパイルフェーズの最後のタスクとして、assets:precompile​ Rake タスクが実行されます。このタスクはすべてのアセットをコンパイルして公開ディレクトリに配置します。Rake 検出またはアセットコンパイルのタスクが失敗した場合、デプロイも失敗します。 詳細については、「Heroku での Rails アセットパイプライン​」を参照してください。

Rails 4 のプラグインインジェクション

Rails 4 はプラグイン機能をサポートしなくなったため、Heroku の Rails 4 のサポートによる挿入は行われません。 ただし、rails_12factor​ gem を含めない場合、警告が発生します。 この gem はプラグインの必要性に取って代わるもので Rails 4 が Heroku 上で実行するために最適に設定されるようになります。

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

アクティベーション

Gemfile.lock​ ファイルに railties​ gem が含まれており、gem のバージョンが 5.0.0 ベータ以上かつ 6.0.0 未満の場合、アプリは Rails 5.x として検出されます。Rails 5.x アプリとして認識されるアプリには、デプロイ時に -----> Ruby/Rails app detected​ が表記されます。

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

環境

次の追加の環境変数が設定されます。

  • RAILS_ENV​ => “production”
  • RACK_ENV​ => “production”
  • RAILS_LOG_TO_STDOUT​ => “enabled”
  • RAILS_SERVE_STATIC_FILES​ => “enabled”

アドオン

純粋な Ruby アプリ​と同じアドオンを追加します。

プロセスタイプ

Procfile​ を含めない場合、Rails 5 アプリはデプロイ時に Web およびコンソールのプロセスタイプを定義します。

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

選択した Web サーバーには関係なく、常に本番環境のアプリでは Procfile​ に明示的に Web サーバーを指定します。

コンパイルフェーズ

assets:precompile​ Rake タスクが定義されていて、public/assets/manifest-*.json​ ファイルがない場合、コンパイルフェーズの最後のタスクとして、assets:precompile​ Rake タスクが実行されます。このタスクはすべてのアセットをコンパイルして公開ディレクトリに配置します。Rake 検出またはアセットコンパイルのタスクが失敗した場合、デプロイも失敗します。 詳細については、「Heroku での Rails アセットパイプライン​」を参照してください。

Rails 5 のプラグインインジェクション

Rails 5 はプラグイン機能をサポートしなくなったため、Heroku の Rails 5 のサポートによる挿入は行われません。以前の Rails 4 では、ロギングおよび静的ファイルサービスを有効化するために gem rails_12factor​ が必要でした。新しいアプリケーションはそのまますぐに動作します。アプリケーションをアップグレードする場合、「Heroku スターターガイド (Rails 5.x)​」を参照してください。

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

Rails 5.x アプリケーション​と同じです

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

Rails 6.x アプリケーション​と同じです

Node.js のサポート

多くの Ruby アプリケーションでは Node エコシステムのツールを使用してフロントエンドのアセットを生成します。これらのアプリケーションをサポートするために、Heroku では heroku/nodejs​ buildpack を heroku/ruby​ buildpack より前に配置し、Node の依存関係をインストールすることを推奨しています。この順序を確認するには、次のコマンドを実行します。

$ heroku buildpacks
=== polar-inlet-4930 Buildpack URLs

1. heroku/nodejs
2. heroku/ruby

アプリケーションが heroku/nodejs​ buildpack を使用していない場合は、次のコマンドで追加できます。

$ heroku buildpacks:add heroku/nodejs -i 1

次に、heroku buildpacks​ を再度実行して、heroku/nodejs​ が heroku/ruby​ より前にあることを確認します。インストールされた Node と Yarn のバージョンを、ご使用のアプリケーション向けに heroku/nodejs​ buildpack でカスタマイズするには、それらを package.json​ ファイルで指定します。次に例を示します。

{
  "engines": {
    "node": "20.9.0",
    "yarn": "1.22.19"
  }
}

インストールされている Node バージョンの設定についての詳細は、Dev Center の「Heroku の Node.js サポート​」記事を参照してください。

アプリケーションが heroku/nodejs​ buildpack を使用していないのにアプリケーションのルートに execjs​ gem または package.json​ ファイルがある場合、Ruby buildpack は Node のデフォルトバージョンをインストールします。webpacker​ gem または yarn.lock​ ファイルがある場合は、アプリは Yarn のバージョンを受け取ります。

Node.js buildpack が使用されていない場合、heroku/ruby​ でインストールされるバージョンは次のとおりです。

  • Node: 20.9.0
  • Yarn: 1.22.19

デフォルトのバージョンは時間と共に変わるため、この動作に長期的に頼ることはお勧めしません。アプリケーションの Node または Yarn のバージョンを制御するには、heroku/nodejs​ buildpack をアプリケーションに追加する必要があります​。

インストールされるバイナリ

Ruby バイナリとそれに付属するデフォルトのツール (Rubygems や Bundler など) に加えて、一部のアプリケーションでは、アプリケーションを実行するために追加のバイナリが必要です。Heroku ではこのような依存関係をインストールするには明示的な buildpack を使用することを強く推奨していますが、heroku/ruby​ buildpack が追加のバイナリをインストールする場合もあります。このセクションでは、インストールされるバイナリとその条件を紹介します。

アプリケーションのルートに package.json​ があり、過去の node​ バイナリがパス上に見つからない場合、Ruby buildpack は Node.js のデフォルトバージョンをインストールします。詳細は、heroku/ruby​ の Node.js のサポートセクション​を参照してください。yarn.lock​ ファイルがアプリケーションのルートにあり、過去の yarn​ バイナリがパス上に見つからない場合、Yarn のバージョンがインストールされます。詳細は、heroku/ruby​ の Node.js のサポートセクション​を参照してください。

挿入されたプラグイン

デフォルトでは、アプリケーションが Heroku プラットフォームを最大限に活用できるようにするために、Heroku は Rails 3.x アプリケーションのプラグインを挿入します。 挿入可能な 2 つのプラグインは、rails_stdout_logging​ と rails3_serve_static_assets​ です。Rails 3 でこれらが挿入されることを防ぐには、アプリケーションの Gemfile に rails_12factor​ gem を含めます。

gem 'rails_12factor'

Stdout

rails_stdout_logging​ gem によって、ログは標準出力に確実に送信されます。

Heroku ではログはファイルではなく、イベントのストリームとして​扱われます。ログを stdout にパイプすることで、ログは Logplex​ によって複数の dyno から取り込まれて統合され、それによりログはコマンドライン $ heroku logs --tail​ またはロギングアドオン​から利用できるようになります。

静的アセット

rails3_serve_static_assets​ gem により、Web プロセスは静的アセットを処理できます。

デフォルトの Rails 開発環境では、アセットは sprockets​ と呼ばれるミドルウェアを介して処理されます。ただし本番環境で、Heroku 以外のほとんどの Rails デプロイメントでは、サイトのロードバランシングを行い静的ファイルを直接処理できる Nginx などの HTTP リバースプロキシサーバーの背後に Ruby サーバーを設置します。Nginx は /assets/rails.png​ などのアセットのリクエストを認識すると、ディスクの /public/assets/rails.png​ からアセットを取得して処理します。Rails サーバーはリクエストを認識しません。

Heroku では、アプリケーションの実行に Nginx は必要ありません。水平にスケールアウトするとき、Heroku のルーティングレイヤ​がロードバランシングを処理します。使用するアプリケーションがエッジキャッシュ CDN​ を通じて静的アセットを処理する場合、Nginx のキャッシュ動作は必要ありません。

デフォルトでは、アセットが Nginx などの外部プロキシを介して処理されない場合、Rails 4 は 404 を返します。このデフォルトの動作は Nginx 設定のデバッグに役立ちますが、アセットを持つデフォルトの Rails アプリが Heroku 上で使用できなくなります。これを修正するために、gem rails_serve_static_assets​ が公開されています。

この rails_serve_static_assets​ という gem により、Rails サーバーは 404 を返す代わりにアセットを配信できるようになります。この gem を使用して、エッジキャッシュ CDN に入力したり、Web アプリからファイルを直接提供したりすることができます。この gem により、アプリによる完全な制御が可能になり、リダイレクトや Ruby コードのヘッダーの設定などができるようになります。この動作をアプリで有効にするには、次に示す 1 つの設定オプションを設定します。

config.serve_static_assets = true

この設定は gem が実行するため、このオプションを設定する必要はありません。これで、アセットの処理方法をアプリケーションが制御できるようになります。

デバッガ gem のインストールの失敗

実行先の Ruby の特定のパッチレベルを必要とする gem がいくつか存在します。このことにより、Ruby の特定のパッチレベルに固定され、セキュリティ修正を受け取るようにアップグレードできなくなるため、本番アプリにとって不利益となります。

Heroku では、Ruby バージョンのセキュリティパッチが Ruby コアから使用できるようになると、セキュリティパッチがリリースされます。Ruby バージョンをアップグレードした後、アプリは次回デプロイ時に新しいバージョンを取得します。アプリがこれらのいずれかの gem を使用していた場合、使用中の Ruby のバージョンをアップグレードすると、gem をインストールするときにエラーが表示されます。エラーは次のように表示されることがあります。

Installing debugger-linecache
Gem::Installer::ExtensionBuildError: ERROR: Failed to build gem native extension.

あるいは、次のように表示されます。

Installing debugger
Gem::Installer::ExtensionBuildError: ERROR: Failed to build gem native extension.

この問題を回避する最も良い方法は、debugger​ またはその他のデバッグ用 gem を本番環境で使用しないことです。これらの gem は、実行中のコードを動的に停止して検査するために、言語の低レベルコンポーネントに接続するように設計されています。debugger​を本番環境にインストールしないでください。その代わりに、これらの gem を Gemfile​ の development​ グループに移動します。

group :development do
  gem "debugger"
end

その後、bundle install​ を実行し、Git にコミットして再デプロイします。