企业官网建设流程全解析

使用 Terraform AWS Provider 的aws_medialive_input数据源：读取 AWS Elemental MediaLive 输入详情

【免费下载链接】terraform-provider-awsThe AWS Provider enables Terraform to manage AWS resources.项目地址: https://gitcode.com/GitHub_Trending/te/terraform-provider-aws

导读

aws_medialive_input是 terraform-provider-aws 提供的官方数据源（Data Source），用于按 ID 读取一个已存在的 AWS Elemental MediaLive Input（输入）的完整配置与运行状态。本文基于 website/docs/d/medialive_input.html.markdown 官方文档展开，结合 internal/service/medialive 目录下的数据源实现与验收测试源码，系统讲解该数据源的参数、全部导出属性、底层调用链与典型实战用法，帮助你在 Terraform 配置中安全复用其他模块创建的 MediaLive 输入资源，而无需重新定义或重复管理。

数据源概览

MediaLive Input 是 AWS Elemental MediaLive 频道（Channel）的视频/音频输入端点，支持 PUSH（推流）与 PULL（拉流）两种模式。在 Terraform 中，输入既可以由aws_medialive_input资源直接管理，也可以通过aws_medialive_input数据源按 ID 引用一个既有的输入——例如该输入由另一个 Terraform 工作区、CloudFormation 栈或控制台创建。

数据源的核心价值在于：只读取、不管理。它不会创建、修改或删除任何资源，只负责把指定 Input 的 ARN、类型、状态、关联频道、标签等信息注入当前配置，供引用（如传给aws_medialive_channel的input_attachments）。

从源码看，该数据源基于 Terraform Plugin Framework 实现（input_data_source.go 中通过// @FrameworkDataSource("aws_medialive_input", name="Input")注解注册），其Read实现会调用底层DescribeInputAPI 获取数据后，通过fwflex.Flatten将 API 响应扁平化到模型结构，再写入 Terraform 状态。

参数说明（Argument Reference）

数据源仅接受两个参数：

region参数对应源码模型中的framework.WithRegionModel（input_data_source.go），它被嵌入到数据源模型最前方，使得每个读取操作都携带区域上下文。

最小可用配置如下：

data "aws_medialive_input" "example" { id = aws_medialive_input.example.id }

上面的写法直接引用同目录下aws_medialive_input资源创建后的id，是最常见的"同配置内先建后查"场景。

导出属性（Attribute Reference）

除了两个参数外，数据源还会导出以下只读属性，覆盖了DescribeInputAPI 返回的全部关键信息：

嵌套对象结构说明

从数据源模型定义（input_data_source.go）可以看到三个嵌套对象的具体字段：

• destinations→dsDestination：ip、port、url、vpc（vpc内为availability_zone、network_interface_id）；
• media_connect_flows→dsMediaConnectFlow：flow_arn；
• sources→dsInputSource：password_param（引用 AWS Secrets Manager 中凭据的参数名）、url、username。

这些结构体字段与aws_medialive_input资源中对应的配置块（destinations、media_connect_flows、sources，见 input.go）一一对应，因此你可以在数据源与资源之间无缝迁移引用关系。

完整实战示例

场景一：读取同配置内创建的输入并传给频道

最典型的用法是"资源创建 + 数据源读取 + 供频道引用"三件套：

# 输入安全组：放行推流源 IP resource "aws_medialive_input_security_group" "example" { whitelist_rules { cidr = "10.0.0.8/32" } tags = { Name = "example-input-sg" } } # 创建 UDP PUSH 类型输入 resource "aws_medialive_input" "example" { name = "example-input" input_security_groups = [aws_medialive_input_security_group.example.id] type = "UDP_PUSH" tags = { Name = "example-input" } } # 通过数据源读取该输入的完整信息 data "aws_medialive_input" "example" { id = aws_medialive_input.example.id } output "input_arn" { value = data.aws_medialive_input.example.arn } output "input_state" { value = data.aws_medialive_input.example.state } output "input_sources" { value = data.aws_medialive_input.example.sources }

这一用法与仓库验收测试中的配置完全一致：TestAccMediaLiveInputDataSource_basic（input_data_source_test.go）先创建输入安全组与UDP_PUSH类型输入，再以id = aws_medialive_input.test.id方式声明数据源，并断言数据源的arn、name、input_class、input_devices、input_partner_ids、input_source_type、security_groups、sources、state、type与资源侧一致，同时校验destinations.#等于 2。

