Diferentes métodos para implementar el proyecto Django y sus pros y contras?

Question

Soy bastante novato a la hora de implementar un proyecto de Django. Me gustaría saber cuáles son los diversos métodos para implementar el proyecto Django y cuál es el más preferido.

Answer 1

Usa el Nginx/Apache/mod-wsgi y no puedes equivocarte.

Si prefiere una alternativa simple, solo use Apache.

hay un muy buen documento de despliegue: http://lethain.com/entry/2009/feb/13/the-django-and-ubuntu-intrepid-almanac/

Answer 2

La documentación de Django enumera Apache/mod_wsgi, Apache/mod_python y FastCGI etc.

mod_python ahora está en desuso, uno debe utilizar mod_wsgi lugar.

Django con mod_wsgi es fácil de configurar, pero:

• sólo se puede utilizar una versión de Python en un momento [editar: incluso se puede utilizar solamente el mod_wsgi versión pitón fue compilado por]
• [editar: parece si me equivoco en mod_wsgi no apoyar virtualenv: lo hace]

Así que para múltiples sitios (dirigidos a diferentes versiones de Django/python) en un mod_wsgi servidor no los bes t solución.

FastCGI se puede utilizar con virtualenv, también con diferentes versiones de Python, ya que se corre con

 
./manage.py runfcgi … 

y luego configurar el servidor web para utilizar esta interfaz fcgi.

Lo nuevo y popular sobre la implementación de django parece ser gunicorn. Es un servidor web que implementa wsgi y normalmente se utiliza como servidor con un servidor web "grande" como proxy.

Despliegue con gunicorn se parece mucho a fcgi: ejecuta un proceso de procesamiento de django con manage.py, y un servidor web como frontend para el mundo.

Pero gunicorn despliegue tiene algunas ventajas sobre fcgi:

• velocidad - no he encontrado las fuentes, pero los puntos de referencia fcgi decir no es tan rápido como el F sugiere
• ficheros de configuración, para que fcgi debe hacer toda la configuración en la línea de comando al ejecutar el comando manage.py. Esto no funciona bien cuando se ejecutan varias instancias de django a través de un init.d (inicio de servicio del sistema del sistema operativo similar a Unix). Siempre es la misma línea de cmd, con solo diferentes archivos de configuración
• gunicorn puede eliminar privilegios: no es necesario hacer esto en su script init.d, y es fácil cambiar a un usuario por instancia django
• gunicorn se comporta más como un daemon: escribir archivos pidfile y logfile, bifurcando en el fondo, etc. hace que sea más fácil usarlo en un script init.d.

Por lo tanto, le sugiero que utilice la solución de gunicorn, a menos que tenga un solo sitio en un solo servidor con poco tráfico, de lo que podría utilizar la solución de wsgi. Pero creo que a la larga estás más feliz con Gunicorn.

Si tiene un servidor web django único, le sugiero que use nginx como frontendproxy, ya que es el que mejor funciona (de nuevo, esto se basa en los puntos de referencia que leí en algunos blogs - ya no tengo el URL). Personalmente utilizo apache como frontendproxy, ya que lo necesito para otros sitios alojados en el servidor.

Una instrucción de configuración sencilla para el despliegue django se puede conocer aquí: http://ericholscher.com/blog/2010/aug/16/lessons-learned-dash-easy-django-deployment/

Mi script de init.d en gunicorn se encuentra en github: https://gist.github.com/753053

Por desgracia, sin embargo, no un blog sobre ello, pero un administrador de sistemas experimentado debería poder hacer la configuración requerida.

Answer 3

Yo mismo he enfrentado muchos problemas al implementar Django Projects y automatizar el proceso de implementación. Apache y mod_wsgi eran como una maldición para Django Deployment. Hay varias herramientas como Nginx, Gunicorn, SupervisorD y Fabric que son tendencia para el despliegue de Django. Al principio, los utilicé/configuré individualmente sin la automatización de implementación, lo que demoró mucho tiempo (tuve que actualizar las pruebas y los servidores de producción para mi cliente y tuve que actualizarlos tan pronto como se probó y aprobó una nueva función). Me encontré con django-fagungis, que automatiza totalmente mi Django Deployment para clonar mi proyecto de bitbucket a implementación en mi servidor remoto (usa Nginx, Gunicorn, SupervisorD, Fabtic y virtualenv y también instala todas las dependencias sobre la marcha), todo con solo tres comandos :) Puede encontrar más información al respecto en mi publicación de blog here. Ahora ni siquiera tengo que involucrarme en este proceso (que solía tomar mucho tiempo) y uno de mis desarrolladores junior ejecuta esos tres comandos de django-fagungis mentioned here en su máquina local y obtenemos una copia nueva y nítida de nuestro proyecto implementado en minutos sin ningún problema :)