Laragon番外編9｜Ruby on Railsを導入して動かす｜Rails 8.1.3.1・Puma・VS Code・500エラー対処まで

Laragon番外編8では、LaragonへRubyを追加し、RubyGems・Bundler・Rake・VS Code・Ruby LSPまで動作を確認しました。

今回はその続きとして、Ruby 3.4.10の環境へRuby on Rails 8.1.3.1を導入し、実際にRailsアプリを作成してブラウザへ表示するところまで進めます。

Railsをインストールして終わりではありません。

実際にRailsアプリを作成し、Pumaで開発サーバーを起動し、Homeコントローラーとビューを作成します。その後、http://127.0.0.1:3000/だけで自作ページを表示できるところまで確認します。

さらに今回の実機検証では、Bootsnap、VIPS、Ruby LSP、そして500 Internal Server Errorにも遭遇しました。

正常に動いた部分だけではなく、Windows + Laragon環境で実際に発生した問題と、その切り分け・対処まで順番に確認していきます。

前回｜Laragon番外編8 Ruby

Railsへ進む前に、Rubyそのものの追加・切り替えやRuby LSPの設定を確認したい場合は、前回の記事から確認できます。

あわせて読みたい

Laragon番外編8｜Rubyを追加・切り替える｜RubyGems・Bundler・VS Code・Ruby LSPまで

macOSについて
本記事はWindows版Laragonを使ったRuby開発環境の構築を対象としています。macOSではHomebrewやRubyのバージョン管理ツールを利用する方法が一般的で、手順が大きく異なるため、本記事では解説を省略します。

今回確認したRails開発環境

今回、実機で確認した主な環境は次のとおりです。

前回の記事ではRuby 4.0.6とRuby 3.4.10の両方をLaragonへ追加しましたが、今回のRails編ではRuby 3.4.10を選択した状態から作業を開始しています。

1．Rails導入前にRuby 3.4.10を確認する

最初に、Laragon TerminalがどのRubyを使用しているのか確認します。

LaragonでRubyを切り替えていても、以前から開いていたTerminalには古い環境が残っていることがあります。

そのため、Rubyを切り替えた場合はLaragonを再起動し、新しいLaragon Terminalを開いてから確認するのが安全です。

where.exe ruby
ruby -v
gem -v
bundle -v

今回の確認値は、Ruby 3.4.10 / RubyGems 3.6.9 / Bundler 4.0.16です。

where.exe ruby
ruby -v
gem -v
bundle -v

今回の確認値は、Ruby 3.4.10 / RubyGems 3.6.9 / Bundler 4.0.16です。

今回の環境では、Ruby本体の場所として、

C:\laragon\bin\ruby\ruby-3.4.10\bin\ruby.exe

が表示されました。

あわせてRuby 3.4.10、RubyGems 3.6.9、Bundler 4.0.16を確認しています。

2．Rails 8.1.3.1をインストールする

Ruby 3.4.10を確認できたら、Railsをインストールします。

今回はRails 8.1.3.1を指定しました。

gem install rails -v 8.1.3.1

gem install rails -v 8.1.3.1

インストールには少し時間がかかります。

処理が完了したら、Railsのバージョンを確認します。

rails -v

rails -v

今回の環境では、

Rails 8.1.3.1

と表示されました。

RubyGemsの更新通知が表示された場合

今回のRailsインストール時には、RubyGemsの新しいバージョンが利用できるという通知も表示されました。

ただし、この時点でRubyGemsまで更新すると、Railsの動作確認途中で環境そのものが変わってしまいます。

今回は原因を切り分けやすくするため、RubyGemsの更新は行わず、そのままRailsの検証を続けました。

3．Railsアプリを作成する

Rails本体を確認できたので、実際にアプリケーションを作成します。

今回はLaragonの、

C:\laragon\www

の下へ、

rails-test

という名前のRailsアプリを作成しました。

最初は通常のrails newを試す

まずは通常のRailsアプリ作成を試しました。

cd C:\laragon\www
rails new rails-test

cd C:\laragon\www
rails new rails-test

ところが今回のWindows環境では、この途中でBootsnapに関するエラーが発生しました。

