Ubuntu16.04でuWSGIとNginxを使用してDjangoアプリケーションを提供する方法

getdocs

2年前

序章

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

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

前提条件と目標

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

Djangoを2つの異なる仮想環境にインストールします。これにより、プロジェクトとその要件を個別に処理できるようになります。マルチプロジェクト環境で手順を実行できるように、2つのサンプルプロジェクトを作成します。

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

始めましょう。

VirtualEnvとVirtualEnvWrapperをインストールして構成します

Djangoプロジェクトを独自の仮想環境にインストールして、それぞれの要件を分離します。これを行うために、インストールします virtualenv、Python仮想環境を作成できます。 virtualenvwrapper、これにより、ユーザビリティが向上します。 virtualenv ワークフロー。

これらのコンポーネントの両方を使用してインストールします pip、Pythonパッケージマネージャー。このユーティリティはUbuntuリポジトリからインストールできます。

Python 2 を使用してDjangoプロジェクトをビルドしている場合は、次のように入力します。

sudo apt-get update
sudo apt-get install python-pip

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

sudo apt-get update
sudo apt-get install python3-pip

今、あなたは pip インストール、インストールできます virtualenv と virtualenvwrapper グローバルに。また、アップグレードします pip を使用して最新バージョンに pip 自体。

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

sudo -H pip install --upgrade pip
sudo -H pip install virtualenv virtualenvwrapper

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

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

これらのコンポーネントがインストールされたら、シェルを操作するために必要な情報を使用してシェルを構成できます。 virtualenvwrapper 脚本。仮想環境はすべて、ホームフォルダ内の次のディレクトリに配置されます。 Env 簡単にアクセスできます。これは、と呼ばれる環境変数を介して構成されます WORKON_HOME. これをシェル初期化スクリプトに追加して、仮想環境ラッパースクリプトを入手できます。

Python3を使用している場合 pip3 コマンドを実行するには、シェル初期化スクリプトにも次の行を追加する必要があります。

echo "export VIRTUALENVWRAPPER_PYTHON=/usr/bin/python3" >> ~/.bashrc

使用しているPythonのバージョンに関係なく、次のコマンドを実行する必要があります。

echo "export WORKON_HOME=~/Env" >> ~/.bashrc
echo "source /usr/local/bin/virtualenvwrapper.sh" >> ~/.bashrc

次に、シェル初期化スクリプトを入手して、現在のセッションでこの機能を使用できるようにします。

source ~/.bashrc

これで、次のディレクトリが作成されます。 Env 仮想環境情報を保持するホームフォルダにあります。

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

仮想環境ツールができたので、2つの仮想環境を作成し、それぞれにDjangoをインストールして、2つのプロジェクトを開始します。

最初のプロジェクトを作成する

いくつかのコマンドを使用して、仮想環境を簡単に作成できます。 virtualenvwrapper スクリプトが利用可能になります。

次のように入力して、最初のサイトまたはプロジェクトの名前で最初の仮想環境を作成します。

mkvirtualenv firstsite

これにより、仮想環境が作成され、Pythonがインストールされ、 pip その中で、環境をアクティブにします。プロンプトが変わり、新しい仮想環境内で操作していることを示します。次のようになります。 (firstsite)user@hostname:~$. 括弧内の値は、仮想環境の名前です。を介してインストールされたソフトウェア pip これで、グローバルシステムではなく、仮想環境にインストールされます。これにより、プロジェクトごとにパッケージを分離できます。

最初のステップは、Django自体をインストールすることです。使用できます pip これなしで sudo これを仮想環境にローカルにインストールしているため、次のようになります。

pip install django

Djangoをインストールしたら、次のように入力して最初のサンプルプロジェクトを作成できます。

cd ~
django-admin.py startproject firstsite

これにより、というディレクトリが作成されます firstsite ホームディレクトリ内。この中には、プロジェクトのさまざまな側面を処理するために使用される管理スクリプトと、実際のプロジェクトコードを格納するために使用される同じ名前の別のディレクトリがあります。

サンプルプロジェクトの最小要件の設定を開始できるように、第1レベルのディレクトリに移動します。

