I intend to use a single VPS to deploy multiple low-traffic CherryPy apps as subdirectories; eg: example.com/app1
, example.com/app2
, etc.
After researching on WSGI deployment, it looks like the preferred method for deploying apps is to use a WSGI server (Gunicorn, uWSGI, etc) and NGinx in a reverse-proxy setup. It seems like overkill to use two webservers in tandem — especially since my CherryPy app is itself a webserver — but I don't want to dismiss the idea as it appears everywhere. I'm certainly not an expert so I'd like to discuss it.
I see three options:
- Deploy CherryPy by itself.
- Deploy beneath Gunicorn or another WSGI server.
- Deploy beneath a WSGI server and reverse-proxy to NGinx, which seems to be everyone's solution.
My questions:
- What's the main reason I see this pattern everywhere? Is NGinx just that good?
- For low-traffic apps, is the native CherryPy server good enough, or should I not even try?
Any and all advice is appreciated, thank you.
Best Answer
Why do people put Nginx in the front?
zlib
is just a wrapper around the C library. But because Nginx handles connection effectively it's a good idea to relieve your CherryPy worker threads from serving static content in production and dedicate only on dynamic content.Is it safe to use CherryPy on its own?
According to one of the original authors, yes. Most of web-relevant things you can do with CherryPy on its own.
CherryPy has notion of an application and you can serve several applications with one CherryPy instance. CherryPy also can serve other WSGI applications.
Deploying CherryPy
In a traditional *nix-style deployment you write init script, daemonise you process, drop its privileges, write its PID, etc. It's not a big deal when you have a couple of CherryPy instances. When you have dozens, it becomes tedious and it makes sense to hand over process management to Gunicorn or uWGSI and switch your CherryPy instances from HTTP to WSGI.
I wrote a tutorial/project skeleton, cherrypy-webapp-skeleton, which goal was to fill the gaps for deploying (traditional) a real-world CherryPy application on Debian for a web-developer.
Wrap up
CherryPy * 1 ⇐ HTTP ⇒ Client
.CherryPy * n ⇐ HTTP ⇒ Nginx ⇐ HTTP ⇒ Client
.CherryPy * n ⇐ WSGI ⇒ Gunicorn ⇐ HTTP ⇒ Nginx ⇐ HTTP ⇒ Client
.