In che modo i framework web Python, WSGI e CGI si integrano

https://stackoverflow.com/questions/219110

03-07-2019
|

Domanda

Ho un Bluehost in cui posso eseguire script Python come CGI. Immagino sia il CGI più semplice, perché per eseguirlo devo definire quanto segue in .htaccess :

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

Ora, ogni volta che cerco la programmazione web con Python, sento molto parlare di WSGI e di come la maggior parte dei framework lo usa. Ma non capisco come si adatta tutto, soprattutto quando viene fornito il mio server Web (Apache in esecuzione su una macchina host) e non qualcosa con cui posso davvero giocare (tranne definire i comandi .htaccess ) .

Come sono collegati WSGI , CGI e i framework? Che cosa devo sapere, installare e fare se voglio eseguire un framework Web (ad esempio web.py o < a href = "http://en.wikipedia.org/wiki/CherryPy" rel = "noreferrer"> CherryPy ) sulla mia configurazione CGI di base? Come installare il supporto WSGI?

Soluzione

Come sono collegati WSGI, CGI e i framework?

Apache è in ascolto sulla porta 80. Ottiene una richiesta HTTP. Analizza la richiesta per trovare un modo di rispondere. Apache ha MOLTE scelte per rispondere. Un modo di rispondere è utilizzare CGI per eseguire uno script. Un altro modo di rispondere è semplicemente di servire un file.

Nel caso di CGI, Apache prepara un ambiente e invoca lo script tramite il protocollo CGI. Questa è una situazione standard Unix Fork / Exec: il sottoprocesso CGI eredita un ambiente operativo compreso socket e stdout. Il sottoprocesso CGI scrive una risposta, che risale ad Apache; Apache invia questa risposta al browser.

Il CGI è primitivo e fastidioso. Principalmente perché genera un sottoprocesso per ogni richiesta e il sottoprocesso deve uscire o chiudere stdout e stderr per indicare la fine della risposta.

WSGI è un'interfaccia basata sul modello di progettazione CGI. Non è necessariamente CGI - non deve eseguire il fork di un sottoprocesso per ogni richiesta. Può essere CGI, ma non deve essere.

WSGI aggiunge al modello di progettazione CGI in diversi modi importanti. Analizza le intestazioni delle richieste HTTP per te e le aggiunge all'ambiente. Fornisce qualsiasi input orientato al POST come oggetto simile a un file nell'ambiente. Ti fornisce anche una funzione che formulerà la risposta, salvandoti da molti dettagli di formattazione.

Cosa devo sapere / installare / fare se voglio eseguire un framework Web (ad esempio web.py o cherrypy) sulla mia configurazione CGI di base?

Ricorda che il fork di un sottoprocesso è costoso. Esistono due modi per aggirare questo problema.

Incorporato mod_wsgi o mod_python incorpora Python in Apache; nessun processo è biforcuto. Apache esegue direttamente l'applicazione Django.
Demone mod_wsgi o mod_fastcgi consente ad Apache di interagire con un demone separato (o " processo di lunga durata "), utilizzando il protocollo WSGI. Inizi il tuo lungo processo Django, quindi configura il mod_fastcgi di Apache per comunicare con questo processo.

Nota che mod_wsgi può funzionare in entrambe le modalità: incorporato o demone.

Quando leggi su mod_fastcgi, vedrai che Django utilizza flup per creare un'interfaccia compatibile WSGI dalle informazioni fornite da mod_fastcgi. La pipeline funziona in questo modo.

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

Django ha diversi " django.core.handlers " per le varie interfacce.

Per mod_fastcgi, Django fornisce un manage.py runfcgi che integra FLUP e il gestore.

Per mod_wsgi, c'è un gestore principale per questo.

Come installare il supporto WSGI?

Segui queste istruzioni.

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

Per lo sfondo vedi questo

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

Altri suggerimenti

Penso Risposta di Florian risponde alla parte della tua domanda su "cos'è WSGI", specialmente se leggi the PEP .

Per quanto riguarda le domande che poni verso la fine:

WSGI, CGI, FastCGI ecc. sono tutti protocolli per un server Web per eseguire il codice e fornire il contenuto dinamico che viene prodotto. Confrontalo con il servizio web statico, in cui un semplice file HTML viene sostanzialmente consegnato come al client.

CGI, FastCGI e SCGI sono agnostici del linguaggio. Puoi scrivere script CGI in Perl, Python, C, bash, qualunque cosa. CGI definisce quale verrà chiamato eseguibile, in base all'URL, e come verrà chiamato: gli argomenti e l'ambiente. Definisce inoltre come il valore restituito debba essere restituito al server Web al termine dell'eseguibile. Le variazioni sono sostanzialmente ottimizzazioni per essere in grado di gestire più richieste, ridurre la latenza e così via; il concetto di base è lo stesso.

WSGI è solo Python. Piuttosto che un protocollo agnostico di lingua, viene definita una firma di funzione standard:

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']

Questa è un'applicazione WSGI completa (se limitata). Un web server con supporto WSGI (come Apache con mod_wsgi) può invocare questa funzione ogni volta che arriva una richiesta.

La ragione per cui è così grande è che possiamo evitare il passaggio disordinato della conversione da un HTTP GET / POST a CGI in Python, e viceversa. È un collegamento molto più diretto, pulito ed efficiente.

Inoltre, è molto più semplice avere framework di lunga durata in esecuzione dietro server Web, se tutto ciò che deve essere fatto per una richiesta è una chiamata di funzione. Con il semplice CGI, dovresti avviare l'intero framework per ogni singola richiesta.

Per avere il supporto WSGI, devi aver installato un modulo WSGI (come mod_wsgi ) o utilizzare un server Web con WSGI inserito (come CherryPy ). Se nessuno dei due è possibile, potresti utilizzare il bridge CGI-WSGI indicato nel PEP.

Puoi eseguire WSGI su CGI come dimostra Pep333 come esempio. Tuttavia, ogni volta che c'è una richiesta, viene avviato un nuovo interprete Python e l'intero contesto (connessioni al database, ecc.) Deve essere creato, il che richiede tempo.

Il migliore se si desidera eseguire WSGI sarebbe se il proprio host installasse mod_wsgi e fatto una configurazione appropriata per rinviare il controllo a una tua applicazione.

Flup è un altro modo di funzionare con WSGI per qualsiasi server web in grado di parlare FCGI , SCGI o AJP. Dalla mia esperienza, solo FCGI funziona davvero e può essere utilizzato in Apache tramite mod_fastcgi o se puoi eseguire un demone Python separato con mod_proxy_fcgi .

WSGI è un protocollo molto simile a CGI, che definisce un insieme di regole su come possono interagire webserver e codice Python, è definito come Pep333 . Rende possibile che molti server Web diversi possano utilizzare molti framework e applicazioni diversi utilizzando lo stesso protocollo di applicazione. Questo è molto utile e lo rende così utile.

Se non sei chiaro su tutti i termini in questo spazio, e ammettiamolo, è un acerbo confuso carico di acronimi, c'è anche un buon lettore di background sotto forma di un HOWTO ufficiale in pitone che discute CGI vs FastCGI vs. WSGI e così via: http://docs.python.org/howto/webservers.html

È un semplice livello di astrazione per Python, simile a quello che sono le specifiche Servlet per Java. Mentre il CGI è davvero di basso livello e scarica semplicemente le cose nell'ambiente di processo e lo standard in / out, le due specifiche sopra riportate modellano la richiesta e la risposta http come costrutti nel linguaggio. La mia impressione è tuttavia che in Python le persone non si siano ancora orientate sulle implementazioni di fatto, quindi hai un mix di implementazioni di riferimento e altre librerie di tipi di utilità che forniscono altre cose insieme al supporto WSGI (ad esempio Incolla). Certo che potrei sbagliarmi, sono un nuovo arrivato in Python. Il "web scripting" la comunità sta arrivando al problema da una direzione diversa (hosting condiviso, eredità CGI, problemi di separazione dei privilegi) rispetto a quelli che le persone Java avevano il lusso di iniziare (eseguendo un singolo contenitore aziendale in un ambiente dedicato contro codice compilato e distribuito staticamente).

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow