Conteúdo


Implementando Aplicativos Django em um Servidor de Produção

Django

Django é uma estrutura de desenvolvimento para a Web de software livre para a linguagem Python que tem como meta automatizar o maior número de processos possível, permitindo que você foque o desenvolvimento de software sem se preocupar em reinventar a roda. A estrutura foi projetada para ser fracamente acoplada e fortemente coesa, o que significa que diferentes partes da estrutura, apesar de conectadas umas as outras, não dependem umas das outras. Essa independência significa que é possível usar somente as partes do Django necessárias, sem se preocupar com problemas de dependência.

O Django acelera a gravação de aplicativos da Web reduz drasticamente a quantidade de código necessária, facilitando a manutenção do aplicativo que está avançando. O Django observa de forma rígida o princípio Don't Repeat Yourself (DRY), através do qual cada parte de código ou de dados distinta reside em um único local. Isso significa que quando for necessário fazer uma mudança, será necessário fazê-la em apenas um local, o que leva o processo de alteração de software a se tornar muito mais rápido e muito mais fácil.

O Django foi desenvolvido por uma equipe de desenvolvedores da Web no jornal Lawrence Journal-World em 2003. Sob pressão para liberar aplicativos e aprimoramentos sob limitadores de tempo severos, decidiram criar uma estrutura da Web que economizaria tempo, permitindo que cumprissem seus prazos finais difíceis. A equipe liberou a estrutura como software livre em julho de 2005 e agora é desenvolvida por uma comunidade de milhares de desenvolvedores em todo o mundo.

A estrutura do Django é liberada sob a licença de software livre Berkeley Software Distribution (BSD), que permite redistribuição e reutilização do código de origem e binário, com ou sem modificação, desde que o aviso de copyright, as condições da licença e a renúncia de responsabilidade sejam mantidos no pacote redistribuído. Esses itens também devem estar presentes na documentação e em materiais suplementares do software redistribuído, quando aplicável. E a licença especifica que nem o nome do Django nem o nome dos contribuidores do Django podem ser usados para endossar ou promover produtos derivativos sem permissão expressa por escrito.

Configurando um Ambiente de Desenvolvimento Básico do Django

Felizmente, a instalação do Django é direta, portanto, configurar um ambiente de desenvolvimento é rápido e fácil. O Django é gravado inteiramente em Python, portanto, para instalar o Django, é necessário, primeiramente, instalar Python. Se estiver usando o Mac OS X ou o Linux®, provavelmente, Python já está em sua máquina. Simplesmente execute python em seu shell (use Terminal.app em um Mac) e deverá ver algo como a Lista 1.

Lista 1. Certificar-se de que Python Está em Execução
$ python
Python 2.5.1 (r251:54863, Nov 11 2008, 17:46:48)
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
Listing 1 - Checking for Python on Mac OS X

Desde que seu sistema tenha uma versão de Python, da 2.3 à 2.6, será possível instalar o Django. Se for um usuário do Microsoft® Windows® ou se precisar fazer upgrade para uma versão mais nova, faça download de Python. Um pacote de instalação simples está disponível para usuários do Windows, portanto, instalar Python não poderia ser muito mais simples.

Após verificar se Python está instalado em seu computador, é possível prosseguir para a instalação do Django. Há três opções: instalar um release oficial, instalar um pacote de instalação específico de uma distribuição ou instalar a versão "tronco" mais recente de Subversion. Para o interesse deste artigo, percorrerei somente a instalação de um release oficial. Para obter informações sobre como instalar a versão tronco, consulte as instruções da documentação oficial (consulte Recursos).

A primeira etapa na instalação do release oficial do Django é obter o tarball da página de download do Django. Após ter transferido esse arquivo por download, extraia seu conteúdo. No Linux, simplesmente emita o comando a seguir em sua linha de comando do shell (certifique-se de navegar até o diretório onde transferiu por download o pacote). Observe que a V1.0.2 era o release mais recente na época em que este artigo foi escrito, portanto, certifique-se de substituir esse nome de arquivo pelo nome do arquivo exato do pacote transferido por download: tar zxvf Django-1.0.2-final.tar.gz.

