The basic outline of putting static files into production consists of two\nsteps: run the collectstatic command when static files change, then\narrange for the collected static files directory (STATIC_ROOT) to be\nmoved to the static file server and served. Depending on\nSTATICFILES_STORAGE, files may need to be moved to a new location\nmanually or the post_process method of\nthe Storage class might take care of that.
As with all deployment tasks, the devil’s in the details. Every production\nsetup will be a bit different, so you’ll need to adapt the basic outline to fit\nyour needs. Below are a few common patterns that might help.
\nSe você quer servir arquivos estáticos do mesmo servidor que já está servindo seu site , o processo talvez se pareça com algo como:
\nEnvie seu código para o servidor de deploy.
No servidor, execute: collectstatic para copiar 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ê irá provavelmente querer automatizar o processo, especialmente se você possuir múltiplos servidores web.
\nA maioria dos grandes sites Django usa um servidor Web separado – isto é, um que não está servindo também o 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.
Uma outra tática comum é servir arquivos estáticos de provedores de armazenamento em nuvem como o S3 da Amazom e/ou um CDN (Rede de distribuição de conteúdo). Isso deixa você ignorar os problemas de servir arquivos estáticos e pode muitas vezes fazer páginas web serem carregadas 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.
There’s any number of ways you might do this, but if the provider has an API,\nyou can use a custom file storage backend\nto integrate the CDN with your Django project. If you’ve written or are using a\n3rd party custom storage backend, you can tell collectstatic to use\nit by setting STATICFILES_STORAGE to the storage engine.
Por exemplo, se você escreveu um backend de armazenamento para o S3 em myproject.storage.S3Storage você poderia ele com:
STATICFILES_STORAGE = 'myproject.storage.S3Storage'\nOnce that’s done, all you have to do is run collectstatic and your\nstatic files would be pushed through your storage package up to S3. If you\nlater needed to switch to a different storage provider, you may only have to\nchange your STATICFILES_STORAGE setting.
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 comuns 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.