从网站上传图像时，Heroku 不会更新 github 文件系统

Question

当从网站创建博客文章（包括图片）时，我遇到了 Heroku 不更新我的 GitHub 存储库（或者说静态文件系统）的问题。

其他图像仍然存在，而保存在我的文件系统中且服务器在 heroku 上运行的图像消失了。

我在他们的文档中找到了这个。

Heroku 文件系统是短暂的 - 这意味着在 dyno 运行期间对文件系统的任何更改只会持续到该 dyno 关闭或重新启动。

我仍然很困惑，为什么不是所有图片都消失了，只有后来添加的图片才会消失。

AWS S3 是否可以解决这个问题？如果是，我如何使用存储桶来表示我的文件系统？

比如说，对于Blog Post 1，我有两种图片分辨率，这意味着将文件存储在与这些分辨率相对应的不同文件夹中。

---1920x1920
-----picture.jpg
---800x800
-----picture.jpg

这是否意味着我必须创建 2 个名为 1920x1920 和 800x800 的存储桶，还是有更好的方法来处理它们？

Answer 1

AWS S3 是否可以解决这个问题？

S3 是推荐的解决方案，配置为documented in Heroku DevCentre，具体说明为uploading from Python。

注意这些 Python 指令使用 直接上传 方法：让烧瓶应用程序生成一个预签名的 URL，然后将其传递回客户端 Javascript 代码，以便用户的浏览器可以使直接上传到S3。然后将生成的图像 S3 URL 放入表单中的隐藏元素中，然后由您的应用在表单提交时接收。

您拥有不同尺寸的图像这一事实表明您的应用会进行一些处理（可能使用 PIL）来获取这些缩略图。在这种情况下，使用 Pass-Through 方法可能更容易，您的应用程序实现自己的上传机制，进行处理，然后将缩略图上传到 S3（上传到 S3 部分是很好的文档，比如this SO thread)。

Pass-Through 方法带有警告，这可能会导致单线程工作线程阻塞。如果您的站点收到大量请求导致此问题成为问题，您可能需要增加 gunicorn 工作人员的数量，或更改为支持并发的工作人员类型（此github post 有一些关于并发工作人员的有用命令/信息类型）。

---

实现这一切的最佳方式（尽管对 redisgo dyno 和 worker dyno 的要求可能会将您推入付费阶段）可能是with Background Tasks using rq。您使用上面的 Direct-Upload 方法上传原始图像，然后下载后台作业，调整大小，然后将生成的缩略图放回 S3。

这是否意味着我必须创建 2 个名为 1920x1920 和 800x800 的存储桶，还是有更好的处理方法？

为整个应用程序创建一个 Bucket，只需在对象的键中包含正斜杠以模仿子目录结构。