No Mac OS X, seu navegador da Web provavelmente descompactou automaticamente o pacote quando concluiu o download, portanto, o arquivo será Django-1.0.2-final.tar. Para extrair esse arquivo, simplesmente use o seguinte comando: tar xvf Django-1.0.2-final.tar. Se estiver usando o Windows, é possível usar um utilitário como o 7-Zip para extrair o tarball.

Agora que já extraiu o conteúdo do tarball (provavelmente para um local como Django-1.0.2-final em sua unidade de disco rígido), navegue até essa pasta em seu prompt de comandos. Para instalar o Django, emita o seguinte comando (Mac OS X ou Linux): sudo python setup.py install. Usuários do Windows, certifiquem-se de que seu prompt de comandos seja aberto com privilégios de administrador e emita o seguinte comando: setup.py install.

Após fazer isso, o Django terá sido instalado na pasta site-packages na instalação de Python e você está pronto para iniciar o desenvolvimento no Django. Antes de prosseguirmos para a anatomia de um aplicativo Django, vamos testar se nosso ambiente de desenvolvimento está ativado e em execução. Primeiro, verificaremos se o Django está instalado corretamente. Abra seu shell ou prompt de comandos e inicie a ferramenta interativa Python emitindo o comando python. Agora emita os comandos mostrados na Lista 2 no prompt de Python (não digite os >>>s):

Lista 2. Verificar se o Django Está Instalado Corretamente
>>> import django
>>> django.VERSION

Se sua instalação tiver sido bem-sucedida, você deve ver o texto mostrado na Lista 3.

Lista 3. Instalação Bem-sucedida
(1, 0, 2, 'final', 0)
>>>

Agora que verificamos que o Django está realmente instalado, vamos testar se o servidor de desenvolvimento está funcionando. Para fazer isso, precisamos criar um projeto. Crie um diretório para armazenar seus projetos Django (eu uso /home/joe/django em meu sistema Mac OS X) e navegue até esse diretório. A partir de lá, emita o seguinte comando: django-admin.py startproject testproject.

Isso criará um novo diretório em seu diretório projects, chamado testproject. Esse diretório contém quatro arquivos: __init__.py, manage.py, settings.py e urls.py. Não se preocupe com o que esses arquivos fazem agora; vamos pular adiante e executar o projeto. Certifique-se de que você esteja na pasta project (use cd testproject no prompt) e emita o comando a seguir: python manage.py runserver. Você deve ver a saída mostrada abaixo.

Lista 4. Executando o Servidor de Desenvolvimento Django
Validating models...
0 errors found

Django version 1.0.2 final, using settings 'testproject.settings'
Development server is running at http://127.0.0.1:8000/
Quit the server with CONTROL-C.

Essa mensagem nos informa que o servidor de desenvolvimento agora está em execução na URL http://127.0.0.1:8000/. Abra seu navegador da Web favorito e cole essa URL na barra de endereço. Você deve ver uma página como a mostrada abaixo.

Figura 1. Página Welcome to Django
Página Welcome to Django
Página Welcome to Django

Agora você tem um ambiente de desenvolvimento Django ativado e em execução. Vale a pena mencionar que, apesar de você poder executar aplicativos Django completos nesse ambiente, não é adequado em um ambiente de produção. Vamos cobrir a implementação de aplicativos Django para uso de produção posteriormente neste artigo.

A Anatomia de um Aplicativo Django

