<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-im"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>All
 of that said, there's no reason why a user couldn't use a web server 
like httpd to run all three WSGI apps in the same process, multiplied 
across its normal pool of processes. We should make the apps available 
as separate WSGI apps, and users can deploy them in whatever 
combinations meet their needs. </div></div></div></div></blockquote></span><br><span class="gmail-im"></span><div><span class="gmail-m_-7869750091970137625gmail-im"></span><div>As
 mentioned above, Pulp should use configuration settings to disable and 
enable the REST API and the individual content APIs. Separate WSGI 
applications makes the deployment process more complicated.</div></div></blockquote><div><br></div><div>...<br></div><div><br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>Don't we also want to support having a single WSGI process serve 
both content and the REST API? There are practical reasons why users may
 want to deploy this way too. For example having a smaller memory 
footprint by having fewer process groups, or maybe they just want a 
simpler deployment. If we ship one WSGI application with Pulp then we 
allow for both deployment models (together or separate REST API and 
content serving). Users who want to use separated WSGI processes should 
configure the webserver to instantiate the one WSGI application Pulp 
would ship twice, and route content urls one WSGIProcessGroup and the 
REST API calls to another WSGIProcessGroup. We could document that in a 
deployments page which would be cool.<br></div><div><br></div><div>So 
for ^ reasons I think having Pulp ship one WSGI application that could 
handle all Pulp urls would allow for the most deployment models.</div></blockquote> </div><div>Can someone write up an nginx configuration to show what these different deployment options would look like in practice? I ask for this because some of the assertions made in this thread don't match my practical experience. For example, if I understand correctly, one proposed deployment model is for WSGI applications to run directly in a web server's memory space. (That is, one proposed deployment model is for WSGI applications to run as part of a web server's process.) If my understanding is correct, then I find this very strange. Doing so introduces unnecessarily tight coupling between different services, making it impossible to do simple things like restart one WSGI service while leaving others up. Furthermore, in my experience, it's easy to run multiple WSGI applications behind a web server.</div><div><br></div><div>Here's a concrete example. Let's say I have two web applications that share a single SSL certificate, and that are available at different paths. Here's a snippet of an appropriate nginx configuration:<br></div><div><br></div><div><span style="font-family:monospace,monospace">server {<br>    listen 80;<br>    server_name <a href="http://app.example.com">app.example.com</a>;<br>    return 301 https://$host$request_uri;<br>}<br>server {<br>    listen 443 ssl;<br>    server_name          <a href="http://app.example.com">app.example.com</a>;<br>    ssl_certificate      ssl/app.example.com.chained.crt;<br>    ssl_certificate_key  ssl/app.example.com.key;<br>    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;  # SSLv3 is insecure<br>    location /user-1/ {<br>        proxy_set_header  Host               localhost;<br>        proxy_set_header  X-Forwarded-For    $proxy_add_x_forwarded_for;<br>        proxy_set_header  X-Forwarded-Proto  $scheme;<br>        proxy_set_header  X-Real-IP          $remote_addr;<br>        proxy_pass <a href="http://127.0.0.1:8384/">http://127.0.0.1:8384/</a>;<br>    }<br>    location /user-2/ {<br>        proxy_set_header  Host               localhost;<br>        proxy_set_header  X-Forwarded-For    $proxy_add_x_forwarded_for;<br>        proxy_set_header  X-Forwarded-Proto  $scheme;<br>        proxy_set_header  X-Real-IP          $remote_addr;<br>        proxy_pass <a href="http://127.0.0.1:8385/">http://127.0.0.1:8385/</a>;<br>    }<br>}</span><br></div><div><br></div><div>One especially nice thing to notice about this configuration is that the proxied-to applications are completely opaque. They could be WSGI applications (e.g. <a href="http://gunicorn.org/">Gunicorn</a>), or they could be Go applications, or they could be Java applications, or so on. It's a nice decoupling of concerns.<br></div></div>