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

4.2 KiB
Raw Blame History

title, type, tags, date
title type tags date
CTP Topic 3 Deploy and maintain infrastructure source
IaC
Deployment
CI/CD
CTP
Terraform
Terragrunt
2026-04-14

Source File

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

Key Entities

  • AWS Landing ZoneAWS 多账户环境框架,是本文档讨论的基础部署上下文
  • Gruntwork:提供 Terraform 模块参考架构的公司,本文多次引用其作为最佳实践模型
  • Product Team:在 Landing Zone 中部署工作负载的业务团队,拥有独立的账户集合

Connections

Contradictions

  • ctp-topic-39-implementing-eks-in-the-aws-lab-landing-zone 的 Atlantis 部分存在约束差异:
    • 冲突点Atlantis 对 EKS 部署的支持能力
    • 当前观点Topic 3Terragrunt 可用于所有基础设施部署,包括 EKS
    • 对方观点Topic 39Atlantis 当前不支持 EKS 部署,需通过 Jenkins + Terragrunt 模块替代
    • 评估Topic 39 提供更具体的实践经验Topic 3 提供通用原则,两者约束条件不同不构成直接矛盾