Contents
Djangoプロジェクトのデプロイとは?
Djangoプロジェクトの「デプロイ」は、開発環境で動作確認したWebアプリを本番環境に公開する手順です。開発と本番では セキュリティ設定や静的ファイル管理 など多くの差異があり、無理矢理開発環境のコードを流用すると運用時に深刻な問題が生じます。また、AWSやHerokuといったクラウドサービスは特徴が異なるため、選定する際には スケーラビリティ・コスト・操作性 などの観点で比較検討することが重要です。
開発環境と本番環境の設定差異
環境変数管理のベストプラクティス
開発環境ではsettings.pyに直接環境変数を記述しやすいですが、本番環境では.envファイルやクラウドサービス特有の機能(例: AWS Systems Manager Parameter Store)を使用します。Djangoではpython-decoupleやdjango-environなどのライブラリが役立ちます。
注意:
.envファイルは絶対にバージョン管理しないでください。秘密情報を含むため、.gitignoreに登録し、セキュアな方法(例: AWS Secrets Manager)で管理することがベストプラクティスです。
- 開発時:
DEBUG = Trueで動作確認 - 本番時:
DEBUG = Falseに設定し、セキュリティ対策(CSRF保護の強化やXSS防止など)を実施
特にHerokuでは環境変数は「Config Vars」として管理され、秘密情報をコードに含めないことが基本です。
静的ファイル配置の違い
開発環境ではcollectstaticコマンドでSTATIC_ROOTに静的ファイルをまとめることが一般的ですが、本番環境ではAWS S3やCloudFrontなど外部サービスを使用するケースが増えています。Djangoの設定例は以下の通りです。
|
1 2 3 4 5 |
# settings.py if not DEBUG: STATICFILES_STORAGE = 'storages.backends.s3boto3.S3Boto3Storage' DEFAULT_FILE_STORAGE = 'storages.backends.s3boto3.S3Boto3Storage' |
注意: AWS S3に静的ファイルを配置する際は、セキュリティ設定(ACL制限やSSL有効化)を行う必要があります。また、Herokuのデータベース接続時はSSLが必須となるため、
DATABASE_URL環境変数にsslmode=requireなどを指定して確認してください。
Dockerによるコンテナ化手順
Dockerfile作成ステップ
Dockerはアプリケーションを環境に依存しない形でパッケージングできるため、デプロイの一貫性を高めます。以下は基本的なDockerfileの例です。
|
1 2 3 4 5 6 7 |
FROM python:3.11-slim # Pythonバージョンを最新(現時点ではPython 3.11以降が推奨)に更新 WORKDIR /app COPY requirements.txt . RUN pip install -r requirements.txt COPY . . CMD ["gunicorn", "--bind", "0.0.0.0:8000", "myproject.wsgi"] |
多段階ビルドを使用することで、イメージサイズを抑えることが可能です。後述のDocker Composeで外部サービス(PostgreSQLなど)と連携する際は、
docker-compose.ymlでネットワーク設定に注意が必要です。
Docker Composeでのサービス構築
Docker Composeを使うことで、Webサーバー・データベース・キャッシュなどの複数コンテナを同時に起動できます。以下が簡単な例です。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
version: '3' services: web: build: . ports: - "8000:8000" volumes: - .:/app depends_on: - db db: image: postgres:14 environment: POSTGRES_USER: user POSTGRES_PASSWORD: password |
データベース接続の際は
DJANGO_SETTINGS_MODULEを明示的に指定し、本番環境と開発環境で設定が一致しないトラブルを防ぎましょう。
主要クラウドプラットフォーム別のデプロイ方法
AWS EC2での手動デプロイフロー
AWS EC2は柔軟性が高い反面、手順が多いです。以下に主なステップを整理しました。
- EC2インスタンスの起動: UbuntuなどのOSを選択し、セキュリティグループで80/443ポートを開けます。
- SSH接続してPythonやDjangoの環境構築を行います。
requirements.txtを元に依存関係をインストール- プロジェクトディレクトリに移動し、
gunicornで起動(例:gunicorn myproject.wsgi:application --bind 0.0.0.0:8000)
実運用ではNginxやApacheをフロントエンドに配置し、SSL証明書の設定も必須です。また、IAMロールを使用してAWSリソースへのアクセスを管理することでセキュリティリスクを低減できます。
HerokuのProcfile構成と環境設定
HerokuはコードをGitでプッシュするだけで自動デプロイ可能なクラウドサービスです。以下が基本的な手順です。
-
Procfileを作成し、起動コマンドを記述
web: gunicorn myproject.wsgi --bind 0.0.0.0:$PORT -
Heroku CLI を使ってアプリケーションを作成し、Gitリモートを追加
bash
heroku create my-django-app
git remote add heroku https://git.heroku.com/my-django-app.git -
git push heroku mainでデプロイ
HerokuではPostgreSQLデータベースや環境変数管理(Config Vars)が提供されており、Djangoアプリの運用に最適です。SSL有効化を忘れると、データベース接続時にエラーが発生するため、
DATABASE_URL環境変数にsslmode=requireを指定してください。
CI/CDパイプライン構築方法(CircleCI例)
.circleci/config.ymlの基本構成
CI/CDを導入すると、テスト→ビルド→デプロイの一連の流れを自動化できます。以下はCircleCIでの設定例です。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
version: 2.1 jobs: build: docker: - image: circleci/python:3.11 # Pythonバージョンを最新に更新 steps: - checkout - run: pip install -r requirements.txt - run: python manage.py test - run: docker build -t my-django-app . - run: docker tag my-django-app heroku/my-django-app - run: docker push heroku/my-django-app workflows: version: 2 deploy_to_heroku: jobs: - build |
runコマンドで任意のステップを追加でき、Dockerイメージ作成やHerokuへのPushも可能です。
すぐに導入できるポイントまとめ
環境ごとの設定ファイルテンプレート
- 本番環境:
.env.prodに秘密情報をまとめ、DJANGO_SETTINGS_MODULE = 'myproject.settings.production'と指定 - 開発環境:
settings.py内に直接記述(ただし本番には使用不可)
デプロイ失敗時のトラブルシューティング手順
-
ロギングの確認
AWS EC2では/var/log/nginx/error.log、Herokuではheroku logs --tailでエラーメッセージを検索 -
ポート番号のミス
Herokuはデフォルトで$PORTを使用するため、Gunicorn起動時に--bind 0.0.0.0:$PORTを忘れるとアクセスできません。 -
依存関係の不一致
requirements.txtに含まれていないライブラリやバージョン違いが原因となるケースは頻繁です。
【まとめ】
- Djangoプロジェクトのデプロイでは、開発環境と本番環境での差異を把握することが不可欠
- Dockerを使うことで、デプロイの一貫性を高められます
- AWSやHerokuなどクラウドサービスは特徴が異なるため、用途に応じた選定が必要
- CI/CD(例: CircleCI)の導入で運用コストを削減し、効率的なリリースが可能
以下のチェックリストを参考に、すぐにデプロイ環境の整備を始めてください。
- 環境変数管理方法を決める
ProcfileやDockerfileを作成する- テストコードをCIに組み込む
- 本番環境で静的ファイルの配置先を確認