Sync: expand data model and gitops notes

wiki/sources/ctp-topic-3-deploy-and-maintain-infrastructure.md

@@ -0,0 +1,62 @@
+---
+title: "CTP Topic 3 Deploy and maintain infrastructure"
+type: source
+tags:
+  - IaC
+  - Deployment
+  - CI/CD
+  - CTP
+  - Terraform
+  - Terragrunt
+date: 2026-04-14
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/06_CI_CD_GitOps/ctp-topic-3-deploy-and-maintain-infrastructure.md]]
+
+## Summary（用中文描述）
+- 核心主题：AWS Landing Zone 环境下通过 Terraform/Terragrunt 实现基础设施部署与维护的完整方法论
+- 问题域：多账户、多产品团队环境下 IaC 模块化复用、服务目录治理、Terragrunt 依赖管理
+- 方法/机制：Service Module（业务视角）vs Regular Module（技术视角）的分层抽象；Terragrunt HCL 引用特定版本模块；Service Catalog 三级复用（单账户→产品团队→跨团队）；Terragrunt 缓存目录预取依赖
+- 结论/价值：模块化 IaC 实现独立发布周期和可维护性；Service 层抽象减少配置复杂度，越高层抽象选项越少（类 OO 继承）；推荐使用专用 Service Catalog 而非相对路径引用
+
+## Key Claims（用中文描述）
+- Product Team 在 Landing Zone 中部署基础设施时，跨越多个账户（如 Artifactory 账户、AD 账户），涉及多个 Git 仓库协同
+- Service Module 由 main.tf 文件引用其他仓库模块组合而成，满足特定业务需求（如 AD 服务、DNS 服务）
+- Service 抽象层次高于 Regular Module，提供更少配置选项但更易使用
+- Terragrunt 优于直接引用 master 分支，target 特定版本确保环境一致性
+- 复用层次：单账户使用 → 产品团队 Service Catalog → Terraform Service Catalog（跨团队）
+- Terragrunt 在运行前预取所有引用，通过缓存目录存储克隆的仓库
+
+## 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." — 版本控制优于分支引用
+
+> "The higher up the chain, the less configuration options are available, similar to an object-oriented approach." — 抽象层次与配置灵活性的反向关系
+
+## Key Concepts
+- [[Landing Zone（落地区）]]：云环境的基础账户结构和资源隔离框架，产品团队在此之上部署工作负载
+- [[Service Module（服务模块）]]：满足业务需求的一组 Terraform 模块组合，相较于技术模块提供更高级抽象
+- [[Service Catalog（服务目录）]]：可复用模块的集中管理库，支持三级复用（账户/产品团队/跨团队）
+- [[Terragrunt]]：Terraform 的薄包装层，支持依赖管理、缓存和版本锁定
+- [[Terraform Module]]：Terraform 的可复用配置单元，版本化管理
+- [[Infrastructure as Code（IaC）]]：通过代码管理和配置基础设施的实践
+
+## Key Entities
+- [[AWS Landing Zone]]：AWS 多账户环境框架，是本文档讨论的基础部署上下文
+- [[Gruntwork]]：提供 Terraform 模块参考架构的公司，本文多次引用其作为最佳实践模型
+- [[Product Team]]：在 Landing Zone 中部署工作负载的业务团队，拥有独立的账户集合
+
+## Connections
+- [[ctp-topic-1-gruntwork-landing-zone-architecture]] ← foundational ← [[ctp-topic-3-deploy-and-maintain-infrastructure]]
+- [[ctp-topic-9-ci-cd-with-gruntwork]] ← related ← [[ctp-topic-3-deploy-and-maintain-infrastructure]]
+- [[ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments]] ← related ← [[ctp-topic-3-deploy-and-maintain-infrastructure]]
+- [[ctp-topic-33-an-introduction-to-gitops]] ← extends ← [[ctp-topic-3-deploy-and-maintain-infrastructure]]
+
+## Contradictions
+- 与 [[ctp-topic-39-implementing-eks-in-the-aws-lab-landing-zone]] 的 Atlantis 部分存在约束差异：
+  - 冲突点：Atlantis 对 EKS 部署的支持能力
+  - 当前观点（Topic 3）：Terragrunt 可用于所有基础设施部署，包括 EKS
+  - 对方观点（Topic 39）：Atlantis 当前不支持 EKS 部署，需通过 Jenkins + Terragrunt 模块替代
+  - 评估：Topic 39 提供更具体的实践经验，Topic 3 提供通用原则，两者约束条件不同不构成直接矛盾