¿Cómo implementa USTED su aplicación WSGI?(y por qué es la mejor manera)

StackOverflow https://stackoverflow.com/questions/574068

  •  05-09-2019
  •  | 
  •  

Pregunta

Implementación de una aplicación WSGI.Hay muchas formas de despellejar a este gato.Actualmente estoy usando apache2 con mod-wsgi, pero veo algunos problemas potenciales con esto.

Entonces, ¿cómo se puede hacer?

  1. Apache Mod-wsgi (los otros mod-wsgi parecen no valer la pena)
  2. Servidor web Python puro, por ejemplo, pegar, cherrypy, Spawning, Twisted.web
  3. como 2 pero con proxy inverso de nginx, apache2, etc., con buen manejo de archivos estáticos
  4. Conversión a otro protocolo como FCGI con puente (p. ej. 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.absolutamente lo haría amar que me aburras con detalles sobre el qué y el por qué, cosas específicas de la aplicación, etc.Votaré a favor de cualquier respuesta que no sea una locura.

¿Fue útil?

Solución

Como siempre: Depende; -)

Cuando no necesito ningún características de Apache que voy con un servidor web pitón puro como la pasta, etc. ¿Cuál es exactamente depende de su aplicación y supongo que puede ser decidido por hacer algunos puntos de referencia. Siempre quise hacer algo, pero nunca llegó a ella. Supongo desove podría tener algunas ventajas en el uso de no bloqueo IO fuera de la caja, pero a veces tenía problemas con él debido a la parcheo que está haciendo.

Usted está siempre libre para poner un barniz en frente, así, por supuesto.

Si se requiere un Apache que estoy por lo general iba con una solución de 3 para que pueda mantener los procesos por separado. También puede mover más fácilmente los procesos a otros servidores etc. Simplemente gusta mantener las cosas separadas.

Para los archivos estáticos que estoy usando en este momento un servidor separado para un proyecto que simplemente sirve imágenes / CSS / JS estáticas. Estoy usando lighttpd como servidor web que tiene un gran rendimiento (en este caso no tengo un barniz delante más).

Otra herramienta útil es supervisord para el control y el seguimiento de estos servicios.

Estoy utilizando adicionalmente buildout para la gestión de mis despliegues y cajas de arena de desarrollo (junto con < a href = "http://pypi.python.org/pypi/virtualenv" rel = "noreferrer"> virtualenv ).

Otros consejos

Me encantaría que me aburrieras con detalles sobre el qué y el por qué, aspectos específicos de la aplicación, etc.

Ho.¡Pues tú lo pediste!

Al igual que Daniel, yo personalmente uso Apache con mod_wsgi.Todavía es lo suficientemente nuevo como para que implementarlo en algunos entornos pueda ser complicado, pero si compilas todo tú mismo de todos modos, es bastante fácil.Lo encontré muy confiable, incluso las primeras versiones.Felicitaciones a Graham Dumpleton por mantener el control prácticamente solo.

Sin embargo, para mí es esencial que las aplicaciones WSGI funcionen en todos los servidores posibles.Hay un pequeño agujero en este momento en esta área:tiene el estándar WSGI que le indica qué hace una (aplicación) invocable WSGI, pero no existe una estandarización de implementación;No hay una única forma de decirle al servidor web dónde encontrar la aplicación.Tampoco existe una forma estandarizada de hacer que el servidor recargue 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 se deben realizar subclasificando la aplicación principal y anulando miembros

  • todas las configuraciones de implementación específicas del servidor (p. ej.fábrica de conexiones de base de datos, configuración de retransmisión de correo) como parámetros de clase __init__()

  • un script 'application.py' de nivel superior que inicializa la clase 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 un script CGI, un mod_wsgi WSGIScriptAlias ​​(o Passenger, que aparentemente funciona de la misma manera), o se puede interactuar con él 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 recargue cuando los módulos en los que se basa la aplicación cambian

Entonces, el aspecto final de application.py es algo 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 verifica cada 10 segundos para ver si alguno de los módulos de la aplicación en libdir se ha actualizado y, de ser así, realiza alguna desagradable magia sys.modules para descargarlos todos de manera confiable.Luego, se llamará nuevamente a appfactory() para obtener una nueva instancia de la aplicación actualizada.

(También puede utilizar herramientas de línea de comandos como

./application.py setup
./application.py daemon

para ejecutar cualquier enlace de configuración y tareas en segundo plano proporcionado por la aplicación invocable, un poco como funciona distutils.También responde al inicio/detención/reinicio como un script de inicio).

Otro truco que uso es colocar la configuración de implementación para múltiples servidores (desarrollo/pruebas/producción) en el mismo script application.py y olfatear 'socket.gethostname()' para decidir qué conjunto de configuraciones específicas del servidor usar.

