Google 部署管理器 - BigTable 示例答案

【问题标题】：Google Deployment Manager - BigTable exampleGoogle 部署管理器 - BigTable 示例
【发布时间】：2023-03-16 19:43:01
【问题描述】：

我一直在尝试 Google 的 Deployment Manager GitHub 项目中提供的 this 示例。

它有效，但我不确定创建三个名为 instance_create、instance_update 和 instance_delete 的 instances 的目的是什么。

例如，取自链接：

instance_create = {
      'name':
          'instance_create',
      'action':
          'gcp-types/bigtableadmin-v2:bigtableadmin.projects.instances.create',
      'properties': {
          'parent': project_path,
          'instanceId': instance_name,
          'clusters': copy.deepcopy(initial_cluster),
          'instance': context.properties['instance']
      },
      'metadata': {
          'runtimePolicy': ['CREATE']
      }
}

`action` 和 `metadata`.`runtimePolicy` 的目的是什么？我试图在文档中找到它，但失败了。为什么那里有三个 `BigTable` 实例？

【问题讨论】：

标签： google-cloud-platform google-cloud-bigtable google-deployment-manager

【解决方案1】：

您是对的，文档缺少信息，这将回答您有关这些参数的问题。

但是，了解您链接的 Depoyment Manager 示例中发生了什么会有所帮助。

首先，config.yaml 中的以下行是事情变得棘手的地方：

resources:
- name: my-bigtable
  type: bigtable.py

这一行将调用bigtable.py python 文件，该文件将部署的资源类型设置为GenerateConfig 函数下的资源类型。看看这是如何做到的here。

资源在其末尾以{'resources': resources} 的形式返回，作为资源变量，templates 的列表在那里创建。

这些模板有不同的名称标识符，由"name" 标签设置。因此，您没有在此文件中创建三个不同的实例，名称分别为 instance_create、instance_update 和 instance_delete，而是创建了三个具有这些名称的模板，稍后将附加到 resources 列表中，并且后来返回到 config.yaml resources.type 标签。一旦使用 create 命令，这些模板将由部署管理器按顺序构建和执行。请注意，它们可能出现乱序，这是由于not using a schema。

以.yaml 文件格式更容易看到此结构，例如，使用jinja 构建，您发布的模板将是：

resources:
- action: gcp-types/bigtableadmin-v2:bigtableadmin.projects.instances.create
  name: instance_create
  metadata:
    runtimePolicy:
    - CREATE
  properties:
    clusters:
      initial:
        defaultStorageType: HDD
        location: projects/<PROJECT_ID>/locations/<PROJECT_LOCATION>
        serveNodes: 4
    instance:
      displayName: My BigTable Instance.
      type: PRODUCTION
    instanceId: my-instance
    parent: projects/<PROJECT_ID>

注意properties 下的参数是fields in the request body to bigtableadmin.projects.instances.create（它嵌套了clusters object parameters 和instance object parameters）。请注意，属性下的 InstanceId 始终相同，因此模板调用的 BigTable 实例始终相同。

问题是，不仅您链接的示例创建了要在同一脚本中运行的各种模板，而且每个模板的资源类型is a call to the BigTable API。

通常使用type 标记指定模板资源，但由于您调用的是直接运行 API 调用的资源（即，您不只是指定gcp-types/bigtableadmin-v2，而是指定bigtableadmin-v2:bigtableadmin.projects.instances.create），@使用了 987654345@ 标签。我在任何地方都没有发现这种用法差异，但需要这样指定。如果资源以 create/update/delete 结尾，您将知道是否直接调用 API“端点”。

最后，我在我身边进行了调查，metadata.runtimePolicy 与资源类型是 API 调用这一事实相关（如前一点）。再一次，我还没有在任何地方找到这个记录。但是，由于这是一项要求，因此您始终必须在此字段中设置正确的值。基本上归结为将metadata.runtimePolicy 设置为此值，具体取决于您执行的 API 调用类型：

create -> ['CREATE']

update -> ['UPDATE_ON_CHANGE']

delete -> ['DELETE']

总结：

您创建的不是三个不同的实例，而是三个不同的模板，它们在同一个 BigTable 实例上工作。
如果您正在调用 API 端点（创建/更新/删除），则需要将资源 type 标志更改为 action，而不仅仅是命名基本 API。
metadata.runtimePolicy 值是调用上述端点之一时的要求。

【讨论】：