cd ~/firstsite

データベースを移行して、プロジェクトで使用するSQLiteデータベースを初期化することから始めます。必要に応じて、アプリケーションの代替データベースを設定できますが、これはこのガイドの範囲外です。

~/firstsite/manage.py migrate

これで、というデータベースファイルが作成されます。 db.sqlite3 プロジェクトディレクトリにあります。これで、次のように入力して管理ユーザーを作成できます。

~/firstsite/manage.py createsuperuser

この時点で、プロジェクトディレクトリ（~/firstsite この場合）には、次の内容が含まれている必要があります。

~/firstsite/manage.py：Djangoプロジェクト管理スクリプト。
~/firstsite/firstsite/：Djangoプロジェクトパッケージ。これには、 __init__.py, settings.py, urls.py、と wsgi.py ファイル。
~/firstsite/db.sqlite3：サイト情報の保存に使用されるSQLiteデータベースファイル。

次に、テキストエディタでプロジェクトの設定ファイルを開きます。

nano ~/firstsite/firstsite/settings.py

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

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

〜/ firstsite / firstsite / 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', . . .]

サイトにサービスを提供するようにNginxを設定するため、サイトの静的アセットを保持するディレクトリを構成する必要があります。これにより、Nginxがこれらを直接提供できるようになり、パフォーマンスにプラスの影響があります。これらを次のディレクトリに配置するようにDjangoに指示します static プロジェクトのベースディレクトリにあります。この動作を構成するには、ファイルの最後に次の行を追加します。

〜/ firstsite / firstsite / settings.py

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

終了したら、ファイルを保存して閉じます。次に、サイトの静的要素を収集し、次のように入力してそのディレクトリ内に配置します。

~/firstsite/manage.py collectstatic

アクションを確認して静的コンテンツを収集するために、「yes」と入力するように求められる場合があります。と呼ばれる新しいディレクトリがあります static プロジェクトディレクトリにあります。

次に、ポートを開いてDjango開発サーバーにアクセスできるようにします。サーバーの初期設定ガイドに従っている場合は、UFWファイアウォールを有効にする必要があります。次のように入力して、ポート8080への接続を許可します。

sudo ufw allow 8080

これらすべてが終わったら、開発サーバーを一時的に起動してプロジェクトをテストできます。タイプ：

~/firstsite/manage.py runserver 0.0.0.0:8080

これにより、ポートで開発サーバーが起動します 8080. サーバーのドメイン名またはIPアドレスにアクセスし、その後に 8080 ブラウザで：

http://server_domain_or_IP:8080

次のようなページが表示されます。

追加 /admin ブラウザのアドレスバーのURLの最後に移動すると、管理者ログインページに移動します。

で選択した管理ログイン資格情報を使用する createsuperuser コマンド、サーバーにログインします。これで、管理インターフェイスにアクセスできるようになります。

この機能をテストした後、ターミナルで CTRL-C と入力して、開発サーバーを停止します。これで、2番目のプロジェクトに進むことができます。

2番目のプロジェクトを作成する

2番目のプロジェクトは、最初のプロジェクトとまったく同じ方法で作成されます。このセクションの説明は、あなたがすでにこれをどのように完了したかを見て、簡略化します。

ホームディレクトリに戻り、新しいプロジェクト用の2番目の仮想環境を作成します。アクティベートされたら、この新しい環境内にDjangoをインストールします。

cd ~
mkvirtualenv secondsite
pip install django

新しい環境が作成され、とがに変更され、以前の仮想環境が残ります。このDjangoインスタンスは、構成した他のインスタンスとは完全に分離されています。これにより、それらを個別に管理し、必要に応じてカスタマイズできます。

2番目のプロジェクトを作成し、プロジェクトディレクトリに移動します。

cd ~
django-admin.py startproject secondsite
cd ~/secondsite

データベースを初期化し、管理ユーザーを作成します。

~/secondsite/manage.py migrate
~/secondsite/manage.py createsuperuser

設定ファイルを開きます。

nano ~/secondsite/secondsite/settings.py

