https://blog.yuanpei.me/tags/devops/Recent content in Devops on 元视角Hugozh-cnWed, 20 May 2026 00:00:00 +0000https://blog.yuanpei.me/posts/terraform-minimal-guide/Wed, 20 May 2026 00:00:00 +0000https://blog.yuanpei.me/posts/terraform-minimal-guide/缘起：为什么需要 Terraform 最近，我参与了一个 AWS Serverless 项目。业务需求本身并不复杂：几个 Lambda 函数、一个 S3 存储、一个 EventBridge 定时触发，再加上精细化的 IAM 权限控制。在部署这套服务的过程中，我先后尝试了三种方案，几乎踩遍了云基础设施管理中的经典巨坑： AWS Console：一开始为了快，直接上控制台点鼠标。创建 S3 Bucket、手动上传 Lambda zip 包、配置 EventBridge 规则。问题是：项目要部署到 dev、staging、prod 三个环境，在控制台里点一遍要花半小时，三个环境配置完一个半小时。两个月后，当有人问“这个安全组是谁配的，为什么开了 443端口”时，没人说得清。 SAM：手动上传 zip 太繁琐，同事推荐了 SAM，通过一个 template.yaml 定义 Lambda 和权限，结合 sam build && sam deploy 确实省心。但当面对 VPC、安全组、S3 高级配置、更精细的 IAM 策略时，SAM 显得力不从心。于是我变成了“混合打法”：SAM 管理 Lambda，其余资源还是在控制台管理。两个工具，两套流程，让人身心俱疲。 Terraform：运维同事终于看不下去了：“你这些资源应该用 Terraform 管理起来”。我一开始是抗拒的——一个 S3 Bucket 要写好几行代码，还要声明 Provider、定义变量，控制台里点几下搞定的事，为什么要大费周章写代码？ 但是，很快一次意外说服了我。某天，有人在控制台里偷偷修改了路由表，却没有同步到代码中。第二天跑 terraform plan，配置漂移直接暴露。那一刻我才真正顿悟：Terraform 不仅仅是帮你创建资源的工具，更是帮你锁定“期望状态”的终极防线。 故事到这里，你以为我全面拥抱 Terraform 了？并没有。对于 Lambda 函数的代码部署，我最后还是选择用 GitHub Actions + AWS CLI。因为：Terraform 擅长管理静态的基础设施，而高频的代码迭代更适合放在专业的 CI/CD 流水线中。所以，我最终的工程实践是：Terraform 掌管资源拓扑，CI/CD 流水线负责代码交付。架构没有银弹，关键在于各司其职。