uWSGI + Nginx + Django構成の概要（UbuntuとCentosの両方が利用可能）

環境：Centos7.5またはUbuntu16.04.6。構成で問題が発生した場合は、メッセージを残してください。ブログで問題を自由に変更してください。修正してください。nginx用にポート80を開き、uwsgi用にポート8000​​を開きました。
フレーム：Django
説明：特に大物のブログのおかげで、コンテンツの一部が複製されています：https：//blog.csdn.net/u012145252/article/details/82147440この記事はそれ自体に基づいたほんの数レコードです学習と使用の実際の状況。

正式将之前先说一下大概步骤，我们先将uwsgi与django服务配置好，再将nginx与uwsgi服务之间的联系给配置好，如果你在看这篇文章之前对于这三者的关系不太清楚的话也不要紧，耐心的看完你就明白了，现在开始之前，你只需要了解他们三者的这个配置顺序就行了。配置顺序不是固定的，本文以这种顺序进行配置，主要是为了方便调试与理解，现在我们开始！

1つは、uWSGIの展開

まず、uwsgiを自分のサーバーにインストールする必要があります。仮想環境で使用する場合は、仮想環境にインストールします。サーバーに直接構成する場合は、次のように直接インストールします。

pip3 install uwsgi

インストールが完了したら、uwsgi--versionを使用してバージョン情報を表示できます。

uWSGIのテスト実行

まず、巨大なWebサイトのソースコードを直接使用して構成しないように、テストに合格するためのテストコードが必要です。

プロジェクトのルートディレクトリtest-uwsgi.pyに作成します。コードは次のとおりapplicationです。これは、uwsgiサービスがデフォルトでDajngoに通知するインターフェイスであるため、関数名はである必要があることに注意してください。wsgi.pyまた、私たちがよく使用するDjangoフレームワークの構成ファイルにも表示されます。

def application(env,start_response):
    start_response('200 OK',[('Content-Type','text/html')])
    return [b"Hello Hero, all for one "]

次のコマンドは、uwsgiサービスを実行し、ポート8000​​でWebアクセスを開くことを意味します。

• 注– httpの後にスペースが続き、その後にポート番号が続きます。

uwsgi --http :8000 --wsgi-file test-uwsgi.py

Webサーバーのポート8000​​にアクセスし、test-uwsgi.pyスクリプトで返されたテキストを通常どおり表示します。

これから行うのは、nginxとuwsgiに基づいてDjangoをデプロイすることであるため、クライアントがリクエストを開始し、サーバーがリクエストに応答するため、いくつかのリンクがあります。

the web client <-> the web server(nginx) <-> the socket <-> uwsgi <-> Django

uWSGIが個別にテストされ、アクセス表示が正常である場合、次の3つのリンクがスムーズであることを意味します。

the web client <-> uWSGI <-> Python

ctrl + cでプログラムを停止し、次のテストを実行します。

uWSGIでdjangoプロジェクトを実行する

仮想環境で、djangoルートディレクトリに入り、次のコマンドを入力します。

 uwsgi --http :8000 --module projectname.wsgi

効果と直接次のコマンドを打つ

python manage.py runserver 0.0.0.0:8000

それは同じだ。

注：上記projectname.wsgiは、プロジェクトのルートフォルダーの下にあるwsgi.pyゲートウェイサービス構成ファイルを呼び出すためのものです。デフォルトでは、ユーザーはそれを変更する必要はありません。Djangoプロジェクトのフォルダーパスに震えることはありません。学習した後でわかります。確認することでわかります。したがって、コマンドはプロジェクトのルートディレクトリで実行する必要があります。

注：–module projectname.wsgiは、指定されたwsgiモジュールをロードするためのものです。プロジェクトの名前は何ですか。通常はプロジェクト名.wsgiです。
このテストの後、uWSGIからDjangoへのWebクライアントがスムーズであることが証明できます。

the web client <-> uWSGI <-> Django

ctrl + cを押してプログラムを停止し、次のテストを実行します

uWSGiホットローディングDjangoaプロジェクト