En algún momento podría empaquetar wsgiwrap y publicarlo correctamente (posiblemente con un nombre diferente).Mientras tanto, si estás interesado, puedes ver una versión de desarrollo de prueba interna en http://www.doxdesk.com/file/software/py/v/wsgiwrap-0.5.py.

La absoluta 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 aplicaciones web de menor volumen.

Aparte de eso, no creo que haya ninguna respuesta correcta o incorrecta a esta pregunta. Un montón de sitios web de alto volumen se han construido en las tecnologías de las que hablas, y no creo que se puede ir demasiado malo cualquiera de esas formas (aunque he de decir que estoy de acuerdo con mod-WSGI no siendo hasta el tabaco en cada servidor no Apache).

Además, he estado usando isapi_wsgi para desplegar aplicaciones pitón bajo IIS . Se trata de un menor de configuración ideal, pero funciona y que no siempre se consigue elegir de otro modo cuando se vive en un mundo ventanas centradas.

Nginx proxy inverso y el intercambio de archivos estáticos + + XSendfile uploadprogress_module. Nada es mejor para el propósito.

En el lado WSGI ya sea Apache + mod_wsgi o servidor cherrypy. Me gusta usar el servidor wsgi cherrypy para aplicaciones en servidores con menos memoria y menos solicitudes.

Razonamiento:

he hecho con los puntos de referencia diferentes herramientas para diferentes soluciones populares.

Tengo más experiencia con menor nivel de TCP / IP de desarrollo web, especialmente implementaciones http. Estoy más seguro de que puedo reconocer un buen servidor HTTP de lo que puedo reconocer un buen marco web.

Sé Twisted mucho más que Django o los pilones. La pila HTTP en Twisted todavía no está a esto, pero estará allí.

Estoy usando Google App Engine para una aplicación que estoy desarrollando. Se ejecuta aplicaciones WSGI. He aquí un par de bits de información sobre el mismo.

Esta es la primera aplicación web que he trabajado en realidad, por lo que no tienen una base de comparación, pero si eres un fan de Google, es posible que desee buscar en ella. He tenido un montón de diversión usarlo como mi marco de referencia para el aprendizaje.

TurboGears (2.0)

TurboGears 2.0 se está yendo Beta dentro del próximo mes (ha estado en esto durante mucho tiempo).2.0 mejora la serie 1.0 e intenta brindarle la mejor pila WSGI de su clase, por lo que toma algunas decisiones predeterminadas para usted, si desea el menor problema.

tiene el tg* herramientas para pruebas e implementación en la serie 1.x, pero ahora transformadas a paster equivalentes en la serie 2.0, que deberían resultarle familiares si ha 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 pila WSGI (elección de ORM, elección de plantilla, elección de forma), Pylons se está convirtiendo en la opción consolidada.Esto sería mi elección recomendada, ya que ofrece excelente documentación y permite experimentar con diferentes componentes.

Como resultado, es un placer trabajar con él y funciona bajo Apache (implementación de producción) o de forma independiente (útil para la etapa de prueba y experimentación).

Por lo tanto, puedes hacer ambas cosas con Pylons:

  • 2 opciones para la etapa de prueba (python ser único)

  • 4 para fines de producción escalable (FastCGI, suponiendo que la base de datos que elija pueda mantenerse al día)

La interfaz de administración de Pylons es muy similar a la de TurboGears.aquí hay un juguete ser único ejemplo:

$ paster create -t pylons helloworld
$ cd helloworld
$ paster serve --reload development.ini

para una implementación de clase de producción, puede consultar la guía de configuración de Apache + FastCGI + mod_rewrite está disponible aquí.esto se ampliaría a la mayoría de las necesidades.

Apache httpd + mod_fcgid usando web.py (que es una aplicación wsgi).

Funciona como un encanto.

Estamos utilizando pasta pura para algunos de nuestros servicios web. Es fácil de implementar (con nuestro mecanismo de implementación interna; no estamos con pasta implementar o algo por el estilo) y es agradable para minimizar la diferencia entre los sistemas de producción y Lo que se ejecutan en estaciones de trabajo de los desarrolladores. Advertencia: no esperamos una baja latencia de pasta en sí debido a la naturaleza de peso pesado de nuestras peticiones. En algunos evaluación comparativa crudo que hicimos que no íbamos a fantásticas resultados; que sólo terminó siendo discutible debido a costa de nuestro controlador de solicitudes típico. Hasta ahora ha funcionado bien.

Los datos estáticos se ha manejado por completamente separado (y algo "orgánicamente" adulto) pilas, incluyendo el uso de S3, Akamai, Apache y IIS, de diversas maneras.

Apache + mod_wsgi,

simple, limpia. (Sólo cuatro líneas de configuración de servidor web), fácil para otros sysadimns para conseguir su cabeza alrededor.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top