Rails: production環境のRailsコンソールではsandboxモードを指定しよう（翻訳）

Rails: production環境のRailsコンソールではsandboxモードを指定しよう（翻訳）

開発者として雇われていると、自分が取り組んでいるアプリケーションのproduction環境で特権アクセスを与えられることがよくあります。こうした特権は、バグ修正で必要なこともあれば、他の部署の代わりにコマンドを実行するときに必要な場合もあります。

しかし、大いなる力には、自分の足を撃ち抜いてしまう力ももれなく付いてきます。たとえ意図していなくても、いとも簡単にユーザーのデータを破壊的に変更できてしまいます。

ありがたいことに、Railsは素晴らしい保護機能を提供してくれます。しかし、この保護機能を使うには明示的に指定する必要があります。

🔗 以下のようにするのではなく

Railsコンソールを以下のようにフラグなしで実行する。

$ heroku run rails console

🔗 以下のようにしよう

Railsコンソールを実行するときに--sandboxフラグを指定する¹。

$ heroku run rails console --sandbox

これで、ログインするときにRailsコンソールのIRBプロンプトで以下のメッセージが表示されます。

Loading development environment in sandbox (Rails 7.0.6)
Any modifications you make will be rolled back on exit

🔗 そうする理由

現実の顧客データを恒久的に破壊しないためにも、どうか私を信じてください。production環境（およびstaging環境であっても）にログインするときは、--sandboxモードを指定する習慣をぜひ身に付けてください。

--sandboxモードを指定しておけば、コンソールを終了したときにデータの変更はすべて元に戻されます。これにより、誤って重大な問題を引き起こさずに済みます。データのクエリ（つまり読み取り専用アクセス）を行うだけであれば、このモードを指定することで、うっかり何かを永久に壊してしまう心配がなくなります。

注意: Sidekiqなどでジョブをエンキューするコードや、メールを送信するコードを呼び出す場合、--sandboxメカニズムではロールバックされません。どうぞ気をつけて！

🔗 そうしない理由があるとすれば

ユーザーデータを意図的に変更するためにproductionアプリケーションにログインする場合は、--sandboxモードを避ける必要があるでしょう。ただし、それでも実際に変更をかける前には、変更内容を--sandboxモードで必ずテストしておくことをおすすめします。

さらに、--sandboxの実装方法が元で、通常のproductionトラフィックでテーブルの行やテーブル全体がロックされるリスクがあることも忘れてはいけません。
これは、--sandboxモードがセッションの開始時にすべてをトランザクションとして扱い、ログアウト時にロールバックするようになっているためです。つまり、--sandboxモードを指定しても問題が生じる可能性があるのです（指摘してくれたWillに感謝いたします）。

実際にproductionでデータを変更するときは、Railsコンソールを適当にこねくりまわすよりも、データを変更するコードをきちんと書いてテストを重ね、それをデプロイする方がずっと良い方法です。production環境でrails consoleを実行することを怖いと思えるようになりましょう。

関連記事

Rails: Active Recordのメソッドに渡す文字列を式展開してはいけない（翻訳）

Rails: ルーティングを’only’や’except’オプションで整理する（翻訳）