をセットする ALLOWED_HOSTS 最初のプロジェクトで行ったのと同じように、2番目のプロジェクトのドメイン、サーバーのIPアドレス、またはその両方に。

ALLOWED_HOSTS = ['second_project_domain_or_IP', 'another_domain_or_IP', . . .]

前のプロジェクトで行ったように、静的ファイルの場所を追加します。

〜/ secondsite / secondsite / settings.py

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

ファイルを保存して閉じます。次に、次のように入力して、静的要素をそのディレクトリに収集します。

~/secondsite/manage.py collectstatic

最後に、開発サーバーを起動してサイトをテストします。

~/secondsite/manage.py runserver 0.0.0.0:8080

次の通常のサイトを確認する必要があります。

http://server_domain_or_IP:8080

また、管理サイトにログインします。

http://server_domain_or_IP:8080/admin

すべてが期待どおりに機能していることを確認したら、端末に CTRL-C と入力して、開発サーバーを停止します。

仮想環境からのバックアウト

ガイドのDjangoの部分が終了したので、2番目の仮想環境を非アクティブ化できます。

deactivate

いずれかのDjangoサイトで再度作業する必要がある場合は、それぞれの環境を再アクティブ化する必要があります。あなたはを使用してそれを行うことができます workon 指図：

workon firstsite

または：

workon secondsite

繰り返しますが、サイトでの作業が終了したら非アクティブ化します。

deactivate

これで、アプリケーションサーバーの構成に進むことができます。

uWSGIアプリケーションサーバーのセットアップ

2つのDjangoプロジェクトをセットアップして準備ができたので、uWSGIを構成できます。 uWSGIは、WSGIと呼ばれる標準インターフェイスを介してアプリケーションと通信できるアプリケーションサーバーです。これについて詳しくは、Ubuntu14.04でのuWSGIとNginxのセットアップに関するガイドのこのセクションをお読みください。

uWSGIのインストール

上記のリンク先のガイドとは異なり、このチュートリアルでは、uWSGIをグローバルにインストールします。これにより、複数のDjangoプロジェクトを処理する際の摩擦が少なくなります。 uWSGIをインストールする前に、ソフトウェアが依存するPython開発ファイルが必要です。これはUbuntuのリポジトリから直接インストールできます。

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

sudo apt-get install python-dev

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

sudo apt-get install python3-dev

開発ファイルが利用可能になったので、uWSGIをグローバルにインストールできます。 pip.

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

sudo -H pip install uwsgi

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

sudo -H pip3 install uwsgi

このアプリケーションサーバーは、いずれかのサイトの情報を渡すことですばやくテストできます。たとえば、次のように入力することで、最初のプロジェクトを提供するように指示できます。

uwsgi --http :8080 --home /home/sammy/Env/firstsite --chdir /home/sammy/firstsite -w firstsite.wsgi

ここでは、uWSGIに次の場所にある仮想環境を使用するように指示しました。 ~/Env ディレクトリ、プロジェクトのディレクトリに移動し、 wsgi.py 内部に保存されているファイル firstsite ファイルを提供するディレクトリ（ firstsite.wsgi Pythonモジュール構文）。デモンストレーションでは、ポートでHTTPを提供するように指示しました 8080.

ブラウザでサーバーのドメイン名またはIPアドレスに移動し、その後に :8080、あなたはあなたのサイトを再び見るでしょう（ /admin CSSのようなインターフェースはまだ機能しません）。この機能のテストが終了したら、ターミナルにCTRL-Cと入力します。

構成ファイルの作成

コマンドラインからuWSGIを実行することはテストには役立ちますが、実際の展開には特に役立ちません。代わりに、uWSGIを「エンペラーモード」で実行します。これにより、マスタープロセスは、一連の構成ファイルを指定して、個別のアプリケーションを自動的に管理できます。

構成ファイルを保持するディレクトリを作成します。これはグローバルプロセスであるため、次のディレクトリを作成します。 /etc/uwsgi/sites 構成ファイルを保存するには：

sudo mkdir -p /etc/uwsgi/sites

