mod_wsgiLink para este cabeçalho#Implementar Django com Apache e mod_wsgi é uma forma testada e experimentada de colocar o Django em produção.
\nO 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.
\nA official mod_wsgi documentation é sua fonte para todos os detalhes sobre como usar mod_wsgi. Você provavelmente quer começar com installation and configuration documentation.
\nUm vez que tenha o mod_wsgi instalado e ativado, edite seu arquivo http_conf do servidor Apache e adicione o seguinte. Se estiver usando uma versão do Apache anterior a 2.4, substitua Require all granted por Allow from all e também a linha Order deny,allow acima dele.
WSGIScriptAlias / /path/to/mysite.com/mysite/wsgi.py\nWSGIPythonHome /path/to/venv\nWSGIPythonPath /path/to/mysite.com\n\n<Directory /path/to/mysite.com/mysite>\n<Files wsgi.py>\nRequire all granted\n</Files>\n</Directory>\nA 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.
Se você instalar as dependências Python do seu projeto dentro de um virtualenv, adicione o caminho para o virtualenv usando` WSGIPythonHome`. Veja o guia `` mod_wsgi virtualenv`` para mais detalhes.
\nA 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.
mod_wsgi no modo deamonLink para este cabeçalho#“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-home=/path/to/venv python-path=/path/to/mysite.com\nWSGIProcessGroup example.com\nSe 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\nVeja a documentação oficial do mod_wsgi para details on setting up daemon mode
\nO Django não serve arquivos, deixa este trabalho para qualquer web server que você escolha.
\nRecomendamos usar um Web Server separado – isto é, um que não esteja rodando o Django – para servir media. Aqui algums boas escolhas:
\n\nSe, 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.
\nEste 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\nAlias /favicon.ico /path/to/mysite.com/static/favicon.ico\n\nAlias /media/ /path/to/mysite.com/media/\nAlias /static/ /path/to/mysite.com/static/\n\n<Directory /path/to/mysite.com/static>\nRequire all granted\n</Directory>\n\n<Directory /path/to/mysite.com/media>\nRequire all granted\n</Directory>\n\nWSGIScriptAlias / /path/to/mysite.com/mysite/wsgi.py\n\n<Directory /path/to/mysite.com/mysite>\n<Files wsgi.py>\nRequire all granted\n</Files>\n</Directory>\nSe 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.
\n