infra-as-code

核心用法

本 Skill 提供三大主流 Infrastructure as Code（IaC）工具的全面实践指南。Terraform 部分涵盖 HCL 语法、模块化架构、远程状态管理（S3 + DynamoDB）、工作空间多环境隔离，以及 VPC、EC2、RDS、Lambda、S3 等核心 AWS 资源的配置示例。CloudFormation 侧重 YAML 模板编写、参数化配置、变更集（Change Set）预览机制及栈生命周期管理。Pulumi 则展示如何使用 TypeScript/Python 等通用编程语言定义基础设施，支持循环、条件判断等复杂逻辑，适合需要代码级抽象能力的场景。

显著优点

1. 标准化与可复用性：通过模块化设计（modules）和变量抽象，实现跨环境、跨项目的配置复用，避免重复造轮子。
2. 版本控制友好：基础设施代码可纳入 Git 管理，变更历史可追溯，支持 Code Review 流程，显著降低人为配置错误。
3. 变更可视化：terraform plan 和 pulumi preview 提供详细的资源变更预览（创建/修改/销毁），在执行前即可评估影响范围。
4. 多环境管理：通过工作空间（workspaces）或栈（stacks）机制，配合变量文件（tfvars/config）实现 dev/staging/prod 环境隔离。
5. 成本可控：集成 Infracost 等工具可在部署前估算月度云资源成本。

潜在缺点与局限性

1. 学习曲线陡峭：需要同时掌握云服务商概念（VPC、IAM、安全组）和 IaC 工具语法，初学者容易在状态管理和依赖关系上踩坑。
2. 状态管理复杂性：Terraform 状态文件（state）是单点故障源，一旦损坏或泄露可能导致基础设施失控或敏感信息暴露。
3. 云厂商锁定：虽然 Terraform 支持多云，但具体资源配置仍深度绑定 AWS/Azure/GCP 的 API 细节，跨云迁移成本不低。
4. 调试困难：基础设施漂移（drift）问题排查需要深入理解状态文件与实际资源的映射关系，错误信息有时晦涩难懂。

适合的目标群体

• DevOps 工程师：负责 CI/CD 流水线、云资源编排和自动化部署
• 云架构师：设计可扩展的多环境基础设施架构
• 全栈开发者：需要独立管理应用依赖的数据库、缓存、对象存储等资源
• SRE 团队：实施 GitOps 流程，保障基础设施变更的可观测性和可回滚性

使用风险

1. 权限配置风险：示例中的 IAM 策略若直接复制到生产环境，可能因过度授权（如 * 通配符权限）导致安全漏洞。
2. 状态文件安全：虽然文档建议使用远程加密存储，但用户若误将 .tfstate 提交到 Git，会泄露数据库密码等敏感信息。
3. 资源误删：误操作 terraform destroy 或配置错误 deletion_protection 可能导致生产数据永久丢失。
4. 依赖版本冲突：Provider 版本未锁定（未使用 ~> 约束）可能导致不同成员执行时出现非预期行为。
5. 网络隔离风险：安全组规则示例中开放了 0.0.0.0/0 访问，生产环境需根据实际业务收紧 CIDR 范围。