Let me second the need for a good "How To" document on deployment. As a neophyte django user I suddenly felt very lost last week. After several months of development, the ADO interface to the Microsoft SQL server from Linux is working (it still needs some tuning, but the data does go in and out using runserver) and it is now time to deploy. The boss requested an Nginx server, so I started searching the web for how to do it. I had come the the conclusion that FastCGI was the only way that I could deploy and was planning on starting that this morning, until I read this thread. Now I know that I was about to start down an obsolescent path. A "How To" in the official documentation would have prevented this false start.
Does anyone know of an existing cookbook that I can refer to as a starting point? Or should I be making accurate records of my work with a view to contributing a new document? -- Vernon Cole On Saturday, July 20, 2013 5:32:44 AM UTC-6, Christian Schmitt wrote: > > I would recommand to remove FastCGI. > That's the thing i love with the Python Community. Remove depracted or > obsolete things. > > The thing is, there are way more important things to do, than supporting a > 'depracted' way to deploy. And it's really not that hard to get mod_wsgi > with a httpd running. > You could strip that down so easily and compile it, even on CentOS. > > Maybe it's better to improve the Docs about Apache2 / nginx / HAProxy > deployment with mod_wsgi than supporting FCGI. > I mean some things like that: > > > > http://ontwik.com/python/django-deployment-workshop-by-jacob-kaplan-moss/ > > I think that these things are really important. Howto get from development > to Production, with security. > (btw. the talk is from 2011 and some things aren't up 2 date, like the > pgpool single point of failure thing, etc. today you could really well > deploy a good enviroment or 2 or more servers where you don't have any > single point of failure where you don't need to add any extra line of code. > okai maybe you need to find a good way to hold cookies in a good memory > based database, that you could share them between machines, but that is the > only thing you should care about, since that is the only you shouldn't hold > in your legacy database.) > > Am Sonntag, 14. Juli 2013 21:17:00 UTC+2 schrieb Florian Apolloner: >> >> Hi, >> >> I'd like to get rid of everything FCGI-specific in Django sooner or later >> (rather sooner). Flup isn't maintained since a long time and there is no >> ticket tracker to report stuff. Graham pointed out that if someone wants to >> use FCGI they can use >> http://uwsgi-docs.readthedocs.org/en/latest/Options.html#fastcgi-socketwhich >> doesn't even require flup, which sounds like a good compromise to me. >> I'd need some help for the docs from some uWSGI users, since I have no idea >> about it ;) >> >> Thoughts, objections? >> >> Cheers, >> Florian >> > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
