Djangoアプリを公開！Nginx連携によるデプロイ実践ガイド

By /

Djangoアプリを公開！Nginx連携によるデプロイ実践ガイド

はじめに

Djangoアプリケーションを開発環境で動かすのは簡単ですが、それをインターネット上に公開し、安定かつ安全に稼働させる「本番デプロイ」は、全く異なる一連の課題を伴います。開発サーバーである python manage.py runserver は開発目的に特化しており、実際のプロダクション環境での高負荷、セキュリティ、パフォーマンスには対応できません。

本ガイドでは、Djangoアプリケーションを本番環境で公開するための最も一般的で堅牢な構成である「Nginx + Gunicorn」を用いたデプロイ方法を、詳細かつ実践的に解説します。サーバーの準備から、各コンポーネントの設定、SSL/TLSによるHTTPS化、そしてデプロイ後の運用・保守、さらにはトラブルシューティングまで、ステップバイステップで網羅します。

なぜNginxとGunicornなのか？

  • Gunicorn (Green Unicorn): DjangoのようなPython Webアプリケーションは、WSGI (Web Server Gateway Interface) という標準インターフェースを通じてWebサーバーと通信します。GunicornはWSGIサーバーの一種で、Pythonアプリケーションのプロセス管理やリクエストの処理を行います。Python製のサーバーであるため、Djangoアプリケーションとの相性が非常に良いのが特徴です。
  • Nginx (Engine X): Nginxは、高性能なWebサーバーであり、リバースプロキシサーバーとしても機能します。クライアントからのHTTP/HTTPSリクエストを最初に受け取り、必要に応じてGunicornに転送します。また、HTML、CSS、JavaScript、画像などの静的ファイルを直接配信することで、Gunicorn（ひいてはDjango）の負荷を軽減し、高速なレスポンスを実現します。SSL/TLSの終端もNginxが行うことが一般的です。

この組み合わせにより、Djangoアプリケーションは効率的にリクエストを処理し、Nginxが静的ファイルの配信とセキュリティ（SSLなど）を担うことで、堅牢でスケーラブルなシステムを構築できます。

この記事で学ぶこと

  • Djangoアプリケーションを本番環境に最適化する方法
  • GunicornをWSGIサーバーとしてセットアップし、systemdで管理する方法
  • Nginxをリバースプロキシとして設定し、静的ファイルとメディアファイルを配信する方法
  • CertbotとLet’s Encryptを使って無料でSSL/TLS（HTTPS）を設定する方法
  • ファイアウォールの設定と基本的なセキュリティ対策
  • デプロイ後のトラブルシューティングと運用管理のヒント

さあ、あなたのDjangoアプリケーションを世界に公開する旅を始めましょう！

1. Djangoデプロイの基礎知識

本番環境へのデプロイを開始する前に、いくつか重要な概念を理解しておく必要があります。

1.1. 開発環境と本番環境の違い

  • 開発環境: 開発者がコードを書いたりテストしたりするための環境です。Djangoの runserver はこの目的のために設計されており、開発の利便性を優先しています。しかし、シングルスレッドで動作し、静的ファイルの配信も内部で行うため、多数の同時接続やセキュリティ、パフォーマンスの面で本番利用には不向きです。
  • 本番環境: 実際にユーザーがアクセスする環境です。ここでは、アプリケーションの安定性、セキュリティ、パフォーマンス、可用性が最優先されます。これらを達成するために、専用のWebサーバー（Nginx）、WSGIサーバー（Gunicorn）、データベース、そして適切な設定が必要になります。

1.2. WSGI (Web Server Gateway Interface) とは？

WSGIは、PythonのWebサーバーとPythonのWebアプリケーション（Django, Flaskなど）の間で通信を行うための標準インターフェースです。WSGIが登場するまで、PythonアプリケーションとWebサーバーはそれぞれ独自の接続方法を持っていましたが、WSGIによって共通の「言語」が提供され、WebサーバーはWSGIに準拠した任意のPythonアプリケーションと通信できるようになりました。

GunicornはWSGIサーバーの一種であり、クライアントからのリクエストをNginxが受け取った後、NginxからGunicornにリクエストが転送され、GunicornがDjangoアプリケーションのWSGIエントリポイント (your_project/wsgi.py) を呼び出して、Djangoがレスポンスを生成します。

1.3. 静的ファイルとメディアファイルの扱い

Djangoアプリケーションは、CSS、JavaScript、画像などの静的ファイルや、ユーザーがアップロードする画像やファイルなどのメディアファイルを扱います。

  • 開発環境: DEBUG = True の場合、Djangoは runserver コマンドで静的ファイルとメディアファイルを自動的に配信します。
  • 本番環境: DEBUG = False に設定するため、Django自身は静的ファイルやメディアファイルを配信しません。これらはWebサーバー（Nginx）が直接配信する役割を担います。これにより、Djangoアプリケーションの負荷を軽減し、配信速度を向上させます。
    • STATIC_ROOT: Djangoが collectstatic コマンドで全ての静的ファイルを収集し、一元的に配置するディレクトリです。Nginxはこのディレクトリ内のファイルを配信します。
    • MEDIA_ROOT: ユーザーがアップロードしたメディアファイルが保存されるディレクトリです。Nginxはこのディレクトリ内のファイルを配信します。

1.4. プロセス管理 (systemd)

Gunicornのようなバックグラウンドで動作するサービスは、サーバー起動時に自動的に立ち上がり、クラッシュした際には自動的に再起動されるように管理する必要があります。Linuxシステムでは、systemd がこの役割を担う標準的なツールです。systemdサービスファイルを作成することで、Gunicornの起動、停止、再起動、状態確認などを効率的に行えます。

2. 前提条件とサーバーの準備

デプロイを開始する前に、必要な環境とツールをセットアップしましょう。

2.1. サーバーの選定とOS

  • サーバー: VPS (Virtual Private Server) や、AWS EC2, Google Cloud Compute Engine, Azure Virtual Machines などのクラウドインスタンスを使用するのが一般的です。この記事では、任意のLinuxベースのサーバーを想定します。
  • OS: Ubuntu Server (LTS版) を推奨します。デプロイに必要なパッケージのインストールや設定が比較的容易です。CentOSやAlmaLinuxでも同様の概念でデプロイ可能ですが、コマンドや設定ファイルのパスが一部異なります。本ガイドではUbuntuを前提に説明します。

2.2. SSH接続の確立

