[openstack-dev] [Openstack-operators] [kolla][puppet][openstack-ansible][tripleo] Better way to run wsgi service.

Sam Yaple samuel at yaple.net
Thu Aug 24 21:32:39 UTC 2017


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 <mnaser at vexxhost.com>
wrote:

> On Thu, Aug 24, 2017 at 11:15 AM, Jeffrey Zhang <zhang.lei.fly at 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-operators at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> >
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170824/57fcb16f/attachment.html>


More information about the OpenStack-dev mailing list