Comment les frameworks Web Python, WSGI et CGI s'harmonisent

Question

J'ai un compte Bluehost où je peux exécuter des scripts Python en tant que CGI. Je suppose que c’est l’interface CGI la plus simple, car pour exécuter, je dois définir les éléments suivants dans .htaccess :

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

Maintenant, chaque fois que je regarde la programmation Web avec Python, j'entends beaucoup parler de WSGI et de son utilisation par la plupart des frameworks. Mais je ne comprends tout simplement pas comment tout cela fonctionne, en particulier lorsque mon serveur Web est fourni (Apache s'exécutant sur la machine d'un hôte) et pas quelque chose avec lequel je peux vraiment jouer (à l'exception de la définition des commandes .htaccess ) .

Comment WSGI , CGI et les cadres sont-ils tous connectés? Que dois-je savoir, installer et faire si je veux exécuter un framework Web ( web.py ou < un href = "http://en.wikipedia.org/wiki/CherryPy" rel = "noreferrer"> CherryPy ) sur ma configuration de base CGI? Comment installer le support WSGI?

Answer 1

Comment WSGI, CGI et les frameworks sont-ils tous connectés?

Apache écoute sur le port 80. Il reçoit une requête HTTP. Il analyse la demande pour trouver un moyen de répondre. Apache a beaucoup de choix pour répondre. Une façon de répondre consiste à utiliser CGI pour exécuter un script. Une autre façon de répondre est simplement de servir un fichier.

Dans le cas de CGI, Apache prépare un environnement et appelle le script via le protocole CGI. Il s’agit d’une situation Unix Fork / Exec standard: le sous-processus CGI hérite d’un environnement de système d’exploitation comprenant le socket et la sortie standard. Le sous-processus CGI écrit une réponse, qui retourne à Apache. Apache envoie cette réponse au navigateur.

CGI est primitif et ennuyeux. Principalement parce qu'il crée un sous-processus pour chaque demande et qu'il doit quitter ou fermer stdout et stderr pour indiquer la fin de la réponse.

WSGI est une interface basée sur le modèle de conception CGI. Ce n'est pas nécessairement CGI - il n'est pas nécessaire de créer un sous-processus pour chaque demande. Ce peut être du CGI, mais ce n’est pas obligatoire.

WSGI ajoute au modèle de conception CGI de plusieurs manières importantes. Il analyse les en-têtes de demande HTTP pour vous et les ajoute à l'environnement. Il fournit toute entrée orientée POST sous forme d'objet de type fichier dans l'environnement. Il vous fournit également une fonction qui formulera la réponse, vous évitant beaucoup de détails de formatage.

Que dois-je savoir / installer / faire si je veux exécuter un framework Web (par exemple web.py ou cherrypy) sur ma configuration CGI de base?

Rappelez-vous que la duplication d'un sous-processus coûte cher Il existe deux manières de contourner ce problème.

1. Embarqué mod_wsgi ou mod_python intègre Python dans Apache; aucun processus n'est déclenché. Apache exécute directement l'application Django.

2. Démon mod_wsgi ou mod_fastcgi permet à Apache d'interagir avec un démon distinct (ou "processus de longue durée"), en utilisant le protocole WSGI. Vous démarrez votre processus Django de longue durée, puis vous configurez le mod_fastcgi d'Apache pour communiquer avec ce processus.

Notez que mod_wsgi peut fonctionner en mode: incorporé ou démon.

En lisant le texte sur mod_fastcgi, vous verrez que Django utilise flup pour créer une interface compatible avec WSGI à partir des informations fournies par mod_fastcgi. Le pipeline fonctionne comme ceci.

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

Django a plusieurs "django.core.handlers". pour les différentes interfaces.

Pour mod_fastcgi, Django fournit un manage.py runfcgi qui intègre FLUP et le gestionnaire.

Pour mod_wsgi, il existe un gestionnaire de base pour cela.

Comment installer le support WSGI?

Suivez ces instructions.

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

Pour le fond voir ceci

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

Answer 2

Je pense que la réponse de Florian répond à la partie de votre question sur "Qu'est-ce que WSGI", surtout si vous lisez la PEP .

En ce qui concerne les questions que vous posez vers la fin:

WSGI, CGI, FastCGI, etc. sont tous des protocoles permettant à un serveur Web d’exécuter le code d’exécution , et de fournir le contenu dynamique généré. Comparez cela au service Web statique, où un fichier HTML brut est essentiellement livré tel quel au client.

CGI, FastCGI et SCGI ne dépendent pas du langage. Vous pouvez écrire des scripts CGI en Perl, Python, C, bash, peu importe. CGI définit quel exécutable sera appelé, en fonction de l'URL, et comment il sera appelé: les arguments et l'environnement. Il définit également comment la valeur de retour doit être renvoyée au serveur Web une fois que votre exécutable est terminé. Les variations sont essentiellement des optimisations permettant de traiter plus de demandes, de réduire les temps de latence, etc. le concept de base est le même.

WSGI est uniquement en Python. Au lieu d'un protocole indépendant du langage, une signature de fonction standard est définie:

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

Il s'agit d'une application WSGI complète (si limitée). Un serveur Web prenant en charge WSGI (tel que Apache avec mod_wsgi) peut appeler cette fonction chaque fois qu'une demande arrive.

La raison en est que nous pouvons éviter la tâche fastidieuse de convertir un fichier HTTP GET / POST vers un fichier CGI vers un fichier Python, et inversement à la sortie. C'est un lien beaucoup plus direct, propre et efficace.

Il est également beaucoup plus facile d’avoir des infrastructures de longue durée fonctionnant derrière des serveurs Web, si tout ce qui doit être fait pour une demande est un appel de fonction. Avec de simples CGI, il vous faudrait démarrer tout votre framework pour chaque requête individuelle.

Pour bénéficier du support WSGI, vous devez avoir installé un module WSGI (du type mod_wsgi ) ou utilisez un serveur Web avec WSGI cuit (comme CherryPy ). Si aucune de ces solutions n’est possible, vous pouvez utiliser le pont CGI-WSGI indiqué dans le PEP.

Answer 3

Vous pouvez exécuter WSGI sur CGI comme le montre Pep333. à titre d'exemple. Cependant, chaque fois qu'il y a une demande, un nouvel interpréteur Python est démarré et tout le contexte (connexions à la base de données, etc.) doit être créé, ce qui prend du temps.

Si vous voulez exécuter WSGI, le mieux serait que votre hôte installe mod_wsgi et fait une configuration appropriée pour reporter le contrôle à une de vos applications.

Flup est un autre moyen de s'exécuter avec WSGI pour tout serveur Web pouvant parler FCGI , SCGI ou AJP. D'après mon expérience, seul FCGI fonctionne réellement et il peut être utilisé dans Apache via mod_fastcgi ou si vous pouvez exécuter un démon Python distinct avec mod_proxy_fcgi .

WSGI est un protocole très semblable à CGI, qui définit un ensemble de règles permettant au serveur Web et au code Python d'interagir. défini comme Pep333 . Cela permet à de nombreux serveurs Web différents d'utiliser de nombreux frameworks et applications utilisant le même protocole d'application. Ceci est très bénéfique et le rend si utile.

Answer 4

Si vous n'êtes pas sûr de tous les termes de cet espace et que vous en avez conscience, c'est un acronyme chargé de acronymes, il y a aussi un bon lecteur d'arrière-plan sous la forme d'un HOWTO python officiel qui traite de CGI vs. FastCGI vs. WSGI et autres: http://docs.python.org/howto/webservers.html

Answer 5

Il s’agit d’une simple couche d’abstraction pour Python, semblable à la spécification Servlet pour Java. Alors que CGI est vraiment de bas niveau et dépose juste des éléments dans l’environnement de processus et les entrées / sorties standard, les deux spécifications ci-dessus modélisent la requête et la réponse http comme des constructions dans le langage. Mon impression est toutefois qu'en Python, les gens ne se sont pas encore décidés pour des implémentations de facto. Vous disposez donc d'une combinaison d'implémentations de références et d'autres bibliothèques de types utilitaires fournissant d'autres fonctionnalités, ainsi que le support WSGI (par exemple, Coller). Bien sûr, je peux me tromper, je suis un nouveau venu dans Python. Le " web scripting " La communauté aborde le problème sous un angle différent (hébergement partagé, héritage CGI, préoccupations relatives à la séparation des privilèges) que les gens de Java avaient le luxe de commencer avec (exécuter un seul conteneur d'entreprise dans un environnement dédié contre du code statique compilé et déployé).