このディレクトリに、構成ファイルを配置します。提供しているプロジェクトごとに構成ファイルが必要です。 uWSGIプロセスは、さまざまな形式の構成ファイルを取得できますが、 .ini それらの単純さのためにファイル。

最初のプロジェクトのファイルを作成し、テキストエディタで開きます。

sudo nano /etc/uwsgi/sites/firstsite.ini

内部では、 [uwsgi] セクションヘッダー。すべての情報はこのヘッダーの下に表示されます。また、変数を使用して、構成ファイルをより再利用しやすくします。ヘッダーの後に、という変数を設定します project 最初のプロジェクトの名前で。と呼ばれる変数を追加します uid あなたを保持します sudo ユーザー名。

また、という変数を追加します base ユーザーのホームディレクトリへのパスを指定します。これは、を使用して設定したユーザー名から作成されます %(variable_name) 構文。これは、構成が読み取られるときに変数の値に置き換えられます。

/etc/uwsgi/sites/firstsite.ini

[uwsgi]
project = firstsite
uid = sammy
base = /home/%(uid)

次に、プロジェクトを正しく処理するようにuWSGIを構成する必要があります。次のように設定して、ルートプロジェクトディレクトリに変更する必要があります。 chdir オプション。同じ変数構文を使用して、ホームディレクトリとプロジェクト名を組み合わせることができます。

同様の方法で、プロジェクトの仮想環境を示します。モジュールを設定することで、プロジェクトとのインターフェース方法を正確に示すことができます（から呼び出し可能な「アプリケーション」をインポートすることにより） wsgi.py 内部プロジェクトディレクトリ内のファイル）。これらのアイテムの構成は次のようになります。

/etc/uwsgi/sites/firstsite.ini

[uwsgi]
project = firstsite
uid = sammy
base = /home/%(uid)

chdir = %(base)/%(project)
home = %(base)/Env/%(project)
module = %(project).wsgi:application

5人のワーカーでマスタープロセスを作成したいと思います。これを追加することでこれを行うことができます：

/etc/uwsgi/sites/firstsite.ini

[uwsgi]
project = firstsite
uid = sammy
base = /home/%(uid)

chdir = %(base)/%(project)
home = %(base)/Env/%(project)
module = %(project).wsgi:application

master = true
processes = 5

次に、uWSGIが接続をリッスンする方法を指定する必要があります。 uWSGIのテストでは、HTTPとネットワークポートを使用しました。ただし、リバースプロキシとしてNginxを使用するため、より適切なオプションがあります。

ネットワークポートを使用する代わりに、すべてのコンポーネントが単一のサーバーで動作しているため、Unixソケットを使用できます。これはより安全で、より良いパフォーマンスを提供します。このソケットはHTTPを使用しませんが、代わりにuWSGIを実装します uwsgi プロトコル。他のサーバーと通信するために設計された高速バイナリプロトコルです。 Nginxは、を使用してネイティブにプロキシできます uwsgi プロトコルなので、これが最善の選択です。

また、Webサーバーに書き込みアクセスを許可するため、ソケットの所有権とアクセス許可も変更します。設定します vacuum サービスが停止したときにソケットファイルが自動的にクリーンアップされるようにするオプション：

/etc/uwsgi/sites/firstsite.ini

[uwsgi]
project = firstsite
uid = sammy
base = /home/%(uid)

chdir = %(base)/%(project)
home = %(base)/Env/%(project)
module = %(project).wsgi:application

master = true
processes = 5

socket = /run/uwsgi/%(project).sock
chown-socket = %(uid):www-data
chmod-socket = 660
vacuum = true

これで、最初のプロジェクトのuWSGI構成が完了しました。ファイルを保存して閉じます。

変数を使用してファイルを設定する利点は、再利用が非常に簡単になることです。最初のプロジェクトの構成ファイルをコピーして、2番目の構成ファイルのベースとして使用します。

sudo cp /etc/uwsgi/sites/firstsite.ini /etc/uwsgi/sites/secondsite.ini

テキストエディタで2番目の構成ファイルを開きます。

sudo nano /etc/uwsgi/sites/secondsite.ini

2番目のプロジェクトで機能させるには、このファイルの1つの値を変更するだけで済みます。を変更します project 2番目のプロジェクトに使用した名前の変数：