サーバーにアクセスするためにはSSH (Secure Shell) を使用します。

  1. サーバーのIPアドレスとユーザー名を確認: プロバイダから提供されます。
  2. SSHクライアントで接続:
    bash
    ssh your_username@your_server_ip
    初回接続時には、サーバーのフィンガープリントが聞かれる場合がありますので、yes と入力して続行します。

2.3. システムのアップデートと基本的なツールのインストール

サーバーにログインしたら、まずはパッケージリストを更新し、システムを最新の状態に保ちます。

bash
sudo apt update
sudo apt upgrade -y

必要な基本的なツールをインストールします。

bash
sudo apt install -y python3-pip python3-venv git nginx curl ufw

  • python3-pip: Pythonパッケージのインストールに必要です。
  • python3-venv: 仮想環境の作成に必要です。
  • git: Djangoプロジェクトをサーバーにクローンするために必要です。
  • nginx: Webサーバー/リバースプロキシです。
  • curl: 外部との通信確認などに利用します。
  • ufw: ファイアウォール管理ツールです。

2.4. データベースの準備

Djangoアプリケーションは通常データベースを使用します。PostgreSQLがDjangoと相性が良く、本番環境でよく利用されます。

PostgreSQLのインストールと設定 (PostgreSQLの場合)

  1. PostgreSQLのインストール:
    bash
    sudo apt install -y postgresql postgresql-contrib
  2. PostgreSQLの起動確認:
    bash
    sudo systemctl start postgresql
    sudo systemctl enable postgresql
    sudo systemctl status postgresql

  3. PostgreSQLユーザーの作成:
    PostgreSQLはデフォルトで postgres というスーパーユーザーを作成します。このユーザーで対話的に接続し、Djangoプロジェクト用のデータベースユーザーとデータベースを作成します。
    bash
    sudo -i -u postgres
    psql
    PostgreSQLのプロンプト postgres=# が表示されます。

  4. データベースユーザーの作成: 強力なパスワードを設定してください。
    sql
    CREATE USER myuser WITH PASSWORD 'my_strong_password';
    myuser と my_strong_password は、Djangoのsettings.pyで設定する値に合わせて変更してください。

  5. データベースの作成: 作成したユーザーが所有者となるようにします。
    sql
    CREATE DATABASE myprojectdb OWNER myuser;
    myprojectdb は、Djangoのsettings.pyで設定するデータベース名に合わせて変更してください。

  6. データベースの権限付与:
    sql
    GRANT ALL PRIVILEGES ON DATABASE myprojectdb TO myuser;

  7. PostgreSQLからログアウト:
    sql
    \q
    通常のシェルに戻ります。

これでDjangoアプリケーションがデータベースに接続できるようになりました。

2.5. Djangoプロジェクトのクローンと仮想環境のセットアップ

サーバー上にDjangoプロジェクトを配置します。

  1. プロジェクトディレクトリの作成: 通常、/var/www/ 以下に配置します。
    bash
    sudo mkdir -p /var/www/your_project_name
    sudo chown your_username:your_username /var/www/your_project_name
    cd /var/www/your_project_name
    your_project_name はあなたのプロジェクト名に合わせて変更してください。

  2. Gitリポジトリからプロジェクトをクローン:
    bash
    git clone your_repository_url .
    . を指定することで、現在のディレクトリにクローンされます。SSHキーやユーザー名/パスワードの入力が求められる場合があります。

  3. 仮想環境の作成とアクティベート:
    bash
    python3 -m venv venv
    source venv/bin/activate
    プロンプトの先頭に (venv) と表示されれば成功です。

  4. Python依存パッケージのインストール: Djangoプロジェクトの requirements.txt に基づいてインストールします。
    bash
    pip install -r requirements.txt
    requirements.txt には、Django, gunicorn, psycopg2-binary (PostgreSQLの場合) など、プロジェクトで必要な全てのパッケージが記載されている必要があります。

    例: requirements.txt の内容
    Django==4.2
    gunicorn==21.2.0
    psycopg2-binary==2.9.9
    Pillow==10.1.0 # 画像処理が必要な場合
    ...

3. Djangoプロジェクトの設定

本番環境で正しく動作させるために、Djangoプロジェクトの settings.py ファイルを調整する必要があります。

3.1. settings.py の本番環境向け変更点

Djangoプロジェクトのルートディレクトリにある your_project_name/settings.py を開きます。

bash
nano /var/www/your_project_name/your_project_name/settings.py

1. DEBUG = False

必須 です。本番環境では必ず False に設定してください。
True のままでは、セキュリティ上の重大な脆弱性（スタックトレースの表示、秘密情報漏洩など）が生じます。

“`python

your_project_name/settings.py

DEBUG = False # 開発中はTrue、本番では必ずFalseに
“`

2. ALLOWED_HOSTS の設定

アプリケーションが応答を許可するホスト名またはIPアドレスのリストを指定します。Nginxがリクエストを受け付け、Djangoに転送するため、Nginxがアクセスするドメイン名またはIPアドレスをここに追加します。

python
ALLOWED_HOSTS = ['your_server_ip_address', 'your_domain.com', 'www.your_domain.com']
your_server_ip_address はサーバーのIPアドレスに、your_domain.com はあなたのドメイン名に置き換えてください。

3. STATIC_URL, STATIC_ROOT, MEDIA_URL, MEDIA_ROOT の設定

静的ファイルとメディアファイルの配信はNginxに任せるため、Djangoがこれらを収集する場所と、Web上でアクセスされるURLパスを設定します。

“`python
import os

Build paths inside the project like this: BASE_DIR / ‘subdir’.

BASE_DIR = Path(file).resolve().parent.parent

静的ファイルのURLパス

STATIC_URL = ‘static/’

静的ファイルの収集先ディレクトリ (Nginxが配信する)

STATIC_ROOT = os.path.join(BASE_DIR, ‘staticfiles’)

メディアファイルのURLパス

MEDIA_URL = ‘media/’

メディアファイルの保存先ディレクトリ (Nginxが配信する)

MEDIA_ROOT = os.path.join(BASE_DIR, ‘mediafiles’)
``
*STATIC_ROOTとMEDIA_ROOTは、プロジェクトのルートディレクトリからの相対パスで指定します。例えば、プロジェクトのトップレベルにstaticfilesとmediafiles` というディレクトリが作成されます。*

4. DATABASES の設定

本番データベースの設定に更新します。環境変数や外部ファイルから読み込むのがベストプラクティスですが、ここでは直接記述する例を示します。

