前書き

Djangoは強力なWebフレームワークであり、PythonアプリケーションまたはWebサイトの開発を支援します。 Djangoには、ローカルでコードをテストするための簡素化された開発サーバーが含まれていますが、わずかに生産関連の場合でも、より安全で強力なWebサーバーが必要です。

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

前提条件と目標

このガイドを完了するには、 `+ sudo +`特権が設定された非rootユーザーを持つ新しいUbuntu 16.04サーバーインスタンスが必要です。 https://www.digitalocean.com/community/tutorials/initial-server-setup-with-ubuntu-16-04 [初期サーバーセットアップガイド]を実行して、これを設定する方法を学ぶことができます。

仮想環境にDjangoをインストールします。 プロジェクト固有の環境にDjangoをインストールすると、プロジェクトとその要件を個別に処理できます。

データベースとアプリケーションを起動して実行したら、Gunicornアプリケーションサーバーをインストールして構成します。 これは、アプリケーションへのインターフェイスとして機能し、HTTPのクライアントリクエストをアプリケーションが処理できるPython呼び出しに変換します。 次に、Gunicornの前にNginxをセットアップして、高性能な接続処理メカニズムと実装しやすいセキュリティ機能を活用します。

始めましょう。

Ubuntuリポジトリからパッケージをインストールします

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

ローカルの `+ apt +`パッケージインデックスを更新してから、パッケージをダウンロードしてインストールする必要があります。 インストールするパッケージは、プロジェクトで使用するPythonのバージョンによって異なります。

  • Python 2 *を使用している場合は、次を入力します。

sudo apt-get update
sudo apt-get install python-pip python-dev libpq-dev postgresql postgresql-contrib nginx
  • Python 3 *でDjangoを使用している場合は、次のように入力します。

sudo apt-get update
sudo apt-get install python3-pip python3-dev libpq-dev postgresql postgresql-contrib nginx

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

PostgreSQLデータベースとユーザーを作成する

Djangoアプリケーションのデータベースとデータベースユーザーをすぐに作成します。

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

Postgresのインストール中に、 + postgres + PostgreSQL管理ユーザーに対応するために、 `+ postgres +`という名前のオペレーティングシステムユーザーが作成されました。 このユーザーを使用して管理タスクを実行する必要があります。 sudoを使用し、-uオプションでユーザー名を渡すことができます。

次のように入力して、インタラクティブなPostgresセッションにログインします。

sudo -u postgres psql

要件を設定できるPostgreSQLプロンプトが表示されます。

まず、プロジェクトのデータベースを作成します。

CREATE DATABASE ;

Note

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

CREATE USER  WITH PASSWORD '';

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

デフォルトのエンコーディングをUTF-8に設定していますが、これはDjangoが期待しています。 また、デフォルトのトランザクション分離スキームを「コミット済み読み取り」に設定しています。これは、コミットされていないトランザクションからの読み取りをブロックします。 最後に、タイムゾーンを設定しています。 デフォルトでは、Djangoプロジェクトは `+ UTC`を使用するように設定されます。 これらはすべてhttps://docs.djangoproject.com/en/1.9/ref/databases/#optimizing-postgresql-s-configuration[Djangoプロジェクト自体]からの推奨事項です。

ALTER ROLE  SET client_encoding TO 'utf8';
ALTER ROLE  SET default_transaction_isolation TO 'read committed';
ALTER ROLE  SET timezone TO 'UTC';

これで、新しいユーザーに新しいデータベースを管理するアクセス権を与えることができます。

GRANT ALL PRIVILEGES ON DATABASE  TO ;

終了したら、次を入力してPostgreSQLプロンプトを終了します。

\q

プロジェクト用のPython仮想環境を作成する

データベースができたので、残りのプロジェクト要件の準備を開始できます。 管理を容易にするために、仮想環境にPython要件をインストールします。

これを行うには、最初に `+ virtualenv `コマンドにアクセスする必要があります。 これは ` pip +`でインストールできます。

  • Python 2 *を使用している場合は、 `+ pip +`をアップグレードし、次を入力してパッケージをインストールします。

sudo -H pip install --upgrade pip
sudo -H pip install virtualenv
  • Python 3 *を使用している場合は、 `+ pip +`をアップグレードし、次を入力してパッケージをインストールします。

sudo -H pip3 install --upgrade pip
sudo -H pip3 install virtualenv

`+ virtualenv +`をインストールすると、プロジェクトの形成を開始できます。 プロジェクトファイルを保存できるディレクトリを作成して移動します。

mkdir ~/
cd ~/

プロジェクトディレクトリ内で、次のように入力してPython仮想環境を作成します。

