Ansible 配置管理与 Terraform IaC

• 静态与动态 Inventory
• 动态 Inventory 插件（AWS/云/脚本）
• 分组策略与大规模管理

Ansible Inventory 管理节点清单，分静态（INI/YAML 文件写死）与动态（运行时从云/CMDB 获取）。动态 Inventory：用云 provider 的动态 inventory 插件（如 aws_ec2、azure_rm、gcp_compute，或脚本/CMDB 自定义）在运行时拉取节点列表，自动发现新节点，无需手工维护。分组策略：用 inventory 的组（group）与变量（group_vars/host_vars）组织节点——按环境（dev/prod）、role（web/db）、zone（region）分组，结合 pattern 选择主机（如 web:&prod）。大规模管理：用 --limit 控制执行范围、forks 控制并发、用 gather_facts 缓存减少开销、按批次分批执行（serial）、用动态 inventory + 分组实现自动化。落地：动态 inventory 拉取 + 统一分组规范 + host_vars/group_vars 管理差异 + 分批/并发执行，支撑大规模节点管理。

动态 Inventory 的核心是"让节点清单来源于真实状态而非手工维护"。分组策略让"按环境/角色批量操作"，大规模管理靠并发、分批与缓存。动态发现 + 分组是规模化 Ansible 的基础。

• 何时需要自定义 Module
• Module 开发规范（返回 JSON、支持 check mode）
• 测试策略

Ansible Module 是 Ansible 执行任务的原子单元，自定义扩展用于内置模块无法覆盖的场景。开发边界：当内置模块不足（如私有系统 API、特定软件集成）时开发自定义 module；应优先用 command/shell 组合或已有模块，真正需要时才写 module（运维层应避免过度自定义）。开发规范：module 用 Python 编写，输入通过 module.params，输出以 JSON 返回（module.exit_json/fail_json），需支持 check_mode（幂等检查）与幂等性（重复执行结果一致），返回 changed 状态。测试策略：用 ansible-test 做单元测试与集成测试（合入 Ansiballz 框架），编写测试用例覆盖参数、幂等、check_mode、失败场景；在 CI 中集成 ansible-test 验证模块正确性。落地：定义"何时自定义"的边界，遵循规范编写，用 ansible-test 做单元/集成测试质量保障。

自定义 Module 的核心是"规范 + 幂等 + 测试"。边界是"内置无法覆盖才写"，规范是"JSON 输出、支持 check_mode、幂等"，测试是"ansible-test 保障质量"。避免滥写模块导致维护负担。

• 幂等性的概念
• 幂等 module 与条件判断
• changed_when/register 与验证

幂等性指"无论执行多少次，最终状态一致"，是 Ansible Playbook 的核心设计原则。设计原则：优先使用幂等模块（如 file、package、service、copy、template——它们内部判断"是否需要变更"），避免使用非幂等命令（command/shell 每次执行都报 changed）或需配合 creates/when 条件。实现手段：用 register 捕获结果 + when 条件判断（如"已存在则跳过"）、用 changed_when 自定义 changed 判定（如命令输出无变化则 not changed）、用 state 参数（present/absent）声明目标状态。验证：多次执行应产生相同结果（第二次 changed=false），通过 --check（check mode）预览。落地：复用幂等模块、用条件与 changed_when 控制非幂等命令、用 check mode 验证，确保"重复执行结果一致、无副作用"。

幂等性的核心是"声明目标状态而非执行步骤"。幂等模块是首选，非幂等命令需用条件/changed_when 显式控制。check mode 验证是保证幂等的实践手段。

• Role 的目录结构
• Role 的复用与依赖
• Role 命名与版本化

Ansible Role 是组织可复用配置代码的标准方式，有固定目录结构（tasks/main.yml、handlers/main.yml、vars、defaults、templates、files、meta）。最佳实践：按"职责单一"设计 Role（如 nginx、postgres、app），把默认配置放 defaults（可覆盖）、内部变量放 vars、敏感变量放 vault 或 group_vars；用 templates 渲染配置、用 handlers 处理重启；Role 间用 meta/dependencies 声明依赖，减少耦合。复用：把通用 Role 放独立仓库并版本化（Galaxy 或私有仓库），用 Ansible Galaxy 或 requirements.yml 管理依赖；定义清晰的输入变量（role 的 interface）与文档。命名规范：Role 名用"作者-角色"（如 geerlingguy.nginx），版本化遵循 semver。落地：按职责拆分 Role、规范目录与变量、用 Galaxy/requirements 管理复用、版本化与文档化，形成可复用、可测试的配置库。

Role 的核心是"职责单一 + 结构规范 + 可复用"。默认值/变量分离、templates/handlers 规范、依赖管理、版本化，让 Role 可被多个项目复用且可维护。是 Ansible 工程化的基石。

• Tower/AWX 的核心能力（作业、调度、RBAC、审计）
• 多租户治理（组织/团队/项目）
• 与 CI/CD 集成

Ansible Tower（商业版）/AWX（开源版）是 Ansible 的可视化与企业级管理平台。核心能力：作业模板（Job Template）封装 Playbook、图形化执行、调度（定时）、RBAC（角色权限）、审计（作业日志）、库存管理、凭据管理（Vault 加密）、通知（失败告警）。多租户治理：用 Organization（组织）→ Team（团队）→ 用户 的层级隔离，按组织/项目/库存/作业模板划分权限，实现"多部门/多业务共享平台但权限隔离"；用 RBAC 控制谁能看、谁能跑、谁能改。集成：与 CI/CD 集成（通过 Tower API 或 AWX CLI 触发作业）、与 Git 集成（拉取 Playbook）、与 SSO（LDAP/OIDC）集成。落地：定义组织/团队/项目层级，用 RBAC 与凭据隔离实现多租户治理，用作业模板与调度规范化执行，用审计与通知保证可追踪。

Tower/AWX 的价值是"把 Ansible 变成企业级、可治理、可审计的平台"。多租户治理靠组织/团队/权限隔离，RBAC 与凭据隔离是关键，审计与调度保证规范化。适合大型团队统一管理 Ansible。

• Ansible Vault 的加密对象（变量/文件）
• Vault 密钥（password）管理与轮换
• 与 CI/集成的最佳实践

Ansible Vault 用于加密敏感数据（变量、文件、整个 inventory），工程实践的核心是"加密什么、密钥放哪、如何轮换"。加密对象：对敏感变量（密码、密钥、token）用 ansible-vault encrypt 加密（可加密单个变量、vars 文件、或文件），Playbook 运行时自动解密。密钥管理：Vault 的 password 有多个来源（--ask-vault-pass、vault password file、环境变量 ANSIBLE_VAULT_PASSWORD_FILE、Vault 插件如 HashiCorp Vault）；企业常用"vault password file + 权限控制"或"password store"集中管理，避免明文密码。多密钥：用 --vault-id 支持多个 vault 密钥（不同环境/用途不同 key）。密钥轮换：定期更换 vault password，用 ansible-vault rekey 重新加密（用新密码重写文件），或配合密钥管理服务轮换；轮换后更新所有引用。与 CI 集成：CI 中把 vault 密码放密文/密钥管理（如 CI secret），避免明文进仓库。落地：Vault 加密敏感数据 + 集中密钥管理 + 多 vault-id + 定期 rekey 轮换 + CI 密钥安全注入。

Vault 的核心是"加密数据 + 管好密钥 + 定期轮换"。加密防止明文泄露，密钥管理（password file/密钥服务）防止密钥泄露，轮换（rekey）降低密钥泄露风险。与 CI 集成要保证密钥不进明文仓库。

• facts 收集的开销
• fact caching（redis/jsonfile）
• 大规模节点的优化

