Ubuntu18.04でPostgres、Nginx、Gunicornを使用してDjangoを設定する方法

投稿日: 2022-08-01 2022-10-20
タグ: Databases, Django, nginx, postgresql, python, Python Frameworks, Ubuntu 18.04

序章

Django は、PythonアプリケーションまたはWebサイトを立ち上げるのに役立つ強力なWebフレームワークです。 Djangoには、コードをローカルでテストするための簡略化された開発サーバーが含まれています。少しでも本番環境に関連するものを好む場合は、より安全で強力なWebサーバーをお勧めします。

このチュートリアルでは、Djangoアプリケーションをサポートおよび提供するためにUbuntu 18.04にいくつかのコンポーネントをインストールして構成し、デフォルトのSQLiteデータベースを使用する代わりにPostgreSQLデータベースをセットアップしてから、アプリケーションとインターフェイスするようにGunicornアプリケーションサーバーを構成します。最後に、GunicornにリバースプロキシするようにNginxを設定し、アプリケーションにサービスを提供するためのセキュリティ機能とパフォーマンス機能にアクセスできるようにします。

前提条件

このチュートリアルを完了するには、Ubuntu18.04サーバーをセットアップする必要があります。 sudo 特権が構成され、ファイアウォールが有効になっています。開始するには、Ubuntu18.04初期サーバーセットアップガイドに従ってください。

ステップ1—Ubuntuリポジトリからパッケージをインストールする

まず、Ubuntuリポジトリから必要なすべてのアイテムをダウンロードしてインストールします。 Pythonパッケージマネージャーを使用する pip 後で追加のコンポーネントをインストールします。

まず、ローカルを更新します apt パッケージインデックスを作成し、パッケージをダウンロードしてインストールします。

sudo apt update

次に、パッケージをインストールします。これは、プロジェクトで使用するPythonのバージョンによって異なります。

Python 3 でDjangoを使用している場合は、次を実行します。

sudo apt install python3-pip python3-dev libpq-dev postgresql postgresql-contrib nginx curl

Django 1.11は、 Python2をサポートするDjangoの最後のリリースです。新しいプロジェクトを開始する場合は、Python3を選択することを強くお勧めします。それでもPython2を使用する必要がある場合は、次を実行します。

sudo apt install python-pip python-dev libpq-dev postgresql postgresql-contrib nginx curl

これによりインストールされます pip、後でGunicornを構築するために必要なPython開発ファイル、Postgresデータベースシステムとそれと対話するために必要なライブラリ、およびNginxWebサーバー。

ステップ2—PostgreSQLデータベースとユーザーを作成する

このステップでは、PostgreSQLを使用してDjangoアプリケーション用のデータベースとデータベースユーザーを作成します。これは「Postgres」とも呼ばれます。

デフォルトでは、Postgresはローカル接続にピア認証と呼ばれる認証スキームを使用します。これは、ユーザーのオペレーティングシステムのユーザー名が有効なPostgresユーザー名と一致する場合、そのユーザーはそれ以上の認証なしでログインできることを意味します。

Postgresのインストール中に、 postgres に対応するために作成されました postgres PostgreSQL管理ユーザー。管理タスクを実行するには、このユーザーを使用する必要があります。を使用してインタラクティブなPostgresセッションにログインします sudo そして、ユーザー名を -u オプション：

sudo -u postgres psql

要件を設定できるPostgreSQLプロンプトが表示されます。まず、プロジェクトのデータベースを作成します。

CREATE DATABASE myproject;

注：すべてのPostgresステートメントはセミコロンで終了する必要があります。問題が発生している場合は、コマンドが1で終了していることを確認してください。

次に、プロジェクトのデータベースユーザーを作成し、安全なパスワードを選択します。

CREATE USER myprojectuser WITH PASSWORD 'password';

OutputCREATE ROLE

その後、作成したユーザーの接続パラメーターのいくつかを変更します。これにより、データベース操作が高速化されるため、接続が確立されるたびに正しい値を照会して設定する必要がなくなります。

デフォルトのエンコーディングをに設定します UTF-8、Djangoが期待するもの：

ALTER ROLE myprojectuser SET client_encoding TO 'utf8';

