Django本身不提供文件; 它将该作业留给您选择的任何Web服务器。 我们建议使用单独的Web服务器 - 即不是也在运行Django的服务器 - 用于服务媒体。 以下是一些不错的选择：
- Nginx
- 精简版的Apache
但是，如果您没有选择，只能在与Django相同的Apache VirtualHost上提供媒体文件，则可以将Apache设置为将某些URL作为静态媒体提供，而将其他设备用于使用Django的mod_wsgi接口。
此示例在站点根目录中设置Django，但将/ robots.txt，favicon.ico，任何CSS文件以及/ static /和/ media / URL空间中的任何内容显式地作为静态文件提供。 所有其他URL将使用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>
如果您使用的是2.4以前版本的Apache，请将Require all granted替换为Allow from all，并且添加 line Order deny，允许在其之上。
提供管理文件
当django.contrib.staticfiles在INSTALLED_APPS中时，Django开发服务器会自动提供管理应用程序的静态文件（以及其他已安装的应用程序）。 然而，当您使用任何其他服务器配置时，情况并非如此。 您负责设置Apache或您使用的任何Web服务器来为管理文件提供服务。
管理文件位于Django发行版的（django / contrib / admin / static / admin）中。 我们强烈建议使用django.contrib.staticfiles来处理管理文件（以及上一节中概述的Web服务器;这意味着使用collectstatic management命令来收集STATIC_ROOT中的静态文件，然后配置您的Web服务器以进行服务 STATIC_URL在STATIC_URL），但这里有三种其他方法：
-
从文档根目录中创建一个到管理静态文件的符号链接（这可能需要在Apache配置中添加+ FollowSymLinks）。
-
如上所示，使用Alias指令将相应的URL（可能是STATIC_URL + admin /）别名到管理文件的实际位置。
-
复制管理静态文件，以便它们位于Apache文档根目录中。
如果你得到一个Unicodeencodeerror
如果您正在利用Django的国际化功能，并且您打算允许用户上传文件，则必须确保用于启动Apache的环境已配置为接受非ASCII文件名。 如果您的环境未正确配置，则在调用包含非ASCII字符的文件名的os.path中的函数时，将触发UnicodeEncodeError异常。
为了避免这些问题，用于启动Apache的环境应包含类似于以下内容的设置：
export LANG='en_US.UTF-8'
export LC_ALL='en_US.UTF-8'
请参阅您操作系统的文档以获取适当的语法和位置以放置这些配置项; / etc / apache2 / envvars是Unix平台上的常见位置。 一旦将这些语句添加到您的环境中，请重新启动Apache。
在生产中提供静态文件
将静态文件投入生产的基本概述很简单：在静态文件更改时运行collectstatic命令，然后将收集的静态文件目录（STATIC_ROOT）安排到静态文件服务器并提供服务。
根据STATICFILES_STORAGE，可能需要手动将文件移动到新的位置，否则Storage类的post_process方法可能会处理此问题。
当然，就像所有部署任务一样，恶魔在细节上。 每个生产设置都会有所不同，因此您需要调整基本轮廓以适应您的需求。
以下是一些可能有所帮助的常见模式。
从同一服务器提供站点和您的静态文件
如果您想从已经为您的网站提供服务的同一服务器提供静态文件，则此过程可能如下所示：
- 将代码推送到部署服务器。
- 在服务器上运行collectstatic将所有静态文件复制到STATIC_ROOT。
- 配置您的Web服务器以在STATIC_URL下的STATIC_ROOT中提供文件。
您可能希望自动执行此过程，特别是如果您拥有多个Web服务器。 有许多方法可以实现这种自动化，但许多Django开发人员喜欢Fabric的一种选择。
在下面和下面的章节中，我们将展示几个自动执行这些文件部署选项的fabfiles（即Fabric脚本）示例。 fabfile的语法非常简单，但不会在这里介绍; 请参阅Fabric的文档，以获取语法的完整说明。 因此，将静态文件部署到几个Web服务器的fabfile可能如下所示：
from fabric.api import *
# Hosts to deploy onto
env.hosts = ['www1.example.com', 'www2.example.com']
# Where your project code lives on the server
env.project_root = '/home/www/myproject'
def deploy_static():
with cd(env.project_root):
run('./manage.py collectstatic -v0 --noinput')
从专用服务器提供静态文件
大多数较大的Django站点使用单独的Web服务器（即，不是也在运行Django的服务器）来提供静态文件。 该服务器通常运行不同类型的Web服务器 - 速度更快但功能更少。 一些常见的选择是：
- Nginx
- 精简版的Apache
配置这些服务器超出了本文档的范围; 检查每个服务器的正确文档以获取指示。 由于您的静态文件服务器不会运行Django，因此您需要修改部署策略，如下所示：
- 当您的静态文件更改时，请在本地运行collectstatic。
- 将您的本地STATIC_ROOT到静态文件服务器推送到正在提供服务的目录中。 rsync是此步骤的常用选择，因为它只需传输已更改的静态文件的位。
下面是在fabfile中可能的外观：
from fabric.api import *
from fabric.contrib import project
# Where the static files get collected locally. Your STATIC_ROOT setting.
env.local_static_root = '/tmp/static'
# Where the static files should go remotely
env.remote_static_root = '/home/www/static.example.com'
@roles('static')
def deploy_static():
local('./manage.py collectstatic')
project.rsync_project(
remote_dir = env.remote_static_root,
local_dir = env.local_static_root,
delete = True
)
从云服务或CDN提供静态文件
另一种常见策略是从Amazon S3和/或CDN（内容交付网络）等云存储提供商处提供静态文件。 这可以让您忽略服务静态文件的问题，并且通常可以使网页更快加载（特别是在使用CDN时）。
在使用这些服务时，基本工作流看起来有点像上面的，除了使用rsync将静态文件传输到服务器之外，您需要将静态文件传输到存储提供程序或CDN。 有多种方式可以做到这一点，但如果提供者具有API，则自定义文件存储后端将使该过程变得非常简单。
如果您已经编写或正在使用第三方自定义存储后端，则可以通过将STATICFILES_STORAGE设置为存储引擎来告诉collectstatic使用它。 例如，如果您在myproject.storage.S3Storage中编写了S3存储后端
你可以使用它：
STATICFILES_STORAGE = 'myproject.storage.S3Storage'
完成之后，您只需运行collectstatic，并将静态文件通过存储包推送到S3。 如果以后需要切换到不同的存储提供商，则可以像更改STATICFILES_STORAGE设置一样简单。 有第三方应用程序可用于为许多常见的文件存储API提供存储后端。 djangopackages.com提供了一个很好的起点。
网友评论