python
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.postgresql', # MySQLの場合は 'django.db.backends.mysql'
'NAME': 'myprojectdb', # 上記で作成したデータベース名
'USER': 'myuser', # 上記で作成したデータベースユーザー名
'PASSWORD': 'my_strong_password', # 上記で設定したパスワード
'HOST': 'localhost', # データベースが同じサーバー上にある場合
'PORT': '', # デフォルトポート (空でOK)
}
}

5. SECRET_KEY の管理

SECRET_KEY は非常に重要で、絶対に公開してはいけません。本番環境では、環境変数から読み込むのが一般的です。

“`python
import os

…

SECRET_KEY = os.environ.get(‘DJANGO_SECRET_KEY’, ‘default-insecure-key-for-development’)
``
そして、サーバーの環境変数としてDJANGO_SECRET_KEY` を設定します。これは後述のGunicornサービスファイル内で設定することも可能です。

6. CSRF_TRUSTED_ORIGINS の設定

DjangoのCSRF保護は、信頼できるオリジンからのPOSTリクエストのみを許可します。本番環境のドメインを追加します。

python
CSRF_TRUSTED_ORIGINS = ['https://your_domain.com', 'https://www.your_domain.com']

7. ロギングの設定 (オプション)

本番環境ではログを適切に管理することが重要です。ファイルにログを出力するように設定します。

“`python
LOGGING = {
‘version’: 1,
‘disable_existing_loggers’: False,
‘handlers’: {
‘file’: {
‘level’: ‘INFO’,
‘class’: ‘logging.handlers.RotatingFileHandler’,
‘filename’: os.path.join(BASE_DIR, ‘logs’, ‘django.log’),
‘maxBytes’: 1024 * 1024 * 5, # 5 MB
‘backupCount’: 5,
‘formatter’: ‘verbose’,
},
},
‘formatters’: {
‘verbose’: {
‘format’: ‘{levelname} {asctime} {module} {process:d} {thread:d} {message}’,
‘style’: ‘{‘,
},
},
‘loggers’: {
‘django’: {
‘handlers’: [‘file’],
‘level’: ‘INFO’,
‘propagate’: True,
},
},
}

logsディレクトリを作成

if not os.path.exists(os.path.join(BASE_DIR, ‘logs’)):
os.makedirs(os.path.join(BASE_DIR, ‘logs’))
``
*os.makedirs(os.path.join(BASE_DIR, ‘logs’))の部分は、settings.py` が評価されるタイミングではなく、デプロイ時にログディレクトリが存在するか確認し、なければ作成するスクリプトとして実行するのが適切です。例えば、デプロイスクリプトに含めるか、手動で作成します。*

3.2. collectstatic の実行

settings.py の変更を保存したら、Djangoの静的ファイルを STATIC_ROOT で指定したディレクトリに収集します。

プロジェクトの仮想環境がアクティブな状態で実行してください。

bash
cd /var/www/your_project_name
source venv/bin/activate
python manage.py collectstatic
yes と入力して続行します。これにより、/var/www/your_project_name/staticfiles/ ディレクトリ以下に全ての静的ファイルがコピーされます。

3.3. データベースマイグレーションの実行

データベースの変更を適用します。

bash
python manage.py migrate

これでDjangoプロジェクトの準備は整いました。

4. Gunicornの設定とテスト

Gunicornは、Nginxからのリクエストを受け取り、Djangoアプリケーションに転送するWSGIサーバーです。ここではGunicornをセットアップし、systemd を使ってサービスとして管理します。

4.1. Gunicornとは？なぜ必要か？

Gunicornは、Pythonで書かれたWSGI (Web Server Gateway Interface) サーバーです。DjangoのようなPythonアプリケーションは、WSGIという標準仕様に準拠しており、GunicornはそのWSGIアプリケーションを実行するためのランタイム環境を提供します。

開発サーバー (runserver) はシングルスレッドで動くため、同時アクセスに弱く、静的ファイルの配信などもDjango自身が行うため非効率です。Gunicornは複数のワーカープロセスを起動し、並列にリクエストを処理することで、本番環境での高い同時接続数と安定性を実現します。

NginxがWebサーバーとしてクライアントからのリクエストを受け付け、それを内部的にGunicornに転送（プロキシ）することで、Nginxが静的ファイルの配信やSSL終端、負荷分散を担当し、Gunicornが純粋にPythonアプリケーションの処理に集中できるという役割分担ができます。

4.2. Gunicornのインストール

すでに requirements.txt に含まれているはずですが、念のため確認またはインストールします。

“`bash

プロジェクトの仮想環境がアクティブなことを確認 (venv)

pip install gunicorn
“`

4.3. Gunicornのテスト実行

GunicornがDjangoプロジェクトを正しく起動できるかテストします。

bash
cd /var/www/your_project_name
source venv/bin/activate
gunicorn --bind 0.0.0.0:8000 your_project_name.wsgi:application
your_project_name は、settings.py などがある親ディレクトリ名（プロジェクトのルートモジュール名）に置き換えてください。

成功すると、以下のような出力が表示されます。

