我有一个通过Gunicorn运行的WSGI Python应用程序：
CONFIG = { 'bind': "unix:{}".format(os.path.join(RUN_DIR, "brain.sock")), 'preload_app': False, # supervisord requires that the child process runs in foreground 'daemon': False, ... } 它通过Nginx的套接字文件接收HTTP请求：
server { ... location / { proxy_pass http://unix:$root/run/brain.sock:; ... }
Gunicorn通过Supervisord运行：
[program:myapp] command = venv/bin/gunicorn -c gunicorn.conf.py myapp.wsgi:application ...
我正在考虑一种无需停机和等待时间来部署我的应用程序的方法。 每个工作人员最多可能需要30秒才能填满caching。
我的想法是这样部署的：
用新的代码启动第二个Gunicorn，它将监听另一个套接字文件。
等到应用程序开始，所有的caching被填满。
重命名套接字文件以指向Nginx使用的位置。 Nginx仍然会将请求发送到旧套接字。
用旧的应用程序版本closures老Gunicorn。 Nginx将会看到socket被closures，并且会从同一个地方重新打开一个新的socket。
这会工作吗？
我是否重新发明了轮子？
那是蓝绿色的部署模式 。
而不是重命名套接字（步骤3），你可以有两个nginxconfiguration（站点文件或服务器指令具有不同的名称），蓝色和绿色，指向每个gunicorn实例。 然后，当你想部署时，启用一个，禁用另一个。 最后nginx重新加载将优雅地处理所有活动的连接。
这是一个例子 。
你可能想看看uwsgi，而不是gunicorn
旨在为构build托pipe服务开发一个完整的堆栈。
应用程序服务器（用于各种编程语言和协议），代理服务器，进程pipe理器和监视器都是使用通用api和通用configuration风格实现的。
由于其可插拔的架构，它可以扩展到支持更多的平台和语言。
目前，你可以用C，C ++和Objective-C编写插件。
名称中的“WSGI”部分是对同名Python标准的致敬，因为它是第一个为该项目开发的插件。
多function性，性能，低资源使用和可靠性是项目的优势（也是唯一遵循的规则）。
其中一个function是优雅的重新加载 。