初心者のためのDjango入門

■第４話：本番環境におけるDjangoの設定と構成

（最終更新日：2023.04.11）

「設定ってどこで変更するの？」

Djangoを使う時、基本操作と同じくらい大事なのが設定ファイルの使い方だ。 Djangoの設定はsetting.pyに書く。ここでは、本番環境でのsetting.pyの設定とDjangoの構成について説明する。

１.本番環境におけるDjangoの設定（setting.py）

Djangoの設定ファイル（setting.py）は、プロジェクトと同名のアプリケーションディレクトリ内にある。 このファイルを開くと、いくつかの設定項目が表示される。 最初に変更が必要なのがDEBUG（下記左）で、デフォルトではDEBUGの表示はTrueになっている。 開発環境ではDEBUGを表示しても問題ないが、本番環境で表示するとエラー発生時に不要な情報がユーザーに漏れることがある。 本番環境にデプロイする際は、DEBUGをFalseにすることを忘れないようにしよう。

ALLOWED_HOSTSは、公開を許可するドメインを指定する場所だ。 テスト環境ではlocalhostを、本番環境では使用しているドメインを指定しよう。 さらに、その下にあるアプリケーションの部分では、現在使用しているアプリケーションを宣言する。 新しいアプリケーションを作成したり、Django REST Frameworkのようなインストール済みアプリを追加したりする場合は、必ず記述しよう。

Middleware（下記右）は、リクエストが送信されたり、レスポンスが返されたりする際に実行される処理だ。 最初はあまり触らないでおくのが良いだろう。 慣れてくると自作のミドルウェアを作る人もいるが、今の段階ではただ存在を認識しておけば十分だ。 また、その下のROOT_URLCONFはデフォルトの設定で問題ない。 指定されたディレクトリのurls.pyが読み込まれ、ルーティングが行われる仕組みになっている。

TEMPLATESは、変更することがよくある設定のひとつだ。 デフォルトでは、各アプリケーションディレクトリにtemplatesディレクトリを配置し、HTMLを表示する仕組みになっている。 ただ、この方法だとTemplateファイル（HTML）が各ディレクトリに散らばってしまうことがある。 Templateファイルを一箇所にまとめたい場合は、BASE_DIR（一番上のディレクトリ直下）にtemplatesディレクトリを設置し、 その場所を指定することができる。下記右下のDIRSでその設定が記述されている。

さらに設定を見ていくと、下記左にデータベースの設定がある。 デフォルトではsqliteが設定されているが、本番環境でよく使われるMySQL（MariaDB）やPostgreSQLに変更することも可能だ。 下記の例ではMySQLの設定が示されており、ユーザー名、パスワード、ポートなどを設定して接続することができる。

さらにその下には言語コードとタイムゾーンの設定がある。 日本で利用する場合は、デフォルトのen-usをjaに、UTCをAsia/Tokyoに変更しよう。

続いて、staticディレクトリ（静的ファイルの置き場所）の設定がある。 これは、画像ファイルやCSS、JavaScriptファイルを置く場所の設定だ。 これもTEMPLATESディレクトリと同様に、BASE_DIR（一番上のディレクトリ直下）に設定することが一般的だ。

さらに、URLの末尾にスラッシュを付ける設定やユーザー認証（ログイン）に関する設定があるが、今回は存在についてのみ触れる。 最後に、サインアップや問い合わせ時にユーザーや管理者に送るメールの設定について説明する。 開発環境の場合は、EMAIL_BACKENDをコンソールに出力するように設定（コメントアウトしてある方）する。 本番環境ではSMTPを選択し、配信元となるメールサーバーのホストURLやポート、メールアドレス、パスワードを設定する項目が存在する。

２.本番環境におけるDjangoの構成

第１話ではDjangoの全体像について解説した。 今回はこれまでの復習も兼ねて、Webサーバーを含めた構成図を紹介する。 下図はDjangoとWebサーバーを示すもので、右側のDjangoの仕組み部分（middlewareより右側）は、 1話～3話を読んでいれば理解できるはずだ。

ここで、左側のWebサーバーとの連携について話をしよう。 開発時はWebサーバーを使用せず、代わりにDjango内蔵のmanage.pyをrunserverさせることで、 ブラウザ上で表示が可能になる（manage.pyが「Webサーバー+wsgi.py」に代わり、簡易サーバーの役割を果たす）。 ただし、manage.pyは並列処理やプロセスの自動再起動ができないため、アクセスが多い本番環境には向かない。

本番環境では、ApacheやNginxと連携（デプロイ）して運用することになる。 デプロイの詳細は技術書や別のサイトに譲るが、要点としては、 wsgiというインターフェースがApache（Webサーバー）とDjango（アプリケーションサーバー）の仲介をしている。 つまり、wsgiと連携できるWebサーバーであれば、Djangoはデプロイできるということだ。 ちなみに、wsgiはPython共通のインターフェースであり、wsgiが使えれば、Flaskなどの別のPythonウェブフレームワークも利用できることを意味する。

最後に、これまで触れていなかったadmin.pyについて説明しよう。 これは非常にシンプルなものだ。Djangoデフォルトの管理ページで管理するかどうかを設定するファイルである。 admin.pyに「admin.site.register（モデル名）」を追記することで、管理サイトで管理できるModel（データベースのテーブル）を増やすことができる。これにより、管理画面からデータの追加や編集が容易になる。

▼参考図書、サイト

 「Djangoのツボとコツがゼッタイにわかる本」　大橋亮太　秀和システム
 「現場で使えるDjango管理サイトのつくり方」　横瀬明仁
   言語を日本語に切り替える方法【settingsファイルで一発です】　Code for Django
   WEBサーバのinterfaceのイメージはこんな感じだろうか〜CGI, FastCGI, Apacheモジュール, WSGI〜　Blow Up by Black Swan
   djangoは誰が動かしているのか？（デプロイのための俯瞰）　Qiita