Ansible facts 收集（gather_facts）在每次运行都连接到节点收集系统信息，在大规模节点下会造成明显性能开销（大量 SSH 连接与轮询）。优化：对不需要 facts 的 Playbook 关闭 gather_facts: no，或按需用 gather_subset 收集子集（如只收集网络/CPU），减少收集量。fact caching：用缓存避免每次运行都重新收集——把 facts 缓存到 redis 或 jsonfile，后续运行直接从缓存读取（fact_caching = redis 或 jsonfile，设 fact_caching_timeout）。redis 缓存适合大规模、分布式、多控制机场景（集中缓存、读写快）；jsonfile 简单但为单机、文件 I/O。在大规模下：开启 fact caching + 按需收集子集 + 提高 forks 并发 + 关闭不必要 gather，能显著提升运行性能。落地：按需 gather_facts、用 redis/jsonfile 缓存 facts、配合 forks 调优，减少重复收集的 SSH 开销。

facts 收集的开销源自"每次连接的轮询"。缓存（redis/jsonfile）让 facts 跨运行复用，按需收集子集减少数据量，是规模化优化的关键。redis 适合大规模集中缓存，jsonfile 适合轻量场景。

• forks 并发
• pipelining（SSH 管道）
• async 异步任务与策略

Ansible 性能优化针对大规模节点。forks：控制并发执行节点数（forks = 20，默认 5），提高 forks 可并行处理更多节点，但受控制机资源与 SSH 连接限制，需平衡。pipelining：开启 SSH pipelining（pipelining = True）减少 SSH 连接往返次数（把模块执行通过管道传输，减少临时文件与连接），可显著提升小任务性能，但需 sudo 配置配合。async：对耗时任务（如长命令、软件安装）用 async 异步执行（async 指定超时、poll 轮询间隔），把任务放到后台并行，避免阻塞整个 Play；配合 async_status 查询结果。策略（strategy）调优：linear 默认线性执行，free 策略让各节点独立推进（不受其他节点阻塞），适合无明显依赖的批量任务；host_poll_interval 加快轮询。综合：用"提高 forks + 开启 pipelining + 耗时任务 async + 按需选 free 策略"提升大规模节点执行效率，并结合 fact caching 减少重复收集。

性能优化的核心是"减少等待与串行"。forks 增加并行、pipelining 减少连接开销、async 把耗时任务后台化、free 策略打破节点间互相等待，四者配合并辅以 fact caching，才能系统性提升大规模执行效率。

• handlers 与 notify 的触发机制
• changed_when 配合
• 常见陷阱（多次触发、依赖顺序）

handlers 是"仅在变动时执行"的处理程序（如重启服务），通过 notify 触发。触发机制：任务在"changed"（状态变化）时 notify 对应 handler，handler 在 Play 中所有任务执行完后运行一次；同一 handler 被多次 notify 也只执行一次（在 Play 末尾）。changed_when 配合：对非幂等命令或自定义判断，用 changed_when 显式定义"何时算 changed"（如命令输出含某个标志），确保 notify 在期望时触发、避免误触发。常见陷阱：多次触发——同一 handler 被多个任务 notify 只执行一次，避免重复；但若任务都 changed 且 handler 有副作用，需注意 changed_when 判定。依赖顺序——handler 在 Play 末尾执行，若后续任务依赖 handler 结果会失败（需用 meta: flush_handlers 提前处理）；handler 顺序固定但依赖需用 listen 或合理安排。落地：用 notify+handlers 做"变更后重启"，用 changed_when 精确控制触发，用 meta: flush_handlers 处理依赖顺序，避免多次触发与顺序陷阱。

handlers 的核心是"只在变更时、只在 Play 末尾、只执行一次"。changed_when 让触发条件可控，flush_handlers 解决顺序依赖。理解这些机制避免"重启多次/顺序错乱"。

• 各工具架构（push/pull、agent/agentless）
• 语言与学习成本
• 适用场景

