如何以最低成本将简单应用部署到 GCP或如何在部署后禁用自动缩放？ 更新 #1更新 #2

如何解决如何以最低成本将简单应用部署到 GCP或如何在部署后禁用自动缩放？ 更新 #1更新 #2

在我第一次尝试使用 Cloud 部署应用程序时...

问题： GCP (Google Cloud Platform) 意外实例小时使用量 (Frontend Instance Hours)。 高流量不是问题，但由于某种原因，创建了一堆“实例”和“版本” 通过他们的自动缩放功能。

他们建议的解决方案： 禁用自动缩放并停止为之前部署的实例版本提供服务。 我仍然需要运行一个版本/实例，但通过他们的控制台我仍然没有找到 它显示我运行了多少个版本/实例或在哪里停止它们 （还要验证至少有 1 个实例仍在工作，以免破坏我的应用）

我的应用是由 Google 开发人员开发并由他们推荐用于动态呈现 JS SPA（允许搜索引擎和抓取工具查看完全呈现的 html）的简单应用。
我的实际网站与节点应用程序一起指向 GCP 爬虫托管在其他地方（在 Godaddy 上） 并且两人合作得很好。

我部署到 GCP 的应用叫做 rendertron (https://github.com/GoogleChrome/rendertron)

Google 还建议部署到 GCP （大多数文档都涵盖了这种部署形式）。 我尝试部署到我的 Godaddy 共享主机，但这并不简单易行 为了工作，所以我只是尝试创建一个 GCP 项目并尝试在那里部署。 一切都很棒！

将应用部署到几乎没有流量的 GCP 后， 我期望零成本或最多低于 1 美元。

很遗憾，我收到了当月超过 150 美元的账单 下个月的预测大致相同。

无需额外支付 150 美元的技术支持费用，我就能联系 GCP 结算 通过电话，他们很棒，因为他们愿意报销费用 但只有在我自己解决问题之后。

他们慷慨地向你扔了一组文档链接 （意外实例小时使用的常见原因） 但无能为力。

经过多次谷歌搜索，阅读文档， 通过plexsight.com支付和观看gcloud教程， 目前我了解或不了解的方向如下：

• 几乎所有文档、视频和教程都讨论了管理或关闭自动缩放 使用 Compute Engine 实例组
• 不清楚实例组是不是我会陷入的另一个漏洞是付费服务 我将被收取超过必要的费用
• 对于一个只希望以最低成本运行一个实例的简单应用来说，实例组似乎有点过分
• 关于如何使用最少的资源以最少的成本运行非常小规模的应用程序的文档不够或很难找到
• 我还没有阅读或观看任何关于如何简单地使用 config .yaml 文件（最初部署）来确保应用程序不会自动缩放以及如果我发现似乎我仍然需要删除版本或实例的任何内容已经开始，但不清楚如何做。
• google 控制台上的实例和版本不清楚有多少正在运行，我仍然没有在 google 控制台上找到运行多个实例/版本的地方。

我可以使用一个指示来继续尝试调查如何解决问题。

1. 我需要创建一个组实例的方向（所以我可以 从那里管理无自动缩放）是要走的路，我应该把我的尝试集中在哪里？

2. 继续学习如何简单地更新 .yaml 文件中的配置以创建无缩放的方向，例如将 min_instances 和 max_instances 设置为 1 以及学习如何手动停止（直接从 GCP 控制台） ) 目前正在运行的 1 个以上的实例/版本是我应该关注的地方吗？

3. 第三种选择？

顺便说一句，使用 GCP 进行自动缩放似乎不是很智能。
为什么我的几乎没有流量的应用会遇到创建多个实例的问题？

任何见解将不胜感激。

**** 更新 **** 平台信息

我的应用已部署到 Google App Engine (GAE) （部署的代码，不是容器）

部署步骤：

git clone https://github.com/GoogleChrome/rendertron.git
cd rendertron
npm install && npm run build
gcloud app deploy app.yaml --project MY_PROJECT_ID

我只是按照上面的步骤操作，我的应用程序一直在运行 很好，自部署以来没有碰过任何东西。

最初部署的配置（app.yaml）是：
（我没有从 rendertron 存储库中对其进行任何更改）

runtime: nodejs12
instance_class: F4_1G
automatic_scaling:
  min_instances: 1
env_variables:
  disABLE_LEGACY_MetaDATA_SERVER_ENDPOINTS: "true"

-- Google Cloud Console 信息

在 App Engine 下 --> 版本
列出了 1 个具有以下值的项目：

Instances: 1
Runtime: nodejs12

环境：标准

