一次面试反馈让我重新思考技术学习的方式。"你用过这些工具，但技术深度不够。"这句话点醒了我——光看文档不够，必须动手搭建真实的多环境基础设施。我用Terraform、Terragrunt和Ansible从零搭建了开发、预发布、生产三个环境，这篇文章记录完整的搭建过程和踩坑经验。
很多开发者的Terraform工作流是这样的：写main.tf，执行terraform apply，完事。单环境确实够用，但真实公司的代码不会直接上生产。标准流程是三层：开发环境供程序员实验，东西坏了没关系；预发布环境是生产的镜像，QA在这里做发布前测试；生产环境跑真实流量，每次失误都有代价。
当你试图把单份的main.tf扩展到三个环境，三个问题立刻暴露。第一是代码重复。你把main.tf复制到environments/dev、environments/staging、environments/prod三个目录，现在你有三份完全相同的文件。开发环境加了新资源，你得手动同步到另外两个环境。漏掉一次，三个环境就悄悄分道扬镳。
第二是状态文件冲突。Terraform把基础设施的当前状态保存在terraform.tfstate文件里。如果三个环境往同一个S3路径写状态，开发环境的一次apply可能直接覆盖生产环境的状态记录。基础设施状态丢失，恢复起来极其麻烦。
第三是没有访问控制。不做IAM隔离的话，任何拿到AWS凭证的工程师都可能手滑在错误的环境执行terragrunt apply。这次实战就是为解决这三个问题而设计的。
整个项目的目录结构分为三层。_base目录存放统一的Terraform入口文件main.tf，以及EC2、安全组、VPC三个模块。ansible目录包含配置文件、按环境分组的环境变量、基于AWS标签的动态主机清单，以及具体的playbook和角色定义。live目录是Terragrunt的工作区，根配置文件定义S3后端和状态锁定，dev、staging、prod三个子目录各自存放环境专属的配置值。
执行流程是这样的：在live/dev目录运行terragrunt apply，工具先读取根目录的terragrunt.hcl自动生成backend.tf，再读取dev目录的配置获取环境专属参数，然后调用_base/main.tf创建VPC、安全组和EC2实例，最后触发null_resource执行Ansible完成服务器配置。
这套架构的核心价值在于"一份代码，多处部署"。基础模块只定义一次，环境差异通过Terragrunt的变量注入解决，状态文件按环境隔离存储，配合IAM策略就能实现权限管控。从面试被拒到完整跑通三环境自动化，最大的收获是理解了Infrastructure as Code在真实业务场景下的复杂度——不是工具会用就行，而是得想清楚代码复用、状态隔离、权限边界这些工程问题怎么解。
热门跟贴