/etc/uwsgi/sites/secondsite.ini

[uwsgi]
project = secondsite
uid = sammy
base = /home/%(uid)

chdir = %(base)/%(project)
home = %(base)/Env/%(project)
module = %(project).wsgi:application

master = true
processes = 5

socket = /run/uwsgi/%(project).sock
chown-socket = %(uid):www-data
chmod-socket = 660
vacuum = true

終了したら、ファイルを保存して閉じます。 2番目のプロジェクトは今すぐ準備ができているはずです。

uWSGIのsystemdユニットファイルを作成する

これで、Djangoプロジェクトに提供するために必要な構成ファイルができましたが、プロセスはまだ自動化されていません。次に、systemdユニットファイルを作成してuWSGIエンペラープロセスを管理し、起動時にuWSGIを自動的に起動します。

にユニットファイルを作成します /etc/systemd/system 管理者が作成したユニットファイルが保存されるディレクトリ。ファイルを呼び出します uwsgi.service:

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

から始めます [Unit] セクション。メタデータと注文情報を指定するために使用されます。ここにサービスの説明を簡単に記載します。

/etc/systemd/system/uwsgi.service

[Unit]
Description=uWSGI Emperor service

次に、 [Service] セクション。を使用します ExecStartPre サーバーを実行するために必要な部分をセットアップするためのディレクティブ。これにより、 /run/uwsgi ディレクトリが作成され、通常のユーザーがそれを所有している www-data グループ所有者としてのグループ。両方 mkdir とともに -p 旗と chown コマンドは、操作が不要な場合でも正常に戻ります。これが私たちが望んでいることです。

実際の開始コマンドの場合、 ExecStart ディレクティブ、私たちはポイントします uwsgi 実行可能。「Emperormode」で実行するように指示し、見つかったファイルを使用して複数のアプリケーションを管理できるようにします /etc/uwsgi/sites. また、systemdがプロセスを正しく管理するために必要な要素を追加します。これらは、uWSGIドキュメントここから取得されます。

/etc/systemd/system/uwsgi.service

[Unit]
Description=uWSGI Emperor service

[Service]
ExecStartPre=/bin/bash -c 'mkdir -p /run/uwsgi; chown sammy:www-data /run/uwsgi'
ExecStart=/usr/local/bin/uwsgi --emperor /etc/uwsgi/sites
Restart=always
KillSignal=SIGQUIT
Type=notify
NotifyAccess=all

今、私たちがする必要があるのは、 [Install] セクション。これにより、サービスを自動的に開始するタイミングを指定できます。サービスをマルチユーザーシステムの状態に結び付けます。システムが複数のユーザー向けに設定されている場合（通常の動作状態）、当社のサービスがアクティブになります。

/etc/systemd/system/uwsgi.service

[Unit]
Description=uWSGI Emperor service

[Service]
ExecStartPre=/bin/bash -c 'mkdir -p /run/uwsgi; chown sammy:www-data /run/uwsgi'
ExecStart=/usr/local/bin/uwsgi --emperor /etc/uwsgi/sites
Restart=always
KillSignal=SIGQUIT
Type=notify
NotifyAccess=all

[Install]
WantedBy=multi-user.target

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

サービスはに依存しているため、現時点ではサービスを正常に開始できません。 www-data ユーザーが利用可能です。 Nginxがインストールされるまで、uWSGIサービスの開始を待つ必要があります。

Nginxをリバースプロキシとしてインストールおよび構成する

uWSGIを構成して準備ができたら、Nginxをリバースプロキシとしてインストールして構成できます。これは、Ubuntuのデフォルトのリポジトリからダウンロードできます。

sudo apt-get install nginx

Nginxをインストールしたら、プロジェクトごとにサーバーブロック構成ファイルを作成できます。サーバーブロック構成ファイルを作成して、最初のプロジェクトから開始します。

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

内部では、最初のプロジェクトにアクセスできるポート番号とドメイン名を指定することで、サーバーブロックを開始できます。 The server_name ブロックはサーバーのドメイン名またはそのIPアドレスの1つと一致する必要があります。そうでない場合は、代わりにデフォルトのNginxページを使用できます。それぞれにドメイン名があると想定します。

