使用 aws_mq_broker_engine_types 数据源动态获取 Amazon MQ 可用引擎类型与版本【免费下载链接】terraform-provider-awsThe AWS Provider enables Terraform to manage AWS resources.项目地址: https://gitcode.com/GitHub_Trending/te/terraform-provider-awsaws_mq_broker_engine_types是 AWS Providerterraform-provider-aws为 Amazon MQ 服务提供的一个只读数据源用于查询当前区域中可用的 broker 引擎类型如 ActiveMQ、RabbitMQ及其全部引擎版本。本文以 数据源官方文档 为主体结合仓库内数据源实现源码、服务注册表与验收测试完整讲解该数据源的参数、返回属性、底层实现原理以及在创建aws_mq_broker资源时的实战配合方式。数据源概览它解决什么问题在 Terraform 中创建aws_mq_broker资源时engine_type与engine_version是必填参数而 AWS 的引擎版本号会随服务演进持续更新。如果直接在配置中硬编码版本号会导致版本号写死升级成本高不同区域支持的引擎版本集合可能不同写死的版本在新区域可能不可用难以快速获取某个引擎当前支持的全部版本清单。aws_mq_broker_engine_types数据源正是为此设计的它封装了对 Amazon MQDescribeBrokerEngineTypesAPI 的调用将可用引擎类型及版本列表以结构化数据暴露给 Terraform 配置供aws_mq_broker等资源动态引用。从服务包注册表 service_package_gen.go 可以看到该数据源在 MQ 服务包中以TypeName: aws_mq_broker_engine_types、名称 Broker Engine Types 注册与aws_mq_broker数据源、aws_mq_broker_instance_type_offerings数据源同属 MQ 服务的 SDK 数据源集合。基本用法示例官方文档给出的最小示例是直接声明engine_type参数并过滤特定引擎data aws_mq_broker_engine_types example { engine_type ACTIVEMQ }查询结果无需额外配置即可通过aws_mq_broker_engine_types.example.broker_engine_types访问。结合该数据源返回的版本列表可以进一步将其作为创建 broker 的版本来源data aws_mq_broker_engine_types active_mq { engine_type ACTIVEMQ } resource aws_mq_broker example { broker_name example-broker engine_type ActiveMQ engine_version data.aws_mq_broker_engine_types.active_mq.broker_engine_types[0].engine_versions[0].name host_instance_type mq.t3.micro security_groups [aws_security_group.example.id] user { username admin password ChangeMe123! } }说明engine_versions列表的顺序与DescribeBrokerEngineTypesAPI 返回顺序一致见下文实现解析从源码结构看并未做排序。若需要锁定某个具体版本建议对engine_versions[*].name结合element或tolist等函数按需选取。参数Argument Reference该数据源支持以下参数参数类型是否必填说明engine_typestring可选要返回版本详情的 MQ 引擎类型如ACTIVEMQ、RABBITMQ。未指定时返回全部引擎类型。regionstring可选查询引擎类型信息所在的区域默认为 provider 配置或其环境变量链中设置的区域。engine_type的取值与校验engine_type并非自由字符串。在数据源实现 broker_engine_types_data_source.go 中该参数声明为Optional并通过enum.Validate[types.EngineType]()进行枚举校验engine_type: { Type: schema.TypeString, Optional: true, ValidateDiagFunc: enum.Validate[types.EngineType](), },enum.Validate是仓库internal/enum包提供的泛型枚举校验器validate.go其底层调用validation.StringInSlice(Values[T](), false)即传入值必须命中 AWS SDK Go v2 中types.EngineType枚举的有效值大小写敏感。因此示例中的ACTIVEMQ是全大写写法而activemq、ActiveMQ这类大小写变体在该数据源中会被校验拒绝。相比之下aws_mq_broker资源在 broker.go 中对该字段使用enum.ValidateIgnoreCase[types.EngineType]()忽略大小写校验因此资源侧允许写ActiveMQ而数据源侧要求ACTIVEMQ两者在使用习惯上需要注意区分。从仓库其他代码的使用情况可以推断当前 SDK 枚举值至少包含ACTIVEMQ与RABBITMQ两种引擎类型见 broker.go 中types.EngineTypeRabbitmq与types.EngineTypeActivemq的分支判断。具体可用值以当前仓库go.mod锁定的 AWS SDK for Go v2 版本中types.EngineType枚举为准。region参数的生效方式数据源文档声明region可选、默认为 provider 配置区域。从实现看数据源自身 schema 中并未声明独立region属性而是在 service_package_gen.go 中标记为Region: inttypes.ResourceRegionDefault()即采用 provider 的默认区域解析链provider 配置 →AWS_DEFAULT_REGION等环境变量 → 共享配置。对绝大多数场景直接使用 provider 区域即可获得本区域支持的引擎类型与版本清单。属性Attribute Reference该数据源在参数之外导出以下属性属性类型说明broker_engine_typeslist可用引擎类型及对应版本的列表见下方broker_engine_typesBlock。broker_engine_typesBlock列表中的每个元素包含属性类型说明engine_typestringBroker 的引擎类型如ACTIVEMQ、RABBITMQ。engine_versionslist该引擎类型对应的版本列表见下方engine_versionsBlock。engine_versionsBlock属性类型说明namestring引擎版本的名称例如5.18.6、5.17.6等可直接用作aws_mq_broker.engine_version。在 Terraform 配置中通常这样引用# 遍历所有引擎类型及其版本 output all_engine_versions { value { for et in data.aws_mq_broker_engine_types.all.broker_engine_types : et.engine_type [for v in et.engine_versions : v.name] } }源码级实现解析数据源的核心实现在 broker_engine_types_data_source.go整体流程可分为四个阶段理解它可以更准确地预判数据源行为。1. 通过 SDK Data Source 注解声明文件顶部以// SDKDataSource(aws_mq_broker_engine_types, nameBroker Engine Types)注解声明并由代码生成器据此在服务包注册表中登记service_package_gen.go最终通过 provider 工厂注册到 Terraform SDK v2 中。数据源使用ReadWithoutTimeout而非ReadContext表示读取操作不设置超时适用于 API 响应较慢或需多页拉取的场景。2. 组装请求并调用 DescribeBrokerEngineTypes读取函数dataSourceBrokerEngineTypesReadbroker_engine_types_data_source.go首先从 meta 中取得 MQ 客户端client : meta.(*conns.AWSClient).MQClient(ctx) input : mq.DescribeBrokerEngineTypesInput{} if v, ok : d.GetOk(engine_type); ok { input.EngineType aws.String(v.(string)) }即仅在配置中提供了engine_type时才将其写入请求参数不提供时请求返回全部引擎类型。3. 分页拉取与结果聚合DescribeBrokerEngineTypes支持分页。实现通过for循环持续调用 API并将每页的output.BrokerEngineTypes追加到本地切片直到响应中NextToken nil才终止var engineTypes []types.BrokerEngineType for { output, err : client.DescribeBrokerEngineTypes(ctx, input) // err 处理略 engineTypes append(engineTypes, output.BrokerEngineTypes...) if output.NextToken nil { break } input.NextToken output.NextToken }这意味着即使某个区域支持非常多的引擎版本数据源也能完整拉取不会因分页而遗漏数据。4. 设置 ID 并写入状态聚合完成后数据源调用d.SetId(create.UniqueId(ctx))生成唯一 ID再通过flattenBrokerList/flattenEngineVersions两个扁平化函数broker_engine_types_data_source.go将 AWS SDK 的结构体转为 Terraform state 中的 map/list 结构func flattenEngineVersions(engines []types.EngineVersion) (versions []map[string]string) { for _, engine : range engines { versions append(versions, map[string]string{ names.AttrName: aws.ToString(engine.Name), }) } return }engine_versions中的name属性直接取自 API 返回的EngineVersion.Name因此该数据源拿到的版本名称与 AWS 控制台展示、以及aws_mq_broker资源接受的值保持一致。这也解释了上文提到的顺序问题列表顺序完全取决于 AWS API 返回顺序数据源不做二次排序。与相关 MQ 数据源和资源的配合Amazon MQ 服务在 AWS Provider 中还有两个紧密相关的数据源可在同一配置中协同使用aws_mq_broker 数据源读取已有 broker 的配置其engine_type属性同样暴露供引用见 broker_data_source.goaws_mq_broker_instance_type_offerings数据源查询可用的实例规格如mq.t3.micro。典型的多数据源联动场景是用aws_mq_broker_engine_types拿到引擎版本用aws_mq_broker_instance_type_offerings确认可用实例类型再据此创建aws_mq_broker同时用aws_mq_broker数据源反查验证。aws_mq_broker资源在 broker.go 中也会将配置的engine_type与版本一并传给CreateBroker请求与数据源查询结果天然衔接。验收测试佐证仓库为数据源编写了验收测试 broker_engine_types_data_source_test.go其中TestAccMQBrokerEngineTypesDataSource_basic使用engine_type ACTIVEMQ的配置并断言resource.TestCheckResourceAttr(dataSourceName, broker_engine_types.#, 1), resource.TestCheckResourceAttr(dataSourceName, broker_engine_types.0.engine_type, ACTIVEMQ),即过滤ACTIVEMQ后返回列表仅包含 1 个引擎类型元素且该元素的engine_type为ACTIVEMQ。测试同时通过acctest.PreCheckPartitionHasService(t, names.MQEndpointID)与acctest.ErrorCheck(t, names.MQServiceID)做分区服务可用性预检与错误归一化运行前提是目标分区已开放 Amazon MQ 服务。使用注意事项大小写敏感数据源的engine_type使用区分大小写的枚举校验应填写 SDK 枚举原值如ACTIVEMQ、RABBITMQ若写ActiveMQ会在 plan 阶段直接报错。列表顺序依赖 APIbroker_engine_types与engine_versions的顺序由 AWS API 决定若配置中对版本顺序敏感建议用 Terraform 内置函数按name排序或显式取用特定版本。区域相关性查询结果与区域相关不同区域可用的引擎版本集合可能有差异多区域部署时可为每个区域分别声明该数据源。只读数据源该数据源不产生任何资源变更仅在 plan/apply 时调用 AWS API 读取数据并缓存到 state。通过本文的参数说明、属性表格与源码解析你可以将aws_mq_broker_engine_types与aws_mq_broker资源组合使用让 broker 的引擎版本始终跟随区域实际可用版本避免硬编码带来的维护成本。【免费下载链接】terraform-provider-awsThe AWS Provider enables Terraform to manage AWS resources.项目地址: https://gitcode.com/GitHub_Trending/te/terraform-provider-aws创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/9/19 10:03:44 · 阅读 1.2k 使用 aws_mq_broker_engine_types 数据源动态获取 Amazon MQ 可用引擎类型与版本
使用 aws_mq_broker_engine_types 数据源动态获取 Amazon MQ 可用引擎类型与版本【免费下载链接】terraform-provider-awsThe AWS Provider enables Terraform to manage AWS resources.项目地址: https://gitcode.com/GitHub_Trending/te/terraform-provider-awsaws_mq_broker_engine_types是 AWS Providerterraform-provider-aws为 Amazon MQ 服务提供的一个只读数据源用于查询当前区域中可用的 broker 引擎类型如 ActiveMQ、RabbitMQ及其全部引擎版本。本文以 数据源官方文档 为主体结合仓库内数据源实现源码、服务注册表与验收测试完整讲解该数据源的参数、返回属性、底层实现原理以及在创建aws_mq_broker资源时的实战配合方式。数据源概览它解决什么问题在 Terraform 中创建aws_mq_broker资源时engine_type与engine_version是必填参数而 AWS 的引擎版本号会随服务演进持续更新。如果直接在配置中硬编码版本号会导致版本号写死升级成本高不同区域支持的引擎版本集合可能不同写死的版本在新区域可能不可用难以快速获取某个引擎当前支持的全部版本清单。aws_mq_broker_engine_types数据源正是为此设计的它封装了对 Amazon MQDescribeBrokerEngineTypesAPI 的调用将可用引擎类型及版本列表以结构化数据暴露给 Terraform 配置供aws_mq_broker等资源动态引用。从服务包注册表 service_package_gen.go 可以看到该数据源在 MQ 服务包中以TypeName: aws_mq_broker_engine_types、名称 Broker Engine Types 注册与aws_mq_broker数据源、aws_mq_broker_instance_type_offerings数据源同属 MQ 服务的 SDK 数据源集合。基本用法示例官方文档给出的最小示例是直接声明engine_type参数并过滤特定引擎data aws_mq_broker_engine_types example { engine_type ACTIVEMQ }查询结果无需额外配置即可通过aws_mq_broker_engine_types.example.broker_engine_types访问。结合该数据源返回的版本列表可以进一步将其作为创建 broker 的版本来源data aws_mq_broker_engine_types active_mq { engine_type ACTIVEMQ } resource aws_mq_broker example { broker_name example-broker engine_type ActiveMQ engine_version data.aws_mq_broker_engine_types.active_mq.broker_engine_types[0].engine_versions[0].name host_instance_type mq.t3.micro security_groups [aws_security_group.example.id] user { username admin password ChangeMe123! } }说明engine_versions列表的顺序与DescribeBrokerEngineTypesAPI 返回顺序一致见下文实现解析从源码结构看并未做排序。若需要锁定某个具体版本建议对engine_versions[*].name结合element或tolist等函数按需选取。参数Argument Reference该数据源支持以下参数参数类型是否必填说明engine_typestring可选要返回版本详情的 MQ 引擎类型如ACTIVEMQ、RABBITMQ。未指定时返回全部引擎类型。regionstring可选查询引擎类型信息所在的区域默认为 provider 配置或其环境变量链中设置的区域。engine_type的取值与校验engine_type并非自由字符串。在数据源实现 broker_engine_types_data_source.go 中该参数声明为Optional并通过enum.Validate[types.EngineType]()进行枚举校验engine_type: { Type: schema.TypeString, Optional: true, ValidateDiagFunc: enum.Validate[types.EngineType](), },enum.Validate是仓库internal/enum包提供的泛型枚举校验器validate.go其底层调用validation.StringInSlice(Values[T](), false)即传入值必须命中 AWS SDK Go v2 中types.EngineType枚举的有效值大小写敏感。因此示例中的ACTIVEMQ是全大写写法而activemq、ActiveMQ这类大小写变体在该数据源中会被校验拒绝。相比之下aws_mq_broker资源在 broker.go 中对该字段使用enum.ValidateIgnoreCase[types.EngineType]()忽略大小写校验因此资源侧允许写ActiveMQ而数据源侧要求ACTIVEMQ两者在使用习惯上需要注意区分。从仓库其他代码的使用情况可以推断当前 SDK 枚举值至少包含ACTIVEMQ与RABBITMQ两种引擎类型见 broker.go 中types.EngineTypeRabbitmq与types.EngineTypeActivemq的分支判断。具体可用值以当前仓库go.mod锁定的 AWS SDK for Go v2 版本中types.EngineType枚举为准。region参数的生效方式数据源文档声明region可选、默认为 provider 配置区域。从实现看数据源自身 schema 中并未声明独立region属性而是在 service_package_gen.go 中标记为Region: inttypes.ResourceRegionDefault()即采用 provider 的默认区域解析链provider 配置 →AWS_DEFAULT_REGION等环境变量 → 共享配置。对绝大多数场景直接使用 provider 区域即可获得本区域支持的引擎类型与版本清单。属性Attribute Reference该数据源在参数之外导出以下属性属性类型说明broker_engine_typeslist可用引擎类型及对应版本的列表见下方broker_engine_typesBlock。broker_engine_typesBlock列表中的每个元素包含属性类型说明engine_typestringBroker 的引擎类型如ACTIVEMQ、RABBITMQ。engine_versionslist该引擎类型对应的版本列表见下方engine_versionsBlock。engine_versionsBlock属性类型说明namestring引擎版本的名称例如5.18.6、5.17.6等可直接用作aws_mq_broker.engine_version。在 Terraform 配置中通常这样引用# 遍历所有引擎类型及其版本 output all_engine_versions { value { for et in data.aws_mq_broker_engine_types.all.broker_engine_types : et.engine_type [for v in et.engine_versions : v.name] } }源码级实现解析数据源的核心实现在 broker_engine_types_data_source.go整体流程可分为四个阶段理解它可以更准确地预判数据源行为。1. 通过 SDK Data Source 注解声明文件顶部以// SDKDataSource(aws_mq_broker_engine_types, nameBroker Engine Types)注解声明并由代码生成器据此在服务包注册表中登记service_package_gen.go最终通过 provider 工厂注册到 Terraform SDK v2 中。数据源使用ReadWithoutTimeout而非ReadContext表示读取操作不设置超时适用于 API 响应较慢或需多页拉取的场景。2. 组装请求并调用 DescribeBrokerEngineTypes读取函数dataSourceBrokerEngineTypesReadbroker_engine_types_data_source.go首先从 meta 中取得 MQ 客户端client : meta.(*conns.AWSClient).MQClient(ctx) input : mq.DescribeBrokerEngineTypesInput{} if v, ok : d.GetOk(engine_type); ok { input.EngineType aws.String(v.(string)) }即仅在配置中提供了engine_type时才将其写入请求参数不提供时请求返回全部引擎类型。3. 分页拉取与结果聚合DescribeBrokerEngineTypes支持分页。实现通过for循环持续调用 API并将每页的output.BrokerEngineTypes追加到本地切片直到响应中NextToken nil才终止var engineTypes []types.BrokerEngineType for { output, err : client.DescribeBrokerEngineTypes(ctx, input) // err 处理略 engineTypes append(engineTypes, output.BrokerEngineTypes...) if output.NextToken nil { break } input.NextToken output.NextToken }这意味着即使某个区域支持非常多的引擎版本数据源也能完整拉取不会因分页而遗漏数据。4. 设置 ID 并写入状态聚合完成后数据源调用d.SetId(create.UniqueId(ctx))生成唯一 ID再通过flattenBrokerList/flattenEngineVersions两个扁平化函数broker_engine_types_data_source.go将 AWS SDK 的结构体转为 Terraform state 中的 map/list 结构func flattenEngineVersions(engines []types.EngineVersion) (versions []map[string]string) { for _, engine : range engines { versions append(versions, map[string]string{ names.AttrName: aws.ToString(engine.Name), }) } return }engine_versions中的name属性直接取自 API 返回的EngineVersion.Name因此该数据源拿到的版本名称与 AWS 控制台展示、以及aws_mq_broker资源接受的值保持一致。这也解释了上文提到的顺序问题列表顺序完全取决于 AWS API 返回顺序数据源不做二次排序。与相关 MQ 数据源和资源的配合Amazon MQ 服务在 AWS Provider 中还有两个紧密相关的数据源可在同一配置中协同使用aws_mq_broker 数据源读取已有 broker 的配置其engine_type属性同样暴露供引用见 broker_data_source.goaws_mq_broker_instance_type_offerings数据源查询可用的实例规格如mq.t3.micro。典型的多数据源联动场景是用aws_mq_broker_engine_types拿到引擎版本用aws_mq_broker_instance_type_offerings确认可用实例类型再据此创建aws_mq_broker同时用aws_mq_broker数据源反查验证。aws_mq_broker资源在 broker.go 中也会将配置的engine_type与版本一并传给CreateBroker请求与数据源查询结果天然衔接。验收测试佐证仓库为数据源编写了验收测试 broker_engine_types_data_source_test.go其中TestAccMQBrokerEngineTypesDataSource_basic使用engine_type ACTIVEMQ的配置并断言resource.TestCheckResourceAttr(dataSourceName, broker_engine_types.#, 1), resource.TestCheckResourceAttr(dataSourceName, broker_engine_types.0.engine_type, ACTIVEMQ),即过滤ACTIVEMQ后返回列表仅包含 1 个引擎类型元素且该元素的engine_type为ACTIVEMQ。测试同时通过acctest.PreCheckPartitionHasService(t, names.MQEndpointID)与acctest.ErrorCheck(t, names.MQServiceID)做分区服务可用性预检与错误归一化运行前提是目标分区已开放 Amazon MQ 服务。使用注意事项大小写敏感数据源的engine_type使用区分大小写的枚举校验应填写 SDK 枚举原值如ACTIVEMQ、RABBITMQ若写ActiveMQ会在 plan 阶段直接报错。列表顺序依赖 APIbroker_engine_types与engine_versions的顺序由 AWS API 决定若配置中对版本顺序敏感建议用 Terraform 内置函数按name排序或显式取用特定版本。区域相关性查询结果与区域相关不同区域可用的引擎版本集合可能有差异多区域部署时可为每个区域分别声明该数据源。只读数据源该数据源不产生任何资源变更仅在 plan/apply 时调用 AWS API 读取数据并缓存到 state。通过本文的参数说明、属性表格与源码解析你可以将aws_mq_broker_engine_types与aws_mq_broker资源组合使用让 broker 的引擎版本始终跟随区域实际可用版本避免硬编码带来的维护成本。【免费下载链接】terraform-provider-awsThe AWS Provider enables Terraform to manage AWS resources.项目地址: https://gitcode.com/GitHub_Trending/te/terraform-provider-aws创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考