IaC 3.0使用实践总结
基础设施即代码（Infrastructure as Code，简称IaC）理念的核心，是将基础设施的配置、部署和管控逻辑以代码形式固化，实现基础设施的自动化、可复用和可追溯。IaC 3.0是这一理念在2026年的最新实践形态，它不再局限于“用代码管理服务器”，而是将治理范围扩展到了云服务、网络、身份与访问管理、安全配置、数据平台与管道，乃至AI/ML基础设施的全栈领域。
本文基于华为云应用平台AppStage中IaC3.0的工程实践，结合行业通用方法论，系统总结IaC 3.0的使用实践经验。
一、核心概念：IaC 3.0的定位与价值
IaC 3.0以YAML作为输入，经由云原生环境管理服务、IaC执行引擎、Operator平台解析和执行，实现环境自动部署以及动态基础设施的管理。它强调一致、可重复的供给和变更系统及其配置。当代码发生变更后，可以进行自动化测试，测试完成后可自动化地将变更应用到运行系统中。
与IaC 1.0的“自动化”和IaC 2.0的“工程化”不同，IaC 3.0的核心特征是平台化与智能化。它不再是孤立的配置语言工具，而是平台工程体系中的记录系统（System of Record）——一个AI既依赖它、又为其生成代码的系统。
从市场数据来看，IaC市场预计将从2025年的22亿美元增长到2026年的28亿美元，年复合增长率达28.62%，到2032年有望达到128.6亿美元。这一增长背后，正是IaC从“可选项”变为“必选项”的行业共识。
二、实践一：Spec包与Patch包——两种部署模式的设计
IaC 3.0最核心的实践创新，是引入了“包”（Package）的概念来管理基础设施代码，支持两种互补的部署模式。
2.1 IaC Spec包：服务级统一部署
IaC Spec包将同一个服务下所有微服务的IaC代码放在一个代码仓中统一管理。打包生成Spec包后，可以实现服务下所有微服务在同一个服务环境下的一键部署。
这种模式最适合全量、统一的发布场景。当需要上线一个完整的新服务时，Spec包确保了所有微服务的基础设施配置在同一时间点以一致的版本被部署，避免了因分批部署导致的配置不一致问题。
2.2 IaC Patch包：微服务级独立部署
IaC Patch包则走另一条路径：微服务的IaC代码单独管理，放在微服务代码仓中与微服务软件代码共同管理。通过Spec包创建了服务环境之后，可以通过Patch包进行微服务的独立部署。
这种模式适合敏捷、独立的迭代场景。当只需要更新某一个微服务时，无需重新部署整个服务，Patch包可以精准地只变更目标组件。
2.3 实践建议
在实际使用中，两种模式通常是组合使用的：用Spec包完成环境的初始化搭建，用Patch包进行日常的增量迭代。这种“先全量后增量”的策略，兼顾了初始化的一致性和迭代的灵活性。
三、实践二：代码结构设计——从单文件到模块化
IaC 3.0的代码结构经历了从单文件到多文件、再到带global的多文件描述结构的演进。
3.1 单文件描述结构
在IaC主体描述文件meta.yaml中进行变更流程编排，同时定义所有资源。这种结构简单直接，适合小规模场景，但随着资源增多，文件会变得臃肿难以管理。
3.2 多文件描述结构
通过引入resources.yaml和文件引用语法，将单文件结构改造为多文件描述目录结构，避免诸多资源的描述都集中于meta.yaml。典型的目录结构如下：
package.json # 包括文档（必须） specs/ # 规格目录（必须） cn_dev_default/ # 开发环境规格目录 cn_product_default/ # 生产环境规格目录 meta.yaml # IaC主体描述文件 config/ business_config.yaml nginx.conf db/ schema.sql values.yaml resources.yaml
3.3 带global的多文件描述结构
这是IaC 3.0的典型目录结构。为解决不同规格目录（如开发环境与生产环境）间的配置复用问题，IaC 3.0支持将公共配置抽取到global/文件夹中，被所有规格目录所复用。
3.4 文件引用语法
更进一步，IaC 3.0支持使用$ref键值对跨文档引用其他文本文件的内容。实践中的建议是：将更新频率较高的属性（如镜像版本号）分散到被引用的独立文件中，这样每次变更只需修改小文件，而无需改动主体描述文件。
四、实践三：依赖关系与流水线编排——让变更有序进行
一次完整的业务变更，往往涵盖多种类型、多个模块的变更，如集群扩容、申请ELB、创建数据库、软件升级等。这些变更之间存在着天然的依赖关系——例如，为一个微服务创建NUWA实例之前，往往需要先创建该微服务的数据库。
4.1 声明依赖关系
IaC 3.0的实践要求：通过代码清晰描述各资源、各模块之间的依赖关系。本质上，这是在描述各模块、各资源之间的依赖关系图谱。
4.2 有向无环图（DAG）执行
在变更过程中，IaC引擎会根据依赖关系生成有向无环图（DAG），并严格按照图中的顺序执行各资源的变更过程。这确保了依赖项先于被依赖项完成部署，从根本上避免了因顺序错误导致的部署失败。
4.3 流水线编排
组件间的编排在meta.yaml中描述。流水线支持串行和并行两种执行模式：
串行任务（
Serial）：按顺序依次执行，适合有严格依赖关系的步骤并行任务（
Parallel）：同时执行，适合相互独立的步骤
实践中，流水线可以处理组件间的升级依赖关系，并通过多阶段方式提供灰度升级能力。例如，可以先灰度升级少量实例验证，再逐步扩大范围，最后全量发布。
五、实践四：从开发到部署——完整工作流
5.1 代码开发与打包
IaC代码的开发遵循与软件代码相同的工程化规范。开发者可以使用两种方式进行代码开发和打包：
使用开发中心：通过开发中心将镜像包和IaC 3.0包直接推送至运维中心
使用本地工具：手动上传镜像包和IaC 3.0包至运维中心
5.2 上传IaC 3.0包
在运维中心，操作路径为：进入AppStage运维中心 → 在顶部导航栏选择服务 → 选择左侧导航栏 → 在类型下拉列表中选择“IAC 3.0包” → 单击“上传”。上传后系统会根据包文件中定义的内容进行解析和准备。
5.3 创建与变更组件
组件是具有相同资源的集合。实践中，通过以下步骤完成组件的创建与变更：
进入环境详情页面
单击“创建组件”，配置组件名称、组件版本和规格参数
在创建组件变更计划中选择变更资源
确认后执行变更
5.4 导出与审计
部署服务支持导出环境当前使用的IaC包，可以导出并查看IaC代码。这一能力使得配置审计和问题排查变得有据可查——任何时候都可以回溯“环境当前长什么样”。
六、实践五：安全与治理——策略即代码
在企业级和受监管环境中，没有策略的IaC是不够的。IaC 3.0的实践要求将策略即代码（Policy as Code）深度嵌入到基础设施定义的每一个层面。
实践中应关注以下安全最佳实践：
版本控制：所有IaC代码纳入版本管理，每一次变更都可追溯
策略即代码：安全护栏不再是外部附加的检查，而是基础设施定义本身的有机组成部分
CI/CD集成扫描：在部署前对IaC配置进行安全扫描
最小权限原则：控制谁可以修改和执行IaC变更
持续监控：检测配置漂移和错误配置
七、趋势与展望：AI正在重塑IaC
2026年最显著的变化是：AI正在大规模介入IaC的生成与运维。
一方面，AI辅助生成IaC代码已成为现实。IBM推出的IaC Spec Kit提供了AI辅助工作流，将业务需求翻译为基础设施代码；aiac等命令行工具允许用户用自然语言描述需求，由LLM生成对应的IaC模板。
另一方面，自愈基础设施正在成为前沿探索方向——通过自主Agent实时识别并从配置漂移和安全错误配置中恢复。基础设施不再是“配置完就放任不管”的静态资产，而是具备自我感知和修复能力的动态系统。
然而，实践者也应保持清醒：AI生成代码的速度远超组织吸收代码的能力。生成式AI会重塑IaC的写法，但它替代不了真正懂系统的人。IaC 3.0的价值恰恰在于：它不只是生成代码的工具，更是验证、治理和部署代码的平台。
八、总结
IaC 3.0的使用实践，可以归结为以下几个核心要点：
两种包模式：Spec包实现服务级一键部署，Patch包实现微服务级独立部署，组合使用兼顾效率与灵活性
模块化代码结构：从单文件到多文件再到带global的多文件结构，通过文件引用语法实现高复用、低耦合
依赖关系驱动：通过声明依赖关系生成DAG，确保变更有序执行
流水线编排：串行与并行结合，支持灰度升级和多阶段发布
安全内生：策略即代码，安全与基础设施同源、同版本、同流程
AI赋能：AI辅助生成IaC代码，但验证与治理仍需人工把关
把基础设施当作代码来写、来管、来审，让每一次变更都可追溯、可回滚、可审计——这正是IaC 3.0实践的核心价值所在。