使用CachedFileMixin+S3滚动部署

Question

我们使用S3Storage和cachedFileMixin和静态模板标记从云前端提供我们的文件。在打包我们的应用程序时，我们运行collect static来生成哈希并将文件同步到S3。效果很好。但有一个问题让我很担心。在

这个问题之所以出现是因为我们进行滚动升级。这造成了两种形式的不一致，因为我们推出了新版本的应用程序：

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

我正在考虑几个选择，只是好奇是否有人已经解决了这个问题或得到了反馈。在

1）删除cachedFileMixin，并将应用“version”作为位置添加到S3Storage中。这基本上是“版本化”资产。这里的缺点是我们失去了高级别的缓存，用户必须在每次部署应用程序时重新下载文件

2）扩展CacheFilesMixin并提供基于“版本化”文件计算哈希的能力。调用collect static之后，我会将当前未处理的文件上载到S3上的一个版本文件夹中。cachedFileMixin将从版本文件夹中提取文件以计算哈希值。在

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

3）重写存储类，以便“打开”将从本地磁盘读取。更新缓存以使用本地内存缓存。这意味着当缓存未命中时，它将在磁盘上保存本地文件。在

编辑：9/18/2014-找到解决方案

我最终得到了3个工作，尽管与最初的想法略有不同。以下是我采取的步骤。在

1）将S3存储器移到简单的东西上 2） 创建了一个新的存储类，该类子类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）我的存储类现在继承了这个新类

^{pr2}$

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

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

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

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

如果collect static将被推到S3，这将是一件好事，但除此之外，这似乎工作得非常好。在