O esquama básico para colocar arquivos estáticos em produção é simples: execute o comando collectstatic quando houver mudanças nos arquivos estáticos, então faça os arranjos para que o diretório de arquivos estáticos (STATIC_ROOT) seja movido para o servidor de arquivos estátios e o sirva. Dependendo do STATICFILES_STORAGE, os arquivos talvez precisem ser movidos manualmente para um novo local ou o método post_process da classe Storage talvez o faça.
Claro, como todas as tarefas de implantação, os problemas estão nos detalhes. Cada configuração de produção será um pouco diferente, então você irá precisar adaptar o esquema básico para atender suas necessidades. Abaixo estã alguns padrões que podem ajudar.
\nSe você quer servir arquivos estáticos do mesmo servidor que já está servindo seu site , o processo talvez se parece com algo como:
\nSuba seu código para o servidor de deploy.
No servidor, execute: collectstatic para que copie todos os arquivos estáticos para dentro de STATIC_ROOT.
Configure seu servidor Web para servir seus arquivos em STATIC_ROOT sob a URL STATIC_URL. Por exemplo, aqui como fazer isso com Apache e mod_wsgi.
Você provavelmente irá querer automatizar esse processo, principalmente se você tem múltiplos servidores web. Existem várias maneiras de fazer essa automação, mas uma opção que muitos desenvolvedores Django gostam é o Fabric.
\nAbaixo, e nas seções seguintes, mostraremos alguns exemplos de “fabfiles” (isto é scripts fabric) que automatizam essas opções para colocar arquivos em produção. A sintaxe de um fabfile é bastante simples más não será coberto aqui; consulte`a documentação do Fabric <http://docs.fabfile.org/>`_, para uma explicação completa sobre a sintaxe.
\nEntão, um fabfile para implantar arquivos estáticos em alguns servidores web pode ser algo como:
\nfrom fabric.api import *\n\n# Hosts to deploy onto\nenv.hosts = ['www1.example.com', 'www2.example.com']\n\n# Where your project code lives on the server\nenv.project_root = '/home/www/myproject'\n\ndef deploy_static():\n with cd(env.project_root):\n run('./manage.py collectstatic -v0 --noinput')\nA maioria dos grandes sites Django usqm um servidor Web separado – iesto é, um que nao está servido também um Django – para servir arquivos estáticos. Este servidor roda um tipo diferente de servidor web – mais rápido mas sem tantas funcionalidades. Algums opções são:
\n\nA configuração destes servidores estão fora do escopo deste documento; verifique a respectiva documentação de cada um para instruções.
\nJá que seu servidor de arquivos estáticos não irão rodar um Django, você irá precisar modificar a estratégia para algo como:
\nQuando seus arquivos estáticos mudarem, execute collectstatic localmente.
Coloque seu STATIC_ROOT local no servidor de arquivo estático dentro do diretório que esta sendo servido. O rsync é uma opção comum para este passo já que ele precisa transferir somente as partes dos arquivos estáticos quesofreram mudanças.
Aqui está como isso pode parar no fabfile:
\nfrom fabric.api import *\nfrom fabric.contrib import project\n\n# Where the static files get collected locally. Your STATIC_ROOT setting.\nenv.local_static_root = '/path/to/static'\n\n# Where the static files should go remotely\nenv.remote_static_root = '/home/www/static.example.com'\n\n@roles('static')\ndef deploy_static():\n local('./manage.py collectstatic')\n project.rsync_project(\n remote_dir=env.remote_static_root,\n local_dir=env.local_static_root,\n delete=True,\n )\nUma outra tática comum é servir arquivos estáticos de um fornecedor de armazenamento na “cloud” como o S3 da Amazom e/ou um CDN (Content delivery network). Isso deixa você ignorar os problemas de servir arquivos estáticos e pode muitas vezes fazer páginas web serem carregads mais rapidamente (especialmente quando em uma CDN).
\nQuando usar estes serviços, o processo básico será parecido como o acima, exceto que no lugar de usar o rsync para transferir seus arquivos estáticos para o servidor, você irá precisa transferir os arquivos estáticos para fornecedor do armazenamento ou CDN.
Existem inúmeras maneiras para fazer isso, mas se o provedor tem uma API um um backend personalizado para armazenamento de arquivo fará o processo incrivelmente simples. Se você escreveu ou está usando um “backend” de armazenamento personalizado de terceiros, você pode avisar o collectstatic para usá-lo definido STATICFILES_STORAGE para o mecanismo de armazenamento.
Por exemplo, se você escreveu um backend de armazenamento para o S3 em myproject.storage.S3Storage você poderia usar isso com:
STATICFILES_STORAGE = 'myproject.storage.S3Storage'\nUma vez isso feito, tudo que tem a fazer é executar collectstatic e seus arquivos estáticos deveriam ser então colocados através do seu pacote de armazenamento no S3. Se você mais tarde precisar trocar para um provedor de armazenamento diferente, isso deveria ser tão fácil quando alterar suas configurações no STATICFILES_STORAGE.
Para detalhes sobre como escrever um destes backends, veja Escrevendo um sistema de armazenamento personalizado. Existem aplicações de terceiros disponíveis que fornecem backends de armazenamento para muitas APIs de armazenamento comuns. Um bom começo é uma olhada geral no djangopackages.com.
\nPara detalhes completos sobre todas as configurações, comandos, tags de templates, e outras partes incluidas em django.contrib.staticfiles, veja a referencia de arquivos estáticos.