Firebase存储构件非常庞大，并且不断增加

我刚刚注意到，在过去几周内，我的应用程序的存储空间几乎达到了5GB的免费使用限制。在详细检查之后，似乎这是由“工件”桶造成的

我看到它说“工件”桶与节点10环境相关

我确实在一个月前移动到了节点10，但在发现firestore功能控制台中的日志不再是结构化的之后，我在几天后又返回到节点8，并从那时起只使用节点8

然而，我可以看到“工件”存储每周不断增加约800Mb，这至少让我感到担忧（请查看下面的屏幕截图）

我假设这与firestore功能的部署有关（是否？），但这真的是预期的吗？我可以安全地清理这些工件吗

在我看来很奇怪，它在几周内就急剧增加了，而之前我使用函数有几年了，从来没有出现过这样的问题

对于如何在这种情况下安全地处理存储大小并将其消耗量保持在最小值，请接受任何建议

我还使用了

pubsub.schedule

函数，以防它在这里起作用

我还注意到，“工件”的带宽意外增加，我想这也会带来成本影响，我也希望您能提供任何可能的方法来减少此类峰值（22.5GB中约22GB来自“工件”桶）：

我假设这与firestore功能的部署有关（是否？），但这真的是预期的吗

是的，这是意料之中的。每次部署功能时，Cloud Build都会为构建的docker映像使用专用的云存储空间，并将其保留到删除为止

我可以安全地清理这些工件吗

---

是的，但这样你就无法轻松还原到先前的图像。您必须从自己的源代码重新部署。

找到了一个解决方案-似乎有一种方法可以在谷歌云控制台中为那些使存储混乱的图像设置自动删除规则

转到google云控制台，选择您的项目->存储->浏览器

选择“工件”存储桶

在“生命周期”选项卡下，添加一条自动删除旧图像的规则（在我的情况下，我将“更新后1天后删除”，这对我来说很好）

现在仓库安全了

注意：如果您以后遇到任何部署问题，比如连续部署几天，如果在部署时出现错误，只需手动删除工件中的整个“容器”文件夹即可解决问题，然后重新部署。（确保不要删除工件存储桶本身！）

---

希望firebase团队能够改进这一点-当前的行为看起来令人困惑，因为它很容易导致意外的账单，除非您采取额外的措施来防止。但是，你永远不会知道它会发生，直到它发生。

< P>在GCP的<强>生命周期设置对于工件图像，你还可以考虑下面的进一步优化和降低你的FiBasic函数部署：

清理你的

函数

文件夹，不要在其中放入不必要的文件，因为我们不知道谷歌是否只会按依赖项或整个

函数

文件夹上传文件。如果你们中的任何人都能确认这一点，请随意修改这个项目

从JS文件中删除

函数/package.json

、

函数/node_模块

和

require

语句中不必要的依赖项，例如

函数/index.JS

通过删除不必要的注释、控制台日志等压缩和压缩函数的JS文件。您可以借助和

uglify

NPM软件包实现这一点。同样，我们不确定云构建（或任何谷歌功能部署系统）是否会在将功能图像存储到容器注册表或云存储之前为我们自动压缩功能图像（如果您有更好的答案，请细化此项）

正确组织您的功能，这样您就可以只部署特定的功能组，而不是简单地

firebase部署--只部署功能

如有必要，编写自动检测和解决环境差异的代码，例如从本地仿真器到生产/分段的环境变量，因为Firebase仿真器和生产环境可能不是100%一致的。如果不这样做，由于某些疏忽，您可能会每天需要部署几次——这将增加部署成本

如有必要，更改部署计划：根据每月预算、关键性和紧迫性，从每天更改为每周，甚至从每周更改为每月

---

最后，我希望社区也能在这篇文章中添加更多推荐的成本降低计划和策略，以帮助一些小企业和个人在Firebase和Google云平台上更好地生存。即使只是一些好文章的链接也会有所帮助。谢谢

谢谢你。有没有一种方法可以管理这个过程，这样它就不会占用这么大的空间？有没有上限，或者它会随着未来的部署而无限期地增加？我想它以前从来没有这样做过。完全由你来设计和执行一个计划，以符合你的喜好的方式控制成本。每次部署都需要更多的空间，因此您应该根据需要管理空间。有关于如何控制此过程的文档/参考资料吗？目前，从您的答案来看，默认情况下，它将保持递增