デプロイ ― 本番公開の勘どころ

導入

runserver は開発専用です。実際にインターネットへ公開するときは、本番用のサーバー構成と、いくつかの設定変更が必要になります。全体像をつかんでおきましょう。

説明

本番の構成は、こんな形が定番です。

flowchart LR
  U["利用者<br/>ブラウザ"] --> N["Nginx<br/>（受付・静的配信・HTTPS）"]
  N --> G["Gunicorn / uWSGI<br/>（アプリサーバー）"]
  G --> D["Django<br/>（あなたのコード）"]
  D --> DB[("PostgreSQL<br/>本番DB")]
  N --> S["静的ファイル<br/>CSS/JS/画像"]

• Nginx（ウェブサーバー） … 最前面で受付。HTTPS 化、静的ファイル配信、負荷分散を担当。
• Gunicorn / uWSGI（アプリサーバー） … Django を動かすプロセス。runserver の本番版。Django が用意する WSGI（同期）や ASGI（非同期）の接続口（wsgi.py / asgi.py）を通して起動します。
• PostgreSQL … 本番では SQLite ではなく PostgreSQL や MySQL を使うのが一般的。

pip install gunicorn
gunicorn mysite.wsgi   # 本番はこれで起動（runserver ではない）

公開前の必須チェック（settings.py）：

DEBUG = False                          # 本番では必ず False（エラー詳細を隠す）
ALLOWED_HOSTS = ["example.com"]        # 自分のドメインを列挙
SECRET_KEY = os.environ["SECRET_KEY"]  # コードに直書きせず環境変数から
DATABASES = { ... }                    # 本番DB（PostgreSQL など）へ

• DEBUG = False … これを忘れるとエラー画面から内部情報が漏れます。最重要。
• ALLOWED_HOSTS … 許可するドメインを指定（DEBUG=False では必須）。
• SECRET_KEY … 秘密の鍵。Git に入れず、環境変数で渡します。
• 静的ファイルの収集 … 本番では散らばった static/ を1か所に集めます。

python manage.py collectstatic   # 全アプリの静的ファイルを STATIC_ROOT へ集約
python manage.py migrate         # 本番DBにテーブルを作成

デプロイ先の選択肢：

• PaaS（手軽） … Render、Railway、Fly.io、Heroku など。Git push するだけで公開できるものが多い。
• VPS（自由） … さくらのVPS、AWS EC2 などにサーバーを借り、Nginx＋Gunicorn を自分で構成。
• コンテナ … Docker イメージにして、クラウド（AWS ECS、Google Cloud Run など）で動かす。

公開前チェックリスト（Django が用意するコマンド）：

python manage.py check --deploy   # 本番設定の問題点を自動診断

最初は PaaS で「とにかく公開してみる」のがおすすめです。DEBUG=False・ALLOWED_HOSTS・SECRET_KEY の3点さえ押さえれば、まずは安全に外へ出せます。