BootsnapがWindows Application Controlでブロックされた

エラー内容を確認すると、bootsnap.soの読み込みがWindows Application Controlによってブロックされていました。
※今回はWindows11 での実証です。Windows10の場合はBootsnapをスキップしなくても
構築できるかもしれません、それならそのまま一度削除する工程は省いてください。

作成途中のrails-testをいったん削除し、Bootsnapをスキップして作り直します。

cd C:\laragon\www
Remove-Item -Recurse -Force .\rails-test
rails new rails-test --skip-bootsnap

cd C:\laragon\www
Remove-Item -Recurse -Force .\rails-test
rails new rails-test --skip-bootsnap

今回重要なのは、

--skip-bootsnap

を付けている点です。

VIPSの警告が表示された

Railsアプリの生成中には、VIPS関連の警告も表示されました。

今回確認したものには、vips-heif.dll、vips-jxl.dll、vips-magick.dll、vips-openslide.dll、vips-poppler.dllなどがあります。

かなり目立つ警告ですが、その後もRailsの生成処理は続き、最終的にはTerminalのプロンプトへ戻りました。

Kamal初期化時にはfiddleの警告も表示された

Railsアプリ生成中のkamal initでは、fiddleに関する警告も表示されました。

今回も警告は表示されましたが、Kamal関連の設定ファイルやhooksなどの生成は最後まで進んでいます。

4．データベースを準備する

Railsアプリの生成が完了したら、作成したプロジェクトへ移動してデータベースを準備します。

cd C:\laragon\www\rails-test
bundle exec rails db:prepare

cd C:\laragon\www\rails-test
bundle exec rails db:prepare

今回もVIPS関連の警告が表示されましたが、処理後にプロンプトへ戻りました。

このあとRailsサーバーを起動できるか確認します。

5．PumaでRailsサーバーを起動する

Railsには開発用WebサーバーとしてPumaが組み込まれています。

Railsアプリのディレクトリで、Railsサーバーを起動します。

bundle exec rails server

bundle exec rails server

正常に起動すると、今回の環境では、

Rails 8.1.3.1 application starting in development
Puma version: 8.0.2
Ruby version: ruby 3.4.10
Listening on http://127.0.0.1:3000

といった情報を確認できました。

Pumaを起動したTerminalは、このあとも停止せず、そのまま開いておきます。

Railsの初期ページを確認する

ブラウザを開いて、

http://127.0.0.1:3000

へアクセスします。

Railsの初期ページが表示されれば、RailsアプリとPumaの基本的な起動確認は成功です。

今回表示された画面から、Rails 8.1.3.1、Rack 3.2.7、Ruby 3.4.10を確認できました。

6．Homeコントローラーを作成する

Railsの初期画面だけではなく、ここからは自分で作成したページを表示してみます。

Pumaを起動しているTerminalはそのまま残し、別のLaragon Terminalを開きます。

rails-testディレクトリへ移動した状態で、Homeコントローラーとindexアクションを生成します。

cd C:\laragon\www\rails-test
bundle exec rails generate controller Home index

cd C:\laragon\www\rails-test
bundle exec rails generate controller Home index

実行すると、HomeControllerだけでなく、app/views/home/index.html.erbやテスト・ヘルパーファイルも生成されます。

7．VS CodeでRailsプロジェクトを開く

RailsアプリのディレクトリからVS Codeを開きます。

code .

code .

Laragon Terminalからcode .で開くことで、そのTerminalが利用している開発環境を引き継ぎやすくなります。

Home画面を編集する

VS Codeで、

app/views/home/index.html.erb

を開きます。

今回は、Railsが本当に動いていることを分かりやすく確認するため、「Hello, ToshiLab!」とRuby・Railsのバージョンを表示するページにしました。

<h1>Hello, ToshiLab!</h1>

<p>LaragonでRuby on Railsが正常に動作しています。</p>

<ul>
  <li>Ruby：<%= RUBY_VERSION %></li>
  <li>Rails：<%= Rails.version %></li>
</ul>

<h1>Hello, ToshiLab!</h1>

<p>LaragonでRuby on Railsが正常に動作しています。</p>