/ etc / nginx / sites-available / firstsite

server {
    listen 80;
    server_name firstsite.com www.firstsite.com;
}

次に、ファビコンが見つからなくても心配しないようにNginxに指示できます。また、サイトの静的要素を収集した静的ファイルディレクトリの場所も示します。

/ etc / nginx / sites-available / firstsite

server {
    listen 80;
    server_name firstsite.com www.firstsite.com;

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

次に、すべての追加クエリをアプリケーションに直接渡すキャッチオールロケーションブロックを作成できます。含まれます uwsgi にあるパラメータ /etc/nginx/uwsgi_params そして、uWSGIサーバーが設定するソケットにトラフィックを渡します。

/ etc / nginx / sites-available / firstsite

server {
    listen 80;
    server_name firstsite.com www.firstsite.com;

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

    location / {
        include         uwsgi_params;
        uwsgi_pass      unix:/run/uwsgi/firstsite.sock;
    }
}

これで、最初のサーバーブロックが完成しました。

これを2番目のプロジェクトのNginx構成ファイルの基礎として使用します。今すぐコピーしてください：

sudo cp /etc/nginx/sites-available/firstsite /etc/nginx/sites-available/secondsite

テキストエディタで新しいファイルを開きます。

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

ここでは、への参照を変更する必要があります firstsite を参照して secondsite. また、変更する必要があります server_name 2番目のプロジェクトが別のドメイン名に応答するようにするか、複数のドメイン名またはIPアドレスがない場合はポートを変更します。終了すると、次のようになります。

/ etc / nginx / sites-available / secondsite

server {
    listen 80;
    server_name secondsite.com www.secondsite.com;

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

    location / {
        include         uwsgi_params;
        uwsgi_pass      unix:/run/uwsgi/secondsite.sock;
    }
}

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

次に、両方の新しい構成ファイルをNginxにリンクします sites-enabled それらを有効にするディレクトリ：

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

次のように入力して、構成構文を確認します。

sudo nginx -t

構文エラーが検出されない場合は、Nginxサービスを再起動して、新しい構成をロードできます。

sudo systemctl restart nginx

以前から覚えていると思いますが、実際にuWSGIサーバーを起動したことはありません。次のように入力して、今すぐ実行してください。

sudo systemctl start uwsgi

ポートへのUFWルールを削除しましょう 8080 代わりに、Nginxサーバーへのアクセスを許可します。

sudo ufw delete allow 8080
sudo ufw allow 'Nginx Full'

これで、それぞれのドメイン名に移動して、2つのプロジェクトにアクセスできるようになります。パブリックインターフェイスと管理インターフェイスの両方が期待どおりに機能するはずです。

これがうまくいけば、次のように入力して、起動時に両方のサービスを自動的に開始できるようにすることができます。

sudo systemctl enable nginx
sudo systemctl enable uwsgi

ノート

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

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

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

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

アプリケーションにアクセスできない場合は、インストールのトラブルシューティングを行う必要があります。

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

Nginxがアプリケーションにプロキシする代わりにデフォルトのページを表示する場合、それは通常、調整する必要があることを意味します server_name 以内 /etc/nginx/sites-available/firstsite サーバーの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/uwsgi/firstsite.sockに失敗しました（2：そのようなファイルまたはディレクトリはありません）

これは、Nginxが指定された場所でソケットファイルを見つけることができなかったことを示しています。比較する必要があります uwsgi_pass で定義された場所 firstsite と secondsite のファイル /etc/nginx/sites-available の実際の場所にファイル firstsite.sock と secondsite.sock のソケットファイル /run/uwsgi ディレクトリ。

内にソケットファイルが存在するかどうかを確認します /run/uwsgi 次のように入力してディレクトリを作成します。

sudo ls /run/uwsgi

にソケットファイルがない場合 /run/uwsgi、それは一般的に uwsgi プロセスはそれを作成できませんでした。のステータスを確認してください uwsgi 開始できたかどうかを確認するプロセス：

sudo systemctl status uwsgi

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

sudo journalctl -u uwsgi

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

プロジェクトファイルは、 root の代わりにユーザー sudo ユーザー
The ExecStartPre の行 /etc/systemd/system/uwsgi.service ファイルに、ディレクトリを作成して所有権を割り当てるための正しいコマンドが含まれていません
The uwsgi_pass のサイト構成ファイルのパス /etc/nginx/sites-available ディレクトリは正しいソケットの場所を対象としていません
で定義されたuWSGI構成 .ini 内のファイル /etc/uwsgi/sites ディレクトリが正しくありません。次の項目を確認してください。
- The chdir ディレクティブは、補間されると、メインプロジェクトディレクトリを指します。
- The home ディレクティブは、補間されると、仮想環境ディレクトリを指します。
- The module ディレクティブは、Pythonモジュールのインポート構文を使用して wsgi.py 内部プロジェクトディレクトリ内からのファイル。
- The socket ディレクティブはファイルをポイントします /run/uwsgi ファイル（によって作成される必要があります ExecStartPre 上記のサービスファイルの行）。

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

sudo systemctl daemon-reload
sudo systemctl restart uwsgi

これらの問題を修正すると、Nginxがソケットファイルを正しく検出できるようになります。

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

これは、権限の問題のためにNginxがuWSGIソケットに接続できなかったことを示しています。通常、これは、制限された環境でソケットが作成されている場合、またはアクセス許可が間違っている場合に発生します。 uWSGIプロセスはソケットファイルを作成できますが、Nginxはそれにアクセスできません。

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

namei -nom /run/uwsgi/firstsite.sock

Outputf: /run/uwsgi/firstsite.sock
 drwxr-xr-x root  root     /
 drwxr-xr-x root  root     run
 drwxr-xr-x sammy www-data uwsgi
 srw-rw---- sammy www-data firstsite.sock

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

上記の例では、ソケットファイルに至るまでの各ディレクトリにワールド読み取りおよび実行権限があります（ディレクトリの権限列はで終わります r-x それ以外の ---). The www-data グループは、ソケット自体に対するグループ所有権を持っています。これらの設定により、Nginxプロセスはソケットに正常にアクセスできるはずです。

