Cómo encajan los frameworks web de Python, WSGI y CGI

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

  •  03-07-2019
  •  | 
  •  

Pregunta

Tengo una cuenta de Bluehost donde puedo ejecutar scripts de Python como CGI. Supongo que es el CGI más simple, porque para ejecutar tengo que definir lo siguiente en .htaccess : 

Options +ExecCGI
AddType text/html py
AddHandler cgi-script .py

Ahora, cada vez que busco programación web con Python, escucho mucho sobre WSGI y cómo la mayoría de los marcos lo usan. Pero simplemente no entiendo cómo encaja todo esto, especialmente cuando mi servidor web recibe (Apache se ejecuta en la máquina de un host) y no es algo con lo que pueda jugar (excepto la definición de los comandos .htaccess ) .

¿Cómo están WSGI , CGI y los marcos de trabajo conectados? ¿Qué necesito saber, instalar y hacer si quiero ejecutar un marco web (por ejemplo, web.py o < a href = "http://en.wikipedia.org/wiki/CherryPy" rel = "noreferrer"> CherryPy ) en mi configuración CGI básica? ¿Cómo instalar el soporte WSGI?

¿Fue útil?

Solución

¿Cómo se conectan WSGI, CGI y los marcos?

Apache escucha en el puerto 80. Obtiene una solicitud HTTP. Analiza la solicitud para encontrar una manera de responder. Apache tiene MUCHAS opciones para responder. Una forma de responder es usar CGI para ejecutar un script. Otra forma de responder es simplemente servir un archivo.

En el caso de CGI, Apache prepara un entorno e invoca el script a través del protocolo CGI. Esta es una situación estándar de Unix Fork / Exec: el subproceso CGI hereda un entorno de sistema operativo que incluye el socket y la salida estándar. El subproceso CGI escribe una respuesta, que se remonta a Apache; Apache envía esta respuesta al navegador.

CGI es primitivo y molesto. Principalmente porque solicita un subproceso para cada solicitud, y el subproceso debe salir o cerrar stdout y stderr para indicar el final de la respuesta.

WSGI es una interfaz que se basa en el patrón de diseño CGI. No es necesariamente CGI, no tiene que bifurcar un subproceso para cada solicitud. Puede ser CGI, pero no tiene que ser.

WSGI se agrega al patrón de diseño CGI de varias maneras importantes. Analiza los encabezados de solicitud HTTP por usted y los agrega al entorno. Proporciona cualquier entrada orientada a POST como un objeto similar a un archivo en el entorno. También le proporciona una función que formulará la respuesta y le ahorrará muchos detalles de formato.

¿Qué necesito saber / instalar / hacer si quiero ejecutar un marco web (por ejemplo, web.py o cherrypy) en mi configuración CGI básica?

Recuerde que forking a subprocess es caro. Hay dos formas de solucionar esto.

  1. Incrustado mod_wsgi o mod_python incrusta Python dentro de Apache; ningún proceso se bifurca Apache ejecuta la aplicación Django directamente.

  2. Daemon mod_wsgi o mod_fastcgi permite que Apache interactúe con un demonio separado (o " proceso de ejecución prolongada "), utilizando el protocolo WSGI. Comienzas tu proceso Django de larga duración, luego configuras el mod_fastcgi de Apache para comunicarse con este proceso.

Tenga en cuenta que mod_wsgi puede funcionar en cualquier modo: incrustado o daemon.

Cuando lea sobre mod_fastcgi, verá que Django usa flup para crear una interfaz compatible con WSGI a partir de la información proporcionada por mod_fastcgi. El oleoducto funciona así. 

Apache -> mod_fastcgi -> FLUP (via FastCGI protocol) -> Django (via WSGI protocol)

Django tiene varios " django.core.handlers " para las diferentes interfaces.

Para mod_fastcgi, Django proporciona un manage.py runfcgi que integra FLUP y el controlador.

Para mod_wsgi, hay un controlador central para esto.

¿Cómo instalar el soporte WSGI?

Sigue estas instrucciones.

https://code.google.com/archive/p/ modwsgi / wikis / IntegrationWithDjango.wiki

Para el fondo, vea esto

http://docs.djangoproject.com/en / dev / howto / deployment / # howto-deployment-index

Otros consejos

Creo que Respuesta de Florian responde a la parte de tu pregunta sobre " ¿qué es WSGI " ;, especialmente si lees el PEP .

