Pour des raisons indépendantes de ma volonté, notre site Web est hébergé chez un hébergeur qui utilise IIS pour leurs serveurs. Ils proposent actuellement PHP et ASP, ainsi que Python et Perl via des scripts cgi.

Je veux faire une refonte, une réécriture de notre site Web et je veux passer de PHP à une configuration Python / Django. Le fournisseur d'hébergement est ouvert aux suggestions, mais il est clair que "Nous ne savons pas vraiment ce qu'est Python, ni comment cela fonctionne, mais si vous pouvez nous l'expliquer, nous essaierons de vous configurer avec tout ce dont vous avez besoin" .

Cependant, je sais peut-être comment configurer Django dans un environnement d'hébergement partagé sur apache / mod_python, mais je n'ai aucune idée de la façon dont il serait configuré sur IIS, et certainement pas comment il serait configuré pour un environnement d'hébergement partagé. J'ai googlé un peu, mais la plupart des ressources que je trouve supposent que le sysadmin 1) connaît Python / Django et 2) utilise un hébergement IIS dédié pour son site.

Quelqu'un pourrait-il expliquer comment je peux expliquer le processus à mon fournisseur d'hébergement ou me donner des conseils sur de bonnes ressources détaillées que je peux transmettre à mon fournisseur d'hébergement? Gardez à l'esprit que les personnes qui gèrent l'hébergement peuvent savoir "tout" sur IIS, mais n'ont aucune idée de la façon de gérer Python.

Si vous êtes coincé avec IIS, utilisez PyISAPIe au lieu de CGI si vous le pouvez. Les instructions et les liens pour PyISAPIe sont ci-dessous. Votre hébergeur en saura beaucoup plus sur les extensions ISAPI s'il gère IIS que sur Python, et il n'a pas besoin d'en savoir beaucoup sur Python avec PyISAPIe.

UNE MEILLEURE MEILLEURE FAÇON DE FAIRE CELA UTILISE PyISAPIe, UNE EXTENSION ISAPI . PyISAPIe est beaucoup, beaucoup plus rapide que CGI sur IIS7. Ce que cela fait est similaire à mod_python sur Apache. La page d'accueil du projet PyISAPIe contient des instructions pour configurer Django avec WSGI sur PyISAPIe. Cela portera vos performances à des vitesses raisonnables pour un site Web public / à fort trafic.

• http://apps.sourceforge.net/trac/pyisapie/
• http://pypi.python.org/pypi/PyISAPIe/

La configuration de Django dans un IIS + Python via un environnement CGI va être horriblement lente pour toute utilisation en production. Vous ne devez jamais l'utiliser pour un site Web sur lequel vous prévoyez de traiter plus d'une poignée de demandes par minute. Cela vous limite également considérablement dans ce que vous pouvez mettre en cache en mémoire dans le cadre de mise en cache de Django, car le processus de l'application Django est redémarré à chaque nouvelle demande.

Dans un serveur Web sain comme Apache, lighttpd, etc., avec mod_python, l'interpréteur Python exécutant le processus Django reste en mémoire et est initialisé avec chaque nouveau thread de travail Apache qui gère de nombreuses demandes au fil du temps. Cela signifie que Python + Django ne sont pas fermés et redémarrés pour chaque nouvelle demande. Dans une configuration FastCGI, le serveur Web (Apache ou lighttpd par exemple) crée un socket (domaine UNIX ou TCP) sur lequel il communique avec une application FastCGI (votre application Web Django) via le protocole FastCGI. Idem pour les configurations de proxy HTTP (ils parlent HTTP au lieu de FastCGI). Dans un environnement CGI, l'interpréteur Python est appelé qui exécute l'application Django, complètement à nouveau pour chaque demande, de sorte que l'application ne peut pas garder l'état des demandes en mémoire et ne peut pas mettre en cache correctement ailleurs que dans une base de données.

Assez de diatribes, si vous devez utiliser IIS + CGI + Django, voici comment accomplir cette horrible chose horrible: Utilisez le code suivant pour créer votre propre script CGI qui exécute votre application Django (il traduit entre CGI et WSGI). Vous devrez modifier un peu le script pour qu'il pointe vers votre application et votre code Django. Il s'agit du script CGI auquel vous devez transmettre les demandes. Ensuite, vous devez transférer / réécrire toutes les demandes dans votre script CGI ...

Sous IIS6, vous aurez besoin d'un équivalent mod_rewrite comme IISRewrite, qui je pense n'est pas gratuit et est une source fermée. Sous IIS7, Microsoft a finalement inclus un module de réécriture d'URL. La documentation pour cela se trouve ici . Les instructions pour créer des règles de réécriture dans IIS7 sont ici . Vous voudrez tout transmettre à l'URL de base cible à gérer par votre script CGI.

• http://code.djangoproject.com/attachment/ticket/2407/django.cgi
• http://learn.iis.net/page.aspx/460/using-url-rewrite-module/
• http://learn.iis.net/page.aspx/461/creating-rewrite-rules-for-the-url-rewrite-module/
• http://apps.sourceforge.net/trac/pyisapie/
• http://pypi.python.org/pypi/PyISAPIe/

Comment configurer Python sur FastCGI sur IIS

Voici comment configurer Python sur FastCGI IIS 7+ avec ouvre la voie à une configuration DJango décente

... et être capable de connecter un débogueur au processus vous permettant de parcourir votre code Python

Cet exemple n'utilise pas la console de gestion IIS mais répertorie le contenu des fichiers de configuration résultants

Étape 1

