Sync: add ses and networking notes

wiki/sources/ctp-topic-12-using-ses-smtp-service-terraform-module.md

@@ -0,0 +1,59 @@
+---
+title: "CTP Topic 12 Using SES SMTP service terraform module"
+type: source
+tags:
+  - AWS
+  - Terraform
+  - SES
+  - Email
+  - CTP
+  - Cloud-Email
+date: 2026-04-14
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/03_Terraform/ctp-topic-12-using-ses-smtp-service-terraform-module]]
+
+## Summary（用中文描述）
+- 核心主题：Micro Focus 团队使用 Terraform 模块自动化部署 AWS SES SMTP 服务，以替代传统的本地 SMTP 网关。
+- 问题域：随着业务向云端迁移，使用本地 SMTP 网关（如 smtbmicrofocus.com）已不再高效，网络安全部门要求统一使用云端邮件发送方案。
+- 方法/机制：在应用 VPC 中配置 VPC 终端节点以实现私有连接；通过 IAM 用户凭证作为 SMTP 认证信息并存储于 Secrets Manager；Terraform 模块自动化 SMTP 终端节点配置、DKIM 验证和 DNS 记录创建；支持现有应用程序通过标准 SMTP 协议集成，无需重构代码适配 SES API。
+- 结论/价值：SES 是唯一获网络安全部门批准的云端邮件发送方案；Terraform 模块化封装降低了集成复杂度；需注意两个手动步骤（申请脱离 Sandbox Mode 和手动更新 DNS TXT 记录）。
+
+## Key Claims（用中文描述）
+- 在应用 VPC 中配置 VPC 终端节点，使应用可在不访问公网的情况下通过私有节点与 SES SMTP 服务通信。
+- IAM 用户的 Access Key 和 Secret Key 被转换后作为 SMTP 认证的用户名和密码，相关凭证安全存储于 AWS Secrets Manager。
+- Terraform 模块自动化完成 DKIM 验证和 Infoblox DNS 管理系统中域名所有权记录的创建。
+- 手动更新 DNS TXT 记录以验证域名所有权仍是必需步骤，因 Terraform 难以处理多个 AWS 账号共享同一域名时对同一 TXT 记录值的追加操作。
+- 脱离 SES Sandbox Mode（向 AWS 提交工单申请生产访问权限）是启用完整邮件发送能力的必要前提。
+- SES 是 Micro Focus 网络安全部门唯一批准的云端邮件发送方案，替代了原有的本地 SMTP 网关。
+
+## Key Quotes
+> "随着业务向云端迁移，使用本地 SMTP 网关（如 smtbmicrofocus.com）已不再高效，SES 是目前网络安全部门唯一批准的云端邮件发送方案。" — Christian Deckelmann
+
+> "SES Terraform 模块封装了 SMTP 终端节点的配置，方便现有应用程序通过标准的 SMTP 协议进行集成，而无需重构代码以适配 SES API。" — Filos Christolakis
+
+## Key Concepts
+- [[VPC-Endpoint]]：AWS 提供的私有连接服务，允许在 VPC 内部通过私有 IP 地址安全访问 AWS 服务，无需经过公网。
+- [[DKIM-Email-Authentication]]：DomainKeys Identified Mail 的缩写，一种电子邮件验证标准，通过在邮件头部添加数字签名来防止欺诈和确保邮件完整性。
+- [[Secrets-Manager]]：AWS 提供的凭证管理服务，用于安全地存储和检索 SES SMTP 的认证信息。
+- [[SES-Sandbox-Mode]]：AWS SES 的默认限制状态，仅允许向已验证的地址发送少量邮件，需提交工单申请生产访问权限以提升发送限额。
+
+## Key Entities
+- [[AWS]]：Amazon Web Services，云服务提供商，SES（Simple Email Service）所属平台。
+- [[Christian-Deckelmann]]：演讲者之一，分享 Micro Focus 在云转型中采用 SES SMTP 服务的背景与动机。
+- [[Filos-Christolakis]]：演讲者之一，详细讲解 SES Terraform 模块的技术实现方案。
+- [[Infoblox]]：公司内部使用的 DNS 管理系统，用于存放和管理验证域名所有权所需的 DNS 记录。
+- [[VPC-Wrapper-Module]]：SES Terraform 模块所依赖的前置 VPC 配置模块，负责预先配置 SMTP VPC 终端节点。
+
+## Connections
+- [[VPC-Wrapper-Module]] ← depends_on ← [[ctp-topic-12-using-ses-smtp-service-terraform-module]]
+- [[ctp-topic-12-using-ses-smtp-service-terraform-module]] ← extends ← [[AWS]]
+- [[Terraform-And-Terragrunt-Best-Practices]] ← related_to ← [[ctp-topic-12-using-ses-smtp-service-terraform-module]]（Terragrunt Pre-hook/Post-hook 用于处理手动 DNS 验证步骤）
+- [[ctp-topic-36-sendgrid-as-an-email-service]] ← alternative_to ← [[ctp-topic-12-using-ses-smtp-service-terraform-module]]（SendGrid 被选定为新 Landing Zone 标准，SES 用于现有应用迁移）
+
+## Contradictions
+- 与 [[ctp-topic-36-sendgrid-as-an-email-service]] 在邮件服务选型上的差异：
+  - 冲突点：两门课程分别介绍了不同的云邮件服务方案——SendGrid 被选定为标准云端邮件服务，而 SES 则专注于服务现有应用通过 SMTP 协议迁移上云。
+  - 当前观点：SES 通过 Terraform 模块封装现有应用 SMTP 接入路径，实现平滑迁移，无需修改应用代码。
+  - 对方观点：SendGrid 作为新标准云邮件服务，提供更高上限（每封 1,000 收件人 vs SES 每封 50 收件人）、更简单的 API 集成和全球中继节点。

