Docs header transparent bg

バンドルされたアプリケーションのデプロイ方法

Bundlerを使用するアプリをデプロイする前に、GemfileGemfile.lockをソース管理に追加してください。ただし、.bundleフォルダは各マシンに固有なので無視してください。

$ echo ".bundle" >> .gitignore
$ git add Gemfile Gemfile.lock .gitignore
$ git commit -m "Add Bundler support"

それが完了したら、Bundlerを使用してデプロイする方法は手動と自動の2つがあります。

手動デプロイ

デプロイスクリプトで、最新のコードに更新した後、すべての依存関係が満たされていることを確認して、バンドルをvendor/bundleディレクトリにインストールします。

$ bundle install --deployment

通常どおりにアプリケーションサーバーを起動すると、開発で使用するのとまったく同じgemを使用して、アプリケーションはバンドルされた環境を使用します。

bundle packageを実行した場合は、キャッシュされたgemが自動的に使用されます。

詳細: パッケージング

Capistranoを使用した自動デプロイ

Bundler Capタスクを組み込むには、deploy.rbファイルにこれを追加するだけです

require 'bundler/capistrano'

以上です! cap deployを実行すると、デプロイに適したオプションを使用してリモートサーバーでbundle installが自動的に実行されるようになります。変更可能なオプションのリストは、capタスクのヘルプにあります。表示するには、cap -e bundle:installを実行します。

Vladを使用した自動デプロイ

デフォルトのVladタスクが利用可能です。利用できるようにするには、Vladのdeploy.rbに次の行を追加します。

require 'bundler/vlad'

それが完了すると、vlad:bundle:installタスクが使用可能になります。デプロイの一部として実行されていることを確認してください。たとえば

task "vlad:deploy" => %w[
  vlad:update vlad:bundle:install vlad:start_app vlad:cleanup
]

デプロイ後

バンドル内のgemから実行可能ファイルを実行するには、必ずbundle execを使用してください

$ bundle exec rake db:setup

または、インストールコマンドで--binstubsオプションを使用して、bundle execの代わりに使用できる実行可能バイナリを生成することもできます。

詳細: 実行可能ファイル

Heroku

Herokuにデプロイすると、Gemfileが存在する限り、Bundlerは自動的に実行されます。Gemfile.lockをチェックインすると、Herokuはbundle install --deploymentを実行します。--withoutオプションを使用して特定のグループを除外する場合は、heroku configを使用する必要があります。

$ heroku config:set BUNDLE_WITHOUT="test development" --app app_name

Heroku Bundlerのドキュメント

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

bundle installを実行すると、bundlerは(デフォルトで)gemをシステムのgemリポジトリにインストールします。つまり、gem listに表示されます。さらに、多数のアプリケーションを開発している場合は、各アプリケーションに共通のgemをダウンロードしてインストールする必要はありません。これは開発には便利ですが、デプロイにはやや問題があります。

デプロイシナリオでは、デプロイに使用するUnixユーザーは、システムロケーションにgemをインストールするアクセス権を持っていない可能性があります。ユーザーがアクセス権を持っている(またはsudoを使用している)場合でも、アプリケーションを起動するユーザーはアクセス権を持っていない可能性があります。たとえば、PassengerはRubyサブプロセスをやや制限されたユーザーであるnobodyで実行します。デプロイ環境でのトレードオフは、隔離をより重視する傾向があります(たとえ、一部のサードパーティの依存関係が変更された場合に、デプロイ時のbundle installがやや遅くなるとしても)。

その結果、bundlerには、デプロイ環境でbundlerを使用するためのベストプラクティスをカプセル化する--deploymentフラグが付属しています。これらのプラクティスは、bundlerの開発中に受け取った重要なフィードバックと、デプロイ用にbundlerを最適に構成する方法の誤解を反映した多数のバグレポートに基づいています。 --deploymentフラグは、次のデフォルトを追加します

  • bundlerは、gemをシステムロケーションにインストールする代わりに、アプリケーション内のvendor/bundleにgemをインストールします。アプリケーション内で(Bundler.setupおよびBundler.requireで)起動すると、Bundlerはこの場所を透過的に記憶します。
  • Bundlerは、システムに既にインストールされているgemが存在していても、それらを使用しません。
  • bundle packを実行し、vendor/cacheディレクトリをチェックインし、git gemがない場合、Bundlerはバンドルのインストール中にインターネットに接続しません。
  • BundlerにはGemfile.lockのスナップショットが必要であり、提供しなかった場合は失敗します。
  • Bundlerは、Gemfile.lockGemfileと比べて古い場合、透過的に更新しません

Capistranoを使用している場合は、vendor/bundleshared/vendor_bundleにシンボリックリンクする必要があります。これにより、bundlerはデプロイ間でインストール済みのgemを共有し(変更がなかった場合は、処理を高速化します)、他のアプリケーションからの分離のメリットも得られます。

バンドルディレクトリをデフォルトでvendor/bundleに設定し、デプロイプロセスの一部としてバンドルをインストールすることで、アプリケーションをチェックアウトした同じUnixユーザーが、アプリケーションに必要なサードパーティコードもインストールしていることを確認できます。つまり、Passenger(またはUnicorn)がアプリケーションを表示できる場合は、その依存関係も表示できます。

--deploymentフラグには、開発環境とステージング環境で行ったテストが、実際に運用環境に投入したコードを反映していることを確認するために、最新のGemfile.lockが必要です。アプリケーションをデプロイする前にbundle checkを実行して、Gemfile.lockが最新であることを確認できます。 Gemfileを最後に変更してからbundle installを実行し、アプリケーションを正常に起動した場合(またはテストを実行した場合)は、常に最新の状態になることに注意してください。

エラーを見つけたり、不足しているものに気づいた場合は、GitHubでこのドキュメントを編集してください