<ul>
  <li>Ruby：<%= RUBY_VERSION %></li>
  <li>Rails：<%= Rails.version %></li>
</ul>

ここでは固定文字だけではなく、RUBY_VERSIONとRails.versionを使っています。

そのため、実際に動作中のRubyとRailsのバージョンをブラウザへ表示できます。

8．作成したHome画面をブラウザで確認する

ファイルを保存したら、ブラウザで、

http://127.0.0.1:3000/home/index

へアクセスします。

今回の環境では、

Hello, ToshiLab!

LaragonでRuby on Railsが正常に動作しています。

Ruby：3.4.10
Rails：8.1.3.1

と表示されました。

9．トップページにHome画面を設定する

現在は/home/indexへアクセスしてHome画面を表示しています。

次は、

http://127.0.0.1:3000/

だけで同じHome画面が表示されるようにします。

VS Codeでconfig/routes.rbを開き、rootルートを追加します。

対象ファイル：

config/routes.rb

config/routes.rb

Rails.application.routes.draw do ～ end の内側へ追加します。

root "home#index"

root "home#index"

今回のroutes.rbでは、既にController生成時の

get "home/index"

get "home/index"

も存在するため、最終的には次の2つを確認できます。

get "home/index"

root "home#index"

get "home/index"

root "home#index"

Railsが認識しているrootルートも確認する

routes.rbを書き換えたあと、Railsが実際にどのControllerへ/を割り当てているか確認できます。

bundle exec rails routes | findstr /I root

bundle exec rails routes | findstr /I root

正しく設定できていれば、

root GET  /
home#index

という組み合わせを確認できます。

今回の検証中には、編集内容が実ファイルへ反映されておらず、意図しないルートを参照していた場面もありました。

ブラウザでエラーになった場合は、routes.rbの見た目だけでなく、rails routesで実際に認識されているルートを確認すると切り分けやすくなります。

10．500 Internal Server Errorが発生した

rootルートを確認したあと、ブラウザへアクセスしたところ、今回の検証では500 Internal Server Errorが発生しました。

500エラーの場合、ブラウザ画面だけでは原因を判断できません。

Pumaを起動しているTerminalのログを確認します。

今回のログでは、application.html.erb内のcsp_meta_tag付近で、

wrong number of arguments (given 2, expected 1)

というエラーが出ていました。

11．jsonのバージョンを確認する

ログを確認したあと、Rails環境で利用されているjsonのバージョンを調べました。

bundle exec ruby -rjson -e "puts JSON::VERSION"

bundle exec ruby -rjson -e "puts JSON::VERSION"

今回の環境では、

3.0.2

と表示されました。

そこで、検証としてjsonを2.21.2へ固定して動作を確認します。

Gemfileへjson 2.21.2を追加する

VS CodeでGemfileを開きます。

今回はgem "jbuilder"のすぐ下へjsonの指定を追加しました。

これはTerminalで実行するコマンドではありません。

対象ファイル：

Gemfile

Gemfile

今回はgem "jbuilder"の下へ追加します。

gem "json", "2.21.2"

gem "json", "2.21.2"

該当部分は、

# Build JSON APIs with ease [https://github.com/rails/jbuilder]
gem "jbuilder"
gem "json", "2.21.2"

# Build JSON APIs with ease [https://github.com/rails/jbuilder]
gem "jbuilder"
gem "json", "2.21.2"

となります。

gem "json", "2.21.2"はTerminalへ入力するコマンドではありません。

Gemfileへ記述するGemの指定です。

12．jsonを2.21.2へ戻して動作を確認する

Gemfileを保存したら、Pumaをいったん停止してからBundlerでjsonを戻します。

bundle update json

bundle update json

今回の結果では、

json 3.0.2 → 2.21.2

Fetching json 2.21.2 (was 3.0.2)
Installing json 2.21.2 (was 3.0.2) with native extensions
Note: json version regressed from 3.0.2 to 2.21.2
Bundle updated!

Fetching json 2.21.2 (was 3.0.2)
Installing json 2.21.2 (was 3.0.2) with native extensions
Note: json version regressed from 3.0.2 to 2.21.2
Bundle updated!

