标签: uwsgi

(关于SO的其他帖子类似,但没有一个具有uwsgi + Flask + virtualenv的特定组合)(这一个是最接近的)

我通过apt-get安装了uwsgi.我也试过pip install wsgi.两个人都给了我同样的问题.

测试命令:

sudo uwsgi -s /tmp/uwsgi.sock -w myapp:app -H myvirtualenv

结果:

Python version: 2.7.4 (default, Apr 19, 2013, 18:35:44)  [GCC 4.7.3]
Set PythonHome to myvirtualenv
ImportError: No module named site

我可以在虚拟环境中运行我的应用程序.

我使用主管来运行uWSGI应用程序.为什么uWSGI应用程序在停止主管后并不总是停止？主管配置:

[program:test]
autostart = true
user=root
command=uwsgi --master --workers  5 --disable-logging --socket 127.0.0.1:8888
--module web --callable app
priority=1
redirect_stderr=true
stdout_logfile = /data/log

首先,请让我明白我是一个Windows用户,对网络世界来说是一个新手.在过去的几个月里,我一直在学习python和django,对我来说这是一次很棒的经历.现在我以某种方式创建了一个我希望在生产服务器中部署的小项目.由于django有内置的开发服务器,所以对我没有问题.但现在我必须将它部署到生产服务器上,我用Google搜索并发现Nginx + uWSGI或Nginx + Gunicorn是它的最佳选择.由于uWSGI和Gunicord与Windows不兼容,我认为我应该适应Ubuntu或其他Unix系统.

所以我的问题是:

1. 为了清楚起见,因为我将不得不使用上述其中一个,请向我解释为什么我需要两台服务器？
2. 如果我必须适应Ubuntu环境,我是否必须学习Ubuntu shell脚本,SSH和其他东西？或托管服务提供商会帮助我做到这一点？
3. 请让我知道上述有关我还需要什么.

非常感谢你的时间,如果我的问题是一个蹩脚的问题,请原谅.希望得到积极回应的答案.

我有这个问题和答案中描述的完全相同的问题.这个问题的答案是一个很好的解决方法,但我不明白根本问题.在负载均衡器处终止SSL并在负载均衡器和Web/app服务器之间使用HTTP非常常见.什么片段不尊重X-Forwarded-Proto？是werkzeug吗？烧瓶？uwsgi？

在我的情况下,我正在使用AWS ELB(设置X-Forwarded-Proto)=> Nginx(它沿着X-Forwarded-Proto转发到uwsgi).但是在python应用程序中,我必须按照上面引用的问题中描述的Flask Request子类.

由于这是一种常见的部署方案,似乎应该有更好的解决方案.我错过了什么？

我有一个使用python记录器的uWSGI/Flask设置.虽然只有一些工作人员的日志才能登录日志,但过了一段时间后,甚至那些日志根本就不再出现了.我的假设是,当uWSGI重新启动(克隆)工作程序时,日志记录会以某种方式被破坏.有任何想法吗？

app/server.py:

app = Flask(...)
handler = logging.StreamHandler()
app.logger.addHandler(handler)
app.run()

uWSGI:

