thanks mnaser and sam for the advice. i think uwsgi + native http is not a good solution, nova. A http server + uwsgi is better. So i am imaging that the deployment architecture will be like
haproxy --> http server -> uwsgi_nova_api / uwsgi_glance_api etc. As mnaster said, one http server serve for others uwsgi services. on the other hand, which following solution is better? - apache + mod_uwsgi ( not recommended by uwsgi ) - apache + mode_proxy_uwsgi ( recommended by uwsgi) - nginx + uwsgi So the question is why community choose apache rather than nginx? [0] http://uwsgi-docs.readthedocs.io/en/latest/Apache.html On Fri, Aug 25, 2017 at 5:32 AM, Sam Yaple <sam...@yaple.net> wrote: > 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-u >> se-uwsgi-s-http-capabilities-in-production >> > >> > -- >> > Regards, >> > Jeffrey Zhang >> > Blog: http://xcodest.me >> > >> > _______________________________________________ >> > OpenStack-operators mailing list >> > OpenStack-operators@lists.openstack.org >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators >> > >> >> _______________________________________________ >> OpenStack-operators mailing list >> OpenStack-operators@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 > > -- Regards, Jeffrey Zhang Blog: http://xcodest.me
_______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
