.. .. META INFORMATION OF TRANSLATION .. .. $TranslationStatus: In Progress $ .. $OriginalRevision: 15028 $ .. $TranslationAuthors: Walter Cruz $ .. .. INFO OF THIS FILE (DO NOT EDIT! UPDATED BY SUBVERSION) .. .. $HeadURL$ .. $LastChangedRevision$ .. $LastChangedBy$ .. $LastChangedDate$ .. ============================================ Como usar o Django com o Apache e mod_python ============================================ .. warning:: Support for mod_python has been deprecated, and will be removed in Django 1.5. If you are configuring a new deployment, you are strongly encouraged to consider using :doc:`mod_wsgi ` or any of the other :doc:`supported backends `. .. highlight:: apache O módulo `mod_python`_ para o Apache_ pode ser usado para fazer a implantação do Django em um servidor de produção, embora ele tenha sido praticamente superado pela opção mais simples :doc:`implantação com mod_wsgi `. O mod_python é semelhante (e inspirado) ao `mod_perl`_ : Ele embute o Python dentro do Apache e carrega o código Python na memória quando o servidor inicia. o Código fica na memória durante o tempo de vida do processo Apache, que leva a ganhos de performance significantes sobre outras opções de disposição de servidor. O Django requer o Apache 2.x e o mod_python 3.x, e você deve usar o `MPM prefork`_, ao invés do `MPM worker`_. .. seealso:: * O apache é um animal grande e complexo, e esse documento dá apenas um panorama do que o Apache é capaz de fazer. Se você precisa de informação mais avançado sobre o Apache, não há fonte de informação melhor que `a própria documentação oficial do Apache`_ * Você pode também estar interessado em :doc:`Como usar o Django com FastCGI, SCGI ou AJP `. .. _Apache: http://httpd.apache.org/ .. _mod_python: http://www.modpython.org/ .. _mod_perl: http://perl.apache.org/ .. _MPM prefork: http://httpd.apache.org/docs/2.2/mod/prefork.html .. _MPM worker: http://httpd.apache.org/docs/2.2/mod/worker.html .. _a própria documentação oficial do Apache: http://httpd.apache.org/docs/ Configuração Básica =================== Para configurar o Django com o mod_python, verifique primeiro se você tem o Apache instalado, Com o módulo mod_python ativado. Edite o arquivo ``httpd.conf`` e adicione o seguinte:: SetHandler python-program PythonHandler django.core.handlers.modpython SetEnv DJANGO_SETTINGS_MODULE mysite.settings PythonOption django.root /mysite PythonDebug On ...e substitua o ``mysite.settings`` com o caminho de importação do Python para o seu arquivo de configuração do projeto Django. Isso diz ao Apache: "Use o mod_python para qualquer URL em ou sobre '/mysite/', usando o handler do mod_python do Django." Ele passa o valor do :ref:`DJANGO_SETTINGS_MODULE ` para que o mod_python saiba quais configurações usar. Como o mod_python não sabe que estamos servido esse site a partir do prefixo ``/mysite/``, esse valor precisa ser passado para o Django através do manipulador do mod_python, pela linha ``PythonOption django.root ...``. O valor configurado nessa linha (o último item) deve ser igual ao texto informado na diretiva ````. O efeito disso é que o Django irá automaticamente remover a string ``/mysite`` no início de quaisquer URLs antes de fazer a verificação deles com os seus padrões em ``URLConf``. Se você depois mudar o seu site para um endereço como ``/mysite2``, você não irá precisar alterar nada, exceto a opção ``django.root`` no arquivo de configuração. Ao usar o ``django.root`` você deve assegurar-se que o que resta, após a remoção do prefixo, inicie com uma barra. Seus padrões do URLConf que esperar uma barra inicial funcionaram corretamente. No exemplo acima, supondo que queiramos enviar uma URL como ``/mysite/admin/`` para o ``/admin/``, precisamos remover a string ``/mysite`` do início, então esse deve ser o valor do ``django.root``. Seria um error usar o ``/mysite/`` (com uma barra final) nesse caso. Repare que estamos usando a diretiva ```` , não a diretiva ````. Essa última é usada para apontar para lugares no sistema de arquivos, enquanto ```` aponta para lugares específicos na estrutura de URL de um Web site. ```` seria sem significado aqui. Além disso, se o seu projeto Django não está no ``PYTHONPATH`` padrão do seu computador, você terá de dizer ao mod_python onde o seu projeto pode ser encontrado: .. parsed-literal:: SetHandler python-program PythonHandler django.core.handlers.modpython SetEnv DJANGO_SETTINGS_MODULE mysite.settings PythonOption django.root /mysite PythonDebug On **PythonPath "['/path/to/project'] + sys.path"** O valor usado em ``PythonPath`` deve incluir o diretório pai de todos os módulos que você vai importar em sua aplicação. Deve também incluir o diretório pai da localização do :ref:`DJANGO_SETTINGS_MODULE `. Essa é exatamente a mesma situação do caminho do Python para uso iterativo. Sempre que você tenta importar algo, o Python irá percorrer todos os diretórios no ``sys.path`` em ordem, do primeiro ao último, e tentar importar de cada diretório até ter sucesso. Verique se as permissões dos seus arquivos de código Python estejam configuradas de forma que o usuário do Apache (normalmente chamado de ``apache`` ou ``httpd`` na maioria dos sistemas) tenha acesso de leitura aos arquivos. Um exemplo que pode tornar isso mais claro: suponha que você tenha algumas aplicações em ``/usr/local/django-apps/`` (por exemplo, ``/usr/local/django-apps/weblog/`` e assim por diante), seu arquivo de configurações está em ``/var/www/mysite/settings.py`` e você tem o :ref:`DJANGO_SETTINGS_MODULE ` especificado como no exemplo acima. Nesse caso, você precisa escrever a sua diretiva ``PythonPath`` assim:: PythonPath "['/usr/local/django-apps/', '/var/www'] + sys.path" Com esse caminho, ``import weblog`` e ``import mysite.settings`` irão funcionar. Se você tem ``import blogroll`` em algum lugar do seu código e ``blogroll`` está no diretório ``weblog/``, você *também* precisa adicionar ``/usr/local/django-apps/weblog/`` ao seu ``PythonPath``. Lembre-se: os **diretórios pai** de tudo o que você for importar diretamente devem estar no caminho do Python. .. note:: Se você está usando o Windoes, ainda assim recomendamos que você use barras normais nos nome dos caminhos, ainda que o Windows normalmente use as barras invertidas como seu separador nativo. O Apache sabe como converter a barra para o formato nativo, então esse jeito de lidar é mais portável e mais fácil de ler. (E evida problemas esquisitos como ter de escapar as barras invertidas duas vezes.) Isso é válido mesmo em um sistema Windows:: PythonPath "['c:/path/to/project'] + sys.path" Você também pode adicionar diretivas como ``PythonAutoReload Off`` para performance. Veja a `documentação do mod_python`_ para uma lista completa de opções. Note que você deve configurar ``PythonDebug Off`` em um servidor de produção. Se você deixar o ``PythonDebug On``, seus usuários vão ver tracebacks Python feios (e reveladores) se algo der errado dentro do mod_python. Reinicie o Apache, e quaisquer requisições feitas para ``/mysite/`` ou abaixo dele serão servidas pelo Django. Note que as URLconfs do Django não não eliminar o "/mysite/" -- elas recebem a URL completa. Ao implantar sites Django no mod_python, você irá precisar reiniciar o Apache a cada vez que você fizer mudanças no seu código Python. Múltiplas instalações do Django no mesmo Apache =============================================== É inteiramente possível executar múltiplas instalações do Django na mesma instância do Apache. Apenas use ``VirtualHost`` para isso, assim so:: NameVirtualHost * ServerName www.example.com # ... SetEnv DJANGO_SETTINGS_MODULE mysite.settings ServerName www2.example.com # ... SetEnv DJANGO_SETTINGS_MODULE mysite.other_settings Se você precisa colocar duas instalações do Django dentro do mesmo ``VirtualHost`` (ou em blocos ``VirtualHost`` diferentes que compartilham o mesmo nome de servidor), você precisará tomar um cuidade especial para que o cache do mod_python não bagunce as coisas. Use a diretiva ``PythonInterpreter`` para dar a cada diretiva ```` diferente interpretadores separados:: ServerName www.example.com # ... SetEnv DJANGO_SETTINGS_MODULE mysite.settings PythonInterpreter mysite SetEnv DJANGO_SETTINGS_MODULE mysite.other_settings PythonInterpreter othersite Os valores para ``PythonInterpreter`` não importam muito, desde que eles sejam diferentes entre os blocos ``Location``. Executando um servidor de desenvolvimento com o mod_python ========================================================== Se você usar o mod_python como seu servidor de desenvolvimento, você pode evitar o fardo de ter de reiniciar o servidor cada vez que seu código muda. Apenas configure ``MaxRequestsPerChild 1`` no seu arquivo ``httpd.conf`` para forçar o Apache a recarregar tudo de novo em cada requisição. Mas não faça isso no servidor de produção, ou revogaremos seus privilégios Django. Se você é o tipo de programador que debuga disperando declarações ``print`` no meio do seu código, note que declarações ``print`` não aparecem no log do Apache e podem até mesmo `causar erros de resposta`_. .. _causar erros de resposta: http://blog.dscpl.com.au/2009/04/wsgi-and-printing-to-standard-output.html Se você precisa imprimir informação de depuração em uma configuração com o mod_python, você tem algumas opções. You can print to ``stderr`` explicitly, like so:: print >> sys.stderr, 'debug text' sys.stderr.flush() (note that ``stderr`` is buffered, so calling ``flush`` is necessary if you wish debugging information to be displayed promptly.) A more compact approach is to use an assertion:: assert False, 'debug text' Outra alternativa é adicionar a informação de debug no template da sua página. .. _documentação do mod_python: http://modpython.org/live/current/doc-html/directives.html Servindo arquivos de mídia ========================== O Django não serve arquivos de mídia por si só; ele delega esse trabalho ao servidor Web de sua escolha. Nós recomendanos o uso de um servidor Web separado -- i.e., um que não esteja executando o Django -- para servir mídia. Aqui estão algumas boas escolhas: * lighttpd_ * Nginx_ * TUX_ * Uma versão reduzida do Apache_ * Cherokee_ Se, porém, você não tem opção exceto servir arquivos de mídia no mesmo ``VirtualHost`` do Apache do Django, aqui está como você pode desligar o mod_python para uma parte em particular do site:: SetHandler None Apenas mude o ``Location`` para a URL raiz dos seus arquivos de mídia. Você pode usar também o ```` para casar com uma expressão regular. Esse exemplo configura o Django na raiz do site mas explicitamente desabilita o Django para o subdiretório ``media`` e qualquer URL quer termine em ``.jpg``, ``.gif`` ou ``.png``:: SetHandler python-program PythonHandler django.core.handlers.modpython SetEnv DJANGO_SETTINGS_MODULE mysite.settings SetHandler None SetHandler None .. _lighttpd: http://www.lighttpd.net/ .. _Nginx: http://wiki.nginx.org/Main .. _TUX: http://en.wikipedia.org/wiki/TUX_web_server .. _Apache: http://httpd.apache.org/ .. _Cherokee: http://www.cherokee-project.com/ Servindo os arquivos da administração ===================================== Note que o servidor de desenvolvimento do Django automaticamente serve os arquivos de mídia da administração, mas isso não é automático quando você usa outra disposição de servidor. Você é responsável por configurar o Apache, ou qualquer outro servidor de mídia que estiver usando, para servir os arquivos da administração. Os arquivos da administração ficam na pasta (:file:`django/contrib/admin/media`) da distribuição do Django. Aqui estão duas formas recomendadas: 1. Crie um link simbólico para os arquivos de mídia da administração dentro do seu document root. Dessa forma, todos os seus arquivos relacionados ao Django -- código **e** templates -- ficam em um único lugar, e você ainda irá ser capaz de fazer um ``svn update`` no seu código para obter as últimas versões dos templates da administração, se eles mudarem. 2. Ou, copie os arquivos de mídia da administração de forma que eles fiquem dentro do document root do seu Apache. Usando "eggs" com o mod_python ============================== Se você instalou o Django de um Python egg_ ou está usando eggs no seu projeto Django, algumas configurações extra são requeridas. Crie um arquivo extra no seu projeto (ou em algum outro lugar) que contenha algo assim: .. code-block:: python import os os.environ['PYTHON_EGG_CACHE'] = '/some/directory' Aqui, ``/some/directory`` é um diretório ao qual o servidor Apache tenha acesso de escrita. Ele será usado como o local de descompactação para qualquer código que os eggs precisem fazer. Então você irá precisar dizer ao mod_python para importar esse arquivo antes de fazer qualquer coisa. Isso é feito usando a diretiva PythonImport_ do seu mod_python. Você precisa garantir que você especificou a diretiva ``PythonInterpreter`` do mod_python como descrito acima__ (nesse caso, você precisa fazer isso mesmo que você não esteja servindo múltiplas instalações). Então, adicione a linha ``PythonImport`` na configuração principal do servidor (i.e., fora das seções ``Location`` ou ``VirtualHost``). Por exemplo:: PythonInterpreter my_django PythonImport /path/to/my/project/file.py my_django Note que você pode usar um caminho absoluto aqui (ou um caminho de importação com pontos normal), como descrito no `manual do mod_python`_. Nós usamos um caminho absoluto no exemplo acima porque se quaisquer modificações no Python path forem necessárias para acessar seu projeto, elas não terão sido feitas no momento em que a linha ``PythonImport`` é processada. .. _Egg: http://peak.telecommunity.com/DevCenter/PythonEggs .. _PythonImport: http://www.modpython.org/live/current/doc-html/dir-other-pimp.html .. _manual do mod_python: PythonImport_ __ `Múltiplas instalações do Django no mesmo Apache`_ Tratamento de erros =================== QUando você usa o Apache/mod_python, os error serão capturados pelo Django -- em outras palavras, eles não irão propagar para o nível do Apache nem aparecerão no ``error_log`` do Apache. A exceção a isso é se algo estiver realmente quebrado na sua configuração do Django. Nesse caso, você verá uma página de "Erro Interno do Servidor" no seu navegador e o traceback completo do Python no seu arquivo ``error_log`` do Apache. O traceback no ``error_log`` ocupa diversas linhas. (Sim, isso é feio e bem chato de ler, mas é como o mod_python faz as coisas.) Se você tiver uma falha de segmentação ====================================== Se o Apache causar uma falha de segmentação, existem duas razões prováveis, nenhuma das quais tem a ver com o Django em si. 1. Pode ser que o seu código Python está importando o módulo "pyexpat", que pode causar conflito com a versão embutida no Apache. Para informação completa, veja `Expat fazendo o Apache travar`_. 2. Pode ser porque você está usando o mod_python e o mod_php na mesma instância do Apache, com o MySQL como seu banco de dados. Em alguns casos, isso causa um problema conhecido do mod_python devido a conflito de versões no PHP e no backend do MySQL do Python. Existem informação completa na `entrada da FAQ do mod_python`_. Se você continuar a ter problemas configurando o mod_python, algo interessante a se fazer e conseguir um site mod_python cru rodando, sem o framework Django. Isso é um modo fácil de isolar problemas específicos do mod_python. `Fazendo o mod_python funcionar`_ detalha esse procedimento. O próximo passo deve ser editar seu código de teste e adicionar um import de qualquer código específico do Django que você esteja usando -- suas views, seus models, suas URLconf, sua configuração de RSS, etc. Coloque esses imports na sua função gerenciadora de teste e acesse sua URL de teste em um navegador. Se isso causa um crash, você confirmou que a importação de código Django que causa o problema. Gradualmente reduza o conjunto de imports até que pare de travar, para que você encontre o módulo específico que causa o problema. Investigue cada módulo e veja seus imports, conforme necessário. .. _Expat fazendo o Apache travar: http://www.dscpl.com.au/wiki/ModPython/Articles/ExpatCausingApacheCrash .. _entrada da FAQ do mod_python: http://modpython.org/FAQ/faqw.py?req=show&file=faq02.013.htp .. _Fazendo o mod_python funcionar: http://www.dscpl.com.au/wiki/ModPython/Articles/GettingModPythonWorking If you get a UnicodeEncodeError =============================== If you're taking advantage of the internationalization features of Django (see :doc:`/topics/i18n/index`) and you intend to allow users to upload files, you must ensure that the environment used to start Apache is configured to accept non-ASCII file names. If your environment is not correctly configured, you will trigger ``UnicodeEncodeError`` exceptions when calling functions like ``os.path()`` on filenames that contain non-ASCII characters. To avoid these problems, the environment used to start Apache should contain settings analogous to the following:: export LANG='en_US.UTF-8' export LC_ALL='en_US.UTF-8' Consult the documentation for your operating system for the appropriate syntax and location to put these configuration items; ``/etc/apache2/envvars`` is a common location on Unix platforms. Once you have added these statements to your environment, restart Apache.