Ansible、Puppet、Chef、SaltStack 是主流的配置管理工具，架构与理念不同。Ansible：无 agent（agentless，基于 SSH），push 模式，用 YAML 声明式，学习成本低、上手快，适合运维自动化与临时任务。Puppet：有 agent（pull 模式），用 Puppet DSL 声明式，强调目录（catalog）与期望状态，适合大规模、长期状态管理，但 DSL 学习成本高。Chef：有 agent（pull 模式），用 Ruby DSL（recipe/cookbook 命令式），灵活但学习成本高、技术要求高。SaltStack：有 agent（可选 agentless），用 YAML/pillar 状态管理，速度快、支持 event-driven，master-minion 架构。选型考量：简单/快速/agentless 选 Ansible；大规模/长期/声明式状态管理选 Puppet；Ruby 生态/高度定制选 Chef；高性能/事件驱动选 SaltStack。落地：按团队技能、架构（agent/agentless）、规模与运维需求选择，Ansible 因无 agent 与低门槛常被选为入门与通用工具。

选型的关键是"架构（agent vs agentless）、语言（声明式 vs 命令式）、规模与技能"。Ansible 无 agent 易上手，Puppet/Chef 有 agent 适合长期状态管理，SaltStack 高性能。按实际运维场景权衡。

• import 的用途与安全
• state 操作命令（rm/mv/pull/push）的风险
• 操作安全与权限

Terraform import 与 state 操作是管理"已存在资源"的工具，但需明确安全边界。import：把真实资源导入 state（只写入 state，不创建/不修改资源），用于接管存量资源；安全边界是"import 后必须配置对齐，否则 plan 显示大量 diff，可能误删/误改"。state 操作命令：terraform state rm（从 state 移除资源，使其脱离 Terraform 管理，不再被 apply 删除）、terraform state mv（移动资源地址，用于重命名/重构）、terraform state pull/push（导出/导入 state 文件）。风险：state 是"真相"，手动操作（rm/mv/push/pull）可能造成 state 与真实资源不一致、丢失资源映射、或把错误 state 推送给共享后端，导致生产资源失控。安全边界：限制 state 操作权限（仅授权角色可执行）、避免手动编辑 state、用远程后端 + 锁 + 版本化保护、操作前备份 state、rm 前确认资源不再需要（rm 后 Terraform 不再管它，但真实资源仍在，需另行清理）。落地：明确"谁可操作 state"，import 后对齐配置，rm/mv 谨慎并备份，生产环境加审批。

state 操作的安全边界是"state 即真相，操作需谨慎"。import 是接管不修改，rm/mv 是变更管理边界，pull/push 是迁移。权限管控 + 备份 + 对齐是避免"state 与真实失控"的关键。

• Module 版本化（semver）
• 注册中心（registry/Git 引用）
• 版本约束与升级

Terraform Module 版本化与注册中心是模块复用的最佳实践。版本化：用 semver 版本（v1.2.0）标注模块变更，遵守语义化版本（major 破坏性变更、minor 新增、patch 修复），发布按版本打 tag。注册中心：把模块发布到公开/私有 registry（Terraform Registry、Terraform Cloud Private Registry、自建兼容 registry）或 Git 仓库（source = "git::https://...//modules/xxx?ref=v1.2.0"），用授权管理访问。版本约束：使用处用 version 约束（如 ~> 1.2 允许 minor/patch）锁定版本，避免无约束升级破坏；升级时先看 changelog、在测试环境验证、再晋升。最佳实践：模块统一命名与规范（输入输出文档、测试、README）、版本晋升流程（dev→staging→prod 用同一版本）、模块 Owner 与评审、依赖锁定与兼容性验证。用 registry 集中管理 + 版本约束 + 晋升流程，避免"各自复制代码"与"版本漂移"。

模块治理的核心是"复用 + 版本 + 受控升级"。registry 是发布与管理的中心，版本约束是消费的护栏，晋升流程是变更控制。避免无版本与无约束导致的不兼容。

• Plan/Apply 分离
• CI/CD 集成（plan 评审、apply 审批）
• 多环境滚动

