Skip Navigation
Show nav
Heroku Dev Center
  • Get Started
  • ドキュメント
  • Changelog
  • Search
  • Get Started
    • Node.js
    • Ruby on Rails
    • Ruby
    • Python
    • Java
    • PHP
    • Go
    • Scala
    • Clojure
  • ドキュメント
  • Changelog
  • More
    Additional Resources
    • Home
    • Elements
    • Products
    • Pricing
    • Careers
    • Help
    • Status
    • Events
    • Podcasts
    • Compliance Center
    Heroku Blog

    Heroku Blog

    Find out what's new with Heroku on our blog.

    Visit Blog
  • Log inorSign up
View categories

Categories

  • Heroku のアーキテクチャ
    • Dyno (アプリコンテナ)
    • スタック (オペレーティングシステムイメージ)
    • ネットワーキングと DNS
    • プラットフォームポリシー
    • プラットフォームの原則
  • コマンドライン
  • デプロイ
    • Git を使用したデプロイ
    • Docker によるデプロイ
    • デプロイ統合
  • 継続的デリバリー
    • 継続的統合
  • 言語サポート
    • Node.js
    • Ruby
      • Bundler の使用
      • Rails のサポート
    • Python
      • Python でのバックグランドジョブ
      • Django の使用
    • Java
      • Maven の使用
      • Java でのデータベース操作
      • Play Framework の使用
      • Spring Boot の使用
      • Java の高度なトピック
    • PHP
    • Go
      • Go の依存関係管理
    • Scala
    • Clojure
  • データベースとデータ管理
    • Heroku Postgres
      • Postgres の基礎
      • Postgres Getting Started
      • Postgres のパフォーマンス
      • Postgres のデータ転送と保持
      • Postgres の可用性
      • Postgres の特別なトピック
    • Heroku Redis
    • Apache Kafka on Heroku
    • その他のデータストア
  • モニタリングとメトリクス
    • ログ記録
  • アプリのパフォーマンス
  • アドオン
    • すべてのアドオン
  • 共同作業
  • セキュリティ
    • アプリのセキュリティ
    • ID と認証
    • コンプライアンス
  • Heroku Enterprise
    • Private Space
      • インフラストラクチャネットワーキング
    • Enterprise Accounts
    • Enterprise Team
    • Heroku Connect (Salesforce 同期)
      • Heroku Connect の管理
      • Heroku Connect のリファレンス
      • Heroku Connect のトラブルシューティング
    • シングルサインオン (SSO)
  • パターンとベストプラクティス
  • Heroku の拡張
    • Platform API
    • アプリの Webhook
    • Heroku Labs
    • アドオンのビルド
      • アドオン開発のタスク
      • アドオン API
      • アドオンのガイドラインと要件
    • CLI プラグインのビルド
    • 開発ビルドパック
    • Dev Center
  • アカウントと請求
  • トラブルシューティングとサポート
  • Integrating with Salesforce
  • 言語サポート
  • Ruby
  • Rails のサポート
  • Heroku スターターガイド (Rails 3.x)

Heroku スターターガイド (Rails 3.x)

日本語 — Switch to English

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

最終更新日 2022年11月17日(木)

Table of Contents

  • 前提条件
  • ローカルワークステーションの設定
  • アプリの記述
  • Git でアプリを保存します
  • Heroku へアプリケーションをデプロイします
  • アプリケーションへのアクセス
  • dyno のスリープおよびスケーリング
  • ログの表示
  • コンソール
  • Rake およびデータベースの移行
  • Web サーバー
  • トラブルシューティング
  • 次のステップ

Heroku dyno、Heroku Postgres、および Heroku Data for Redis の無料プランは 2022 年 11 月 28 日で提供を終了します​。

低料金プラン​を使用してこのチュートリアルを完了することをお勧めします。資格のある学生の皆様は、新しい Heroku for GitHub Students プログラム​を通じてプラットフォームクレジットを申請できます。

 