[INFO] Starting gunicorn 21.2.0
[INFO] Listening at: http://0.0.0.0:8000 (PID: 12345)
[INFO] Using worker: sync
[INFO] Booting worker with pid: 12348
この状態で、サーバーのIPアドレスとポート8000 (http://your_server_ip_address:8000) にWebブラウザからアクセスしてみてください。Djangoのページが表示されれば成功です。

テストが成功したら、Ctrl+C でGunicornを停止します。

4.4. Gunicornのsystemdサービス設定

Gunicornをバックグラウンドで永続的に実行し、サーバー起動時に自動的に立ち上がるようにするため、systemdサービスを作成します。

1. Gunicornソケットファイル (gunicorn.socket) の作成

gunicorn.socket ファイルは、NginxとGunicornの間で通信するためのUNIXソケットを定義します。TCPポートではなくUNIXソケットを使用する方が、同じサーバー上での通信においてはパフォーマンスが良く、安全です。

bash
sudo nano /etc/systemd/system/gunicorn.socket
以下の内容を記述します。

“`ini
[Unit]
Description=gunicorn socket

[Socket]
ListenStream=/run/gunicorn.sock

[Install]
WantedBy=sockets.target
``
*ListenStream=/run/gunicorn.sock` は、GunicornがリッスンするUNIXソケットのパスを指定しています。*

2. Gunicornサービスファイル (gunicorn.service) の作成

gunicorn.service ファイルは、Gunicornをどのように起動するか、どのユーザーで実行するかなどを定義します。

bash
sudo nano /etc/systemd/system/gunicorn.service
以下の内容を記述します。

“`ini
[Unit]
Description=Gunicorn daemon for your_project
Requires=gunicorn.socket
After=network.target

[Service]
User=your_username # あなたのSSHログインユーザー名
Group=www-data # Nginxが通常動作するグループ
WorkingDirectory=/var/www/your_project_name # プロジェクトのルートディレクトリ
ExecStart=/var/www/your_project_name/venv/bin/gunicorn \
–access-logfile – \
–workers 3 \
–bind unix:/run/gunicorn.sock \
your_project_name.wsgi:application

ExecReload=/bin/kill -s HUP $MAINPID
KillMode=mixed
TimeoutStopSec=5
PrivateTmp=true

Environment=”DJANGO_SECRET_KEY=your_actual_secret_key” # 環境変数でSECRET_KEYを設定
Environment=”DB_NAME=myprojectdb”
Environment=”DB_USER=myuser”
Environment=”DB_PASSWORD=my_strong_password”

必要な環境変数を追加

[Install]
WantedBy=multi-user.target
“`
重要な設定項目:

  • User: Gunicornプロセスを実行するユーザー。セキュリティのため、root 以外のユーザー（あなたのSSHログインユーザーなど）を指定します。
  • Group: Gunicornプロセスが所属するグループ。Nginxがアクセスできるように www-data を指定するのが一般的です。
  • WorkingDirectory: Djangoプロジェクトのルートディレクトリです。manage.py がある場所を指定します。
  • ExecStart: Gunicornを起動するためのコマンドです。
    • /var/www/your_project_name/venv/bin/gunicorn: 仮想環境内のGunicorn実行可能ファイルへのパスです。
    • --access-logfile -: 標準出力にアクセスログを出力します (systemdがログを管理)。
    • --workers 3: Gunicornのワーカープロセス数。CPUコア数の (2 * コア数) + 1 が目安とされますが、サーバーのリソースとアプリケーションの特性に合わせて調整してください。
    • --bind unix:/run/gunicorn.sock: Nginxが接続するUNIXソケットのパスです。
    • your_project_name.wsgi:application: DjangoプロジェクトのWSGIエントリポイントです。your_project_name はDjangoプロジェクトのルートモジュール名です。
  • Environment: Django settings.py で os.environ.get() を使って読み込む環境変数をここで設定できます。特に DJANGO_SECRET_KEY は重要です。本番環境用の実際のキーを設定してください。

3. systemdサービスの有効化と起動

Gunicornサービスとソケットを有効化し、起動します。

bash
sudo systemctl daemon-reload # systemd設定をリロード
sudo systemctl start gunicorn.socket # ソケットを起動
sudo systemctl enable gunicorn.socket # サーバー起動時にソケットが自動起動するように設定
sudo systemctl start gunicorn # Gunicornサービスを起動
sudo systemctl enable gunicorn # サーバー起動時にGunicornサービスが自動起動するように設定

4. Gunicornのステータス確認

Gunicornが正しく動作しているか確認します。

bash
sudo systemctl status gunicorn
active (running) と表示されていれば成功です。

bash
sudo systemctl status gunicorn.socket
こちらも active (running) と表示されていることを確認してください。

また、ソケットファイルが作成されているかも確認します。

bash
ls -l /run/gunicorn.sock
srwxrwxrwx 1 root root ... のように表示されればOKです。

もしエラーが表示された場合は、Gunicornのログを確認します。
bash
sudo journalctl -u gunicorn
sudo journalctl -u gunicorn.socket
ログからエラーの原因を特定し、修正してください。よくある問題は、パスの誤り、パーミッションの問題、Python依存関係の不足などです。

5. Nginxの設定

NginxをWebサーバー兼リバースプロキシとして設定し、クライアントからのリクエストを処理し、必要に応じてGunicornに転送するようにします。

5.1. Nginxとは？なぜ必要か？

Nginxは、オープンソースで高性能なHTTPサーバーおよびリバースプロキシサーバーです。その高いパフォーマンスと安定性から、多くの大規模なWebサイトで利用されています。

  • リバースプロキシ: クライアントからのリクエストを直接受け取り、内部の別のサーバー（この場合はGunicorn）にリクエストを転送し、そのレスポンスをクライアントに返す役割をします。これにより、Gunicorn（Django）を外部から直接アクセスできないようにし、セキュリティを高めます。また、NginxがSSL終端やロードバランシングを行うことで、Gunicornの負担を軽減できます。
  • 静的ファイル配信: HTML、CSS、JavaScript、画像などの静的ファイルを非常に高速に配信できます。これにより、Djangoアプリケーションが静的ファイルの配信にリソースを割く必要がなくなり、動的なコンテンツの生成に集中できます。
  • 負荷分散: 複数のGunicornインスタンス（サーバー）がある場合に、リクエストをそれらに分散させることができます（このガイドでは単一インスタンスですが、拡張性があります）。

5.2. Nginxのインストール

すでにインストール済みですが、念のため確認します。

bash
sudo apt install -y nginx

Nginxのサービスを有効化し、起動します。

bash
sudo systemctl start nginx
sudo systemctl enable nginx
sudo systemctl status nginx
active (running) と表示されていればOKです。

5.3. Nginx設定ファイルの構造

Nginxの設定ファイルは通常 /etc/nginx/ ディレクトリにあります。

  • /etc/nginx/nginx.conf: Nginxのメイン設定ファイルです。グローバルな設定や、他の設定ファイルをインクルードするディレクティブが含まれます。
  • /etc/nginx/sites-available/: 各Webサイト（バーチャルホスト）ごとの設定ファイルを保存するディレクトリです。
  • /etc/nginx/sites-enabled/: 有効化されたWebサイトの設定ファイルへのシンボリックリンクを保存するディレクトリです。Nginxはここにある設定ファイルを読み込みます。

5.4. Djangoアプリケーション向けNginx設定の作成

Djangoアプリケーション用の新しいNginx設定ファイルを作成します。

bash
sudo nano /etc/nginx/sites-available/your_project_name
以下の内容を記述します。

“`nginx
server {
listen 80;
server_name your_domain.com www.your_domain.com your_server_ip_address; # あなたのドメイン名とIPアドレスに置き換える

charset utf-8;
client_max_body_size 75M; # ファイルアップロードの最大サイズ

# 静的ファイルの配信設定
location /static/ {
    alias /var/www/your_project_name/staticfiles/; # collectstaticで集められた静的ファイルの場所
}

# メディアファイルの配信設定
location /media/ {
    alias /var/www/your_project_name/mediafiles/;  # ユーザーがアップロードしたメディアファイルの場所
}

# すべてのリクエストをGunicornにプロキシ
location / {
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_pass http://unix:/run/gunicorn.sock; # Gunicornソケットへのパス
}

}
“`

重要な設定項目:

  • listen 80;: HTTP (ポート80) でリッスンします。後でHTTPS (ポート443) にリダイレクトするように設定します。
  • server_name: Nginxがこの設定を適用するドメイン名を指定します。IPアドレスも指定しておくと、ドメイン解決前でもアクセス確認ができます。
  • charset utf-8;: 文字コードをUTF-8に設定します。
  • client_max_body_size 75M;: クライアントがアップロードできるリクエストボディの最大サイズです。ファイルアップロードがある場合に調整します。
  • location /static/: /static/ で始まるURLのリクエストを処理します。
    • alias /var/www/your_project_name/staticfiles/;: Nginxが /static/ のリクエストに対して /var/www/your_project_name/staticfiles/ ディレクトリ内のファイルを直接配信するように指示します。
  • location /media/: /media/ で始まるURLのリクエストを処理します。
    • alias /var/www/your_project_name/mediafiles/;: Nginxが /media/ のリクエストに対して /var/www/your_project_name/mediafiles/ ディレクトリ内のファイルを直接配信するように指示します。
  • location / { ... }: それ以外の全てのリクエストを処理します。
    • proxy_set_header ...: Gunicornに転送されるHTTPヘッダーを設定します。これにより、GunicornがクライアントのIPアドレスやプロトコルなどを正しく認識できます。
    • proxy_pass http://unix:/run/gunicorn.sock;: リクエストをGunicornのUNIXソケットに転送します。

5.5. Nginx設定の有効化

作成した設定ファイルを有効化するために、sites-enabled ディレクトリにシンボリックリンクを作成します。

bash
sudo ln -s /etc/nginx/sites-available/your_project_name /etc/nginx/sites-enabled/
デフォルトのNginx設定ファイルは無効化しておきましょう。

bash
sudo rm /etc/nginx/sites-enabled/default

5.6. Nginx設定のテストと再起動

Nginxの設定ファイルに構文エラーがないかテストします。

bash
sudo nginx -t
test is successful と表示されればOKです。エラーがあれば、nano で設定ファイルを修正してください。

設定が正しければ、Nginxサービスを再起動して新しい設定を適用します。

bash
sudo systemctl restart nginx

これで、WebブラウザからサーバーのIPアドレスまたはドメイン名にアクセスし、Djangoアプリケーションが表示されることを確認してください。静的ファイル（CSS、JS、画像）も正しくロードされているか確認します（開発者ツールでネットワークタブを確認すると良いでしょう）。

6. ファイアウォールの設定 (UFW)

サーバーへの不正アクセスを防ぐため、ファイアウォールを設定することは非常に重要です。UbuntuではUFW (Uncomplicated Firewall) が標準的です。

6.1. UFWの基本操作

  1. UFWのステータス確認:
    bash
    sudo ufw status
    通常は inactive です。

  2. デフォルトのルールを設定:
    すべての着信接続を拒否し、すべての発信接続を許可します。
    bash
    sudo ufw default deny incoming
    sudo ufw default allow outgoing

  3. 必要なポートを開放:

    • SSH (ポート22): サーバーへのアクセスに必要です。設定を誤るとサーバーにログインできなくなるため、必ず最初に許可します。
      bash
      sudo ufw allow OpenSSH
      # またはポート番号を指定: sudo ufw allow 22/tcp
    • HTTP (ポート80): Webサイトへのアクセスに必要です。
      bash
      sudo ufw allow 'Nginx HTTP'
      # またはポート番号を指定: sudo ufw allow 80/tcp
    • HTTPS (ポート443): 後でSSL/TLSを設定した際に必要になります。
      bash
      sudo ufw allow 'Nginx HTTPS'
      # またはポート番号を指定: sudo ufw allow 443/tcp
    • PostgreSQL (ポート5432): データベースに外部からアクセスする必要がある場合（通常はlocalhostからアクセスするため不要）
      bash
      sudo ufw allow 5432/tcp

  4. UFWを有効化:
    bash
    sudo ufw enable
    警告が表示されますが、SSHポートを許可していれば y で続行します。

  5. UFWのステータス再確認:
    bash
    sudo ufw status verbose
    許可したルールが表示され、Status: active になっていれば成功です。

これで、必要なポート以外へのアクセスがブロックされ、サーバーのセキュリティが向上しました。

7. SSL/TLS (HTTPS) の設定 (Certbot/Let’s Encrypt)

WebサイトをHTTPS化することは、セキュリティ、信頼性、SEOの観点から現在では必須です。Let’s Encryptは無料でSSL/TLS証明書を発行してくれるサービスで、CertbotはLet’s Encryptの証明書を簡単に取得・設定できるツールです。

7.1. なぜHTTPSが必要か？

  • データ暗号化: ユーザーの入力情報（パスワード、個人情報など）を含む通信内容が暗号化され、盗聴や改ざんから保護されます。
  • 信頼性: ブラウザはHTTPSのサイトを「安全」と表示し、HTTPのサイトを「安全ではありません」と警告します。これにより、ユーザーの信頼を得られます。
  • SEO: Googleなどの検索エンジンは、HTTPSのサイトを検索結果で優遇します。
  • 新しいWeb技術の利用: Service Worker、Geolocationなど、多くのモダンなWeb APIはHTTPS接続を要求します。

7.2. Certbotのインストール

Certbotは、Nginxの設定を自動的に更新してHTTPSを有効にできるプラグインを提供しています。

bash
sudo snap install core
sudo snap refresh core
sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/bin/certbot

7.3. CertbotによるSSL証明書の取得とNginx設定

Certbotは、あなたのNginx設定を自動的に読み込み、必要な変更を加えて証明書を取得・設定します。

bash
sudo certbot --nginx -d your_domain.com -d www.your_domain.com
your_domain.com と www.your_domain.com はあなたのドメイン名に置き換えてください。

コマンドを実行すると、いくつか質問されます。

  1. メールアドレスの入力: 有効期限が切れる前に通知を受け取るために必要です。
  2. 利用規約への同意: A を入力して同意します。
  3. メールアドレス共有の同意: 任意です (Y または N)。
  4. HTTPからHTTPSへのリダイレクト設定:
    • 1: No redirect (リダイレクトしない)
    • 2: Redirect (HTTPアクセスをHTTPSに自動的にリダイレクト)
      通常は 2 を選択して、全てのHTTPアクセスをHTTPSに強制的にリダイレクトさせることを強く推奨します。

成功すると、以下のようなメッセージが表示されます。

“`
Congratulations! You have successfully enabled HTTPS on https://your_domain.com and https://www.your_domain.com

IMPORTANT NOTES:
– Congratulations! Your certificate and chain have been saved at:
/etc/letsencrypt/live/your_domain.com/fullchain.pem
Your key file has been saved at:
/etc/letsencrypt/live/your_domain.com/privkey.pem
…
– If you like Certbot, please consider supporting our work by:

Donating to ISRG / Let’s Encrypt: https://letsencrypt.org/donate
Donating to EFF: https://eff.org/donate-le

``
これであなたのDjangoサイトはHTTPSでアクセス可能になりました。ブラウザでhttps://your_domain.com` にアクセスし、アドレスバーに鍵マークが表示されることを確認してください。

7.4. SSL証明書の自動更新設定

Let’s Encryptの証明書は90日間で有効期限が切れます。Certbotは自動更新の仕組みを提供しており、通常はインストール時に自動的にcronジョブやsystemdタイマーが設定されます。

自動更新が機能するかテストします。

bash
sudo certbot renew --dry-run
The dry run was successful. と表示されれば、自動更新は正しく設定されています。

8. デプロイ後の管理と保守

デプロイは一度きりの作業ではありません。アプリケーションを安定稼働させるためには、継続的な監視と保守が必要です。

8.1. ログの確認

問題発生時の診断に役立つため、定期的にログを確認しましょう。

  • Nginxアクセスログ/エラーログ:
    bash
    sudo tail -f /var/log/nginx/access.log
    sudo tail -f /var/log/nginx/error.log
    Nginxがリクエストを正しく処理しているか、Gunicornへのプロキシに問題がないかなどを確認できます。

  • Gunicornログ:
    Gunicornはsystemdサービスとして実行されているため、journalctl を使用してログを確認します。
    bash
    sudo journalctl -u gunicorn -f
    GunicornがDjangoアプリケーションを正しく起動しているか、アプリケーション内部でエラーが発生していないかなどを確認できます。

  • Djangoアプリケーションログ:
    settings.py で設定したロギング設定に基づきます。
    bash
    tail -f /var/www/your_project_name/logs/django.log
    アプリケーション固有のエラーや警告が表示されます。

8.2. 自動起動の確認

サーバーを再起動して、NginxとGunicornが自動的に起動することを確認します。

bash
sudo reboot
サーバーが再起動したら、SSHで再ログインし、サービスのステータスを確認します。
bash
sudo systemctl status nginx
sudo systemctl status gunicorn
sudo systemctl status gunicorn.socket
全て active (running) であればOKです。

8.3. 定期的なアップデート

サーバーOS、Pythonパッケージ、Nginx、Gunicornなど、使用している全てのソフトウェアを定期的にアップデートすることで、セキュリティ脆弱性への対策やパフォーマンスの改善が期待できます。

  • OSパッケージ:
    bash
    sudo apt update
    sudo apt upgrade -y
    sudo apt autoremove -y
  • Pythonパッケージ:
    bash
    cd /var/www/your_project_name
    source venv/bin/activate
    pip install -U -r requirements.txt # pip install --upgrade
    その後、Gunicornサービスを再起動します。
    bash
    sudo systemctl restart gunicorn

8.4. エラーページのカスタマイズ (Nginx)

Nginxでカスタムエラーページを設定することで、ユーザー体験を向上させることができます。

“`nginx

/etc/nginx/sites-available/your_project_name に追加

error_page 500 502 503 504 /50x.html;
location = /50x.html {
root /usr/share/nginx/html; # またはカスタムエラーページのパス
}
``
そして、/usr/share/nginx/html/50x.html` に独自のHTMLエラーページを作成します。

8.5. デプロイスクリプトの作成 (発展的)

アプリケーションの更新が頻繁な場合、手動でのデプロイは面倒でエラーの元になります。Gitのプル、依存関係のインストール、マイグレーション、静的ファイルの収集、サービスの再起動などを自動化するシェルスクリプトやFabric、Ansibleなどのツールを導入することを検討してください。

デプロイスクリプトの例 (deploy.sh)

“`bash

!/bin/bash

エラー発生時にスクリプトを終了

set -e

変数

PROJECT_ROOT=”/var/www/your_project_name”
VENV_DIR=”$PROJECT_ROOT/venv”
LOG_DIR=”$PROJECT_ROOT/logs”

echo “Deploying Django project to $PROJECT_ROOT…”

プロジェクトディレクトリへ移動

cd “$PROJECT_ROOT”

Gitから最新のコードをプル

echo “Pulling latest code from Git…”
git pull origin main # または master ブランチ

仮想環境をアクティベート

echo “Activating virtual environment…”
source “$VENV_DIR/bin/activate”

Python依存パッケージのインストール/更新

echo “Installing/Upgrading Python dependencies…”
pip install -r requirements.txt

データベースマイグレーションの実行

echo “Running database migrations…”
python manage.py migrate

静的ファイルの収集

echo “Collecting static files…”
python manage.py collectstatic –noinput

Gunicornサービスの再起動

echo “Restarting Gunicorn service…”
sudo systemctl restart gunicorn

Nginxサービスの再起動 (必要に応じて)

Nginx設定を変更した場合のみ

echo “Restarting Nginx service…”

sudo systemctl restart nginx

echo “Deployment complete!”
このスクリプトをサーバーに保存し、実行権限を与え、デプロイ時に実行します。bash
chmod +x deploy.sh
./deploy.sh
“`
これにより、デプロイプロセスが効率化され、人的ミスが減ります。

9. トラブルシューティング

デプロイは複雑なプロセスであり、様々な問題が発生する可能性があります。ここでは、よくある問題とその解決策をいくつか紹介します。

9.1. Gunicornが起動しない/502 Bad Gatewayエラー

Gunicornが正しく起動していない、またはNginxがGunicornに接続できない場合に発生します。

  • 症状:

    • sudo systemctl status gunicorn が failed または inactive。
    • Nginxアクセス時にブラウザで「502 Bad Gateway」が表示される。

  • 解決策:

    1. Gunicornログの確認:
      bash
      sudo journalctl -u gunicorn -f
      最も重要な情報源です。Gunicornがどの段階で失敗しているか、Pythonのエラーメッセージ、ファイルのパスの誤り、依存関係の不足などが表示されます。

      • よくある原因:
        • your_project_name.wsgi:application のパスが間違っている。
        • 仮想環境のパス (ExecStart 内のGunicornパス) が間違っている。
        • requirements.txt のパッケージが不足している、またはインストールされていない。
        • settings.py のエラー（特に DEBUG = False にした後の文法エラーや設定ミス）。
        • SECRET_KEY やデータベース接続情報などの環境変数が設定されていない。
        • ファイルやディレクトリのパーミッション不足。User に指定したユーザーがプロジェクトディレクトリにアクセスできるか確認。

    2. UNIXソケットの存在確認:
      Gunicornが起動しているのにNginxが接続できない場合、ソケットファイルが作成されているか確認します。
      bash
      ls -l /run/gunicorn.sock
      ファイルが存在しない、またはパーミッションが正しくない場合、Gunicornサービスファイルやソケットファイルの設定を見直してください。ソケットの所有者/グループがNginx（通常 www-data）からアクセス可能か確認。

    3. Nginxエラーログの確認:
      bash
      sudo tail -f /var/log/nginx/error.log
      NginxがGunicornソケットに接続しようとしてエラーになった詳細が表示されることがあります。

9.2. 静的ファイル（CSS, JS, 画像）が読み込まれない (404 Not Found)

Webサイトのデザインが崩れていたり、画像が表示されなかったりする場合。

  • 症状:

    • ブラウザの開発者ツールで、静的ファイルやメディアファイルのリクエストが「404 Not Found」になる。

  • 解決策:

    1. collectstatic の実行確認:
      STATIC_ROOT ディレクトリに全ての静的ファイルがコピーされているか確認します。
      bash
      ls -l /var/www/your_project_name/staticfiles/css/
      もしファイルがなければ、python manage.py collectstatic を再度実行してください。

    2. Nginx設定の確認:
      /etc/nginx/sites-available/your_project_name の location /static/ および location /media/ ブロックの alias パスが正しいか確認します。
      nginx
      location /static/ {
      alias /var/www/your_project_name/staticfiles/;
      }
      location /media/ {
      alias /var/www/your_project_name/mediafiles/;
      }
      パスが正しい場合でも、Nginxユーザー（通常 www-data）がこれらのディレクトリとファイルへの読み取り権限を持っているか確認します。
      bash
      sudo chown -R your_username:www-data /var/www/your_project_name/staticfiles
      sudo chown -R your_username:www-data /var/www/your_project_name/mediafiles
      sudo chmod -R 755 /var/www/your_project_name/staticfiles
      sudo chmod -R 755 /var/www/your_project_name/mediafiles

    3. Django settings.py の確認:
      STATIC_URL, STATIC_ROOT, MEDIA_URL, MEDIA_ROOT の設定が正しいか確認します。
      特に DEBUG = False であることを再確認してください。

    4. Nginxの再起動:
      設定変更後は必ず sudo nginx -t でテストし、sudo systemctl restart nginx で再起動してください。

9.3. Allowed Hostsエラー

Djangoのセキュリティ機能の一つで、不正なホストからのアクセスを防ぎます。

  • 症状:

    • ブラウザで「DisallowedHost at / Invalid HTTP_HOST header」または類似のエラーメッセージが表示される。
    • Djangoアプリケーションのログに django.core.exceptions.DisallowedHost が記録される。

  • 解決策:

    1. settings.py の ALLOWED_HOSTS の確認:
      アクセスしているドメイン名やIPアドレスが ALLOWED_HOSTS リストに正確に含まれているか確認します。
      python
      ALLOWED_HOSTS = ['your_server_ip_address', 'your_domain.com', 'www.your_domain.com']
      複数のドメインを使用している場合や、開発環境と本番環境で異なる場合は特に注意が必要です。

    2. Nginx設定の server_name の確認:
      Nginxの server_name と ALLOWED_HOSTS が一致していることを確認します。
      nginx
      server_name your_domain.com www.your_domain.com your_server_ip_address;

9.4. パーミッションの問題

ファイルやディレクトリへのアクセス権限が不足していると、様々な問題が発生します。

  • 症状:

    • Gunicornが起動しない。
    • Nginxが静的ファイルを読み込めない。
    • ログファイルに書き込めない。

  • 解決策:

    • 所有者の確認: ls -l でファイルやディレクトリの所有者とグループを確認します。
      bash
      ls -ld /var/www/your_project_name
      ls -l /var/www/your_project_name/your_project_name/wsgi.py
    • 権限の付与:
      • プロジェクトディレクトリ全体: your_username が所有し、www-data グループが読み書きできるように設定します。
        bash
        sudo chown -R your_username:www-data /var/www/your_project_name
        sudo chmod -R 755 /var/www/your_project_name # ディレクトリ
        sudo chmod -R g+s /var/www/your_project_name # 新規作成ファイルがwww-dataグループになるように
        sudo find /var/www/your_project_name -type f -exec chmod 644 {} \; # ファイル
      • UNIXソケット: Nginxユーザー（www-data）がソケットにアクセスできる必要があります。GunicornサービスファイルでGroup=www-dataを設定することで解決されます。
      • ログディレクトリ: Djangoがログファイルを書き込めるように、該当ディレクトリの所有者と権限を確認します。
        bash
        sudo mkdir -p /var/www/your_project_name/logs
        sudo chown your_username:www-data /var/www/your_project_name/logs
        sudo chmod 775 /var/www/your_project_name/logs
        Gunicorn の User と Group に設定したユーザーとグループがログディレクトリに書き込める権限が必要です。

9.5. ファイアウォール (UFW) の問題

必要なポートがファイアウォールでブロックされていると、外部からアクセスできません。

  • 症状:

    • Webブラウザからサイトにアクセスできない (タイムアウト)。
    • SSH接続できない。

  • 解決策:

    1. UFWステータスの確認:
      bash
      sudo ufw status verbose
      80/tcp (HTTP), 443/tcp (HTTPS), 22/tcp (SSH) が ALLOW になっていることを確認します。

    2. ルールを追加: もし不足しているポートがあれば、ルールを追加します。
      bash
      sudo ufw allow 80/tcp
      sudo ufw allow 443/tcp
      sudo ufw allow 22/tcp
      その後、sudo ufw reload または sudo ufw disable && sudo ufw enable で設定を再読み込みします。

    3. プロバイダのセキュリティグループ/ファイアウォールの確認:
      クラウドプロバイダ（AWS, GCP, Azureなど）には、OSのファイアウォールとは別に、インスタンスへのネットワークアクセスを制御するセキュリティグループやVPCファイアウォールがあります。これらの設定でポートがブロックされていないか確認してください。

10. 発展的なトピック

デプロイが完了し、基本的な運用ができるようになったら、さらに堅牢でスケーラブルなアプリケーションを目指すために、以下のトピックを検討してみてください。

10.1. 環境変数の管理 (python-decouple, django-environ)

settings.py に直接パスワードやAPIキーなどの機密情報を書くのはセキュリティ上好ましくありません。python-decouple や django-environ のようなライブラリを使用すると、環境変数や .env ファイルから設定値を安全に読み込むことができます。

  • インストール:
    bash
    pip install python-decouple
    # または pip install django-environ

  • 使用例 (settings.py):
    “`python
    from decouple import config # または from environ import Env

    …

    SECRET_KEY = config(‘DJANGO_SECRET_KEY’)

    DATABASES = {
    ‘default’: {
    ‘ENGINE’: ‘django.db.backends.postgresql’,
    ‘NAME’: config(‘DB_NAME’),
    ‘USER’: config(‘DB_USER’),
    ‘PASSWORD’: config(‘DB_PASSWORD’),
    ‘HOST’: config(‘DB_HOST’, default=’localhost’),
    ‘PORT’: config(‘DB_PORT’, default=”),
    }
    }

    DEBUG = config(‘DJANGO_DEBUG’, default=False, cast=bool)
    ALLOWED_HOSTS = config(‘DJANGO_ALLOWED_HOSTS’, cast=lambda v: [s.strip() for s in v.split(‘,’)])

    * **`.env` ファイルの例 (`/var/www/your_project_name/.env`)**:
    DJANGO_SECRET_KEY=’your_very_secret_key_here’
    DB_NAME=’myprojectdb’
    DB_USER=’myuser’
    DB_PASSWORD=’my_strong_password’
    DB_HOST=’localhost’
    DJANGO_DEBUG=False
    DJANGO_ALLOWED_HOSTS=’your_domain.com,www.your_domain.com,your_server_ip_address’
    ``.envファイルはGit管理から除外 (.gitignore` に追加) し、サーバーには手動で配置するか、安全な方法で転送します。