Terraform Plan/Apply 工作流与 CI/CD 集成，核心是"plan 评审、apply 审批"。工作流：init → plan（生成变更计划）→ 评审 → apply（应用）。CI/CD 集成模式：CI 中运行 terraform plan，把 plan 输出作为 PR/MR 评审依据（通过 plan comment/artifact 展示变更），有一个"plan 门禁"；通过后，apply 在受控环境执行（生产环境人手审批或环境审批）。可用工具：GitHub Actions、GitLab CI、Jenkins、Terraform Cloud 的 Run 工作流（plan 后人工 apply）。多环境滚动：按 dev→staging→prod 多环境，用 workspace/目录隔离，每个环境单独 plan/apply，先低风险环境验证再晋升。最佳实践：plan-only 在 CI（评审看到变更）、apply 需审批（生产双人）、plan 与 apply 用同一 state 与版本、失败可回滚、tfsec/checkov 安全扫描作为门禁。落地：CI 里 plan + 安全扫描 + 评审，apply 审批 + 多环境滚动 + 审计。

Plan/Apply 集成的核心是"让变更可评审、可审批"。plan 在 CI 生成可评审的 diff，apply 在受控环境审批执行，多环境滚动控制风险。这是 IaC 变更安全的最佳实践。

• Provider 开发框架（Terraform Plugin SDK/protocol）
• 自定义资源与数据源
• 数据源设计

当内置 provider 无法覆盖（私有系统、自定义 API）时，需开发自定义 Terraform Provider。框架：用 Terraform Plugin SDK（v2）或 Plugin Framework（protocol v5/v6）编写，用 Go 语言实现 provider 的 schema 与 CRUD。设计：定义 Resource（可创建/更新/删除的资源）与 Data Source（只读查询，如拉取外部数据），每个实现 schema（属性）、CRUD 方法（Create/Read/Update/Delete）与幂等。数据源设计：数据源用于读取不归 Terraform 管理的资源（如查询现有 AMI、VPC、外部 API 数据），实现 Read 方法返回属性，供配置引用；数据源设计要保证"只读、可缓存、返回稳定字段"。质量：遵循 HCL schema 规范、支持 schema 校验、支持 terraform plan 的 diff 与 import、写测试（terraform-plugin-testing）。落地：评估是否需要自定义 provider（优先用内置/community），用 SDK/框架开发，规范 schema 与幂等，测试覆盖。

自定义 Provider 的核心是"用 Go + SDK 实现资源的 CRUD 与数据源读取"。资源要幂等、支持 plan/import，数据源只读返回稳定字段。provider 是扩展 Terraform 到私有系统的通道。

• 远程后端（S3/OSS + 锁）
• 状态锁与并发冲突
• 团队协作与 workflow 隔离

Terraform State 管理解决团队协作的关键是"远程共享 + 加锁 + 隔离"。远程后端：用 S3/OSS + DynamoDB 锁（或 Terraform Cloud）共享 state，避免多人各自本地 state 导致不一致。状态锁（DynamoDB）：并发 apply 时，后者获取锁失败报错，防止两个 apply 同时写 state 造成冲突/损坏。协作冲突解决：一个 state 文件对应一个"可独立变更的单元"（如一个环境/一个组件），通过拆分 state（按环境/模块/组件分文件）减少多人同时改同一 state 的冲突；用 workspace 隔离环境（但共享后端）；对同一 state 的并发变更，用锁 + 审批 + 串行化（CI 中排队）。团队 workflow：代码评审（plan 变更）→ 审批（apply）→ 锁保护，多人协作时用"一个 state 一个人/一个流水线"避免冲突。落地：远程后端 + 锁 + 拆分 state + 审批/串行化，解决多人协作冲突。

协作冲突的核心是"共享 state + 锁 + 隔离变更单元"。远程后端共享，锁防并发写，拆分 state 减少冲突面，审批与串行化保证变更可控。是 IaC 团队协作的基础设施。

• Terraform 声明式 vs Pulumi/CDK 编程式
• 选型考量
• 迁移路径

