rails 7.2で追加されたブラウザバージョン指定機能と406-unsupported-browser.html

bin/rails app:updateコマンドを実行するとpublic/に406-unsupported-browser.html作成されます。 このHTMLフィアルは、rails 7.2で追加されたブラウザバージョン指定機能が指定範囲外のブラウザに対して送るファイルです。

なお、既存アプリでは、この機能の利用を始めないのであれば、念のため406-unsupported-browser.htmlを置くだけ置いておくという対応で良いように思います。

rails 7.2への移行におけるActive Storageのmigration

bin/rails app:updateコマンドを実行すると以下の3つのファイルがdb/migrate/に作成されることがありますが、
Active Storageをまだ使用したことがないアプリケーションでは、 これら3つのファイルは単純に削除してしまっても良いはずです。

• xxx_add_service_name_to_active_storage_blobs.active_storage.rb
• xxx_create_active_storage_variant_records.active_storage.rb
• xxx_remove_not_null_on_active_storage_blobs_checksum.active_storage.rb

より正確に言うと、データベースにactive_storage_blobsテーブルが存在していない場合は、 これら3つのファイルは単純に削除してしまっても良いはずです。 その理由として、これら3つのファイルはデータベースのactive_storage_blobsテーブルに対して影響を与えるものであり、 table_exists?(:active_storage_blobs)がfalseを返すと何もせずにreturnする処理が3つのファイル全てに記述されているからです。

ご自身のRailsアプリケーションのデータベースにactive_storage_blobsテーブルが存在するかの確認はbin/rails consoleを実行して、 以下のようにコマンドを実行することで行えます。 結果がfalseであればactive_storage_blobsテーブルは存在していない、つまり前述の3つのファイルは削除で大丈夫のはずです。

foobar(dev)> ActiveRecord::Base.connection.table_exists? :active_storage_blobs
=> false

ちなみに、データベースにあるテーブルの一覧を見たい場合にはbin/rails consoleで ActiveRecord::Base.connection.tablesを叩くことでテーブルの一覧を確認できます。

rails 7.2でのconfig/puma.rbの大幅な更新

rails newで生成されるconfig/puma.rbが大幅に更新されました。

• v7.1.4のpuma.rb.tt
• v7.2.1のpuma.rb.tt

主要な変更点は以下の通りです。

• threadsの指定方法の変更: リリースノート：Pumaのデフォルトのスレッド数が新しくなった、PR #50450 、PR #50669
• pidfileの変更: PR #50644、PR #50669、commit 57a6916
• environmentの削除: PR #52541
• production環境でのworkersの削除: commit 142e6ab
• production環境でのpreload_app!の削除: PR #52541
• development環境でのworker_timeoutの削除: PR #52541

rails 7.2ではfilter_parametersに:emailが追加された

rails newで生成されるconfig/initializers/filter_parameter_logging.rbにおいて、 rails 7.2でconfig.filter_parametersに:emailが追加されました。 この追加に関するプルリクエストはこちらです。

 Rails.application.config.filter_parameters += [
-  :passw, :secret, :token, :_key, :crypt, :salt, :certificate, :otp, :ssn
+  :passw, :email, :secret, :token, :_key, :crypt, :salt, :certificate, :otp, :ssn
 ]

セキュリティや個人情報保護の観点からは、確かにメールアドレスをフィルタすることは適切であるように思いますので、既存アプリにおいても:emailを追加すると良さそうです。

ちなみに、デバッグ作業などでメールアドレスを確認するときには少し不便になるような気もしますが、 emailへの直接の読み書きが疎外されるわけではありませんし、 またpluckなどの活用もすればデバッグの支障にはさほどならないような気がします。

rails 7.2におけるpublic_file_server.enabled

rails newで生成されるconfig/environments/test.rbにおいて、 7.1以前は以下の設定用コードが存在していましたが、 このプルリクエストのマージによって削除されました。

  config.public_file_server.enabled = true

削除された理由は、このプルリクエストによると、default値がtrue、かつ、全てのenvironment（test、development、production）の間で設定値に違いが無いということからです。 ですので、既存アプリにおいても、設定値をtrueとしている場合には、この設定用コードは削除してしまっても良いかもしれません。

rails 7.2におけるannotate_rendered_view_with_filenames

annotate_rendered_view_with_filenamesは、rails 6.1で追加されたビューのテンプレートの開始と終了に対応するHTMLコメントを挿入する機能です。

rails newで生成されるconfig/environments/development.rbにおいて、 7.1以前はこの機能を有効化する以下のコードがコメントアウトされていましたが、 7.2からは以下のように有効になるコードになりました（この変更のPR）。 ちなみに、default値は7.1以前から変わらずfalseですので、 development.rb内の当該設定を意図的に変更しなければ、既存アプリの挙動が勝手に変わることはありません。

  config.action_view.annotate_rendered_view_with_filenames = true

確かにdevelopment環境において便利そうな機能ですので、7.2へのアップデートを機に、使い始めてみるのも良いかもしれません。

基本的にはRailsガイドの手順に従えば良いと思います。

ガイドの手順にもありますが、ぜひbin/rails app:updateコマンドを活用しましょう。

rails 7.2への移行で対応が必要そうな個別の作業について、以下のコメントでそれぞれ取り上げますので、ご参考になれば幸いです。