A arquitetura Django é vagamente baseada no padrão Model-View-Controller (MVC), pois separa a lógica do aplicativo, a interface com o usuário (UI) e as camadas de acesso a dados, com a meta de permitir que cada camada seja modificada de forma independente, sem afetar as outras camadas. De acordo com a documentação do Django, no entanto, o Django segue um padrão semelhante: ao que se refere como uma arquitetura Model-Template-View (MTV) . Model pode ser visto como a camada de acesso a dados, onde o aplicativo interage com quaisquer bancos de dados e fontes de informações. Template é a camada que define como os dados devem ser apresentados ao usuário, enquanto que essa é considerada a camada View em um padrão MVC. Em uma arquitetura MTV, a camada View descreve quais dados devem ser apresentados ao usuário. Não define exatamente como devem ser apresentados; delega essa tarefa à camada Template. Para a camada Controller de MVC, o Django vê isso como a própria estrutura, pois determina a visualização apropriada para a qual enviar pedidos, conforme definido na configuração da URL.

Além de Models, Templates e Views, o Django oferece alguns recursos avançados prontos, como configurações de URL, uma interface administrativa automática, armazenamento em cache e mais. Como Python, uma das filosofias chave por trás do Django é a abordagem de baterias incluídas, o que significa que é fornecido com uma grande biblioteca padrão de pacotes adicionais que podem ser usados em seus aplicativos sem downloads adicionais.

A camada Model de um aplicativo Django é tratada pela camada de acesso a dados do Django. Nessa camada, você encontrará tudo que está relacionado aos dados: configurações de conexão, parâmetros de validação, relações, etc. Com instalação padrão, o Django inclui suporte para PostgreSQL (o banco de dados preferencial dos criadores do Django), MySQL, SQLite e Oracle. Qual banco de dados usar está armazenado em um arquivo de configurações e a camada Model é a mesma, independentemente da opção escolhida.

Modelos no Django podem ser vistos como descrições dos esquemas de tabela de banco de dados, representados em código Python. O Django usa o modelo para gerar e executar instruções SQL no banco de dados, que, por sua vez, retornam um resultado. Em seguida, o Django o converte para uma estrutura de dados Python, que pode ser usada por seu aplicativo Django. Uma vantagem óbvia aqui é poder efetuar hot swap entre diferentes sistemas de bancos de dados (por exemplo, alterar de MySQL para PostgreSQL) sem precisar alterar seus modelos.

O código na Lista 5 é um exemplo de uma definição de modelo. Ele geralmente estaria armazenado em um arquivo models.py em um diretório do aplicativo Django.

Lista 5. Modelo do Django de Amostra
from django.db import models

class Person(models.Model):
    first_name = models.CharField(max_length=30)
    last_name = models.CharField(max_length=30)
    email = models.EmailField()
    date_of_birth = models.DateField()

A camada Template de um aplicativo Django permite separar a UI ou o layout da apresentação de um aplicativo da Web de seus dados. Usa variáveis marcadoras e instruções de lógica simples para definir quais dados devem ser preenchidos no template. Templates geralmente produzem uma saída HTML, mas também podem produzir XML ou qualquer outro tipo de documento.

A ideia por trás da camada Template é que o código da camada de apresentação seja separado do código da camada de negócios. Isso significa que um desenvolvedor de Python pode focar o desenvolvimento de software, enquanto deixa o designer da Web trabalhar nos templates. Também significa que o desenvolvedor e o designer podem trabalhar no mesmo projeto ao mesmo tempo, pois os dois componentes são completamente separados um do outro.

É importante observar que o sistema de templates do Django não permite que o código Python seja executado diretamente a partir do modelo. Oferece um conjunto rudimentar de recursos de estilo de programação, como variáveis, instruções de lógica (instruções if ) e construções de looping (loops for ), que devem oferecer mais do que lógica suficiente necessária para a apresentação dos dados. A Lista 6 é um exemplo de qual seria a aparência de um template do Django.

Lista 6. Template do Django de Amostra
<html> <head>
<title>Your message has been sent</title>
</head>
<body>
<h1>Thank you!</h1>
<p>Just wanted to say a quick thanks, {{ name }}, for the message you have just
    sent.</p>
