Home Software Libraries Ruby rails rails 7.1からrails 7.2への移行（アップデート、アップグレード）で必要な作業 @wakairo 2024/09/25 07:51 最終更新 2024/09/25 09:56 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を叩くことでテーブルの一覧を確認できます。
Home Software Libraries Ruby rails rails 7.1からrails 7.2への移行（アップデート、アップグレード）で必要な作業 @wakairo 2024/09/24 20:00 最終更新 2024/09/26 19:50 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
Home Software Libraries Ruby rails rails 7.1からrails 7.2への移行（アップデート、アップグレード）で必要な作業 @wakairo 2024/09/24 08:40 最終更新 2024/09/24 08:41 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などの活用もすればデバッグの支障にはさほどならないような気がします。
Home Software Libraries Ruby rails rails 7.1からrails 7.2への移行（アップデート、アップグレード）で必要な作業 @wakairo 2024/09/23 20:59 最終更新 2024/09/23 21:03 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としている場合には、この設定用コードは削除してしまっても良いかもしれません。
Home Software Libraries Ruby rails rails 7.1からrails 7.2への移行（アップデート、アップグレード）で必要な作業 @wakairo 2024/09/23 19:43 最終更新 2024/09/23 19:45 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へのアップデートを機に、使い始めてみるのも良いかもしれません。
Home Software Libraries Ruby rails rails 7.1からrails 7.2への移行（アップデート、アップグレード）で必要な作業 @wakairo 2024/09/23 17:06 最終更新 2024/09/27 16:42 基本的にはRailsガイドの手順に従えば良いと思います。 ガイドの手順にもありますが、ぜひbin/rails app:updateコマンドを活用しましょう。 rails 7.2への移行で対応が必要そうな個別の作業について、以下のコメントでそれぞれ取り上げますので、ご参考になれば幸いです。
Home Software その他 PostgreSQL PostgreSQLイメージとPodmanを利用した使い捨てのコンテナ環境 @wakairo 2024/09/20 21:42 最終更新 2024/09/20 21:56 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
Home Cloud services Heroku HerokuでDBのアップデート等を行うときの作業の流れ @wakairo 2024/09/20 19:39 最終更新 2024/09/20 19:46 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 メジャーバージョンのアップグレードのテストをご覧ください。
Home Cloud services Heroku Herokuでは環境変数DATABASE_URLを使ってrailsアプリが接続するDBの設定を行っている @wakairo 2024/09/19 19:03 最終更新 2024/09/19 19:32 railsのDB接続設定では、環境変数DATABASE_URLの情報が優先されます。 Herokuでは、環境変数DATABASE_URLへの設定を通してDB設定が行れています。また、このDB設定（つまり、DATABASE_URLの値）を変更したいときにはheroku pg:promoteコマンドを用います。 なお、環境変数DATABASE_URLの現在の設定値はheroku configコマンドで確認できます。
Home Software その他 Podman tオプションを付けてPodmanからリダイレクトでバイナリ出力を取り出すと壊れる @wakairo 2024/09/19 13:48 最終更新 2024/09/20 11:51 概要 Podmanで、-itオプション、厳密には-tオプションを付けっぱなしで、以下のようにリダイレクトを使うと、出力されたファイルの内容が壊れることがあります。-tオプションの意味を考えれば、出力をリダイレクトに回すときに指定する必要があるオプションではないのですが、コマンドを改変して流用するときなどに付けっぱなしにするとバイナリが壊れますのでご注意ください。 podman run -it --rm -v "$PWD":/x -w /x ruby:latest ruby print_bin.rb > podman.bin この問題は、以下のようにtオプションを外すことで回避できます。もちろんiオプションを残さず合わせて外してもOKです。 podman run -i --rm -v "$PWD":/x -w /x ruby:latest ruby print_bin.rb > no_t.bin また、この問題を回避方法として、以下のように、bash -cを使う方法もあります。 podman run -it --rm -v "$PWD":/x -w /x ruby:latest bash -c 'ruby print_bin.rb > bash.bin' ちなみにこの問題は、Dockerでも起きるようです。 詳細 例として、0x00から0xffまでの256バイトのバイナリを標準出力に出力する以下のRubyスクリプトを利用します。 print_bin.rb print (0..255).to_a.pack('C*') Podmanを使わずに、ローカルでこのスクリプトを実行して確認すると、以下のように正しく出力されているのが分かります。 $ ruby print_bin.rb > local.bin $ hexdump -C local.bin 00000000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f |................| 00000010 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f |................| 00000020 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f | !"#$%&'()*+,-./| 00000030 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f |0123456789:;<=>?| 00000040 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f |@ABCDEFGHIJKLMNO| 00000050 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f |PQRSTUVWXYZ[\]^_| 00000060 60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f |`abcdefghijklmno| 00000070 70 71 72 73 74 75 76 77 78 79 7a 7b 7c 7d 7e 7f |pqrstuvwxyz{|}~.| 00000080 80 81 82 83 84 85 86 87 88 89 8a 8b 8c 8d 8e 8f |................| 00000090 90 91 92 93 94 95 96 97 98 99 9a 9b 9c 9d 9e 9f |................| 000000a0 a0 a1 a2 a3 a4 a5 a6 a7 a8 a9 aa ab ac ad ae af |................| 000000b0 b0 b1 b2 b3 b4 b5 b6 b7 b8 b9 ba bb bc bd be bf |................| 000000c0 c0 c1 c2 c3 c4 c5 c6 c7 c8 c9 ca cb cc cd ce cf |................| 000000d0 d0 d1 d2 d3 d4 d5 d6 d7 d8 d9 da db dc dd de df |................| 000000e0 e0 e1 e2 e3 e4 e5 e6 e7 e8 e9 ea eb ec ed ee ef |................| 000000f0 f0 f1 f2 f3 f4 f5 f6 f7 f8 f9 fa fb fc fd fe ff |................| 00000100 では、Podmanで動かした出力をリダイレクトさせてみたものを確認するとどうなっているかといいますと、 0x09の後に0x0dが増えてしまっており、ファイルの中身が壊れていることがわかります。 $ podman run -it --rm -v "$PWD":/x -w /x ruby:latest ruby print_bin.rb > podman.bin $ hexdump -C podman.bin 00000000 00 01 02 03 04 05 06 07 08 09 0d 0a 0b 0c 0d 0e |................| 00000010 0f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e |................| 00000020 1f 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e |. !"#$%&'()*+,-.| 00000030 2f 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e |/0123456789:;<=>| 00000040 3f 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e |?@ABCDEFGHIJKLMN| 00000050 4f 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e |OPQRSTUVWXYZ[\]^| 00000060 5f 60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e |_`abcdefghijklmn| 00000070 6f 70 71 72 73 74 75 76 77 78 79 7a 7b 7c 7d 7e |opqrstuvwxyz{|}~| 00000080 7f 80 81 82 83 84 85 86 87 88 89 8a 8b 8c 8d 8e |................| 00000090 8f 90 91 92 93 94 95 96 97 98 99 9a 9b 9c 9d 9e |................| 000000a0 9f a0 a1 a2 a3 a4 a5 a6 a7 a8 a9 aa ab ac ad ae |................| 000000b0 af b0 b1 b2 b3 b4 b5 b6 b7 b8 b9 ba bb bc bd be |................| 000000c0 bf c0 c1 c2 c3 c4 c5 c6 c7 c8 c9 ca cb cc cd ce |................| 000000d0 cf d0 d1 d2 d3 d4 d5 d6 d7 d8 d9 da db dc dd de |................| 000000e0 df e0 e1 e2 e3 e4 e5 e6 e7 e8 e9 ea eb ec ed ee |................| 000000f0 ef f0 f1 f2 f3 f4 f5 f6 f7 f8 f9 fa fb fc fd fe |................| 00000100 ff |.| 00000101 この問題を回避するために、今度は以下のように-tオプションを外します。 無事に正しく出力できていることが分かります。 $ podman run -i --rm -v "$PWD":/x -w /x ruby:latest ruby print_bin.rb > no_t.bin wakairo@DESKTOP-633O7R3:~/tmp$ hexdump -C no_t.bin 00000000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f |................| 00000010 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f |................| 00000020 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f | !"#$%&'()*+,-./| 00000030 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f |0123456789:;<=>?| 00000040 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f |@ABCDEFGHIJKLMNO| 00000050 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f |PQRSTUVWXYZ[\]^_| 00000060 60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f |`abcdefghijklmno| 00000070 70 71 72 73 74 75 76 77 78 79 7a 7b 7c 7d 7e 7f |pqrstuvwxyz{|}~.| 00000080 80 81 82 83 84 85 86 87 88 89 8a 8b 8c 8d 8e 8f |................| 00000090 90 91 92 93 94 95 96 97 98 99 9a 9b 9c 9d 9e 9f |................| 000000a0 a0 a1 a2 a3 a4 a5 a6 a7 a8 a9 aa ab ac ad ae af |................| 000000b0 b0 b1 b2 b3 b4 b5 b6 b7 b8 b9 ba bb bc bd be bf |................| 000000c0 c0 c1 c2 c3 c4 c5 c6 c7 c8 c9 ca cb cc cd ce cf |................| 000000d0 d0 d1 d2 d3 d4 d5 d6 d7 d8 d9 da db dc dd de df |................| 000000e0 e0 e1 e2 e3 e4 e5 e6 e7 e8 e9 ea eb ec ed ee ef |................| 000000f0 f0 f1 f2 f3 f4 f5 f6 f7 f8 f9 fa fb fc fd fe ff |................| 00000100 この問題を回避するために、今度は以下のようにbash -cを使ってみます。 こちらでも無事に正しく出力できていることが分かります。 $ podman run -it --rm -v "$PWD":/x -w /x ruby:latest bash -c 'ruby print_bin.rb > bash.bin' $ hexdump -C bash.bin 00000000 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f |................| 00000010 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f |................| 00000020 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f | !"#$%&'()*+,-./| 00000030 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f |0123456789:;<=>?| 00000040 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f |@ABCDEFGHIJKLMNO| 00000050 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f |PQRSTUVWXYZ[\]^_| 00000060 60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f |`abcdefghijklmno| 00000070 70 71 72 73 74 75 76 77 78 79 7a 7b 7c 7d 7e 7f |pqrstuvwxyz{|}~.| 00000080 80 81 82 83 84 85 86 87 88 89 8a 8b 8c 8d 8e 8f |................| 00000090 90 91 92 93 94 95 96 97 98 99 9a 9b 9c 9d 9e 9f |................| 000000a0 a0 a1 a2 a3 a4 a5 a6 a7 a8 a9 aa ab ac ad ae af |................| 000000b0 b0 b1 b2 b3 b4 b5 b6 b7 b8 b9 ba bb bc bd be bf |................| 000000c0 c0 c1 c2 c3 c4 c5 c6 c7 c8 c9 ca cb cc cd ce cf |................| 000000d0 d0 d1 d2 d3 d4 d5 d6 d7 d8 d9 da db dc dd de df |................| 000000e0 e0 e1 e2 e3 e4 e5 e6 e7 e8 e9 ea eb ec ed ee ef |................| 000000f0 f0 f1 f2 f3 f4 f5 f6 f7 f8 f9 fa fb fc fd fe ff |................| 00000100
rails 7.1からrails 7.2への移行（アップデート、アップグレード）で必要な作業
rails 7.2への移行におけるActive Storageのmigration
bin/rails app:updateコマンドを実行すると以下の3つのファイルがdb/migrate/に作成されることがありますが、Active Storageをまだ使用したことがないアプリケーションでは、 これら3つのファイルは単純に削除してしまっても良いはずです。
より正確に言うと、データベースに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つのファイルは削除で大丈夫のはずです。ちなみに、データベースにあるテーブルの一覧を見たい場合には
bin/rails consoleでActiveRecord::Base.connection.tablesを叩くことでテーブルの一覧を確認できます。rails 7.1からrails 7.2への移行（アップデート、アップグレード）で必要な作業
rails 7.2でのconfig/puma.rbの大幅な更新
rails newで生成されるconfig/puma.rbが大幅に更新されました。主要な変更点は以下の通りです。
threadsの指定方法の変更: リリースノート：Pumaのデフォルトのスレッド数が新しくなった、PR #50450 、PR #50669pidfileの変更: PR #50644、PR #50669、commit 57a6916environmentの削除: PR #52541workersの削除: commit 142e6abpreload_app!の削除: PR #52541worker_timeoutの削除: PR #52541rails 7.1からrails 7.2への移行（アップデート、アップグレード）で必要な作業
rails 7.2ではfilter_parametersに:emailが追加された
rails newで生成されるconfig/initializers/filter_parameter_logging.rbにおいて、 rails 7.2でconfig.filter_parametersに:emailが追加されました。 この追加に関するプルリクエストはこちらです。セキュリティや個人情報保護の観点からは、確かにメールアドレスをフィルタすることは適切であるように思いますので、既存アプリにおいても:emailを追加すると良さそうです。
ちなみに、デバッグ作業などでメールアドレスを確認するときには少し不便になるような気もしますが、 emailへの直接の読み書きが疎外されるわけではありませんし、 またpluckなどの活用もすればデバッグの支障にはさほどならないような気がします。
rails 7.1からrails 7.2への移行（アップデート、アップグレード）で必要な作業
rails 7.2におけるpublic_file_server.enabled
rails newで生成されるconfig/environments/test.rbにおいて、 7.1以前は以下の設定用コードが存在していましたが、 このプルリクエストのマージによって削除されました。削除された理由は、このプルリクエストによると、default値がtrue、かつ、全てのenvironment（test、development、production）の間で設定値に違いが無いということからです。 ですので、既存アプリにおいても、設定値を
trueとしている場合には、この設定用コードは削除してしまっても良いかもしれません。rails 7.1からrails 7.2への移行（アップデート、アップグレード）で必要な作業
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内の当該設定を意図的に変更しなければ、既存アプリの挙動が勝手に変わることはありません。確かにdevelopment環境において便利そうな機能ですので、7.2へのアップデートを機に、使い始めてみるのも良いかもしれません。
rails 7.1からrails 7.2への移行（アップデート、アップグレード）で必要な作業
基本的にはRailsガイドの手順に従えば良いと思います。
ガイドの手順にもありますが、ぜひ
bin/rails app:updateコマンドを活用しましょう。rails 7.2への移行で対応が必要そうな個別の作業について、以下のコメントでそれぞれ取り上げますので、ご参考になれば幸いです。
PostgreSQLイメージとPodmanを利用した使い捨てのコンテナ環境
PostgreSQLに関した練習やテスト、実験などを行うときにPostgreSQLが動いている一時的な環境が欲しくなるときがあります。 PostgreSQLイメージとPodmanを利用すると、特定バージョンのPostgreSQLに関する一通りの操作ができる一時的なコンテナ環境を用意することが出来ます。
以下にコンテナ環境の作成、利用、削除の流れと方法を示します。
コンテナ環境の作成
以下の3つのコマンドを実行することで、PostgreSQLのコンテナ環境を作成し、クライアント側のコンテナのbash環境に入ることが出来ます。
なお、コマンド内の「16」のところはPostgreSQLのメジャーバージョンに相当しますので、ご利用になりたいバージョンの数に変更してください。 また、
-v "$PWD":/x -w /xのオプションにより、ホストOSのカレントディレクトリにコンテナ内からもアクセス出来る状態でbashが立ち上がります。 したがって、実験などに利用したいファイルをカレントディレクトリに置いてから以下のコマンドを実行すればコンテナ内でもそのファイルを利用できますし、 コンテナ内で/xのディレクトリに作成したファイルはコンテナ環境を終了した後もホストOSのカレントディレクトリに残ります。以下のようなプロンプトが表示されていれば成功です。クライアント側のコンテナのbash環境に入れました。
クライアント側のコンテナのbash環境の利用
このbash環境では、
psqlなどのPostgreSQLのコマンドを一通り利用することが出来ます。以下に例を示します。PostgreSQLのターミナルを開く例：
バックアップファイルを作成する例：
バックアップファイルをリストアする例：
クライアントのコンテナを終了しそのbash環境から退出する場合は
exitコマンドで抜けられます。 また、退出後にもう一度クライアントを使いたくなった場合は、後述のコンテナ環境全体の削除をまだしていなければ、 以下の3つめのコマンドだけ実行すれば、クライアントのコンテナをもう一度作成しそのbash環境に入ることが出来ます。コンテナ環境全体の削除
以下のコマンドで、コンテナ環境全体の停止と削除が実行できます。
HerokuでDBのアップデート等を行うときの作業の流れ
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 メジャーバージョンのアップグレードのテストをご覧ください。
Herokuでは環境変数DATABASE_URLを使ってrailsアプリが接続するDBの設定を行っている
railsのDB接続設定では、環境変数DATABASE_URLの情報が優先されます。
Herokuでは、環境変数DATABASE_URLへの設定を通してDB設定が行れています。また、このDB設定（つまり、DATABASE_URLの値）を変更したいときには
heroku pg:promoteコマンドを用います。なお、環境変数DATABASE_URLの現在の設定値は
heroku configコマンドで確認できます。tオプションを付けてPodmanからリダイレクトでバイナリ出力を取り出すと壊れる
概要
Podmanで、
-itオプション、厳密には-tオプションを付けっぱなしで、以下のようにリダイレクトを使うと、出力されたファイルの内容が壊れることがあります。-tオプションの意味を考えれば、出力をリダイレクトに回すときに指定する必要があるオプションではないのですが、コマンドを改変して流用するときなどに付けっぱなしにするとバイナリが壊れますのでご注意ください。この問題は、以下のようにtオプションを外すことで回避できます。もちろんiオプションを残さず合わせて外してもOKです。
また、この問題を回避方法として、以下のように、
bash -cを使う方法もあります。ちなみにこの問題は、Dockerでも起きるようです。
詳細
例として、0x00から0xffまでの256バイトのバイナリを標準出力に出力する以下のRubyスクリプトを利用します。
print_bin.rb
Podmanを使わずに、ローカルでこのスクリプトを実行して確認すると、以下のように正しく出力されているのが分かります。
では、Podmanで動かした出力をリダイレクトさせてみたものを確認するとどうなっているかといいますと、 0x09の後に0x0dが増えてしまっており、ファイルの中身が壊れていることがわかります。
この問題を回避するために、今度は以下のように
-tオプションを外します。 無事に正しく出力できていることが分かります。この問題を回避するために、今度は以下のように
bash -cを使ってみます。 こちらでも無事に正しく出力できていることが分かります。