Django gracefully shutdown

[Odagi]

Hello! 

After lot of work I'm ready to deploy my site on production. I'll use Nginx with uWSGI or fastCGI (not sure yet), and my doubt is how can I shutdown my production Django app gracefully (for make changes for example). Of course I can kill django-python-fcgi processes and restart everything again but is that correct? Can someone give me some hints please?

Thanks!

[Chris Cogdon]

I would actually suggest using gunicorn to run django as a stand-along app server listening on localhost:some-local-port, and use nginx proxy passing to redirect queries to / to the local port.

But that said, once a request is served, the listening processes are essentially idle. So, either just shut down enginx, or set up a redirect to a "we're under maintenance" page, so the requests dont go through to django, or if you're running gunicon, shutting that down will let the existing requests complete, then detach... so nginx wont have a proxyport to connect to.

fastcgi is pretty "old" now, and my personal opinion is that it should probably be avoided. gunicon can talk directly to a wsgi application, so its just about a drop-in replacement.

[Javier Guerra Giraldez]

On Fri, Dec 7, 2012 at 3:25 PM, Odagi <fcmi...@gmail.com> wrote:
> I'll use Nginx with uWSGI or fastCGI (not sure yet), and my doubt is
> how can I shutdown my production Django app gracefully (for make
> changes for example).

on the first paragraph of the new uWSGI docs page about reloads:

"When running with the master process mode, the uWSGI server can be
gracefully restarted without closing the main sockets"

then it goes to explain how to reload code. without breaking any
request in the process.

in short, since Django loads all python code at startup, you can
replace the code (ideally using a VCS) while it keeps running. after
that, you send the SIGHUP signal to make uWSGI reload the app on each
worker as it finishes current requests.


--
Javier

[Roberto De Ioris]

There are various way to accomplish that in uWSGI. As always there is no
'one fit for all' solution so you have to evaluate yourself.

For example lot of people are satisfied with simple 'binary-patching'
approach (sending SIGHUP to the master) where the sockets are not closed
between reloads.

Other people (generally the ones with very high-loaded sites) cannot
tolerate the slowdown of the application during the reload, so they prefer
to spawn a whole new stack (with the new code) and simply move the
connections to the new one as soon as the new app is ready (and eventually
move back to the old instance if something is wrong)

This second approach requires a bit of effort (compared to the simple
SIGHUP approach) but is fore sure the most versatile.

Regarding fastcgi (read: flup, as fastcgi is only a communication
protocol) i do not think it is still "on par" with more modern solutions
like uWSGI, gunicorn and mod_wsgi.

Again, if you want a simple pure-python application server, gunicorn is a
better solution than flup (IMHO)

--
Roberto De Ioris
http://unbit.it

[fuxter fuxter]

I found this solution pretty easy and to my likings:

$ uwsgi ... --touch-reload /var/run/any_file_actually.pid ... # launching uwsgi
$ touch /var/run/any_file_actually.pid # anytime i want to reload all the python code

I'm using using uWSGI in master mode with handfull of small sites and this approach reloads all workers, so it might not be for everybody.

[Odagi]

Thank you for all comments, hints and suggestions. I'll dive a bit more in uWSGI signals and documentations. Gunicorn seems to be a good option too, thanks!