gunicornflask(gunicornflask按天记录日志)
本篇文章给大家谈谈gunicornflask,以及gunicornflask按天记录日志对应的知识点,希望对各位有所帮助,不要忘了收藏本站喔。
本文目录一览:
- 1、gunicorn部署flask--出现错误解决方案
- 2、用Gunicorn部署Flask&Django, since 2022-04-06
- 3、gunicorn部署Flask服务
- 4、Flask使用gunicorn和docker部署项目
- 5、Python3+Gunicorn+Nginx 部署Flask项目
- 6、部署flask应用时,为什么会需要gunicorn/uWSGI
gunicorn部署flask--出现错误解决方案
gunicorn -c gunicorn.conf.py wsgi:app
-c指定执行文件
wsgi是启动文件蠢野名称
gunicorn.errors.HaltServer: HaltServer 'Worker failed to boot.' 3
在启动得时候加入命令:兄埋
如下: gunicorn wsgi:app -c /gunicorn.conf.py --log-level=debug
然后在我们配置的日志文件中可以找到错误进行准确定位:羡档蚂
用Gunicorn部署Flask&Django, since 2022-04-06
(2022.04.06 Wed)
注:Nginx+Gunicorn+web framework是完整的部署流程,本文只介绍用Gunicorn部署web framework的流程作为alternative。
Gunicorn是Python WSGI HTTP服务器,对web框架具有广泛兼容性,易实现,占用服务器资源少,速度快。常和Nginx一起使用,因其有互补特性。
The Gunicorn "Green Unicorn" is a Python Web Server Gateway Interface HTTP server. It is a pre-fork worker model, ported from Ruby's Unicorn project. The Gunicorn server is broadly compatible with a number of web frameworks, simply implemented, light on server resources and fairly fast. It is often paired with NGINX, as the two have complementary features.
一个标准和典型的web应用流程如下:
浏览器发送请求
在这个过程中,web应歼枯备用本质是一个socket服务端,用户是socket客户端。
在web应用处理响氏毁应的过程中,包括对HTTP请求和响应的处理,HTML的解析和生成,响应内容填充到HTML文档中等等。其中任何涉及HTTP解析的部分,比如HTTP接收请求、解析请求、发送响应,都需要深度了解HTTP协议和规范。另外关于TCP/IP的连接,HTML文件的格式等等,也是底层性质的基础工作。理想情况是web应用仅仅处理业务请求,即如何响应球球,而这些基础性质的繁重工作交给一个统一的接口败余完成,接口处理业务以外的部分工作。这个接口就是WSGI。
更多WSGI内容,查看Django基础, 。
写好一个Flask服务,如test.py
使用pip安装Gunicorn,如果安装过程缓慢,选用国内pip服务器,如清华,或者修改pip连接服务器的设置。
可选择性安装若干异步框架
之后就可以用Gunicorn启动Flask服务了
参数说明
之后就可以用过 localhost:8000/ (本地浏览器)访问。
如果通过局域网内的其他设备访问该连接,可先查询host IP地址,方法是在terminal中输入如下指令,找到 inet 对应的ip即可。
有了host ip,即可在LAN的其他设备上通过 192.168.3.8:8000/ 访问Gunicorn部署的Flask程序。访问效果和Flask直接起服务相同,即 python3 test.py
gunicorn部署Flask服务
作为一个Python选手,工作中需要的一些服务接口一般会用Flask来开发。
Flask非常容易上手,它自带的 app.run(host="0.0.0.0", port=7001) 用来调试非常方便,但是用于生产环境无论是处理高并发还是鲁棒性都有所欠缺,一般会配合WGSI容器来进行[生产环境的部署][1]。
小磊哥推荐了参考文章[1]中的部署方式,希望将已有的服务放到gunicorn或者Tornado中部署,并用supervisor来管理所有进程(有几个不同的服务)。
经过调研和尝试
首先pip安装gunicorn。
pip install gunicorn --user
由于是部署在公司云主机上,通常不会给root权亏没带限。之前都是提工单给SA sudo装的,后来发现更安全也更方便的方法是 pip install xxx --user ,美中不足是安装完以后需要 手动添加PATH
export PATH=/home/username/.local/bin:$PATH
方便起见可以加到 ~/.bash_profile 中
简单地,gunicorn可以通过 gunicorn -w 4 -b 127.0.0.1:4000 run:app 启动一个Flask应用。其中,
其中run.py中文件的可能形式是:
通过 gunicorn -h 可以看到gunicorn有非常多的配置项,因此通常会写成一个config.py文件来进行配置。看了一下文档似乎没有给出正确的config.py中配置项的命名,并且有些博客博主给出的配置项命名是错误的,导致配置没有生效,踩了不少的坑(我找不到那篇坑坑的文章了)。这篇博客[2]给出了一些比较常用且 正确 的配置。
我所用项目的配置察扒项如下:
生产环境不需要这个配置项,但调试的时候还是挺好用的。而且,开启debug项后,在启动gunicorn的时候可以看到所有可配置项的配置,如下所示。
之前在被上一篇博主欺骗的时候,仔细看了调试销芦信息,发现 accesslog 和 errorlog 都没有被配置,所以导致启动以后看不到任何日志。
config.py中只需要配置需要修改的项的,大部分采用默认配置即可。默认配置的具体配置内容可以通过 gunicorn -h 来查询。
* 配置文件和调试信息来自两个不同进程,因此信息可能有细微差异
worker_class是指开启的每个工作进程的模式类型,默认为sync模式,也可使用gevent模式。
workers 是工作进程数量,在上述 config.py 中,取的是CPU的数量。需要注意部署机器的性能,不能无限制多开。多篇文章中推荐了 multiprocessing.cpu_count() * 2 + 1 这个数量,考虑到我会在一个机器上部署两个服务,因此数量减半。
daemon = True 意味着开启后台运行,默认为 False
gunicorn的环境配置和使用都比较简单,也解决了我总是用nohup python run.py out.log 21 来启动Flask后台服务的问题。
在采用gunicorn部署之前,我也对后台服务的目录结构进行了调整。虽然只是便利工作的服务,也希望可以尽可能变的更加professional~
传送门: Flask目录调整
参考文章:
[1] 部署方式实践
[2]
Flask使用gunicorn和docker部署项目
使用gunicorn和gevent主要是为了弥补flask在并发上的不足
flask启动文件应该尽量简滚盯老洁则搜
执行 docker ps 看容器是否运行成功,也可以查大升看日志看容器运行情况。
至此,部署完成。若有错误或者疑问请留言!
[img]Python3+Gunicorn+Nginx 部署Flask项目
前言: 之前在本地测试项目的过程中一直使用python app.py的方式来启动项目,这种方式在本地测试的亏明话还可以,但是在生产环境的话就不能使用这种方式。
原因:
1.可能会出现无响应情况
2.无法支持高并发和多线程
3.无法合理利用服务器资源
生产环境: Centos7、Python3
需要模块: Gunicon、Nginx、Flask
一、安装Gunicorn
Gunicorn是一个高效的Web服务器,地蠢橘位相当于Java中的Tomcat。简单来说gunicorn封装了HTTP的底层实现,我们通过gunicorn启动服务,用户请求与服务相应都经过gunicorn传输。
1.创建虚拟环境
项目上传到服务器指定目录下,然后创建python3的虚拟环境,激活并进去虚拟环境,在虚拟环境下可以看到命令前有虚拟环境的名称。(之前在使用Gunicorn模块的过程中,没有使用虚拟环境,导致我启动项目有一直提示没有找到gunicorn这个命令,可能是我在使用python全局环境的过程中,有某些模块影响到这个gunicorn模块,后面在使用虚拟环境就没有出现这个问题。)
2.安装项目所需的模块
3.安装gunicorn
二、项目配置启动
1.创建一个简易的web程序
2.启动服务
4--启动4个进程来分配服务
0.0.0.0--允许任意主机访问
5000--启动端口(与nginx转发的端口一致)
app:目标文件
app:指定模块
补充部分: gunicorn和nginx关系
gunicorn 可以单独提供服务,但生产环境一般不这样做。首先静态资源(带空团jscssimg)会占用不少的请求资源,而对于 gunicorn 来讲它本身更应该关注实际业务的请求与处理而不应该把资源浪费在静态资源请求上;此外,单独运行 gunicorn 是没有办法起多个进程多个端口来负载均衡的。
nginx 的作用就是弥补以上问题,首先作为前端服务器它可以处理一切静态文件请求,此时 gunicorn 作为后端服务器,nginx 将会把动态请求转发给后端服务器,因此我们可以起多个 gunicorn 进程,然后让 nginx 作均衡负载转发请求给多个 gunicorn 进程从而提升服务器处理效率与处理能力。最后,nginx 还可以配置很多安全相关、认证相关等很多处理,可以让你的网站更专注业务的编写,把一些转发规则等其它业务无关的事情交给 nginx 做。
参考链接:
部署flask应用时,为什么会需要gunicorn/uWSGI
Flask ,Django 自带的web server的目的如段就是用于开发,而不是生产环境。他们俩本身是web framework而不是web
server. 他们自带的server应该都只能开如橡告单进程。而像gunicorn是
prefork模式,从nginx每发过来一个请渣明求,它就fork一个进程去处理这个请求,并buffer相关的数据。wsgi服务器都是专门为生产环境
开发的,能配置更多从而处理更复杂的请求状况,从性能和稳定性来说,都更好。
关于gunicornflask和gunicornflask按天记录日志的介绍到此就结束了,不知道你从中找到你需要的信息了吗 ?如果你还想了解更多这方面的信息,记得收藏关注本站。