10.2. ドメイン名の設定

IPアドレスではなく、覚えやすいドメイン名でアクセスできるようにするためには、ドメインレジストラでDNS設定を行います。

  1. ドメインレジストラでDNSレコードを設定:
    • Aレコード: ドメイン名 (例: your_domain.com) をサーバーのIPアドレスにマッピングします。
    • CNAMEレコード: www.your_domain.com のようにサブドメインをAレコードにマッピングします。
  2. Nginx設定の更新: server_name にドメイン名を追加します。
    nginx
    server_name your_domain.com www.your_domain.com;
  3. CertbotでSSLを再設定: 新しいドメイン名に対してCertbotを再実行します。
    bash
    sudo certbot --nginx -d your_domain.com -d www.your_domain.com

10.3. CDN (Content Delivery Network) の利用

静的ファイル（画像、CSS、JS）の配信速度を向上させ、サーバーの負荷を軽減するためにCDNの利用を検討します。Cloudflare, AWS CloudFront, Google Cloud CDNなどが有名です。

  • メリット:
    • ユーザーに近いエッジロケーションからコンテンツを配信するため、表示速度が向上。
    • オリジンサーバー（あなたのDjangoサーバー）の負荷を軽減。
    • DDoS攻撃などのセキュリティ対策。
  • 設定: Djangoのsettings.pyでSTATIC_URLをCDNのURLに設定し、Nginxの設定でCDNからのリクエストを許可するようにします。