Rails 3 は、Rails コアチームによるバグ修正プログラムおよび機能が積極的には維持されていません。できるだけ早く Rails 4 にアップグレードすることをお勧めします。詳細については、『Heroku スターターガイド (Ruby)​』を参照してください。

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

前提条件

  • Ruby 2.0.0、Rubygems、Bundler、Rails 3 のインストール済みバージョンを含む、Ruby/Rails に関する基本的な知識。
  • Git に関する基本的な知識
  • アプリケーションは Ruby (MRI) 2.0.0 上で実行する必要があります。
  • 確認済みの Heroku アカウント
  • Eco dyno プラン​にサブスクライブしている (推奨)

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

Heroku CLI​ をローカルワークステーションにインストールします。 これにより、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​ キーをアップロードするか新しいキーを作成します。

開発には PostgreSQL を使用することを強くお勧めします。 処理中の開発と開発環境を一致させることで、環境の違いによる微妙なバグの発生が阻止されます。

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 でアプリを作成します。

dyno とデータベースを使用してこのチュートリアルを完了した場合、使用量のカウントに入ります。コストを抑制するために、完了したらすぐにアプリを削除​し、データベースも削除​してください。

 

Ruby ビルドパックにより、Mini Heroku Postgres データベースがアプリ用に自動プロビジョニングされます。Eco にサブスクライブしている場合、アプリではデフォルトで Eco dyno が使用されます。それ以外の場合は、デフォルトで Basic dyno が使用されます。Eco dyno プランは、アカウントのすべての Eco dyno 間で共有され、多数の小さなアプリを Heroku にデプロイする場合にお勧めします。詳細は、こちら​を参照してください。資格のある学生の皆様は、Heroku for GitHub Students プログラム​を通じてプラットフォームクレジットを申請できます。

$ 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 のスリープおよびスケーリング

デフォルトでは、アプリは Eco dyno でデプロイされます。Eco dyno はアイドル状態 (トラフィックを何も受信しない状態) が 30 分続くとスリープします。 スリープすると、スリープ解除するときの最初のリクエスト時に数秒の遅延が発生します。その後のリクエストは正常に処理されます。 Eco dyno は、月ごとに割り当てられるアカウント別の Eco dyno 時間​を消費します。割り当て時間が残っている限り、Eco アプリはすべて稼働し続けます。

dyno がスリープしないようにするには、「dyno タイプ​」の記事で紹介されている Basic または Professional の dyno タイプにアップグレードできます。たとえば、アプリを Professional dyno に移行すると、Heroku に特定の数の dyno の実行を指示するコマンドを実行し、各 dyno で Web プロセスタイプを実行させて、アプリを簡単にスケールすることができます。

ログの表示

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 の仕組み​」では、アプリケーションの作成、設定、デプロイ、および実行時に必要な技術的な概念の概要を紹介しています。

関連カテゴリー

  • Rails のサポート
Unicorn を使用した Rails アプリケーションのデプロイ Heroku での Rails 4

Information & Support

  • Getting Started
  • Documentation
  • Changelog
  • Compliance Center
  • Training & Education
  • Blog
  • Podcasts
  • Support Channels
  • Status

Language Reference

  • Node.js
  • Ruby
  • Java
  • PHP
  • Python
  • Go
  • Scala
  • Clojure

Other Resources

  • Careers
  • Elements
  • Products
  • Pricing

Subscribe to our monthly newsletter

Your email address:

  • RSS
    • Dev Center Articles
    • Dev Center Changelog
    • Heroku Blog
    • Heroku News Blog
    • Heroku Engineering Blog
  • Heroku Podcasts
  • Twitter
    • Dev Center Articles
    • Dev Center Changelog
    • Heroku
    • Heroku Status
  • Facebook
  • Instagram
  • Github
  • LinkedIn
  • YouTube
Heroku is acompany

 © Salesforce.com

  • heroku.com
  • Terms of Service
  • Privacy
  • Cookies
  • Cookie Preferences