ARTICLE DETAIL

资讯详情

深耕网站视觉设计与运营推广的一线实战洞察。

Terraform AWS Provider 中 aws_apigatewayv2_apis 数据源:批量发现与过滤 API Gateway V2 API(附源码解析)

Terraform AWS Provider 中 aws_apigatewayv2_apis 数据源:批量发现与过滤 API Gateway V2 API(附源码解析) Terraform AWS Provider 中 aws_apigatewayv2_apis 数据源批量发现与过滤 API Gateway V2 API附源码解析【免费下载链接】terraform-provider-awsThe AWS Provider enables Terraform to manage AWS resources.项目地址: https://gitcode.com/GitHub_Trending/te/terraform-provider-awsaws_apigatewayv2_apis是 Terraform AWS Provider 提供的聚合型数据源用于按名称、协议类型和标签等条件批量检索账号中所有的 Amazon API Gateway V2 APIHTTP API 与 WebSocket API并以标识符集合ids的形式输出结果。阅读本文你将掌握该数据源的完整参数用法、典型配置写法并能从 源码实现 中理解它的分页拉取、过滤匹配与标签比对逻辑从而在 Terraform 配置中可靠地驱动发现既有 API类的场景。数据源定位解决我不知道有哪些 API ID的问题API Gateway V2 的大部分配套资源路由aws_apigatewayv2_route、集成aws_apigatewayv2_integration、路由规则aws_apigatewayv2_routing_rule、部署aws_apigatewayv2_deployment等都需要以 API ID 作为关联键。但 API ID 是 AWS 自动生成的短字符串用户通常无法在配置中直接硬编码。aws_apigatewayv2_apis数据源注意复数形式区别于按单个 ID 查询的 aws_apigatewayv2_api 数据源正是为此设计它把条件筛选结果以一组 API 标识符返回供后续资源通过for_each或ids集合引用。该数据源由 internal/service/apigatewayv2/apis_data_source.go 实现并通过源码第 23 行的// SDKDataSource(aws_apigatewayv2_apis, nameAPIs)注解声明从源码结构看由 provider 的工厂代码统一注册为 SDKv2 数据源。快速上手一个可复制的最小配置官方文档给出的最小示例如下见 aws_apigatewayv2_apis 文档data aws_apigatewayv2_apis example { protocol_type HTTP }所有protocol_type为HTTP的 API Gateway V2 API 都会被返回。一个更贴近实战、组合多种过滤条件的配置示例# 按名称 标签组合过滤并显式指定 Region data aws_apigatewayv2_apis by_name { name orders-api protocol_type HTTP region us-east-1 tags { environment production team billing } } output api_ids { value data.aws_apigatewayv2_apis.by_name.ids }配合for_each可以为发现的每个 API 批量创建部署resource aws_apigatewayv2_deployment example { for_each toset(data.aws_apigatewayv2_apis.by_name.ids) api_id each.value stage_name live }参数参考Argument Reference该数据源支持以下参数均为 Optional可以任意组合也可以全部缺省缺省时返回当前 Region 内的全部 API参数类型说明nameStringAPI 名称精确匹配。只有Name字段与给定值完全相等的 API 才会被选中。protocol_typeStringAPI 协议类型精确匹配。API Gateway V2 中常见的取值为HTTP与WEBSOCKET可参考 验收测试配置 中的两种取值。regionString执行查询的 Region默认继承 provider 配置中的 Region。跨 Region 扫描时可为不同数据源实例指定不同值。tagsMap(String)标签键值对集合部分匹配每个键值对都必须精确出现在目标 API 的标签中API 可以有额外标签见下文源码解析。输出属性Attribute Reference除上述参数回显外数据源额外导出ids- Set of API identifiers即所有命中 API 的 API ID 字符串集合。注意ids是Set 而非 List顺序不保证且天然去重。消费时应使用toset/for_each或one(...)等集合语义不要依赖下标顺序。源码级解析过滤是如何实现的1. Schema 定义dataSourceAPIs 定义的 Schema 非常精简idsTypeSetComputed元素为TypeString使用schema.HashString计算集合哈希第 30-35 行——这解释了为什么ids在 Terraform 状态中是无序集合。name与protocol_type普通Optional字符串。tags通过 provider 统一的标签 Schema 构造器tftags.TagsSchema()生成第 44 行与其他资源/数据源的标签参数行为保持一致。2. 读取主流程先全量拉取再本地过滤dataSourceAPIsRead第 50-88 行的执行顺序值得注意构造标签匹配集tftags.New(ctx, d.Get(names.AttrTags)...).IgnoreAWS().IgnoreConfig(ignoreTagsConfig)。这里的IgnoreAWS()表示忽略 AWS 保留前缀aws:的标签IgnoreConfig读取 provider 级别的ignore_tags_config意味着你在 provider 中配置的始终忽略的标签键同样作用于本数据源的标签过滤——这是源码中可见、但官方参数文档未单独强调的行为。全量分页拉取调用findAPIs(ctx, conn, apigatewayv2.GetApisInput{})。本地逐个过滤对每个 API 依次判断name、protocol_type、tags任一条件不满足即continue跳过。写入状态命中项的ApiId汇总后写入ids数据源自身的id被设为当前 Region 名称d.SetId(...Region(ctx))第 81 行。第 3 步的过滤代码第 65-79 行展示了精确匹配语义if v, ok : d.GetOk(names.AttrName); ok v.(string) ! aws.ToString(api.Name) { continue } if v, ok : d.GetOk(protocol_type); ok v.(string) ! string(api.ProtocolType) { continue } if len(tagsToMatch) 0 !keyValueTags(ctx, api.Tags).IgnoreAWS().IgnoreConfig(ignoreTagsConfig).ContainsAll(tagsToMatch) { continue }三个要点name/protocol_type是等值比较不支持通配符或前缀匹配条件之间是 AND 关系——同时设置了name和protocol_type时API 必须两者都命中标签匹配是子集包含语义ContainsAll(tagsToMatch)要求数据源tags中的每个键值对都精确包含在 API 自身标签中但 API 标签里存在多余键值对不影响命中。例如数据源指定{team billing}一个带{team billing, environment prod, owner x}标签的 API 也会被选中。3. findAPIs基于 SDK 分页器的全量采集findAPIs第 90-108 行包装了getAPIsPages分页回调逐页累积GetApis接口返回的Items直到lastPageerr : getAPIsPages(ctx, conn, input, func(page *apigatewayv2.GetApisOutput, lastPage bool) bool { if page nil { return !lastPage } apis append(apis, page.Items...) return !lastPage })getAPIsPages由仓库的代码生成机制从 AWS SDK 的分页描述生成参见同目录 list_pages_gen.go。从源码结构看这意味着本数据源不受单次 API 响应条数上限影响——它会遍历当前 Region 内的全部 API 再做本地过滤因此 Region 内 API 数量很大时读取耗时随之增长。验收测试中的过滤行为验证apis_data_source_test.go 提供了三个可对照的验收测试它们构建了 3 个 APItest1/test2 为HTTPtest3 为WEBSOCKET且 test2 与 test3 同名分别验证三种过滤维度测试配置方式断言结果name 过滤name分别取两个不同名称一个数据源命中 1 个 ID另一个命中 2 个 ID同名 API 被全部选中protocol_type 过滤在name基础上追加protocol_type分别命中 1 个与 1 个 IDtags 过滤按标签精确命中、子集命中、附加不存在的键值对依次命中 1、2、0 个 ID其中 tags 测试的第三组断言ids.# 0值得注意数据源在标签中附加了一个 API 上不存在的Key2 Value2结果没有任何 API 命中——这从测试侧印证了上文所述的数据源侧标签必须全部被 API 标签包含的包含关系。测试还展示了一个实用技巧由于数据源参数本身不产生对资源依赖测试配置用element([aws_apigatewayv2_api.test1.name, ...], n)间接引用资源属性以强制建立依赖、避免读取发生在资源创建之前。使用注意事项与常见误区输出只有 ID 集合。ids不含 API 名称、协议、CORS 配置等元数据。需要单个 API 的详细属性时应结合one(...)/element(...)取出 ID 后使用 aws_apigatewayv2_api 数据源查询需要列出全部 ID 且无过滤条件时也可直接使用 aws_apigatewayv2_api_list 列表数据源同目录 api_list.go 实现。跨 Region 场景要显式指定region。数据源查询只覆盖一个 Region而数据源id本身即为该 Region 名称多个 Region 需要多个数据源实例分别查询后合并。标签过滤尊重 provider 的ignore_tags_config。若你在 provider 配置中忽略了某个标签键该键即使出现在数据源tags与 API 标签两侧也不会参与比对排查少了一个键为什么还能命中时优先检查此配置。无过滤条件时返回全量。当账号中 API 数量大时ids集合可能很大建议在for_each场景下始终至少保留一个过滤条件以控制爆炸半径。protocol_type大小写敏感。源码使用字符串直接比较HTTP与http不匹配请沿用 AWS 控制台/API 中的大写取值。小结aws_apigatewayv2_apis是 Terraform AWS Provider 中按条件发现资源 ID的典型范例name、protocol_type精确匹配tags子集包含region控制查询范围最终输出无序的ids集合。结合 源码 可见其SDK 分页全量拉取 本地过滤的实现路径理解这一点后你可以准确预判它的匹配语义、性能特征以及与 provider 级标签忽略配置的交互把它稳妥地用于部署编排、跨资源关联等自动化场景。【免费下载链接】terraform-provider-awsThe AWS Provider enables Terraform to manage AWS resources.项目地址: https://gitcode.com/GitHub_Trending/te/terraform-provider-aws创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表