Como explicar a instalação do Django / Python para o Python-newbie executando um servidor IIS compartilhado [fechado]

9

Por motivos fora do meu controle, nosso site é hospedado com um provedor de hospedagem que usa o IIS para seus servidores. Atualmente, eles oferecem PHP e ASP, além de Python e Perl através de cgi-scripts.

Eu quero fazer um re-design, reescrever o nosso site e quero mudar do PHP para uma configuração do Python / Django. O provedor de hospedagem está aberto a sugestões, mas é claro que "Nós realmente não sabemos o que é o Python ou como ele funciona, mas se você puder nos explicar, tentaremos configurá-lo com o que você precisar" .

No entanto, talvez eu saiba como configurar o Django em um ambiente de hospedagem compartilhada no apache / mod_python, mas não tenho idéia de como ele seria configurado no IIS e, certamente, não como ele seria configurado para um ambiente de hospedagem compartilhado. Pesquisei um pouco no Google, mas a maioria dos recursos encontrados presume que o sysadmin 1) conheça Python / Django e 2) esteja usando hospedagem IIS dedicada para seu site.

Alguém poderia explicar como eu posso explicar o processo para o meu provedor de hospedagem ou fornecer-me indicações de bons recursos detalhados que posso encaminhar ao meu provedor de hospedagem? Lembre-se de que as pessoas que executam a hospedagem podem saber "tudo" sobre o IIS, mas não têm idéia de como lidar com o Python.

Epcylon
fonte

Respostas:

8

Se você está preso ao uso do IIS, use PyISAPIe em vez de CGI, se puder. Instruções e links para o PyISAPIe estão abaixo. Seu host saberá muito mais sobre extensões ISAPI se eles gerenciarem o IIS do que sobre Python, e eles não precisam saber muito sobre Python com PyISAPIe.

UMA MANEIRA MELHOR DE FAZER ISSO ESTÁ USANDO PyISAPIe, UMA EXTENSÃO ISAPI . PyISAPIe é muito, muito mais rápido que CGI no IIS7. O que isso faz é semelhante ao mod_python no Apache. A página inicial do projeto PyISAPIe tem instruções para configurar o Django com o WSGI sobre o PyISAPIe. Isso elevará seu desempenho a velocidades razoáveis ​​para um site público / de alto tráfego.

Configurar o Django em um IIS + Python via ambiente CGI será terrivelmente lento para qualquer uso de produção. Você nunca deve usar isso em um site no qual espera atender a mais de um punhado de solicitações por minuto. Ele também limita severamente o que você pode armazenar em cache na memória na estrutura de cache do Django, já que o processo do aplicativo Django é reiniciado a cada nova solicitação.

Em um servidor web sadio como Apache, lighttpd etc. com mod_python, o interpretador Python executando o processo Django permanece na memória e é inicializado com cada novo thread de trabalho do Apache que lida com muitas solicitações ao longo do tempo. Isso significa que o Python + Django não é encerrado e reiniciado para cada nova solicitação. Em uma configuração do FastCGI, o servidor da web (Apache ou lighttpd por exemplo) cria um soquete (domínio UNIX ou TCP) através do qual ele se comunica com um aplicativo FastCGI (seu aplicativo da web Django) através do protocolo FastCGI. O mesmo vale para as configurações de proxy HTTP (eles falam HTTP em vez de FastCGI). Em um ambiente CGI, o interpretador Python é chamado, que executa o aplicativo Django, completamente novo para cada solicitação, para que o aplicativo não possa manter o estado entre solicitações na memória e não pode armazenar em cache adequadamente em qualquer lugar, exceto em um banco de dados.

Bastante reclamação, se você deve usar o IIS + CGI + Django, eis como realizar essa coisa horrível: Use o código a seguir para criar seu próprio script CGI que executa seu aplicativo Django (que se traduz entre CGI e WSGI). Você precisará editar um pouco o script para apontar para o seu aplicativo e código do Django. Esse é o script CGI para o qual você precisaria passar solicitações. Em seguida, é necessário encaminhar / reescrever todas as solicitações no seu script CGI ...

No IIS6, você precisará de um equivalente mod_rewrite como o IISRewrite, que acho que não é gratuito e é de código fechado. No IIS7, a Microsoft finalmente incluiu um módulo de reescrita de URL. A documentação para isso está localizada aqui . As instruções para criar regras de reescrita no IIS7 estão aqui . Você deseja encaminhar tudo no URL base de destino a ser tratado pelo seu script CGI.

user6281
fonte
Como a hospedagem é compartilhada, o principal problema é como o provedor de hospedagem configuraria o PyISAPIe para atender às minhas necessidades e também às diferentes necessidades de seus outros clientes. Não consegui encontrar as instruções para configurar o Django com o WSGI na página inicial ... Se tudo mais falhar, vou usar a abordagem CGI. Com menos de 400 solicitações por semana , acho que podemos viver com a solução CGI até decidirmos mudar de hospedagem.
Epcylon
1

Como configurar o Python no FastCGI no IIS

Veja como configurar o Python no FastCGI IIS 7+ com abre caminho para uma instalação decente do DJango

... e poder conectar um depurador ao processo, permitindo que você percorra seu código Python

Este exemplo não usa o console de gerenciamento do IIS, mas lista o conteúdo dos arquivos de configuração resultantes