Terraform 是声明式（HCL），Pulumi/CDK 是编程式（真实语言）。选型对比：Terraform 声明式、跨云、生态成熟、state/module 完善，适合团队熟 HCL、依赖 Terraform 生态与云中立；Pulumi 用 Python/TS/Go 等编程语言，支持循环/条件/抽象/组件复用，类型安全，适合团队擅编程、需复杂逻辑与多云；CDK（AWS CDK/CDKTF）更适合 AWS 深度或需用 CDK 生态。选型考量：技能（HCL vs 编程语言）、生态依赖（Terraform 模块 vs 编程库）、云绑定（多云 vs 单云）、复杂度（简单声明 vs 复杂逻辑）。迁移路径：从 Terraform 迁 Pulumi/CDK 可用工具（Pulumi 的 pulumi convert 从 Terraform 转换，或 CDKTF 从 Terraform 代码生成）；迁移时先小范围试点（转换一个模块/环境），对比 state 与资源，逐步迁移，分阶段验证。逆向也可（Pulumi/CDK 迁 Terraform 用 terraform import 或转换）。落地：按"技能/生态/云绑定"选型，迁移用转换工具 + 试点 + 逐步验证。

选型核心是"声明式 vs 编程式"，各有用武之地。迁移路径关键是用转换工具 + 试点 + 逐步验证，避免一次性全量迁移。选型要匹配团队与生态。

• Workspace 多环境
• Directory（目录）多环境
• Module 参数化

Terraform 多环境管理（dev/staging/prod）有三种策略。Workspace：用 terraform workspace 管理多个环境，共享同一套代码，state 按 workspace 隔离（同一后端、不同 key），适合环境差异小、同一代码库的场景；缺点是 workspace 间 state 共享易误用、变量管理需用 terraform.workspace 插值。Directory：每个环境一个目录（environments/dev、environments/prod），各自独立 main.tf 与 backend（不同 state key），环境隔离最清晰，适合环境差异大、需要独立配置/审批的场景；缺点是代码重复（可用模块复用）。Module 参数化：把复用逻辑封装成模块，用不同变量（环境、region、规格）实例化，多环境共用模块但参数不同，保证一致性与复用。取舍：小差异用 Workspace，大差异/独立审批用 Directory，共享逻辑用 Module 参数化。常组合：Directory 分环境 + Module 复用 + 变量参数化。落地：按"环境差异 + 审批隔离 + 复用"选择，Directory 保隔离、Module 保复用、Workspace 保简单。

多环境管理的核心是"隔离 + 复用"。Workspace 简单但隔离弱，Directory 隔离强但重复，Module 保复用。通常 Directory（环境）+ Module（复用）+ 变量参数化是推荐的组合。

• 漂移的原因与检测
• 自动修复（apply 收敛）
• 工程实践（CI 检测、告警）

漂移（drift）指真实资源与 Terraform state/配置不一致（被控制台手工修改、被其他工具/脚本改动、被云自动伸缩）。检测：terraform plan 会显示配置与真实资源的差异（漂移）；terraform plan -detailed-exitcode 可检测是否有漂移；可定期用 terraform plan 或漂移检测工具（如 Driftctl、CloudFormation drift detection）扫描。自动修复：若漂移是"非期望的"，用 terraform apply 让配置收敛回声明的状态（issue 手动改的会被纠正）；若漂移是"期望的"（如外部工具管理），需更新配置或用 ignore_changes 避免 Terraform 去纠正。工程实践：把 plan 漂移检测做成 CI 定时任务（定期 plan，检测到漂移即告警/工单）；配置"漂移"告警（如 plan 输出有 diff 时通知）；对漂移资源评估是"纠正"还是"接受"；用 terraform plan 作为"配置与真实对照"的持续检查。落地：定期 plan 检测漂移 + 告警 + 评估处置（apply 收敛/ignore_changes/更新配置）。

漂移治理的核心是"检测 + 判断 + 收敛"。plan 是检测手段，apply 收敛非期望漂移，ignore_changes 接受外部管理的属性。定期检测 + 告警让漂移可被发现与处置，避免"配置与真实越走越远"。

• 依赖图（DAG）与隐式引用
• depends_on 显式依赖
• 并行 apply 的行为差异

