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

前書き

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

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

前提条件と目標

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

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

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

始めましょう。

VirtualEnvおよびVirtualEnvWrapperのインストールと構成

Djangoプロジェクトを独自の仮想環境にインストールして、それぞれの要件を分離します。これを行うには、Python仮想環境を作成できる `+ virtualenv `と、 ` virtualenv `ワークフローに使いやすさを向上させる ` virtualenvwrapper +`をインストールします。

Pythonパッケージマネージャーである `+ pip +`を使用して、これらのコンポーネントの両方をインストールします。このユーティリティは、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 +」と呼ばれる環境変数を通じて設定されます。これをシェル初期化スクリプトに追加して、仮想環境ラッパースクリプトをソースにできます。

Python 3 *と `+ 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

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

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

pip install django

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

cd ~
django-admin.py startproject

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

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

cd ~/

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

~//manage.py migrate

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

~//manage.py createsuperuser

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

+〜/ firstsite / manage.py +：Djangoプロジェクト管理スクリプト。
+〜/ firstsite / firstsite / +：Djangoプロジェクトパッケージ。これには、「+ init 。py 」、「 settings.py 」、「 urls.py 」、および「 wsgi.py +」ファイルが含まれている必要があります。
+〜/ firstsite / db.sqlite3 +：サイト情報を保存するために使用されるSQLiteデータベースファイル。

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

nano ~///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 = ['', '', ]

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

〜/ firstsite / firstsite / settings.py

. . .
STATIC_URL = '/static/'

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

~//manage.py collectstatic

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

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

sudo ufw allow 8080

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

~//manage.py runserver 0.0.0.0:8080

これにより、ポート `+ 8080 `で開発サーバーが起動します。ブラウザのサーバーのドメイン名またはIPアドレスの後に「+8080」を入力します。

http://:8080

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

image：https：//assets.digitalocean.com/articles/django_uwsgi_nginx_1404/sample_site.png [Djangoサンプルサイト]

ブラウザのアドレスバーのURLの末尾に「+ / admin +」を追加すると、管理者ログインページが表示されます。

画像：https：//assets.digitalocean.com/articles/django_uwsgi_nginx_1404/admin_login.png [Django admin login]

`+ createsuperuser +`コマンドで選択した管理ログイン資格情報を使用して、サーバーにログインします。その後、管理インターフェイスにアクセスできます。

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

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

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

2番目のプロジェクトは、最初のプロジェクトとまったく同じ方法で作成されます。このセクションの説明は、すでにこれを1回完了しているものとして、簡略化します。

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

cd ~
mkvirtualenv
pip install django

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

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

cd ~
django-admin.py startproject
cd ~/

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

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

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

nano ~///settings.py

最初のプロジェクトで行ったように、2番目のプロジェクトのドメイン、サーバーのIPアドレス、またはその両方に「+ ALLOWED_HOSTS +」を設定します。

ALLOWED_HOSTS = ['', '', ]

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

〜/ secondsite / secondsite / settings.py

. . .
STATIC_URL = '/static/'

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

~//manage.py collectstatic

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

~//manage.py runserver 0.0.0.0:8080

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

http://:8080

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

http://:8080/admin

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

仮想環境のバックアウト

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

deactivate

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

workon

Or:

workon

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

deactivate

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

uWSGI Application Serverのセットアップ

2つのDjangoプロジェクトがセットアップされて準備ができたので、uWSGIを構成できます。 uWSGIは、WSGIと呼ばれる標準インターフェイスを介してアプリケーションと通信できるアプリケーションサーバーです。詳細については、https：//www.digitalocean.com/community/tutorials/how-to-set-up-uwsgi-and-nginx-to-serve-python-apps-on-ubuntu-14-04をご覧ください。 Ubuntu 14.04でのuWSGIおよびNginxのセットアップに関するガイドの＃definitions-and-concepts [このセクション]。

uWSGIのインストール

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

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

sudo apt-get install python-dev

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

sudo apt-get install python3-dev

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

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

sudo -H pip install uwsgi

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

sudo -H pip3 install uwsgi

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

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

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

ブラウザでサーバーのドメイン名またはIPアドレスに移動してから「：8080」を入力すると、サイトが再び表示されます（CSSなどの「+ / admin +」インターフェイスの静的要素はまだ機能しません））。この機能のテストが終了したら、ターミナルでCTRL-Cを入力します。

構成ファイルの作成

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

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

sudo mkdir -p /etc/uwsgi/sites

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

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

sudo nano /etc/uwsgi/sites/.ini

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

また、ユーザーのホームディレクトリへのパスを持つ「+ base 」という変数を追加します。これは、 `％（variable_name）+`構文を使用して設定したユーザー名から構築されます。これは、構成が読み取られるときに変数の値に置き換えられます。

/etc/uwsgi/sites/firstsite.ini

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

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

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

/etc/uwsgi/sites/firstsite.ini

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

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

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

/etc/uwsgi/sites/firstsite.ini

[uwsgi]
project =
uid =
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 =
uid =
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/.ini /etc/uwsgi/sites/.ini

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

sudo nano /etc/uwsgi/sites/.ini

このファイルの1つの値を変更するだけで、2番目のプロジェクトで機能するようになります。 2番目のプロジェクトで使用した名前で `+ project +`変数を変更します。

/etc/uwsgi/sites/secondsite.ini

[uwsgi]
project =
uid =
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プロジェクトを処理するために必要な設定ファイルは用意されましたが、プロセスはまだ自動化されていません。次に、uWSGI皇帝プロセスを管理し、ブート時にuWSGIを自動的に起動するsystemdユニットファイルを作成します。

管理者が作成したユニットファイルが保存されている `+ / 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 `グループをグループ所有者として所有するようになります。 ` -p `フラグ付きの ` mkdir `と ` chown +`コマンドは、操作が不要な場合でも正常に戻ります。これが私たちが欲しいものです。

`+ ExecStart `ディレクティブで指定された実際の開始コマンドでは、 ` uwsgi `実行可能ファイルを指します。「 / etc / uwsgi / sites +」で見つかったファイルを使用して複数のアプリケーションを管理できるように、「Emperorモード」で実行するように指示します。 systemdがプロセスを正しく管理するために必要な部分も追加します。これらは、uWSGIドキュメントhttp://uwsgi-docs.readthedocs.io/en/latest/Systemd.html [こちら]から取得されます。

/etc/systemd/system/uwsgi.service

[Unit]
Description=uWSGI Emperor service

[Service]
ExecStartPre=/bin/bash -c 'mkdir -p /run/uwsgi; chown :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 :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/

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

/ etc / nginx / sites-available / firstsite

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

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

/ etc / nginx / sites-available / firstsite

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

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

次に、すべての追加クエリをアプリケーションに直接渡すcatch-all locationブロックを作成できます。 `+ / etc / nginx / uwsgi_params `にある ` uwsgi +`パラメーターを含め、uWSGIサーバーが設定するソケットにトラフィックを渡します。

/ etc / nginx / sites-available / firstsite

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

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

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

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

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

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

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

sudo nano /etc/nginx/sites-available/

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

/ etc / nginx / sites-available / secondsite

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

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

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

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

次に、両方の新しい設定ファイルをNginxの `+ sites-enabled +`ディレクトリにリンクして有効にします：

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

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

sudo nginx -t

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

sudo systemctl restart nginx

以前のことを覚えていれば、実際にuWSGIサーバーを起動したことはありません。次のように入力して、これを実行します。

sudo systemctl start uwsgi

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

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

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

これがうまくいく場合は、次のように入力して、ブート時に両方のサービスを自動的に開始できるようにします。

sudo systemctl enable nginx
sudo systemctl enable uwsgi

Note

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

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

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：/run/uwsgi/firstsite.sockへのconnect（）の失敗（2：そのようなファイルまたはディレクトリはありません）*

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

次のように入力して、 `+ / run / uwsgi +`ディレクトリ内のソケットファイルの存在を確認します。

sudo ls /run/uwsgi

`+ / run / uwsgi `にソケットファイルがない場合は、通常、 ` uwsgi `プロセスがソケットファイルを作成できなかったことを意味します。 ` uwsgi +`プロセスのステータスをチェックして、開始できたかどうかを確認します。

sudo systemctl status uwsgi

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

sudo journalctl -u uwsgi

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

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

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

sudo systemctl daemon-reload
sudo systemctl restart uwsgi

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

unix：/run/uwsgi/firstsite.sockへのconnect（）が失敗しました（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

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

上記の例では、ソケットファイルに至る各ディレクトリには、読み取りと実行の権限があります（ディレクトリの権限列は、「+ --- 」ではなく「 r-x 」で終わります）。 ` www-data`グループには、ソケット自体のグループ所有権があります。これらの設定により、Nginxプロセスはソケットに正常にアクセスできるはずです。

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

ディレクトリパスがパーミッションや所有権を制限しすぎている場合は、 `+ / etc / systemd / system / uwsgi.service `ファイルを見てください。 ` ExecStartPre `ディレクティブは、 ` / run / uwsgi `ディレクトリを作成し、グループの所有権を ` www-data +`グループに割り当てる役割を果たします。ここのコマンドが正しくない場合、ディレクトリパスの制限が厳しすぎる可能性があります。

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

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

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

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

「+ sudo journalctl -u nginx + `」と入力して、Nginxプロセスログを確認します。
「+ sudo less / var / log / nginx / access.log + `」と入力して、Nginxのアクセスログを確認します。
「+ sudo less / var / log / nginx / error.log + `」と入力して、Nginxエラーログを確認します。
「+ sudo journalctl -u uwsgi + `」と入力して、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は、多くの共通部分を提供することでプロジェクトとアプリケーションの作成を簡単にし、独自の要素に集中できるようにします。この記事で説明した一般的なツールチェーンを活用することで、単一のサーバーから作成したアプリケーションを簡単に提供できます。

TOC

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

前書き

前提条件と目標

VirtualEnvおよびVirtualEnvWrapperのインストールと構成

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

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

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

仮想環境のバックアウト

uWSGI Application Serverのセットアップ

uWSGIのインストール

構成ファイルの作成

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

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

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

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

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

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

結論

Related