へ変更され、最後にBundle updated!と表示されました。

続けて、実際に使われているjsonのバージョンを確認します。

bundle exec ruby -rjson -e "puts JSON::VERSION"

bundle exec ruby -rjson -e "puts JSON::VERSION"

2.21.2

2.21.2

今度は、

2.21.2

と表示されました。

13．Railsを再起動して500エラーが解消するか確認する

jsonの変更後、もう一度Railsサーバーを起動します。

ここでは、先ほど使用したbundle exec rails serverをもう一度実行します。

bundle exec rails server

bundle exec rails server

まず、

http://127.0.0.1:3000/home/index

を確認したところ、「Hello, ToshiLab!」が再び表示されました。

続いて、

http://127.0.0.1:3000/

へアクセスします。

こちらも正常に表示されました。

これで、/home/indexを付けなくてもHome画面へアクセスできるようになりました。

14．Ruby LSPがrbenvを探して失敗する場合

VS Codeを開いた際、今回の環境ではRuby LSPから、

Automatic Ruby environment activation with rbenv failed

という通知も表示されました。

今回のLaragon環境ではrbenvでRubyを管理していません。

そこでRuby LSPの「Select Ruby manually」から手動設定を行い、workspaceへ、

C:\laragon\bin\ruby\ruby-3.4.10\bin\ruby.exe

を指定しました。

指定後は、先ほどのRuby LSPエラー通知が表示されなくなりました。

今回確認できたこと

今回のLaragon番外編9では、Ruby環境の確認からRailsアプリを実際に表示するところまで進めました。

1. Ruby 3.4.10の確認から始まり
2. Rails 8.1.3.1の導入
3. Railsアプリ生成
4. データベース準備
5. Puma起動
6. HomeControllerとViewの作成
7. rootルート設定
8. 500エラーの切り分け
9. json 2.21.2への変更
10. Ruby LSPの手動設定まで確認できました。

まとめ

今回は、前回Laragonへ追加したRuby 3.4.10を使い、Ruby on Rails 8.1.3.1を実際に動かしました。

Rails本体のインストールだけではなく、Railsアプリの生成、データベース準備、Puma起動、Controller・Viewの作成、Routingの設定まで進めています。

最終的には、

Ruby 3.4.10
Rails 8.1.3.1
Puma 8.0.2
json 2.21.2

の環境で、

Hello, ToshiLab!

をブラウザへ表示できました。

Windows + Laragonでは、すべてが何も警告なく進むとは限りません。

今回もBootsnap、VIPS、Ruby LSP、500 Internal Server Errorと複数の問題に遭遇しました。

ただし、エラーが出たときに設定を無闇に変更するのではなく、TerminalやPumaのログを確認しながら一つずつ切り分けることで、最終的にRailsアプリを動かせる状態まで到達できました。

• Ruby 3.4.10
• Rails 8.1.3.1
• PumaによるRailsサーバー
• HomeController
• /home/index
• root "home#index“
• トップページ表示
• Ruby LSPのLaragon Ruby参照

まで確認できれば、今回の作業は完了です。

Laragon番外編の流れを確認する

Laragon番外編を最初から確認したい場合は、番外編1で複数バージョンを追加・切り替える基本的な仕組みから確認できます。

最初に読んで欲しい

Laragon番外編1｜複数バージョンを追加・切り替える仕組みを理解する

次回はLaragon番外編10｜Javaへ

RubyとRuby on Railsまで確認できたので、次のLaragon番外編ではJava環境へ進む予定です。

JavaをLaragonでどのように扱うか、JDKの導入・バージョン確認・実際のプログラム実行まで、今回と同じように実機で確認していきます。

あわせて読みたい

【Laragon番外編10】Java 25とMaven 3.9.16を導入｜VS Codeでデバッグ・JAR実行まで

toshi

フルスタックエンジニア

XFacebookInstagramContact

C型肝炎や感染症の闘病を経て現在通院中
フリーランスとして今日を生きる、それがすべて。
静かな光の中で、歩みを止めずに生きていく。
実験大好きなので色々とやっていきます。