OutputALTER ROLE

次に、デフォルトのトランザクション分離スキームをに設定します read committed コミットされていないトランザクションからの読み取りをブロックするには：

ALTER ROLE myprojectuser SET default_transaction_isolation TO 'read committed';

OutputALTER ROLE

Djangoプロジェクトが使用するように設定されるため UTC デフォルトでは、関連するタイムゾーンを設定します。

ALTER ROLE myprojectuser SET timezone TO 'UTC';

OutputALTER ROLE

これらはすべてDjangoプロジェクトからの推奨事項です。

次に、新しいユーザーに新しいデータベースを管理するためのアクセス権を付与します。

GRANT ALL PRIVILEGES ON DATABASE myproject TO myprojectuser;

OutputGRANT

終了したら、次のコマンドを実行してPostgreSQLプロンプトを終了します。

\q

これで、Postgresが正常にセットアップされ、Djangoがデータベース情報に接続して管理できるようになりました。

ステップ3—プロジェクト用のPython仮想環境を作成する

データベースができたので、残りのプロジェクト要件の準備を始めることができます。これには、より効率的な管理のために仮想環境内にPython要件をインストールすることが含まれます。プロジェクトに固有の仮想環境にDjangoをインストールすると、プロジェクトとその要件を個別に処理できるようになります。

これを行うには、にアクセスする必要があります virtualenv 指図。これをインストールすることから始めます pip.

Python 3 を使用している場合は、アップグレードしてください pip:

sudo -H pip3 install --upgrade pip

次に、パッケージをインストールします。

sudo -H pip3 install virtualenv

Python 2 を使用している場合は、アップグレードしてください pip:

sudo -H pip install --upgrade pip

次に、パッケージをインストールします。

sudo -H pip install virtualenv

と virtualenv インストールすると、プロジェクトの形成を開始できます。まず、プロジェクトファイルを保存できるディレクトリを作成します。ここで名前を付けます myprojectdir、お好きな名前を付けてください。

mkdir ~/myprojectdir

次に、そのディレクトリに移動します。

cd ~/myprojectdir

プロジェクトディレクトリ内に、Python仮想環境を作成します。

virtualenv myprojectenv

これにより、というディレクトリが作成されます myprojectenv あなたの中で myprojectdir ディレクトリ。内部には、Pythonのローカルバージョンとのローカルバージョンがインストールされます pip. これを使用して、プロジェクト用に分離されたPython環境をインストールおよび構成できます。

ただし、プロジェクトのPython要件をインストールする前に、仮想環境をアクティブ化する必要があります。

source myprojectenv/bin/activate

プロンプトが変化して、Python仮想環境内で操作していることを示します。次のようになります。 (myprojectenv)user@host:~/myprojectdir$.

仮想環境をアクティブにして、Django、Gunicorn、および psycopg2 ローカルインスタンスが pip:

注：仮想環境がアクティブ化されたとき（プロンプトが (myprojectenv) その前に）、使用する pip それ以外の pip3、Python3を使用している場合でも。ツールの仮想環境のコピーには常に名前が付けられます pip、Pythonのバージョンに関係なく。

pip install django gunicorn psycopg2-binary

これで、Djangoプロジェクトを開始するために必要なすべてのソフトウェアが揃いました。

ステップ4—新しいDjangoプロジェクトの作成と構成

Pythonコンポーネントをインストールすると、実際のDjangoプロジェクトファイルを作成できるようになります。すでにプロジェクトディレクトリがあるので、ここにファイルをインストールするようにDjangoに指示します。通常の実際のコードを使用して第2レベルのディレクトリを作成し、このディレクトリに管理スクリプトを配置します。 Djangoが現在のディレクトリに関連する決定を行うことを許可するのではなく、ディレクトリを明示的に定義しているため、これは重要です。

django-admin.py startproject myproject ~/myprojectdir

この時点で、プロジェクトディレクトリ（~/myprojectdir この場合）には、次の内容が含まれます。

~/myprojectdir/manage.py：Djangoプロジェクト管理スクリプト。
~/myprojectdir/myproject/：Djangoプロジェクトパッケージ。これには、 __init__.py, settings.py, urls.py、と wsgi.py ファイル。
~/myprojectdir/myprojectenv/：前に作成した仮想環境ディレクトリ。

