On Fri, Aug 25, 2017 at 9:56 AM, Jeffrey Zhang <[email protected]> wrote:
> 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? > Well, in TripleO we're using apache + mod_wsgi [1] not mod_uwsgi. [1] https://modwsgi.readthedocs.io/en/develop/ > > [0] http://uwsgi-docs.readthedocs.io/en/latest/Apache.html > > > On Fri, Aug 25, 2017 at 5:32 AM, Sam Yaple <[email protected]> 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 <[email protected]> >> wrote: >> >>> On Thu, Aug 24, 2017 at 11:15 AM, Jeffrey Zhang <[email protected]> >>> 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 >>> > [email protected] >>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstac >>> k-operators >>> > >>> >>> _______________________________________________ >>> OpenStack-operators mailing list >>> [email protected] >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators >>> >> >> >> ____________________________________________________________ >> ______________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: [email protected]?subject:unsubscrib >> e >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > > -- > Regards, > Jeffrey Zhang > Blog: http://xcodest.me > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Juan Antonio Osorio R. e-mail: [email protected]
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