virtualenv

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

プロジェクトのPython要件をインストールする前に、仮想環境をアクティブ化する必要があります。 次のように入力して、それを行うことができます。

source /bin/activate

プロンプトが変わり、Python仮想環境内で操作していることを示す必要があります。 次のようになります: +()@:〜/ $ +

仮想環境をアクティブにして、Django、Gunicorn、および + psycopg2 + PostgreSQLアダプターをローカルインスタンスの `+ pip +`とともにインストールします。

Note

pip install django gunicorn psycopg2

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

新しいDjangoプロジェクトを作成して構成する

Pythonコンポーネントをインストールすると、実際のDjangoプロジェクトファイルを作成できます。

Djangoプロジェクトを作成する

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

django-admin.py startproject  ~/

この時点で、プロジェクトディレクトリ(この例では +〜/ +)には次の内容が含まれているはずです。

  • +〜/ myproject / manage.py +:Djangoプロジェクト管理スクリプト。

  • +〜/ myproject / myproject / +:Djangoプロジェクトパッケージ。 これには、「+ init 。py 」、「 settings.py 」、「 urls.py 」、および「 wsgi.py +」ファイルが含まれている必要があります。

  • +〜/ myproject / myprojectenv / +:前に作成した仮想環境ディレクトリ。

プロジェクト設定を調整する

新しく作成したプロジェクトファイルで最初に行うべきことは、設定を調整することです。 テキストエディターで設定ファイルを開きます。

nano ~///settings.py

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

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

〜/ myproject / 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 = ['', '', ]

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

PostgreSQLデータベース情報を使用して設定を変更します。 `+ pip `でインストールした ` psycopg2 `アダプタを使用するようDjangoに指示します。 データベース名、データベースユーザー名、データベースユーザーのパスワードを指定し、データベースがローカルコンピューターにあることを指定する必要があります。 ` PORT +`設定は空の文字列のままにしておくことができます:

〜/ myproject / myproject / settings.py

. . .

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

. . .

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

〜/ myproject / myproject / settings.py

. . .

STATIC_URL = '/static/'

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

初期プロジェクトのセットアップを完了する

これで、管理スクリプトを使用して初期データベーススキーマをPostgreSQLデータベースに移行できます。

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

次を入力して、プロジェクトの管理ユーザーを作成します。

~//manage.py createsuperuser

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

次のように入力して、すべての静的コンテンツを構成したディレクトリの場所に収集できます。

~//manage.py collectstatic

操作を確認する必要があります。 静的ファイルは、プロジェクトディレクトリ内の「+ static +」というディレクトリに配置されます。

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

次のように入力して、ポート8000​​の例外を作成します。

sudo ufw allow 8000

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

~//manage.py runserver 0.0.0.0:8000

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

http://:8000

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

image:https://assets.digitalocean.com/articles/django_gunicorn_nginx_1404/django_index.png [Django index page]

アドレスバーのURLの末尾に「+ / admin 」を追加すると、「 createsuperuser」コマンドで作成した管理ユーザー名とパスワードの入力を求められます。

画像:https://assets.digitalocean.com/articles/django_gunicorn_nginx_1404/admin_login.png [Django管理者ログイン]

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

image:https://assets.digitalocean.com/articles/django_gunicorn_nginx_1404/admin_interface.png [Django管理インターフェース]

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

Gunicornのプロジェクト提供能力のテスト

仮想環境を離れる前にやりたい最後のことは、Gunicornをテストして、アプリケーションにサービスを提供できることを確認することです。 これを行うには、プロジェクトディレクトリを入力し、 `+ gunicorn +`を使用してプロジェクトのWSGIモジュールを読み込みます。

cd ~/
gunicorn --bind 0.0.0.0:8000 .wsgi

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

Pythonのモジュール構文を使用して、アプリケーションへのエントリポイントであるDjangoの `+ wsgi.py `ファイルへの相対ディレクトリパスを指定して、Gunicornにモジュールを渡しました。 このファイルの内部には、アプリケーションとの通信に使用される「 application +」という関数が定義されています。 WSGI仕様の詳細については、https://www.digitalocean.com/community/tutorials/how-to-set-up-uwsgi-and-nginx-to-serve-python-apps-on-ubuntu-14をクリックしてください。 -04#definitions-and-concepts [こちら]。

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

これで、Djangoアプリケーションの構成が完了しました。 次のように入力して、仮想環境からバックアウトできます。

deactivate

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

Gunicorn systemdサービスファイルを作成する

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

テキストエディタでGunicornのsystemdサービスファイルを作成し、 `+ sudo +`特権で開きます。

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