Terraform 构建资源依赖图（DAG）决定 apply 的执行顺序与并行度。隐式引用：当资源 A 引用资源 B 的输出（如 aws_instance.web.id 传给 aws_security_group 或 aws_elb 的 instance），Terraform 自动建立 A→B 的依赖，B 先创建。depends_on 显式依赖：当没有属性引用但有逻辑依赖（如 A 依赖 B 的副作用）时，用 depends_on = [B] 显式声明。行为差异：隐式引用能精确表达"数据依赖"（B 的输出被 A 用），Terraform 据此排序；depends_on 表达"非数据依赖"，强制 A 在 B 之后。并行 apply 中，无依赖关系的资源并行执行（Terraform 并发），有依赖的串行（等依赖完成后）。优化：合理组织依赖，让独立资源并行（提升 apply 速度），避免过度的 depends_on（会串行化、降低并行、且无语义依据）。依赖图还决定"替换顺序"（create_before_destroy 等）。落地：优先用隐式引用表达数据依赖，仅对无属性但有逻辑依赖用 depends_on，保持依赖图简洁以利于并行。

依赖图的核心是"数据依赖（隐式）与逻辑依赖（显式）"。隐式引用精确且利于并行，depends_on 用过度会串行化并降低并行度。理解依赖图才能合理组织资源以提升 apply 性能。

• block/rescue/always 错误处理
• ignore_errors 的边界
• 何时必须失败停止

Ansible 错误处理用 block/rescue/always 与 ignore_errors。block/rescue/always：类似 try/catch/finally——block 定义一组任务，rescue 在 block 中任务失败时执行（错误处理/补救），always 无论成败都执行（清理/收尾）。ignore_errors：忽略指定任务的失败继续执行（ignore_errors: true），用于"不影响主流程"的辅助任务。工程边界：ignore_errors 只用于"失败可容忍"（如清理、非关键通知），不能掩盖关键错误；对关键步骤（部署、配置、服务启动）失败必须失败停止（fail fast），否则会把失败状态带入后续导致更大问题。设计原则：用 block/rescue 做结构化错误处理（失败后补救/回滚），用 always 做清理，用 ignore_errors 仅对可容忍任务；关键链路失败时用 fail 模块或让任务失败（不 ignore）触发停止。落地：block/rescue/always 组织错误处理，ignore_errors 限定可容忍任务，关键失败 fail fast 并告警。

错误处理的核心是"区分可容忍与关键失败"。block/rescue 结构化处理（补救/回滚），always 保证清理，ignore_errors 只用于可容忍任务；关键步骤失败必须停止（fail fast），避免错误状态蔓延。边界要清晰。

• Terraform（资源/生命周期）与 Ansible（配置/软件）的边界
• 协作分工模式
• 避免职责重叠

Terraform 与 Ansible 的经典分工是"Terraform 管资源生命周期，Ansible 管配置与软件"。Terraform：负责创建/更新/销毁云资源（实例、网络、存储、安全组），管理资源的生命周期与 state，处理"资源存在与否、规格如何"。Ansible：负责资源内部的配置（安装软件、配置服务、部署应用、管理文件），使资源"内部状态正确"。协作分工：Terraform 创建资源后，把资源信息（IP、连接信息）传给 Ansible（通过输出/动态 inventory/remote-exec 触发），Ansible 对资源做配置；Terraform 更新资源时，Ansible 重新配置。模式：Terraform apply（建资源）→ 触发 Ansible playbook（配软件）；或 Terraform 用 local-exec/remote-exec 调 Ansible，或外部编排（CI）串联两者。避免重叠：不把"软件安装"做进 Terraform（用 provisioner 是反模式），不把"资源创建"做进 Ansible（Ansible 不建云资源），保持职责单一。落地：Terraform 管"是什么"，Ansible 管"怎么配置"，用传递信息串联，避免 provisioner 滥用。

分工的核心是"不一致的边界"：Terraform 管资源生命周期，Ansible 管资源配置。保持职责单一可避免"provisioner 滥用"与"Ansible 建资源"的混乱，用 CI/编排串联两者。

