最終更新日 2020年06月11日(木)

このクイックスタートでは、Heroku にデプロイされた Rails 3​ で始めます。Rails の最新バージョンは Rails 4​ です。新しいアプリを開始している場合は、おそらく『スターターガイド (Rails 4)​』を使用する必要があります。Sinatra または他の Ruby アプリの場合は、『Heroku スターターガイド (Ruby)​』を参照してください。

前提条件

• Ruby 2.0.0、Rubygems、Bundler、Rails 3 のインストール済みバージョンを含む、Ruby/Rails に関する基本的な知識。
• Git に関する基本的な知識
• アプリケーションは Ruby (MRI) 2.0.0 上で実行する必要があります。
• Heroku ユーザーアカウント。無料ですぐにサインアップできます​。

ローカルワークステーションの設定

Heroku ＣＬＩ​ をローカルワークステーションにインストールします。 これにより、Heroku コマンドラインクライアント​ および heroku local​ コマンドにアクセスできるようになります。

インストールすると、コマンドシェルから heroku​ コマンドにアクセスできます。 Heroku アカウントを作成したときに使用したメールアドレスとパスワードでログインします。

$ heroku login
Enter your Heroku credentials.
Email: adam@example.com
Password:
Could not find an existing public key.
Would you like to generate one? [Yn]
Generating new SSH public key.
Uploading ssh public key /Users/adam/.ssh/id_rsa.pub

プロンプトで Enter キーを押し、後でコードのプッシュに使用するため、既存の ssh​ キーをアップロードするか新しいキーを作成します。

Heroku は、アプリ用の PostgreSQL​ データベースを提供しているので、PostgreSQL をローカルデータベースとしても使用します。ローカルでこれを設定​する必要があります。

アプリの記述

アプリの生成

新しいアプリ

既存のアプリから開始できます。 そうでない場合、vanilla Rails 3 アプリは適切なサンプルアプリとして機能します。

$ rails new myapp --database=postgresql
$ cd myapp

既存のアプリ

既存のアプリをアップグレードしている場合は、SQLite3 ではなく PostgreSQL を使用していることを確認してください。Gemfile​ を編集し、以下の行を変更します。

gem 'sqlite3'

変更後は次のようになります。

gem 'pg'

pg​ gem の使用に加えて、config/database.yml​ で sqlite3​ ではなく postgresql​ アダプターが使用されていることも確認する必要があります。config/database.yml​ ファイルは次のようになります。

development:
  adapter: postgresql
  encoding: unicode
  database: myapp_development
  pool: 5
  username: myapp
  password:
test:
  adapter: postgresql
  encoding: unicode
  database: myapp_test
  pool: 5
  username: myapp
  password:
production:
  adapter: postgresql
  encoding: unicode
  database: myapp_production
  pool: 5
  username: myapp
  password:

必ずデータベースのユーザ名とパスワードを更新してください。

また、(新しい Gemfile.lock​ を生成するために) 依存関係を再インストールします。

$ bundle install

Rails のプラグイン

Heroku プラットフォームを最大限に活用するため、rails_12factor​ gem を含めます。これは、プラットフォームで動作するようにアプリへのログインなどの機能を設定します。

gem 'rails_12factor', group: :production

Bundler を使用して依存関係を更新する必要があります。

$ bundle install

この詳細は、「Ruby Support​」(Ruby サポート) ドキュメントで確認できます。

アセットパイプラインの設定

Rails 3.1 では、JavaScript および CSS アセットを結合し、削減または縮小するために、アセットパイプライン​を導入しました。Heroku には、slug にアセットを事前コンパイルするステップがビルドプロセスにあるので、簡単に利用できます。アセットの事前コンパイルの速度を上げるために、アプリを部分的にのみ読み込むように Rails に指示することをお勧めします。Heroku ではまた、ビルドプロセスにアプリ環境全体を提供しないので、これが必要です。config/application.rb​ で次のように設定します。

config.assets.initialize_on_precompile = false

Heroku へのデプロイ時に Rails 3.1+ アセットパイプライン​を起動する方法は複数あります。完全な詳細については、「Rails 3.1+ Asset Pipeline on Heroku Cedar​」(Heroku Ceder での Rails 3.1 およびアセットパイプライン) の記事を参照してください。

Ruby バージョンの指定

