Question

我们将S3Storage与CachedFilesMixin和静态模板标签一起使用，以便从Cloud Front提供我们的文件。在打包我们的应用程序时，我们运行collect static来生成哈希并将文件同步到S3。它运作得很好。但是有一个问题让我感到担忧。

问题是因为我们进行了滚动升级。当我们推出新版本的应用程序时，这会产生两种形式的不一致：

1）在我们调用collectstatic / clear cache之前，任何运行新代码的服务器都不会看到他们期望的新资产。 2）在调用collectsstatic / clear cache之后，任何运行旧代码的服务器都会看到它不期望的新资产。

我正在考虑几种选择，如果有人已经解决了这个问题或者有反馈，我只是很好奇。

1）删除CachedFilesMixin并添加应用程序＆＃34;版本＆＃34;作为S3Storage的位置。这本质上是＆＃34;版本＆＃34;资产。这里的缺点是我们失去了高级别的缓存，用户每次部署应用程序时都必须重新下载文件

2）扩展CacheFilesMixin并提供基于＆＃34;版本化＆＃34;计算哈希的能力。文件。在调用collect static之后，我会将当前未散列的文件上传到S3上的版本文件夹。 CachedFilesMixin将从版本文件夹中提取文件以计算哈希值。

编辑：2014年9月17日 - 第三个选项（目前我最喜欢的）

3）覆盖我们的存储类，以便＆＃34;打开＆＃34;将从本地光盘读取。更新缓存以使用本地内存缓存。这意味着当存在高速缓存未命中时，它将具有光盘上的本地文件。

编辑：2014年9月18日 - 找到解决方案

我最终得到＃3工作，虽然与最初的想法略有不同。以下是我采取的步骤。

1）删除S3Storage简单的事情 2）创建一个新的Storage类，它继承StaticFileStorage并覆盖url以提供云前端URL。

class LocalStorageWithCloudFrontUrl(StaticFilesStorage):

    # This url is on the super class so that mix can fire first to provide the hash name functionality..
    def url(self, name, *args, **kwargs):
       return 'https://{0}/{1}'.format(STATIC_DOMAIN, name)

3）我的存储类现在继承自这个新类

class StaticStorage(PipelineMixin, CachedFilesMixin, LocalStorageWithCloudFrontUrl):

4）将我的缓存更新为内存缓存中的本地

'staticfiles': {
    'BACKEND': 'django.core.cache.backends.locmem.LocMemCache',
    'LOCATION': 'staticfiles-filehashes'
}

5）在我的测试中包作业我调用collect static然后调用aws sync将散列文件推送到S3。

6）现在S3将包含所有散列版本，以及最新版本的未散列文件，但这些文件从未使用过，因为CachhedFilesMixin将使用本地文件系统上的文件生成哈希值

如果收集静态将推送到S3，这将是很好的，但否则这似乎工作得很好。

使用CachedFilesMixin + S3滚动部署

0 个答案: