序章

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

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

前提条件と目標

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

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

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

始めましょう。

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

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

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

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

  1. sudo apt-get update

  2. sudo apt-get install python-pip

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

  1. sudo apt-get update

  2. sudo apt-get install python3-pip

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

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

  1. sudo -H pip install --upgrade pip

  2. sudo -H pip install virtualenv virtualenvwrapper

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

  1. sudo -H pip3 install --upgrade pip

  2. sudo -H pip3 install virtualenv virtualenvwrapper

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

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

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

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

  1. echo "export WORKON_HOME=~/Env" >> ~/.bashrc

  2. echo "source /usr/local/bin/virtualenvwrapper.sh" >> ~/.bashrc

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

  1. source ~/.bashrc

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

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

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

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

virtualenvwrapperスクリプトで使用できるコマンドを使用すると、仮想環境を簡単に作成できます。

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

  1. mkvirtualenv firstsite

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

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

  1. pip install django

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

  1. cd ~

  2. django-admin.py startproject firstsite

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

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

  1. cd ~/firstsite

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

  1. ~/firstsite/manage.py migrate

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

  1. ~/firstsite/manage.py createsuperuser

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

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

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

  1. 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がこれらを直接提供できるようになり、パフォーマンスにプラスの影響があります。 これらをプロジェクトのベースディレクトリのstaticというディレクトリに配置するようにDjangoに指示します。 この動作を構成するには、ファイルの最後に次の行を追加します。

〜/ firstsite / firstsite / settings.py
. . .
STATIC_URL = '/static/'
STATIC_ROOT = os.path.join(BASE_DIR, 'static/')

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

  1. ~/firstsite/manage.py collectstatic

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

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

  1. sudo ufw allow 8080

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

  1. ~/firstsite/manage.py runserver 0.0.0.0:8080

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

http://server_domain_or_IP:8080

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

Django sample site

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

Django admin login

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

Django admin interface

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

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

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

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

  1. cd ~

  2. mkvirtualenv secondsite

  3. pip install django

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

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

  1. cd ~

  2. django-admin.py startproject secondsite

  3. cd ~/secondsite

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

  1. ~/secondsite/manage.py migrate

  2. ~/secondsite/manage.py createsuperuser

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

  1. 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/')

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

  1. ~/secondsite/manage.py collectstatic

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

  1. ~/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番目の仮想環境を非アクティブ化できます。

  1. deactivate

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

  1. workon firstsite

または：

  1. workon secondsite

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

  1. deactivate

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

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

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

uWSGIのインストール

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

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

  1. sudo apt-get install python-dev

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

  1. sudo apt-get install python3-dev

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

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

  1. sudo -H pip install uwsgi

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

  1. sudo -H pip3 install uwsgi

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

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

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

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

構成ファイルの作成

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

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

  1. sudo mkdir -p /etc/uwsgi/sites

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

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

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

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

また、ユーザーのホームディレクトリへのパスを含む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番目の構成ファイルのベースとして使用します。

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

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

  1. 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と呼びます。

  1. 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実行可能ファイルを指します。 「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のデフォルトのリポジトリからダウンロードできます。

  1. sudo apt-get install nginx

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

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

内部では、最初のプロジェクトにアクセスできるポート番号とドメイン名を指定することで、サーバーブロックを開始できます。 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;
    }
}

次に、すべての追加クエリをアプリケーションに直接渡すキャッチオールロケーションブロックを作成できます。 /etc/nginx/uwsgi_paramsにあるuwsgiパラメータを含め、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構成ファイルの基礎として使用します。 今すぐコピーしてください：

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

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

  1. 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ディレクトリにリンクして、次の機能を有効にします。

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

  2. sudo ln -s /etc/nginx/sites-available/secondsite /etc/nginx/sites-enabled

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

  1. sudo nginx -t

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

  1. sudo systemctl restart nginx

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

  1. sudo systemctl start uwsgi

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

  1. sudo ufw delete allow 8080

  2. sudo ufw allow 'Nginx Full'

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

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

  1. sudo systemctl enable nginx

  2. sudo systemctl enable uwsgi

ノート

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

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

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

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

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

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

Nginxがアプリケーションにプロキシする代わりにデフォルトのページを表示する場合は、通常、サーバーのIPアドレスまたはドメイン名を指すように/etc/nginx/sites-available/firstsiteファイル内の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（）からunix：/run/uwsgi/firstsite.sockに失敗しました（2：そのようなファイルまたはディレクトリはありません）

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