開発/本番パリティ​が必要なので、本番環境のものと同じバージョンの Ruby をローカルで指定する必要があります。Bundler で導入された ruby​ DSL を使用します。Gemfile で、次の内容を最下部に追加します。

ruby '2.0.0'

Ruby バージョンの指定​について詳細を確認できます。

Git でアプリを保存します

$ git init
$ git add .
$ git commit -m "init"

Heroku へアプリケーションをデプロイします

Heroku でアプリを作成します。

$ heroku create --addons heroku-postgresql
Creating severe-mountain-793... done, stack is heroku-18
http://severe-mountain-793.herokuapp.com/ | git@heroku.com:severe-mountain-793.git
Git remote heroku added

コードをデプロイします。

$ git push heroku master
Counting objects: 67, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (52/52), done.
Writing objects: 100% (67/67), 86.33 KiB, done.
Total 67 (delta 5), reused 0 (delta 0)

-----> Ruby/Rails app detected
-----> Using Ruby version: ruby-2.0.0
-----> Installing dependencies using Bundler version 1.3.2
       Running: bundle install --without development:test --path vendor/bundle --binstubs vendor/bundle/bin --deployment
       Fetching gem metadata from https://rubygems.org/..........
       Fetching gem metadata from https://rubygems.org/..
       Installing rake (10.1.0)
       ...
       Installing uglifier (2.2.1)
       Your bundle is complete! It was installed into ./vendor/bundle
       Post-install message from rdoc:
       Depending on your version of ruby, you may need to install ruby rdoc/ri data:
       <= 1.8.6 : unsupported
       = 1.8.7 : gem install rdoc-data; rdoc-data --install
       = 1.9.1 : gem install rdoc-data; rdoc-data --install
       >= 1.9.2 : nothing to do! Yay!
       Cleaning up the bundler cache.
-----> Writing config/database.yml to read from DATABASE_URL
-----> Preparing app for Rails asset pipeline
       Running: rake assets:precompile
       Compiled jquery.js  (9ms)  (pid 735)
       Compiled jquery_ujs.js  (0ms)  (pid 735)
       Compiled application.js  (32ms)  (pid 735)
       Compiled application.css  (2ms)  (pid 735)
       Compiled jquery.js  (5ms)  (pid 735)
       Compiled jquery_ujs.js  (0ms)  (pid 735)
       Compiled application.js  (16ms)  (pid 735)
       Compiled application.css  (1ms)  (pid 735)
       Asset precompilation completed (19.16s)
-----> Discovering process types
       Procfile declares types -> (none)
       Default types for Rails -> console, rake, web, worker
-----> Compiled slug size: 34.0MB
-----> Launching... done, v5
       http://severe-mountain-793.herokuapp.com deployed to Heroku

To git@heroku.com:severe-mountain-793.git
 * [new branch]      master -> master

アプリケーションへのアクセス

コードが Heroku にデプロイされ、 プロセスタイプを実行するように Heroku に指示できるようになりました。 Heroku では、これは dyno​ (Heroku の構成の基本単位である軽量コンテナ) で関連付けられているコマンドを実行して行われます。

1 つの dyno によって web​ プロセスタイプが実行されていることを確認します。

$ heroku ps:scale web=1

アプリの dyno の状態をチェックできます。 heroku ps​ コマンドにより、アプリケーションで実行中の dyno の一覧が表示されます。

$ heroku ps
=== web: `bundle exec rails server -p $PORT`
web.1: up for 5s

ここでは、1 つの dyno が実行中です。

heroku open​ を使用して、ブラウザでアプリにアクセスできます。

$ heroku open
Opening severe-mountain-793... done

dyno のスリープおよびスケーリング

ログの表示

Heroku では、アプリケーションのコンポーネントを実行しているすべての dyno の出力ストリームから集約した時系列イベントのストリームとして、ログを扱います。 Heroku の Logplex​ は、これらのすべてのイベントに単一のチャネルを提供します。

たとえば、ログコマンド​の 1 つである heroku logs​ を使って、実行中のアプリに関する情報を簡単に表示できます。

