尧图网站建设 
terraform-provider-aws 数据源aws_backup_framework完全指南查询 AWS Backup 框架详情【免费下载链接】terraform-provider-awsThe AWS Provider enables Terraform to manage AWS resources.项目地址: https://gitcode.com/GitHub_Trending/te/terraform-provider-awsaws_backup_framework是 Terraform AWS Provider 提供的一个只读数据源用于按名称查询已存在的 AWS Backup 框架Framework并导出其 ARN、控制项control、作用域scope、部署状态与标签等完整信息。本文以 数据源文档 为核心结合 framework_data_source.go、framework.go 及对应的 数据源测试带你掌握该数据源的用法、输出属性结构以及底层实现原理从而在 Terraform 配置中安全地引用既有备份合规框架。数据源概览与适用场景在 AWS Backup 服务中Framework框架是一组合规控制Control的集合用于对备份计划、备份选择、备份库Vault和恢复点Recovery Point等资源进行持续评估与审计。AWS Backup 会基于框架中定义的控制规则例如“恢复点至少保留 35 天”“恢复点必须加密”配合 AWS Config 的资源追踪能力给出框架的部署状态deployment_status与整体合规状态status。aws_backup_framework数据源正是为“读取而非创建”框架而生框架可能由其他团队、其他 Terraform 工作区或通过 AWS 控制台创建本工作区只需引用其信息在输出变量、IAM 策略、云监控告警或跨资源关联中需要框架的 ARN、状态等属性需要将框架内的控制项如控制名称、输入参数、作用域读取出来用于自动化审计报告。该数据源由dataSourceFramework()实现通过ReadWithoutTimeout: dataSourceFrameworkRead执行读取逻辑见 framework_data_source.go。基本用法最简用法只需提供框架名称即可获得该框架的全部可导出属性data aws_backup_framework example { name tf_example_backup_framework_name }对于已有框架资源、希望复用其属性的场景更推荐直接引用资源名称而非硬编码字符串这样可避免“名称拼写不一致”导致的数据源查询失败resource aws_backup_framework test { name exampleFramework description Example framework # control 块等内容略详见资源文档 } data aws_backup_framework test { name aws_backup_framework.test.name } output framework_arn { value data.aws_backup_framework.test.arn }第二种写法与仓库中的 数据源验收测试 保持一致——测试正是先创建aws_backup_framework.test资源再通过data.aws_backup_framework.test引用其名称。参数Argument Reference参数类型必填说明namestring是要查询的 Backup 框架名称regionstring否框架所在区域默认使用 Provider 配置中设置的区域name作为查询主键其格式约束与资源侧的校验规则一致。在源码 validate.go 中框架名称必须匹配正则^[A-Za-z]{1}[0-9A-Za-z_]{0,255}$即长度 1256 个字符必须以字母开头只能包含字母、数字和下划线。对应的单元测试 validate_test.go 验证了 256 字符的合法名称可通过校验而error开头或 257 字符的超长名称会被拒绝。从源码结构看region参数主要用于支持多区域部署时跨区域读取框架信息未指定时遵循 Provider 的区域配置。导出属性Attribute Reference执行data aws_backup_framework后除参数本身外还会导出以下属性属性类型说明arnstring框架的 ARNcontrollist组成框架的一个或多个控制块含名称、输入参数与作用域结构见下文creation_timestring框架创建时间Unix 格式并统一为 UTCTerraform 中格式化为 RFC3339deployment_statusstring框架部署状态取值CREATE_IN_PROGRESS/UPDATE_IN_PROGRESS/DELETE_IN_PROGRESS/COMPLETED/FAILEDdescriptionstring框架描述idstring框架 ID与框架名称一致statusstring框架整体合规状态取值ACTIVE/PARTIALLY_ACTIVE/INACTIVE/UNAVAILABLEtagsmap框架的标签元数据各属性在源码中的落点从 framework_data_source.go 的dataSourceFrameworkRead实现可以看到完整的属性映射过程读取name参数调用findFrameworkByName其底层通过conn.DescribeFramework调用 AWS Backup API见 framework.god.SetId(name)将框架名称同时作为数据源的idd.Set(arn, output.FrameworkArn)写入 ARNd.Set(control, flattenFrameworkControls(...))将 API 返回的FrameworkControls扁平化为 Terraform 属性结构creation_time通过output.CreationTime.Format(time.RFC3339)格式化为标准时间字符串依次写入deployment_status、description、name、status。其中arn还被Tags(identifierAttributearn)注解标记为标签关联标识这也是tags属性能够正确导出的原因。数据源定义的 Schema 中所有非参数属性均为Computed: true见 framework_data_source.go即只读、由 Provider 计算填充。control 块框架的合规控制项每个框架由一个或多个control块组成。control列表中的每个元素包含三个子属性子属性类型说明namestring控制名称。例如 “backup plan frequency is at least daily and the retention period is at least 1 year” 这类规则对应的系统控制名input_parameterlist一个或多个输入参数块用于设定控制规则的具体阈值scopelist控制的作用域定义该控制将评估哪些资源真实控制名示例仓库中的 数据源验收测试 验证了以下真实存在的 AWS Backup 控制项可直接参考BACKUP_RECOVERY_POINT_MINIMUM_RETENTION_CHECK恢复点最小保留期检查示例参数requiredRetentionDays 35BACKUP_PLAN_MIN_FREQUENCY_AND_MIN_RETENTION_CHECK备份计划最低频率与最低保留期检查三个参数requiredFrequencyUnit hours、requiredRetentionDays 35、requiredFrequencyValue 1BACKUP_RECOVERY_POINT_ENCRYPTED恢复点必须加密BACKUP_RESOURCES_PROTECTED_BY_BACKUP_PLAN资源受备份计划保护测试中配置了compliance_resource_ids指向一个 EBS 卷compliance_resource_types [EBS]BACKUP_RECOVERY_POINT_MANUAL_DELETION_DISABLED禁止手动删除恢复点。测试通过resource.TestCheckTypeSetElemNestedAttrs逐项断言数据源返回的控制名与参数例如control.*.input_parameter.0.name requiredRetentionDays control.*.input_parameter.0.value 35input_parameter 子块input_parameter由name与value两个键值对组成属性说明name参数名称例如BackupPlanFrequency、requiredRetentionDaysvalue参数取值例如hourly、35在源码中API 层的ControlInputParameter通过flattenControlInputParameters扁平化为name/value映射见 framework.go空参数会被安全忽略。scope 子块scope定义控制的作用范围支持以下三种典型语义指定某一个具体的 AWS 资源通过资源 ID所有带特定标签的备份计划通过标签键值对全部备份计划不配置任何过滤条件。属性类型说明compliance_resource_idslist(string)控制作用域所包含的唯一 AWS 资源 ID 列表如 EBS 卷 IDcompliance_resource_typeslist(string)控制作用域包含的资源类型列表如EBS、RDS、EFStagsmap应用于目标资源的标签键值对用于触发规则评估最多只能提供一个键值对在资源侧的 framework.go 实现中可以看到约束说明“最多一个键值对标签值可选但不能为空字符串”。数据源读取时flattenControlScope会把 API 返回的ControlScope转换回这三个字段见 framework.go。读取一个完整框架的实战示例下面给出一个可直接运行的最小完整示例先创建一个带控制项的框架资源再用数据源读取并输出关键信息结构参考 数据源测试配置并补充了资源文档中的更多控制项。resource aws_backup_framework example { name example_framework description Example framework control { name BACKUP_RECOVERY_POINT_MINIMUM_RETENTION_CHECK input_parameter { name requiredRetentionDays value 35 } } control { name BACKUP_RECOVERY_POINT_ENCRYPTED } control { name BACKUP_RESOURCES_PROTECTED_BY_BACKUP_PLAN scope { compliance_resource_types [EBS] } } tags { Name Example Framework } } data aws_backup_framework example { name aws_backup_framework.example.name } output framework_arn { value data.aws_backup_framework.example.arn } output framework_status { value data.aws_backup_framework.example.status } output framework_deployment_status { value data.aws_backup_framework.example.deployment_status } output framework_controls { value data.aws_backup_framework.example.control }部署前置条件根据 资源文档 的说明要使框架的部署状态最终变为COMPLETED需要先在 AWS 控制台开启资源追踪AWS Config recording以便 AWS Config 记录备份资源的配置变更。未开启时框架可能长期停留在CREATE_IN_PROGRESS或进入FAILED进而影响数据源读取到的deployment_status与status。与框架资源aws_backup_framework的关系数据源是框架管理链路中的“读”半边与之配套的aws_backup_framework资源负责“增删改”两者共享同一套控制/参数/作用域数据结构资源的 Schema 中control为TypeSet必填、至少 1 项input_parameter与scope为可选见 framework.go资源的name为ForceNew不可原地修改见 framework.go因此数据源以name作为查询主键与资源的id即名称天然对应资源在创建、更新、删除时都会通过waitFrameworkCreated/waitFrameworkUpdated/waitFrameworkDeleted轮询DeploymentStatus直至终态见 framework.go而数据源读取的deployment_status正是同一状态机产出的值。从实现看资源与数据源共用了findFrameworkByName/flattenFrameworkControls/flattenControlInputParameters/flattenControlScope等函数定义在 framework.go保证了“写入什么结构、读回什么结构”的一致性。标签读取与测试保障数据源通过tftags.TagsSchemaComputed()声明tags为计算属性见 framework_data_source.go框架的标签会原样导出。仓库通过自动生成的 framework_data_source_tags_gen_test.go 覆盖了标签相关场景包括基础标签读取tags精确匹配空 Map 与 null Map 边界情况Provider 级default_tags与资源标签不重叠时数据源可见性ignore_tags与默认标签/资源标签重叠时的过滤行为。这些测试采用串行执行acctest.RunSerialTests1Level以避免标签类测试相互干扰同时主数据源测试也被标记为Testing(serializetrue)。如果你需要在自己的配置中依赖框架标签做条件判断可以放心使用data.aws_backup_framework.example.tags其行为与资源侧tags_all语义一致。小结aws_backup_framework数据源是一个轻量、只读的查询入口帮你把“已经存在的 AWS Backup 框架”安全地接入 Terraform 配置只需提供name即可获得arn、control含input_parameter与scope、creation_time、deployment_status、description、status与tags等完整信息。其实现基于 AWS Backup 的DescribeFrameworkAPI属性扁平化逻辑与配套资源完全对齐测试覆盖了主流控制项、作用域与标签场景可作为合规审计、跨工作区引用和多区域部署的可靠数据来源。【免费下载链接】terraform-provider-awsThe AWS Provider enables Terraform to manage AWS resources.项目地址: https://gitcode.com/GitHub_Trending/te/terraform-provider-aws创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 terraform-provider-aws 数据源 `aws_backup_framework` 完全指南：查询 AWS Backup 框架详情
terraform-provider-aws 数据源aws_backup_framework完全指南查询 AWS Backup 框架详情【免费下载链接】terraform-provider-awsThe AWS Provider enables Terraform to manage AWS resources.项目地址: https://gitcode.com/GitHub_Trending/te/terraform-provider-awsaws_backup_framework是 Terraform AWS Provider 提供的一个只读数据源用于按名称查询已存在的 AWS Backup 框架Framework并导出其 ARN、控制项control、作用域scope、部署状态与标签等完整信息。本文以 数据源文档 为核心结合 framework_data_source.go、framework.go 及对应的 数据源测试带你掌握该数据源的用法、输出属性结构以及底层实现原理从而在 Terraform 配置中安全地引用既有备份合规框架。数据源概览与适用场景在 AWS Backup 服务中Framework框架是一组合规控制Control的集合用于对备份计划、备份选择、备份库Vault和恢复点Recovery Point等资源进行持续评估与审计。AWS Backup 会基于框架中定义的控制规则例如“恢复点至少保留 35 天”“恢复点必须加密”配合 AWS Config 的资源追踪能力给出框架的部署状态deployment_status与整体合规状态status。aws_backup_framework数据源正是为“读取而非创建”框架而生框架可能由其他团队、其他 Terraform 工作区或通过 AWS 控制台创建本工作区只需引用其信息在输出变量、IAM 策略、云监控告警或跨资源关联中需要框架的 ARN、状态等属性需要将框架内的控制项如控制名称、输入参数、作用域读取出来用于自动化审计报告。该数据源由dataSourceFramework()实现通过ReadWithoutTimeout: dataSourceFrameworkRead执行读取逻辑见 framework_data_source.go。基本用法最简用法只需提供框架名称即可获得该框架的全部可导出属性data aws_backup_framework example { name tf_example_backup_framework_name }对于已有框架资源、希望复用其属性的场景更推荐直接引用资源名称而非硬编码字符串这样可避免“名称拼写不一致”导致的数据源查询失败resource aws_backup_framework test { name exampleFramework description Example framework # control 块等内容略详见资源文档 } data aws_backup_framework test { name aws_backup_framework.test.name } output framework_arn { value data.aws_backup_framework.test.arn }第二种写法与仓库中的 数据源验收测试 保持一致——测试正是先创建aws_backup_framework.test资源再通过data.aws_backup_framework.test引用其名称。参数Argument Reference参数类型必填说明namestring是要查询的 Backup 框架名称regionstring否框架所在区域默认使用 Provider 配置中设置的区域name作为查询主键其格式约束与资源侧的校验规则一致。在源码 validate.go 中框架名称必须匹配正则^[A-Za-z]{1}[0-9A-Za-z_]{0,255}$即长度 1256 个字符必须以字母开头只能包含字母、数字和下划线。对应的单元测试 validate_test.go 验证了 256 字符的合法名称可通过校验而error开头或 257 字符的超长名称会被拒绝。从源码结构看region参数主要用于支持多区域部署时跨区域读取框架信息未指定时遵循 Provider 的区域配置。导出属性Attribute Reference执行data aws_backup_framework后除参数本身外还会导出以下属性属性类型说明arnstring框架的 ARNcontrollist组成框架的一个或多个控制块含名称、输入参数与作用域结构见下文creation_timestring框架创建时间Unix 格式并统一为 UTCTerraform 中格式化为 RFC3339deployment_statusstring框架部署状态取值CREATE_IN_PROGRESS/UPDATE_IN_PROGRESS/DELETE_IN_PROGRESS/COMPLETED/FAILEDdescriptionstring框架描述idstring框架 ID与框架名称一致statusstring框架整体合规状态取值ACTIVE/PARTIALLY_ACTIVE/INACTIVE/UNAVAILABLEtagsmap框架的标签元数据各属性在源码中的落点从 framework_data_source.go 的dataSourceFrameworkRead实现可以看到完整的属性映射过程读取name参数调用findFrameworkByName其底层通过conn.DescribeFramework调用 AWS Backup API见 framework.god.SetId(name)将框架名称同时作为数据源的idd.Set(arn, output.FrameworkArn)写入 ARNd.Set(control, flattenFrameworkControls(...))将 API 返回的FrameworkControls扁平化为 Terraform 属性结构creation_time通过output.CreationTime.Format(time.RFC3339)格式化为标准时间字符串依次写入deployment_status、description、name、status。其中arn还被Tags(identifierAttributearn)注解标记为标签关联标识这也是tags属性能够正确导出的原因。数据源定义的 Schema 中所有非参数属性均为Computed: true见 framework_data_source.go即只读、由 Provider 计算填充。control 块框架的合规控制项每个框架由一个或多个control块组成。control列表中的每个元素包含三个子属性子属性类型说明namestring控制名称。例如 “backup plan frequency is at least daily and the retention period is at least 1 year” 这类规则对应的系统控制名input_parameterlist一个或多个输入参数块用于设定控制规则的具体阈值scopelist控制的作用域定义该控制将评估哪些资源真实控制名示例仓库中的 数据源验收测试 验证了以下真实存在的 AWS Backup 控制项可直接参考BACKUP_RECOVERY_POINT_MINIMUM_RETENTION_CHECK恢复点最小保留期检查示例参数requiredRetentionDays 35BACKUP_PLAN_MIN_FREQUENCY_AND_MIN_RETENTION_CHECK备份计划最低频率与最低保留期检查三个参数requiredFrequencyUnit hours、requiredRetentionDays 35、requiredFrequencyValue 1BACKUP_RECOVERY_POINT_ENCRYPTED恢复点必须加密BACKUP_RESOURCES_PROTECTED_BY_BACKUP_PLAN资源受备份计划保护测试中配置了compliance_resource_ids指向一个 EBS 卷compliance_resource_types [EBS]BACKUP_RECOVERY_POINT_MANUAL_DELETION_DISABLED禁止手动删除恢复点。测试通过resource.TestCheckTypeSetElemNestedAttrs逐项断言数据源返回的控制名与参数例如control.*.input_parameter.0.name requiredRetentionDays control.*.input_parameter.0.value 35input_parameter 子块input_parameter由name与value两个键值对组成属性说明name参数名称例如BackupPlanFrequency、requiredRetentionDaysvalue参数取值例如hourly、35在源码中API 层的ControlInputParameter通过flattenControlInputParameters扁平化为name/value映射见 framework.go空参数会被安全忽略。scope 子块scope定义控制的作用范围支持以下三种典型语义指定某一个具体的 AWS 资源通过资源 ID所有带特定标签的备份计划通过标签键值对全部备份计划不配置任何过滤条件。属性类型说明compliance_resource_idslist(string)控制作用域所包含的唯一 AWS 资源 ID 列表如 EBS 卷 IDcompliance_resource_typeslist(string)控制作用域包含的资源类型列表如EBS、RDS、EFStagsmap应用于目标资源的标签键值对用于触发规则评估最多只能提供一个键值对在资源侧的 framework.go 实现中可以看到约束说明“最多一个键值对标签值可选但不能为空字符串”。数据源读取时flattenControlScope会把 API 返回的ControlScope转换回这三个字段见 framework.go。读取一个完整框架的实战示例下面给出一个可直接运行的最小完整示例先创建一个带控制项的框架资源再用数据源读取并输出关键信息结构参考 数据源测试配置并补充了资源文档中的更多控制项。resource aws_backup_framework example { name example_framework description Example framework control { name BACKUP_RECOVERY_POINT_MINIMUM_RETENTION_CHECK input_parameter { name requiredRetentionDays value 35 } } control { name BACKUP_RECOVERY_POINT_ENCRYPTED } control { name BACKUP_RESOURCES_PROTECTED_BY_BACKUP_PLAN scope { compliance_resource_types [EBS] } } tags { Name Example Framework } } data aws_backup_framework example { name aws_backup_framework.example.name } output framework_arn { value data.aws_backup_framework.example.arn } output framework_status { value data.aws_backup_framework.example.status } output framework_deployment_status { value data.aws_backup_framework.example.deployment_status } output framework_controls { value data.aws_backup_framework.example.control }部署前置条件根据 资源文档 的说明要使框架的部署状态最终变为COMPLETED需要先在 AWS 控制台开启资源追踪AWS Config recording以便 AWS Config 记录备份资源的配置变更。未开启时框架可能长期停留在CREATE_IN_PROGRESS或进入FAILED进而影响数据源读取到的deployment_status与status。与框架资源aws_backup_framework的关系数据源是框架管理链路中的“读”半边与之配套的aws_backup_framework资源负责“增删改”两者共享同一套控制/参数/作用域数据结构资源的 Schema 中control为TypeSet必填、至少 1 项input_parameter与scope为可选见 framework.go资源的name为ForceNew不可原地修改见 framework.go因此数据源以name作为查询主键与资源的id即名称天然对应资源在创建、更新、删除时都会通过waitFrameworkCreated/waitFrameworkUpdated/waitFrameworkDeleted轮询DeploymentStatus直至终态见 framework.go而数据源读取的deployment_status正是同一状态机产出的值。从实现看资源与数据源共用了findFrameworkByName/flattenFrameworkControls/flattenControlInputParameters/flattenControlScope等函数定义在 framework.go保证了“写入什么结构、读回什么结构”的一致性。标签读取与测试保障数据源通过tftags.TagsSchemaComputed()声明tags为计算属性见 framework_data_source.go框架的标签会原样导出。仓库通过自动生成的 framework_data_source_tags_gen_test.go 覆盖了标签相关场景包括基础标签读取tags精确匹配空 Map 与 null Map 边界情况Provider 级default_tags与资源标签不重叠时数据源可见性ignore_tags与默认标签/资源标签重叠时的过滤行为。这些测试采用串行执行acctest.RunSerialTests1Level以避免标签类测试相互干扰同时主数据源测试也被标记为Testing(serializetrue)。如果你需要在自己的配置中依赖框架标签做条件判断可以放心使用data.aws_backup_framework.example.tags其行为与资源侧tags_all语义一致。小结aws_backup_framework数据源是一个轻量、只读的查询入口帮你把“已经存在的 AWS Backup 框架”安全地接入 Terraform 配置只需提供name即可获得arn、control含input_parameter与scope、creation_time、deployment_status、description、status与tags等完整信息。其实现基于 AWS Backup 的DescribeFrameworkAPI属性扁平化逻辑与配套资源完全对齐测试覆盖了主流控制项、作用域与标签场景可作为合规审计、跨工作区引用和多区域部署的可靠数据来源。【免费下载链接】terraform-provider-awsThe AWS Provider enables Terraform to manage AWS resources.项目地址: https://gitcode.com/GitHub_Trending/te/terraform-provider-aws创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考