Passo 1

Instale o Python + um bom depurador (este exemplo usa o WingIDE, que achei uma excelente ferramenta) Este exemplo assume a pasta c: \ python27

Passo 2

Crie uma pasta da web, por exemplo, em localhost c: \ inetpub \ wwwroot \ mypythonfolder e coloque o seguinte arquivo web.config nela:

Observe o | caractere de pipe na diretiva scriptProcessor. Isso é usado pelo IIS para mapear o script para um aplicativo fastCgi (etapa 3). Ele deve corresponder caractere por caractere às configurações de caminho completo + caractere de pipe + argumentos da etapa 3 abaixo.

etapa 3

No arquivo applicationHost.config na pasta c: \ windows \ system32 \ inetsrc \ config, coloque o seguinte na seção:

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

Passo 4

Em c: \ python27 \ lib \ mylib \ myfcgi.py, coloque o seguinte código:

import wingdbstub

importar os, io, sys ret = "ambiente: \ r \ n" para param em os.environ.keys (): ret = ret + "% s =% s \ r \ n"% (param, os.environ [ param]) ret = ret + "\ r \ nArgs:" para arg em sys.argv: ret = ret + arg manipula = io.open ("c: \ temp \ myfcgi.log", 'wb') handle.write (ret) handle.close ()

Etapa 5

Verifique se o IUSR tem direitos para gravar na sua pasta c: \ temp

Etapa 6

Coloque wingdbstub.py e wingdebugpw na sua pasta c: \ python27 \ lib \ mylib \. Isso permitirá a depuração no wingide. Esses arquivos são fornecidos com a instalação do seu wing. Nota: se o Python também precisar compilar seu código no wingstub.pyc, o IUSR precisará de direitos de gravação nessa pasta, pois o processo python será iniciado sob essa conta pelo IIS

Etapa 6

Abra o wingdb e defina um ponto de interrupção na linha 'import os, io, sys'

Etapa 7

Clique no seu navegador http: // localhost / mypythonfolder

Se tudo funcionar corretamente, o wingide agora deve ser acionado para exibir o código em execução no seu ponto de interrupção. Caso contrário: - ou há um problema de firewall. O processo python se comunica com a interface WingIDE através de uma conexão tcp - ou há um problema com a segurança dentro do wingide. Ele precisa da versão correta do arquivo wingdebugpw, que basicamente contém uma senha ou token que valida o acesso à sua instalação lateral. Se não fosse esse o caso, qualquer pessoa com acesso tcp ao seu PC poderia depurar seu código.

Etapa 8

Verifique se em c: \ temp o arquivo de log foi criado. Isso também deve funcionar se você não conseguir dar o passo 7

Etapa 9

Observe que esta página aciona o depurador, mas não retorna nenhuma página ao navegador da web. Alguns antecedentes: o servidor da web comunica o fastcgi através dos chamados 'registros'. Isso significa que cada solicitação de usuário entra em seu aplicativo compactado em vários 'registros' separados. Cada registro é uma estrutura de dados que indica o início de uma solicitação, a string de consulta, as variáveis ​​de postagem etc. A descompactação desses registros em uma única solicitação é meio complicada, segue a especificação fastcgi de http: //www.fastcgi .com / devkit / doc / fcgi-spec.html # S1

Como o conteúdo de c: \ python27 \ lib \ mylib \ myfcgi.py, acabei de inserir uma cópia do zoofcgi.py fornecida pela helicontech. Este arquivo python é capaz de decodificar esses registros e servir uma página e é bastante interessante para depurar. Observe também que o helicontech opcionalmente fornece uma dll que fica entre o IIS e o zoofcgi.py, mas essa dll não é estritamente necessária. Eu acredito que implementa uma versão genérica e ligeiramente melhorada da implementação fastcgi que o msft fornece. No entanto, quando você usa a dll deles, quando você deseja percorrer seu código, o processo é finalizado de maneira bastante rápida e o IIS / DLL mata o processo python quando conclui que nenhuma resposta está voltando dentro de um segundo ou 2.

É isso aí. Em princípio, a comunicação entre o IIS e seu código python é feita com pipes nomeados. Você deve ser capaz de configurá-lo usando soquetes tcp, mas não consegui descobrir qual porta é usada (acredito que o stdin deve ser transformado na porta que pode ser selecionada (), mas não dei isso qualquer tentativa)

Robert van Geel
fonte
0

Eu não tentei isso com Python, mas funcionou muito bem como CGI com Perl. Os produtos da ActiveState se integram aparentemente ao IIS. Eu tive um grande sucesso com o ActivePerl. Eles também têm o ActivePython, que pode (provavelmente) também resolver o problema. Então eu acho que você faria o download do Django para instalá-lo .

EDIT: Ok, então raspe a integração sem aparência com o IIS ... NO ENTANTO, aqui está um artigo sobre como integrar no IIS . Você também pode considerar o Iron Python como sua distribuição para uma caixa do Windows.

Para o provedor, eu duvido que eles precisem saber mais do que uma plataforma de desenvolvimento web como o ASP / ASP.NET e que Python é a linguagem usada para desenvolver com ele.

Quanto à instalação mencionada acima, vou tentar isso e ver como se sai. Vou postar anotações se eu estiver funcionando bem!

squillman
fonte