Firebase 存储工件巨大且不断增加

Posted 2023-02-22

【中文标题】Firebase 存储工件巨大且不断增加

【英文标题】：Firebase storage artifacts is huge and keeps increasing

【发布时间】：2020-12-29 18:43:05

【问题描述】：

我刚刚注意到，在过去几周内，我的应用的存储空间几乎达到了 5GB 的免费使用限制。仔细检查后，似乎这是由“artifacts”桶引起的。

我看到this SO question 说“artifacts”存储桶与 Node 10 环境有关。

我确实在一个月前搬到了 Node 10，但在发现日志不再在 firestore 函数控制台中结构化后，几天后我又回到了 Node 8，从那时起只使用 Node 8。

但是我可以看到“工件”存储量每周都在以大约 800Mb 的速度增长，这至少让我担心（请查看下面的屏幕截图）

我认为这与 Firestore 功能部署有关（或不？），但这真的是预期的吗？我可以安全地清理这些工件吗？

在我看来很奇怪，它在短短几周内急剧增加，而之前我使用函数几年并且从未遇到过这样的问题。

感谢有关在这种情况下如何安全处理存储大小并将其消耗保持在最低限度的任何建议。

我也在使用pubsub.schedule 函数以防万一。

我还注意到“工件”的带宽出人意料地飙升，我猜这也有成本影响，我也很感激任何关于尽可能减少这种峰值的方法的意见（22.5GB 中的大约 22GB 来自“工件”桶）：

【参考方案1】：

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

进入谷歌云控制台，选择你的项目->存储->浏览器https://console.cloud.google.com/storage/browser

选择“工件”存储桶

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

现在存储是安全的！

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

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

【讨论】：

我也很惊讶，我以为有人入侵了我的数据库：D，因为我得到了大约 82 个对象和大约 16 Mb 的总存储空间。但我的云存储显示我存储了 443Mb。我只使用云功能来存储评分和计算 cmets。你能解释一下这里发生了什么吗，我像上面一样检查了我的存储桶详细信息。当我检查我的 us.artifacts 时，有很多带有图像的文件，有些文件包含超过 60 MB。我什至没有使用功能来改变图像质量。您从哪里找到与此相关的信息？或者你能解释一下幕后的情况吗？

@IsuruBandara - 这一切对我来说都很出乎意料，所以我开始用谷歌搜索，发现了一个关于“它是什么？”的类似问题。在 SO 的另一个线程中 - 我在我的问题中包含了该链接。正如弗兰克在那里提到的，如果您使用 Node10+，这就是 firebase 现在处理功能部署的方式。正如 Doug 在这里确认的那样，现在这是一种预期的行为，我希望它会在某个时候改变。

更多信息在这里：***.com/a/64144324/2228559

我 90% 确定此设置会导致云功能部署失败。我认为这是最近的问题：***.com/questions/67338215/…。其他人看到了吗？

@SameerMadan 如果您遇到部署问题，您可以尝试在工件中手动删除整个“容器”文件夹并尝试再次重新部署。 （只要确保不要删除工件存储桶本身）

【参考方案2】：

除了针对工件图像的 GCP 生命周期设置之外，您还可以考虑以下事项以进一步优化 Firebase Functions 部署并降低成本：

清理您的functions 文件夹，不要将不必要的文件放入其中，因为我们不知道 Google 是否只会通过依赖项或通过整个functions 文件夹。如果你们中的任何人可以确认这一点，请随时完善此项目。 从您的 JS 文件中的 functions/package.json、functions/node_modules 和 require 语句中删除不必要的依赖项，例如functions/index.js。 压缩和压缩函数的 JS 文件，通过删除不必要的 cmets、控制台日志等。您可以借助 grunt 和 uglify NPM 包来实现此目的。同样，我们不确定 Cloud Build（或任何 Google 功能部署系统）是否会在将它们存储到 Container Registry 或 Cloud Storage 之前为我们自动压缩功能的图像（请细化如果您有更好的答案，请选择此项）。 由creating relevant function groups 正确组织您的功能，这样您就可以只部署某些功能组，而不仅仅是firebase deploy --only functions。 如有必要，编写自动检测和解决环境差异的代码，例如从本地模拟器到生产/登台的环境变量，因为 Firebase 模拟器和生产环境可能不是 100% 一致的。如果您不这样做，由于某些疏忽，您最终可能需要每天部署多次 - 这会增加您的部署成本。 如有必要，更改您的部署计划：从每天改为每周，甚至从每周改为每月，具体取决于您的每月预算、重要性和紧迫性。

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

【讨论】：

哟，如果我删除整个文件夹，我用firebase设置的env文件也会消失吗？

【参考方案3】：

我认为这与部署 Firestore 功能有关（或不部署？），但这真的可以预期吗？

是的，这是意料之中的。每次部署函数时，Cloud Build 都会为构建的 docker 镜像使用一个专用的 Cloud Storage 空间，并保留它直到您将其删除。

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

是的，但是您将无法轻松恢复到之前的图像。您必须从自己的源代码再次部署。

【讨论】：

谢谢面团。有没有办法管理这个过程，所以它不会消​​耗这么大的空间？有没有上限，还是会随着未来的部署而无限期地增加？我想它以前从来没有这样的行为。

完全由您来制定和执行计划，以适合您偏好的方式控制成本。每次部署都需要更多空间，因此您应该根据需要管理空间。

关于如何控制这个过程的任何文档/参考资料？目前，从您的回答来看，默认情况下它会不断增加，除非我们以某种方式明确控制它。如果您能详细说明，将不胜感激。

我不知道。网络搜索可能会有所帮助。

嘿@DougStevenson，当您说部署功能时，您是什么意思。您的意思是每次运行一个函数时，例如在我的应用程序中，如果我以这样一种方式制作它，即每次单击按钮时都会运行云函数来执行服务器功能，我的存储空间是否会每次增加，或者我的函数占用的存储空间只会在我创建新函数时增加，这意味着如果我一年不编辑或创建新函数，函数占用的存储空间也不会增加一年？请回答谢谢