開始コマンドの後にパラメーターを追加します。

uwsgi --http :8000 --module pojectname.wsgi --py-autoreload=1

同様に、この時点でサーバーのポート8000​​にアクセスするということは、djangoプロジェクト（pojectname）にアクセスすることを意味します。

そしてもう1つのパラメータがあります：
--py-autoreloadリロードをトリガーするためにPythonモジュールを監視します（開発でのみ使用されます）

同様の発行コマンド

/..dir../uwsgi --http 0.0.0.0 :8000 --chdir /home/operation/work/luffy --module luffy.wsgi` 
 #此时修改django代码，uWSGI会自动加载django程序，页面生效 # 除此外，还可以接上很多参数

uwsgiデプロイメントの機能強化

1つは、uwsgi構成ファイルを使用してdjangoプロジェクトを実行する

上記の構成はテストフェーズに属します。テスト後に問題がなければ、システムを構成できます。uwsgiは、ini、xml、およびその他の構成方法をサポートしています。例としてiniを取り上げ、プロジェクトのルートディレクトリに新しいuwsgi.iniを作成します。構成例は次のとおりです。

[uwsgi] #代表这里是uwsgi的配置文件，必须要写这个在第一行

# 指定运行目录，其实就是项目的根目录
# 导入django项目的wsgi模块，我的项目叫GradingSystem,其中application就是默认的网关配置文件的那个函数
module = GradingSystem.wsgi:application
dir=/web/GradingSystem
# 载入wsgi-file，这里是指明网关配置文件在项目文件夹下的路径
wsgi-file = GradingSystem/wsgi.py

# 补充，uwsgi启动时的用户和用户组,注意要按你自己的实际权限进行配置
# 我这边是因为项目属主是gxa，而gxa我设置了添加进了gxa组
# 但这种情况下uid仍不能设置gxa，除非你的项目目录所有文件属主都改为了gxa
uid = centos
gid = www

# 开启master主进程
master = true

# 开启多少个进程数，workers项也等同processes
# threads项则是设置运行线程，测试倒不用设置上线程
processes = 10

# 设置使用的socket端口或socket地址
# socket = 0.0.0.0:8000
# 上面的socket建议配置成一个GradingSystem.socket文件后使用nginx来连接uWSGI运行,不然容易报socket的请求头错误和权限错误等。
#socket = /web/GradingSystem/GradingSystem.socket

#以上信息来源于转载，是大佬博主的建议，但是我采用之后出现了网关错误的问题，可能是我哪里没有搞明白，但是换成下面的配置后就正常了，这个socket指定的端口代表的是uwsgi服务监听的端口

# 在配置uwsgi时，如果直接使用socket进行配置，那么浏览器无法通过http协议进行访问，必须在前面加上nginx转发才可以通过nginx间接访问，因此只测试uwsgi时使用http进行配置。
#socket = 0.0.0.0:8000
http = 0.0.0.0:8000

# 配置生成的sock文件的权限，一般对网站用户的权限都设置为如此，较为安全
chmod-socket = 664

# 退出时清空环境，其实就是将自动生成的GradingSyster.sock和相关pid文件给干掉。
vacuum = true

#设置uwsgi服务的缓存区大小
auffer-size = 65536

uwsgiは、djangoプロジェクトを開始するための構成ファイルを指定します。実行するには、Webで指定されたユーザーを使用することをお勧めします。

uwsgi --ini /..dir../uwsgi.ini

（ここで... dir ...はサーバー上のプロジェクトのパスです）

第二に、ウェブサイトのユーザーグループを構成する問題

まず、ルートディレクトリのアクセス許可設定の必要性：
Webサイトサーバーのセキュリティと運用のために、特定のユーザーとユーザーグループを使用する必要があります。従来の慣例に従って、wwwユーザーグループの下でwwwユーザーを使用することを選択します。ウェブサイトを実行するにはサーバーは、nginxであろうとapacheであろうと、これを行うことができます。

wwwユーザーが実行するサーバーは、phpスクリプトなどの動的スクリプトや、html、css、javaScriptなどのファイルなど、Webサイトのルートディレクトリにあるさまざまなリソースを読み取る必要があります。もちろん、phpスクリプトで他のユーザーに切り替えることで特別なスクリプトを実行することもできます。これは、シェルスクリプトでユーザーを切り替えるのと同じです。

さらに、新しいカスタムユーザーを作成し、新しいカスタムユーザーグループを作成し、プロジェクトファイルの所属をユーザーグループのユーザーに設定し、対応するディレクトリアクセス許可を設定することもできます。

1. WebサーバーがApacheの場合、ユーザーがWebページにアクセスすると、Apacheサービス（httpd）の所有者のIDを介してアクセスされるため、httpdサービスの所有者であるapache、およびすべてのグループは次のようになります。 apacheまたはselfに設定ユーザーを設定します。rootは使用しないでください。この一般的なインストール中にデフォルト設定が行われます（またはapache構成ファイルのユーザー項目とグループ項目を変更します）。

2. Webサイトプログラムの所有者は、apacheサービスの所有者と同じであってはなりません。これは、通常の訪問者にWebファイルを操作するすべての権利を与えることと同じである場合です。Webプログラムに抜け穴ができたら、それは
終わりです。デフォルトは通常rootです。自分でデーモンを作成するなど、他のユーザーに変更してみてください。Apacheサービスの所有者と同じにならないように注意してください。

3. Webサイトのルートディレクトリのアクセス許可については、最小アクセス許可の原則に従って、755に設定する必要があります。

4.キャッシュディレクトリまたはキャッシュディレクトリなどのアップロードディレクトリの場合：cachesディレクトリ。このディレクトリには書き込み権限が必要です。つまり、ディレクトリにはrwxの3つの権限も必要です。この時点で、
空のキャッシュを直接作成できます。ディレクトリを選択してから、daemon.daemon
./cachesを変更すると、キャッシュとすべてのグループの所有者をカスタムデーモンに変更できます。これにより、Webページにアクセスした場合、
キャッシュをapacheとして入力して、キャッシュディレクトリとファイルを作成できます。 。デフォルトでは、システムは最小限の権限で作成されます！

5.通常のディレクトリの場合、最小アクセス許可は755であり、通常のユーザーは書き込みアクセス許可を与えません

6.通常のファイルの場合、最小アクセス許可は644であり、通常のユーザーには実行アクセス許可が与えられません。
つまり、ディレクトリに書き込みアクセス許可を与えたり、ファイルに実行アクセス許可を与えたりしないでください（次のような特別な状況を除く）。アップロードするディレクトリ）

上記は、自分で構成したときにこの情報が見つからなかったため、比較的厳密なWebサイトディレクトリのアクセス許可設定です。したがって、私の権限の管理は上記のように詳細ではありませんが、操作方法は同じです。以下の操作はroot権限で実行されます

1.ユーザーグループを作成します（作成する必要はありません。同じユーザー名のデフォルトグループを使用してください）

groupadd groupname

2.ユーザーを作成し、ユーザーグループを指定します

useradd -g groupname username

または、デフォルトのユーザーグループを使用します。これは、Webサイトサービスを構成するユーザーには推奨されません。

useradd username

3.ユーザーパスワードを変更します

passwd username

4.ユーザーに特定のroot権限を付与します（特別な必要がない場合、一般的なWebサイトサービスはそれを必要としません）

visudo

最後の行に追加します。

username ALL=(root) /usr/bin/*, /usr/local/elasticsearch-2.4.4/*, !/usr/bin/passwd [A-Za-z]*

注：ALL =（root）は、suをrootユーザーにのみ切り替えることができることを意味します。ユーザーの権限はコンマで区切られます。/usr/bin/*は、基本的なコマンドを実行できることを意味します。/usr/local/elasticsearch- 2.4.4 / *は、私自身のElasticsearchのファイルパスの下にあるすべての権限です。！/ usr / bin / passwd [A-Za-z] *は、自分以外のすべてのユーザーのパスワードを変更できないことを意味します。

5. Webサイトのプロジェクトルートディレクトリの所有者を新しいユーザーに割り当て
ます。httpサーバーを実行しているユーザーとユーザーグループはwww、Webサイトユーザーはcentos、Webサイトルートディレクトリは/ home / centos /であると想定しています。ウェブ。
方法/ステップ：

1
最初に、Webサイトのディレクトリとファイルの所有者とすべてのグループをcentos、www、および次のコマンドに設定します。
chown -R centos:www /home/centos/web

2
Webサイトのディレクトリ権限を750に設定します。750は、centosユーザーがディレクトリの読み取り、書き込み、および実行の権限を持っていることを意味します。これにより、centosユーザーは任意のディレクトリにファイルを作成でき、ユーザーグループは読み取りおよび実行の権限を持ちます。ディレクトリに入ることができます。他のユーザーには権限がありません。
find -type d -exec chmod 750 {} \;

3
Webサイトファイルのアクセス許可を640に設定します。640は、centosユーザーのみがWebサイトファイルを変更するアクセス許可を持っていることを意味します。httpサーバーはファイルを読み取るアクセス許可のみを持ち、ファイルを変更することはできません。他のユーザーにはアクセス許可がありません。個々のディレクトリがアクセス許可を書き込むための
find -not -type d -exec chmod 640 {} \;
4
。たとえば、Webサイトの一部のキャッシュディレクトリには、httpサービスの書き込み権限が必要です。たとえば、discuzx2の/ data /ディレクトリには書き込み権限が必要です。
find data -type d -exec chmod 770 {} \;

上記の設定後、上記のテスト環境のようにrootでサービスを開始する代わりに、指定したユーザーを使用してWebサイトのサービスを開始できます。rootでサービスを開始することは安全ではありません。

uWSGIスタートアップサービス

引き続きdjangoプロジェクトを例として取り上げ、起動時にuWSGIにサービスを開始させ、ファイルを編集して、/etc/rc.localこのコード行の前に次のコンテンツを追加しますexit 0。

/..uwsgi再系统中的路径../uwsgi --ini /..Django项目中uwsgi配置文件的路径../uwsgi_luffy.ini

ini構成ファイルでユーザーユーザーグループ、sockファイル、sock文件的权限および后台运行その他の構成を設定することを忘れないでください。

2、Nginxのデプロイ

• Nginxの役割は主に監視することです。クライアントに静的リクエストがある場合、リクエストで指定された静的ファイルがクライアントに返されます。クライアントが動的URLリクエストを送信すると、リクエストはリスニングポートからuwsgiに送られます。 serviceポートをリッスンします。リクエストを受信すると、uwsgiポートはプロジェクトフォルダーの下の各Djangoサービス（ビュー内の関数）に渡されて処理されます。処理後、uwsgiはnginxに戻り、最後にnginxはコンテンツをに返します。クライアント。
• 当然のことながら、これは3人の協力のプロセスです。したがって、このステップでの構成は、主にnginxのリスニングポートを構成することであり、動的リクエストを受信した後、どのuwsgiリスニングポートを処理に渡す必要があります。さらに、プロジェクトのルートディレクトリ、プロジェクトの静的フォルダーの静的パス、メディアフォルダーのメディアパスなど、nginx自体の静的要件フォルダーを構成する必要があります。

以下は私のプロジェクト構成です：

---

nginxはuwsgiとdjangoを構成します

• uwsgi_paramsファイルをプロジェクトフォルダにコピーします。
  uwsgi_paramsファイルは通常/etc/nginx/ディレクトリにありnginx、githubページからダウンロードすることもできます。

• uwsgi_params構成ファイルは次のとおりです。

uwsgi_param  QUERY_STRING       $query_string;
uwsgi_param  REQUEST_METHOD     $request_method;
uwsgi_param  CONTENT_TYPE       $content_type;
uwsgi_param  CONTENT_LENGTH     $content_length;

uwsgi_param  REQUEST_URI        $request_uri;
uwsgi_param  PATH_INFO          $document_uri;
uwsgi_param  DOCUMENT_ROOT      $document_root;
uwsgi_param  SERVER_PROTOCOL    $server_protocol;
uwsgi_param  REQUEST_SCHEME     $scheme;
uwsgi_param  HTTPS              $https if_not_empty;

uwsgi_param  REMOTE_ADDR        $remote_addr;
uwsgi_param  REMOTE_PORT        $remote_port;
uwsgi_param  SERVER_PORT        $server_port;
uwsgi_param  SERVER_NAME        $server_name;

• プロジェクトにコピーします。

sudo cp /etc/nginx/uwsgi_params /..项目目录../

• 所有者、グループなどの権限を再変更します。

sudo chown www:centos uwsgi_params
sudo chmod 664 /..项目所在的目录../uwsgi_params

• プロジェクトフォルダの下にファイルnginx.confを作成し、次のコンテンツを入力して変更します。

http{
    
    
	include  /etc/nginx/mime.types;
	upstream django {
    
    
    # server unix:///path/to/your/mysite/mysite.sock; 
    # 用于文件套接字
    server 127.0.0.1:8000; 
    # 用于Web端口套接字（我们将首先使用它）
	}
	# //解决web部署到ｎｇｉｎｘ后js,css等不能访问。
# 服务器配置
server {
    
    
    #您的网站将在其上服务的端口
    listen  80; #nginx的监听端口，相当于是我们提供服务的第一道墙

    # 指定提供服务的主机地址，我们将uwsgi服务于nginx服务配置再一台服务器的，因此指定本机即可
    server_name 127.0.0.1; 
    # 设置nginx传送内容的字符集格式，解决网页乱码问题
    charset utf-8;

    # 设置请求体大小；可用于解决大文件上传不了的问题
    client_max_body_size 500M;   # adjust to taste

    location / {
    
    
        uwsgi_pass  django;
        include  /web/GradingSystem/uwsgi_params; 
        # 您安装的uwsgi_params文件（这个很重要，我是将uwsgi的这个文件拷贝到了项目文件夹下面）
    }

    location /static/ {
    
    
        alias /web/GradingSystem/static/; 
        # 您的Django项目的静态文件-根据需要进行修改
    }

    # Django media
    location /media/  {
    
    
        alias /web/GradingSystem/static/media/;  
        # 您的Django项目的媒体文件-根据需要进行修改
    }

    # 最后，将所有非静态和媒体请求发送到Django服务器。
    
	}
}
events {
    
    
  worker_connections  1024;  ## Default: 1024
}

• いくつかの関連パラメーターの意味を追加します。

1.client_max_body_size
	-  限制请求体的大小，若超过所设定的大小，返回413错误。
2.client_header_timeout
	- 读取请求头的超时时间，若超过所设定的大小，返回408错误。
3.client_body_timeout
	- 读取请求实体的超时时间，若超过所设定的大小，返回413错误。
4.proxy_connect_timeout
	- http请求无法立即被容器(tomcat, netty等)处理，被放在nginx的待处理池中等待被处理。此参数为等待的最长时间，默认为60秒，官方推荐最长不要超过75秒。
5.proxy_read_timeout
	- http请求被容器(tomcat, netty等)处理后，nginx会等待处理结果，也就是容器返回的response。此参数即为服务器响应时间，默认60秒。
6.proxy_send_timeout
	- http请求被服务器处理完后，把数据传返回给Nginx的用时，默认60秒。

この構成ファイルは、サービスとしてファイルシステムからメディアファイルと静的ファイルをプル
し、同時にDjangoリクエストに応答するようにnginxに指示します。

この目的のために、対応するプロジェクトディレクトリにメディアフォルダと静的フォルダも作成しました。

nginxの実行中に構成情報を簡単に使用できるようにするには、nginx.confからnginxのデフォルトsites-enabledディレクトリへのソフトリンクを作成します。

sudo ln -s /..项目所在../nginx.conf /etc/nginx/sites-enabled/nginx.conf

このソフト接続が生成されない場合、Nginxの起動時にデフォルトで読み込まれる設定ファイルがデフォルトになります。もちろん、nginx -c /.../nginx.confコマンドを使用してnginxを起動すると、指定した設定ファイルの設定情報が読み込まれ、nginxが起動します。

---

Djangoは静的ファイルをデプロイします（プロジェクトにすでに静的ファイルがある場合は、ディレクトリパスが正しいかどうかを確認できます）

• プロジェクトフォルダの下に静的ファイルディレクトリを作成します。

mkdir static

• djangoの設定ファイルに次の行を追加します。

STATIC_ROOT = os.path.join(BASE_DIR, “static/”)

• 実行（这个必须得运行）

python manage.py collectstatic

• プロジェクトフォルダに、メディアファイルディレクトリを作成します（テスト用の写真、音楽、その他のファイルを保存するために使用されます）

mkdir media

• メディアディレクトリで、nginxをテストするために画像ファイル2333.pngを渡しました。

• パラメータSTATIC_ROOTはどこで使用されますか？STATIC_ROOTに保存
  することによりpython3 manage.py collectstatic、あなたが使用するすべての静的ファイルを収集！

• STATIC_ROOTフォルダーは、STATICFILES_DIRS内のすべてのフォルダー内のすべてのファイルと、各アプリ内の静的なファイルをコピーするために使用されます。これらのファイルは、nginxなどでの展開に便利なようにまとめられています。

テストのためにnginx構成ファイルをリロードします

• 最初に、前の構成ファイルにエラーがないかどうかを確認してください。

sudo /usr/sbin/nginx -t

• nginxをリロードして、ソフトリンクのluffy_nginx.confを有効にします。

sudo /usr/sbin/nginx -s reload

• にhttp://..ip_advers..:80/media/2333.pngアクセスして、画像リソースに正常にアクセスできるかどうかを確認してください。ここで使用するサービスポートは、nginxサービスで実行されるポートであることに注意してください。

この手順を実行する前に、ドメイン名を構成し、テスト用の画像をサーバーに送信したことに注意してください。
この手順を実行すると、多くのピットに遭遇し、多くの不可解な間違いを報告しましたが、要約すると、nginxサービスに問題がある場合は、を使用しsystemctl status nginxてサービスステータスを表示し、systemctl restart nginxコマンドを使用してnginxサービスを再起動してからテスト。

リソースに正常にアクセスできたので、次のテスト手順を実行します。

nginxアプリケーションuWSGIとtest.pyをテストします

以前に作成したテストのtest-uwsgi.pyファイルを覚えていますか？
構成されたnginxを使用して、uwsgiによって開始されたtest-uwsgi.pyにアクセスしてみましょう。
まず、uwsgiを起動します。ポートは、nginx構成の負荷分散プールの8000ポートです。

uwsgi --socket :8000 --wsgi-file test-uwsgi.py

訪問はhttp://ip:80/実際にuwsgiのポート8000​​を訪問します。

正常にアクセスできれば。次のリンクが遮られていないことを示します。

the web client <-> the web server <-> the socket <-> uWSGI <-> Python

テストが成功すると、プログラムは終了します。これまで、サーバーのuwsgi、nginx、Djangoの関係を公開しました。最後に、Nginx、WSGI、Djangoの対話を通じて、3つの関係について説明します。

Nginx：ねえ、WSGI、リクエスト（動的httpリクエスト）を受け取ったところです。準備が必要です。Flaskがリクエストを処理します。
WSGI：OK、Nginx。環境変数を設定してから、リクエストをDjangoに渡して処理します。Django：
WSGIに感謝します！しばらくお待ちください。リクエストに対する回答をお送りします。WSGI：了解しました。それでは、お待ちしております。
Django：わかりました。これがリクエストの応答結果です。リクエストは結果をNginxに渡します。WSGI：お疲れ様でした
。Nginx、これが応答結果です。これは必要に応じて返されます。Nginx：かっこいい、受け取ったので、応答結果をクライアントに返します。みなさん、よろしくお願いします〜

コメント欄にメッセージを残してください。何か間違ったことを書いたら、それを上げてください。私はそれを時間内に修正し、一緒に進歩します！