okinawan_eats

config/deploy/staging.rb を追加する。ステージング用ドメイン、S3 バケット、メール設定を分けるか決めて設定する。

追記（2026-10-09）: 本番の RDS は MySQL 8.4（#716）にするので、ステージングもバージョンを揃える。

• 本番を RDS へ移した（#718）あとで、Lightsail の MySQL を 8.0 から 8.4 に上げる（本番稼働中は触らない）
• Ubuntu 22.04 の apt は 8.0 しかないので、MySQL 公式の APT リポジトリ（mysql-apt-config）で 8.4 LTS を入れる。8.0 から 8.4 は直接アップグレードできる
• unattended-upgrade で mysqld が再起動して Puma が落ちた件（#710）があるので、アップグレード後に Puma の自動復帰（Restart=always）も確認する

追記（2026-10-09）: OS も本番（#717 の EC2 は Ubuntu 24.04 LTS / arm64）に揃えて 24.04 にする。

• 今の Lightsail（okinawan-01）は imuge から流用した Ubuntu 22.04。do-release-upgrade での上書き更新より、24.04 の新しい Lightsail インスタンスを作り、infra/app_server/setup.sh で同じ手順で構築する方が安全（MySQL 8.4 もそのとき公式 APT リポジトリから入れる）
• 新しいインスタンスに切り替えたら、旧 okinawan-01 は止めて、スナップショットを取ってから削除する

追記（2026-10-09・#738 より）: Lightsail のファイアウォールの公開範囲を見直す。

• 22（SSH）が 0.0.0.0/0 に開いている。アクセス元の IP を絞る（または EC2 と同じく SSM で管理して閉じる）
• 3000（Puma）は #738 で閉じた。ステージング化のときも開けない
• 新しい 24.04 のインスタンスで作り直す場合も、公開ポートは 80・443（＋必要なら絞った 22）だけにする

追記（2026-10-09）: S3 バケットを本番とステージングで分ける（必須）。

• 今はアプリ用のバケットが okinawan-eats の 1 つだけ。CarrierWave の保存先は uploads/<モデル>/<カラム>/<レコード ID>/ なので、DB を分けたステージングで同じバケットを使うと、ステージングでの画像の差し替え・削除が本番の同じ ID のレコードの画像を上書き・削除してしまう
• 1. ステージング用バケット okinawan-eats-stg を Terraform（infra/s3.tf）で作る。暗号化は本番と同じ、パブリックアクセスは最初から全ブロック
• 2. ステージング用の IAM ユーザー（アクセスキー）を okinawan-eats-stg だけに権限を絞って作る（Lightsail はインスタンスロールが使えないため）。本番のキーはステージングに置かない
• 3. ステージングの config/x/carrierwave.yml（linked_files）を新しいバケットとキーに向ける
• 4. ステージングの DB を本番のコピーで作る場合は、画像も aws s3 sync s3://okinawan-eats s3://okinawan-eats-stg でコピーする