Size: 392.7 MB
Deployed: Feb 23,2021
Config:
  runtime: nodejs12
  env: standard
  instance_class: F4_1G
  handlers:
    url: .*
    script: auto
  env_variables:
    disABLE_LEGACY_MetaDATA_SERVER_ENDPOINTS: 'true'
  automatic_scaling:
    min_idle_instances: automatic
    max_idle_instances: automatic
    min_pending_latency: automatic
    max_pending_latency: automatic
    min_instances: 1
  network: {}

**** 解决方案 ****
我上传了一个新的 app.yaml 文件并更改了： min_instances: 1 到 max_instances: 1 （必须使用更新的 app.yaml 重新部署整个项目）

一开始我也是为了省钱，把“instance_class”从F4_1G改成了F1， 但是我在我的应用程序中收到一个错误，提示内存不足，并且我的应用程序因 500 服务器错误而崩溃。 （渲染器应用程序出现但在尝试渲染某些内容时崩溃） 我再次将其更新回 F4_1G，该应用似乎可以正常运行。

如果我在未来流量上升时再次看到收费，我会检查 F1 到 F4_1G 之间是否有一个实例类可以为我的应用工作提供足够的内存，但累积可能的最低收费。

您可以在下面看到，当我在周五进行更改时，直到下周日，成本降至 0，但应用程序仍在正常运行：
Screenshot showing GCP billing report costs dropped after change
**** 解决方案 ****

解决方法

rendertron 存储库建议使用 App Engine 标准 (app.yaml)，因此我认为这就是您使用的。

如果您使用的是 App Engine 标准，则：

• 您未使用 Compute Engine [实例组]，因为这些资源由 App Engine flexible（非标准）使用；
• 管理多个部署不应该成为问题，因为维护多个非流量接收版本的标准不收费（！？），并且应该自动为您将流量从当前版本迁移到新版本。

App Engine 标准至少有 2 个关键变量：您使用的 App Engine 实例的大小及其数量：

1. 您可能希望使用（更便宜的）实例类 (link)。
2. 您可以通过 max_instances: 1 来限制实例数 (link)。

看来您的带宽使用率很低（并且在很大程度上会受到上述限制）但也要记住这一点，以及...

您的应用很可能暴露在公共互联网上，因此很容易消耗来自偶然发现您的端点并GET它的抓取工具和其他“参与者”的流量。

如您所见，很容易过度消耗（基于云的）资源并面临超出预期的账单。 GCP 中有一些控件可让您监控（不一定是消除）大额账单 (link)。

唯一真正的解决方案是尽可能熟悉该平台及其资源的定价方式。

更新 #1

我的偏好是使用 gcloud (CLI) 来管理服务，但我认为您的偏好是控制台。

当您将“应用”部署到 App Engine 时，它​​包含 >=1 个服务 (default)。我已经部署了最简单的“Hello World！”包含单个 default 服务 (Node.JS) 的应用：

https://console.cloud.google.com/appengine/services?serviceId=default&project=[[YOUR-PROJECT-ID]]

我部署了多次 (3) 次，就好像我在改进应用程序一样。在“版本”页面上，列出了 3 个版本：

https://console.cloud.google.com/appengine/versions?serviceId=default&project=[[YOUR-PROJECT-ID]]

注意 平台上存储了多个版本，但只有最新版本提供（和 100%）流量。 IIRC App Engine 标准不收取存储多个版本的费用。

我调整了配置 (app.yaml) 以指定 instance_class (F1) 并限制 max_instances: 1：

app.yaml：

runtime: nodejs14
instance_class: F1
automatic_scaling:
  max_instances: 1

而且，这反映在部署的应用程序的配置中：

更新 #2

如果您可以鼓励某人编写 Dockerfile 并将其贡献给 rendertron 存储库，那么您可以将容器部署到各种替代服务（Google 和非 Google）。

App Engine 标准的一个奇怪事实是，当您将“代码”部署到平台时，它会根据您的工件创建一个容器映像，这就是部署到 App Engine 的内容。您可以通过查看项目中的 Container Registry（服务）来证明这一点：

https://console.cloud.google.com/gcr/images/dazwilkin-210503-67357098?project=[[YOUR-PROJECT-ID]]

而且，如果您愿意，可以在其他地方重复使用该图像。

Google Cloud Run 可能是您在 Google 上的最佳选择。 Cloud Run 允许您限制您运行的实例数量，并且您可以更轻松地将已部署应用的访问权限限制为经过身份验证的用户。

使用容器，您可以在任何运行容器即服务的地方部署 rendertron。

,

配置了 automatic_scaling，这是一个可选配置。
其他可用选项是 basic_scaling 和 manual_scaling。

最便宜的配置可能是带有单个 manual_scaling 实例的 B1：

instance_class: B1
manual_scaling:
  instances: 1

这两个配置参数直接影响定价，即“按配置付费”。

虽然这可能不是生产的建议配置。
有关更多信息，请参阅 scaling elements 和 princing。