uwsgi

flask+uwsgi+supervisor+nginx在局域网服务器上部署实践

喜你入骨 提交于 2019-12-01 23:55:17
flask可以快速的搭建http服务,但是为了搭建网站还是需要web服务器和相关监控管理操作,一套flask、uwsgi、supervisor、nginx是较好的完整解决方案。 本文对自己学习做一个记录,以一个简单的显示‘Hello Flask!’程序来测试,跑通整个流程,方式是在局域网服务器上部署,在个人电脑上访问。 服务器系统是centos7 安装了pyenv pyenv 切换到python3.5版本,不懂版本切换的可以参考我这边文章 https://my.oschina.net/u/3851199/blog/1941983 新建一个简单程序test_flask.py from flask import Flask app = Flask(__name__) @app.route('/') def hello_world(): return 'Hello Flask!' if __name__ == '__main__': app.run(host='0.0.0.0',port=8080) 测试局域网访问 在服务器上运行# python test_flask.py,出现如下: 此时,在个人电脑浏览器输入10.12.28.27:8080,(10.12.28.27是我服务器ip),出现如下错误: ok,此时原因可能是服务器防火墙打开了,需要关闭,在服务器上输入关闭防火墙命令

nginx安装+虚拟主机配置+UWSGI

半城伤御伤魂 提交于 2019-12-01 23:55:03
安装 (1)在线安装 $sudo apt-get install nginx Nginx的版本是1.2.1 ubuntu安装Nginx之后的文件结构大致为: 所有的配置文件都在/etc/nginx下,并且每个虚拟主机已经安排在了/etc/nginx/sites-available下 启动程序文件在/usr/sbin/nginx 日志放在了/var/log/nginx中,分别是access.log和error.log 并已经在/etc/init.d/下创建了启动脚本nginx 默认的虚拟主机的目录设置在了/usr/share/nginx/www (2)源码安装也比较简单,所有文件默认放到/usr/local/nginx目录,也可以自己指定位置 启动 (1)在线安装的启动过程 $sudo /etc/init.d/nginx start # 或者下面 sudo service nginx start (2)源代码安装的启动过程 $cd /usr/local/nginx $sbin/nginx 虚拟主机 (1)在site-ennable下面创建文件ubuntu.nobsu.net.conf文件,编辑如下: server { listen 80; server_name ubuntu.nobsu.net; index index.html index.htm index.php; root

nginx + uwsgi + debian + django部署

喜欢而已 提交于 2019-12-01 23:11:08
准备工作 我使用的不是本机系统,而是运行docker镜像库中的debian系统,因为后面还想研究一下,docker自动化部署相关内容,如果你想直接部署,可以跳过准备工作。 下载docker替换镜像源,因为如果用docker自己的镜像源下载速度会很慢。根据操作系统的不同,大家可以自行百度,mac系统docker桌面版可以在prefrence daemon 的registry mirrors: docker images 查看本地镜像 docker search debian 查找debian网络镜像 docker pull debian从第三步的结果中拉取想要的镜像 docker run --name mytest -p 0.0.0.0:8000:8081/tcp -it debian /bin/bash --name 为容器取名字 -p 本机端口:容器端口 -it 交互 docker ps 查看容器 -a 查看所有容器 docker stop container_id 停止容器 Docker rm -v containerid 删除容器 将宿主机的项目拷贝到容器中:docker cp 宿主机中要拷贝的文件名及其路径 容器名:要拷贝到容器里面对应的路径 系统镜像 在容器中,同样要先更新一下debian的下载源 sudo sed -i 's/deb.debian.org/mirrors

uWSGI 漏洞复现(CVE-2018-7490)

↘锁芯ラ 提交于 2019-12-01 23:08:21
uWSGI是一个Web服务器,它实现了WSGI协议、uwsgi、http等协议。Nginx中HttpUwsgiModule的作用是与uWSGI服务器进行交换。WSGI是一种Web服务器网关接口。它是一个Web服务器(如nginx,uWSGI等服务器)与web应用(如用Flask框架写的程序)通信的一种规范。 目标: 了解uWSGI CVE-2018-7490漏洞形成原理和漏洞利用方法。 利用搜索工具了解CVE-2018-7490漏洞详情。再利用漏洞获取根目录key.txt的值。 解析思路 http://219.153.49.228:48001/..%2f..%2fkey.txt .. 表示上一级 %2f表示/ 在IP后面输入: ..%2f..%2f..%2f..%2f..%2f..%2f..%2fkey.txt 来源: https://www.cnblogs.com/daiorz/p/11720420.html

uWSGI、WSGI、uwsgi、wsgiref

