見出し画像

【IT】HerokuでDjangoを“最短で正しく”公開する（第2回：運用の初期整備）

T A｜ITインフラ／写真と言葉／英語童話

皆さま、こんにちは

前回（第1回）に引き続きDjangoアプリケーションをHerokuへ公開する手順を記載します。

（第1回の続き。運用で最初に知っておくとラクになるポイントを、迷いどころと合わせてご説明します）


0. この回のゴール

  • ログとリリースの見方／戻し方を把握

  • Dyno のスケール／再起動 の基礎

  • カスタムドメイン + HTTPS（ACM） の導入ステップ

  • 日常運用で使う One-off dyno／Config Vars 操作 を手元に

1. ログとリリースの運用

1-1. ライブログを追う

heroku logs --tail -a yourapp

  • Router 行（`heroku[router]`）でリクエスト状況、`app[web.1]` でアプリ例外が読めます。

  • 絞り込み：`| grep ERROR`、`| grep -E "H10|H14|R14"` など。

1-2. リリース（デプロイ履歴）とロールバック

# リリース一覧（vNNN = "v+連番"）
heroku releases -a yourapp

# 特定版の詳細
heroku releases:info v125 -a yourapp

# その版へロールバック（その時のコード＝slugへ）
heroku rollback v123 -a yourapp

注意：ロールバックで戻るのは アプリのコード（slug）。DB の状態は戻りません（DB はバックアップ/リストアで対応）。
vNNN とは？ … リリースの連番です。Config Vars の変更やAdd-on 付与も「リリース」に記録されるため、履歴全体を見て状況を把握しましょう。

2. Dyno の基本操作（スケール／再起動）

# Web Dyno を1つに（最小構成の目安）
heroku ps:scale web=1 -a yourapp

# Dyno の再起動（設定変更の反映や軽障害のリカバリ）
heroku ps:restart -a yourapp

  • 小規模では web=1 で十分。挙動が怪しい／設定変更後は再起動して切り分けるのが早道。

3. カスタムドメイン & HTTPS（Heroku 標準 ACM）

3-1. 手順（落ち着いて順番に）

  1. Heroku Dashboard → Settings → Domains → Custom domain を追加

  2. 表示された DNS Target を、あなたの DNS で CNAME として設定

  3. 数分〜で ACM（自動証明書管理） により HTTPS 化

3-2. 反映後にやること（忘れがち）

  • `ALLOWED_HOSTS` に 新ドメインを追加（`www.` あり/なし両方使うなら両方）

  • 本ミニ連載では CSRF は ALLOWED_HOSTS から https で自動生成 しているため、ここだけ合わせれば整合が取れます

補足（ルートドメイン運用）
多くの DNS ではサブドメインは CNAME 可、ルートは ALIAS/ANAME 等の仕組みで解決します。迷ったら、`www` を本命にして、ルートは DNS 側のリダイレクトで `www` へ送る構成が簡単です。
(wwwは、例のサブドメイン名です。）
 
ポイント：
DNS設定を置いてから反映までに時間がかかりますので
一旦設定したら、反映までしばらくお待ちください。

4. 管理者の“小技”まとめ（手元に置いておくと便利）

  • One-off dyno（一回だけコマンド実行）

heroku run --app yourapp -- python manage.py shell

  • Config Vars を CLI でまとめ設定

heroku config:set \
  DEBUG=false \
  SECRET_KEY='your-production-secret' \
  ALLOWED_HOSTS='yourapp.herokuapp.com,example.com' \
  -a yourapp

  • 静的ファイルを再収集（テーマ変更や大きな追加後）

heroku run --app yourapp -- python manage.py collectstatic --noinput

  • メンテナンスモード

heroku maintenance:on  -a yourapp

# 作業...

heroku maintenance:off -a yourapp

5. よくある質問

Q. なぜ Whitenoise？ CDN や S3 を最初から使わないの？
A. 小〜中規模では 追加インフラ不要で十分高速。将来 S3+CDN に移しても差分は限定的で、段階導入しやすいです。

Q. `SECURE_PROXY_SSL_HEADER` は設定しないの？
A. 最小構成では未設定です。`request.is_secure()` を厳密に扱う場面や追加セキュリティ設定が増えた段階で個別に導入してください。

Q. collectstatic は自動と手動どっちが良い？
A. 最初は手動で成功パターンを確認 → 安定後は自動任せでもOK。失敗時の切り分けが容易です。
（自動を止めたいときのみ `DISABLE_COLLECTSTATIC=1`。常用は非推奨）

Q. CSRF で詰まります
A. 多くは `ALLOWED_HOSTS` の列挙漏れです。本記事の方式では ALLOWED_HOSTS→https 付きで自動生成 なので、使う全ホスト（`www` 有/無も含め）を入れてください。

Q. Dyno に置いたファイルが消える
A. Dyno のローカルは揮発です。恒久ファイルは外部ストレージ（S3 等）へ置きます。

6. トラブル対応の基本の流れ（Runbook）

  1. `heroku logs --tail` で症状を把握（エラー行・スタックトレース）

  2. 設定を疑う（`heroku config`／`ALLOWED_HOSTS`／`DEBUG=false`）

  3. 依存関係を疑う（`requirements.txt`／`gunicorn` があるか）

  4. 一度再起動（`heroku ps:restart`）

  5. 直らないときは One-off で個別コマンド実行（`migrate` 等）して切り分け

  6. コード起因なら リリースを戻す（`heroku releases` → `rollback vNNN`）

7. まとめ（第2回）

  • 運用の初手（ログ／リリース／Dyno 管理）を把握

  • カスタムドメイン＆HTTPS（ACM） → ALLOWED_HOSTS 更新で CSRF 自動整合

  • これで “Heroku で正しく公開して、最初の運用が回る” 状態まで到達です

では
また！

前回の記事

過去の記事

いいなと思ったら応援しよう！