<p>It was sent on {{ sent_date|date:"j F Y" }}. We aim to respond within
    48 hours.</p>
<p>Thanks again!</p>
</body>
</html>

A Lista 7 mostra como esse template seria usado em um aplicativo Django.

Lista 7. Carregando o Template do Django de Amostra em uma Visualização
def send_message(request):
    name = "Joe Lennon"
    sent_date = datetime.datetime.now()
    return render_to_response('thankyou.html', locals())

As funções de visualização, ou "visualizações" como são mais comumente conhecidas, são basicamente funções Python que aceitam um parâmetro de pedido e retornam uma resposta. O pedido é geralmente um pedido de um servidor da Web e a visualização aceita quaisquer parâmetros passados juntamente com esse pedido. A visualização executa, então, a lógica necessária para determinar a resposta apropriada antes de retornar essa resposta. As visualizações podem ser armazenadas em qualquer parte de um aplicativo Django, mas geralmente são armazenadas em um arquivo denominado views.py. A Lista 5 é um exemplo de uma função de visualização denominada send_message. Ela aceita o parâmetro request em sua definição e retorna um modelo renderizado (thankyou.html) como sua resposta.

Você acabou de ler que visualizações podem ser armazenadas em qualquer local. Se esse for o caso, como o Django sabe onde localizá-las? Isso nos leva a URLconfs, que define quais URLs apontam para quais visualizações. URLconfs são armazenados em um arquivo chamado urls.py e basicamente mapeiam uma URL para uma função de visualização. Por exemplo, a url /send_message/ pode ser mapeada para nossa visualização send_message, conforme descrito na Lista 7. Na verdade, a maneira como URLconfs funcionam permite que sejam usados para belas URLs prontas — ou seja, em vez de usar cadeias de consultas como myfile.php?param1=value1, sua URL pode ser /myfile/value1/.

O código da Lista 8 fornece um exemplo de um arquivo urls.py, que conecta a URL /send_message/ à nossa função de visualização send_message , conforme definido na Lista 7.

Lista 8. URLconf de Amostra
from django.conf.urls.defaults import *
from testproject.views import send_message

urlpatterns = patterns('',
    ('^send_message/$', send_message),
)

Um dos recursos mais interessantes e comentados do Django é sua interface administrativa automática. Os desenvolvedores de aplicativos da Web que trabalharam em projetos que requerem que interfaces administrativas de backend sejam desenvolvidas além do front-end podem ser capazes de entenderem a frustração e o tédio que vem do desenvolvimento dessas interfaces. As interfaces administrativas são muito complexas, não requerem muita habilidade e não exercitam seus músculos de programação de forma alguma. O recurso de interface administrativa automática do Django será de grande valor, pois tira esse requisito da equação, automatizando toda a tarefa.

Depois de criar os modelos para seu aplicativo e configurar as definições do banco de dados, é possível ativar a interface administrativa para seu aplicativo. Após fazer isso, simplesmente aponte seu navegador para http://127.0.0.1:8000/admin/ e efetue login para gerenciar o backend de seu aplicativo Django. A interface é altamente customizável e apresenta excelentes controles de autenticação baseados em usuário e grupo. Uma captura de tela dela em ação é mostrada abaixo.

Figura 2. Interface Administrativa Automática do Django em Ação
Interface Administrativa Automática do Django em Ação
Interface Administrativa Automática do Django em Ação

Fornecemos uma visão geral resumida de como um aplicativo Django é criado e de como o padrão MTV no qual é baseado funciona. Demos uma olhada nos conceitos de modelos, templates, visualizações e URLconfs; além de vermos uma pequena amostra do sistema de interface administrativa automática brilhante do Django. Se estiver procurando um guia aprofundado para desenvolvimento de aplicativos Django, visite o Web site oficial do projeto Django e leia a documentação disponível ou leia o Django Book (consulte Recursos). Ambos oferecem um excelente guia de princípio gratuito para tudo do Django e cobre muito mais detalhes do que podemos aqui.

