On Sun, May 15, 2011 at 9:38 AM, Dragan Espenschied <[email protected]> wrote:
> Sorry, I don't think reverse-proxying a server internal to the app to the
> outside world is a simple setup. :))
::shrug::
Done that multiple times, and it's much more reliable for me than
mod_wsgi. FTR, if you want to avoid having to do maintenance, you have
to modify your app a bit to run as a system service, which is not
difficult, but has to be done.
> It might be a nice option for people needing speed optimized setup. But
> actually
> most users would want to drop their project folder into a directory on some
> server and see it run.
Well, I'm certainly not the most users if that's the description of
most users. ;)
The way I thought about it was, I wanted a way to serve the app the
way I run it in development, and that's ``python app.py``.
Reverse-proxying allows this, and it's a lot simpler to set up than
you might think (if you don't use Apache as a frontend, that is).
Here's an example nginx config for one of my apps:
server {
listen: 80;
servername: subdomain.domain.com;
... some logger config here ...
location / {
proxy_pass http://127.0.0.1:8080; # use whatever port you have
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
location ~ /static/(.*) {
alias /opt/myapp/source/static/$1;
expires 300d; # add expire header of 300 days to static content
add_header Vary Accept-Encoding;
add_header Cache-Control private;
}
}
And that's pretty much it. The second location block that deails with
static files is optional, but it's recommended to have nginx serve
static content since it's much better at it. The ``proxy_set_header``
lines are used to relay incoming request's headers to the application,
or otherwise the application will think the request is coming from the
frontend server (nginx), because it really is in reality.
In the second block, all lines except the first one (alias) are optional.
With the above setup (which is simple to figure out even if you have
to google a little), you just start your app normally at port 8080,
using either built-in Cherrypy (uses a bit more memory) or using
bjoern, or whatever dedicated wsgi server.
My opinion is that this greatly simplifies deployment. If you want to
start your application as a system service, that's another issue, and
it's a tad bit more involved. You don't have to, of course, but it
just completes the setup.
--
Branko Vukelic
--
You received this message because you are subscribed to the Google Groups
"web.py" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/webpy?hl=en.