场景二：跨配置引用既有输入

当输入由其他工作区管理时，通过terraform_remote_state或直接硬编码 ID 读取：

data "aws_medialive_input" "existing" { id = "1234567" # 替换为实际 Input ID } # 供其他资源引用 # resource "aws_medialive_channel" "main" { # ... # input_attachments { # input_id = data.aws_medialive_input.existing.id # ... # } # }

场景三：跨区域读取

若输入创建于eu-west-1，而当前 provider 默认区域为us-east-1，可显式指定region：

data "aws_medialive_input" "eu" { id = "1234567" region = "eu-west-1" }

底层实现：一次读取的完整调用链

数据源的Read方法（input_data_source.go）执行流程如下：

1. 通过d.Meta().MediaLiveClient(ctx)获取 MediaLive 服务客户端；
2. 从配置中读取id；
3. 调用findInputByID（input.go）：构造medialive.DescribeInputInput{InputId: ...}并执行conn.DescribeInput。若返回NotFoundException，则包装为retry.NotFoundError；若响应为空则返回EmptyResultError；
4. 调用fwflex.Flatten将DescribeInputOutput扁平化写入数据源模型；
5. 通过setTagsOut处理标签（数据源模型中的tags字段是tftags.Map计算属性），最后resp.State.Set写回状态。

值得注意：数据源的读取与aws_medialive_input资源的Read（resourceInputRead，见 input.go）共用同一个findInputByID查询函数，因此两者导出的字段集合高度一致。这也解释了为什么数据源能拿到attached_channels、input_partner_ids这类"资源创建后由 AWS 侧回填"的计算属性——它们都来自DescribeInput的响应体。

标签读取行为

该数据源在@Tags注解下注册了只读的tags属性（input_data_source.go）。仓库中的标签专项测试（input_data_source_tags_gen_test.go）覆盖了以下行为：

• 数据源tags精确反映输入上的实际标签；
• 未打标签时返回空 map；
• 与 provider 级default_tags叠加时，数据源返回合并后的全部标签（含 provider 默认标签与资源标签，非重叠场景两者共存）；
• 配置ignore_tags时，数据源导出的tags会剔除被忽略的键，但完整的标签集合（tags_all语义）仍可通过内部expectFullInputDataSourceTags校验获得（该检查以arn作为标签标识属性，见 input_data_source_tags_gen_test.go）。

因此，在数据源侧读取tags时需要注意：它遵循 provider 的ignore_tags过滤规则；若需要绝对完整的标签视图，建议同时读取对应资源侧的tags_all。

使用建议与注意事项

1. id是唯一查找键：数据源不支持按名称或其他条件搜索，必须持有 Input ID。若只有名称，可先通过aws_medialive_inputs（若可用）或data.aws_medialive_input配合其他信息定位。
2. destinations属性名注意：官方文档正文中曾误写为destionations，实际合法属性名为destinations，请以本文及 数据源 Schema 定义 为准。
3. 状态判断：state属性可用于条件逻辑（例如仅在ATTACHED时创建下游资源），但注意 MediaLive 输入创建是异步的，资源侧创建完成后数据源读取到的一瞬间仍可能处于中间态，业务上如需强一致应结合aws_medialive_channel的依赖关系编排。
4. 跨区域限制：region参数仅支持单区域读取；若配置了多个 provider 别名，也可以直接用对应 provider 的数据源块实现等效效果。
5. 只读原则：数据源永远不会触发资源的增删改，适合作为"只读引用层"隔离不同 Terraform 工作区之间的管理职责。

小结

aws_medialive_input数据源把 AWS Elemental MediaLive Input 的完整描述（含 ARN、类型、状态、PUSH 目标、PULL 源、MediaConnect Flow、输入安全组、设备与标签）以只读方式注入 Terraform 配置。其实现与aws_medialive_input资源共用DescribeInput查询链路，字段对齐、行为一致。无论是同配置内的"建后读"、跨工作区的"引用既有输入"，还是跨区域的"按 ID 拉取详情"，它都是连接 MediaLive 输入与频道配置之间最简洁、最可靠的桥梁。更多细节可继续阅读仓库中的 官方文档、数据源实现 与 验收测试。

【免费下载链接】terraform-provider-awsThe AWS Provider enables Terraform to manage AWS resources.项目地址: https://gitcode.com/GitHub_Trending/te/terraform-provider-aws