python - django apache
¿Cómo implementa USTED su aplicación WSGI?(y por qué es la mejor manera) (9)
Despliegue de una aplicación WSGI. Hay muchas maneras de despellejar a este gato. Actualmente estoy usando apache2 con mod-wsgi, pero puedo ver algunos problemas potenciales con esto.
Entonces, ¿cómo se puede hacer?
- Apache Mod-wsgi (los otros mod-wsgi parecen no valer la pena)
- Servidor web Pure Python, por ejemplo, paste, cherrypy, Spawning, Twisted.web
- como 2 pero con proxy inverso desde nginx, apache2, etc., con un buen manejo de archivos estáticos
- Conversión a otro protocolo como FCGI con un puente (por ejemplo, Flup) y ejecución en un servidor web convencional.
¿Más?
Quiero saber cómo lo haces y por qué es la mejor manera de hacerlo. Me encantaría que me aburre con detalles sobre qué y por qué, cosas específicas de la aplicación, etc. Rechazaré cualquier respuesta no loca.
Como siempre: depende ;-)
Cuando no necesito ninguna característica de apache voy con un servidor web de python puro como pegar, etc. Supongo que depende exactamente de su aplicación y puede decidirse haciendo algunos benchmarks. Siempre quise hacer algo pero nunca llegué a eso. Creo que el Spawning podría tener algunas ventajas al usar IO no bloqueado de fábrica, pero a veces tuve problemas debido a los parches que está haciendo.
Siempre puedes poner un barniz en el frente también, por supuesto.
Si se requiere un Apache, usualmente voy con la solución 3 para poder mantener los procesos separados. También puede mover procesos más fácilmente a otros servidores, etc. Simplemente me gusta mantener las cosas separadas.
Para archivos estáticos, estoy usando ahora un servidor separado para un proyecto que solo sirve imágenes estáticas / css / js. Estoy usando lighttpd como servidor web que tiene un gran rendimiento (en este caso, ya no tengo barniz).
Otra herramienta útil es la supervisión para controlar y monitorear estos servicios.
También estoy usando buildout para administrar mis despliegues y sandboxes de desarrollo (junto con virtualenv ).
Estoy usando Google App Engine para una aplicación que estoy desarrollando. Ejecuta aplicaciones WSGI. Aquí hay un par de bits de información sobre él.
Esta es la primera aplicación web en la que he trabajado realmente, por lo que no tengo una base para comparar, pero si eres un seguidor de Google, es posible que quieras investigarlo. Me he divertido mucho usándolo como mi marco para el aprendizaje.
Apache httpd + mod_fcgid usando web.py (que es una aplicación de wsgi).
Funciona de maravilla.
Estamos utilizando Pure Paste para algunos de nuestros servicios web. Es fácil de implementar (con nuestro mecanismo de implementación interno, no estamos usando Paste Deploy ni nada de eso) y es bueno minimizar la diferencia entre los sistemas de producción y lo que se ejecuta en las estaciones de trabajo de los desarrolladores. Advertencia: no esperamos baja latencia de Paste en sí debido a la naturaleza pesada de nuestras solicitudes. En algunos benchmarking crudos que hicimos, no obtuvimos resultados fantásticos ; simplemente terminó siendo discutible debido al gasto de nuestro controlador de solicitud típico. Hasta ahora ha funcionado bien.
Los datos estáticos han sido manejados por pilas completamente separadas (y algo "orgánicamente" cultivadas), incluyendo el uso de S3, Akamai, Apache e IIS, de varias maneras.
Apache + mod_wsgi,
Simple, limpio. (solo cuatro líneas de configuración del servidor web), fácil para otros administradores de sistemas.
Me encantaría que me aburre con detalles sobre qué y por qué, cosas específicas de la aplicación, etc.
Ho. ¡Bueno, lo pediste!
Al igual que Daniel, yo personalmente uso Apache con mod_wsgi. Todavía es lo suficientemente nuevo como para desplegarlo en algunos entornos, lo que puede ser complicado, pero si compila todo usted mismo, es bastante fácil. Lo encontré muy confiable, incluso las primeras versiones. Apoyos a Graham Dumpleton por mantener el control de él solo.
Sin embargo, para mí es esencial que las aplicaciones WSGI funcionen en todos los servidores posibles. Hay un agujero en este momento: tienes el estándar WSGI que te dice qué hace una aplicación invocable de WSGI (aplicación), pero no hay una estandarización de implementación; no hay una sola forma de decirle al servidor web dónde encontrar la aplicación. Tampoco hay una forma estandarizada de hacer que el servidor vuelva a cargar la aplicación cuando la haya actualizado.
El enfoque que he adoptado es poner:
toda la lógica de la aplicación en módulos / paquetes, preferiblemente en clases
todas las personalizaciones específicas del sitio web que se realizarán mediante subclases de la Aplicación principal y los miembros primordiales
todas las configuraciones de implementación específicas del servidor (por ejemplo, fábrica de conexión de base de datos, configuración de retransmisión de correo) como parámetros de clase __init __ ()
una secuencia de comandos ''application.py'' de alto nivel que inicializa la clase de la Aplicación con la configuración de implementación correcta para el servidor actual, luego ejecuta la aplicación de tal manera que pueda funcionar implementada como una secuencia de comandos CGI, un WSGIScriptAlias mod_wsgi (o Pasajero, que aparentemente funciona de la misma manera), o se puede interactuar desde la línea de comando
un módulo auxiliar que se ocupa de los problemas de implementación anteriores y permite que la aplicación se vuelva a cargar cuando los módulos de la aplicación se basan en el cambio
Entonces, ¿cómo se ve la aplicación.py al final es algo así como:
#!/usr/bin/env python
import os.path
basedir= os.path.dirname(__file__)
import MySQLdb
def dbfactory():
return MySQLdb.connect(db= ''myappdb'', unix_socket= ''/var/mysql/socket'', user= ''u'', passwd= ''p'')
def appfactory():
import myapplication
return myapplication.Application(basedir, dbfactory, debug= False)
import wsgiwrap
ismain= __name__==''__main__''
libdir= os.path.join(basedir, ''system'', ''lib'')
application= wsgiwrap.Wrapper(appfactory, libdir, 10, ismain)
El wsgiwrap.Wrapper comprueba cada 10 segundos para ver si alguno de los módulos de aplicación en libdir se han actualizado, y si es así, algunos desagradables sys.modules mágicos para descargarlos de forma confiable. A continuación, se volverá a llamar a appfactory () para obtener una nueva instancia de la aplicación actualizada.
(También puede usar herramientas de línea de comandos como
./application.py setup
./application.py daemon
para ejecutar cualquier configuración y tareas de fondo de los ganchos proporcionados por la aplicación invocable, un poco como funciona distutils. También responde para iniciar / detener / reiniciar como un guión de inicio).
Otro truco que uso es colocar la configuración de implementación para varios servidores (desarrollo / prueba / producción) en el mismo script application.py, y olfatear ''socket.gethostname ()'' para decidir qué grupo de configuraciones específicas del servidor usar.
En algún momento podría empaquetar wsgiwrap y liberarlo adecuadamente (posiblemente con un nombre diferente). Mientras tanto, si está interesado, puede ver una versión de desarrollo de alimentos para perros en http://www.doxdesk.com/file/software/py/v/wsgiwrap-0.5.py .
Lo más fácil de implementar es CherryPy. Su aplicación web también puede convertirse en un servidor web independiente. CherryPy es también un servidor bastante rápido teniendo en cuenta que está escrito en Python puro. Dicho esto, no es Apache. Por lo tanto, me parece que CherryPy es una buena opción para webapps de menor volumen.
Aparte de eso, no creo que haya una respuesta correcta o incorrecta a esta pregunta. Muchos de los sitios web de gran volumen se han basado en las tecnologías de las que hablas, y no creo que puedas equivocarte en ninguna de esas formas (aunque diré que estoy de acuerdo con que mod-wsgi no esté a la altura de cada servidor no apache).
Además, he estado usando isapi_wsgi para implementar aplicaciones de python bajo IIS. Es una configuración menos que ideal, pero funciona y no siempre puedes elegir lo contrario cuando vives en un mundo centrado en Windows.
TurboGears (2.0)
TurboGears 2.0 dejará Beta el próximo mes (ha estado en él durante mucho tiempo). 2.0 mejora la serie 1.0 e intenta darle la mejor pila de WSGI, por lo que realiza algunas elecciones predeterminadas para usted, si quiere el menor alboroto.
tiene las herramientas tg* para probar e implementar en la serie 1.x, pero ahora se transformó en equivalentes de paster en series 2.0, lo que parece familiar si has experimentado con pylons .
tg-admin quickstart —> paster quickstart tg-admin info —> paster tginfo tg-admin toolbox –> paster toolbox tg-admin shell –> paster shell tg-admin sql create –> paster setup-app development.ini
Pilones
Si desea ser más flexible en su stack de WSGI (elección de ORM, elección de templater, elección de configuración), Pylons se está convirtiendo en la opción consolidada. Esta sería mi elección recomendada , ya que ofrece una excelente documentación y le permite experimentar con diferentes componentes.
Es un placer trabajar con él como resultado, y funciona bajo Apache (implementación de producción) o independiente (útil para pruebas y experimentación).
lo que sigue es que puedes hacer ambas cosas con Pylons:
2 opciones para la etapa de prueba (
pythonindependiente)4 para fines de producción escalable (
FastCGI, suponiendo que la base de datos que elija pueda mantener el ritmo)
La interfaz de administración de Pylons es muy similar a TurboGears. Aquí hay un ejemplo independiente de juguetes:
$ paster create -t pylons helloworld $ cd helloworld $ paster serve --reload development.ini
para la implementación de la clase de producción, puede consultar la guía de configuración de Apache + FastCGI + mod_rewrite disponible aquí . esto se ampliaría a la mayoría de las necesidades.
Nginx reverse proxy y el intercambio de archivos estáticos + XSendfile + uploadprogress_module. Nada lo supera para el propósito.
En el lado de WSGI, ya sea Apache + mod_wsgi o servidor cherrypy. Me gusta usar el servidor de wsgi cherrypy para aplicaciones en servidores con menos memoria y menos solicitudes.
Razonamiento:
He hecho benchmarks con diferentes herramientas para diferentes soluciones populares.
Tengo más experiencia con TCP / IP de menor nivel que con el desarrollo web, especialmente las implementaciones de http. Estoy más seguro de poder reconocer un buen servidor http de lo que puedo reconocer un buen marco web.
Sé Twisted mucho más que Django o Pylons. La pila http en Twisted todavía no está a la altura de esto, pero estará allí.