Auto-sync: update nexus workspace
This commit is contained in:
@@ -1,62 +1,78 @@
|
||||
---
|
||||
title: "CTP Topic 3 Deploy and maintain infrastructure"
|
||||
title: "CTP Topic 3 Deploy and Maintain Infrastructure"
|
||||
type: source
|
||||
tags:
|
||||
- IaC
|
||||
- Deployment
|
||||
- CI/CD
|
||||
- CTP
|
||||
- Terraform
|
||||
- Terragrunt
|
||||
- Landing-Zone
|
||||
- CTP
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/06_CI_CD_GitOps/ctp-topic-3-deploy-and-maintain-infrastructure.md]]
|
||||
- [[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 而非相对路径引用
|
||||
- 核心主题：AWS Landing Zone 环境下的基础设施部署与维护机制
|
||||
- 问题域：产品团队如何在 Landing Zone 多账号架构中高效、一致、可复用地部署基础设施
|
||||
- 方法/机制：通过 Terraform 模块化 + Terragrunt 版本控制 + 多层 Service Catalog 实现跨账户、跨团队的基础设施即代码部署
|
||||
- 结论/价值：Service（业务需求封装）优于 Module（技术实现）的抽象层级越高，可用性越强；推荐使用专用 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 在运行前预取所有引用，通过缓存目录存储克隆的仓库
|
||||
- **产品团队通过 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 解决技术问题
|
||||
> "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." — 版本控制优于分支引用
|
||||
> "When deploying infrastructure, Terragrunt HCL files are used to reference these services, targeting specific versions rather than the master branch." — 版本控制优于直接引用 master
|
||||
|
||||
> "The higher up the chain, the less configuration options are available, similar to an object-oriented approach." — 抽象层次与配置灵活性的反向关系
|
||||
> "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
|
||||
- [[Landing Zone（落地区）]]：云环境的基础账户结构和资源隔离框架，产品团队在此之上部署工作负载
|
||||
- [[Service Module（服务模块）]]：满足业务需求的一组 Terraform 模块组合，相较于技术模块提供更高级抽象
|
||||
- [[Service Catalog（服务目录）]]：可复用模块的集中管理库，支持三级复用（账户/产品团队/跨团队）
|
||||
- [[Terragrunt]]：Terraform 的薄包装层，支持依赖管理、缓存和版本锁定
|
||||
- [[Terraform Module]]：Terraform 的可复用配置单元，版本化管理
|
||||
- [[Infrastructure as Code（IaC）]]：通过代码管理和配置基础设施的实践
|
||||
- [[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
|
||||
- [[AWS Landing Zone]]：AWS 多账户环境框架，是本文档讨论的基础部署上下文
|
||||
- [[Gruntwork]]：提供 Terraform 模块参考架构的公司，本文多次引用其作为最佳实践模型
|
||||
- [[Product Team]]：在 Landing Zone 中部署工作负载的业务团队，拥有独立的账户集合
|
||||
- [[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-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]]
|
||||
- [[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-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 提供通用原则，两者约束条件不同不构成直接矛盾
|
||||
- 与 [[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 的详细对比
|
||||
|
||||
Reference in New Issue
Block a user