Installez Python + un bon débogueur (cet exemple utilise WingIDE dont j'ai trouvé un excellent outil) Cet exemple suppose que le dossier c: \ python27

Étape 2

Créez un dossier Web, par exemple sur localhost c: \ inetpub \ wwwroot \ mypythonfolder et placez-y le fichier web.config suivant:

Notez le | caractère de canal dans la directive scriptProcessor. Il est utilisé par IIS pour mapper le script à une application fastCgi (étape 3). Il doit correspondre caractère par caractère aux paramètres de chemin complet + caractère de canal + arguments de l'étape 3 ci-dessous.

Étape 3

Dans le fichier applicationHost.config du dossier c: \ windows \ system32 \ inetsrc \ config, placez ce qui suit dans la section:

    <fastCgi>
        <application fullPath="c:\python27\python.exe" arguments="c:\python27\lib\mylib\myfcgi.py" monitorChangesTo="C:\Python27\Lib\r4a\r4afcgi.py" stderrMode="ReturnStdErrIn500" maxInstances="4" idleTimeout="300" activityTimeout="300" requestTimeout="90" instanceMaxRequests="200" protocol="NamedPipe" queueLength="1000" flushNamedPipe="true" rapidFailsPerMinute="10" />
    </fastCgi>

Étape 4

Dans c: \ python27 \ lib \ mylib \ myfcgi.py mettez le code suivant:

import wingdbstub

importer os, io, sys ret = "environnement: \ r \ n" pour param dans os.environ.keys (): ret = ret + "% s =% s \ r \ n"% (param, os.environ [ param]) ret = ret + "\ r \ nArgs:" pour arg dans sys.argv: ret = ret + arg handle = io.open ("c: \ temp \ myfcgi.log", 'wb') handle.write (ret) handle.close ()

Étape 5

Assurez-vous que l'IUSR a le droit d'écrire dans votre dossier c: \ temp

Étape 6

Placez wingdbstub.py et wingdebugpw dans votre dossier c: \ python27 \ lib \ mylib \. Cela permettra le débogage dans wingide. Ces fichiers sont fournis avec l'installation de votre aile. Remarque: si Python doit également compiler votre code dans wingstub.pyc, IUSR a besoin des droits d'écriture sur ce dossier car le processus python sera lancé sous ce compte par IIS

Étape 6

Ouvrez wingdb et définissez un point d'arrêt sur la ligne 'import os, io, sys'

Étape 7

Frappez dans votre navigateur http: // localhost / mypythonfolder

Si tout fonctionne correctement, wingide devrait maintenant être déclenché pour afficher le code en cours d'exécution à votre point d'arrêt. Sinon: - soit il y a un problème de pare-feu. Le processus python communique avec l'interface WingIDE via une connexion TCP - ou il y a un problème de sécurité au sein de Wingide. Il a besoin de la version appropriée du fichier wingdebugpw, qui contient essentiellement un mot de passe ou un jeton qui valide l'accès par rapport à votre installation wingide. Si ce n'était pas le cas, toute personne ayant un accès TCP à votre PC pourrait déboguer contre votre code.

Étape 8

Vérifiez que dans c: \ temp le fichier journal est créé. Cela devrait également fonctionner si vous ne pouvez pas démarrer l'étape 7

Étape 9

Notez que cette page déclenche le débogueur mais ne renvoie aucune page au navigateur Web. Quelques informations de base: le serveur Web communique fastcgi via ce que l'on appelle des «enregistrements». Cela signifie que chaque demande utilisateur unique entre dans votre application, emballée dans plusieurs «enregistrements» distincts. Chaque enregistrement est une structure de données qui indique le début d'une demande, la chaîne de requête, les variables poste , etc. Le non-emballage de ces enregistrements à une seule demande est un peu encombrant, il suit la spécification FastCGI de http: //www.fastcgi .com / devkit / doc / fcgi-spec.html # S1

Comme le contenu de c: \ python27 \ lib \ mylib \ myfcgi.py, je viens de déposer une copie de zoofcgi.py fournie par helicontech. Ce fichier python est capable de décoder ces enregistrements et de servir une page et est assez intéressant à déboguer. Notez également que helicontech fournit éventuellement une DLL qui se situe entre IIS et et zoofcgi.py mais cette DLL n'est pas strictement nécessaire. Je crois qu'il implémente une version légèrement améliorée et générique de l'implémentation fastcgi fournie par msft. Cependant, lorsque vous utilisez leur dll, lorsque vous souhaitez parcourir votre code, le processus se termine assez rapidement et IIS / la DLL tue votre processus python lorsqu'elle conclut qu'aucune réponse ne revient dans une seconde ou deux.

C'est ça. En principe, la communication entre IIS et votre code python se fait avec des canaux nommés. Vous devriez pouvoir le configurer en utilisant des sockets tcp mais je n'ai pas pu déterminer quel port est utilisé (je crois que le stdin devrait être transformé en le port qui peut ensuite être sélectionné () ed mais je n'ai pas donné cela toute tentative)

Je n'ai pas essayé cela avec Python, mais cela fonctionnait très bien en tant que CGI avec Perl. Les produits d'ActiveState s'intègrent apparemment avec IIS. J'ai eu beaucoup de succès avec ActivePerl. Ils ont également ActivePython qui pourrait (probablement) faire aussi l'affaire. Ensuite, je pense que vous voudriez simplement télécharger Django pour l' installer .

EDIT: Ok, alors supprimez l'intégration apparente avec IIS ... CEPENDANT, voici un article sur la façon d'intégrer dans IIS . Vous pouvez également considérer Iron Python comme votre distribution pour une boîte Windows.

Pour le fournisseur, je doute qu'il ait besoin d'en savoir plus que d'une plate-forme de développement Web comme ASP / ASP.NET et que Python est le langage utilisé pour développer avec.

En ce qui concerne l'installation que je mentionne ci-dessus, je vais essayer cela et voir comment cela se passe. Je posterai des notes dessus si je le fais fonctionner ok!