Em seguida, dê uma olhada em usando os aplicativos do Django e implementando-os em servidores de produção.

Aprontando seu Aplicativo do Django para Implementação

Como vimos, a estrutura do Django inclui, de forma conveniente, um servidor de desenvolvimento, que é ideal para depurar e testar seu aplicativo do Django. Infelizmente, esse servidor é projetado para ser executado somente em um ambiente local e não poderia suportar as pressões de um aplicativo da Web de produção usado por muitas pessoas simultaneamente. Por isso, é necessário implementar o Django em um servidor da Web de nível de produção, como o Apache ou o lighttpd. Explore algumas etapas que precisam ser executadas para tornar seu aplicativo pronto para produção, em seguida, aprenda o que está envolvido na preparação de seu servidor da Web para atender seu aplicativo do Django.

Antes de discutir como configurar seu ambiente de produção para seu aplicativo Django, há algumas coisas que precisam ser feitas nas configurações de seu aplicativo Django. É importante fazer essas alterações, pois quaisquer vulnerabilidades em seu aplicativo Django podem se tornar públicas, graças a mensagens de erro de depuração, etc.

Naturalmente, você não irá querer alterar essas configurações em seu ambiente de desenvolvimento, já que mensagens de depuração e erros são extremamente úteis na manutenção de seu aplicativo. Para solucionar isso, você poderia manter dois arquivos de configurações separados: um para seu servidor de desenvolvimento e um para seu servidor de produção. Como alternativa, você poderia implementar o seguinte truque para mantê-las no mesmo arquivo e indicar ao Django para usar somente as configurações de desenvolvimento se estiver no ambiente de desenvolvimento. Para fazer isso, seria necessário determinar o layout de seu arquivo settings.py da seguinte forma (obviamente, substitua joe-mac-mini pelo nome do host de seu servidor de desenvolvimento, conforme mostrado na Lista 9).

Lista 9. Configurações Separadas para Ambientes de Desenvolvimento e Produção
import socket
if socket.get_hostname() == 'joe-mac-mini':
    #Configurações do Servidor de Desenvolvimento entram aqui
else:
    #Configurações do Servidor de Produção entram aqui

Agora, que verificamos como manter configurações separadas para nossos dois ambientes, vamos examinar as configurações que precisamos alterar em nosso ambiente de produção. As duas configurações essenciais que precisam ser alteradas em seu ambiente de produção são DEBUG e TEMPLATE_DEBUG. Elas são configuradas para True por padrão quando o aplicativo Django é criado usando django-admin.py startproject. É essencial alterar isso para False para seu ambiente de produção. Em seu settings.py, na seção Production, esta linha deve ter a seguinte: DEBUG = TEMPLATE_DEBUG = False.

Por padrão, o Django é configurado para enviar um e-mail toda vez que uma exceção não manipulada for levantada em seu aplicativo Django. Para ativar esse recurso, indique ao Django para quem deve enviar o e-mail. Isso é feito com a configuração ADMINS no arquivo settings.py.

Lista 10. Definindo Administradores de Aplicativos
ADMINS = (
    ('Joe Lennon', 'joe@joelennon.ie'),
)

Se surgirem erros em seu código quando estiver desenvolvendo seu aplicativo Django, talvez você terá notado as páginas de erro que o Django gera, cheias de informações úteis para ajudá-lo a localizar a raiz do problema. Ao desativar o modo de depuração, essas belas páginas de erros desaparecem, já que são uma ameaça em potencial à segurança. Como resultado, se alguém encontrar um erro (por exemplo, um 404 Página Não Localizada, 403 Proibido ou 5000 Erro Interno do Servidor), verá somente uma página de código de erro crítico. Para retificar isso, é aconselhável criar belas páginas explanatórias de modelo de erro e colocá-las na pasta template de seu aplicativo. Cada modelo deve ser denominado de acordo com o código de erro que representa. Para Página Não Localizada, você deve denominar o arquivo 404.html; para Erro Interno do Servidor, use 500.html; etc.