wiki/sources/learning-sessions-cloud-transformation-programme-20230808-183322-meeting-recordi.md

@@ -0,0 +1,55 @@
+---
+title: "Learning Sessions Cloud Transformation Programme-20230808 183322-Meeting Recording"
+type: source
+tags:
+  - Terraform
+  - CTP
+  - IaC
+date: 2023-08-08
+---
+
+## Source File
+- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/03_Terraform/learning-sessions-cloud-transformation-programme-20230808-183322-meeting-recordi]]
+
+## Summary（用中文描述）
+- 核心主题：通过 Terraform IaC 实现 ECS 容器化应用的自动化部署
+- 问题域：企业在不可预测性和敏捷性需求下的基础设施挑战
+- 方法/机制：基于 Gruntwork 仓库构建 ECS Terraform 模块，支持 Docker 容器/EC2 部署，具备自动扩缩容、自动故障恢复、金丝雀部署能力；采用 Listener 集中管理方式
+- 结论/价值：CTP/SRE 团队通过 IaC 实现 ECS 部署标准化，与 AWS 服务深度集成
+
+## Key Claims（用中文描述）
+- 企业必须在不可预测性和敏捷性需求之间找到平衡，基础设施即代码（IaC）是应对这一挑战的关键手段
+- ECS（Elastic Container Service）是 AWS 原生技术，与 AWS 服务深度集成，相比 EKS 或原生 Kubernetes 有其独特优势与挑战
+- CTP/SRE 团队基于 Gruntwork 仓库构建了可复用的 ECS Terraform 模块，支持 Docker 容器作为逻辑单元
+- ECS 模块支持 EC2 实例或目标部署，具备自动扩缩容、自动故障恢复、金丝雀部署功能
+- Listener 集中管理方式避免了各产品直接下载 Gruntwork 模板并本地使用的碎片化问题
+- ECS 部署的前置条件包括 VPC、ELB 安全组和 EFS 卷挂载
+- 模块支持通过 YAML 或 JSON 传递配置，集成 CloudWatch、Splunk、Grafana 和 Prometheus
+
+## Key Quotes
+> "Businesses have to thrive in the middle of all these challenges and it is forged by code." — JP，阐述企业面临的不可预测性挑战与 IaC 的核心价值
+> "We have implemented the listener approach because we have seen many of the products are downloading the quotes from the Gruntwork and using locally." — Raja M，说明 Listener 集中管理模式的动机
+
+## Key Concepts
+- [[Infrastructure-as-Code]]：通过代码定义和管理基础设施，实现自动化、可重复、可审计的部署流程
+- [[Canary-Deployment]]：金丝雀部署，通过逐步将流量切换到新版本，降低新版本上线的风险
+- [[ECS-Module]]：CTP/SRE 团队基于 Gruntwork 仓库构建的 ECS Terraform 模块
+
+## Key Entities
+- [[JP]]：主讲人之一，介绍 ECS 的业务和技术背景
+- [[Raja-M]]：CTP/SRE 团队成员，详细讲解 ECS 模块的构建方式
+- [[Gruntwork]]：提供 Terraform 模块的基础仓库，CTP 在其基础上构建了 ECS 模块
+- [[AWS]]：云服务提供商，ECS 为 AWS 弹性容器服务
+- [[Cloud-Transformation-Programme]]：云转型计划，组织发起的基础设施现代化计划
+
+## Connections
+- [[learning-sessions-ecs-deployment-using-iac-20230808-183322-meeting-recording]] ← same_topic ← [[learning-sessions-ecs-deployment-using-iac-20230808-183322-meeting-recording]]
+- [[Infrastructure-as-Code]] ← implements ← [[Cloud-Transformation-Programme]]
+- [[ECS-Module]] ← based_on ← [[Gruntwork]]
+
+## Contradictions
+- 与 [[ctp-topic-64-scaling-out-with-amazon-eks]] 在容器编排选型上存在差异：
+  - 冲突点：ECS 强调 AWS 原生集成，EKS 强调可移植性
+  - 当前观点：ECS 与 AWS 服务深度集成，适合追求 AWS 原生体验的场景
+  - 对方观点：EKS 基于原生 Kubernetes，提供更好的跨云可移植性
+  - 结论：两者适用于不同场景，可根据业务需求互补使用

wiki/sources/learning-sessions-cloud-transformation-programme-deploying-rds-via-terraform.md

@@ -0,0 +1,57 @@
+---
+title: "Learning Sessions Cloud Transformation Programme-Deploying RDS via Terraform"
+type: source
+tags: [Terraform, RDS, IaC, CTP, DevOps, DBRE, AWS]
+date: 2026-04-14
+---
+
+## Source File
+- [[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 告警等）；代码即文档
+
+## 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 消耗
+
+## 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 的文档价值
+
+## 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 密钥加密功能
+
+## 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
+
+## 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]]
+
+## 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 载体不同，适用于不同规模和架构场景，无直接冲突