新しく作成したプロジェクトファイルで次に行うことは、設定を調整することです。お好みのテキストエディタで設定ファイルを開きます。ここでは使用します nano:

nano ~/myprojectdir/myproject/settings.py

を見つけることから始めます ALLOWED_HOSTS 指令。これは、Djangoインスタンスへの接続に使用できるサーバーのアドレスまたはドメイン名のリストを定義します。このリストにないHostヘッダーを持つ着信要求は、例外を発生させます。 Djangoでは、特定のクラスのセキュリティの脆弱性を防ぐためにこれを設定する必要があります。

角かっこ内に、Djangoサーバーに関連付けられているIPアドレスまたはドメイン名をリストします。各項目は、エントリをコンマで区切って引用符で囲む必要があります。ドメイン全体とサブドメインのリクエストを希望する場合は、エントリの先頭にピリオドを追加します。次のスニペットには、デモンストレーションに使用されるコメントアウトされた例がいくつかあります。

注：必ず含めてください localhost ローカルのNginxインスタンスを介して接続をプロキシするため、オプションの1つとして。

〜/ myprojectdir / myproject / settings.py

. . .
# The simplest case: just add the domain name(s) and IP addresses of your Django server
# ALLOWED_HOSTS = [ 'example.com', '203.0.113.5']
# To respond to 'example.com' and any subdomains, start the domain with a dot
# ALLOWED_HOSTS = ['.example.com', '203.0.113.5']
ALLOWED_HOSTS = ['your_server_domain_or_IP', 'second_domain_or_IP', . . ., 'localhost']

次に、データベースアクセスを構成するセクションを見つけます。それはで始まります DATABASES. ファイル内の構成はSQLiteデータベース用です。プロジェクト用にPostgreSQLデータベースをすでに作成しているので、これらの設定を調整する必要があります。

PostgreSQLデータベース情報で設定を更新します。次に、Djangoに psycopg2 インストールしたアダプター pip. また、データベース名、作成したデータベースユーザーのユーザー名、データベースユーザーのパスワードを指定し、データベースがローカルコンピューターで検出できることを指定する必要があります。あなたは去ることができます PORT 空の文字列として設定：

〜/ myprojectdir / myproject / settings.py

. . .

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.postgresql_psycopg2',
        'NAME': 'myproject',
        'USER': 'myprojectuser',
        'PASSWORD': 'password',
        'HOST': 'localhost',
        'PORT': '',
    }
}

. . .

次に、ファイルの最後に移動し、静的ファイルを配置する場所を示す設定を追加します。これは、Nginxがこれらのアイテムのリクエストを処理できるようにするために必要です。次の行は、Djangoにそれらをというディレクトリに配置するように指示しています static ベースプロジェクトディレクトリ：

〜/ myprojectdir / myproject / settings.py

. . .

STATIC_URL = '/static/'
import os
STATIC_ROOT = os.path.join(BASE_DIR, 'static/')

終了したら、ファイルを保存して閉じます。使用している場合 nano、を押すことでこれを行うことができます CTRL + X それから Y と ENTER.

ステップ5—プロジェクトの初期設定を完了する

次のステップは、次の管理スクリプトを使用して、初期データベーススキーマをPostgreSQLデータベースに移行することです。

~/myprojectdir/manage.py makemigrations
~/myprojectdir/manage.py migrate

プロジェクトの管理ユーザーを作成します。

~/myprojectdir/manage.py createsuperuser

ユーザー名を選択し、メールアドレスを入力して、パスワードを選択して確認する必要があります。

次のコマンドを実行して、構成したディレクトリの場所にすべての静的コンテンツを収集します。

~/myprojectdir/manage.py collectstatic

静的ファイルは、次のディレクトリに配置されます。 static プロジェクトディレクトリ内。

サーバーの初期設定ガイドに従った場合は、サーバーを保護するUFWファイアウォールが必要です。開発サーバーをテストするには、使用するポートへのアクセスを許可する必要があります。この場合、ポートの例外を作成します 8000:

