I have been running api services behind uwsgi in http mode from Newton forward. I recently switched to the uwsgi+nginx model with 2 containers since I was having wierd issues with things that I couldn't track down. Mainly after I started using keystone with ldap. There would be timeouts and message-to-long type errors that all went away with nginx.
Additionally, running with HTTPS was measurably faster with nginx proxying to a uwsgi socket. This was just my experience with it, if you do want to switch to uwsgi+http make sure you do thorough testing of all the components or you may be left with a component that just won't work with your model. On Thu, Aug 24, 2017 at 12:29 PM, Mohammed Naser <mna...@vexxhost.com> wrote: > On Thu, Aug 24, 2017 at 11:15 AM, Jeffrey Zhang <zhang.lei....@gmail.com> > wrote: > > We are moving to deploy service via WSGI[0]. > > > > There are two recommended ways. > > > > - apache + mod_wsgi > > - nginx + uwsgi > > > > later one is more better. > > > > For traditional deployment, it is easy to implement. Use one > > uwsgi progress to launch all wsgi services ( nova-api,cinder-api , etc). > > Then one nginx process to forward the http require into uwsgi server. > > > > But kolla is running one process in one container. If we use > > the recommended solution, we have to use two container to run > > nova-api container. and it will generate lots of containers. > > like: nginx-nova-api, uwsig-nova-api. > > > > i propose use uwsgi native http mode[1]. Then one uwsgi > > container is enough to run nova-api service. Base one the official > > doc, if there is no static resource, uWSGI is recommended to use > > as a real http server. > > > > So how about this? > > I think this is an interesting approach. At the moment, the Puppet > modules currently allow deploying for services using mod_wsgi. > Personally, I don't think that relying on the HTTP support of uWSGI is > very favorable. It is quite difficult to configure and 'get right' > and it leaves a lot to be desired (for example, federated auth relies > on Apache modules which would make this nearly impossible). > > Given that the current OpenStack testing infrastructure proxies to > UWSGI, I think it would be best if that approach is taken. This way, > a container (or whatever service) would expose a UWSGI API, which you > can connect whichever web server that you need. > > In the case of Kolla, the `httpd` container would be similar to what > the `haproxy` is. In the case of Puppet, I can imagine this being > something to be managed by the user (with some helpers in there). I > think it would be interesting to add the tripleo folks on their > opinion here as consumers of the Puppet modules. > > > > > > > [0] https://governance.openstack.org/tc/goals/pike/deploy-api- > in-wsgi.html > > [1] > > http://uwsgi-docs.readthedocs.io/en/latest/HTTP.html#can-i- > use-uwsgi-s-http-capabilities-in-production > > > > -- > > Regards, > > Jeffrey Zhang > > Blog: http://xcodest.me > > > > _______________________________________________ > > OpenStack-operators mailing list > > openstack-operat...@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > > > > _______________________________________________ > OpenStack-operators mailing list > openstack-operat...@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
