5.5 KiB
5.5 KiB
title, type, tags, date
| title | type | tags | date | |||||||
|---|---|---|---|---|---|---|---|---|---|---|
| CTP Topic 3 Deploy and Maintain Infrastructure | source |
|
2026-04-14 |
Source File
Summary（用中文描述）
- 核心主题：AWS Landing Zone 环境下的基础设施部署与维护机制
- 问题域：产品团队如何在 Landing Zone 多账号架构中高效、一致、可复用地部署基础设施
- 方法/机制：通过 Terraform 模块化 + Terragrunt 版本控制 + 多层 Service Catalog 实现跨账户、跨团队的基础设施即代码部署
- 结论/价值：Service（业务需求封装）优于 Module（技术实现）的抽象层级越高，可用性越强；推荐使用专用 Service Catalog 而非相对路径，以实现独立发布周期和更好的可维护性
Key Claims（用中文描述）
- 产品团队通过 Landing Zone 分组：每个产品团队拥有独立的 Landing Zone 和工作负载账号（如 DevTools 团队部署 Artifactory 和 Active Directory）
- 三层 Git 仓库架构：核心 Landing Zone 仓库 + Terraform Service Catalog + 产品团队 Service Catalog，三者分离实现独立生命周期
- Service 模块 = 业务封装：Service 模块由 main.tf 组成，引用多个 Module 以满足单一业务需求（如 AD 服务或 DNS 服务）
- Terragrunt HCL 优先使用依赖而非读取状态文件：通过 dependencies 声明跨服务引用，支持版本锁定而非直接引用 master 分支
- Service 优于 Module 的抽象层级：Service 是业务需求视角，Module 是技术实现视角；层级越高，配置选项越少（类似面向对象抽象）
- Terragrunt 缓存机制：运行前预取所有引用，使用 Terragrunt 缓存目录存储克隆的仓库
- Apply 前必须验证：不经验证直接 apply 是不推荐的做法
Key Quotes
"A service is a business requirement, while a regular module is a technical requirement." — 区分 Service 与 Module 的本质定义
"When deploying infrastructure, Terragrunt HCL files are used to reference these services, targeting specific versions rather than the master branch." — 版本控制优于直接引用 master
"Modules can be used within one account, reused within a product team (in the product team service catalog), or used across product teams (in the Terraform service catalog)." — 模块三层复用模型
Key Concepts
- Infrastructure-as-Code：通过代码定义和管理基础设施，Terraform/Terragrunt 为核心工具
- Terraform：基础设施即代码工具，HCL 配置文件定义云资源
- Terragrunt：Terraform 包装器，支持 DRY 配置、依赖管理和版本控制
- Service-Catalog：服务目录，分 Terraform Service Catalog（跨产品团队）和产品团队 Service Catalog 两层
- Module：Terraform 模块，技术层面的可复用组件
- Service：业务服务视角的封装，抽象多个 Module 满足单一业务需求
- Landing-Zone：AWS Landing Zone，多账号基础设施框架
Key Entities
- Terraform：IaC 工具，HCL 配置文件定义云资源
- Terragrunt：Terraform 包装器，实现 DRY 配置和依赖管理
- Gruntwork：参考架构和服务目录提供商
- Jenkins：CI/CD 工具，可与 Terraform/Terragrunt 集成
- DevTools：示例产品团队，部署 Artifactory 和 Active Directory
Connections
- ctp-topic-1-gruntwork-landing-zone-architecture ← foundational ← ctp-topic-3-deploy-and-maintain-infrastructure
- ctp-topic-3-deploy-and-maintain-infrastructure ← extends ← Terraform（核心 IaC 工具）
- ctp-topic-3-deploy-and-maintain-infrastructure ← extends ← Terragrunt（版本控制和依赖管理）
- ctp-topic-3-deploy-and-maintain-infrastructure ← extends ← Service-Catalog（模块复用架构）
- ctp-topic-3-deploy-and-maintain-infrastructure ← related ← ctp-topic-48-terraform-vs-terragrunt（Terragrunt 详细对比）
- ctp-topic-3-deploy-and-maintain-infrastructure ← related ← ctp-topic-56-automated-infrastructure-testing（自动化测试）
- ctp-topic-3-deploy-and-maintain-infrastructure ← related ← ctp-topic-16-cross-account-terraform-modules（跨账户模块）
- ctp-topic-3-deploy-and-maintain-infrastructure ← related ← ctp-topic-33-an-introduction-to-gitops（GitOps 上下文）
- ctp-topic-3-deploy-and-maintain-infrastructure ← related ← ctp-topic-9-ci-cd-with-gruntwork（Gruntwork CI/CD 集成）
Contradictions
-
与 ctp-topic-1-gruntwork-landing-zone-architecture：
- 冲突点：Topic 1 强调 Gruntwork Reference Architecture 提供最佳实践起点；Topic 3 强调产品团队自主定义具体服务
- 当前观点：Topic 3 认为产品团队在 LZ 框架内自主管理 Service Catalog
- 对方观点：Topic 1 认为 Gruntwork Reference Architecture 是标准化起点，产品团队基于此定制
- 说明：两者实际互补——Topic 1 提供架构框架，Topic 3 描述具体部署机制
-
与 ctp-topic-48-terraform-vs-terragrunt：
- 冲突点：Topic 3 明确推荐 Terragrunt HCL 引用版本（而非 master）；Topic 48 可能涉及 Terragrunt 选型讨论
- 当前观点：Terragrunt 版本锁定是最佳实践
- 对方观点：（待交叉验证）
- 说明：属深度递进关系，Topic 48 补充 Terragrunt vs Terraform 的详细对比