前書き

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

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

前提条件と目標

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

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

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

始めましょう。

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

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

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

  • 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`をグローバルにインストールできます。

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

sudo pip install virtualenv virtualenvwrapper
  • Python 3 *を使用している場合は、次を入力します。

sudo 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

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

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

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

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

〜/ firstsite / firstsite / settings.py

. . .
STATIC_URL = '/static/'

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

./manage.py collectstatic

「yes」と入力してアクションを確認し、静的コンテンツを収集できます。 プロジェクトディレクトリに「+ static +」という新しいディレクトリが作成されます。

ポート8080で実行されるDjango開発サーバーへのトラフィックを許可するには、ファイアウォールの設定を調整する必要があります。

`+ ufw +`ファイアウォールを実行している場合、次を入力してポート8080へのトラフィックを許可できます。

sudo ufw allow 8080

代わりに `+ iptables +`を実行している場合、必要な正確なコマンドは現在のファイアウォール設定によって異なります。 https://www.digitalocean.com/community/tutorials/how-to-set-up-a-firewall-using-iptables-on-ubuntu-14-04 [ほとんどの構成]の場合、このコマンドは機能するはずです。

sudo iptables -I INPUT -p tcp --dport 8080 -j ACCEPT

これらすべてが邪魔にならないので、開発サーバーを一時的に起動してプロジェクトをテストできます。 開発サーバーを起動するには、次のように入力します。

./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番目のプロジェクトを作成し、プロジェクトディレクトリに移動します。

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開発ファイルが必要です。 これをDebianのリポジトリから直接インストールできます。

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

sudo apt-get install python-dev
  • Python 3 *を使用している場合は、次を入力します。

sudo apt-get install python3-dev

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

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

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

sudo pip3 install uwsgi

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

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

ここでは、uWSGIに、 `〜/ Env +`ディレクトリにある仮想環境を使用し、プロジェクトのディレクトリに変更し、内部の `+`ディレクトリに保存されている `+ wsgi.py `ファイルを使用するように指示しました。ファイルを提供します。 デモンストレーションのために、ポート ` 8080 `でHTTPを提供するように指示しました。 ブラウザでサーバーのドメイン名またはIPアドレスに移動してから「:8080+」を入力すると、サイトが再び表示されます(CSSなどの「+ / admin +」インターフェイスの静的要素はまだ機能しません) )。 この機能のテストが終了したら、ターミナルでCTRL-Cを入力します。

構成ファイルの作成

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

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

sudo mkdir -p /etc/uwsgi/sites
cd /etc/uwsgi/sites

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

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

sudo nano .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プロジェクトを処理するために必要な設定ファイルは用意されましたが、プロセスはまだ自動化されていません。 次に、systemdユニットファイルを作成して、ブート時に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 `実行可能ファイルを指します。 「 / 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をリバースプロキシとしてインストールして構成できます。 これは、Debianのデフォルトリポジトリからダウンロードできます。

sudo apt-get install nginx

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

sudo nano /etc/nginx/sites-available/

内部では、最初のプロジェクトにアクセスできるポート番号とドメイン名を指定することにより、サーバーブロックを開始できます。 それぞれにドメイン名があると仮定します:

/ 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 +」を変更する必要があります。 終了すると、次のようになります。

/ 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: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

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

sudo systemctl restart nginx

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

sudo systemctl start uwsgi

ファイアウォールを再度調整する必要があります。 Nginxを介してプロキシしているため、ポート8080を開く必要がなくなり、そのルールを削除できます。 次に、Nginxプロセスへのトラフィックを許可する例外を追加できます。

`+ ufw +`を使用している場合、次のように入力してこれを行うことができます。

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

`+ iptables +`を使用している場合、適切なコマンドは次のようになります。

sudo iptables -D INPUT -p tcp --dport 8080 -j ACCEPT
sudo iptables -I INPUT -p tcp --dport 80 -j ACCEPT

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

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

sudo systemctl enable nginx
sudo systemctl enable uwsgi

Note

結論

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

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