Update nexus wiki content
This commit is contained in:
@@ -1,57 +1,61 @@
|
||||
---
|
||||
title: "Learning Sessions Cloud Transformation Programme-Deploying RDS via Terraform"
|
||||
type: source
|
||||
tags: [Terraform, RDS, IaC, CTP, DevOps, DBRE, AWS]
|
||||
tags:
|
||||
- Terraform
|
||||
- RDS
|
||||
- IaC
|
||||
- Cloud-Transformation-Programme
|
||||
- DBRE
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/03_Terraform/learning-sessions-cloud-transformation-programme-deploying-rds-via-terraform.md]]
|
||||
- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/03_Terraform/learning-sessions-cloud-transformation-programme-deploying-rds-via-terraform]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：**通过 Terraform 在 AWS 上部署 RDS 数据库**，涵盖 IaC 最佳实践和 Gruntwork RDS 模块的选型对比
|
||||
- 问题域：RDS 部署方式的选择（控制台 vs 代码）、模块选型（grunt work 模块 vs SRE 核心模块）、Day 2 运维（扩缩容/补丁/升级）
|
||||
- 方法/机制：使用 Terragrunt（Terraform 封装器）管理 RDS 部署，通过 GitHub PR + Atlantis 实现变更自动化；CloudWatch 负责监控告警
|
||||
- 结论/价值：IaC 部署任何规模的 RDS 到 AWS 均优于控制台；grunt work RDS Service 相比裸模块提供更完整的企业级功能（KMS 加密、CloudWatch 告警等）；代码即文档
|
||||
- 核心主题：通过 Terraform 在 AWS 上自动化部署 RDS 数据库，DBRE 团队的 Greg 主讲
|
||||
- 问题域：IaC 部署 RDS 的模块选型、Day 2 运维操作、监控告警配置
|
||||
- 方法/机制：推荐使用 Gruntwork 的 RDS Service 模块（含 KMS 加密、CloudWatch 告警），配合 Terragrunt 管理多环境配置；Day 2 操作通过 GitHub PR + Atlantis 审批后自动 apply
|
||||
- 结论/价值：任何规模的 RDS 部署都应使用 Terraform 而非 Console，IaC 的核心价值在于"代码即文档"
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- **IaC 六大大好处**：速度、灵活性、一致性、灾难恢复、文档、自动化。代码即文档
|
||||
- **两种 RDS 部署选项**：裸模块 RDS module（基础功能）vs 更完整的 grunt work RDS Service（推荐，预建 KMS 加密和 CloudWatch 告警）
|
||||
- **SRE 核心模块功能弱于 grunt work 服务**：建议生产环境使用 grunt work RDS Service
|
||||
- **Terragrunt 优于裸 Terraform**：避免变量重复声明，保持代码整洁，贯彻 DRY 原则
|
||||
- **Day 2 运维通过 GitHub PR + Atlantis 实现**：扩缩容、补丁、大版本升级均在 Terragrunt 文件中修改，通过 PR 触发 Atlantis 自动应用
|
||||
- **监控方案**：CloudWatch Dashboard + Alarms，注意突发性能实例（burstable instance）的 CPU credits 消耗
|
||||
- **Greg（DBRE 团队）× IaC 选型**：提倡所有规模的 RDS 部署都使用 Terraform，Console 方式不可取
|
||||
- **IaC 六大核心价值**：速度、灵活性、一致性、灾难恢复、文档化、自动化；"代码即文档"是最核心的文档化原则
|
||||
- **RDS 模块二选一**：grunt work RDS Service（推荐，功能完整）vs SRE Core Modules（功能较少）；grunt work 预置 KMS 加密 + CloudWatch 告警，SRE 模块无此能力
|
||||
- **Terragrunt 实践**：使用 tagged release（不用 master）确保稳定性，避免变量重复声明，代码保持 DRY
|
||||
- **Day 2 运维流程**：变更在 Terragrunt 文件中完成 → GitHub Pull Request → Atlantis 审批 → 自动 apply；支持扩缩容、打补丁、主版本升级
|
||||
- **监控策略**：CloudWatch Dashboard + 告警；burstable 实例需关注 CPU credits
|
||||
|
||||
## Key Quotes
|
||||
> "We use Terragrunt, which is basically it's a wrapper around Terraform, and it allows you to keep your code clean and you're not repeating your variables all the time." — Greg, DBRE Team
|
||||
> "The code is the documentation." — Greg, 强调 IaC 的文档价值
|
||||
|
||||
> "The code is the documentation." — Greg, DBRE Team（IaC 核心哲学）
|
||||
|
||||
## Key Concepts
|
||||
- [[Infrastructure-as-Code]]：通过代码定义和版本控制基础设施资源，核心优势包括速度、一致性、灾难恢复和自动化
|
||||
- [[DRY Principle]]：Terragrunt 通过管理 provider 和 remote_state 块减少跨环境重复声明
|
||||
- [[GitOps]]：通过 GitHub PR + Atlantis 实现基础设施变更的自动化审核和应用
|
||||
- [[CloudWatch-Alarms]]：RDS 监控与告警机制，包含突发性能实例的 CPU credits 考虑
|
||||
- [[KMS-Encryption]]：grunt work RDS Service 内置的 KMS 密钥加密功能
|
||||
- [[Infrastructure-as-Code]]：IaC 是本次分享的主题，Terraform 是核心工具，覆盖速度/灵活性/一致性/灾难恢复/文档化/自动化六大价值
|
||||
- [[InfrastructureAsCode]]：页面已有，本次来源提供 IaC 选型 RDS 的具体实践补充
|
||||
- [[DRY-Principle]]：Terragrunt 践行 DRY 原则，避免变量在多环境间重复声明
|
||||
- [[Terraform-State]]：Terraform 通过状态文件将期望状态绑定到实际环境（本来源提及但未展开）
|
||||
|
||||
## Key Entities
|
||||
- [[Gruntwork]]：提供预建 Terraform 模块（RDS Service 等），建议生产环境使用其 grunt work RDS Service 而非裸模块
|
||||
- [[Atlantis]]：Git 驱动的 Terraform 自动化工具，配合 GitHub PR 实现 IaC 变更
|
||||
- [[Terraform]]：云厂商无关的 IaC 核心工具
|
||||
- [[Terragrunt]]：Terraform 的 DRY 封装层，用于管理 RDS 部署配置
|
||||
- [[DBRE]]：Database Reliability Engineering 团队，Greg 来自该团队
|
||||
- [[CloudWatch]]：AWS 监控服务，用于 RDS Dashboard 和 Alarms
|
||||
- [[Greg]]：DBRE 团队成员，本次 Learning Session 的讲师，主讲 Terraform 部署 RDS
|
||||
- [[Amazon-RDS]]：本次分享的核心资源，Greg 主张所有规模都用 Terraform 部署
|
||||
- [[Gruntwork]]：提供 RDS Service 模块和 SRE Core Modules，是本次分享的模块选型依据
|
||||
- [[Terragrunt]]：推荐的 Terraform 封装工具，使用 tagged release 管理多环境
|
||||
- [[AWS]]：RDS 所在的云平台，监控使用 CloudWatch
|
||||
- [[Atlantis]]：GitOps 工具，配合 GitHub PR 实现 RDS 变更的自动化审批和 apply
|
||||
|
||||
## Connections
|
||||
- [[learning-sessions-cloud-transformation-programme-20230808-183322-meeting-recordi]] ← related ← [[learning-sessions-cloud-transformation-programme-deploying-rds-via-terraform]]（同一 CTP 系列，ECS 部署 + RDS 部署）
|
||||
- [[ctp-topic-48-terraform-vs-terragrunt]] ← related ← [[learning-sessions-cloud-transformation-programme-deploying-rds-via-terraform]]（Terragrunt 在两个主题中均有讨论）
|
||||
- [[ctp-topic-16-cross-account-terraform-modules]] ← related ← [[learning-sessions-cloud-transformation-programme-deploying-rds-via-terraform]]（IaC 模块化 + Cross-account Terraform）
|
||||
- [[ctp-topic-9-ci-cd-with-gruntwork]] ← foundation ← [[learning-sessions-cloud-transformation-programme-deploying-rds-via-terraform]]（Gruntwork CI/CD 基础）
|
||||
- [[Terraform]] ← wraps ← [[Terragrunt]]
|
||||
- [[Gruntwork]] ← provides ← [[RDS-Module]]（grunt work RDS Service）
|
||||
- [[Atlantis]] ← automates ← [[Terraform]]
|
||||
- [[CloudWatch]] ← monitors ← [[RDS-Module]]
|
||||
- [[ctp-topic-48-terraform-vs-terragrunt]] ← related_to ← [[learning-sessions-cloud-transformation-programme-deploying-rds-via-terraform]]（两者均讨论 Terragrunt 选型，本来源侧重 RDS 场景下的实践）
|
||||
- [[ctp-topic-3-deploy-and-maintain-infrastructure]] ← depends_on ← [[learning-sessions-cloud-transformation-programme-deploying-rds-via-terraform]]（基础设施部署与维护是本来源的上下文）
|
||||
- [[ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments]] ← extends ← [[learning-sessions-cloud-transformation-programme-deploying-rds-via-terraform]]（Day 2 运维中 GitHub PR + Atlantis 自动 apply 与该来源的 Atlantis 配置细节互补）
|
||||
- [[ctp-topic-9-ci-cd-with-gruntwork]] ← related_to ← [[learning-sessions-cloud-transformation-programme-deploying-rds-via-terraform]]（两者均涉及 Gruntwork 模块体系）
|
||||
- [[learning-sessions-cloud-transformation-programme-20230808-183322-meeting-recordi]] ← extends ← [[learning-sessions-cloud-transformation-programme-deploying-rds-via-terraform]]（ECS 部署和 RDS 部署共同构成 CTP 的 IaC 全景）
|
||||
|
||||
## Contradictions
|
||||
- 与 [[ctp-topic-9-ci-cd-with-gruntwork]]（Gruntwork CI/CD）：两者均依赖 Gruntwork 模块体系；本主题聚焦 RDS 部署，CI/CD 主题聚焦 ECS 应用部署；RDS 部署同样适用 Gruntwork 流水线规范，两者互补而非冲突
|
||||
- 与 [[ctp-topic-48-terraform-vs-terragrunt]]（Terraform vs Terragrunt）：本主题的实际案例印证了该主题的观点——Terragrunt 保持代码整洁、避免变量重复；两主题一致，共同推荐 Terragrunt 作为 Terraform 的封装层
|
||||
- 与 [[ctp-topic-16-cross-account-terraform-modules]]（跨账号 Terraform 模块）：两者均讨论 Terraform 模块的运维方式；跨账号模块方案（Jenkins + ECS Deploy Runner）与本主题（RDS 通过 Atlantis）的 CI/CD 载体不同，适用于不同规模和架构场景，无直接冲突
|
||||
- 与 [[ctp-topic-48-terraform-vs-terragrunt]] 的潜在冲突：
|
||||
- 冲突点：Terraform vs Terragrunt 的定位
|
||||
- 当前观点（来源）：Terragrunt 是 RDS 部署的首选工具，"keep your code clean, not repeating variables"
|
||||
- 对方观点：CTP Topic 48 对 Terraform 和 Terragrunt 的适用场景做了更细致的对比，指出 Terragrunt 是"轻量封装"而非必须选择
|
||||
- 实际情况：两者不矛盾，本来源是 Terragrunt 的正面用例，Topic 48 提供的是通用对比框架
|
||||
|
||||
Reference in New Issue
Block a user