“Django/docs/2.2.x/howto/static-files/deployment”的版本间差异
(autoload) |
小 (Page commit) |
||
第1行: | 第1行: | ||
+ | {{DISPLAYTITLE:部署静态文件 — Django 文档}} | ||
<div id="deploying-static-files" class="section"> | <div id="deploying-static-files" class="section"> | ||
第5行: | 第6行: | ||
<div class="admonition seealso"> | <div class="admonition seealso"> | ||
− | + | 也可以看看 | |
− | + | 关于使用的介绍 [[../../../ref/contrib/staticfiles#module-django.contrib|django.contrib.staticfiles]] , 看管理静态文件(例如 图片、JavaScript、CSS) . | |
第16行: | 第17行: | ||
== 在生产环境提供静态文件服务 == | == 在生产环境提供静态文件服务 == | ||
− | + | 将静态文件投入生产的基本大纲很简单:当静态文件发生变化时运行[[#id1|:djadmin:`collectstatic`]]命令,然后安排收集的静态文件目录([[#id3|:setting:`STATIC_ROOT`]] ) 移动到静态文件服务器并提供服务。 根据 [[#id5|:setting:`STATICFILES_STORAGE`]],文件可能需要手动移动到新位置,或者 <code>Storage</code> 类的 [[../../../ref/contrib/staticfiles#django.contrib.staticfiles.storage.StaticFilesStorage|post_process]] 方法可能会处理这个问题. | |
− | + | 当然,与所有部署任务一样,细节决定成败。 每个制作设置都会有所不同,因此您需要调整基本轮廓以满足您的需求。 以下是一些可能会有所帮助的常见模式。 | |
<div id="serving-the-site-and-your-static-files-from-the-same-server" class="section"> | <div id="serving-the-site-and-your-static-files-from-the-same-server" class="section"> | ||
第24行: | 第25行: | ||
=== 在同一服务器提供站点和静态文件服务 === | === 在同一服务器提供站点和静态文件服务 === | ||
− | + | 如果您想从已经为您的站点提供服务的同一台服务器上提供静态文件,该过程可能如下所示: | |
* 将代码推送至部署服务器。 | * 将代码推送至部署服务器。 | ||
− | * | + | * 在服务器端运行[[#id7|:djadmin:`collectstatic`]],将所有静态文件复制到[[#id9|:setting:`STATIC_ROOT`]]。 |
− | * | + | * 配置您的 Web 服务器以提供 URL [[#id13|:setting:`STATIC_URL`]] 下的 [[#id11|:setting:`STATIC_ROOT`]] 中的文件。 例如,这里是 [[../../deployment/wsgi/modwsgi#serving-files|如何使用 Apache 和 mod_wsgi]] 执行此操作。 |
− | + | 您可能希望自动化此过程,尤其是当您有多个 Web 服务器时。 | |
第38行: | 第39行: | ||
=== 专用服务器提供静态文件服务 === | === 专用服务器提供静态文件服务 === | ||
− | + | 大多数较大的 Django 站点使用单独的 Web 服务器(即,不运行 Django 的服务器)来提供静态文件。 该服务器通常运行不同类型的 Web 服务器——速度更快但功能较少。 一些常见的选择是: | |
− | * [https://nginx.org/en/ | + | * [https://nginx.org/en/ nginx] |
− | * | + | * [https://httpd.apache.org/ Apache] 的精简版 |
− | + | 配置这些服务器超出了本文档的范围; 检查每个服务器各自的文档以获取说明。 | |
− | + | 由于您的静态文件服务器不会运行 Django,您需要将部署策略修改为如下所示: | |
− | * | + | * 当您的静态文件更改时,请在本地运行 [[#id15|:djadmin:`collectstatic`]]。 |
− | * | + | * 将您的本地 [[#id17|:setting:`STATIC_ROOT`]] 推送到静态文件服务器到正在提供服务的目录中。 [https://rsync.samba.org/ rsync] 是这一步的常用选择,因为它只需要传输已更改的静态文件的位。 |
第57行: | 第58行: | ||
=== 从云服务或 CDN 提供静态文件服务 === | === 从云服务或 CDN 提供静态文件服务 === | ||
− | + | 另一种常见的策略是从云存储提供商(如 Amazon 的 S3 和/或 CDN(内容交付网络))提供静态文件。 这让您可以忽略提供静态文件的问题,并且通常可以加快网页加载速度(尤其是在使用 CDN 时)。 | |
− | + | 使用这些服务时,基本工作流程看起来有点像上面的,除了使用 <code>rsync</code> 将静态文件传输到服务器时,您需要将静态文件传输到存储提供商或 CDN . | |
− | + | 有很多方法可以做到这一点,但如果提供者有一个 API,一个 [[../../custom-file-storage|自定义文件存储后端]] 将使这个过程非常简单。 如果您已经编写或正在使用 3rd 方自定义存储后端,您可以通过将 [[#id21|:setting:`STATICFILES_STORAGE`]] 设置为存储来告诉 [[#id19|:djadmin:`collectstatic`]] 使用它引擎。 | |
− | + | 例如,如果您在 <code>myproject.storage.S3Storage</code> 中编写了一个 S3 存储后端,则可以将其用于: | |
<div class="highlight-default notranslate"> | <div class="highlight-default notranslate"> | ||
第69行: | 第70行: | ||
<div class="highlight"> | <div class="highlight"> | ||
− | < | + | <syntaxhighlight lang="python">STATICFILES_STORAGE = 'myproject.storage.S3Storage'</syntaxhighlight> |
</div> | </div> | ||
</div> | </div> | ||
− | + | 完成后,您所要做的就是运行 [[#id23|:djadmin:`collectstatic`]],您的静态文件将通过您的存储包推送到 S3。 如果您以后需要切换到不同的存储提供程序,它可能就像更改您的 [[#id25|:setting:`STATICFILES_STORAGE`]] 设置一样简单。 | |
− | + | 有关如何编写这些后端之一的详细信息,请参阅 [[../../custom-file-storage|编写自定义存储系统]] 。 有 3rd 方应用程序可以为许多常见的文件存储 API 提供存储后端。 一个很好的起点是 djangopackages.org [https://djangopackages.org/grids/g/storage-backends/ 上的] 概述。 | |
第86行: | 第87行: | ||
== 了解更多 == | == 了解更多 == | ||
− | + | 有关 [[../../../ref/contrib/staticfiles#module-django.contrib|django.contrib.staticfiles]] 中包含的所有设置、命令、模板标签和其他部分的完整详细信息,请参阅 [[../../../ref/contrib/staticfiles|静态文件参考]] 。 | |
第92行: | 第93行: | ||
</div> | </div> | ||
+ | <div class="clearer"> | ||
− | [[Category:Django 2.2.x | + | |
+ | |||
+ | </div> | ||
+ | |||
+ | [[Category:Django 2.2.x 文档]] |
2021年10月31日 (日) 04:04的最新版本
部署静态文件
在生产环境提供静态文件服务
将静态文件投入生产的基本大纲很简单:当静态文件发生变化时运行:djadmin:`collectstatic`命令,然后安排收集的静态文件目录(:setting:`STATIC_ROOT` ) 移动到静态文件服务器并提供服务。 根据 :setting:`STATICFILES_STORAGE`,文件可能需要手动移动到新位置,或者 Storage
类的 post_process 方法可能会处理这个问题.
当然,与所有部署任务一样,细节决定成败。 每个制作设置都会有所不同,因此您需要调整基本轮廓以满足您的需求。 以下是一些可能会有所帮助的常见模式。
在同一服务器提供站点和静态文件服务
如果您想从已经为您的站点提供服务的同一台服务器上提供静态文件,该过程可能如下所示:
- 将代码推送至部署服务器。
- 在服务器端运行:djadmin:`collectstatic`,将所有静态文件复制到:setting:`STATIC_ROOT`。
- 配置您的 Web 服务器以提供 URL :setting:`STATIC_URL` 下的 :setting:`STATIC_ROOT` 中的文件。 例如,这里是 如何使用 Apache 和 mod_wsgi 执行此操作。
您可能希望自动化此过程,尤其是当您有多个 Web 服务器时。
专用服务器提供静态文件服务
大多数较大的 Django 站点使用单独的 Web 服务器(即,不运行 Django 的服务器)来提供静态文件。 该服务器通常运行不同类型的 Web 服务器——速度更快但功能较少。 一些常见的选择是:
配置这些服务器超出了本文档的范围; 检查每个服务器各自的文档以获取说明。
由于您的静态文件服务器不会运行 Django,您需要将部署策略修改为如下所示:
- 当您的静态文件更改时,请在本地运行 :djadmin:`collectstatic`。
- 将您的本地 :setting:`STATIC_ROOT` 推送到静态文件服务器到正在提供服务的目录中。 rsync 是这一步的常用选择,因为它只需要传输已更改的静态文件的位。
从云服务或 CDN 提供静态文件服务
另一种常见的策略是从云存储提供商(如 Amazon 的 S3 和/或 CDN(内容交付网络))提供静态文件。 这让您可以忽略提供静态文件的问题,并且通常可以加快网页加载速度(尤其是在使用 CDN 时)。
使用这些服务时,基本工作流程看起来有点像上面的,除了使用 rsync
将静态文件传输到服务器时,您需要将静态文件传输到存储提供商或 CDN .
有很多方法可以做到这一点,但如果提供者有一个 API,一个 自定义文件存储后端 将使这个过程非常简单。 如果您已经编写或正在使用 3rd 方自定义存储后端,您可以通过将 :setting:`STATICFILES_STORAGE` 设置为存储来告诉 :djadmin:`collectstatic` 使用它引擎。
例如,如果您在 myproject.storage.S3Storage
中编写了一个 S3 存储后端,则可以将其用于:
STATICFILES_STORAGE = 'myproject.storage.S3Storage'
完成后,您所要做的就是运行 :djadmin:`collectstatic`,您的静态文件将通过您的存储包推送到 S3。 如果您以后需要切换到不同的存储提供程序,它可能就像更改您的 :setting:`STATICFILES_STORAGE` 设置一样简单。
有关如何编写这些后端之一的详细信息,请参阅 编写自定义存储系统 。 有 3rd 方应用程序可以为许多常见的文件存储 API 提供存储后端。 一个很好的起点是 djangopackages.org 上的 概述。