序章

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

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

前提条件と目標

このガイドを完了するには、sudo権限が設定されたroot以外のユーザーがいる新しいUbuntu16.04サーバーインスタンスが必要です。 初期サーバーセットアップガイドを実行すると、これをセットアップする方法を学ぶことができます。

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

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

始めましょう。

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

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

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

Python 2 を使用している場合は、次のように入力します。

  1. sudo apt-get update
  2. sudo apt-get install python-pip python-dev libpq-dev postgresql postgresql-contrib nginx

Python 3 でDjangoを使用している場合は、次のように入力します。

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

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

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

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

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

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

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

  1. sudo -u postgres psql

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

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

  1. CREATE DATABASE myproject;

ノート

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

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

  1. CREATE USER myprojectuser WITH PASSWORD 'password';

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

Djangoが期待するデフォルトのエンコーディングをUTF-8に設定しています。 また、デフォルトのトランザクション分離スキームを「読み取りコミット」に設定しています。これは、コミットされていないトランザクションからの読み取りをブロックします。 最後に、タイムゾーンを設定します。 デフォルトでは、DjangoプロジェクトはUTCを使用するように設定されます。 これらはすべて、Djangoプロジェクト自体からの推奨事項です。

  1. ALTER ROLE myprojectuser SET client_encoding TO 'utf8';
  2. ALTER ROLE myprojectuser SET default_transaction_isolation TO 'read committed';
  3. ALTER ROLE myprojectuser SET timezone TO 'UTC';

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

  1. GRANT ALL PRIVILEGES ON DATABASE myproject TO myprojectuser;

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

  1. \q

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

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

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

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

  1. sudo -H pip install --upgrade pip
  2. sudo -H pip install virtualenv

Python 3 を使用している場合は、pipをアップグレードし、次のように入力してパッケージをインストールします。

  1. sudo -H pip3 install --upgrade pip
  2. sudo -H pip3 install virtualenv

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

  1. mkdir ~/myproject
  2. cd ~/myproject

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

  1. virtualenv myprojectenv

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

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

  1. source myprojectenv/bin/activate

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

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

ノート

使用しているPythonのバージョンに関係なく、仮想環境がアクティブ化されている場合は、pipコマンドを使用する必要があります(pip3ではありません)。

  1. pip install django gunicorn psycopg2

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

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

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

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

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

  1. django-admin.py startproject myproject ~/myproject

この時点で、プロジェクトディレクトリ(この場合は~/myproject)には次のコンテンツが含まれているはずです。

  • ~/myproject/manage.py:Djangoプロジェクト管理スクリプト。
  • ~/myproject/myproject/:Djangoプロジェクトパッケージ。 これには、__init__.pysettings.pyurls.py、およびwsgi.pyファイルが含まれている必要があります。
  • ~/myproject/myprojectenv/:以前に作成した仮想環境ディレクトリ。

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

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

  1. nano ~/myproject/myproject/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 = ['your_server_domain_or_IP', 'second_domain_or_IP', . . .]

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

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

〜/ myproject / myproject / settings.py
. . .

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

. . .

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

〜/ myproject / myproject / settings.py
. . .

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

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

プロジェクトの初期設定を完了する

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

  1. ~/myproject/manage.py makemigrations
  2. ~/myproject/manage.py migrate

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

  1. ~/myproject/manage.py createsuperuser

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

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

  1. ~/myproject/manage.py collectstatic

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

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

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

  1. sudo ufw allow 8000

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

  1. ~/myproject/manage.py runserver 0.0.0.0:8000

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

http://server_domain_or_IP:8000

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

Django index page

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

Django admin login

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

Django admin interface

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

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

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

  1. cd ~/myproject
  2. gunicorn --bind 0.0.0.0:8000 myproject.wsgi

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

注: Gunicornはこれに関与する静的CSSコンテンツを認識していないため、管理インターフェースにはスタイルが適用されません。

Pythonのモジュール構文を使用して、アプリケーションへのエントリポイントであるDjangoのwsgi.pyファイルへの相対ディレクトリパスを指定することにより、Gunicornにモジュールを渡しました。 このファイルの中には、applicationという関数が定義されており、アプリケーションとの通信に使用されます。 WSGI仕様の詳細については、ここをクリックをクリックしてください。

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

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

  1. deactivate

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

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

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

テキストエディタでsudo権限を持つGunicornのsystemdサービスファイルを作成して開きます。

  1. 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=sammy
