从零开始自动部署Django项目（三）：使用uWSGI emperor管理进程

引言

在上一篇从零开始自动部署Django项目（二）：使用Python编写Git Hooks，笔者直接通过Python模拟正常的人肉linux命令来确定python debug server是否在指定端口运行，如果正在运行则先杀掉该进程，在更新了Git仓库之后再人肉启动python debug server。

咦，好像有哪里不对，为什么不直接删掉文件，然后进程不就自动结束了吗？这样子就不用检查端口是否有进程在运行了。

相信大家都试过，在linux下如果先开启python debug server进程，然后把进程的相关文件都删掉，而进程还能正常运行。这是因为linux下的删除（rm）其实是减少对文件的link数目，虽然删除了文件，但是打开的进程还保持着对文件的一个link，因此在执行了rm之后文件并不会被立即删除，只有link数为0的时候才会被删除。

因此，笔者希望在服务器上运行一个进程管理工具监控Git仓库，每当仓库更新的时候，进程管理工具就自动重启python debug server，而Git Hooks只要负责仓库的更新就可以了。

在Python的进程管理工具中，supervisor应该是比较广为人知，而uWSGI emperor的曝光度似乎并不太高，然而基于nginx＋uwsgi＋django的标配，笔者还是对uWSGI emperor的折腾比较期待的。
uWSGI文档传送门：Quickstart for Python/WSGI applications

准备

• uWSGI与uwsgi是同一样东西吗？它们有什么区别？

  先给出结论：uWSGI是一个生产用服务器，而uwsgi是一种网络通信协议（在uWSGI文档中也承认了这个名字的选择真的是wrong name choice）。
  Django为开发者提供了一个开发调试用的服务器，只要通过python manage.py runserver就可以在默认的运行端口8000提供服务，但是这个服务器不能在生产环境中使用，需要更为稳定的服务器提供服务，而uWSGI也是Django官方文档中推荐使用的生产服务器。
  至于uwsgi协议则多用于与反向代理服务器的内部信息通信，nginx支持对uwsgi协议的解析，而为什么使用uwsgi协议而不是在内部继续使用http协议进行通信，uWSGI的文档给出以下解释：

  Why not simply use HTTP as the protocol?
  A good question with a simple answer: HTTP parsing is slow, really slow. Why should we do a complex task twice? The web server has already parsed the request! The uwsgi protocol is very simple to parse for a machine, while HTTP is very easy to parse for a human. As soon as humans are being used as servers, we will abandon the uwsgi protocol in favor of the HTTP protocol. All this said, you can use uWSGI via Native HTTP support, FastCGI, ZeroMQ and other protocols as well.

  uWSGI文档传送门：Frequently Asked Questions (FAQ)

• 折腾环境选择
  笔者开发使用的mac系统：

  uname -a
  Darwin bogon 15.6.0 Darwin Kernel Version 15.6.0: Thu Jun