Agora, que configuramos nossas definições para uso em um ambiente de produção, vamos mostrar como esse ambiente deve ser configurado para hospedar seu aplicativo Django. Apesar de ser possível executar o Django usando FastCGI e lighttpd, uma configuração mais típica é Apache e mod_python. Agora, vamos dar uma olhada em como implementar um servidor executando Apache e mod_python. Em seguida, vamos olhar rapidamente como implementar um ambiente hosting da Web compartilhado, onde o acesso a httpd.conf é proibido.

Implementando Aplicativos Django no Apache com mod_python

De acordo com a documentação do Django, uma configuração do servidor da Web Apache executando mod_python é a opção recomendada para implementar aplicativos Django. Django suporta configurações com pelo menos o Apache HTTP Server V2.0 e o mod_python V3.0 e posterior. mod_python é um módulo Apache que integra suporte para a linguagem de programação Python no servidor da Web. É muito mais rápido do que o método CGI tradicional de execução de scripts Python.

Para carregar o módulo mod_python no Apache, inclua a seguinte linha no arquivo httpd.conf de seu servidor: LoadModule python_module /usr/lib/apache2/modules/mod_python.so.

Além de carregar o módulo mod_python, também é necessário configurar uma diretiva Location que indica ao Apache qual URL associar a seu aplicativo Django. Por questão de exemplo, as configurações aqui são as que seriam aplicadas ao projeto testproject criado anteriormente.

Lista 11. Diretiva Location de testproject
<Location "/testproject">
    SetHandler python-program
    PythonHandler django.core.handlers.modpython
    SetEnv DJANGO_SETTINGS_MODULE testproject.settings
    PythonDebug Off
</Location>

Isso indica ao Apache que seu projeto testproject do Django está acessível através da URL /testproject. Por exemplo, se o nome de domínio de seu servidor for example.com, seu aplicativo estaria disponível através de http://www.example.com/testproject/. Para carregar essas ovas configurações no Apache, simplesmente reinicie o servidor Apache.

Os desenvolvedores do Django recomendam muito não entregar arquivos de mídia (como imagens, vídeo, áudio, etc.) a partir do mesmo servidor da Web que seu aplicativo da Web, mas, em muitos casos, isso não é uma opção — pelo menos inicialmente. Para configurar uma área de seu Web site onde os arquivos de mídia podem ser entregues, é possível incluir a diretiva a seguir em seu arquivo httpd.conf.

Lista 12. Indicando ao Apache para Não Usar mod_python para Arquivos de Mídia
<LocationMatch "\.(png|gif|jpg|mov|mp3|avi|wav)$">
    SetHandler None
</LocationMatch>

Isso é tudo para configurar o Apache e o mod_python para implementar o Django em um servidor da Web de produção. Em seguida, vamos dar uma olhada em um cenário de implementação comum no qual alguém está implementando em um servidor de hosting da Web compartilhado onde não é permitido modificar httpd.conf.

Implementando Aplicativos Django em um Ambiente de Hosting da Web Compartilhado

Infelizmente, servidores dedicados e servidores privados virtuais têm a tendência de serem muito caros e, como resultado, não são opções viáveis para implementação para todos. É comum primeiramente implementar um aplicativo da Web em um ambiente de hosting compartilhado, fazendo upgrade para soluções dedicadas à medida que o aplicativo cresce em popularidade. Felizmente, a maioria dos provedores de hosting da Web compartilhados inclui suporte a Python, portanto, é possível implementar aplicativos Django nesse cenário.