sudo ufw allow 8000

最後に、次のコマンドを使用してDjango開発サーバーを起動し、プロジェクトをテストします。

~/myprojectdir/manage.py runserver 0.0.0.0:8000

Webブラウザーで、サーバーのドメイン名またはIPアドレスにアクセスし、その後にアクセスします。 :8000:

http://server_domain_or_IP:8000

次のデフォルトのDjangoインデックスページが表示されます。

追加する場合 /admin アドレスバーのURLの最後に、で作成した管理ユーザー名とパスワードの入力を求められます。 createsuperuser 指図：

認証後、デフォルトのDjango管理インターフェースにアクセスできます。

探索が終了したら、を押します CTRL + C ターミナルウィンドウで、開発サーバーをシャットダウンします。

ステップ6—プロジェクトにサービスを提供するGunicornの能力をテストする

仮想環境を離れる前に、Gunicornをテストして、アプリケーションに対応できることを確認してください。これを行うには、最初にプロジェクトディレクトリに移動します。

cd ~/myprojectdir

次に実行します gunicorn プロジェクトのWSGIモジュールをロードするには：

gunicorn --bind 0.0.0.0:8000 myproject.wsgi

これにより、Django開発サーバーが実行されていたのと同じインターフェースでGunicornが起動します。戻ってアプリケーションを再度テストできます。

注： Gunicornはこれに関与する静的CSSコンテンツを見つける方法を知らないため、管理インターフェースにはスタイルが適用されません。

要約すると、Djangoへの相対ディレクトリパスを指定して、Gunicornにモジュールを渡しました。 wsgi.py ファイル。Pythonのモジュール構文を使用した、アプリケーションへのエントリポイントです。 Gunicornはアプリケーションへのインターフェースとして機能し、クライアントリクエストをHTTPからアプリケーションが処理できるPython呼び出しに変換します。このファイル内で、 application アプリケーションとの通信に使用されるが定義されました。興味がある場合は、WSGI仕様について詳しく知ることができます。

テストが終了したら、を押します CTRL + C ターミナルウィンドウでGunicornを停止します。

これでDjangoアプリケーションの構成が完了し、仮想環境を非アクティブ化できます。

deactivate

プロンプトの仮想環境インジケーターが削除されます。

ステップ7—Gunicorn用のsystemdソケットおよびサービスファイルの作成

GunicornがDjangoアプリケーションと対話できることをテストしたので、アプリケーションサーバーを起動および停止するためのより堅牢な方法を実装する必要があります。これを実現するには、systemdサービスとソケットファイルを作成します。

Gunicornソケットは起動時に作成され、接続をリッスンします。接続が発生すると、systemdは接続を処理するためにGunicornプロセスを自動的に開始します。

まず、Gunicornのsystemdソケットファイルを作成して開きます。 sudo 好みのテキストエディタでの権限：

sudo nano /etc/systemd/system/gunicorn.socket

内部で、を作成します [Unit] ソケットを説明するセクション、 [Socket] ソケットの位置を定義するセクション、および [Install] ソケットが適切なタイミングで作成されていることを確認するセクション：

/etc/systemd/system/gunicorn.socket

[Unit]
Description=gunicorn socket

[Socket]
ListenStream=/run/gunicorn.sock

[Install]
WantedBy=sockets.target

終了したら、ファイルを保存して閉じます。

次に、Gunicornのsystemdサービスファイルを作成して開きます。 sudo 好みのテキストエディタでの権限。サービスファイル名は、拡張子を除いてソケットファイル名と一致する必要があります。

sudo nano /etc/systemd/system/gunicorn.service

から始めます [Unit] セクション。メタデータと依存関係を指定するために使用されます。ここにサービスの説明を追加し、ネットワークターゲットに到達した後にのみこのサービスを開始するようにinitシステムに指示します。サービスはソケットファイルのソケットに依存しているため、 Requires その関係を示すディレクティブ：

/etc/systemd/system/gunicorn.service

[Unit]
Description=gunicorn daemon
Requires=gunicorn.socket
After=network.target