Group=www-data
WorkingDirectory=/home/sammy/myproject
ExecStart=/home/sammy/myproject/myprojectenv/bin/gunicorn --access-logfile - --workers 3 --bind unix:/home/sammy/myproject/myproject.sock myproject.wsgi:application

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

/etc/systemd/system/gunicorn.service
[Unit]
Description=gunicorn daemon
After=network.target

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

[Install]
WantedBy=multi-user.target

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

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

  1. sudo systemctl start gunicorn
  2. sudo systemctl enable gunicorn

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

Gunicornソケットファイルを確認してください

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

  1. sudo systemctl status gunicorn

次に、プロジェクトディレクトリ内にmyproject.sockファイルが存在するかどうかを確認します。

  1. ls /home/sammy/myproject
Output
manage.py myproject myprojectenv myproject.sock static

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

  1. sudo journalctl -u gunicorn

ログのメッセージを見て、Gunicornが問題に遭遇した場所を見つけてください。 問題が発生した理由はたくさんありますが、Gunicornがソケットファイルを作成できなかった場合は、次のいずれかの理由が考えられます。

  • プロジェクトファイルは、sudoユーザーではなく、rootユーザーが所有しています。
  • /etc/systemd/system/gunicorn.serviceファイル内のWorkingDirectoryパスがプロジェクトディレクトリを指していません
  • ExecStartディレクティブでgunicornプロセスに指定された構成オプションが正しくありません。 次の項目を確認してください。 gunicornバイナリへのパスは、仮想環境内のバイナリの実際の場所を指します。–bindディレクティブは、Gunicornがアクセスできるディレクトリ内に作成するファイルを定義します。myproject.wsgi:applicationは、WSGI呼び出し可能オブジェクトへの正確なパスです。 つまり、WorkingDirectoryにいるときは、myproject.wsgiモジュール(./myproject/wsgi.pyというファイルに変換されます)を調べることで、呼び出し可能な名前付きアプリケーションにアクセスできるはずです。

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

  1. sudo systemctl daemon-reload
  2. sudo systemctl restart gunicorn

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

NginxをGunicornへのプロキシパスに設定する

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

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

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

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

/ etc / nginx / sites-available / myproject
server {
    listen 80;
    server_name server_domain_or_IP;
}

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

/ 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/myproject;
    }
}

最後に、他のすべてのリクエストに一致するlocation / {}ブロックを作成します。 この場所の中に、Nginxインストールに含まれている標準のproxy_paramsファイルを含め、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/myproject;
    }

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

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

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

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

  1. sudo nginx -t

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

  1. sudo systemctl restart nginx

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

  1. sudo ufw delete allow 8000
  2. sudo ufw allow 'Nginx Full'

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

ノート

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

ドメイン名をお持ちの場合、トラフィックを保護するためにSSL証明書を取得する最も簡単な方法は、Let’sEncryptを使用することです。 このガイドに従って、Ubuntu16.04でLet’sEncryptwithNginxを設定します。

ドメイン名をお持ちでない場合でも、自己署名SSL証明書を使用して、テストと学習のためにサイトを保護できます。

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

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

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

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

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

プロジェクトのサーバーブロックのserver_nameよりも具体的である必要があります。

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

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

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

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

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

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

connect()to unix:/home/sammy/myproject/myproject.sock failed(2:そのようなファイルまたはディレクトリはありません)

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

プロジェクトディレクトリ内にmyproject.sockファイルが見つからない場合は、通常、gunicornプロセスがファイルを作成できなかったことを意味します。 Gunicornソケットファイルの確認に関するセクションに戻り、Gunicornのトラブルシューティング手順を実行します。

connect()からunix:/home/sammy/myproject/myproject.sockに失敗しました(13:アクセスが拒否されました)

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

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

  1. namei -nom /home/sammy/myproject/myproject.sock
Output
f: /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

出力には、各ディレクトリコンポーネントのアクセス許可が表示されます。 アクセス許可(最初の列)、所有者(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インスタンスが実行されていることを確認します。

  1. sudo systemctl status postgresql

そうでない場合は、次のように入力して、起動し、起動時に自動的に起動できるようにすることができます(まだ設定されていない場合)。

  1. sudo systemctl start postgresql
  2. 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プロセスを再起動して、次のように入力することで変更を取得できます。

  1. sudo systemctl restart gunicorn

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

  1. sudo systemctl daemon-reload
  2. sudo systemctl restart gunicorn

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

  1. sudo nginx -t && sudo systemctl restart nginx

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

結論

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

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