Como usar o Django com Apache e 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.

Configuração Básica

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.

Usando um 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).

Usando 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

Servindo arquivos

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.

Persistindo arquivos do admin

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:

  1. 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).

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

  3. Copie os arquivos estáticos do admin para que entã eles fiquem dentro do “document root” do Apache.

Autenticação do usuário Django vindo 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.

Back to Top