ソケットに至るまでのディレクトリのいずれかが所有されていない場合 www-data グループ化するか、ワールド読み取りおよび実行権限がない場合、Nginxはソケットにアクセスできません。通常、これは構成ファイルに誤りがあることを意味します。

ディレクトリパスのアクセス許可または所有権が制限されすぎている場合は、 /etc/systemd/system/uwsgi.service ファイル。 The ExecStartPre ディレクティブは、 /run/uwsgi ディレクトリとグループ所有権の割り当て www-data グループ。ここでのコマンドが正しくない場合は、ディレクトリパスが制限されすぎている可能性があります。

ソケットファイル自体がNginxプロセスにアクセスできない場合、 .ini 内のファイル /etc/uwsgi/sites 正しくない可能性があります。の値を確認してください chown-socket と chmod-socket Webプロセスにファイルへのアクセス許可が与えられていることを確認します。

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

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

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

次のように入力して、Nginxプロセスログを確認します。 sudo journalctl -u nginx
次のように入力して、Nginxアクセスログを確認します。 sudo less /var/log/nginx/access.log
次のように入力して、Nginxエラーログを確認します。 sudo less /var/log/nginx/error.log
次のように入力して、uWSGIアプリケーションログを確認します。 sudo journalctl -u uwsgi

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

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

sudo systemctl restart uwsgi

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

sudo systemctl daemon-reload
sudo systemctl restart uwsgi

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

sudo nginx -t && sudo systemctl restart nginx

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

結論

このガイドでは、それぞれ独自の仮想環境に2つのDjangoプロジェクトを設定しました。それぞれに構成された仮想環境を使用して、各プロジェクトに個別にサービスを提供するようにuWSGIを構成しました。その後、クライアント接続を処理し、クライアントの要求に応じて正しいプロジェクトを提供するリバースプロキシとして機能するようにNginxを設定しました。

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