Sync: add infrastructure as code notes
This commit is contained in:
@@ -53,7 +53,13 @@ Cloud Transformation Programme (CTP) materials cover AWS landing zones, EKS, Ter
|
||||
|
||||
**[[ctp-topic-15-working-with-renovatebot]]**(CTP Topic 15):Paul Hopkins 主讲 Renovate Bot 自动化依赖项更新——解决"依赖地狱"问题,实时扫描 Docker 镜像/Terraform 模块/Terragrunt 配置/pre-commit 钩子等版本标签,自动发起 Pull Request;通过 Dependency Dashboard 提供全局依赖状态视图;集成 Jenkins 流水线,使用 Podman 容器化运行并配置 Rate Limiting 避免 PR 风暴;提升基础设施安全性(及时修复漏洞)和配置一致性。属 [[GitOps]] 和 [[CI/CD Pipeline]] 的依赖治理层,与 [[ctp-topic-9-ci-cd-with-gruntwork]](Gruntwork CI/CD)和 [[ctp-topic-33-an-introduction-to-gitops]](GitOps 入门)共同构成完整的 IaC 知识链路。
|
||||
|
||||
**[[ctp-topic-56-automated-infrastructure-testing]]**(CTP Topic 56):Mark Francis 主讲自动化基础设施测试——将软件测试原则应用于 Terraform IaC 代码,通过 TerraTest(Golang 框架)实现 apply → test → destroy 自动化验证循环。核心主张:集成测试超越语法检查,验证实际部署行为是否符合预期;倡导测试驱动开发(TDD)应用于 IaC 领域,先写测试再实现功能;提议将测试编写作为基础设施开发的首要步骤,移除手动验证,追求自动化验证套件和更高的部署信心。核心价值观:"让机器做重复的事,把人脑留给复杂的人类问题"。属 [[GitOps]] 和 [[CI/CD Pipeline]] 的质量保障层,与 [[ctp-topic-33-an-introduction-to-gitops]](GitOps 概念)和 [[ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments]](Atlantis 工具)共同构成完整的 IaC 质量保障链路。
|
||||
**[[ctp-topic-56-automated-infrastructure-testing]]**(CTP Topic 56):Mark Francis 主讲自动化基础设施测试——将软件测试原则应用于 Terraform IaC 代码,通过 TerraTest(Golang 框架)实现 apply → test → destroy 自动化验证循环。核心主张:集成测试超越语法检查,验证实际部署行为是否符合预期;倡导测试驱动开发(TDD)应用于 IaC 领域,先写测试再实现功能;提议将测试编写作为基础设施开发的首要步骤,移除手动验证,追求自动化验证套件和更高的部署信心。核心价值观:"让机器做重复的事,把人脑留给复杂的人类问题"。属 [[GitOps]] 和 [[CI/CD Pipeline]] 的质量保障层,与 [[ctp-topic-33-an-introduction-to-gitops]](GitOps 概念)和 [[ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments]](Atlantis 工具)共同构成 IaC 知识体系。
|
||||
|
||||
**[[ctp-topic-48-terraform-vs-terragrunt]]**(CTP Topic 48):Bob(AWS Solutions Architect)对比 Terraform 与 Terragrunt——Terraform(HashiCorp 出品)是云厂商无关的 Golang 应用,通过状态文件将期望状态与实际环境绑定,企业级使用须将状态文件存储在安全可访问位置;Terragrunt 是 Terraform 的轻量封装,贯彻 DRY 原则,通过管理 provider 和 remote_state 块减少跨环境的重复声明。两者命令和语法高度一致(`terraform plan` = `terragrunt plan`),Terragrunt 通过减少硬编码来优化大规模企业部署。辅助工具:Terraform Enterprise(CI 平台 + workspaces)、Gruntwork(预建可定制模块)、Atlantis(Git 集成)、tfsec(静态安全分析)、Terratest(IaC 测试自动化)。属 [[Infrastructure As Code]] 工具选型层,与 [[ctp-topic-3-deploy-and-maintain-infrastructure]](Terragrunt HCL)和 [[ctp-topic-56-automated-infrastructure-testing]](Terratest)共同构成 Terraform 生态知识链路。
|
||||
|
||||
**(本条新增)Learning Sessions ECS Deployment using IAC**(2023-08-08):JP 和 Raja M 主讲,CTP/SRE 团队通过 Terraform IaC 实现 ECS 容器化应用自动化部署——基于 Gruntwork 仓库构建的 ECS 模块,将 Docker 容器作为逻辑单元,支持 EC2 实例部署;核心功能:自动扩缩容、自动故障恢复、金丝雀部署;通过 Listener 方式集中管理(避免各产品团队重复下载 Gruntwork 代码);前置条件包括 VPC、ELB 安全组和 EFS 卷挂载;集成 CloudWatch/Splunk/Grafana/Prometheus。ECS 作为 AWS 原生技术与 AWS 服务深度集成,适合追求简单性和紧密集成的场景;属 [[Infrastructure-as-Code]] 在 ECS 场景的实践,与 [[ctp-topic-70-eks-deployment-using-iac]](EKS IaC 部署)构成容器编排双路径,与 [[ctp-topic-9-ci-cd-with-gruntwork]](Gruntwork CI/CD)共享 Gruntwork 基础设施基础。与 [[ctp-topic-67-cloud-native-observability-using-opentelemetry]] 在可观测性集成方面关联(ECS 模块集成 CloudWatch/Grafana)。
|
||||
|
||||
**[[ctp-topic-16-cross-account-terraform-modules]]**(CTP Topic 16):Fibos 主讲,多账号 AWS 环境中跨账号 Terraform 模块的中心化部署方案——解决原有 Gruntwork 流水线主要针对单账号设计、账号间直接互访存在安全风险(Blast Radius)的问题。核心架构:基于 **Shared Account(共享账号)** 作为中转站,Jenkins 托管于 Shared Account,检测到模块目录中 `cross-account.json` 标记文件后触发 **ECS Deploy Runner**(ECS 上的 Docker 容器);该 Runner 通过 Assume Role 访问目标账号的两个角色——`TF state bucket accessor`(读取状态文件)和 `cross-account ECS deploy runner role`(执行资源部署);角色切换逻辑在根目录 `terragrunt.hcl` 中全局配置。实现三大目标:**安全性**(无 Workload 账号间直接信任)、**自动化**(Jenkins 自动识别模块类型)、**可复用性**(模块代码不硬编码特定账号角色)。属 [[Infrastructure-as-Code]] 在多账号场景的进阶实践,与 [[ctp-topic-9-ci-cd-with-gruntwork]](单账号流水线)构成演进关系,与 [[ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments]](Atlantis 跨账号角色)共享 Assume Role 机制但执行载体不同(ECS 容器 vs EC2),与 [[ECS Deploy Runner]](实体)共同构成跨账号部署完整链路。
|
||||
|
||||
**[[ctp-topic-21-supply-chain-security-in-micro-focus]]**(CTP Topic 21):
|
||||
|
||||
@@ -185,7 +191,17 @@ Key concepts: [[Process]], [[Value]], [[Value-Stream]], [[Value-Adding]], [[Wast
|
||||
|
||||
**[[public-cloud-learning-sessions-best-practices-for-ec2-cost-optimization-in-aws-2]]**(Public Cloud Learning Sessions,Mike Dukes 和 Steele Taylor 主讲):AWS EC2 成本优化最佳实践深度解析——核心主题覆盖计算效率、Nitro 系统、Graviton 使用、EC2 Spot 竞价实例和容器化成本部署。AWS Nitro 系统通过将网络、存储和安全组件外部化来提升效率;Graviton 处理器基于 ARM64 架构,提供高达 40% 更好的性价比,功耗比同等 x86 实例减少高达 60%;EC2 Spot 实例利用 AWS 闲置容量提供高达 90% 的按需价格折扣;购买选项包括 On-Demand、Savings Plans 和 Spot Instances。Spot Invaders 游戏作为容错混沌工程的实践案例,展示了在 EKS 上使用 Spot 实例构建弹性应用的最佳实践。Graviton 适用于大多数工作负载(Web 服务、容器、HPC 批处理、大数据、CI/CD),但排除有状态服务(如数据库);Spot 和 Graviton 可组合使用以最大化成本节省。属 [[FinOps(云财务管理)]] 技术实践层,与 [[public-cloud-learning-sessions-reducing-cloud-costs-20250318-170100-meeting-reco]](成本优化技术)和 [[ctp-topic-13-cloud-finops-policies]](政策框架)共同构成完整的 EC2 成本优化知识链路。
|
||||
|
||||
**[[public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machin]]**(Public Cloud Learning Sessions,AWS 高级解决方案架构师 Suraav Paul 主讲):AWS AI/ML 与生成式 AI 入门——AI 复制需要人类智能的任务,通过机器学习使用数据创建决策模型;分类 AI 识别模式,预测 AI 预判趋势,生成式 AI 利用基础模型(Foundation Models)创造内容。Amazon 在 ML 领域深耕 20 年,AWS 在四大领域帮助客户应用 AI:提升客户体验、实现更优决策、改善运营、创造新产品。Amazon Bedrock 是全托管生成式 AI 服务,提供 Titan 等多种基础模型,支持微调、持续预训练、RAG 和 Bedrock Agents 等数据定制技术;Guardrails for Bedrock 提供负责任 AI 安全护栏。ML Ops 将机器学习与运维融合,涵盖数据流水线(数据收集/集成/准备)、训练流水线(特征工程/模型训练/超参调优)和推理流水线(部署/监控)。属 Cloud Transformation Programme 的 Serverless & AI 专题入门,与 [[public-cloud-learning-sessions-opentext-generative-ai-prompt-engineering-2024111]](Prompt Engineering)和 [[public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee]](无服务器计算)共同构成 Serverless & AI 知识链路。
|
||||
**[[public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machin]]**(Public Cloud Learning Sessions,AWS 高级解决方案架构师 Suraav Paul 主讲):AWS AI/ML 与生成式 AI 入门——AI 复制需要人类智能的任务,通过机器学习使用数据创建决策模型;分类 AI 识别模式,预测 AI 预判趋势,生成式 AI 利用基础模型(Foundation Models)创造内容。Amazon 在 ML 领域深耕 20 年,AWS 在四大领域帮助客户应用 AI:提升客户体验、实现更优决策、改善运营、创造新产品。Amazon Bedrock 是全托管生成式 AI 服务,提供 Titan 等多种基础模型,支持微调、持续预训练、RAG 和 Bedrock Agents 等数据定制技术;Guardrails for Bedrock 提供负责任 AI 安全护栏。ML Ops 将机器学习与运维融合,涵盖数据流水线(数据收集/集成/准备)、训练流水线(特征工程/模型训练/超参调优)和推理流水线(部署/监控)。属 Cloud Transformation Programme 的 Serverless & AI 专题入门,与 [[public-cloud-learning-sessions-opentext-generative-ai-prompt-engineering-2024111]](Generative AI & Prompt Engineering,OpenText 技术客户经理 Shikad Holtzman 主讲)和 [[public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee]](无服务器计算)共同构成 Serverless & AI 知识链路。
|
||||
|
||||
**[[public-cloud-learning-sessions-opentext-generative-ai-prompt-engineering-2024111]]**(Public Cloud Learning Sessions,OpenText 技术客户经理 Shikad Holtzman 主讲):AWS 生成式 AI 服务与提示工程实践——Shikad Holtzman 阐述生成式 AI 四大价值路径(新体验/员工生产力/洞察提取/创造力激发),涵盖客服聊天机器人、代码生成摘要、文档处理和图像生成等行业场景;核心洞见:**企业数据是差异化关键**,通过 Amazon Bedrock 连接自有数据(无需重训练)即可构建专属生成式 AI 应用,且 Bedrock 保证用户数据与提示词绝不与模型提供商共享。Amazon Bedrock 提供来自 Anthropic/Meta/Amazon Titan 的多种基础模型(含多模态),内置 RAG 知识库、微调、Agents 和 Guardrails for Bedrock 自定义有害内容过滤;Amazon Q 分企业版(多数据源搜索/摘要)和开发者版(代码生成/单元测试/代码迁移);AWS 专用训练芯片 Trainium 和推理芯片 Inferentia 支撑底层算力。提示工程(Prompt Engineering)是创建、设计和优化提示词引导 LLM 响应的迭代过程,提示由指令、上下文、用户输入和输出指示器四部分组成;基础技巧包括 One-shot/Few-shot(通过示例引导)和 Chain of Thoughts(逐步推理解决复杂任务)。属 Cloud Transformation Programme 的 Serverless & AI 专题,与 [[public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machin]](AI/ML 入门)共同构成生成式 AI 知识链路。
|
||||
|
||||
**[[public-cloud-learning-sessions-opentext-ai-use-cases-20241126-160106-meeting-rec]]**(Public Cloud Learning Sessions,AWS AI 专家 Stephen Frank 主讲):AWS Gen2 AI 发展驱动力与企业在生产中的 AI 应用场景——Stephen Frank 阐述 AI 演进历程(模仿人类行为 → 机器学习 → 深度学习 → Gen2 大语言模型),Gen2 AI 崛起背后的两大驱动力:2000 年代以来数据爆发式增长和更大算力的可获得性。Amazon 在核心产品和服务中应用 AI/ML 已 25 年,将经验应用于新客户产品。通用 AI 应用场景:创造新客户体验、从数据中推断核心洞察、流程自动化、生成新内容;企业软件场景:优化内部流程、启用新功能、创造新产品。**数据是差异化关键**——生成式 AI 应用通过 RAG / Fine-tuning / 持续预训练与企业现有业务数据集成。AWS 三层产品战略:基础设施层(基础模型训练/推理)→ Amazon Bedrock(旗舰 API 访问,承诺不与第三方共享用户数据,符合 GDPR)→ 即用型 AI 应用(Amazon Q 等)。Amazon Bedrock 保证用户数据与提示词不与第三方模型提供商共享;Amazon Q 通过自然语言连接多种企业数据源(知识摘要/内容创建/洞察提取)。AI 实施关键:培育实验文化、灵活选择模型、重视安全治理与合规;负责任 AI 原则:公平性(Fairness)、可解释性(Explainability)、透明度(Transparency);最佳实践:优先考虑人、评估风险、迭代全生命周期。属 Cloud Transformation Programme 的 Serverless & AI 专题,与 [[public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machin]](AI/ML 入门)和 [[public-cloud-learning-sessions-opentext-generative-ai-prompt-engineering-2024111]](提示工程)共同构成完整的 AI 知识链路。
|
||||
|
||||
**[[public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee]]**(Public Cloud Learning Sessions,OpenText):AWS 无服务器计算深度解析——现代企业面临快速创新、安全合规、事件响应和盈利增长的多重压力,Serverless 计算通过将运维任务转移给云厂商,使开发团队专注业务代码。AWS Lambda 是核心服务,开发者只需编写业务逻辑,AWS 负责负载均衡、自动扩展和安全,函数由事件(状态变化)触发,支持同步、异步和事件源映射三种调用模式;Lambda 权限模型分离执行角色(决定函数能调用哪些资源)和资源策略(决定谁能触发函数),版本、别名和 Layers 支持代码管理和复用,ARM64 架构提供更优性价比。Step Functions 基于状态机编排多个 Lambda 函数和 AWS 服务,提供 Standard(长时)和 Express(高频)两种工作流类型;API Gateway 提供边缘优化、区域和私有三种部署选项管理 API 生命周期;SAM(Serverless Application Model)基于 CloudFormation 构建,支持本地开发和测试。属 Cloud Transformation Programme 的 Serverless & AI 专题,与 [[public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machin]](AI/ML 入门)共同构成 Serverless & AI 知识链路,与 [[public-cloud-learning-sessions-opentext-event-driven-architecture-part-1-2024091]](事件驱动架构 Part 1)和 [[public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091]](事件驱动架构 Part 2)共享事件驱动执行模型。
|
||||
|
||||
**[[public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091]]**(Public Cloud Learning Sessions,AWS 解决方案架构师 Dr. Anil Giri 主讲):事件驱动架构(EDA)进阶实践——详解 EDA 三组件(事件生产者/消费者/代理)、事件路由器(EventBridge/SNS)与事件存储(SQS/Kinesis)、编排与编排模式(Choreography vs Orchestration)、幂等性(Idempotency)、事件排序(SQS FIFO/Kinesis 保证顺序)、团队独立性(去中心化所有权 vs 集中式所有权)、Fan-out 模式(SNS 主题/EventBridge 规则)、竞争消费者模式(SQS)、死信队列(DLQ)和 EventBridge 最佳实践(每个订阅者单条规则、避免默认事件总线、失败事件处理)。核心洞见:**"Everything fails every time"**——任何系统任何时刻都可能故障,因此幂等性和 DLQ 是 EDA 生产级落地的必要保障。属 Cloud Transformation Programme 的 Serverless & AI 专题进阶篇,与 [[public-cloud-learning-sessions-opentext-event-driven-architecture-part-1-2024091]](Part 1)构成完整 EDA 知识体系,与 [[public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee]](无服务器计算)共享 Lambda 事件驱动执行模型。
|
||||
|
||||
**[[public-cloud-learning-sessions-opentext-event-driven-architecture-part-1-2024091]]**(Public Cloud Learning Sessions,AWS 解决方案架构师 Dr. Anil Giri 主讲):事件驱动架构(EDA)入门与概述——核心学习目标:掌握企业级集成模式(Enterprise Integration Patterns),通过 Amazon EventBridge、SQS 和 SNS 探索事件驱动架构以解决现实世界中的业务挑战。会议原定演示具体 EDA 架构组件,但因 Teams 屏幕共享故障,仅完成开场介绍(⚠️ 完整演示内容参见 [[public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091]])。属 Cloud Transformation Programme 的 Serverless & AI 专题,与 [[public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee]](无服务器计算)共享事件驱动执行模型,共同构成 Serverless & AI 知识链路。
|
||||
|
||||
**[[ctp-topic-20-program-demand-process-flow-and-poc-onboarding]]**(CTP Topic 20):云转型计划的程序需求流程与 POC 入职流程——Sergio 和 Damian 主讲。核心内容:①需求来源——主要由业务案例(如数据中心关闭)、高层管理人员战略优先级及产品路线图驱动;②Gate Process——Gate 0 评估准入、Gate 1 负责 Design Authority 审批、Gate 3 作为启动迁移的最终准入;③POC 目的——不仅验证架构和技术可行性,还包括让团队熟悉基于 Gruntwork 的新一代 Landing Zone;④新环境特点——强调 IaC(Terraform/Terragrunt)自动化部署,严禁手动构建;⑤PCG 团队——平台控制组,负责提供云环境支持、安全策略制定及协助产品组进行 POC;⑥成功标准——POC 成功标准必须在启动前明确定义。属 CTP 治理知识体系入口,与 [[ctp-topic-65]](价值量化)、[[ctp-topic-57]](需求管理)、[[ctp-topic-30]](变更管理)共同构成完整的治理框架链条。
|
||||
|
||||
|
||||
Reference in New Issue
Block a user