Diferentemente de um ambiente dedicado, os usuários finais geralmente não têm a opção de executar um processo do servidor separado nem editar o arquivo de configuração httpd.conf. Isso significa que não podem fazer as mudanças descritas na seção anterior, portanto, não podem deixar o Django ativado e em execução dessa maneira. Felizmente, é possível implementar o Django em ambientes de hosting compartilhados, usando processos com spawn efetuado pelo servidor da Web que executam um programa FastCGI. Crie um arquivo chamado .htaccess e coloque-o no mesmo diretório no qual está implementando seu aplicativo Django.

Lista 13. Arquivo .htaccess
AddHandler fastcgi-script .fcgi
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ testproject.fcgi/$1 [QSA,L]

Em seguida, crie um pequeno script Python que informe ao Apache sobre as diversas configurações para seu projeto Django e execute o programa FastCGI. O nome do arquivo não é importante, mas deve ser o mesmo que o nome do arquivo na linha RewriteRule de .htaccess. Na Lista 14, usamos o nome do arquivo testproject.fcgi, de forma que chamarei meu script.

Lista 14. Arquivo testproject.fcgi
#!/usr/bin/python
import sys, os
sys.path.insert(0, "/home/joelennon/python")
os.environ['DJANGO_SETTINGS_MODULE'] = "testproject.settings"

from django.core.servers.fastcgi import runfastcgi
runfastcgi(method="threaded", daemonize="false")

Certifique-se de fazer o arquivo executável. Caso tenha acesso de shell a seu servidor de hosting compartilhado, efetue login e vá para o diretório no qual o arquivo se encontra e execute chmod 755 testproject.fcgi.

Caso não tenha acesso de shell, pode alterar as permissões do arquivo com a maioria dos clientes FTP adequados. Toda vez que alterar o código de seu aplicativo, é necessário alterar o registro de data e hora nesse arquivo. Isso indica ao Apache que o aplicativo foi atualizado e continuará a reiniciar seu aplicativo Django. Se você tiver acesso de shell, isso é tão simples quanto executar touch testproject.fcgi. Caso não tenha acesso de shell, é possível atualizar o registro de data e hora fazendo novo upload do mesmo ou editando-o e salvando-o novamente.

Se preferir não sujar suas mãos com esses arquivos de configuração, poderia sempre se beneficiar de um serviço de hosting projetado para suportar aplicativos Django prontos. O popular provedor de hosting MediaTemple oferece um complemento GridContainer do Django para sua oferta GridService, a partir de US$20/mês para 256 MB de RAM. O GridContainer é executado em uma configuração lighttpd/FastCGI pré-ajustada e a quantidade de RAM pode ser aumentada para escalar juntamente com seu aplicativo.

Escalando a Implementação do Django

Se seu aplicativo Django for bem-sucedida, provavelmente, você precisará que sua implementação seja o mais escalável possível. É comum que os aplicativos da Web funcionem bem sob cargas médias, mas fenômenos como o efeito Digg podem encaminhar tanto tráfego para o aplicativo que ele se rende sob o surto de carga. Felizmente, Django e Python são altamente escaláveis por natureza, mas há outras coisas que precisam ser consideradas à medida que seu aplicativo cresce.

Se estiver executando seu aplicativo Django em um ambiente de hosting compartilhado e estiver começando o sentir que está crescendo além dos recursos limitados disponíveis para ele nesse espaço, seu primeiro ponto de parada óbvio é ir para uma máquina dedicada. Se o custo for um problema, servidores privados virtuais oferecem uma alternativa intermediária barata entre hosting compartilhado e um servidor dedicado.

