django uWSGI Nginx

一直都是用python manage.py runserver 这种Django自带的命令来开启一个服务器。有一次人家问我部署怎么办，我说用这个不行，然后被人家歧视了（我又不是运营人员，我咋知道）。

然后开始弄django+uWSGI+nginx这套！

安装环境

安装Django环境就不用说了

安装uwsgi模块，我是用tar.gz包安装的 但是不是用python setup.py install这种模式安装的，而是直接make就可以了：

tar xvzf uwsgi-2.0.9.tar.gz
cd uwsgi-2.0.9
make

3安装Nginx，可以参考http://www.cnblogs.com/hanyinglong/p/5102141.html这篇文章真的很棒！

首先描述下我解压nginx-1.10.1之后目录结构：

执行./configure (这一步骤有的需要其它参数，比如：--with-    pcre=../pcre-8.38/ --with-zlib=../zlib-1.2.8/ --with-openssl=../openssl-SNAP-20160104/ 自己选择，深度细节我没有追究)
make
make install

cd /usr/local/nginx/sbin/
./nginx -t (root权限)
./nginx
在网页上输入Nginx机器地址看到关于Nginx的描述页面就可以了

——————–分割线——————–

之前是直接用uwsgi这个模块跟Django一起的，后来又加入nginx。中间遇到很多坑，然后照着博客：http://www.cnblogs.com/fnng/p/5268633.html居然搭建成功了

先看过程

1在conf文件夹中的nginx.conf文件中修改如下：



要注意 listen 9998 意思是指：浏览器访问这个端口，请求先到达9998这个端口，

include uwsgi_params;

uwsgi_pass 10.20.23.185:8000;

以上两句是添加的，这两句就是Nginx和uwsgi有关联的。

然后启动./sbin/nginx -c ./conf/nginx.conf命令就代表启动nginx了

在uwsgi中，uwsgi.ini文件中配置如下：



要注意socket的这个端口号是跟nginx.conf中的uwsgi_pass 中的端口是一致的！然后启动uwsgi –ini uwsgi.ini命令就可以了。

在浏览器中输入9998的端口请求地址。就可以有数据反馈了！

——————-分割线———————-

最近突然有个需求，我的Nginx，项目a，项目b都是在同一台机器上c上面的。我以为能实现a,b使用同一端口就可以了。后来发现不行。

然后就让项目a 使用9999端口，项目b使用9998端口让Nginx监听，然后Nginx把请求又相应的分配给a项目的8000 uwsgi端口和b项目的8001uwsgi端口。这样就可以实现了一台机器两个服务都使用Nginx和uwsgi

下面是Nginx的配置:





至于两个uwsgi_ini的配置文件那就不晒了

—————分割线—————–

后来，我又加了一个Django项目，但是项目里面会有前端页面。

这个时候，我在uwsgi上（这里不知道配置是不是多余的）配置static 还有Nginx上也要配置static。

配好了发现，报403错误，是js和css都是403，目录都已经设置为：

chmod -R 777 .

后来查资料发现：

文件夹的权限确实是有的,拥有者是root；那么就认为是nginx权限没有访问权限，因此我想到了在nginx.conf中有个user的配置，主要是指定执行nginx的worker process的用户，linux里所有程序都是文件，都具有权限问题，这个指定的用户对特定的文件有没有权限访问或执行，就是这个用户的意义。
再了解一下 Nginx的用户管理 ：
（1） Nginx在以Linux service脚本启动时，通过start-stop-domain启动，会以root权限运行daemon进程。
（2） 然后daemon进程读取/etc/nginx/nginx.conf文件中的user配置选项，默认这里的user=nginx，也就是用nginx用户启动worker process。403错误就是因为nginx用户没有权限访问我当前开发用的用户目录。

以上是网上的介绍。最终解决答案了！

—————分割线———————

今天碰到一个非常奇葩的问题：明明改变了Django工程的代码，发现服务没反应！甚至我都删掉Django工程代码，居然还能展现页面和数据！卧槽！！！！！

第一反应，缓存！判处了浏览器缓存后，发现是服务器上有缓存。

接着使用uwsg -i uwsgi.ini命令（我以为是重启命令），甚至是Nginx重启，依然没有解决！百度各种Nginx的缓存，都解决不了这个问题！后来就把Nginx给重装了（因为之前安装的时候，忽略掉了pcre,zlib,openssl这几个东西），然后也老老实实安装这三个东西。然后发现依然没有解决！这个时候就锁定是uwsgi这里有缓存！

然后发现uwsgi.pid中进程与实际中的进程不一致！后来发现直接kill 掉进程然后重启uwsgi才解决这个问题！