メタデータと依存関係を指定するために使用される `+ [Unit] +`セクションから始めます。 ここにサービスの説明を入力し、ネットワーキングターゲットに到達した後にのみこれを開始するようにinitシステムに指示します。

/etc/systemd/system/gunicorn.service

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

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

次に、作業ディレクトリをマップし、サービスを開始するために使用するコマンドを指定します。 この場合、仮想環境内にインストールされているGunicorn実行可能ファイルへのフルパスを指定する必要があります。 Nginxは同じコンピューターにインストールされているため、プロジェクトディレクトリ内のUnixソケットにバインドします。 これは、ネットワークポートを使用するよりも安全で高速です。 ここで、オプションのGunicorn調整を指定することもできます。 たとえば、この場合、3つのワーカープロセスを指定しました。

/etc/systemd/system/gunicorn.service

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

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

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

/etc/systemd/system/gunicorn.service

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

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

[Install]
WantedBy=multi-user.target

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

これで、作成したGunicornサービスを開始し、起動時に開始できるように有効化できます。

sudo systemctl start gunicorn
sudo systemctl enable gunicorn

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

Gunicornソケットファイルを確認する

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

sudo systemctl status gunicorn

次に、プロジェクトディレクトリ内の `+ .sock +`ファイルの存在を確認します。

ls /home//
Outputmanage.py  myproject  myprojectenv    static

`+ systemctl status `コマンドがエラーの発生を示した場合、またはディレクトリに ` .sock +`ファイルが見つからない場合、Gunicornが正しく起動できなかったことを示しています。 次を入力してGunicornプロセスログを確認します。

sudo journalctl -u gunicorn

ログのメッセージを見て、Gunicornがどこで問題に遭遇したかを調べてください。 問題が発生した可能性がある多くの理由がありますが、Gunicornがソケットファイルを作成できなかった場合、多くの場合、次のいずれかの理由によります。

  • プロジェクトファイルは、 + sudo`ユーザーの代わりに + root`ユーザーによって所有されています

  • `+ / etc / systemd / system / gunicorn.service `ファイル内の ` WorkingDirectory +`パスはプロジェクトディレクトリを指していません

  • `+ ExecStart `ディレクティブで ` gunicorn +`プロセスに与えられた設定オプションは正しくありません。 次の項目を確認してください。

  • `+ gunicorn +`バイナリへのパスは、仮想環境内のバイナリの実際の場所を指します

  • `+-bind +`ディレクティブは、Gunicornがアクセスできるディレクトリ内に作成するファイルを定義します

  • `+ .wsgi:application `はWSGI呼び出し可能オブジェクトへの正確なパスです。 これは、 ` WorkingDirectory `にいるとき、 ` .wsgi `モジュール( `。/ myproject / wsgi.py + `)

`+ / etc / systemd / system / gunicorn.service +`ファイルに変更を加えた場合、デーモンをリロードしてサービス定義を再読み込みし、次のように入力してGunicornプロセスを再起動します。

sudo systemctl daemon-reload
sudo systemctl restart gunicorn

続行する前に、上記の問題のいずれかをトラブルシューティングしてください。

NunicornをGunicornにプロキシパスするように構成する

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

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

sudo nano /etc/nginx/sites-available/

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

/ etc / nginx / sites-available / myproject

server {
   listen 80;
   server_name ;
}

次に、ファビコンを見つける際の問題を無視するようにNginxに指示します。 また、 `+〜// static +`ディレクトリで収集した静的アセットの場所を指定します。 これらのファイルにはすべて「/ static」の標準URIプレフィックスが付いているため、これらの要求に一致する場所ブロックを作成できます。

/ etc / nginx / sites-available / myproject