À medida que seu aplicativo cresce, mesmo os recursos de um servidor dedicado podem se tornar esparsos muito rapidamente. Seguem alguns recursos que podem reduzir o peso em seu servidor:

  • Desative processos ou daemons não usados, como servidores de e-mail, servidores de fluxo, servidores de jogos ou qualquer outro processo desnecessário, que estejam usando tempo de CPU e RAM precisos.
  • Delegue seus arquivos de mídia para uma plataforma de nuvem, como Amazon S3. Isso permitirá usar seu servidor da Web somente para pedidos do Django e manter sua mídia em um servidor separado.
  • Desative a opção Keep-Alive do Apache. Keep-Alive é uma extensão para o protocolo HTTP, que permite conexões persistentes através de HTTP. Isso, por sua vez, permite que diversos pedidos sejam enviados através da mesma conexão TCP, acelerando drasticamente a entrega de documentos e imagens HTML estáticos. Infelizmente, essa extensão pode ter um efeito negativo no desempenho de um aplicativo Django. Observe que você deve desativar essa opção somente se tiver movido seus arquivos de mídia para um servidor diferente. Para desativar Keep-Alive, localize a linha relevante em seu arquivo httpd.conf e altere-a para Keep-Alive Off.
  • Use a estrutura de cache integrada do Django. Ela é desenvolvida por memcached, um sistema de armazenamento em cache de objeto de memória distribuído popular. O armazenamento em cache efetivo pode aprimorar de forma drástica o desempenho de seus aplicativos Django.
  • Faça upgrade de seu servidor. Dedique o máximo de RAM possível e, se o espaço em disco for um problema, considere incluir um novo disco. Se seu servidor estiver com dificuldades, mais provavelmente, deve-se ao uso total da RAM. Não gaste dinheiro fazendo upgrade de processadores — em vez disso, gaste dinheiro em RAM.
  • Compre outro servidor. Pode chegar um momento em que ser servidor simplesmente não pode mais tratar da carga do aplicativo Django sozinho. Assim que sua configuração de servidor único começar a ceder, inclua outro servidor. Você deve executar seu servidor da Web em uma máquina e seu servidor de banco de dados no outro. Certifique-se de usar a máquina com mais RAM para seu servidor de banco de dados. Se necessário, faça upgrade da nova máquina com mais RAM e espaço em disco quando necessário.
  • Use a replicação de banco de dados. Se seu servidor de banco de dados estiver ficando sem recursos, é possível reduzir o peso replicando-o em mais de um servidor. Quando a replicação for realizada, é possível incluir servidores quando for necessário para fornecer recursos adicionais.
  • Inclua redundância. Com aplicativos de grande escala, ter um único ponto de falha para seu servidor da Web ou servidor de banco de dados é ficar aguardando que ocorra um desastre. Você deve incluir servidores redundantes sempre que possível, que assumirão em caso de falha do servidor principal. Além disso, usar hardware ou software de balanceamento de carga, como mod_proxy, para distribuir o tráfego por seus servidores pode aumentar de forma drástica o desempenho de seu aplicativo.

É importante considerar um caminho de escala para seu aplicativo Django o mais breve possível. Isso permite colocar um plano de ação em andamento que cobre todo cenário possível. Portanto, se o efeito Digg dominar seu aplicativo, você pode simplesmente iniciar o próximo estágio de seu plano de escala e receber seus novos usuários de braços abertos — e, o mais importante, um aplicativo de execução rápida.

Resumo

Vimos a estrutura do Django de ambos os lados do espectro — de um desenvolvedor sem experiência anterior em usar a estrutura começando até alguém que possui um aplicativo Django totalmente pronto aguardando implementação, procurando um guia sobre como lidar com a implementação do aplicativo na Web. Também examinamos o que considerar em termos de escalabilidade para o futuro. Vimos do que é feito um aplicativo Django e aprendemos sobre o padrão Model-Template-View (MTV) no qual é baseado. Vimos que o Django é uma estrutura leve, fácil de instalar e fácil de aprender com excelente documentação e uma comunidade vibrante a ser redor, tornando-o uma excelente estrutura para seu próximo aplicativo da Web.


Recursos para download


Temas relacionados

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Software livre
ArticleID=394395
ArticleTitle=Implementando Aplicativos Django em um Servidor de Produção
publish-date=04072009