10.4. コンテナ化 (Docker)

Dockerを使ってアプリケーションをコンテナ化すると、デプロイの再現性が高まり、環境構築が容易になります。開発環境と本番環境で一貫した動作を保証し、スケーラビリティも向上します。

  • 利点:
    • 「私のPCでは動くのに…」問題の解消。
    • アプリケーションの依存関係がコンテナ内に閉じ込められる。
    • 開発、テスト、デプロイの一貫性が向上。
    • オーケストレーションツール (Kubernetesなど) との連携。
  • 構成例: Dockerコンテナ内でGunicornを動かし、Nginxも別のコンテナで動かすか、ホストのNginxを使用します。docker-compose を使って複数のサービスを連携させることが一般的です。

10.5. モニタリングとアラート

アプリケーションが本番稼働したら、そのパフォーマンスと状態を常に監視することが重要です。

  • サーバー監視: CPU使用率、メモリ使用量、ディスク使用量、ネットワークトラフィックなどを監視します。Prometheus, Grafana, Datadogなどが利用されます。
  • アプリケーション監視: Djangoアプリケーションのパフォーマンス（リクエスト処理時間、エラー率など）や、Gunicorn、Nginxのログを収集・分析します。Sentry, ELK Stack (Elasticsearch, Logstash, Kibana) などが役立ちます。
  • アラート設定: 異常を検知した際に、メールやSlackなどで通知を受け取れるように設定します。