En cuanto a las preguntas que plantea hacia el final:

WSGI, CGI, FastCGI, etc., son todos protocolos para que un servidor web ejecute código de ejecución y entregue el contenido dinámico que se produce. Compare esto con el servicio web estático, donde un archivo HTML simple se entrega básicamente como está al cliente.

CGI, FastCGI y SCGI son independientes del lenguaje. Puedes escribir scripts CGI en Perl, Python, C, bash, lo que sea. CGI define a qué se llamará el ejecutable, según la URL, y cómo se llamará: los argumentos y el entorno. También define cómo debe devolverse el valor de retorno al servidor web una vez que el ejecutable haya finalizado. Las variaciones son básicamente optimizaciones para poder manejar más solicitudes, reducir la latencia, etc. El concepto básico es el mismo.

WSGI es solo Python. En lugar de un protocolo independiente del lenguaje, se define una firma de función estándar: 

def simple_app(environ, start_response):
    """Simplest possible application object"""
    status = '200 OK'
    response_headers = [('Content-type','text/plain')]
    start_response(status, response_headers)
    return ['Hello world!\n']

Esa es una aplicación WSGI completa (si está limitada). Un servidor web con soporte WSGI (como Apache con mod_wsgi) puede invocar esta función cada vez que llega una solicitud.

La razón por la que esto es tan bueno es que podemos evitar el paso complicado de convertir de un HTTP GET / POST a CGI a Python, y volver a la salida. Es un enlace mucho más directo, limpio y eficiente.

También hace que sea mucho más fácil tener marcos de trabajo de ejecución prolongada detrás de servidores web, si todo lo que se necesita hacer para una solicitud es una llamada a la función. Con CGI simple, tendría que iniciar todo el marco para cada solicitud individual.

Para tener soporte de WSGI, deberá haber instalado un módulo WSGI (como mod_wsgi ), o use un servidor web con WSGI incorporado (como CherryPy ). Si ninguno de los dos es posible, podría utilizar el puente CGI-WSGI que se proporciona en el PEP.

Puedes ejecutar WSGI sobre CGI como demuestra Pep333 como ejemplo. Sin embargo, cada vez que se realiza una solicitud, se inicia un nuevo intérprete de Python y se debe construir todo el contexto (conexiones de base de datos, etc.) que lleva tiempo.

Lo mejor si desea ejecutar WSGI sería si su host instalara mod_wsgi y realizó una configuración adecuada para diferir el control a una aplicación tuya.

Flup es otra forma de ejecutar con WSGI para cualquier servidor web que pueda hablar FCGI , SCGI o AJP. Desde mi experiencia, solo FCGI realmente funciona, y puede usarse en Apache a través de mod_fastcgi o si puede ejecutar un demonio de Python con mod_proxy_fcgi .

WSGI es un protocolo muy parecido a CGI, que define un conjunto de reglas sobre cómo pueden interactuar el servidor web y el código Python. definido como Pep333 . Hace posible que muchos servidores web diferentes puedan usar muchos marcos y aplicaciones diferentes utilizando el mismo protocolo de aplicación. Esto es muy beneficioso y lo hace muy útil.

Si no está claro en todos los términos en este espacio, y seamos sinceros, es un confuso código cargado de siglas, también hay un buen lector de antecedentes en la forma de un CÓMO de python oficial que analiza CGI vs. FastCGI vs. WSGI y así sucesivamente: http://docs.python.org/howto/webservers.html

Es una capa de abstracción simple para Python, similar a la especificación de Servlet para Java. Mientras que CGI es realmente de bajo nivel y simplemente descarga cosas en el entorno de proceso y entrada / salida estándar, las dos especificaciones anteriores modelan la solicitud y respuesta http como construcciones en el lenguaje. Sin embargo, mi impresión es que en Python la gente no se ha conformado con implementaciones de facto, por lo que tiene una combinación de implementaciones de referencia y otras bibliotecas de tipo de utilidad que proporcionan otras cosas junto con el soporte WSGI (por ejemplo, Pegar). Por supuesto que podría estar equivocado, soy un recién llegado a Python. El " web scripting " La comunidad se enfrenta al problema desde una dirección diferente (alojamiento compartido, legado de CGI, problemas de separación de privilegios) que la gente de Java tuvo el lujo de comenzar con (ejecutar un solo contenedor empresarial en un entorno dedicado contra el código implementado y compilado de forma estática). p>

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