Open Stack

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 <samuel at 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 <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-u
>> se-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
>>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Regards,
Jeffrey Zhang
Blog: http://xcodest.me
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170825/c92f9d94/attachment.html>