11. まとめ

本ガイドでは、DjangoアプリケーションをNginxとGunicornを組み合わせて本番環境にデプロイするための詳細な手順を解説しました。

  1. 環境準備: サーバーのセットアップ、OSのアップデート、Python、Git、Nginx、UFWのインストール、データベースの準備を行いました。
  2. Django設定: settings.py を本番向けに調整し、DEBUG=False、ALLOWED_HOSTS、静的/メディアファイルパス、データベース接続を設定しました。collectstatic と migrate を実行し、準備を整えました。
  3. Gunicorn設定: Gunicornをインストールし、テスト実行後、systemd を使用してサービスとして永続化・自動起動するように設定しました。
  4. Nginx設定: Nginxをインストールし、リバースプロキシとしてGunicornにリクエストを転送し、静的/メディアファイルを直接配信するための設定を行いました。
  5. セキュリティ: UFWでファイアウォールを設定し、SSH、HTTP、HTTPSポートを開放しました。
  6. HTTPS化: CertbotとLet’s Encryptを使って無料でSSL/TLS証明書を取得し、HTTPS通信を有効化しました。
  7. 運用管理: ログの確認方法、自動起動の検証、定期的なアップデート、トラブルシューティングのヒントを提供しました。

これにより、あなたのDjangoアプリケーションは、堅牢で、安全で、高性能な本番環境で稼働する準備ができました。デプロイは一度やれば終わりではありません。継続的な監視、更新、そして改善を通じて、アプリケーションを最高の状態で維持してください。

このガイドが、あなたのDjangoデプロイ成功の一助となれば幸いです。Happy Deploying!

コメントする

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

上部へスクロール