$ heroku logs
2011-03-10T11:10:34-08:00 heroku[web.1]: State changed from created to starting
2011-03-10T11:10:37-08:00 heroku[web.1]: Running process with command: `bundle exec rails server -p 53136`
2011-03-10T11:10:40-08:00 app[web.1]: [2011-03-10 19:10:40] INFO  WEBrick 1.3.1
2011-03-10T11:10:40-08:00 app[web.1]: [2011-03-10 19:10:40] INFO  ruby 2.0.0 (2013-06-27) [x86_64-linux]
2011-03-10T11:10:40-08:00 app[web.1]: [2011-03-10 19:10:40] INFO  WEBrick::HTTPServer#start: pid=12198 port=53136
2011-03-10T11:10:42-08:00 heroku[web.1]: State changed from starting to up

コンソール

Heroku では、heroku run​ コマンドを使用して、One-off dyno​ (必要な場合にのみ実行するスクリプトおよびアプリケーション) でコマンドを実行できます。 これを使用して、アプリの環境で試行するためにローカルターミナルにアタッチされた Rails コンソールプロセスを起動します。

$ heroku run rails console
Running `bundle exec rails console` attached to terminal... up, ps.1
Loading production environment (Rails 3.2.14)
irb(main):001:0>

Rake およびデータベースの移行

Rake は、コンソールと同様に、アタッチされたプロセスとして実行できます。

$ heroku run rake db:migrate

上記のようなデータベースの移行は自動的には実行されません。移行を実行させる場合は、デプロイ後に必ず heroku run rake db:migrate​ を実行してください。Rake コマンド​の詳細がわかります。

Web サーバー

デフォルトで、アプリの Web プロセスでは、Webrick を使用する rails server​ が実行されます。テストにはこれで十分ですが、本番環境のアプリではより堅牢な Web サーバーに切り替えてください。Cedar の場合、Web サーバーには Unicorn をお勧めします​。選択した Web サーバーには関係なく、本番環境のアプリでは Procfile​ で明示的に Web サーバーが常に指定される必要があります。

Procfile

Procfile​ を呼ばれるファイルを作成し、以下を入力して、Web プロセスを起動するのに使用するコマンドを変更します。

web: bundle exec unicorn -p $PORT -E $RACK_ENV

環境で RACK_ENV​ を開発に設定し、接続先の PORT​ を設定します。Heroku にプッシュする前に、Heroku アプリが実行される環境となる本番環境に設定された RACK_ENV​ でテストする必要があります。

$ echo "RACK_ENV=development" >>.env
$ echo "PORT=5000" >> .env

さらに、ローカル環境の設定として、.env​ を .gitignore​ に追加する必要があります。

$ echo ".env" >> .gitignore
$ git add .gitignore
$ git commit -m "add .env to .gitignore"

Gemfile にこれを追加することにより、Unicorn gem をインストールする必要があります。

gem 'unicorn'

bundle install​ を実行して、ローカルでこれをインストールします。

ローカルで heroku local​ を使用している Procfile​ をテストします。