佐手、 提交于 2019-12-01 21:44:48
WSGI WSGI: 全称是 Web Server Gateway Interface , WSGI 不是服务器,也不是 python 模块、框架、 API 或者任何软件,只是一种 规范 ,描述 web server 如何与 web application 通信的规范 。是Web服务器和Web应用程序之间或框架之间的 通用接口标准 WSGI就是一座桥梁,WSGI的接口分为两个:一个是与Web服务器的接口,一个是与服务器端程序的接口;WSGI的作用就是在协议之间进行转化。WSGI将Web组件分成了三类:Web 服务器(WSGI Server)、Web中间件(WSGI Middleware)与Web应用程序(WSGI Application)。 Web Server接收HTTP请求,封装一系列环境变量,按照WSGI接口标准调用注册的WSGI Application(如:django程序),最后将响应返回给客户端。 虽然WSGI的设计目标是连接标准的Web服务器(Nginx、Apache)与服务器端程序,但它本身也可以作为Web服务器运行。但由于性能方面的限制,该服务器一般只在测试时使用。 wsgiref wsgiref则是官方给出的一个实现了WSGI标准用于演示用的简单Python内置库,它实现了一个简单的WSGI Server和WSGI Application(在simple

项目部署 ubuntu Django uwsgi配置

蹲街弑〆低调 提交于 2019-12-01 21:40:56
1.进入项目文件夹   mkdir uwsgi_file   vim uwsgi.ini   写入保存 1 [uwsgi] 2 3 chdir = /home/mysite/my_project # 项目目录 4 module = my_project.wsgi:application # wsgi所在目录 5 # home = /root/.virtualenvs/mywork # 虚拟环境目录 缺省 6 7 master = true # 主进程 8 processes = 4 # 进程数 9 harakiri =60 10 max-requests = 5000 11 12 13 14 socket=127.0.0.1:8001 #端口 15 # http=127.0.0.1:8001 16 uid = 1000 17 gid = 2000 18 pidfile =/home/mysite/my_project/uwsgi_file/uwsgi.pid 19 daemonize = /home/mysite/my_project/uwsgi_file/uwsgi.log #日志 20 vacuum = true 后台开启 21 22 23 2.重启Nginx   service nginx restart 3.开启setting debug = True 4.启动uwsgi

UWSGI killing workers too fast

点点圈 提交于 2019-12-01 21:13:55
问题 I have encountered one bug in my webapp that has been working for more than a year before, and when I switched to UWSGI on a new instance to speed things up a bit, I encountered this. My app has "quick add" modal window which allows user to add a new customer to the database, and immediately go to the shopping cart for that user. So, the module makes a POST request to /customers/quick_create/ , which does the redirection to /cart/10000 , where 10000 is the ID of the customer. Then the fun

UWSGI killing workers too fast

試著忘記壹切 提交于 2019-12-01 20:01:30
I have encountered one bug in my webapp that has been working for more than a year before, and when I switched to UWSGI on a new instance to speed things up a bit, I encountered this. My app has "quick add" modal window which allows user to add a new customer to the database, and immediately go to the shopping cart for that user. So, the module makes a POST request to /customers/quick_create/ , which does the redirection to /cart/10000 , where 10000 is the ID of the customer. Then the fun starts. As there is a check on that /cart to see whether there is a customer with that ID or not, I

Enabling internal routing in uWSGI

微笑、不失礼 提交于 2019-12-01 17:00:33
I have a Django app working with uWSGI. My uWSGI config is: [uwsgi] http = 127.0.0.1:8000 env = DJANGO_SETTINGS_MODULE=my_django_app.settings module = my_django_app.wsgi:application home = /var/www/myapp/venv chdir = /var/www/myapp/app pidfile = /tmp/myapp.pid logger = syslog logfile-chown = True logfile-chmod = 644 touch-logreopen = /var/www/uwsgi/log/rotate_monitor uid = myapp gid = myapp master = True vacuum = True harakiri = 20 max-requests = 5000 processes = 4 threads = 1 post-buffering=4096 touch-reload = /var/www/myapp/conf/uwsgi.ini route = ^/test log:someone called /test But route

Enabling internal routing in uWSGI

安稳与你 提交于 2019-12-01 16:41:42
问题 I have a Django app working with uWSGI. My uWSGI config is: [uwsgi] http = 127.0.0.1:8000 env = DJANGO_SETTINGS_MODULE=my_django_app.settings module = my_django_app.wsgi:application home = /var/www/myapp/venv chdir = /var/www/myapp/app pidfile = /tmp/myapp.pid logger = syslog logfile-chown = True logfile-chmod = 644 touch-logreopen = /var/www/uwsgi/log/rotate_monitor uid = myapp gid = myapp master = True vacuum = True harakiri = 20 max-requests = 5000 processes = 4 threads = 1 post-buffering