我一直在尝试Google的Deployment Manager GitHub项目中提供的this示例。
它可以工作，但是我不确定创建三个instances，instance_create和instance_update的{{1}}的目的。
例如，摘自链接：
instance_delete答案 0 :(得分：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命令，这些模板将由Deployment Manager顺序构建和执行。请注意，它们可能会出现乱序，这是由于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，而是指定{{1 }}），则使用bigtableadmin-v2:bigtableadmin.projects.instances.create标签。我在任何地方都没有发现使用上的区别，但是需要像这样指定。
如果资源以create / update / delete结尾，您将知道是否直接调用API“端点”。
最后，我在我这边进行了调查，action与资源类型是API调用这一事实有关（就像上一点一样）。再一次，我在任何地方都找不到此文件。
但是，由于这是必要条件，因此您将始终必须在此字段中设置正确的值。基本上可以归结为将metadata.runtimePolicy设置为此值，具体取决于您执行的API调用类型：
metadata.runtimePolicy
create -> ['CREATE']
update -> ['UPDATE_ON_CHANGE']
总结：
delete -> ['DELETE']标志更改为type。action值。