mod_wsgi
¶Implantar Django com Apache e mod_wsgi é uma forma testada e experimentada de colocar o Django em produção.
O mod_wsgi é um módulo Apache o quam pode hospedar qualquer aplicação Python WSGI, incluindo Django. Django irá funcionar com qualquer versão do Apache que suporte mod_wsgi.
A official mod_wsgi documentation é fantastica; É o sua fonte para todos os detalhes sobre como usar mod_wsgi. Você provavelmente irá querer começar com installation and configuration documentation.
Once you’ve got mod_wsgi installed and activated, edit your Apache server’s
httpd.conf file and add the following. If you are using a version of Apache
older than 2.4, replace Require all granted
with Allow from all
and
also add the line Order deny,allow
above it.
WSGIScriptAlias / /path/to/mysite.com/mysite/wsgi.py
WSGIPythonPath /path/to/mysite.com
<Directory /path/to/mysite.com/mysite>
<Files wsgi.py>
Require all granted
</Files>
</Directory>
A primeira parte da linha WSGIScriptAlias
é a URL base que você quer servir sua aplicação (/
indica a URL raiz), e a segunda é o local do arquivo “WSGI” – veja abaixo – no seu sistema, geralmente dentro do pacote do seu projeto (mysite
neste exemplo). Isso diz ao Apache para servir qualquer requisição abaixo da URL informada usando a aplicação WSGI definida naquele arquivo.
A linha WSGIPythonPath
assegura que o pacote do seu projeto está disponível no Python path para ser importado; em outras palavras, que import mysite
funcione.
A parte <Directory>
somente assegura que o Apache pode acessar seu arquivo wsgi.py
.
Agora precisamos assegurar que este arquivo wsgi.py
com objeto de aplicação WSGI exista. Desde de o Django versão 1.4, startproject
terá criado um para você; se não, você precisará criá-lo. Veja Documentação geral WSGI para o conteúdo padrão que você deveria colocar neste arquivo, e o que mais você pode adicionar a ele.
Aviso
Se multiplas instâncias de sites Django estão rodando em um único processo WSGI, todos eles irão usar as definições daquele que rodou primeiro. Isso pode ser resolvido mudando:
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "{{ project_name }}.settings")
em wsgi.py
, para:
os.environ["DJANGO_SETTINGS_MODULE"] = "{{ project_name }}.settings"
ou por usando o mode daemon do mod_wsgi e assegurando que cada site está rodando no seu próprio processo deamon.
Arrumando o UnicodeEncodeError
para uploads de arquivos
Se houver um erro UnicodeEncodeError
quando fizer o upload de arquivos que contenham caracteres não ASCII, tenha certeza que o Apache está configurado para aceitar arquivos com nomes não ASCII:
export LANG='en_US.UTF-8'
export LC_ALL='en_US.UTF-8'
Um lugar comum para colocar essa configuração é em /etc/apache2/envvars
.
Veja a seção Files do guia de referência de unicode para detalhes.
virtualenv
¶Se as dependências do seu projeto estão instaladas dentro de um virtualenv, será necessário adicionar o path do diretório site-packages
do virtualenv ao “Python path” também. Para fazer isso, adicione um caminho adicional a sua diretiva WSGIPythonPath
, com múltimplos caminhos separados por dois-pontos (:
) se estiver usando um sistema UNIX-like, ou um ponto-e-vírgula (;
) se estiver usando window. Se qualquer parte do caminho do diretório contiver um caracter espaço, o argumento string todo par WSGIPythonPath
deve estar entre aspas:
WSGIPythonPath /path/to/mysite.com:/path/to/your/venv/lib/python3.X/site-packages
Assegure-se de dar o caminho correto para o seu virtualenv, e troque python3.x``com a versão correta do Python (ex.: ``Python3.4
).
mod_wsgi
no modo deamon¶“Modo Deamon” é o modo recomendado para rodar mod_wsgi (em plataforma não Windows). Para criar o grupo de processos deamon requerido e delegar o Django para rodar dentro, precisa adicionar as diretivas WSGIDaemonProcess
e WSGIProcessGroup
. Um outra mudança requerida na configuração acima se usar deamon mode é que não se pode usar o WSGIPythonPath
; no lugar deve usar a opção python-path
para WSGIDaemonProcess
, por exemplo:
WSGIDaemonProcess example.com python-path=/path/to/mysite.com:/path/to/venv/lib/python2.7/site-packages
WSGIProcessGroup example.com
Se quer servir seu projeto em um subdiretório (https://example.com/mysite
neste exemplo), você pode adicionar WSGIScriptAlias
a configuração acima:
WSGIScriptAlias /mysite /path/to/mysite.com/mysite/wsgi.py process-group=example.com
Veja a documentação oficial do mod_wsgi para details on setting up daemon mode
O Django não serve arquivos, deixa este trabalho para qualquer web server que você escolha.
Recomendamos usar um Web Server separado – isto é, um que não esteja rodando o Django – para servir media. Aqui algums boas escolhas:
Se, porém, você não tem opção de servir arquivos de media na mesmo VirtualHost Apache que está o Django, você pode configurar o Apache para servir algumas URLs como media estática, e outros usando a interface mod_wsgi para Django.
Este exemplo define o DJango como raiz do site, mas serve robots.txt
, favicon.ico
, e qualquer coisa nas URLs /static/
e /media
como arquivos estáticos. Todas as outra URLs serão servidas usando o mod_wsgi:
Alias /robots.txt /path/to/mysite.com/static/robots.txt
Alias /favicon.ico /path/to/mysite.com/static/favicon.ico
Alias /media/ /path/to/mysite.com/media/
Alias /static/ /path/to/mysite.com/static/
<Directory /path/to/mysite.com/static>
Require all granted
</Directory>
<Directory /path/to/mysite.com/media>
Require all granted
</Directory>
WSGIScriptAlias / /path/to/mysite.com/mysite/wsgi.py
<Directory /path/to/mysite.com/mysite>
<Files wsgi.py>
Require all granted
</Files>
</Directory>
Se estiver usando uma versão de Apache menor que 2.4, substitua Require all granted
por Allow from all
e também adicione a linha Order deny,allow
acima deste.
Quando django.contrib.staticfiles
está em INSTALLED_APPS
, o servidor de desenvolvimento do Django serve automaticamente os arquivos estáticos da app admin (e de qualquer outra app instalada). Isso não é o caso quando é usado qualquer outro arranjo de servidor. Voc^é o responsável por configurar o Apache, ou qualquer outro servidor Web que esteja usando, para server arquivos do admin.
Os arquivos do admin ficam em (django/contrib/admin/static/admin
) da distribuição Django.
Fortemente recomendamos usar django.contrib.staticfiles
para tratar dos arquivos do admin (junto com um servidor Web como delineado na seção anterior; isso quer dizer usar o comando de gerenciamento collectstatic
para coletar os arquivos estáticos em STATIC_ROOT
, e então configurar seu servidor Web para servir STATIC_ROOT
at STATIC_URL
), mas aqui estão três outras maneiras:
Crie um link simbólico para os arquivos estáticos do admin de dentro do seu “document root”(isso talvez requeira ``+FollowSymLinks``na sua configuração do Apache).
Use uma diretiva Alias
, como demonstrado acima, para apelidar a URL apropriada (provavelmente : settings:SATTIC_URL`+ ``admin/`) para o local real dos arquivos do admin.
Copie os arquivos estáticos do admin para que entã eles fiquem dentro do “document root” do Apache.
O Django disponibiliza um facilitador para habilitar o Apache a autenticar usuários diretamente no backend de autenticação do Django. veja documentação de autenticação do mod_wsgi.
ago 01, 2016