PostgreSQLに関した練習やテスト、実験などを行うときにPostgreSQLが動いている一時的な環境が欲しくなるときがあります。 PostgreSQLイメージとPodmanを利用すると、特定バージョンのPostgreSQLに関する一通りの操作ができる一時的なコンテナ環境を用意することが出来ます。

以下にコンテナ環境の作成、利用、削除の流れと方法を示します。

コンテナ環境の作成

以下の3つのコマンドを実行することで、PostgreSQLのコンテナ環境を作成し、クライアント側のコンテナのbash環境に入ることが出来ます。

なお、コマンド内の「16」のところはPostgreSQLのメジャーバージョンに相当しますので、ご利用になりたいバージョンの数に変更してください。 また、-v "$PWD":/x -w /xのオプションにより、ホストOSのカレントディレクトリにコンテナ内からもアクセス出来る状態でbashが立ち上がります。 したがって、実験などに利用したいファイルをカレントディレクトリに置いてから以下のコマンドを実行すればコンテナ内でもそのファイルを利用できますし、 コンテナ内で/xのディレクトリに作成したファイルはコンテナ環境を終了した後もホストOSのカレントディレクトリに残ります。

podman pod create --name tmp_pg
podman run --name tmp_pg-server --pod tmp_pg -e POSTGRES_PASSWORD=postgres -d postgres:16
podman run -it --rm -v "$PWD":/x -w /x --name tmp_pg-bash --pod tmp_pg postgres:16 bash

以下のようなプロンプトが表示されていれば成功です。クライアント側のコンテナのbash環境に入れました。

root@tmp_pg:/x#

クライアント側のコンテナのbash環境の利用

このbash環境では、psqlなどのPostgreSQLのコマンドを一通り利用することが出来ます。以下に例を示します。

PostgreSQLのターミナルを開く例：

psql -h localhost -U postgres -d postgres

バックアップファイルを作成する例：

pg_dump -Fc -h localhost -U postgres -d postgres -f backup.dump

バックアップファイルをリストアする例：

pg_restore --clean -h localhost -U postgres -d postgres backup.dump

クライアントのコンテナを終了しそのbash環境から退出する場合はexitコマンドで抜けられます。 また、退出後にもう一度クライアントを使いたくなった場合は、後述のコンテナ環境全体の削除をまだしていなければ、 以下の3つめのコマンドだけ実行すれば、クライアントのコンテナをもう一度作成しそのbash環境に入ることが出来ます。

podman run -it --rm -v "$PWD":/x -w /x --name tmp_pg-bash --pod tmp_pg postgres:16 bash

コンテナ環境全体の削除

以下のコマンドで、コンテナ環境全体の停止と削除が実行できます。

podman pod stop tmp_pg && podman pod rm tmp_pg

PostgreSQLのメジャーバージョンを上げるときなど、通常のデータの読み書きとは異なる更新をDBに対して行うことがあります。

ここではHerokuの公式ドキュメントである「Heroku Postgres データベースのバージョンのアップグレード」を参考に、このようなアップデート等の変更をDBに行うときの大まかな流れをご紹介します。

DBにアップデート等の変更を行うときの作業の流れ

新たなDBを作成する

メジャーバージョンを上げるといった大きな更新をするときには、 何かあったときにすぐに戻せるよう、元のDBには手を入れずそのままにして温存します。 代わりに、addons:createコマンドなどで、大きな更新を行う別の新たなDBを作成します。

DBへの書き込みを停止させて、データを完璧に複製する

addons:createコマンドの--followオプションやpg:copyコマンドを利用して、 元のDBから新たなDBにデータをコピーします。 この際、適切にアプリをメンテナンスモードにするなどして、元のDBへの書き込みを停止させ、 停止している間に元のDBのデータの全てが新たなDBに複製されている状態にします。

ちなみに、公式ドキュメントには記載がありませんが、 バックアップが短時間で終わるデータの規模であるならば、 トラブルに備えてこの書き込みが停止しているタイミングで元のDBのバックアップを手動で作成しても良いように思います。

新たなDBに手を加える

メジャーバージョンの更新などの必要があれば、新たなDBに手を加えます。

アプリの接続先を元のDBから新たなDBに切り替える

pg:promoteコマンドを利用して、アプリが読み書きする対象を新たなDBに切り替えます。

アプリを公開してテストする

メンテナンスモードを解除するなどして、アプリを公開状態に戻します。 本番環境が問題なく動いているかテストを行います。 何かしら問題がある場合には、アプリの接続先を元のDBに迅速に戻すことで、被害が最小化できるはずです。

不要になったDBを削除する

元のDBなどが不要になった場合など、addons:destroyコマンドなどを利用して、不要になったDBを削除します。

（参考）ステージングアプリを利用したテスト

より安全にDBの更新などを行うために、本番のアプリのDBを更新する前に、ステージングのアプリでDBの更新をテストすることも可能です。詳細はPostgreSQL メジャーバージョンのアップグレードのテストをご覧ください。

railsのDB接続設定では、環境変数DATABASE_URLの情報が優先されます。

Herokuでは、環境変数DATABASE_URLへの設定を通してDB設定が行れています。また、このDB設定（つまり、DATABASE_URLの値）を変更したいときにはheroku pg:promote​コマンドを用います。

なお、環境変数DATABASE_URLの現在の設定値はheroku configコマンドで確認できます。