server {
   listen 80;
   server_name ;

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

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

/ etc / nginx / sites-available / myproject

server {
   listen 80;
   server_name ;

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

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

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

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

次のように入力して、構文エラーのNginx設定をテストします。

sudo nginx -t

エラーが報告されていない場合は、次のように入力してNginxを再起動します。

sudo systemctl restart nginx

最後に、ポート80で通常のトラフィックに対してファイアウォールを開く必要があります。 開発サーバーにアクセスする必要がなくなったため、ポート8000​​を開くルールも削除できます。

sudo ufw delete allow 8000
sudo ufw allow 'Nginx Full'

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

Note

NginxとGunicornのトラブルシューティング

この最後の手順でアプリケーションが表示されない場合は、インストールのトラブルシューティングを行う必要があります。

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

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

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

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

NginxがDjangoアプリケーションの代わりに502 Bad Gatewayエラーを表示している

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

詳細情報を検索する主な場所は、Nginxのエラーログです。 通常、これにより、プロキシイベント中に問題が発生した条件がわかります。 次のように入力して、Nginxエラーログに従います。

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

次に、ブラウザで別のリクエストを行って、新しいエラーを生成します(ページを更新してみてください)。 ログに新しいエラーメッセージが書き込まれます。 メッセージを見ると、問題を絞り込むのに役立ちます。

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

  • unix:/home/sammy/myproject/myproject.sockへのconnect()が失敗しました(2:そのようなファイルまたはディレクトリはありません)*

これは、Nginxが指定された場所で `+ myproject.sock `ファイルを見つけられなかったことを示しています。 ` / etc / nginx / sites-available / myproject `ファイル内で定義された ` proxy_pass `の場所を、プロジェクトディレクトリで生成された ` myproject.sock +`ファイルの実際の場所と比較する必要があります。

プロジェクトディレクトリ内で `+ myproject.sock `ファイルが見つからない場合、一般的には ` gunicorn +`プロセスがそれを作成できなかったことを意味します。 リンク:#check-for-the-gunicorn-socket-file [Gunicornソケットファイルの確認に関するセクション]に戻って、Gunicornのトラブルシューティング手順を実行します。

  • unix:/home/sammy/myproject/myproject.sockへのconnect()が失敗しました(13:許可が拒否されました)*

これは、権限の問題により、NginxがGunicornソケットに接続できなかったことを示しています。 通常、これは、 `+ sudo +`ユーザーの代わりにrootユーザーを使用して手順に従うと発生します。 Gunicornプロセスはソケットファイルを作成できますが、Nginxはアクセスできません。

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

namei -nom /home/sammy/myproject/myproject.sock
Outputf: /home/sammy/myproject/myproject.sock
drwxr-xr-x root  root     /
drwxr-xr-x root  root     home
drwxr-xr-x sammy sammy    sammy
drwxrwxr-x sammy sammy    myproject
srwxrwxrwx sammy www-data myproject.sock

出力には、各ディレクトリコンポーネントの権限が表示されます。 アクセス許可(1列目)、所有者(2列目)、グループ所有者(3列目)を調べることで、ソケットファイルへのアクセスが許可されているタイプを把握できます。

上記の例では、ソケットファイルと、ソケットファイルに至る各ディレクトリには、読み取りと実行の権限があります(ディレクトリの権限列は、「+ — 」ではなく「 r-x +」で終わります) 。 Nginxプロセスは、ソケットに正常にアクセスできるはずです。

ソケットにつながるディレクトリのいずれかがワールドの読み取りおよび実行の許可を持っていない場合、Nginxは、ワールドの読み取りおよび実行の許可を許可するか、Nginxが属するグループにグループ所有権が付与されることなく、ソケットにアクセスできませんの。 `+ / root +`ディレクトリのような機密性の高い場所では、上記のオプションは両方とも危険です。 プロジェクトファイルをディレクトリ外に移動すると、セキュリティを損なうことなく安全にアクセスを制御できます。

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

それでも問題が解決しない場合は、 `+〜/ myproject / myproject / settings.py +`ファイルで定義されているデータベース設定が正しいことを確認してください。

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

追加のトラブルシューティングのために、ログは根本原因を絞り込むのに役立ちます。 それぞれを順番に確認し、問題のある領域を示すメッセージを探します。

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

  • 「+ sudo journalctl -u nginx + `」と入力して、Nginxプロセスログを確認します。

  • 「+ sudo less / var / log / nginx / access.log + `」と入力して、Nginxのアクセスログを確認します。

  • 「+ sudo less / var / log / nginx / error.log + `」と入力して、Nginxエラーログを確認します。

  • 「+ sudo journalctl -u gunicorn +」と入力して、Gunicornアプリケーションログを確認します。

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

Djangoアプリケーションを更新する場合、次のように入力してGunicornプロセスを再起動し、変更を反映できます。

sudo systemctl restart gunicorn

+ gunicorn + systemdサービスファイルを変更する場合は、デーモンをリロードし、次のように入力してプロセスを再起動します。

sudo systemctl daemon-reload
sudo systemctl restart gunicorn

Nginxサーバーブロックの構成を変更する場合は、構成をテストしてから、次のように入力してNginxをテストします。

sudo nginx -t && sudo systemctl restart nginx

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

結論

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

Djangoは、多くの共通部分を提供することでプロジェクトとアプリケーションの作成を簡単にし、独自の要素に集中できるようにします。 この記事で説明した一般的なツールチェーンを活用することで、単一のサーバーから作成したアプリケーションを簡単に提供できます。