上一篇文章有些同学感觉不够详细理解起来有些困难，我再来简单解释一下。
我们在开发的情况下：
浏览器请求→ python manage.py runserver(比如8000） → 到应用代码（Django，Flask等等）
部署到线上的情况：
域名请求→ DNS解析→ 服务器IP→ Nginx(80端口）→ 代理转发 127.0.0.1：8000（IP不一定是127.0.0.1）→ 到项目应用代码逻辑。
在整个部署过程中，我们加了一层docker来进行隔离部署，不仅解决了开发（dev）测试（test）线上（prod）多个环境不一致的问题，也达到了一次封装，处处运行的目的，我们日常使用virtualenv进行Python包环境隔离都不需要了，这在多人开发模式下面非常方便。
我其实在docker入门篇Docker 容器化部署实践--入门已经讲过了。至于新手的话如果觉得一开始觉得不太容易上手，可以考虑去掉docker这个中间环节，直接把服务跑在Linux机器上面。
解释完上面，接下来进入我们今天的主题：
Django + Nginx + Gunicorn 部署
Gunicorn
Gunicorn，是「Green Unicorn」，最初来于Ruby社区的Unicorn，是用于Unix的Python WSGI HTTP服务器，Gunicorn与各种Web框架广泛兼容，简单轻便。
我们之所以使用使用uWSGI或Gunicorn原因就是Flask，Django自带的WSGI服务性能不够好，一般用在测试开发环境用，线上主要使用更为高性能的WSGI服务。
作为介绍我这里引用一个官方例子：
$ pip install gunicorn $ cat myapp.py def app(environ, start_response): data = b"Hello, World!\n" start_response("200 OK", [ ("Content-Type", "text/plain"), ("Content-Length", str(len(data))) ]) return iter([data]) $ gunicorn -w 4 myapp:app [2014-09-10 10:22:28 +0000] [30869] [INFO] Listening at: http://127.0.0.1:8000 (30869) [2014-09-10 10:22:28 +0000] [30869] [INFO] Using worker: sync [2014-09-10 10:22:28 +0000] [30874] [INFO] Booting worker with pid: 30874 [2014-09-10 10:22:28 +0000] [30875] [INFO] Booting worker with pid: 30875 [2014-09-10 10:22:28 +0000] [30876] [INFO] Booting worker with pid: 30876 [2014-09-10 10:22:28 +0000] [30877] [INFO] Booting worker with pid: 30877
装好gunicorn之后，我们可以通过gunicorn -h 进行查看配置，通常情况下为了方便，我们都是把gunicorn放在配置文件中。
这里提一点，gunicorn中有一个--statsd-host 这个使得可以用另外一种方式来跟踪请求，我之前在监控一文说到过statsd，大家可以参看我之前写的博客「使用Statsd+Graphite+Grafana搭建web监控系统」，点击阅读原文。
同uWSGI一样我给一个简单的supervisor例子：
# gunicorn.conf.py import multiprocessing import socket bind = '0.0.0.0:9527' workers = multiprocessing.cpu_count() * 2 + 1 worker_class = 'gevent' # 搭配gevent运行 daemon = False proc_name = 'yourproject' pidfile = '/data/run/gunicorn.pid' loglevel = 'error' accesslog = '/data/yourproject/supervisor/gunicorn.access.log' errorlog = '/data/yourproject/supervisor/gunicorn.error.log' max_requests = 200000 # StatsD integration # StatsD host is omitted here, please append `--statsd-host` to gunicorn # statsd_host = 'localhost:8125' statsd_prefix = socket.gethostname()
上面说下为什么worker数目是CPU核数*2+1，这个没有太多科学依据，主要是根据一个work进行读写操作，另一个work处理请求，具体可以根据自己情况进行配置。更多特殊配置，大家可以进行自行查阅文档。
supervisor & nginx & docker-compose
supervisor同上篇文章使用Docker容器化部署实践之Django应用部署(一）一样，唯一变化的就是我们command从uUWSGI变为了gunicorn，这里我就不多列出来supervisor完整配置了。
[program:gunicorn] command=/path/to/gunicorn main:application -c /path/to/gunicorn.conf.py directory=/path/to/project user=nobody autostart=true autorestart=true redirect_stderr=true
Nginx同上篇文章一样，我这里列一个简单的样例:
server { listen 80; server_name example.org; access_log /var/log/nginx/example.log; location / { proxy_pass http://127.0.0.1:8000; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }
docker-compose配置同之前文章一样，内容较多，就不列出来了。可以参考上篇文章使用Docker容器化部署实践之Django应用部署(一）的配置。
说到最后
今天我们主要阐述了Django部署使用的第二种方式，实际上这个过程和没有docker几乎差不多的，你可以剥离掉docker，对你整个过程没有太大影响。
同样的我整个部署过程阐述的过程比较简单，实际情况会多少有些出入，不知道你听懂了么？欢迎大家给我留言，我们一起讨论。
Docker容器化部署相关我们下一篇我们聊聊Kubernets这个大杀器。