$ heroku local
17:04:16 web.1  | started with pid 20032
17:04:16 web.1  | I, [2013-03-13T17:04:16.857230 #20034]  INFO -- : listening on addr=0.0.0.0:5000 fd=9
17:04:16 web.1  | I, [2013-03-13T17:04:16.857402 #20034]  INFO -- : worker=0 spawning...
17:04:16 web.1  | I, [2013-03-13T17:04:16.858497 #20034]  INFO -- : master process ready
17:04:16 web.1  | I, [2013-03-13T17:04:16.859851 #20038]  INFO -- : worker=0 spawned pid=20038
17:04:16 web.1  | I, [2013-03-13T17:04:16.859978 #20038]  INFO -- : Refreshing Gem list

問題がなければ、Ctrl-C を押して終了します。 変更を Heroku にデプロイします。

$ git add .
$ git commit -m "use unicorn via procfile"
$ git push heroku

ps​ をチェックすると、Web dyno によって、Web サーバーとして Unicorn を指定している新しいコマンドが使用されていることが分かります。

$ heroku ps
Process       State               Command
------------  ------------------  ------------------------------
web.1         starting for 3s     bundle exec unicorn -p $PORT..

ログにも、Unicorn が使用されていることが反映されています。

$ heroku logs
2013-03-14T00:08:50+00:00 heroku[web.1]: State changed from created to starting
2013-03-14T00:08:53+00:00 heroku[web.1]: Starting process with command `bundle exec unicorn -p 38195 -E $RACK_ENV`
2013-03-14T00:08:54+00:00 app[web.1]: I, [2013-03-14T00:08:54.833013 #2]  INFO -- : listening on addr=0.0.0.0:38195 fd=9
2013-03-14T00:08:54+00:00 app[web.1]: I, [2013-03-14T00:08:54.834767 #2]  INFO -- : worker=0 spawning...
2013-03-14T00:08:54+00:00 app[web.1]: I, [2013-03-14T00:08:54.842064 #2]  INFO -- : master process ready
2014-03-14T00:08:54+00:00 app[web.1]: I, [2013-03-14T00:08:54.843165 #5]  INFO -- : worker=0 spawned pid=5
2013-03-14T00:08:54+00:00 app[web.1]: I, [2013-03-14T00:08:54.843441 #5]  INFO -- : Refreshing Gem list
2013-03-14T00:08:56+00:00 heroku[web.1]: State changed from starting to up

本番環境用に Unicorn を設定する方法については、「Deploying Rails Applications With Unicorn​」(Unicorn を使用した Rails アプリケーションのデプロイ) を参照してください。

トラブルシューティング

プッシュしたアプリがクラッシュした (heroku ps​ でステータス crashed​ が表示された) 場合は、ログをチェックしてクラッシュの原因を見つけてください。 一般的な問題には、たとえば以下があります。

ソースファイルの要求の失敗

アプリがソースファイルの要求に失敗した場合、ローカル環境で Ruby 1.9.1 または 1.8 を実行している可能性が大いにあります。 ロードパスが Ruby 1.9 で変更され、Ruby 2.0.0 にも適用されています。 Cedar へのプッシュを再度試みる前に、アプリを Ruby 2.0.0 にポートフォワーディングして、ローカルで機能することを確認します。

エンコードエラー

Ruby 1.9 では、より高度なエンコードサポートが言語に追加され、Ruby 2.0.0 にも適用されています。 エンコードエラーが発生した場合は、ローカル環境で Ruby 2.0.0 を使用してアプリを完全にはテストしていない可能性があります。 Cedar へのプッシュを再度試みる前に、アプリを Ruby 2.0.0 にポートフォワーディングして、ローカルで機能することを確認します。

gem の欠落

gem の欠落のためにアプリがクラッシュした場合、その gem がローカルでインストールされていても Gemfile​ で指定されていない可能性があります。 bundle execを使用して、すべてのローカルテストを分離する必要があります。​ たとえば、ruby web.rb​ を実行しないで、bundle exec ruby web.rb​ を実行します。 rake db:migrate​ を実行しないで、bundle exec rake db:migrate​ を実行します。

別のアプローチは、空の RVM gemset を作成して、システムによりインストールされた gem を絶対に扱わないようにすることです。

$ rvm gemset create myapp
$ rvm gemset use myapp

開発/テスト gem でのランタイムの依存関係

デプロイ時にまだ gem がない場合は、Bundler グループをチェックしてください。 Heroku では、アプリは development​ や test​ グループなしで構築されます。アプリの実行がこれらのグループのいずれかからの gem に依存している場合、これをグループから除外します。

最もよくある例の 1 つとして、Rakefile​ で Rspec タスクを使用する場合があります。 Heroku のデプロイで以下が表示されます。

$ heroku run rake -T
Running `bundle exec rake -T` attached to terminal... up, ps.3
rake aborted!
no such file to load -- rspec/core/rake_task

そして、以下の問題が発生します。 最初に、次のように問題をローカルにコピーします。

$ bundle install --without development:test
...
$ bundle exec rake -T
rake aborted!
no such file to load -- rspec/core/rake_task

これらの Rake タスクを gem のロード時に条件付きにすることで、問題を解消できます。 たとえば、次のようになります。

Rakefile

begin
  require "rspec/core/rake_task"

  desc "Run all examples"
  RSpec::Core::RakeTask.new(:spec) do |t|
    t.rspec_opts = %w[--color]
    t.pattern = 'spec/**/*_spec.rb'
  end
rescue LoadError
end

これがローカルで動作することを確認してから、Heroku にプッシュします。

次のステップ

• Ruby カテゴリ​では、Ruby アプリケーションのデプロイに関する詳細を確認できます。
• 「Heroku の仕組み​」では、アプリケーションの作成、設定、デプロイ、および実行時に必要な技術的な概念の概要を紹介しています。