• 常见误区（provisioner、state 安全、模块化）
• 避免方法
• 最佳实践

Terraform 常见误区及规避：其一，滥用 provisioner——用 provisioner 做软件配置（非幂等、不记录 state），应改用配置管理工具（Ansible/cloud-init/Packer）或不可变镜像；provisioner 仅在必要时最小化使用。其二，忽视 state 安全——state 含敏感信息，用本地/无锁/无加密会泄露与冲突，应改用远程后端（S3/OSS）+ 加密 + 锁 + 最小权限 + 版本化。其三，缺乏模块化——把所有资源写在一个大 tf 文件，难以复用与维护，应拆分模块（按层/业务）、版本化、规范输入输出。其他误区：忽略 ignore_changes/lifecycle（导致无谓重建）、用 count 管理易变集合（索引漂移）、plan 与 apply 不分离（无评审直接 apply）、硬编码密钥（应注入/secret）。规避：遵循最佳实践——模块化、远程 state 安全管理、少用 provisioner、plan 评审、生命周期控制、最小权限、密钥管理。落地：用 Terraform 的最佳实践规避常见误区，形成规范与评审。

常见误区本质是"把 Terraform 用错"。provisioner 滥用违背"声明资源"，state 不安全的隐患是泄露与失控，无模块化导致不可维护。规避靠"模块化 + state 安全 + 少 provisioner + 评审"。

• 多环境管理（dev/staging/prod）
• 团队协作（远程 state、评审）
• 变更审计（plan 记录、审批）

Terraform 生产落地案例综合多环境、协作与审计。多环境管理：用 Directory（各环境目录）+ Module 复用 + 变量参数化，各环境独立 state（S3 key 隔离），先 dev 后 staging 再 prod 滚动。团队协作：用远程 state（S3 + DynamoDB 锁）+ 分支/PR 工作流，plan 在 PR 中评审，apply 走审批门禁，分工明确（模块 owner、环境 owner）。变更审计：每次 apply 记录 plan 输出与变更人/时间，state 版本化（S3 版本控制），CI 中保留 plan 产物，配合政策即代码（conftest/checkov）与审计日志，做到"谁在何时改了哪条资源"可追溯。落地：多环境（Directory + Module + 独立 state）→ 团队协作（远程 state + PR 评审 + 审批 apply）→ 变更审计（plan 留档 + state 版本化 + 审计日志），形成可重复、可审计、可协作的生产 IaC 流程。

生产落地的关键是"环境隔离 + 协作受控 + 变更可审计"三件事。环境隔离靠独立 state 与模块，协作靠 PR 评审与审批门禁，审计靠 plan 留档与 state 版本化，三者闭环才能支撑生产环境的安全变更。

• IaC 核心概念（声明式/命令式）
• 可重复、可审计的价值
• 声明式定义与交付

IaC（基础设施即代码）是把基础设施用代码定义并管理，替代手工配置。核心概念：声明式（Describe 目标状态，如 Terraform/Pulumi）与命令式（Describe 操作步骤，如 Ansible/脚本）两种范式；声明式声明"期望状态"，工具自动计算差异并收敛，天然幂等。价值：可重复——同一份代码在任何环境产出一致结果，消除手工漂移与"环境差异"；可审计——基础设施变更以代码 diff、plan、apply 记录呈现，可追溯到人/时间/版本，配合 Git 与 CI 可审查；可版本化——随代码演进、可回滚、可协作。声明式如何实现可重复、可审计：代码即事实（Git 仓库保存定义），执行时工具对比期望状态与实际状态（plan/diff），apply 后记录到 state，整个流程可评审、可回放、可审计，从而保证"环境可重复、变更可审计"。

IaC 的价值本质是"把基础设施变更纳入软件工程实践"。声明式通过"期望状态 + 自动收敛"保证可重复，通过"代码 + plan + state"保证可审计。回答应先讲概念再讲价值，落到"可重复、可审计"两个核心。