Ubuntu16.04でuWSGIとNginxを使用してDjangoアプリケーションを提供する方法
序章
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プロジェクトをビルドしている場合は、次のように入力します。
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 firstsite
これにより、仮想環境が作成され、その中にPythonとpip
がインストールされ、環境がアクティブ化されます。 プロンプトが変わり、新しい仮想環境内で操作していることを示します。 (firstsite)user@hostname:~$
のようになります。 括弧内の値は、仮想環境の名前です。 pip
を介してインストールされたソフトウェアはすべて、グローバルシステムではなく、仮想環境にインストールされるようになります。 これにより、プロジェクトごとにパッケージを分離できます。
最初のステップは、Django自体をインストールすることです。 これは仮想環境にローカルにインストールするため、sudo
なしでpip
を使用できます。
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がこれらを直接提供できるようになり、パフォーマンスにプラスの影響があります。 これらをプロジェクトのベースディレクトリのstatic
というディレクトリに配置するようにDjangoに指示します。 この動作を構成するには、ファイルの最後に次の行を追加します。
〜/ 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
次のようなページが表示されます。
ブラウザのアドレスバーのURLの末尾に/admin
を追加すると、管理者ログインページに移動します。
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
開発ファイルが利用可能になったので、pip
を介してuWSGIをグローバルにインストールできます。
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
ここでは、~/Env
ディレクトリにある仮想環境を使用し、プロジェクトのディレクトリに移動し、内部のfirstsite
内に保存されているwsgi.py
ファイルを使用するようにuWSGIに指示しました。 ]ファイルを提供するディレクトリ(firstsite.wsgi
Pythonモジュール構文を使用)。 デモンストレーションでは、ポート8080
でHTTPを提供するように指示しました。
ブラウザでサーバーのドメイン名またはIPアドレスに移動し、続いて:8080
に移動すると、サイトが再び表示されます(CSSなどの/admin
インターフェイスの静的要素は機能しません)まだ)。 この機能のテストが終了したら、ターミナルにCTRL-Cと入力します。
構成ファイルの作成
コマンドラインからuWSGIを実行することはテストには役立ちますが、実際の展開には特に役立ちません。 代わりに、uWSGIを「エンペラーモード」で実行します。これにより、マスタープロセスは、一連の構成ファイルを指定して、個別のアプリケーションを自動的に管理できます。
構成ファイルを保持するディレクトリを作成します。 これはグローバルプロセスであるため、構成ファイルを保存するために/etc/uwsgi/sites
というディレクトリを作成します。
sudo mkdir -p /etc/uwsgi/sites
このディレクトリに、構成ファイルを配置します。 提供しているプロジェクトごとに構成ファイルが必要です。 uWSGIプロセスはさまざまな形式の構成ファイルを受け取ることができますが、単純さのために.ini
ファイルを使用します。
最初のプロジェクトのファイルを作成し、テキストエディタで開きます。
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番目の構成ファイルのベースとして使用します。
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
グループをグループ所有者として所有していることが確認されます。 -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のデフォルトのリポジトリからダウンロードできます。
sudo apt-get install nginx
Nginxをインストールしたら、プロジェクトごとにサーバーブロック構成ファイルを作成できます。 サーバーブロック構成ファイルを作成して、最初のプロジェクトから開始します。
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構成ファイルの基礎として使用します。 今すぐコピーしてください:
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
ポート8080
へのUFWルールを削除し、代わりに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がアプリケーションにプロキシする代わりにデフォルトのページを表示する場合は、通常、サーバーの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エラーログを追跡します。
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]ソケットファイル。
次のように入力して、/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がソケットファイルを正しく検出できるようになります。
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
で終わります)。 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は、多くの一般的な要素を提供することでプロジェクトとアプリケーションの作成を簡単にし、独自の要素に集中できるようにします。 この記事で説明する一般的なツールチェーンを活用することで、単一のサーバーから作成したアプリケーションを簡単に提供できます。