pip安装gunicorn_gunicorn部署Flask服务

作为一个Python选手，工作中需要的一些服务接口一般会用Flask来开发。

Flask非常容易上手，它自带的app.run(host="0.0.0.0", port=7001)用来调试非常方便，但是用于生产环境无论是处理高并发还是鲁棒性都有所欠缺，一般会配合WGSI容器来进行[生产环境的部署][1]。

小磊哥推荐了参考文章[1]中的部署方式，希望将已有的服务放到gunicorn或者Tornado中部署，并用supervisor来管理所有进程(有几个不同的服务)。

经过调研和尝试

gunicorn可以结合gevent来进行部署，因此在高并发场景下也可适用，于是决定采用gunicorn进行部署。

gunicorn和supervisor会有一定的冲突，即使gunicorn中没有设置为后台启动，supervisor也只会管理gunicorn的master进程；

supervisor的重启服务对于无响应的Flask进程来说并不生效，不能很好地解决我的服务由于某些原因无法正常响应但又找不到方法解决的问题，因此暂时决定不用supervisor。

环境安装

首先pip安装gunicorn。

pip install gunicorn --user

Tips. pip --user用法

由于是部署在公司云主机上，通常不会给root权限。之前都是提工单给SA sudo装的，后来发现更安全也更方便的方法是pip install xxx --user，美中不足是安装完以后需要手动添加PATH

export PATH=/home/username/.local/bin:$PATH

方便起见可以加到~/.bash_profile中

gunicorn 命令启动

简单地，gunicorn可以通过gunicorn -w 4 -b 127.0.0.1:4000 run:app启动一个Flask应用。其中,

-w 4是指预定义的工作进程数为4，

-b 127.0.0.1:4000指绑定地址和端口

run是flask的启动python文件，app则是flask应用程序实例

其中run.py中文件的可能形式是：

# run.py

from flask import Flask

app = Flask(__name__)

通过gunicorn -h可以看到gunicorn有非常多的配置项，因此通常会写成一个config.py文件来进行配置。看了一下文档似乎没有给出正确的config.py中配置项的命名，并且有些博客博主给出的配置项命名是错误的，导致配置没有生效，踩了不少的坑(我找不到那篇坑坑的文章了)。这篇博客[2]给出了一些比较常用且正确的配置。

我所用项目的配置项如下：

# config.py

import os

import gevent.monkey

gevent.monkey.patch_all()

import multiprocessing

# debug = True

loglevel = 'debug'

bind = "0.0.0.0:7001"

pidfile = "log/gunicorn.pid"

accesslog = "log/access.log"

errorlog = "log/debug.log"

daemon = True

# 启动的进程数

workers = multiprocessing.cpu_count()

worker_class = 'gevent'

x_forwarded_for_header = 'X-FORWARDED-FOR'

1. debug = True

生产环境不需要这个配置项，但调试的时候还是挺好用的。而且，开启debug项后，在启动gunicorn的时候可以看到所有可配置项的配置，如下所示。

之前在被上一篇博主欺骗的时候，仔细看了调试信息，发现accesslog和errorlog都没有被配置，所以导致启动以后看不到任何日志。

config.py中只需要配置需要修改的项的，大部分采用默认配置即可。默认配置的具体配置内容可以通过gunicorn -h来查询。

*配置文件和调试信息来自两个不同进程，因此信息可能有细微差异

# Debug Info

[2018-01-18 17:38:47 +0000] [16015] [DEBUG] Current configuration:

proxy_protocol: False

worker_connections: 1000

statsd_host: None

max_requests_jitter: 0

post_fork:

errorlog: -

enable_stdio_inheritance: False

worker_class: gunicorn.workers.ggevent.GeventWorker

ssl_version: 2

suppress_ragged_eofs: True

syslog: False

syslog_facility: user

when_ready:

pre_fork:

cert_reqs: 0

preload_app: False

keepalive: 2

accesslog: log/debug.log

group: 1001

graceful_timeout: 30

do_handshake_on_connect: False

spew: False

workers: 2

proc_name: None

sendfile: None

pidfile: log/gunicorn.pid

umask: 0

on_reload:

pre_exec:

worker_tmp_dir: None

limit_request_fields: 100

pythonpath: None

on_exit:

config: gunicorn_conf.py

logconfig: None

check_config: False

statsd_prefix:

secure_scheme_headers: {'X-FORWARDED-PROTOCOL': 'ssl', 'X-FORWARDED-PROTO': 'https', 'X-FORWARDED-SSL': 'on'}

reload_engine: auto

proxy_allow_ips: ['127.0.0.1']

pre_request:

post_request:

forwarded_allow_ips: ['127.0.0.1']

worker_int:

raw_paste_global_conf: []

threads: 1

max_requests: 0

chdir: /home/hzyangxiao2014/POPORobot/QASP

daemon: False

user: 1028

limit_request_line: 4094

access_log_format: %(h)s %(l)s %(u)s %(t)s "%(r)s" %(s)s %(b)s "%(f)s" "%(a)s"

certfile: None

on_starting:

post_worker_init:

child_exit:

worker_exit:

paste: None

default_proc_name: run:app

syslog_addr: udp://localhost:514

syslog_prefix: None

ciphers: TLSv1

worker_abort:

loglevel: debug

bind: ['0.0.0.0:7001']

raw_env: []

initgroups: False

capture_output: False

reload: False

limit_request_field_size: 8190

nworkers_changed:

timeout: 30

keyfile: None

ca_certs: None

tmp_upload_dir: None

backlog: 2048

logger_class: gunicorn.glogging.Logger

2. 日志

# config.py

accesslog = "log/access.log"

errorlog = "log/debug.log"

loglevel = "debug"

需要log目录存在。如果不存在，启动会报错

accesslog是访问日志，可以通过access_log_format设置访问日志格式。详细的方法可以见参考文章[2]

loglevel用于控制errorlog的信息级别，可以设置为debug、info、warning、error、critical。

3. workers

worker_class是指开启的每个工作进程的模式类型，默认为sync模式，也可使用gevent模式。

workers是工作进程数量，在上述config.py中，取的是CPU的数量。需要注意部署机器的性能，不能无限制多开。多篇文章中推荐了multiprocessing.cpu_count() * 2 + 1这个数量，考虑到我会在一个机器上部署两个服务，因此数量减半。

4. daemon

daemon = True意味着开启后台运行，默认为False

总结

gunicorn的环境配置和使用都比较简单，也解决了我总是用nohup python run.py >out.log 2>&1 &来启动Flask后台服务的问题。

在采用gunicorn部署之前，我也对后台服务的目录结构进行了调整。虽然只是便利工作的服务，也希望可以尽可能变的更加professional~