次に、 [Service] セクションを作成し、プロセスを実行するユーザーとグループを指定します。プロセスは関連するすべてのファイルを所有しているため、プロセスの通常のユーザーアカウントの所有権を提供します。次に、 www-data グループにグループの所有権を付与して、NginxがGunicornと通信できるようにします。

その後、作業ディレクトリをマップし、実行するコマンドを指定してサービスを開始します。この場合、仮想環境内にインストールされているGunicorn実行可能ファイルへのフルパスを指定します。次に、プロセスを、内で作成したUnixソケットにバインドします。 /run プロセスがNginxと通信できるようにディレクトリ。すべてのデータを標準出力に記録して、 journald プロセスはGunicornのログを収集できます。ここで、オプションのGunicornの微調整を指定することもできます。この例では、3つのワーカープロセスを指定しました。

/etc/systemd/system/gunicorn.service

[Unit]
Description=gunicorn daemon
Requires=gunicorn.socket
After=network.target

[Service]
User=sammy
Group=www-data
WorkingDirectory=/home/sammy/myprojectdir
ExecStart=/home/sammy/myprojectdir/myprojectenv/bin/gunicorn \
          --access-logfile - \
          --workers 3 \
          --bind unix:/run/gunicorn.sock \
          myproject.wsgi:application

最後に、 [Install] セクション。これにより、起動時にサービスを開始できるようにした場合に、このサービスを何にリンクするかがsystemdに通知されます。通常のマルチユーザーシステムが稼働しているときにこのサービスを開始する必要があります。

/etc/systemd/system/gunicorn.service

[Unit]
Description=gunicorn daemon
Requires=gunicorn.socket
After=network.target

[Service]
User=sammy
Group=www-data
WorkingDirectory=/home/sammy/myprojectdir
ExecStart=/home/sammy/myprojectdir/myprojectenv/bin/gunicorn \
          --access-logfile - \
          --workers 3 \
          --bind unix:/run/gunicorn.sock \
          myproject.wsgi:application

[Install]
WantedBy=multi-user.target

これで、systemdサービスファイルが完成しました。ここでファイルを保存して閉じます。

次に、Gunicornソケットを起動します。これにより、ソケットファイルが次の場所に作成されます。 /run/gunicorn.sock 現在および起動時：

sudo systemctl start gunicorn.socket

次に、それを有効にして、そのソケットへの接続が確立されたときに、systemdが自動的に開始するようにします。 gunicorn.service それを処理するには：

sudo systemctl enable gunicorn.socket

ソケットファイルを確認することで、操作が成功したことを確認できます。

ステップ8—Gunicornソケットファイルを確認する

プロセスのステータスをチェックして、プロセスを開始できたかどうかを確認します。

sudo systemctl status gunicorn.socket