uwsgi --emperor /etc/uwsgi/apps-enabled/*.ini --die-on-term --uid www-data --gid www-data --logto /var/www/app.com/logs/uwsgi/emperor.log --socket /tmp/uwsgi/emperor.sock --enable-threads --master --single-interpreter --log-reopen --chmod-socket=770

apps-enabled/app-0.ini和apps-enabled/app-1.ini如下所示:

module=server:app
enable-threads=true
single-interpreter=true
master=true
chdir=/var/www/app.com/app
env=APPLICATION_ENVIRONMENT=production
venv=/var/www/app.com/virtualenv

logto=/var/www/app.com/logs/uwsgi/app.com-0.log
log-reopen=true
chmod-socket=770
buffer-size=65535

lazy-apps=true
max-requests=5000
heartbeat=15

for=0 1 2 3 4 5 6 7
socket=/tmp/uwsgi/app.0.%(_).sock
endfor=

processes=8

map-socket=0:1
map-socket=1:2
map-socket=2:3
map-socket=3:4
map-socket=4:5
map=socket=5:6
map=socket=6:7
map=socket=7:8

我也尝试使用SysLogHandler相同的结果.

我安装了以emperor模式运行的uWSGI.Vassals使用不同的python版本,因此我不能在uWSGI二进制文件中嵌入python插件.

有了这个,我想在其中一个封锁中使用asyncio循环引擎,但我无法弄清楚如何运行非嵌入的asyncio插件和greenlet插件.

到目前为止我尝试过的:

• 将asyncio和greenlet嵌入到uWSGI中,使用:

  CFLAGS="-I/usr/local/include/python3.4" make PYTHON=python3.4 asyncio
  

  Run Code Online (Sandbox Code Playgroud)

  建立uWSGI.但这也将嵌入python插件,我不想要它.

• 使用以下方法构建asyncio和uwsgi作为外部插件:

  PYTHON=python3.4 ./uwsgi --build-plugin "plugins/greenlet greenlet"
  PYTHON=python3.4 ./uwsgi --build-plugin "plugins/greenlet greenlet"
  

  Run Code Online (Sandbox Code Playgroud)

  构建插件,但插件无法加载:

  /usr/local/lib/uwsgi/asyncio_plugin.so:unfined defined symbol:up
  /usr/local/lib/uwsgi/greenlet_plugin.so:undefined symbol:up

  在日志中.

  //编辑

  我已经发现必须在设置中的asyncio和greenlet之前启用python插件,因此错误不再发生,但greenlet不起作用,当前greenlet中没有父级.

我还能尝试做些什么？我敢打赌,在python3.4插件中嵌入asyncio和greenlet会起作用,但我不知道该怎么做或者甚至可能.

目前我正在使用内置所需插件的第二个皇帝,但由于平台的限制,我不能再使用该解决方案了.

我的django应用程序的nginx + uwsgi配置有问题,我在uwsgi错误日志中不断收到此错误:

1月13日星期三15:26:04 - uwsgi_response_writev_headers_and_body_do():在POST/company/get_unpaid_invoices_chart /(86.34.48.7)期间断管[core/writer.c第296行] IOError:写入错误

1月13日星期三15:26:20 - uwsgi_response_write_headers_do():在GET/gestiune/print_pdf/nir/136194 /(89.122.255.186)期间断管[core/writer.c第238行] IOError:写入错误

我没有收到他们的所有要求,但我确实每分钟得到几个.我搜索了它,我明白这是因为当uwsgi想要写响应时,nginx会关闭与uwsgi的连接.这看起来很奇怪,因为在我的nginx配置中我有这个:

包括uwsgi_params;

uwsgi_pass unix:/home/project/django/sbo_cloud/site.sock;

uwsgi_read_timeout 600;

uwsgi_send_timeout 600;

uwsgi_connect_timeout 60;

我确信没有出现错误的请求超过600秒超时.知道为什么会这样吗？

谢谢

我在金字塔上有应用程序.我使用这些配置在uWSGI中运行它:

[uwsgi]
socket = mysite:8055
master = true
processes = 4
vacuum = true
lazy-apps = true
gevent = 100

和nginx配置:

server {
    listen 8050;
    include uwsgi_params;

    location / {
        uwsgi_pass mysite:8055;
    }
}

通常都很好,但有时uWSGI会杀死工人.我不明白为什么.

我在uWSGI日志中看到:

DAMN ! worker 2 (pid: 4247) died, killed by signal 9 :( trying respawn ...
Respawned uWSGI worker 2 (new pid: 4457)

但在日志中没有Python异常.

有时我在uWSGI日志中看到:

invalid request block size: 11484 (max 4096)...skip
[uwsgi-http key: my site:8050 client_addr: 127.0.0.1 client_port: 63367] hr_instance_read(): Connection reset by peer …

我用uWSGI和nginx运行我的Flask应用程序.有500错误,但回溯没有出现在浏览器或日志中.如何从Flask记录回溯？

uwsgi --http-socket 127.0.0.1:9000 --wsgi-file /var/webapps/magicws/service.py --module service:app --uid www-data --gid www-data --logto /var/log/magicws/magicapp.log

uWSGI日志仅显示500状态代码,而不是回溯.nginx日志中也没有任何内容.

[pid: 18343|app: 0|req: 1/1] 127.0.0.1 () {34 vars in 642 bytes} 
[Tue Sep 22 15:50:52 2015] 
GET /getinfo?color=White => generated 291 bytes in 64 msecs (HTTP/1.0 500) 
2 headers in 84 bytes (1 switches on core 0)

我有一个在uWSGI后面运行的python 2 flask app,由supervisord管理.烧瓶应用程序正在将日志写入sys.stdout.然后由uWSGI接收这些日志并由supervisord写入文件.uWSGI日志写入/ dev/stderr.请参阅下面的supervisord conf.

[program:uwsgi]
command = uwsgi --ini /etc/uwsgi.conf --master
directory = /app
autostart = true
autorestart = true
stdout_logfile = /var/log/myapplication/application.log
stdout_logfile_maxbytes = 50000000
stdout_logfile_backups = 3
stderr_logfile = /dev/stderr
stderr_logfile_maxbytes = 0
stopsignal = INT

这很棒!我很好地分离了应用程序日志和uWSGI日志.

我现在已升级到python 3.这一切都很顺利,除了应用程序日志现在最终在uWSGI的stderr中,与uWSGI日志混合在一起.

我已经拖网了uWSGI码头,并且无法在python 2和python 3之间找到这种变化的原因.

我在定义套接字时尝试重定向,就像这里建议的http://lists.unbit.it/pipermail/uwsgi/2016-February/008383.html那样只是将所有内容(应用程序和uWSGI日志)重定向到/dev/null.

我也找到了这个http://lists.unbit.it/pipermail/uwsgi/2016-January/008353.html但是找不到关于pyimport-shared的任何信息.

有谁知道可能会发生什么？

如果它有帮助,我的uWSGI conf就在这里.

[uwsgi]
uid = www-data
gid = www-data
module = application:application

socket = /run/uwsgi.sock

single-interpreter = true
enable-threads = true
buffer-size = 16384

processes …