tutorial servidor proyecto produccion para migrar desplegar django web-deployment uwsgi gunicorn django-deployment

proyecto - Desplegando django en un servidor de producción



servidor de produccion django (3)

En primer lugar, permítanme ser claro que soy un usuario de Windows y muy nuevo en el mundo web. Durante los últimos meses he estado aprendiendo python y django, y ha sido una gran experiencia para mí. Ahora, de alguna manera, he creado un pequeño proyecto que me gustaría implementar en el servidor de producción. Dado que django tiene su servidor de desarrollo incorporado, no hubo ningún problema para mí. Pero ahora que tengo que implementarlo en un servidor de producción, busqué en Google y encontré Nginx + uWSGI o Nginx + Gunicorn como la mejor opción para ello. Y como uWSGI y Gunicord son incompatibles con Windows, creo que debería adaptar Ubuntu u otro sistema Unix.

Así que mis preguntas son:

  1. Solo para ser claros, ya que tendré que trabajar con uno de los anteriores, explícame ¿por qué necesito dos servidores?
  2. Si tengo que adaptar el entorno de Ubuntu, ¿tengo que aprender los scripts de shell de Ubuntu, SSH y otras cosas? ¿O el proveedor de hosting me ayudará a hacer eso?
  3. Por favor, permítame ser consciente de qué más necesito para lo mencionado anteriormente.

Muchas gracias por su tiempo y por favor, perdone si mi pregunta fue una pregunta poco convincente. Esperando respuestas positivas.


  1. Una configuración típica involucra dos procesos de servidor (que pueden ejecutarse juntos en el mismo hardware real o servidor virtual) para que el servidor proxy en el frente pueda amortiguar clientes lentos. Por ejemplo: un cliente lento se conectará a nginx con una solicitud. Nginx pasará la solicitud a Gunicorn y Gunicorn responderá. Nginx luego consumirá la respuesta de Gunicorn inmediatamente, liberando los recursos de Gunicorn de inmediato. En ese momento, el cliente lento puede tomar tanto tiempo como quiera consumir la respuesta de Nginx sin ocuparse de los recursos del servidor. Las alternativas al modelo de proceso de dos servidores son usar trabajadores asíncronos con Gunicorn y poner a Gunicorn en primer plano, o usar un combo de sincronización asíncrona como Waitress . Sin embargo, Nginx al frente tiene el beneficio adicional de duplicarse como un servidor de estadísticas listo para usar.

    Tenga en cuenta que los "clientes lentos" pueden describir: los teléfonos móviles que pierden su conexión y dejan el socket TCP hasta que se agote el tiempo de la mitad de la solicitud; Teléfonos móviles que son simplemente lentos; Conexiones no confiables de todos los tipos; clientes hostiles de denegación de servicio que intentan utilizar los recursos del servidor deliberadamente; A veces, cualquier conexión antigua que tenga un problema o un fallo de funcionamiento por cualquier motivo. Este es un problema que afectará a casi cualquier sitio.

  2. No necesitarás shell scripting en sí mismo, pero acostumbrarte a Ubuntu llevará algún tiempo. Hay mucho que aprender, incluso fuera de las secuencias de comandos, como cómo usar el administrador de paquetes, cómo configurar los paquetes una vez que se instalan de manera que no confundan futuras actualizaciones, etc. Y definitivamente tendrá que aprender a usar SSH ; Es una de las herramientas de administración de servidores más fundamentales en el mundo * nix.

    Una alternativa a aprender a usar Ubuntu u otra plataforma de servidor es usar una opción de plataforma como servicio como Heroku, ya que los proveedores de alojamiento de PaaS realmente se encargarán de todo eso por usted. Recomiendo este enfoque. Dicho esto, aunque creo que PaaS es una buena opción para las personas que desean centrarse en el desarrollo y no en el administrador del servidor, independientemente de su nivel de habilidad, también es cierto que un poco de experiencia con las plataformas de servidor Linux hace mucho. al ayudarlo a comprender el entorno en el que se ejecuta su código. Por lo tanto, incluso si usa PaaS, aún se beneficiaría de jugar un poco con Ubuntu (o mucho).

    Otro beneficio de un PaaS es que normalmente su infraestructura maneja la parte Nginx del acuerdo (almacenamiento en búfer de solicitudes lentas a través de proxy). Este es el caso de Heroku, por ejemplo. Por lo tanto, no tendrá que preocuparse por esa parte de la infraestructura.

  3. Esta parte de la pregunta es demasiado amplia para responder, pero hágame saber en los comentarios si necesita una aclaración.


En primer lugar, no hay necesidad de usar Ubuntu si estás más contento con Windows. No sé si nginx funciona en Windows, pero me sorprendería mucho si no lo hace (de hecho, here están los documentos de nginx para instalar en Windows). Apache, mientras tanto, definitivamente funciona en Windows. La documentación de Django tiene una explicación completa de cómo configurar Apache / mod_wsgi para servir a Django.

No necesitas dos servidores. No estoy seguro de por qué crees que lo haces: la razón habitual es tener los activos estáticos en un servidor separado, pero no lo mencionas como una razón. Sin embargo, como solo estás hablando de un sitio pequeño, ni siquiera necesitas hacer eso. Un servidor configurado para servir tanto a Django como a los activos estáticos funcionará bien. Una vez más, los documentos explican exactamente cómo hacer eso.


Lo estoy haciendo casi como en este tutorial: http://michal.karzynski.pl/blog/2013/06/09/django-nginx-gunicorn-virtualenv-supervisor/
Nginx es mi proxy para la aplicación django que se ejecuta en gunicorn y sus estadísticas de servicio, virtualenv para mi entorno de Python, supervisor para ver cómo se ejecuta mi aplicación.
Es posible que se ejecuten algunos errores si no usa Postgresql, pregunte y le ayudaré (usé MySQL en el pasado ahora es Postgresql)