Output● gunicorn.socket - gunicorn socket
     Loaded: loaded (/etc/systemd/system/gunicorn.socket; enabled; vendor prese>
     Active: active (listening) since Thu 2021-12-02 19:58:48 UTC; 14s ago
   Triggers: ● gunicorn.service
     Listen: /run/gunicorn.sock (Stream)
      Tasks: 0 (limit: 1136)
     Memory: 0B
     CGroup: /system.slice/gunicorn.socket

Dec 02 19:58:48 gunicorn systemd[1]: Listening on gunicorn socket.

次に、の存在を確認します gunicorn.sock 内のファイル /run ディレクトリ：

file /run/gunicorn.sock

Output/run/gunicorn.sock: socket

の場合 systemctl status コマンドは、エラーが発生したこと、またはエラーが見つからない場合を示します gunicorn.sock ディレクトリ内のファイルが表示されている場合は、Gunicornソケットが正しく作成されていないことを示しています。以下を実行して、Gunicornソケットのログを確認します。

sudo journalctl -u gunicorn.socket

あなたの /etc/systemd/system/gunicorn.socket 続行する前に問題を修正するためのファイル。

ステップ9—ソケットアクティベーションのテスト

始めたばかりの場合 gunicorn.socket ユニット、 gunicorn.service ソケットが接続を受信していないため、まだアクティブにはなりません。ステータスを確認します。

sudo systemctl status gunicorn

Output● gunicorn.service - gunicorn daemon
   Loaded: loaded (/etc/systemd/system/gunicorn.service; disabled; vendor preset: enabled)
   Active: inactive (dead)

ソケットアクティベーションメカニズムをテストするには、を介してソケットに接続を送信します curl:

curl --unix-socket /run/gunicorn.sock localhost

ターミナルでアプリケーションからHTML出力を受け取る必要があります。これにより、Gunicornが起動され、Djangoアプリケーションを提供できることが確認されます。ステータスをもう一度確認することで、Gunicornサービスが実行されていることを確認できます。

sudo systemctl status gunicorn

Output●  gunicorn.service - gunicorn daemon
   Loaded: loaded (/etc/systemd/system/gunicorn.service; disabled; vendor preset
   Active: active (running) since Tue 2021-11-23 22:55:12 UTC; 11s ago
 Main PID: 11002 (gunicorn)
    Tasks: 4 (limit: 1151)
   CGroup: /system.slice/gunicorn.service
           ├─11002 /home/sammy/myprojectdir/myprojectenv/bin/python /home/sammy/
           ├─11018 /home/sammy/myprojectdir/myprojectenv/bin/python /home/sammy/
           ├─11020 /home/sammy/myprojectdir/myprojectenv/bin/python /home/sammy/
           └─11022 /home/sammy/myprojectdir/myprojectenv/bin/python /home/sammy/
. . .

からの出力の場合 curl またはの出力 systemctl status 問題が発生したことを示します。詳細については、ログを確認してください。

sudo journalctl -u gunicorn

あなたの /etc/systemd/system/gunicorn.service 問題のファイル。に変更を加えた場合 /etc/systemd/system/gunicorn.service ファイル、デーモンをリロードしてサービス定義を再読み取りします。

sudo systemctl daemon-reload

次に、Gunicornプロセスを再起動します。

sudo systemctl restart gunicorn

このような問題が発生した場合は、続行する前にトラブルシューティングを行ってください。

ステップ10—GunicornへのプロキシパスにNginxを構成する

Gunicornがセットアップされたので、次にトラフィックをプロセスに渡すようにNginxを構成します。

Nginxで新しいサーバーブロックを作成して開くことから始めます sites-available ディレクトリ：

sudo nano /etc/nginx/sites-available/myproject

内部で、新しいサーバーブロックを開きます。このブロックが通常のポートでリッスンするように指定することから始めます 80 サーバーのドメイン名またはIPアドレスに応答する必要があります。

/ etc / nginx / sites-available / myproject

server {
    listen 80;
    server_name server_domain_or_IP;
}

次に、ファビコンの検索に関する問題を無視するようにNginxに指示します。また、収集した静的アセットの場所を教えてください ~/myprojectdir/static ディレクトリ。これらのファイルはすべて、標準のURIプレフィックスが /static、したがって、これらのリクエストに一致するロケーションブロックを作成できます。

/ etc / nginx / sites-available / myproject

server {
    listen 80;
    server_name server_domain_or_IP;

    location = /favicon.ico { access_log off; log_not_found off; }
    location /static/ {
        root /home/sammy/myprojectdir;
    }
}

最後に、 location / {} 他のすべてのリクエストに一致するようにブロックします。この場所の中に、標準を含めます proxy_params Nginxインストールからファイルを作成し、トラフィックをGunicornソケットに直接渡します。

/ etc / nginx / sites-available / myproject

server {
    listen 80;
    server_name server_domain_or_IP;

    location = /favicon.ico { access_log off; log_not_found off; }
    location /static/ {
        root /home/sammy/myprojectdir;
    }

    location / {
        include proxy_params;
        proxy_pass http://unix:/run/gunicorn.sock;
    }
}

終了したら、ファイルを保存して閉じます。これで、ファイルをにリンクして有効にすることができます sites-enabled ディレクトリ：

sudo ln -s /etc/nginx/sites-available/myproject /etc/nginx/sites-enabled

構文エラーについてNginx構成をテストします。

sudo nginx -t

エラーが報告されていない場合は、先に進んでNginxを再起動します。

sudo systemctl restart nginx

開発サーバーにアクセスする必要がなくなったため、ポートを開くルールを削除してファイアウォール設定を調整します 8000:

sudo ufw delete allow 8000

次に、ポートで通常のトラフィックを許可します 80 と 443 —これにより、HTTP接続とHTTPS接続をそれぞれ許可します—次のコマンドを使用します。

sudo ufw allow 'Nginx Full'

これで、サーバーのドメインまたはIPアドレスに移動してアプリケーションを表示できるようになります。

注： Nginxを構成したら、次のステップはSSL/TLSを使用してサーバーへのトラフィックを保護する必要があります。これがないと、パスワードを含むすべての情報がプレーンテキストでネットワーク経由で送信されるため、これは重要です。

ドメイン名をお持ちの場合、トラフィックを保護するためにSSL証明書を取得する最も簡単な方法は、Let’sEncryptを使用することです。 Ubuntu18.04でNginxを使用してLet’sEncryptを保護する方法に関するガイドに従って設定できます。このガイドで作成したNginxサーバーブロックを使用してガイドに従ってください。

ドメイン名をお持ちでない場合でも、自己署名SSL証明書を使用して、テストと学習のためにサイトを保護できます。この場合も、このチュートリアルで作成したNginxサーバーブロックを使用してプロセスに従います。

ステップ11—NginxとGunicornのトラブルシューティング

アプリケーションで問題が発生している場合は、次のセクションで、インストールのトラブルシューティング方法に関するガイダンスを提供します。

NginxはDjangoアプリケーションの代わりにデフォルトページを表示しています

Nginxがアプリケーションにプロキシする代わりにデフォルトのページを表示する場合、それは通常、調整する必要があることを意味します server_name 以内 /etc/nginx/sites-available/myproject サーバーのIPアドレスまたはドメイン名を指すファイル。

Nginxは server_name 要求に応答するために使用するサーバーブロックを決定するディレクティブ。デフォルトのNginxページを取得している場合は、Nginxがリクエストをサーバーブロックに明示的に一致させることができなかったため、で定義されたデフォルトのブロックにフォールバックしています。 /etc/nginx/sites-available/default.

The server_name プロジェクトのサーバーブロック内は、選択するデフォルトのサーバーブロック内のものよりも具体的である必要があります。

NginxはDjangoアプリケーションの代わりに502BadGatewayエラーを表示しています

502エラーは、Nginxがリクエストを正常にプロキシできないことを示します。さまざまな構成の問題が502エラーで表されるため、適切にトラブルシューティングするには、より多くの情報が必要です。

詳細情報を見つける主な場所は、Nginxのエラーログです。一般に、これにより、プロキシイベント中に問題が発生した条件がわかります。次のコマンドを実行して、Nginxエラーログを確認します。

sudo tail -F /var/log/nginx/error.log

次に、ブラウザで別のリクエストを実行して、新しいエラーを生成します（ページを更新してみてください）。ログに書き込まれた新しいエラーメッセージを受け取るはずです。メッセージを読むと、問題を絞り込むのに役立つはずです。

次のようなメッセージが表示される場合があります。

connect（）からunix：/run/gunicorn.sockに失敗しました（2：そのようなファイルまたはディレクトリはありません）

これは、Nginxがを見つけることができなかったことを示しています gunicorn.sock 指定された場所にファイルします。比較する必要があります proxy_pass 内で定義された場所 /etc/nginx/sites-available/myproject の実際の場所にファイル gunicorn.sock によって生成されたファイル gunicorn.socket systemdユニット。

見つからない場合 gunicorn.sock 内のファイル /run ディレクトリ、それは一般的にsystemdソケットファイルがそれを作成できなかったことを意味します。 Gunicornソケットファイルの確認のセクションに戻り、Gunicornのトラブルシューティング手順を確認してください。

別のメッセージは次のようになります。

connect（）からunix：/run/gunicorn.sockに失敗しました（13：アクセスが拒否されました）

これは、権限の問題のためにNginxがGunicornソケットに接続できなかったことを示しています。これは、手順がrootユーザーの代わりに使用されている場合に発生する可能性があります。 sudo ユーザー。 systemdはGunicornソケットファイルを作成できますが、Nginxはそれにアクセスできません。

これは、ルートディレクトリ間の任意の時点でアクセス許可が制限されている場合に発生する可能性があります（/）そしてその gunicorn.sock ファイル。ソケットファイルへの絶対パスをに渡すことにより、ソケットファイルとその各親ディレクトリのアクセス許可と所有権の値を確認できます。 namei 指図：

namei -l /run/gunicorn.sock

Outputf: /run/gunicorn.sock
drwxr-xr-x root root /
drwxr-xr-x root root run
srw-rw-rw- root root gunicorn.sock

出力には、各ディレクトリコンポーネントの権限が表示されます。アクセス許可（最初の列）、所有者（2番目の列）、およびグループ所有者（3番目の列）を確認することにより、ソケットファイルに許可されているアクセスの種類を把握できます。

この例では、ソケットファイルとそれに至るまでの各ディレクトリにワールド読み取りおよび実行権限があります（ディレクトリの権限列はで終わります） r-x それ以外の ---). Nginxプロセスはソケットに正常にアクセスできるはずです。

ソケットにつながるディレクトリのいずれかにワールド読み取りおよび実行権限がない場合、Nginxは、ワールド読み取りおよび実行権限を許可しないか、Nginxが含まれるグループにグループ所有権を与えることによってソケットにアクセスできません。。

Djangoが表示されています：「サーバーに接続できませんでした：接続が拒否されました」

Webブラウザでアプリケーションの一部にアクセスしようとしたときにDjangoから受け取る可能性のあるメッセージの1つは次のとおりです。

OperationalError at /admin/login/
could not connect to server: Connection refused
    Is the server running on host "localhost" (127.0.0.1) and accepting
    TCP/IP connections on port 5432?

これは、DjangoがPostgresデータベースに接続できないことを示しています。 Postgresインスタンスが実行されていることを確認します。

sudo systemctl status postgresql

そうでない場合は、起動して、起動時に自動的に起動できるようにすることができます（まだ設定されていない場合）。

sudo systemctl start postgresql
sudo systemctl enable postgresql

それでも問題が解決しない場合は、データベース設定が ~/myprojectdir/myproject/settings.py ファイルは正しいです。

さらなるトラブルシューティング

追加のトラブルシューティングについては、ログが根本原因の絞り込みに役立ちます。それらのそれぞれをチェックし、問題のある領域を示すメッセージに注意してください。

次のログが役立つ場合があります。

Nginxプロセスログを確認します。 sudo journalctl -u nginx
Nginxアクセスログを確認します。 sudo less /var/log/nginx/access.log
Nginxエラーログを確認します。 sudo less /var/log/nginx/error.log
Gunicornのアプリケーションログを確認します。 sudo journalctl -u gunicorn
Gunicornソケットログを確認します。 sudo journalctl -u gunicorn.socket

構成またはアプリケーションを更新するときに、変更に適応するためにプロセスを再起動する必要がある場合があります。

Djangoアプリケーションを更新する場合は、次のコマンドを実行することで、Gunicornプロセスを再起動して変更を取得できます。

sudo systemctl restart gunicorn

Gunicornのソケットまたはサービスファイルを変更した場合は、デーモンをリロードし、次のコマンドを実行してプロセスを再開します。

sudo systemctl daemon-reload
sudo systemctl restart gunicorn.socket gunicorn.service

Nginxサーバーブロックの構成を変更する場合は、次のコマンドを実行して、構成をテストしてからNginxをテストします。

sudo nginx -t && sudo systemctl restart nginx

これらのコマンドは、構成を調整するときに変更を適用するのに役立ちます。

結論

このガイドでは、独自の仮想環境でDjangoプロジェクトをセットアップし、Djangoがクライアントリクエストを処理できるようにクライアントリクエストを変換するようにGunicornを設定しました。その後、クライアント接続を処理し、クライアントの要求に応じて正しいプロジェクトを提供するリバースプロキシとして機能するようにNginxを設定します。

Djangoは、多くの一般的な要素を提供することでプロジェクトやアプリケーションの作成を便利にし、独自の要素に集中できるようにします。このチュートリアルで説明されている一般的なツールチェーンを活用することで、単一のサーバーから作成したアプリケーションを提供できます。

getdocs

13036