ARTICLE DETAIL

资讯详情

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

terraform-provider-aws 中 aws_appconfig_application 数据源:按名称或 ID 查找 AppConfig 应用的完整指南

terraform-provider-aws 中 aws_appconfig_application 数据源:按名称或 ID 查找 AppConfig 应用的完整指南 terraform-provider-aws 中 aws_appconfig_application 数据源按名称或 ID 查找 AppConfig 应用的完整指南【免费下载链接】terraform-provider-awsThe AWS Provider enables Terraform to manage AWS resources.项目地址: https://gitcode.com/GitHub_Trending/te/terraform-provider-aws本文以 Terraform AWS Provider 的数据源aws_appconfig_application为核心讲清它如何从 AWS AppConfig 中按名称或 ID 检索应用Application、支持哪些参数与输出属性并结合 Provider 源码深入剖析其查找逻辑分页 ListApplications 谓词过滤、参数校验器ExactlyOneOf与 ARN 拼装机制以及验收测试对两种查询方式的覆盖方式帮助读者在 Terraform 配置中可靠地引用已有 AppConfig 应用。数据源定位aws_appconfig_application是一个数据源Data Source用于获取一个已存在的 AWS AppConfig 应用的详情。典型场景是应用本身由别的流水线、别的模块甚至控制台创建而当前 Terraform 配置只需要引用它的 ARN、描述或 ID——例如在aws_appconfig_configuration_profile、aws_appconfig_hosted_configuration_version等下游资源中引用data.aws_appconfig_application.example.arn或.id。对应文档为 aws_appconfig_application 数据源文档Provider 中的实现位于 application_data_source.go。基本用法最直接的用法是按应用名称查找data aws_appconfig_application example { name my-appconfig-application }数据源在terraform plan/terraform apply阶段会调用 AWS AppConfig API 完成检索将结果写入 state之后即可通过data.aws_appconfig_application.example.arn、.description、.id、.name等属性在配置中引用。参数参考Argument Reference该数据源支持以下参数id- 可选应用 ID。id与name必须且只能指定其中一个。name- 可选AWS AppConfig 应用名称。name与id必须且只能指定其中一个。region- 可选查询所在 Region默认继承 provider 配置中设置的 Region。从源码看这三个参数的约束并非仅靠文档约定而是由 Schema 校验器和配置级校验器强制执行的id的格式校验在 Schema 定义 中id是Optional Computed并带有正则校验^[0-9a-z]{4,7}$错误提示为 value must contain 4-7 lowercase letters or numbers。也就是说如果误把资源名或 ARN 填进id会在 plan 阶段直接报错而不是等到调用 API 才失败。name的长度校验name为Optional Computed约束为 1–64 个字符LengthBetween(1, 64)与资源配置侧name的校验规则保持一致。region参数数据源模型内嵌了framework.WithRegionModel见 with_region.go它只是声明了一个region字符串属性Region 的最终取值逻辑由 Provider 框架统一处理未显式指定时回退到 provider 级 Region。id/name二选一互斥ConfigValidators 注册了datasourcevalidator.ExactlyOneOf(path.MatchRoot(id), path.MatchRoot(name))即“恰好一个”语义——两个都不给会报错两个都给也会报错。输出属性参考Attribute Reference除上述参数外该数据源还会导出以下属性arn- 应用的 ARN。description- 应用的描述。此外id与name本身也被声明为Computed意味着即使用户只提供了其中一个作为查询条件读回后另一个也会被填充到 state 中例如按name查询后id也会可读。arn属性由 ARNAttributeComputedOnly 构造是纯Computed属性只能由 Provider 写入。一个实用示例先按名称查出应用再交给下游资源引用data aws_appconfig_application example { name my-appconfig-application } # 可引用 data.aws_appconfig_application.example.arn / .id / .description output appconfig_application_arn { value data.aws_appconfig_application.example.arn }源码级实现剖析从输入到 state 的完整链路数据源的Read方法application_data_source.go 第 69–106 行是理解其行为的关键链路如下模型解码通过req.Config.Get(ctx, data)将 HCL 配置解码到dataSourceApplicationModel含arn、description、id、name与嵌入的region任何解码错误都会以诊断信息返回。条件化查找若id非空则调用findApplicationWithFilter过滤谓词为aws.ToString(v.Id) data.ID.ValueString()若name非空则同理按v.Name精确匹配。由于ExactlyOneOf校验器保证二者至多取其一实际只会走其中一条分支。分页遍历 谓词过滤findApplicationWithFilter第 125–133 行建立在两层封装之上listApplicationPages第 139–154 行使用 AWS SDK v2 的appconfig.NewListApplicationsPaginator逐页调用ListApplicationsAPI并以 Goiter.Seq2迭代器把每一页Items向外yield出错时包装为 listing AppConfig Applications: ... 错误上层通过tfslices.CollectAndConcatWithError配合WithFilter(filter)与WithReturnFirstMatch选项收集所有页后应用过滤谓词并只返回第一个匹配项。结果唯一性断言tfresource.AssertSingleValueResult保证“按给定条件匹配到且仅匹配到 1 个应用”若匹配到多个例如名称重复的异常数据会报错而不是静默取第一个。state 回写与 ARN 拼装flex.Flatten把 SDK 的awstypes.Application对象扁平化写入模型随后 ARN 通过RegionalARN(ctx, appconfig, application/id)按区域拼装第 103 行。这一拼法与资源配置 application.go 中的 applicationARN 完全一致即arn:partition:appconfig:region::application/id的标准结构保证数据源与资源产出的 ARN 格式统一。错误上下文所有关键步骤都包在smerr.AddError/smerr.AddEnrich中错误诊断会带上 ID 或名称等上下文便于定位“找不到应用”之类的报错。值得注意的设计取舍按id查找并没有直接调用GetApplication而是复用了与按名称查找相同的ListApplications分页 过滤路径。从源码结构看这一方面让两种查找方式共享同一套分页/过滤基础设施另一方面也意味着查找行为受 ListApplications 的分页返回影响这与同文件中 SDKv2 资源侧findApplicationByID直接调用GetApplicationapplication.go 第 159–165 行的做法形成对照——数据源侧选择了统一的 finder 风格实现。验收测试对两种查询方式的覆盖对应的验收测试位于 application_data_source_test.go分别覆盖名称与 ID 两种入口TestAccAppConfigApplicationDataSource_basic_name第 16–43 行创建一个真实的aws_appconfig_application.test资源后用data aws_appconfig_application test { name aws_appconfig_application.test.name }回查TestAccAppConfigApplicationDataSource_basic_id第 45–72 行改用id aws_appconfig_application.test.id回查。两个用例都断言了数据源与资源之间的属性一致性description、id、name通过TestCheckResourceAttrPair两两比对并校验id符合[a-z\d]{4,7}格式。测试配置模板第 74–97 行同时给出了最小可运行的资源定义resource aws_appconfig_application test { name %[1]q description Example AppConfig Application } data aws_appconfig_application test { name aws_appconfig_application.test.name }这套测试也印证了上文结论数据源查回的description、name与资源状态一致id格式与 Schema 正则吻合。与资源配置的关系与使用提示资源 vs 数据源aws_appconfig_application资源application.go负责创建/更新/删除应用name必填1–64 字符、description可选0–1024 字符并支持tags/tags_all数据源则只做只读查询其id/name均为Optional Computed。同包内还有一系列配套资源与数据源如 configuration_profile、deployment_strategy、environment 等可组合使用。找不到应用时的行为过滤未命中时AssertSingleValueResult会返回“空结果/非唯一结果”错误Read会将其包装为带 ID/名称上下文的诊断报错——配置中引用的应用名拼写错误会在 plan 阶段暴露这是排查此类报错的第一入口。Region 一致性数据源的region参数决定了向哪个区域发起ListApplications请求跨 Region 引用时务必显式设置否则会查询到 provider 默认 Region 下的同名应用可能查不到或查到错误对象。小结aws_appconfig_application数据源以“id/name恰好其一”的强约束换取了确定性的查找语义正则与长度校验器在 plan 阶段拦截非法输入ExactlyOneOf校验器保证查询条件唯一ListApplications分页 谓词过滤 单结果断言保证结果精确且唯一RegionalARN拼装保证 ARN 与资源侧格式一致。理解这条从 HCL 输入到 AWS API 调用的完整链路后读者可以把它可靠地用于任何需要引用既有 AppConfig 应用的 Terraform 模块并借助 验收测试 中的配置模板快速验证自身环境的连通性与权限。【免费下载链接】terraform-provider-awsThe AWS Provider enables Terraform to manage AWS resources.项目地址: https://gitcode.com/GitHub_Trending/te/terraform-provider-aws创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表