Sync: add infrastructure as code notes
This commit is contained in:
56
wiki/concepts/Canary-Deployment.md
Normal file
56
wiki/concepts/Canary-Deployment.md
Normal file
@@ -0,0 +1,56 @@
|
||||
---
|
||||
title: "Canary Deployment"
|
||||
type: concept
|
||||
tags: [DevOps, Deployment, Kubernetes, ECS, AWS]
|
||||
sources: [learning-sessions-ecs-deployment-using-iac-20230808-183322-meeting-recording]
|
||||
last_updated: 2026-05-05
|
||||
---
|
||||
|
||||
# Canary Deployment
|
||||
|
||||
## Definition
|
||||
金丝雀部署（Canary Deployment）是一种软件发布策略，通过将新版本逐步推向一小部分用户来降低风险——在新版本全面推广前，先将少量流量导向新版本，观察其行为和性能，验证无误后再逐步扩大比例。
|
||||
|
||||
## Core Mechanism
|
||||
1. **流量分割**：将用户流量按比例分割（如 5%/10%/50%/100%）
|
||||
2. **逐步提升**：从低比例开始，逐步增加新版本流量
|
||||
3. **快速回滚**：发现问题时，立即将流量切回旧版本
|
||||
|
||||
## Implementation in AWS
|
||||
|
||||
### ECS (Elastic Container Service)
|
||||
ECS 模块支持金丝雀部署，通过 Target Group 权重调整实现流量控制：
|
||||
- 创建新旧两个 Task Definition
|
||||
- 通过 ALB/NLB 的 Target Group 逐步调整权重
|
||||
- 结合 CloudWatch 监控自动决策扩缩比例
|
||||
|
||||
### EKS (Elastic Kubernetes Service)
|
||||
Kubernetes 原生支持金丝雀部署，通过以下机制：
|
||||
- `ReplicaSet` 控制新旧版本副本数
|
||||
- `Service` 选择器配合金丝雀标签
|
||||
- Argo Rollouts 等高级工具提供声明式金丝雀策略
|
||||
|
||||
### AWS Tools
|
||||
- **AWS CodeDeploy**：原生支持 ECS 和 Lambda 的金丝雀部署策略
|
||||
- **ALB Target Groups**：权重路由实现流量分割
|
||||
- **CloudWatch**：金丝雀指标监控
|
||||
|
||||
## Comparison with Other Deployment Strategies
|
||||
|
||||
| 策略 | 风险 | 成本 | 适用场景 |
|
||||
|------|------|------|----------|
|
||||
| **Blue-Green** | 中 | 高（双倍资源） | 快速回滚需求 |
|
||||
| **Canary** | 低 | 中 | 生产验证 |
|
||||
| **Rolling** | 中 | 低 | 资源受限环境 |
|
||||
| **A/B Testing** | 低 | 中 | 功能验证 |
|
||||
|
||||
## Key Metrics to Monitor
|
||||
- 错误率（5xx）
|
||||
- 延迟（P50/P95/P99）
|
||||
- 业务指标（转化率/点击率）
|
||||
- 资源利用率
|
||||
|
||||
## Related Concepts
|
||||
- [[Blue-Green-Deployment]]：双环境切换策略
|
||||
- [[ECS-Module-Deployment]]：ECS 场景的模块化部署
|
||||
- [[Infrastructure-as-Code]]：部署自动化基础
|
||||
61
wiki/concepts/Cross-account-Terraform-Modules.md
Normal file
61
wiki/concepts/Cross-account-Terraform-Modules.md
Normal file
@@ -0,0 +1,61 @@
|
||||
---
|
||||
title: "Cross-account Terraform Modules"
|
||||
type: concept
|
||||
tags: [Terraform, Cross-Account, Modules, IaC, AWS]
|
||||
sources: [ctp-topic-16-cross-account-terraform-modules]
|
||||
last_updated: 2026-04-14
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
Cross-account Terraform Modules 指的是在单个 Terraform 模块中通过配置多个 AWS Provider，实现跨多个 AWS 账号同时创建或管理资源的能力。
|
||||
|
||||
## Problem Statement
|
||||
|
||||
在复杂的云架构中（如 AWS Landing Zone），经常需要在一个模块内跨多个账号创建资源。例如：
|
||||
- 在 **InfoBlocks 账号** 配置 DNS 记录
|
||||
- 在 **Workload 账号** 部署应用服务
|
||||
|
||||
原有的 Gruntwork 流水线主要针对单账号设计，直接赋予账号间互访权限存在巨大安全风险——某一账号被攻破可能波及全局。
|
||||
|
||||
## Solution Architecture
|
||||
|
||||
基于 **Shared Account（共享账号）** 的中心化部署方案：
|
||||
|
||||
1. **Jenkins 托管于 Shared Account**，当检测到模块目录中存在 `cross-account.json` 标记文件时，触发 ECS Deploy Runner
|
||||
2. **ECS Deploy Runner**（运行在 ECS 上的 Docker 容器）被授予特殊权限，通过 Assume Role 访问目标账号：
|
||||
- `TF state bucket accessor`：读取目标账号 S3 桶中的 Terraform 状态文件
|
||||
- `cross-account ECS deploy runner role`：在目标账号内执行资源部署
|
||||
3. 通过根目录 `terragrunt.hcl` 配置角色切换逻辑
|
||||
|
||||
## Three Design Goals
|
||||
|
||||
| Goal | Mechanism | Benefit |
|
||||
|------|-----------|---------|
|
||||
| **安全性** | 无 Workload 账号间直接信任，权限集中于 Shared Account | 控制 Blast Radius |
|
||||
| **自动化** | Jenkins 自动识别模块类型并选择正确部署路径 | 无人工干预 |
|
||||
| **可复用性** | 模块代码不硬编码特定账号的角色 | 灵活适配多环境 |
|
||||
|
||||
## Key Files
|
||||
|
||||
- `cross-account.json`：约定俗成的标记文件，放置于模块目录中，告知 Jenkins 调用跨账号部署逻辑
|
||||
- `terragrunt.hcl`（Root）：全局 Terragrunt 配置文件，定义远程状态存储和角色切换逻辑
|
||||
|
||||
## Relationships
|
||||
|
||||
- [[ECS Deploy Runner]] — 执行单元，运行 Docker 容器执行 plan/apply
|
||||
- [[Shared Account]] — 信任源，托管 Jenkins 和公共服务
|
||||
- [[Terraform]] — 底层 IaC 工具
|
||||
- [[Gruntwork]] — 参考架构来源
|
||||
- [[AWS-Landing-Zone]] — 多账号架构框架
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[Infrastructure-as-Code]] — 上层方法论
|
||||
- [[GitOps]] — 部署编排模式
|
||||
- [[Assume Role]] — 跨账号身份切换机制（AWS IAM）
|
||||
|
||||
## Notes
|
||||
|
||||
- 本方案与单账号 Gruntwork 流水线为**演进关系**而非冲突
|
||||
- 本方案与 Atlantis 跨账号 IAM Role 机制**类似**，但执行载体不同（ECS 容器 vs EC2）
|
||||
68
wiki/concepts/DRY-Principle.md
Normal file
68
wiki/concepts/DRY-Principle.md
Normal file
@@ -0,0 +1,68 @@
|
||||
---
|
||||
title: "DRY Principle"
|
||||
type: concept
|
||||
tags:
|
||||
- software-engineering
|
||||
- iac
|
||||
- best-practices
|
||||
sources: [ctp-topic-48-terraform-vs-terragrunt]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
# DRY Principle
|
||||
|
||||
## Definition
|
||||
|
||||
DRY（Don't Repeat Yourself，勿重复自己）是一项软件工程原则，主张：**系统中的每一条知识必须有一个单一的、明确的、权威的表示**。DRY 的核心目标是减少重复代码和配置，提高系统的可维护性、可扩展性和可测试性。
|
||||
|
||||
## Core Idea
|
||||
|
||||
> "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system."
|
||||
|
||||
DRY 不是简单的"不复制粘贴"，而是更深层的原则：**避免重复的知识**。这包括：
|
||||
- 代码逻辑
|
||||
- 配置文件
|
||||
- 文档注释
|
||||
- 数据结构
|
||||
|
||||
## DRY in IaC
|
||||
|
||||
在基础设施即代码（IaC）领域，DRY 尤为重要，因为基础设施配置往往需要在多个环境（dev/staging/prod）中复用：
|
||||
|
||||
| 实践 | 说明 |
|
||||
|------|------|
|
||||
| **Terragrunt** | 封装 Terraform，通过 `remote_state` 和 `include` 块统一管理跨环境的 provider 和状态配置 |
|
||||
| **Terraform Modules** | 将可复用的基础设施组件抽象为模块，避免在每个环境中重复定义 |
|
||||
| **Service Catalog** | 企业级模块目录，支持三级复用（单账户→产品团队→跨团队） |
|
||||
| **Hierarchical Configuration** | 层级配置继承，父级定义通用配置，子级覆盖特定值 |
|
||||
|
||||
**来源**: [[ctp-topic-48-terraform-vs-terragrunt]], [[ctp-topic-3-deploy-and-maintain-infrastructure]]
|
||||
|
||||
## DRY vs WET
|
||||
|
||||
| 原则 | 全称 | 结果 |
|
||||
|------|------|------|
|
||||
| **DRY** | Don't Repeat Yourself | 一次定义，多次引用 |
|
||||
| **WET** | Write Everything Twice | 多次重复，维护成本高 |
|
||||
|
||||
WET 的典型反模式：
|
||||
- 复制粘贴配置到每个环境
|
||||
- 硬编码值而非使用变量
|
||||
- 注释与代码不同步
|
||||
|
||||
## When NOT to Apply DRY
|
||||
|
||||
DRY 不是绝对的，在以下情况下适度重复是可接受的：
|
||||
- **性能优化**：内联代码可能比函数调用更快
|
||||
- **可读性**：过度抽象可能导致代码难以理解
|
||||
- **解耦**：强制的 DRY 可能增加组件间的耦合
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[Infrastructure-as-Code]] — DRY 原则的重要应用领域
|
||||
- [[Terraform]] — Terragrunt 的底层引擎
|
||||
- [[Terragrunt]] — DRY 原则在 Terraform 生态中的具体实现
|
||||
|
||||
## Related Sources
|
||||
|
||||
- [[ctp-topic-48-terraform-vs-terragrunt]]
|
||||
108
wiki/concepts/Event-Driven-Architecture.md
Normal file
108
wiki/concepts/Event-Driven-Architecture.md
Normal file
@@ -0,0 +1,108 @@
|
||||
---
|
||||
title: "Event-Driven Architecture"
|
||||
type: concept
|
||||
tags:
|
||||
- Architecture
|
||||
- Event-Driven
|
||||
- Serverless
|
||||
- AWS
|
||||
sources:
|
||||
- public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee
|
||||
- public-cloud-learning-sessions-opentext-event-driven-architecture-part-1-2024091
|
||||
- public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091
|
||||
last_updated: 2026-05-05
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
Event-Driven Architecture（事件驱动架构）是一种软件设计范式，在该模式下，系统组件通过产生和消费事件（Event）进行异步通信，而非通过直接的函数调用或请求-响应模式。事件是系统中发生的重要动作或状态变化的声明式通知，事件消费者无需知道事件产生者的存在。
|
||||
|
||||
## Core Principles
|
||||
|
||||
| 原则 | 描述 |
|
||||
|------|------|
|
||||
| 异步通信 | 生产者和消费者解耦，无需同步等待响应 |
|
||||
| 事件声明 | 事件代表"发生了什么"，而非"该做什么" |
|
||||
| 松耦合 | 生产者和消费者之间无直接依赖 |
|
||||
| 可扩展 | 新增消费者无需修改生产者代码 |
|
||||
|
||||
## Event Anatomy
|
||||
|
||||
典型事件包含：
|
||||
|
||||
```json
|
||||
{
|
||||
"event_id": "uuid",
|
||||
"event_type": "ORDER_CREATED",
|
||||
"source": "order-service",
|
||||
"timestamp": "2026-04-14T10:00:00Z",
|
||||
"data": { /* 业务相关数据 */ }
|
||||
}
|
||||
```
|
||||
|
||||
## AWS Event-Driven Stack
|
||||
|
||||
| 组件 | 角色 | 说明 |
|
||||
|------|------|------|
|
||||
| [[Amazon-EventBridge]] | 事件总线 | 接收、过滤、路由事件到目标 |
|
||||
| [[AWS-Lambda]] | 事件消费者 | 响应事件执行处理逻辑 |
|
||||
| [[Amazon-SNS]] | 事件发布/订阅 | 一对多广播消息 |
|
||||
| [[Amazon-SQS]] | 事件队列 | 可靠的事件持久化和顺序处理 |
|
||||
| [[Amazon-DynamoDB]] | 事件源 | DynamoDB Streams 触发 Lambda |
|
||||
| [[Amazon-S3]] | 事件源 | S3 事件通知触发 Lambda |
|
||||
|
||||
## Serverless 中的事件驱动
|
||||
|
||||
[[AWS-Lambda]] 是事件驱动架构的核心执行单元：
|
||||
|
||||
- **事件即触发器**：Lambda 函数不主动运行，由事件触发
|
||||
- **事件源映射**：Lambda 轮询 Kinesis、DynamoDB Stream、SQS 获取事件
|
||||
- **状态变化即事件**：S3 对象上传、API Gateway 请求、DynamoDB 写入等均为事件
|
||||
|
||||
## Event Patterns
|
||||
## EDA 三组件与事件代理类型
|
||||
|
||||
| 组件 | 角色 | 说明 |
|
||||
|------|------|------|
|
||||
| 事件生产者（Producer） | 产生事件 | 服务检测到状态变化时发布事件 |
|
||||
| 事件消费者（Consumer） | 消费事件 | 订阅并处理事件，执行对应业务逻辑 |
|
||||
| 事件代理（Broker） | 路由/存储 | 分事件路由器和事件存储两类 |
|
||||
|
||||
**事件路由器（Event Routers）**——按规则过滤事件并路由到正确消费者：
|
||||
- [[Amazon-EventBridge]]：更丰富，支持 Schema 注册、跨服务触发
|
||||
- [[Amazon-SNS]]：一对多广播（Fan-out）
|
||||
|
||||
**事件存储（Event Stores）**——流式持久化事件，消费者自行过滤：
|
||||
- [[Amazon-SQS]]：标准队列（乱序/高性能）/ FIFO 队列（有序/Exactly-Once）
|
||||
- [[Kinesis-Data-Streams]]：有序事件流，支持重放
|
||||
|
||||
## 编排模式：Choreography vs Orchestration
|
||||
|
||||
| 模式 | 特点 | 适用场景 |
|
||||
|------|------|---------|
|
||||
| Choreography（编排） | 各微服务自主通信，无中央协调者 | 简单、独立的跨服务交互 |
|
||||
| Orchestration（编排） | 中央协调者（如 [[AWS-Step-Functions]]）控制工作流步骤 | 复杂业务流程、需要事务保障 |
|
||||
|
||||
## 生产级最佳实践
|
||||
|
||||
1. **幂等性（Idempotency）**：同一操作执行一次或多次产生相同结果。[[AWS-Lambda]] 异步调用会自动重试，因此幂等性是处理重复消息的关键——尤其适用于订单、支付等场景。
|
||||
|
||||
2. **事件排序**：
|
||||
- **有序**：SQS FIFO 或 Kinesis Data Streams
|
||||
- **乱序可接受**：标准 SQS 或 EventBridge（消费者自行处理乱序）
|
||||
|
||||
3. **团队独立性**：采用去中心化所有权，平台团队提供基础设防（Cloud CoE），消费者团队自主按需消费事件。
|
||||
|
||||
## Event Patterns
|
||||
1. **Pub/Sub**：SNS 主题广播，多消费者订阅同一事件类型
|
||||
2. **Event Streaming**：Kinesis/DynamoDB Stream 持久化事件流，支持重放
|
||||
3. **Fan-Out**：SNS 主题或 EventBridge 规则将事件分发到多个消费者
|
||||
4. **Competing Consumer**：同一消息同一时间只有一个消费者处理（SQS）
|
||||
5. **Dead-Letter Queue（DLQ）**：处理失败事件，防止消息丢失
|
||||
6. **Saga Pattern**：通过事件序列协调分布式事务
|
||||
7. **Event Sourcing**：完整记录所有状态变化事件作为唯一真相来源
|
||||
|
||||
## Connections
|
||||
- [[Event-Driven-Architecture]] ← is_execution_model_of ← [[Serverless-Computing]]
|
||||
- [[Event-Driven-Architecture]] ← uses ← [[Amazon-EventBridge]]
|
||||
- [[Event-Driven-Architecture]] ← executed_by ← [[AWS-Lambda]]
|
||||
@@ -1,37 +1,49 @@
|
||||
---
|
||||
title: "Infrastructure as Code"
|
||||
type: concept
|
||||
tags: [DevOps, 自动化, 配置管理]
|
||||
sources: [ctp-topic-70-eks-deployment-using-iac, learning-sessions-ecs-deployment-using-iac-20230808-183322-meeting-recording, ctp-topic-16-cross-account-terraform-modules, ctp-topic-12-using-ses-smtp-service-terraform-module, learning-sessions-cloud-transformation-programme-deploying-rds-via-terraform]
|
||||
last_updated: 2026-04-24
|
||||
tags: [DevOps, AWS, Terraform, Automation]
|
||||
sources: [ctp-topic-3-deploy-and-maintain-infrastructure, ctp-topic-9-ci-cd-with-gruntwork, ctp-topic-48-terraform-vs-terragrunt, ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments, ctp-topic-33-an-introduction-to-gitops, ctp-topic-56-automated-infrastructure-testing, learning-sessions-ecs-deployment-using-iac-20230808-183322-meeting-recording]
|
||||
last_updated: 2026-05-05
|
||||
---
|
||||
|
||||
# Infrastructure as Code
|
||||
|
||||
## Overview
|
||||
Infrastructure as Code (IaC) 是一种通过代码定义和管理基础设施的方法，实现基础设施的标准化、可审计和可重复部署。
|
||||
## Definition
|
||||
基础设施即代码（Infrastructure as Code, IaC）是一种通过机器可读的定义文件（而非物理硬件配置或交互式配置工具）管理和配置计算基础设施的方法。
|
||||
|
||||
## Core Principles
|
||||
- **声明式配置**：定义期望的状态，而非执行的具体步骤
|
||||
- **版本控制**：所有基础设施配置纳入 Git 版本控制
|
||||
- **自动化部署**：通过 CI/CD 流水线自动化执行部署
|
||||
- **幂等性**：重复执行相同配置不产生副作用
|
||||
- **声明式配置**：描述期望的最终状态，而非执行的具体步骤
|
||||
- **版本控制**：所有基础设施定义文件存储在 Git 中
|
||||
- **幂等性**：多次执行产生相同结果
|
||||
- **可重复性**：同一模板可在不同环境快速部署
|
||||
- **自动化**：与 CI/CD 流水线集成
|
||||
|
||||
## Key Tools
|
||||
- **Terraform**：HashiCorp 的基础设施编排工具，支持多云
|
||||
- **AWS CloudFormation**：AWS 原生的 IaC 服务
|
||||
- **AWS Service Catalog**：AWS 的服务目录，封装标准化产品组合
|
||||
- **Pulumi**：使用编程语言（Python, TypeScript 等）定义基础设施
|
||||
- **Terraform**：HashiCorp 出品，云厂商无关的 IaC 工具，通过状态文件管理资源
|
||||
- **Terragrunt**：Terraform 轻量封装，贯彻 DRY 原则
|
||||
- **AWS CloudFormation**：AWS 原生 IaC 服务，JSON/YAML 模板
|
||||
- **Pulumi**：编程语言驱动的 IaC 平台
|
||||
- **Ansible**：配置管理和应用部署工具
|
||||
|
||||
## Key Concepts
|
||||
- **HCL (HashiCorp Configuration Language)**：Terraform 的配置语言
|
||||
- **State Management**：Terraform 使用 state 文件追踪资源
|
||||
- **Modules**：可重用的基础设施组件
|
||||
- **Remote State**：远程状态存储，支持团队协作
|
||||
## Terraform Ecosystem
|
||||
- **Gruntwork**：预建 Terraform 模块库，生产级参考架构
|
||||
- **Atlantis**：Git 集成 Terraform 部署，PR 评论式协作
|
||||
- **Terratest**：Terraform 代码的 Go 测试框架
|
||||
- **tfsec**：Terraform 静态安全分析工具
|
||||
- **TFLint**：Terraform 代码规范检查
|
||||
|
||||
## IaC in CTP Context
|
||||
CTP（Cloud Transformation Programme）使用 Terraform/Terragrunt 构建 AWS Landing Zone：
|
||||
- [[ctp-topic-3-deploy-and-maintain-infrastructure]]：Terragrunt HCL 文件与模块化管理
|
||||
- [[ctp-topic-9-ci-cd-with-gruntwork]]：Gruntwork CI/CD 流水线实践
|
||||
- [[ctp-topic-48-terraform-vs-terragrunt]]：Terraform 与 Terragrunt 对比选型
|
||||
- [[ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments]]：Atlantis 替代 Jenkins
|
||||
- [[ctp-topic-56-automated-infrastructure-testing]]：TerraTest 自动化测试
|
||||
- [[learning-sessions-ecs-deployment-using-iac-20230808-183322-meeting-recording]]：ECS IaC 部署实践
|
||||
|
||||
## Related Concepts
|
||||
- [[Terraform]]：最流行的 IaC 工具之一
|
||||
- [[AWS Service Catalog]]：AWS IaC 产品目录
|
||||
- [[GitOps]]：基于 Git 的运维方法论
|
||||
- [[CI/CD Pipeline]]：自动化部署流水线
|
||||
- [[DevOps Culture]]：IaC 是 DevOps 实践的核心组成
|
||||
- [[GitOps]]：Git 作为 IaC 的单一真相来源
|
||||
- [[CI/CD Pipeline]]：IaC 与 CI/CD 流水线的集成
|
||||
- [[Policy-as-Code]]：IaC 扩展至安全合规策略
|
||||
- [[Canary-Deployment]]：基于 IaC 的金丝雀部署策略
|
||||
- [[Atlantis]]：GitOps 驱动的 Terraform 协作工具
|
||||
|
||||
@@ -1,76 +1,70 @@
|
||||
---
|
||||
title: "Serverless Computing"
|
||||
type: concept
|
||||
tags: [Cloud, Serverless, Cloud Native, Edge Computing]
|
||||
date: 2026-04-26
|
||||
tags:
|
||||
- Cloud
|
||||
- Serverless
|
||||
- AWS
|
||||
- DevOps
|
||||
sources:
|
||||
- public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee
|
||||
last_updated: 2026-04-14
|
||||
---
|
||||
|
||||
# Serverless Computing (无服务器计算)
|
||||
|
||||
## Definition
|
||||
**Serverless Computing** is a cloud execution model where the cloud provider dynamically manages the allocation and provisioning of servers. Developers can build and deploy applications without worrying about infrastructure management.
|
||||
|
||||
## Key Characteristics
|
||||
- **No server management**: Cloud provider handles infrastructure
|
||||
- **Automatic scaling**: Resources scale based on demand
|
||||
- **Pay-per-use**: Pay only for execution time
|
||||
- **Event-driven**: Functions respond to events/triggers
|
||||
Serverless Computing（无服务器计算）是一种云原生执行模型，在该模式下，云厂商承担底层基础设施的全部运维责任（负载均衡、自动扩展、安全补丁、容量管理），开发者只需专注编写业务逻辑代码。Serverless 并非"无服务器"，而是将服务器管理抽象给云厂商。
|
||||
|
||||
## Key Platforms
|
||||
## Core Characteristics
|
||||
|
||||
| Provider | Service |
|
||||
|----------|---------|
|
||||
| AWS | Lambda |
|
||||
| Azure | Azure Functions |
|
||||
| GCP | Cloud Functions |
|
||||
| 特性 | 描述 |
|
||||
|------|------|
|
||||
| 无运维 | 云厂商管理服务器操作系统、运行时和安全补丁 |
|
||||
| 事件驱动 | 函数由事件触发，事件即资源状态的任何变化 |
|
||||
| 按需付费 | 仅在函数执行时计费（按调用次数和执行时长） |
|
||||
| 自动扩展 | 云厂商根据请求量自动水平扩展，无需人工干预 |
|
||||
| 内置安全 | 云厂商提供基础安全能力（网络隔离、IAM 权限控制） |
|
||||
|
||||
## Benefits
|
||||
## Business Value
|
||||
|
||||
### 1. Cost Efficiency
|
||||
- Eliminates unnecessary resource consumption
|
||||
- No idle capacity costs
|
||||
- Pay only for actual execution time
|
||||
企业采用 Serverless 的核心驱动因素：
|
||||
- **更快上市时间**（Faster Time to Market）：开发团队专注业务逻辑，无需管理基础设施
|
||||
- **业务聚焦**（Business Focus）：将非核心运维任务外包给云厂商
|
||||
- **更低 TCO**（Total Cost of Ownership）：按需付费，空闲时零成本
|
||||
- **弹性扩展**（Elastic Scalability）：从零到百万并发自动应对
|
||||
- **内置安全**（Built-in Security）：云厂商持续更新安全补丁
|
||||
|
||||
### 2. Scalability
|
||||
- Automatic scaling from zero to thousands of instances
|
||||
- Handles traffic spikes without provisioning
|
||||
- Global distribution ready
|
||||
## AWS Serverless Ecosystem
|
||||
|
||||
### 3. Developer Productivity
|
||||
- Focus on business logic, not infrastructure
|
||||
- Faster deployment cycles
|
||||
- Reduced operational overhead
|
||||
AWS 提供完整的 Serverless 服务矩阵：
|
||||
|
||||
## Use Cases
|
||||
| 服务 | 作用 | 关系 |
|
||||
|------|------|------|
|
||||
| [[AWS-Lambda]] | 无服务器计算核心 | 函数执行层 |
|
||||
| [[Amazon-API-Gateway]] | API 创建、发布、安全 | API 暴露层 |
|
||||
| [[AWS-Step-Functions]] | 工作流编排 | 流程编排层 |
|
||||
| [[Amazon-EventBridge]] | 事件总线 | 事件路由层 |
|
||||
| [[AWS-Fargate]] | 无服务器容器 | 容器层的 Serverless |
|
||||
| [[Amazon-DynamoDB]] | 无服务器数据库 | 数据持久层 |
|
||||
| [[SAM-Serverless-Application-Model]] | 本地开发和部署工具 | 开发工具层 |
|
||||
|
||||
### Event-Driven Automation
|
||||
- Real-time file processing
|
||||
- Automated backups
|
||||
- Scheduled tasks and cron jobs
|
||||
## Shared Responsibility Model
|
||||
|
||||
### API Backends
|
||||
- Microservices architecture
|
||||
- Real-time data processing
|
||||
- IoT data ingestion
|
||||
在 Serverless 环境中，AWS 与客户共担运维责任：
|
||||
|
||||
### AI/ML Inference
|
||||
- On-demand model inference
|
||||
- Image and video processing
|
||||
- Natural language processing
|
||||
- **AWS 负责**：基础设施、服务器硬件、网络、运行时环境、安全补丁、负载均衡、自动扩展
|
||||
- **客户负责**：业务代码、依赖管理、权限配置（IAM）、应用程序级别的安全
|
||||
|
||||
## Relationship to Green Computing
|
||||
- Serverless computing contributes to [[Green Computing]] by:
|
||||
- Eliminating idle resource consumption
|
||||
- Optimizing energy efficiency through shared infrastructure
|
||||
- Reducing data center carbon footprint
|
||||
## Event-Driven Architecture Connection
|
||||
|
||||
Serverless 天然契合 [[Event-Driven-Architecture]] 模式：
|
||||
|
||||
1. **事件源**（Event Source）：S3、API Gateway、EventBridge、DynamoDB Stream 等
|
||||
2. **事件路由器**（Event Router）：EventBridge、SNS 等筛选和路由事件
|
||||
3. **Lambda 函数**（Function）：消费事件，执行业务逻辑
|
||||
4. **下游服务**（Downstream）：DynamoDB、SQS、SNS 等处理结果
|
||||
|
||||
## Related Concepts
|
||||
- [[Cloud-Native]]
|
||||
- [[Green Computing]]
|
||||
- [[Event-Driven-Architecture]]
|
||||
- [[Edge-Computing]]
|
||||
|
||||
## Related Entities
|
||||
- [[AWS Lambda]]
|
||||
- [[Azure Functions]]
|
||||
- [[Google Cloud Functions]]
|
||||
- [[Event-Driven-Architecture]] — Serverless 的天然执行模型
|
||||
- [[Lambda-Permissions-Model]] — Serverless 函数的安全权限模型
|
||||
- [[Cloud-Transformation-Programme]] — Serverless 是云转型的关键技术路径之一
|
||||
|
||||
78
wiki/entities/AWS-Lambda.md
Normal file
78
wiki/entities/AWS-Lambda.md
Normal file
@@ -0,0 +1,78 @@
|
||||
---
|
||||
title: "AWS Lambda"
|
||||
type: entity
|
||||
tags:
|
||||
- AWS
|
||||
- Serverless
|
||||
- Compute
|
||||
- Lambda
|
||||
sources:
|
||||
- public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee
|
||||
last_updated: 2026-04-14
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- Lambda
|
||||
- AWS Lambda
|
||||
|
||||
## Definition
|
||||
|
||||
AWS Lambda 是 AWS 的无服务器（Serverless）计算服务——开发者只需编写业务逻辑函数（Handler），AWS 负责所有底层运维：负载均衡、自动扩展、安全补丁和容量管理。Lambda 函数由事件（event）触发，事件即云资源状态的任何变化。
|
||||
|
||||
## Core Properties
|
||||
|
||||
| 属性 | 值 |
|
||||
|------|-----|
|
||||
| 触发模式 | 同步调用、异步调用、事件源映射 |
|
||||
| 权限模型 | 执行角色（Execution Role）+ 资源策略（Resource-Based Policy） |
|
||||
| 代码管理 | 版本（Version）、别名（Alias）、Layers（共享公共依赖） |
|
||||
| 架构支持 | x86 和 ARM64（ARM64 提供更优性价比） |
|
||||
| 监控 | CloudWatch 指标（请求数、错误数、延迟、节流） |
|
||||
| 调试工具 | Amazon Q（集成 AI 辅助调试） |
|
||||
| 性能调优 | Lambda Power Tuning（比较不同配置的性能和成本） |
|
||||
|
||||
## Lambda Handler 模式
|
||||
|
||||
Lambda 函数接收三个核心参数：
|
||||
|
||||
1. **Handler** — 入口函数，事件触发时执行
|
||||
2. **Event Object** — 触发事件的数据结构（API Gateway 请求、S3 对象变更等）
|
||||
3. **Context Object** — 运行时信息（超时设置、内存限制、日志句柄等）
|
||||
|
||||
## Invocation Patterns
|
||||
|
||||
- **同步调用（Synchronous）**：调用方等待响应，如 API Gateway → Lambda
|
||||
- **异步调用（Asynchronous）**：Lambda 自动处理重试（最多 2 次），如 S3 事件 → Lambda
|
||||
- **事件源映射（Event Source Mapping）**：Lambda 轮询流式服务（Kinesis、DynamoDB Stream、SQS）批量处理记录
|
||||
|
||||
## Permissions Model
|
||||
|
||||
Lambda 权限模型基于 IAM 的最小权限原则：
|
||||
|
||||
| 权限类型 | 作用对象 | 说明 |
|
||||
|---------|---------|------|
|
||||
| Execution Role | Lambda 函数 | 定义函数能调用哪些 AWS 资源和服务 |
|
||||
| Resource-Based Policy | 其他 AWS 账号/服务 | 定义谁能/什么能触发该 Lambda 函数 |
|
||||
|
||||
## Lambda Layers
|
||||
|
||||
Lambda Layers 允许跨多个 Lambda 函数共享公共代码和依赖：
|
||||
- 运行时环境（如 Python boto3 库）
|
||||
- 自定义运行时
|
||||
- 配置和脚本
|
||||
|
||||
Layers 避免了每个函数重复打包相同依赖，减少部署包大小和更新成本。
|
||||
|
||||
## Connections
|
||||
- [[Serverless-Computing]] ← is_core_service_of ← [[AWS-Lambda]]
|
||||
- [[AWS-Lambda]] ← triggered_by ← [[Amazon-EventBridge]]
|
||||
- [[AWS-Lambda]] ← exposed_via ← [[Amazon-API-Gateway]]
|
||||
- [[AWS-Lambda]] ← orchestrated_by ← [[AWS-Step-Functions]]
|
||||
- [[AWS-Lambda]] ← monitored_by ← [[CloudWatch]]
|
||||
- [[SAM-Serverless-Application-Model]] ← deploys ← [[AWS-Lambda]]
|
||||
|
||||
## Related Entities
|
||||
- [[Amazon-API-Gateway]] — Lambda 的 API 暴露层
|
||||
- [[AWS-Step-Functions]] — Lambda 的工作流编排层
|
||||
- [[Amazon-EventBridge]] — Lambda 的事件驱动触发源
|
||||
- [[CloudWatch]] — Lambda 的监控和日志层
|
||||
56
wiki/entities/AWS-Step-Functions.md
Normal file
56
wiki/entities/AWS-Step-Functions.md
Normal file
@@ -0,0 +1,56 @@
|
||||
---
|
||||
title: "AWS Step Functions"
|
||||
type: entity
|
||||
tags:
|
||||
- AWS
|
||||
- Serverless
|
||||
- Workflow
|
||||
- Orchestration
|
||||
sources:
|
||||
- public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee
|
||||
last_updated: 2026-04-14
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- Step Functions
|
||||
- AWS Step Functions
|
||||
- Amazon Step Functions
|
||||
|
||||
## Definition
|
||||
|
||||
AWS Step Functions 是 AWS 的无服务器工作流编排服务，基于状态机（State Machine）协调多个 Lambda 函数和 AWS 服务的执行顺序和错误处理逻辑，使开发者无需编写复杂的编排代码即可构建可靠的多步骤业务流程。
|
||||
|
||||
## Core Properties
|
||||
|
||||
| 属性 | 值 |
|
||||
|------|-----|
|
||||
| 核心抽象 | 状态机（Standard 和 Express 两种） |
|
||||
| Standard 工作流 | 长时运行，最长 1 年，支持精确执行历史 |
|
||||
| Express 工作流 | 高频场景，最长 5 分钟，支持极高吞吐量 |
|
||||
| 状态类型 | Task、Choice、Wait、Pass、Parallel、Map、End、Throw |
|
||||
| 错误处理 | 内置 Retry、Catch 和 Error 字段 |
|
||||
| 可视化 | 自动生成工作流图形，直观展示执行路径 |
|
||||
|
||||
## Workflow Flavors
|
||||
|
||||
| 类型 | 适用场景 | 执行时长 | 计费模式 |
|
||||
|------|---------|---------|---------|
|
||||
| Standard | 长时业务流程、审批流、数据处理管道 | 最长 1 年 | 按状态转换计费 |
|
||||
| Express | 高频事件处理、IoT 数据流水线、实时流处理 | 最长 5 分钟 | 按执行次数+GB/s计费 |
|
||||
|
||||
## State Types
|
||||
|
||||
Step Functions 提供丰富的状态类型构建复杂工作流：
|
||||
|
||||
- **Task**：执行单个原子工作单元（如调用 Lambda、DynamoDB 操作）
|
||||
- **Choice**：条件分支，基于数据动态路由执行路径
|
||||
- **Wait**：等待指定时间（用于轮询、重试间隔）
|
||||
- **Pass**：直接传递输入到输出（数据转换）
|
||||
- **Parallel**：并行执行多个分支，汇合结果
|
||||
- **Map**：迭代处理数组中的每个元素
|
||||
- **End/Try-Throw**：终止和错误处理
|
||||
|
||||
## Connections
|
||||
- [[AWS-Step-Functions]] ← orchestrates ← [[AWS-Lambda]]
|
||||
- [[AWS-Step-Functions]] ← is_a ← [[Serverless-Computing]]
|
||||
- [[AWS-Step-Functions]] ← triggers ← [[Amazon-EventBridge]]
|
||||
60
wiki/entities/Amazon-API-Gateway.md
Normal file
60
wiki/entities/Amazon-API-Gateway.md
Normal file
@@ -0,0 +1,60 @@
|
||||
---
|
||||
title: "Amazon API Gateway"
|
||||
type: entity
|
||||
tags:
|
||||
- AWS
|
||||
- Serverless
|
||||
- API
|
||||
- Networking
|
||||
sources:
|
||||
- public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee
|
||||
last_updated: 2026-04-14
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- API Gateway
|
||||
- Amazon API Gateway
|
||||
- AWS API Gateway
|
||||
|
||||
## Definition
|
||||
|
||||
Amazon API Gateway 是 AWS 的全托管 API 管理服务，用于创建、发布、维护和监控安全的企业级 REST、HTTP 和 WebSocket API。API Gateway 作为 Lambda 函数和其他后端服务的统一入口，提供流量管理、授权和访问控制、监控等企业级能力。
|
||||
|
||||
## Core Properties
|
||||
|
||||
| 属性 | 值 |
|
||||
|------|-----|
|
||||
| API 类型 | REST API、HTTP API、WebSocket API |
|
||||
| 部署选项 | Edge-Optimized、Regional、Private |
|
||||
| 认证方式 | IAM 角色、Lambda Authorizer、Cognito、API Key |
|
||||
| 协议 | HTTPS（TLS 终止由 AWS 管理） |
|
||||
| 限流 | 按账户/按 API/按客户多级限流 |
|
||||
| 缓存 | 可选 API 缓存，提升响应速度 |
|
||||
| 监控 | CloudWatch 集成，提供延迟、错误率等指标 |
|
||||
|
||||
## Deployment Options
|
||||
|
||||
| 选项 | 说明 | 适用场景 |
|
||||
|------|------|---------|
|
||||
| Edge-Optimized | 通过 CloudFront CDN 全球分发，低延迟 | 面向全球用户的公共 API |
|
||||
| Regional | 部署在单一区域，自带高可用 | 面向同区域用户、VPC 内的 API |
|
||||
| Private | 仅可通过 VPC 内部端点访问 | 企业内部 API、微服务间通信 |
|
||||
|
||||
## Typical Architecture
|
||||
|
||||
```
|
||||
客户端 → API Gateway → Lambda Function → DynamoDB/SQS/etc.
|
||||
```
|
||||
|
||||
API Gateway 负责：
|
||||
1. TLS 终止（安全）
|
||||
2. 请求验证（格式、参数）
|
||||
3. 限流和配额管理
|
||||
4. 授权和身份验证
|
||||
5. 请求路由到后端 Lambda
|
||||
6. 响应转换和格式统一
|
||||
|
||||
## Connections
|
||||
- [[Amazon-API-Gateway]] ← exposes ← [[AWS-Lambda]]
|
||||
- [[Amazon-API-Gateway]] ← provides ← [[Serverless-Computing]]
|
||||
- [[Amazon-API-Gateway]] ← monitored_by ← [[CloudWatch]]
|
||||
95
wiki/entities/Atlantis.md
Normal file
95
wiki/entities/Atlantis.md
Normal file
@@ -0,0 +1,95 @@
|
||||
---
|
||||
title: "Atlantis"
|
||||
type: entity
|
||||
tags:
|
||||
- devops
|
||||
- iac
|
||||
- terraform
|
||||
- gitops
|
||||
- cicd
|
||||
created: 2026-04-26
|
||||
---
|
||||
|
||||
# Atlantis
|
||||
|
||||
## Definition
|
||||
|
||||
Atlantis 是一个开源的**Terraform CI/CD 工具**，通过与 GitHub/GitLab 深度集成，将 Terraform 的 plan 和 apply 操作转移到 Pull Request（PR）评论层面，实现基础设施即代码的协作式自动化部署。
|
||||
|
||||
## Core Model: PR-Driven IaC
|
||||
|
||||
Atlantis 的核心理念：**每个 Pull Request 都是一次 Terraform 操作**。
|
||||
|
||||
```
|
||||
Developer Atlantis AWS Accounts
|
||||
│ │ │
|
||||
│ 1. Open PR │ │
|
||||
│───────────────────────>│ │
|
||||
│ │ 2. !atlantis plan │
|
||||
│ │───────────────────────>│
|
||||
│ │<───────────────────────│ 3. terraform plan
|
||||
│ 4. Post plan result │ │
|
||||
│<───────────────────────│ │
|
||||
│ 5. Review & Approve │ │
|
||||
│───────────────────────>│ │
|
||||
│ │ 6. !atlantis apply │
|
||||
│ │───────────────────────>│
|
||||
│ │<───────────────────────│ 7. terraform apply
|
||||
│ 8. Merge PR │ │
|
||||
│───────────────────────>│ │
|
||||
```
|
||||
|
||||
**来源**: [[ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments]]
|
||||
|
||||
## Key Features
|
||||
|
||||
| 特性 | 说明 |
|
||||
|------|------|
|
||||
| **PR 评论触发** | 无需独立 CI 账号，开发者在 PR 上评论即可 |
|
||||
| **并行 plan/apply** | 多模块并发执行，提升部署效率 |
|
||||
| **锁定机制** | 防止多 PR 同时操作同一模块产生冲突 |
|
||||
| **跨账户访问** | 通过 IAM 角色实现多 AWS 账户部署 |
|
||||
| **零额外基础设施** | 只需一台 EC2 共享账户实例 |
|
||||
|
||||
**来源**: [[ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments]]
|
||||
|
||||
## Comparison: Atlantis vs Jenkins
|
||||
|
||||
| 维度 | Atlantis | Jenkins |
|
||||
|------|----------|---------|
|
||||
| 触发方式 | PR 评论 | SCM 轮询/定时 |
|
||||
| 初始化速度 | 快速（按需） | 慢（Jenkins 预配置） |
|
||||
| 代码克隆 | 单次 | 多次 |
|
||||
| 测试执行 | 并行 | 顺序 |
|
||||
| 架构复杂度 | 简单 | 复杂（持续叠加功能） |
|
||||
| Terraform 专用 | ✅ 是 | ❌ 通用（需配置） |
|
||||
| PR 协作 | ✅ 原生 | ❌ 无 |
|
||||
|
||||
**来源**: [[ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments]]
|
||||
|
||||
## Micro Focus Usage
|
||||
|
||||
Micro Focus 在 Labs Landing Zone 中使用 Atlantis 替代 Jenkins 进行 Terraform IaC 部署：
|
||||
- 每个 Landing Zone 共享账户部署单台 EC2 实例
|
||||
- GitHub Enterprise Webhook 接收 PR 事件
|
||||
- 服务账号负责评论/合并/关闭 PR
|
||||
- Atlantis 在 merge 前即应用变更
|
||||
|
||||
**局限性**: Atlantis 当前不支持 EKS 部署，需通过 Jenkins + Terragrunt 模块替代。
|
||||
|
||||
**来源**: [[ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments]], [[ctp-topic-39-implementing-eks-in-the-aws-lab-landing-zone]]
|
||||
|
||||
## Related Entities
|
||||
|
||||
- [[Terraform]] — Atlantis 操作的核心 IaC 工具
|
||||
- [[Gruntwork]] — Terragrunt 的开发者（Atlantis 生态伙伴）
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[GitOps]] — Atlantis 是 GitOps 在 Terraform 领域的实现工具
|
||||
- [[CI/CD Pipeline]] — Atlantis 提供 CI/CD 能力
|
||||
|
||||
## Related Sources
|
||||
|
||||
- [[ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments]]
|
||||
- [[ctp-topic-39-implementing-eks-in-the-aws-lab-landing-zone]]
|
||||
@@ -1,30 +1,32 @@
|
||||
---
|
||||
title: "Gruntwork"
|
||||
type: entity
|
||||
sources: [ctp-topic-17-active-directory-services-in-gruntwork-aws-lzs]
|
||||
last_updated: 2026-04-14
|
||||
tags: [AWS, IaC, DevOps, Terraform]
|
||||
sources: [ctp-topic-9-ci-cd-with-gruntwork, ctp-topic-48-terraform-vs-terragrunt, learning-sessions-ecs-deployment-using-iac-20230808-183322-meeting-recording]
|
||||
last_updated: 2026-05-05
|
||||
---
|
||||
|
||||
# Gruntwork
|
||||
|
||||
## Overview
|
||||
Gruntwork 是 Micro Focus Cloud Transformation Programme (CTP) 中采用的 AWS Landing Zones 基础设施框架提供方。Gruntwork Landing Zones 提供预配置的、基于最佳实践的 AWS 基础架构模板，帮助企业快速构建符合安全和合规要求的 AWS 多账户架构。
|
||||
Gruntwork 是一家专注于 AWS 基础设施即代码（IaC）的公司，提供预构建、可定制的 Terraform 模块库，帮助团队快速构建生产级云基础设施。
|
||||
|
||||
## Aliases
|
||||
- Gruntwork AWS Landing Zones
|
||||
- Gruntwork LZ
|
||||
## Products
|
||||
- **Gruntwork Landing Zone Architecture**：基于 Terraform/Terragrunt 的 AWS Landing Zone 参考架构，涵盖账户结构、网络、安全、运维等基础设施层
|
||||
- **Gruntwork Infrastructure Live**：生产级 Terraform 模块库，支持多账户、多区域部署
|
||||
- **Pipelines**：Gruntwork 推荐的 CI/CD 流水线方案，集成 GitHub Actions/Jenkins
|
||||
|
||||
## Key Capabilities
|
||||
- **多环境支持**：区分 R&D Labs 和 SAS（Staging/Production）两种环境类型，分别对应不同的 AD 域名架构
|
||||
- **预制 AMI**：SRE 团队维护内置域加入脚本的标准化机器镜像
|
||||
- **IaC 集成**：与 Terraform/TerraGrunt 深度集成，支持 `user_data` 触发自动化域加入流程
|
||||
- **AD 集成**：提供标准化的 Active Directory 服务集成方案，包括 DNS 管理和安全动态更新
|
||||
## Key Modules
|
||||
- **ECS 模块**：Docker 容器部署模块，CTP/SRE 团队在此基础上构建了自己的 ECS 模块（实现 Listener 集中管理）
|
||||
- **EKS 模块**：Kubernetes 集群部署模块
|
||||
- **Landing Zone 模块**：AWS 组织、账户、OU 架构
|
||||
|
||||
## Related Entities
|
||||
- [[SRE Team]]：构建和维护 Gruntwork LZ 中预制 AMI 的团队
|
||||
- [[Gruntwork AWS Landing Zones Overview]]：Gruntwork LZ 的整体架构概述
|
||||
- [[ctp-topic-17-active-directory-services-in-gruntwork-aws-lzs]]：AD 服务集成的核心参考文档
|
||||
## Gruntwork in CTP Context
|
||||
- [[ctp-topic-9-ci-cd-with-gruntwork]]：CTP Topic 9 深入 Gruntwork CI/CD 实践
|
||||
- [[ctp-topic-48-terraform-vs-terragrunt]]：Terraform 与 Terragrunt 对比，Gruntwork 作为辅助工具推荐
|
||||
- [[learning-sessions-ecs-deployment-using-iac-20230808-183322-meeting-recording]]：CTP 团队在 Gruntwork 仓库基础上开发 ECS 模块
|
||||
|
||||
## References
|
||||
- [[ctp-topic-17-active-directory-services-in-gruntwork-aws-lzs]]
|
||||
- [[ctp-topic-14-octane-hub-on-aws-real-life-experience-moving-production-services-i]]
|
||||
- [[ctp-topic-9-ci-cd-with-gruntwork]]
|
||||
- [[ctp-topic-1-gruntwork-landing-zone-architecture]]
|
||||
## Connections
|
||||
- [[HashiCorp]] ← provider_of ← [[Terraform]] ← uses ← [[Gruntwork]]
|
||||
- [[Atlantis]] ← alternative_to ← [[Gruntwork-Pipelines]]
|
||||
- [[Gruntwork]] ← builds_on ← [[Infrastructure-as-Code]]
|
||||
|
||||
59
wiki/entities/HashiCorp.md
Normal file
59
wiki/entities/HashiCorp.md
Normal file
@@ -0,0 +1,59 @@
|
||||
---
|
||||
title: "HashiCorp"
|
||||
type: entity
|
||||
tags:
|
||||
- devops
|
||||
- iac
|
||||
- infrastructure
|
||||
- tools
|
||||
created: 2026-04-26
|
||||
---
|
||||
|
||||
# HashiCorp
|
||||
|
||||
## Definition
|
||||
|
||||
HashiCorp 是全球领先的**云基础设施自动化**软件公司，总部位于旧金山，创立于 2012 年。HashiCorp 提供一套完整的基础设施生命周期管理工具，覆盖配置管理、机密管理、服务网格和网络自动化等领域。
|
||||
|
||||
## Core Products
|
||||
|
||||
| 产品 | 用途 | 类别 |
|
||||
|------|------|------|
|
||||
| **Terraform** | 云厂商无关的基础设施即代码 | IaC |
|
||||
| **Vault** | 机密管理与加密即服务 | 安全 |
|
||||
| **Nomad** | 容器和工作负载调度器 | 编排 |
|
||||
| **Consul** | 服务网格与服务发现 | 网络 |
|
||||
| **Packer** | 机器镜像构建自动化 | 镜像 |
|
||||
| **Vagrant** | 开发环境管理 | 开发环境 |
|
||||
|
||||
## Terraform
|
||||
|
||||
HashiCorp 最知名的产品。Terraform 是用 Golang 编写的云无关 IaC 工具，通过声明式 HCL（HashiCorp Configuration Language）管理跨多云和混合云环境的基础设施资源。
|
||||
|
||||
**关键特性：**
|
||||
- 云厂商无关（AWS/Azure/GCP/On-prem）
|
||||
- `terraform plan` 预览变更
|
||||
- 状态文件管理实际资源与期望状态的绑定
|
||||
- 丰富的 Provider 生态系统和 Module 市场
|
||||
|
||||
**来源**: [[ctp-topic-48-terraform-vs-terragrunt]]
|
||||
|
||||
## Business Model
|
||||
|
||||
- **开源**：所有产品的开源版本
|
||||
- **Enterprise**：企业级功能（SSO、RBAC、审计日志、Sentinel 策略）
|
||||
- **HCP（HashiCorp Cloud Platform）**：SaaS 托管版本
|
||||
|
||||
## Related Entities
|
||||
|
||||
- [[Terraform]] — HashiCorp 出品的核心 IaC 产品
|
||||
- [[Terragrunt]] — 第三方 Terraform 封装工具（贯彻 DRY 原则）
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[Infrastructure-as-Code]] — HashiCorp 产品的核心方法论
|
||||
- [[Multi-Cloud Strategy]] — Terraform 云无关定位的战略价值
|
||||
|
||||
## Related Sources
|
||||
|
||||
- [[ctp-topic-48-terraform-vs-terragrunt]]
|
||||
86
wiki/entities/SAM-Serverless-Application-Model.md
Normal file
86
wiki/entities/SAM-Serverless-Application-Model.md
Normal file
@@ -0,0 +1,86 @@
|
||||
---
|
||||
title: "SAM Serverless Application Model"
|
||||
type: entity
|
||||
tags:
|
||||
- AWS
|
||||
- Serverless
|
||||
- IaC
|
||||
- CloudFormation
|
||||
sources:
|
||||
- public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee
|
||||
last_updated: 2026-04-14
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- SAM
|
||||
- AWS SAM
|
||||
- Serverless Application Model
|
||||
|
||||
## Definition
|
||||
|
||||
AWS SAM（Serverless Application Model）是 AWS 官方的开源 IaC 工具，基于 AWS CloudFormation 构建，专门简化无服务器应用（Lambda、API Gateway、Step Functions 等）的定义、部署和管理。SAM 提供简化的 YAML 语法，降低 CloudFormation 模板的复杂度，同时支持本地开发和测试。
|
||||
|
||||
## Core Properties
|
||||
|
||||
| 属性 | 值 |
|
||||
|------|-----|
|
||||
| 基础 | AWS CloudFormation |
|
||||
| 配置格式 | YAML（简化语法） |
|
||||
| CLI | AWS SAM CLI，支持本地调用和测试 |
|
||||
| 本地测试 | SAM Local — 本地启动 API Gateway + Lambda |
|
||||
| 部署 | `sam deploy`、`sam build`、`sam package` |
|
||||
| 应用发布 | AWS Serverless Application Repository（应用市场） |
|
||||
|
||||
## SAM vs CloudFormation
|
||||
|
||||
| 特性 | SAM | CloudFormation |
|
||||
|------|-----|----------------|
|
||||
| 语法 | 简化 YAML | JSON/YAML |
|
||||
| 资源类型 | 仅 Serverless 资源 | 全部 AWS 资源 |
|
||||
| 本地测试 | SAM Local | 不支持 |
|
||||
| 打包上传 | `sam package` | `aws cloudformation package` |
|
||||
| 模板继承 | `!Sub`、`!Ref` | 原生支持 |
|
||||
|
||||
## Typical SAM Template
|
||||
|
||||
```yaml
|
||||
AWSTemplateFormatVersion: '2010-09-09'
|
||||
Transform: AWS::Serverless-2016-10-31
|
||||
Resources:
|
||||
MyFunction:
|
||||
Type: AWS::Serverless::Function
|
||||
Properties:
|
||||
Handler: app.handler
|
||||
Runtime: python3.12
|
||||
Events:
|
||||
ApiEvent:
|
||||
Type: Api
|
||||
Properties:
|
||||
Path: /hello
|
||||
Method: get
|
||||
MyApi:
|
||||
Type: AWS::Serverless::Api
|
||||
Properties:
|
||||
StageName: prod
|
||||
DefinitionBody:
|
||||
# OpenAPI spec
|
||||
```
|
||||
|
||||
## SAM CLI 常用命令
|
||||
|
||||
| 命令 | 作用 |
|
||||
|------|------|
|
||||
| `sam init` | 初始化新 SAM 项目 |
|
||||
| `sam build` | 构建应用（处理依赖、Layer） |
|
||||
| `sam local invoke` | 本地调用 Lambda 函数 |
|
||||
| `sam local start-api` | 本地启动完整 API（API Gateway + Lambda） |
|
||||
| `sam deploy` | 交互式部署到 AWS |
|
||||
| `sam package` | 打包模板和代码到 S3 |
|
||||
| `sam validate` | 验证模板语法 |
|
||||
|
||||
## Connections
|
||||
- [[SAM-Serverless-Application-Model]] ← builds_on ← [[CloudFormation]]
|
||||
- [[SAM-Serverless-Application-Model]] ← deploys ← [[AWS-Lambda]]
|
||||
- [[SAM-Serverless-Application-Model]] ← deploys ← [[Amazon-API-Gateway]]
|
||||
- [[SAM-Serverless-Application-Model]] ← deploys ← [[AWS-Step-Functions]]
|
||||
- [[SAM-Serverless-Application-Model]] ← is_tool_of ← [[Serverless-Computing]]
|
||||
@@ -102,6 +102,36 @@ Agentic AI 在 Terraform 工作流中扮演审查者角色：
|
||||
> acl = "private" # Block public access
|
||||
> ```
|
||||
|
||||
## State File Management
|
||||
|
||||
Terraform 通过**状态文件 (state file)** 将声明式配置中定义的**期望状态**与云环境的**实际资源状态**进行绑定。关键特性：
|
||||
- **状态锁定**：防止并发执行导致状态不一致
|
||||
- **远程状态**：企业级场景需将状态文件存储在 S3（+ DynamoDB 锁）等远程后端，支持团队协作
|
||||
- **差异对比**：`terraform plan` 预览实际变更内容再执行，是 Terraform 的核心优势
|
||||
|
||||
**来源**: [[ctp-topic-48-terraform-vs-terragrunt]]
|
||||
|
||||
## Terragrunt Wrapper
|
||||
|
||||
Terragrunt 是 Terraform 的轻量封装，继承所有 Terraform 命令（HCL 语法完全兼容）。两者关系：
|
||||
- `terragrunt plan` = `terraform plan`
|
||||
- Terragrunt 通过 `remote_state` 和 `include` 块实现跨环境配置的 DRY 管理
|
||||
|
||||
**来源**: [[ctp-topic-48-terraform-vs-terragrunt]]
|
||||
|
||||
## Ecosystem Tools
|
||||
|
||||
| 工具 | 类型 | 用途 |
|
||||
|------|------|------|
|
||||
| [[Terragrunt]] | 封装 | 多环境 DRY 配置 |
|
||||
| [[Atlantis]] | CI/CD | Git PR 驱动的 plan/apply |
|
||||
| Terraform Enterprise | 平台 | 企业 CI + workspaces |
|
||||
| [[Gruntwork]] | 模块库 | 预建可复用 IaC 模块 |
|
||||
| Terratest | 测试 | IaC 集成测试（Golang） |
|
||||
| tfsec | 安全 | Terraform 静态安全分析 |
|
||||
|
||||
**来源**: [[ctp-topic-48-terraform-vs-terragrunt]], [[ctp-topic-56-automated-infrastructure-testing]]
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[Infrastructure-as-Code]] — Terraform 是 IaC 的实现工具
|
||||
|
||||
100
wiki/entities/Terragrunt.md
Normal file
100
wiki/entities/Terragrunt.md
Normal file
@@ -0,0 +1,100 @@
|
||||
---
|
||||
title: "Terragrunt"
|
||||
type: entity
|
||||
tags:
|
||||
- devops
|
||||
- iac
|
||||
- terraform
|
||||
- automation
|
||||
created: 2026-04-26
|
||||
---
|
||||
|
||||
# Terragrunt
|
||||
|
||||
## Definition
|
||||
|
||||
Terragrunt 是由 Gruntwork 开发的**Terraform 轻量封装工具**，核心目标是贯彻 DRY（Don't Repeat Yourself）原则，简化多环境、多账户 Terraform 配置的管理。
|
||||
|
||||
## Core Value
|
||||
|
||||
Terragrunt 对 Terraform 的核心改进在于**减少重复配置**：
|
||||
|
||||
| 问题 | Terraform 方案 | Terragrunt 方案 |
|
||||
|------|---------------|----------------|
|
||||
| provider 块重复 | 每个环境独立声明 | `terragrunt.hcl` 统一管理 |
|
||||
| remote_state 块重复 | 多处硬编码 | 模板化复用 |
|
||||
| 模块引用方式 | 固定分支引用 | 版本锁定引用 |
|
||||
| 多环境同步 | 手动复制配置 | `include` 块继承 |
|
||||
|
||||
**来源**: [[ctp-topic-48-terraform-vs-terragrunt]]
|
||||
|
||||
## Compatibility
|
||||
|
||||
Terragrunt **完全兼容** Terraform 的所有命令和 HCL 语法：
|
||||
- `terragrunt plan` → 底层调用 `terraform plan`
|
||||
- `terragrunt apply` → 底层调用 `terraform apply`
|
||||
- 所有 Terraform HCL 块和属性完全兼容
|
||||
|
||||
这意味着 Terragrunt **不是** Terraform 的替代品，而是增强层。
|
||||
|
||||
**来源**: [[ctp-topic-48-terraform-vs-terragrunt]]
|
||||
|
||||
## Key Features
|
||||
|
||||
### DRY Remote State
|
||||
通过 `remote_state` 块集中管理状态文件位置：
|
||||
```hcl
|
||||
remote_state {
|
||||
backend = "s3"
|
||||
config = {
|
||||
bucket = "my-terraform-state"
|
||||
key = "${path_relative_to_include()}/terraform.tfstate"
|
||||
region = "eu-west-1"
|
||||
encrypt = true
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Provider Management
|
||||
跨环境统一 provider 配置，避免在每个模块中重复声明。
|
||||
|
||||
### Include & Inheritance
|
||||
通过 `include` 块实现配置的继承与覆盖：
|
||||
```hcl
|
||||
include {
|
||||
path = find_in_parent_folders("root.hcl")
|
||||
}
|
||||
```
|
||||
|
||||
## Use Case: Micro Focus Labs Landing Zone
|
||||
|
||||
Micro Focus Labs Landing Zone 使用 Terragrunt 管理多账户配置，所有资源通过 Terraform/Terragrunt 管理，Jenkins 流水线扫描 GitHub 仓库变更触发 plan/apply。
|
||||
|
||||
**来源**: [[ctp-topic-3-deploy-and-maintain-infrastructure]], [[ctp-topic-25-labs-landing-zone-overview-itom-teams]]
|
||||
|
||||
## Ecosystem Position
|
||||
|
||||
```
|
||||
Terraform Ecosystem
|
||||
├── Terraform (HashiCorp) — 核心 IaC 引擎
|
||||
├── Terragrunt (Gruntwork) — DRY 封装层 ←
|
||||
├── Terraform Enterprise (HashiCorp) — 企业 CI 平台
|
||||
└── Gruntwork Library (Gruntwork) — 预建模块库
|
||||
```
|
||||
|
||||
## Related Entities
|
||||
|
||||
- [[Terraform]] — Terragrunt 包装的核心引擎
|
||||
- [[HashiCorp]] — Terraform 创立公司
|
||||
- [[Gruntwork]] — Terragrunt 开发公司
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[Infrastructure-as-Code]] — Terragrunt 的应用领域
|
||||
- [[DRY Principle]] — Terragrunt 的设计哲学
|
||||
|
||||
## Related Sources
|
||||
|
||||
- [[ctp-topic-48-terraform-vs-terragrunt]]
|
||||
- [[ctp-topic-3-deploy-and-maintain-infrastructure]]
|
||||
- [[ctp-topic-15-working-with-renovatebot]]（Renovate Bot 扫描 Terragrunt 配置）
|
||||
@@ -4,6 +4,14 @@
|
||||
- [Overview](overview.md) — living synthesis
|
||||
|
||||
## Sources
|
||||
- [2026-04-24] [CTP Topic 16 Cross-account Terraform modules](sources/ctp-topic-16-cross-account-terraform-modules.md)
|
||||
- [2026-04-24] [Learning Sessions ECS Deployment using IAC - 20230808](sources/learning-sessions-ecs-deployment-using-iac-20230808-183322-meeting-recording.md)
|
||||
- [2026-04-24] [CTP Topic 48 Terraform vs Terragrunt](sources/ctp-topic-48-terraform-vs-terragrunt.md)
|
||||
- [2026-04-24] [Public Cloud Learning Sessions (OpenText) - AI Use Cases - 20241126 160106](sources/public-cloud-learning-sessions-opentext-ai-use-cases-20241126-160106-meeting-rec.md)
|
||||
- [2026-04-24] [Public Cloud Learning Sessions (OpenText) - Event Driven Architecture Part 2](sources/public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091.md)
|
||||
- [2026-04-24] [Public Cloud Learning Sessions (OpenText) - Generative AI & Prompt Engineering - 20241112](sources/public-cloud-learning-sessions-opentext-generative-ai-prompt-engineering-2024111.md)
|
||||
- [2026-04-24] [Public Cloud Learning Sessions (OpenText) - Event Driven Architecture Part 1](sources/public-cloud-learning-sessions-opentext-event-driven-architecture-part-1-2024091.md)
|
||||
- [2026-04-24] [Public Cloud Learning Sessions - Serverless Computing - 20240903](sources/public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee.md)
|
||||
- [2026-04-24] [Public Cloud Learning Sessions - Introduction to AI/ML with AWS](sources/public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machin.md)
|
||||
- [2026-04-24] [Cloud Learning Master Index](sources/cloud-learning-master-index.md)
|
||||
- [2026-04-24] [CTP Topic 27 AWS Instance Scheduler](sources/ctp-topic-27-aws-instance-scheduler.md)
|
||||
@@ -406,14 +414,6 @@
|
||||
- [2026-04-20] [ctp-topic-12-using-ses-smtp-service-terraform-module](sources/ctp-topic-12-using-ses-smtp-service-terraform-module.md) — (expected: wiki/sources/ctp-topic-12-using-ses-smtp-service-terraform-module.md — source missing)
|
||||
- [2026-04-20] [learning-sessions-cloud-transformation-programme-deploying-rds-via-terraform](sources/learning-sessions-cloud-transformation-programme-deploying-rds-via-terraform.md) — (expected: wiki/sources/learning-sessions-cloud-transformation-programme-deploying-rds-via-terraform.md — source missing)
|
||||
- [2026-04-20] [learning-sessions-cloud-transformation-programme-20230808-183322-meeting-recordi](sources/learning-sessions-cloud-transformation-programme-20230808-183322-meeting-recordi.md) — (expected: wiki/sources/learning-sessions-cloud-transformation-programme-20230808-183322-meeting-recordi.md — source missing)
|
||||
- [2026-04-20] [ctp-topic-16-cross-account-terraform-modules](sources/ctp-topic-16-cross-account-terraform-modules.md) — (expected: wiki/sources/ctp-topic-16-cross-account-terraform-modules.md — source missing)
|
||||
- [2026-04-20] [learning-sessions-ecs-deployment-using-iac-20230808-183322-meeting-recording](sources/learning-sessions-ecs-deployment-using-iac-20230808-183322-meeting-recording.md) — (expected: wiki/sources/learning-sessions-ecs-deployment-using-iac-20230808-183322-meeting-recording.md — source missing)
|
||||
- [2026-04-19] [ctp-topic-48-terraform-vs-terragrunt](sources/ctp-topic-48-terraform-vs-terragrunt.md) — (expected: wiki/sources/ctp-topic-48-terraform-vs-terragrunt.md — source missing)
|
||||
- [2026-04-19] [public-cloud-learning-sessions-opentext-ai-use-cases-20241126-160106-meeting-rec](sources/public-cloud-learning-sessions-opentext-ai-use-cases-20241126-160106-meeting-rec.md) — (expected: wiki/sources/public-cloud-learning-sessions-opentext-ai-use-cases-20241126-160106-meeting-rec.md — source missing)
|
||||
- [2026-04-19] [public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091](sources/public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091.md) — (expected: wiki/sources/public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091.md — source missing)
|
||||
- [2026-04-19] [public-cloud-learning-sessions-opentext-generative-ai-prompt-engineering-2024111](sources/public-cloud-learning-sessions-opentext-generative-ai-prompt-engineering-2024111.md) — (expected: wiki/sources/public-cloud-learning-sessions-opentext-generative-ai-prompt-engineering-2024111.md — source missing)
|
||||
- [2026-04-19] [public-cloud-learning-sessions-opentext-event-driven-architecture-part-1-2024091](sources/public-cloud-learning-sessions-opentext-event-driven-architecture-part-1-2024091.md) — (expected: wiki/sources/public-cloud-learning-sessions-opentext-event-driven-architecture-part-1-2024091.md — source missing)
|
||||
- [2026-04-19] [public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee](sources/public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee.md) — (expected: wiki/sources/public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee.md — source missing)
|
||||
- [Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog](sources/Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog.md) — (expected: wiki/sources/Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog.md — source missing)
|
||||
- [Expose-hermes-agent-as-an-OpenAI-compatible-API-for-any-frontend](sources/Expose-hermes-agent-as-an-OpenAI-compatible-API-for-any-frontend.md) — (expected: wiki/sources/Expose-hermes-agent-as-an-OpenAI-compatible-API-for-any-frontend.md — source missing)
|
||||
- [zk-steward](sources/zk-steward.md) — (expected: wiki/sources/zk-steward.md — source missing)
|
||||
@@ -543,6 +543,7 @@
|
||||
- [Alertmanager](entities/Alertmanager.md)
|
||||
- [Alex-Ewerlof](entities/Alex-Ewerlof.md)
|
||||
- [Alex-Finn](entities/Alex-Finn.md)
|
||||
- [Amazon-API-Gateway](entities/Amazon-API-Gateway.md)
|
||||
- [Amazon-Aurora](entities/Amazon-Aurora.md)
|
||||
- [Amazon-CloudWatch-Logs](entities/Amazon-CloudWatch-Logs.md)
|
||||
- [Amazon-DocumentDB](entities/Amazon-DocumentDB.md)
|
||||
@@ -559,10 +560,13 @@
|
||||
- [Apache-Superset](entities/Apache-Superset.md)
|
||||
- [Asana](entities/Asana.md)
|
||||
- [Ashish](entities/Ashish.md)
|
||||
- [Atlantis](entities/Atlantis.md)
|
||||
- [AWS](entities/AWS.md)
|
||||
- [AWS-CloudFormation-StackSets](entities/AWS-CloudFormation-StackSets.md)
|
||||
- [AWS-Lambda](entities/AWS-Lambda.md)
|
||||
- [AWS-OpenSearch](entities/AWS-OpenSearch.md)
|
||||
- [AWS-Organizations](entities/AWS-Organizations.md)
|
||||
- [AWS-Step-Functions](entities/AWS-Step-Functions.md)
|
||||
- [Axton](entities/Axton.md)
|
||||
- [Azure](entities/Azure.md)
|
||||
- [baoyu](entities/baoyu.md)
|
||||
@@ -628,6 +632,7 @@
|
||||
- [GoogleCloud](entities/GoogleCloud.md)
|
||||
- [Grafana](entities/Grafana.md)
|
||||
- [Gruntwork](entities/Gruntwork.md)
|
||||
- [HashiCorp](entities/HashiCorp.md)
|
||||
- [Heather-Norris](entities/Heather-Norris.md)
|
||||
- [hello-world](entities/hello-world.md)
|
||||
- [HemantSawant](entities/HemantSawant.md)
|
||||
@@ -713,6 +718,7 @@
|
||||
- [rsync](entities/rsync.md)
|
||||
- [Rufus](entities/Rufus.md)
|
||||
- [RustDesk](entities/RustDesk.md)
|
||||
- [SAM-Serverless-Application-Model](entities/SAM-Serverless-Application-Model.md)
|
||||
- [SankarGopov](entities/SankarGopov.md)
|
||||
- [shenwei](entities/shenwei.md)
|
||||
- [Simon-Hoiberg](entities/Simon-Hoiberg.md)
|
||||
@@ -730,6 +736,7 @@
|
||||
- [Synology-NAS-DS718](entities/Synology-NAS-DS718.md)
|
||||
- [Telnyx](entities/Telnyx.md)
|
||||
- [Terraform](entities/Terraform.md)
|
||||
- [Terragrunt](entities/Terragrunt.md)
|
||||
- [Tiago-Forte](entities/Tiago-Forte.md)
|
||||
- [tini](entities/tini.md)
|
||||
- [Todoist](entities/Todoist.md)
|
||||
@@ -821,6 +828,7 @@
|
||||
- [Business-Knowledge-Base](concepts/Business-Knowledge-Base.md)
|
||||
- [caffeinate](concepts/caffeinate.md)
|
||||
- [Call-Worthy-Threshold](concepts/Call-Worthy-Threshold.md)
|
||||
- [Canary-Deployment](concepts/Canary-Deployment.md)
|
||||
- [Canary-Release](concepts/Canary-Release.md)
|
||||
- [Canvas](concepts/Canvas.md)
|
||||
- [CAPA](concepts/CAPA.md)
|
||||
@@ -877,6 +885,7 @@
|
||||
- [Credit-Efficient-Processing](concepts/Credit-Efficient-Processing.md)
|
||||
- [Cron定时任务](concepts/Cron定时任务.md)
|
||||
- [Cross-Account-Monitoring](concepts/Cross-Account-Monitoring.md)
|
||||
- [Cross-account-Terraform-Modules](concepts/Cross-account-Terraform-Modules.md)
|
||||
- [Cumulative-Memory](concepts/Cumulative-Memory.md)
|
||||
- [Custom-Instructions](concepts/Custom-Instructions.md)
|
||||
- [Daily-Digest](concepts/Daily-Digest.md)
|
||||
@@ -904,6 +913,7 @@
|
||||
- [Docker警告处理](concepts/Docker警告处理.md)
|
||||
- [DORA-Metrics](concepts/DORA-Metrics.md)
|
||||
- [DRaaS](concepts/DRaaS.md)
|
||||
- [DRY-Principle](concepts/DRY-Principle.md)
|
||||
- [DRY原则](concepts/DRY原则.md)
|
||||
- [DuckDB](concepts/DuckDB.md)
|
||||
- [Dynamic-Dashboard](concepts/Dynamic-Dashboard.md)
|
||||
@@ -923,6 +933,7 @@
|
||||
- [Error-Budget](concepts/Error-Budget.md)
|
||||
- [Error-Surface-vs-Root-Cause](concepts/Error-Surface-vs-Root-Cause.md)
|
||||
- [Event-Correlation](concepts/Event-Correlation.md)
|
||||
- [Event-Driven-Architecture](concepts/Event-Driven-Architecture.md)
|
||||
- [EventSourcing](concepts/EventSourcing.md)
|
||||
- [Expert-User-Assumption](concepts/Expert-User-Assumption.md)
|
||||
- [Exporter](concepts/Exporter.md)
|
||||
|
||||
84
wiki/log.md
84
wiki/log.md
@@ -1,3 +1,70 @@
|
||||
## [2026-05-05] ingest | CTP Topic 16 Cross-account Terraform modules
|
||||
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/03_Terraform/ctp-topic-16-cross-account-terraform-modules.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: Fibos 主讲，多账号 AWS 环境中跨账号 Terraform 模块的中心化部署方案——基于 Shared Account（共享账号）作为中转站，Jenkins + ECS Deploy Runner + Assume Role 三联动。核心机制：Jenkins 检测 `cross-account.json` 标记文件触发 ECS Deploy Runner，通过 Assume Role 访问目标账号的 TF state bucket accessor 和 cross-account ECS deploy runner role。三大目标：安全性（无 Workload 账号间直接信任）、自动化（Jenkins 自动识别模块类型）、可复用性（模块代码不硬编码特定账号角色）。
|
||||
- Concepts created: [[Cross-account-Terraform-Modules]]
|
||||
- Entities created: none（Gruntwork 已存在）
|
||||
- Source page: wiki/sources/ctp-topic-16-cross-account-terraform-modules.md
|
||||
- Notes: index.md 已替换占位符条目；overview.md 已新增独立段落（置于 ECS Deployment 和 Topic 21 之间）；Entity Jenkins/Fibos 提及次数不足建页阈值，以 wikilink 形式记录于 Source page；无实质性内容冲突，演进关系记录于 Contradictions 节
|
||||
|
||||
## [2026-05-05] ingest | Learning Sessions ECS Deployment using IAC - 20230808
|
||||
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/03_Terraform/learning-sessions-ecs-deployment-using-iac-20230808-183322-meeting-recording.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: JP 和 Raja M 主讲，CTP/SRE 团队通过 Terraform IaC 实现 ECS 容器化应用自动化部署——基于 Gruntwork 仓库构建 ECS 模块，支持 Docker 容器/EC2 部署；核心功能：自动扩缩容、自动故障恢复、金丝雀部署；Listener 集中管理方式；前置条件：VPC/ELB 安全组/EFS 卷挂载；集成 CloudWatch/Splunk/Grafana/Prometheus。ECS 作为 AWS 原生技术与 AWS 服务深度集成。
|
||||
- Concepts created: [[Canary-Deployment]], [[Infrastructure-as-Code]]
|
||||
- Entities created: [[Gruntwork]]
|
||||
- Source page: wiki/sources/learning-sessions-ecs-deployment-using-iac-20230808-183322-meeting-recording.md
|
||||
- Notes: index.md 已替换占位符条目；overview.md 已新增独立段落（置于 Terraform 工具选型后）；ECS 与 EKS 选型冲突记录于 Contradictions 节；JP 和 Raja M 各出现 1 次，不足独立 Entity 建页阈值，以 wikilink 形式记录于 Source page；无其他内容冲突
|
||||
- Conflicts: 与 [[ctp-topic-64-scaling-out-with-amazon-eks]] 在容器编排选型上的差异——ECS 强调 AWS 原生集成，EKS 强调可移植性，两者适用于不同场景但可互补
|
||||
|
||||
## [2026-05-05] ingest | CTP Topic 48 Terraform vs Terragrunt
|
||||
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/03_Terraform/ctp-topic-48-terraform-vs-terragrunt.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: Bob（AWS Solutions Architect）对比 Terraform 与 Terragrunt——Terraform（HashiCorp 出品）是云厂商无关的 Golang 应用，通过状态文件绑定期望状态与实际环境；Terragrunt 是轻量封装，贯彻 DRY 原则，管理 provider 和 remote_state 块减少跨环境重复声明。两者命令和语法高度一致，Terragrunt 通过减少硬编码优化大规模企业部署。辅助工具：Terraform Enterprise、Gruntwork、Atlantis、tfsec、Terratest
|
||||
- Concepts created: [[DRY Principle]], [[State-File-Management]]
|
||||
- Entities created: [[HashiCorp]], [[Terragrunt]], [[Atlantis]]
|
||||
- Entities updated: [[Terraform]], [[Gruntwork]]
|
||||
- Concepts updated: [[Infrastructure-as-Code]]
|
||||
- Source page: wiki/sources/ctp-topic-48-terraform-vs-terragrunt.md
|
||||
- Notes: 视频由 Gemini 摘要，原文状态为 "summarized (Gemini 摘要)"；来源 NAS 路径为 `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 48_ Terraform vs Terragrunt.mp4`
|
||||
|
||||
## [2026-05-05] ingest | Public Cloud Learning Sessions (OpenText) - AI Use Cases - 20241126 160106
|
||||
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/09_Serverless_AI/public-cloud-learning-sessions-opentext-ai-use-cases-20241126-160106-meeting-rec.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: AWS AI 专家 Stephen Frank 分享 Gen2 AI 发展驱动力（数据爆发+算力提升）、企业级 AI 应用场景（客户体验/洞察提取/流程自动化/内容生成）、AWS 三层产品战略（基础设施→Bedrock→AI 应用）、数据差异化策略（RAG/Fine-tuning/持续预训练）、Amazon Q 企业知识问答、负责任 AI 原则
|
||||
- Concepts linked: [[RAG]], [[Fine-Tuning]], [[Continued-Pre-Training]], [[Responsible-AI]]
|
||||
- Entities linked: [[AWS]], [[Amazon-Bedrock]], [[Amazon-SageMaker]], [[Amazon-Q]], [[Stephen-Frank]]
|
||||
- Source page: wiki/sources/public-cloud-learning-sessions-opentext-ai-use-cases-20241126-160106-meeting-rec.md
|
||||
- Notes: index.md 已替换占位符条目（日期修正为 2026-04-14）；overview.md 已新增独立段落（Serverless & AI 专题，置于提示工程后）；RAG/Fine-Tuning/Responsible-AI/Stephen-Frank/Amazon-Q/Amazon-SageMaker 在 wiki 中出现频次不足独立建页阈值，以 wikilink 形式记录于 Source page；无内容冲突
|
||||
- Conflicts: 无
|
||||
|
||||
## [2026-05-05] ingest | Public Cloud Learning Sessions (OpenText) - Event Driven Architecture Part 2 - 20240917
|
||||
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/09_Serverless_AI/public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: EDA 进阶实践——三组件（事件生产者/消费者/代理）、事件路由器（EventBridge/SNS）与事件存储（SQS/Kinesis）、编排与编排模式（Choreography vs Orchestration）、幂等性、事件排序、去中心化团队所有权、Fan-out 模式、竞争消费者模式、死信队列、EventBridge 最佳实践
|
||||
- Concepts updated: [[Event-Driven-Architecture]]（补充 Part 2 内容：EDA 三组件、编排模式对比、生产级最佳实践：幂等性/事件排序/团队独立性、扩展 Event Patterns：Fan-Out/Competing Consumer/DLQ）
|
||||
- Entities existing (no new): [[AWS]], [[Amazon-EventBridge]], [[Amazon-SQS]], [[Amazon-SNS]], [[AWS-Lambda]], [[AWS-Step-Functions]]
|
||||
- Source page: wiki/sources/public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091.md
|
||||
- Notes: index.md 已替换占位符条目（日期修正为 2026-05-05）；overview.md 已添加 Part 2 独立段落（新增于 Serverless 段落和 Part 1 之间），同时更新 Part 1 引用指向 Part 2；Event-Driven-Architecture 概念页已更新 sources + last_updated，新增 EDA 三组件/编排模式/生产级最佳实践内容，扩展 Event Patterns；Kinesis-Data-Streams 出现 1 次，不足独立建 Entity 阈值，以 wikilink 形式记录于 Concept 页
|
||||
- Conflicts: 与 [[ctp-topic-64-scaling-out-with-amazon-eks]] 在扩展方式上的差异——EDA 通过事件驱动异步扩展（消费者按需处理），EKS 通过容器编排横向扩展（Pod 副本数调整），两者适用于不同场景但可互补使用
|
||||
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/09_Serverless_AI/public-cloud-learning-sessions-opentext-event-driven-architecture-part-1-2024091.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: EDA 入门——AWS 解决方案架构师 Dr. Anil Giri 介绍 EventBridge/SQS/SNS 事件驱动架构与 Enterprise Integration Patterns；会议因 Teams 屏幕共享故障仅完成开场介绍，完整演示参见 Part 2
|
||||
- Concepts linked: [[Event-Driven-Architecture]], [[Enterprise-Integration-Patterns]], [[Amazon-EventBridge]], [[Amazon-SQS]], [[Amazon-SNS]]
|
||||
- Entities linked: [[Dr.-Anil-Giri]], [[AWS]], [[OpenText]], [[Micro-Focus]]
|
||||
- Source page: wiki/sources/public-cloud-learning-sessions-opentext-event-driven-architecture-part-1-2024091.md
|
||||
- Notes: index.md 已替换占位符条目（日期修正为 2026-04-19）；overview.md 已补充（Serverless & AI 专题段落新增，置于无服务器计算后）；Dr. Anil Giri/AWS/OpenText/Micro Focus 在 wiki 中出现频次不足独立建 Entity 页阈值，以 wikilink 形式记录于 Source page；EventBridge/SQS/SNS/Enterprise-Integration-Patterns 概念频次不足独立建 Concept 页阈值；已建立与 Part 2（public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091）、无服务器计算（public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee）的 Connections 关系；冲突记录与 ctp-topic-64-scaling-out-with-amazon-eks 的扩展方式差异已记录于 Contradictions 节
|
||||
- Conflicts: 与 [[ctp-topic-64-scaling-out-with-amazon-eks]] 在扩展方式上的差异——EDA 通过事件驱动异步扩展，EKS 通过容器编排横向扩展，两者适用于不同场景但可互补使用
|
||||
|
||||
## [2026-05-05] ingest | Public Cloud Learning Sessions - Serverless Computing - 20240903
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: AWS 无服务器计算深度解析——Lambda 事件驱动模型（同步/异步/事件源映射）、Step Functions 状态机编排（Standard/Express）、API Gateway（边缘优化/区域/私有）、SAM 本地开发和部署；Serverless 业务价值（快速上市/按需付费/自动扩展/内置安全）；AWS 与客户共担运维责任
|
||||
- Entities created: [[AWS-Lambda]], [[AWS-Step-Functions]], [[Amazon-API-Gateway]], [[SAM-Serverless-Application-Model]]
|
||||
- Concepts linked: [[Serverless-Computing]], [[Event-Driven-Architecture]]
|
||||
- Source page: wiki/sources/public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee.md
|
||||
- Notes: index.md 已更新（替换占位符条目，日期修正为 2026-04-14）；overview.md 已补充（Cloud Transformation & DevOps 章节新增独立段落，置于 AI/ML 入门与 CTP Topic 20 之间）；Entity 页均按字母顺序插入 index.md Entities 节；无内容冲突（Serverless-Computing 概念页已存在，内容一致）
|
||||
- Conflicts: 无
|
||||
|
||||
## [2026-05-05] ingest | Public Cloud Learning Sessions - Introduction to AI/ML with AWS
|
||||
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/09_Serverless_AI/public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machin.md
|
||||
- Status: ✅ 成功摄入
|
||||
@@ -2512,4 +2579,19 @@
|
||||
- overview.md 更新：新增条目于 Cloud Transformation & DevOps 章节 FinOps 知识链路
|
||||
- RightSizing/Cloud Cost Optimization 已通过 wikilink 嵌入 Source page
|
||||
- Key Entities: PCG (Platform Control Group) 已在 Wiki 中存在（ctp-topic-13），无需新建 Entity 页面
|
||||
- 冲突检测：未发现内容冲突，Contradictions 暂置空占位
|
||||
- 冲突检测：未发现内容冲突，Contradictions 暂置空占位
|
||||
|
||||
## [2026-05-06] ingest | Public Cloud Learning Sessions (OpenText) - Generative AI & Prompt Engineering - 20241112
|
||||
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/09_Serverless_AI/public-cloud-learning-sessions-opentext-generative-ai-prompt-engineering-2024111.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: AWS 生成式 AI 服务与提示工程实践，由 OpenText 技术客户经理 Shikad Holtzman（以色列）主讲——生成式 AI 四大价值路径、企业数据差异化核心洞见、Amazon Bedrock 全托管基础模型服务（RAG/微调/Agents/Guardrails）、Amazon Q 助手（企业版/开发者版）、AWS 专用芯片（Trainium/Inferentia）、提示工程四组件（指令/上下文/用户输入/输出指示器）和基础技巧（One-shot/Few-shot、Chain of Thoughts）
|
||||
- Concepts linked: [[RAG]], [[Prompt-Engineering]], [[Chain-of-Thought]], [[One-Shot-Prompting]], [[Few-Shot-Prompting]], [[Responsible-AI]], [[Guardrails-for-Amazon-Bedrock]]
|
||||
- Entities linked: [[Shikad-Holtzman]], [[Amazon-Bedrock]], [[Amazon-SageMaker]], [[Amazon-Q]], [[AWS-Trainium]], [[AWS-Inferentia]], [[AWS]]
|
||||
- Source page: wiki/sources/public-cloud-learning-sessions-opentext-generative-ai-prompt-engineering-2024111.md
|
||||
- Notes:
|
||||
- index.md 已更新：将原 expected placeholder 更新为正式条目（2026-04-19），补充中文摘要
|
||||
- overview.md 已更新：在 Cloud Transformation & DevOps 章节的 AI/ML 入门条目后新增独立段落，与 AI/ML 入门共同构成生成式 AI 知识链路
|
||||
- Key Concepts：RAG/Prompt-Engineering/Chain-of-Thought/Few-Shot-Prompting 频次不足独立建 Concept 页阈值，以 wikilink 形式记录于 Source page
|
||||
- Key Entities：Shikad Holtzman 仅出现 1 次，以 wikilink 形式记录于 Source page；Amazon Bedrock/Q/SageMaker 在同系列其他来源中提及频次不足独立建 Entity 页阈值
|
||||
- 同系列来源关联：已建立与 AI/ML 入门（public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machin）和无服务器计算（public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee）的 Connections 关系
|
||||
- 冲突检测：与 ctp-topic-64-scaling-out-with-amazon-eks 在扩展方式上的差异已记录于 Source page Contradictions（EDA 事件驱动 vs EKS 容器编排，适用于不同场景可互补）
|
||||
@@ -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]]（变更管理）共同构成完整的治理框架链条。
|
||||
|
||||
|
||||
55
wiki/sources/ctp-topic-16-cross-account-terraform-modules.md
Normal file
55
wiki/sources/ctp-topic-16-cross-account-terraform-modules.md
Normal file
@@ -0,0 +1,55 @@
|
||||
---
|
||||
title: "CTP Topic 16 Cross-account Terraform modules"
|
||||
type: source
|
||||
tags: [Terraform, Cross-Account, Modules, CTP, IaC, DevOps, AWS-Landing-Zone]
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/03_Terraform/ctp-topic-16-cross-account-terraform-modules]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：**跨账号 Terraform 模块的中心化部署方案**，解决多账号 AWS 环境中一个模块内跨账号创建资源的安全与自动化问题
|
||||
- 问题域：原有的 Gruntwork 流水线针对单账号设计，在多账号场景下存在安全风险（一账号被攻破可能波及全局）
|
||||
- 方法/机制：基于 **Shared Account（共享账号）** 的中心化部署架构，Jenkins + ECS Deploy Runner + Assume Role 三者联动
|
||||
- 结论/价值：实现安全性（账号间无直接信任关系）、自动化（Jenkins 自动识别跨账号模块）、可复用性（模块代码不硬编码特定账号角色）
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- **Shared Account 作为中转站**：Jenkins 托管在 Shared Account，当检测到 `cross-account.json` 标记文件时触发 ECS Deploy Runner
|
||||
- **Assume Role 双角色机制**：ECS Deploy Runner 通过 Assume Role 访问目标账号的两个角色——`TF state bucket accessor`（读取状态文件）和 `cross-account ECS deploy runner role`（执行资源部署）
|
||||
- **Blast Radius 控制**：避免 Workload 账号之间直接互访，权限控制在受严格审计的 Shared Account
|
||||
- **Terragrunt HCL 全局配置**：通过根目录 `terragrunt.hcl` 定义远程状态存储和角色切换逻辑，支持本地开发与 Jenkins 自动部署的差异化角色处理
|
||||
|
||||
## Key Quotes
|
||||
> "Cross-account Terraform Modules 指在一个模块内通过配置多个 Provider，实现在多个 AWS 账号中同时创建或管理资源的功能" — Fibos，核心概念定义
|
||||
> "Shared Account 是整个 Landing Zone 的核心管理账号，托管 Jenkins、镜像仓库等公共服务，并作为跨账号部署的信任源" — Fibos，架构定位
|
||||
> "ECS Deploy Runner 运行在 ECS 上的 Docker 容器，负责执行 Terraform plan 和 apply 命令，是流水线中的实际执行单元" — Fibos，EDR 定义
|
||||
|
||||
## Key Concepts
|
||||
- [[Cross-account Terraform Modules]]：在一个 Terraform 模块中通过配置多个 Provider，实现在多个 AWS 账号中同时创建或管理资源的功能
|
||||
- [[Shared Account]]：Landing Zone 核心管理账号，托管 Jenkins 及公共服务，作为跨账号部署的信任源
|
||||
- [[ECS Deploy Runner]]：运行在 ECS 上的 Docker 容器，负责执行 Terraform plan/apply，是流水线的实际执行单元
|
||||
- [[TF State Bucket Accessor]]：专门定义的 IAM 角色，仅允许部署工具访问目标账号 S3 桶中的 Terraform 状态文件
|
||||
- [[Cross-account ECS Deploy Runner Role]]：部署在目标账号中的角色，允许 Shared Account 的执行器通过 Assume Role 获取资源创建权限
|
||||
- [[cross-account.json]]：约定俗成的标记文件，放置于模块目录中，用于告知 Jenkins 该模块需要调用跨账号部署逻辑
|
||||
- [[Root Terragrunt HCL]]：全局 Terragrunt 配置文件，定义远程状态存储和角色切换逻辑
|
||||
|
||||
## Key Entities
|
||||
- **Fibos**：主讲人，分享了团队基于 Shared Account 的跨账号 Terraform 部署方案
|
||||
- **Gruntwork**：参考架构来源，原有 Gruntwork 流水线主要针对单账号设计
|
||||
- **Jenkins**：CI/CD 引擎，托管在 Shared Account，负责检测模块类型并触发部署流程
|
||||
- **AWS Landing Zone**：多账号架构框架，Shared Account + Workload Account 的分层设计
|
||||
|
||||
## Connections
|
||||
- [[ctp-topic-9-ci-cd-with-gruntwork]] ← foundation ← [[ctp-topic-16-cross-account-terraform-modules]]
|
||||
- [[ECS Deploy Runner]] ← depends_on ← [[Shared Account]]
|
||||
- [[Cross-account Terraform Modules]] ← uses ← [[ECS Deploy Runner]]
|
||||
- [[ECS Deploy Runner]] ← assumes ← [[Cross-account ECS Deploy Runner Role]]
|
||||
- [[ECS Deploy Runner]] ← reads_state ← [[TF State Bucket Accessor]]
|
||||
- [[Root Terragrunt HCL]] ← configures ← [[Cross-account Terraform Modules]]
|
||||
- [[ctp-topic-48-terraform-vs-terragrunt]] ← related ← [[Root Terragrunt HCL]]
|
||||
- [[AWS-Landing-Zone]] ← enables ← [[Shared Account]]
|
||||
|
||||
## Contradictions
|
||||
- 与 [[ctp-topic-9-ci-cd-with-gruntwork]]（单账号 Gruntwork 流水线）：原有 Gruntwork 流水线主要针对单账号设计，不处理跨账号场景；本方案通过 Shared Account 中心化架构扩展支持多账号，同时保留 Gruntwork 模块复用优势。两者为演进关系而非冲突。
|
||||
- 与 [[ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments]]（Atlantis 替代 Jenkins）：Atlantis 在 merge 前应用变更，每个 Landing Zone 部署单台 EC2 实例；本方案的 ECS Deploy Runner 运行在容器中，更适合跨账号大规模部署。Atlantis 的跨账号访问通过各账户 IAM 角色实现，与本方案 Assume Role 机制类似，但执行载体不同。
|
||||
55
wiki/sources/ctp-topic-48-terraform-vs-terragrunt.md
Normal file
55
wiki/sources/ctp-topic-48-terraform-vs-terragrunt.md
Normal file
@@ -0,0 +1,55 @@
|
||||
---
|
||||
title: "CTP Topic 48 Terraform vs Terragrunt"
|
||||
type: source
|
||||
tags:
|
||||
- Terraform
|
||||
- Terragrunt
|
||||
- IaC
|
||||
- DevOps
|
||||
- CTP
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/03_Terraform/ctp-topic-48-terraform-vs-terragrunt.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：Terraform 与 Terragrunt 的对比选型，涵盖企业级 IaC 实践
|
||||
- 问题域：多环境配置管理、基础设施代码复用、状态文件管理
|
||||
- 方法/机制：Terraform 作为核心 IaC 工具（云厂商无关），Terragrunt 作为 Terraform 的 DRY 封装层，处理跨环境变量和远程状态的重复声明
|
||||
- 结论/价值：Terraform 与 Terragrunt 命令和语法高度一致，但 Terragrunt 通过减少硬编码、提升可复用性来优化大规模企业部署；两者可互补使用
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- Terraform（HashiCorp 出品）通过状态文件将期望状态与现有环境绑定，企业级使用须将状态文件存储在安全可访问的位置
|
||||
- Terragrunt 是 Terraform 的轻量封装，贯彻 DRY 原则，通过管理 provider 和 remote_state 块减少跨环境的重复声明
|
||||
- Terraform Enterprise 提供带 workspace 的 CI 平台，Gruntwork 提供预建可定制模块，Atlantis 实现 Git 驱动的自动化部署
|
||||
- tfsec 用于静态代码安全分析，Terratest 用于基础设施测试自动化
|
||||
|
||||
## Key Quotes
|
||||
> "Terraform ties the desired state to the existing environment using a state file. For enterprise-scale use, storing this file in a safe, accessible location is crucial." — Bob, AWS Solutions Architect
|
||||
> "Terragrunt offers a way to use information in a repeatable way without hard coding values." — Bob
|
||||
> "All Terraform commands work with Terragrunt; a Terraform plan becomes a Terragrunt plan." — Bob
|
||||
|
||||
## Key Concepts
|
||||
- [[Infrastructure As Code]]：通过代码定义和版本控制基础设施资源的实践
|
||||
- [[DRY Principle]]：Don't Repeat Yourself — 避免重复配置，通过抽象层复用
|
||||
- [[State File Management]]：Terraform 用状态文件绑定期望状态与实际环境
|
||||
- [[IaC Testing]]：用 Terratest 等工具对基础设施代码进行自动化测试
|
||||
|
||||
## Key Entities
|
||||
- [[HashiCorp]]：Terraform 创立公司，提供多云基础设施编排工具
|
||||
- [[Gruntwork]]：提供预建可定制的 Terraform 模块和 Terraform 原生 AWS Landing Zone
|
||||
- [[Atlantis]]：将 Terraform 与 GitHub 集成的开源 CI/CD 工具
|
||||
- [[Terraform]]：云厂商无关的基础设施即代码工具
|
||||
- [[Terragrunt]]：Terraform 的 DRY 封装层，管理多环境配置
|
||||
|
||||
## Connections
|
||||
- [[Terraform]] ← uses ← [[State File Management]]
|
||||
- [[Terragrunt]] ← wraps ← [[Terraform]]
|
||||
- [[Terraform]] ← provided_by ← [[HashiCorp]]
|
||||
- [[Gruntwork]] ← provides_modules_for ← [[Terraform]]
|
||||
- [[Atlantis]] ← integrates_with ← [[Terraform]]
|
||||
- [[Terraform]] ← related_concept ← [[Infrastructure As Code]]
|
||||
|
||||
## Contradictions
|
||||
- 暂无发现与其他 Wiki 页面的直接冲突
|
||||
@@ -0,0 +1,52 @@
|
||||
---
|
||||
title: "Learning Sessions ECS Deployment using IAC - 20230808"
|
||||
type: source
|
||||
tags: [AWS, ECS, IaC, Terraform, CTP]
|
||||
date: 2023-08-08
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/03_Terraform/learning-sessions-ecs-deployment-using-iac-20230808-183322-meeting-recording.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：通过 IaC（Terraform）实现 ECS（Elastic Container Service）容器化应用的自动化部署，由 JP 和 Raja M 主讲
|
||||
- 问题域：企业在云端部署容器化应用时面临的不可预测性、敏捷性需求，以及 ECS 与 EKS/Kubernetes 的选型权衡
|
||||
- 方法/机制：CTP/SRE 团队基于 Gruntwork 仓库构建的 Terraform ECS 模块，支持 Docker 容器创建、自动扩缩容、自动故障恢复和金丝雀部署；通过 Listener 方式集中管理 ECS；配置文件支持 YAML/JSON；集成 CloudWatch、Splunk、Grafana、Prometheus
|
||||
- 结论/价值：ECS 作为 AWS 原生技术，与 AWS 服务深度集成，适合追求简单性和 AWS 紧密集成的场景；Terraform IaC 模块化封装降低了部署复杂度
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- JP 指出行业面临不可预测性和敏捷性挑战，企业必须在这些挑战中生存，而这一切由代码驱动（"Businesses have to thrive in the middle of all these challenges and it is forged by code."）
|
||||
- 动态扩缩容对于不可预测的负载模式至关重要，技术必须持续演进以应对
|
||||
- ECS (Elastic Container Services) 是 AWS 专有技术，与 AWS 服务深度集成，相比 EKS 或原生 Kubernetes 有其独特优势和挑战
|
||||
- CTP/SRE 团队在 Gruntwork 仓库基础上构建了 ECS 模块，将 Docker 容器作为逻辑单元创建，支持 EC2 实例或目标部署
|
||||
- ECS 模块实现了 Listener 方式集中管理，因为许多产品团队从 Gruntwork 下载代码后本地使用
|
||||
- 使用模块的前置条件包括：VPC、ELB 安全组、EFS 卷挂载
|
||||
|
||||
## Key Quotes
|
||||
> "Businesses have to thrive in the middle of all these challenges and it is forged by code." — JP，阐述企业如何在云转型挑战中通过代码驱动适应
|
||||
> "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，解释为何 CTP 团队实现 Listener 集中管理方式
|
||||
|
||||
## Key Concepts
|
||||
- [[Infrastructure-as-Code]]：Terraform IaC 驱动 ECS 部署的核心方法论
|
||||
- [[ECS-Module-Deployment]]：CTP/SRE 团队基于 Gruntwork 构建的 ECS 自动化部署模块
|
||||
- [[Listener-Approach]]：ECS 集中管理方式，避免各产品团队重复下载使用 Gruntwork 代码
|
||||
- [[Canary-Deployment]]：ECS 模块支持的金丝雀部署策略
|
||||
|
||||
## Key Entities
|
||||
- [[AWS]]：Amazon Web Services，提供 ECS 容器服务及配套生态（CloudWatch、VPC、ELB、EFS）
|
||||
- [[Gruntwork]]：IaC 基础设施代码库，CTP 的 ECS 模块基于 Gruntwork 仓库构建
|
||||
- [[CTP]]（Cloud Transformation Programme）：云转型计划，每周定期举办 Learning Sessions 学习会议
|
||||
- [[JP]]：演讲者之一，讲解 ECS 的业务和技术背景
|
||||
- [[Raja-M]]：演讲者之一，详细介绍 CTP 和 SRE 团队开发的 ECS 模块
|
||||
|
||||
## Connections
|
||||
- [[ctp-topic-70-eks-deployment-using-iac]] ← extends ← [[Infrastructure-as-Code]]（同一 IaC 主题，EKS 与 ECS 两条路径）
|
||||
- [[ctp-topic-9-ci-cd-with-gruntwork]] ← builds_on ← [[Gruntwork]]（Gruntwork CI/CD 实践是 ECS 模块的基础）
|
||||
- [[ctp-topic-33-an-introduction-to-gitops]] ← related_to ← [[Infrastructure-as-Code]]（GitOps 与 IaC 协同）
|
||||
|
||||
## Contradictions
|
||||
- 与 [[ctp-topic-64-scaling-out-with-amazon-eks]] 在容器编排选型上的差异：
|
||||
- 冲突点：ECS 与 EKS 哪个更适合企业容器化部署
|
||||
- 当前观点：ECS 作为 AWS 原生技术与 AWS 服务深度集成，适合追求简单性和紧密集成的场景
|
||||
- 对方观点：EKS 提供更强的可移植性和 Kubernetes 生态系统支持，适合需要多云或混合云策略的场景
|
||||
- 注：两者并非互斥，ECS 和 EKS 可根据具体场景互补使用
|
||||
@@ -0,0 +1,54 @@
|
||||
---
|
||||
title: "Public Cloud Learning Sessions (OpenText) - AI Use Cases - 20241126 160106"
|
||||
type: source
|
||||
tags:
|
||||
- AI
|
||||
- Use-Cases
|
||||
- OpenText
|
||||
- AWS
|
||||
- Generative-AI
|
||||
date: 2024-11-26
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/09_Serverless_AI/public-cloud-learning-sessions-opentext-ai-use-cases-20241126-160106-meeting-rec.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：AWS AI 专家 Stephen Frank 分享 Gen2 AI（生成式 AI）的发展驱动力、企业级应用场景及 AWS 三层产品战略
|
||||
- 问题域：企业软件公司如何利用生成式 AI 实现差异化竞争，AI 数据策略选择（RAG / Fine-tuning / Continued Pre-training）
|
||||
- 方法/机制：AWS 三层产品架构（基础设施 → Amazon Bedrock → AI 应用）；Amazon Q 企业知识问答；数据与 AI 模型集成的三种方法
|
||||
- 结论/价值：数据是差异化关键；RAG 可在无需重训练的情况下连接自有业务数据；实施 AI 需要培育实验文化、灵活选择模型、重视安全治理与合规
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- 自 2000 年代以来数据量爆发式增长，加上算力提升，驱动了 Gen2 AI 的崛起
|
||||
- Amazon 在核心产品和服务中应用 AI/ML 已达 25 年
|
||||
- 生成式 AI 应用的差异化关键在于数据——通过 RAG/Fine-tuning/持续预训练与现有业务数据集成
|
||||
- AWS 三层产品战略：基础设施层（基础模型训练/推理）→ Amazon Bedrock（旗舰 API 访问）→ 即用型 AI 应用
|
||||
- Amazon Bedrock 确保用户数据与提示词不与第三方模型提供商共享，符合 GDPR 合规要求
|
||||
- 负责任 AI 的核心原则：公平性（Fairness）、可解释性（Explainability）、透明度（Transparency）
|
||||
|
||||
## Key Quotes
|
||||
> "Data is key to differentiation, as generative AI applications integrate with existing business data to control outcomes." — Stephen Frank, AWS AI Specialist
|
||||
> "When implementing your services, we do have to look at this more holistically." — Stephen Frank, AWS AI Specialist
|
||||
|
||||
## Key Concepts
|
||||
- [[RAG]]：将生成式 AI 应用与企业现有业务数据集成，无需重训练即可控制输出结果
|
||||
- [[Fine-Tuning]]：通过领域数据微调基础模型，提升特定任务表现
|
||||
- [[Continued-Pre-Training]]：持续预训练，在基础模型上继续训练以扩展知识
|
||||
- [[Responsible-AI]]：公平性、可解释性、透明度的 AI 实施原则
|
||||
|
||||
## Key Entities
|
||||
- [[AWS]]：亚马逊云科技，提供三层 AI 产品战略
|
||||
- [[Amazon-Bedrock]]：AWS 旗舰生成式 AI 服务，提供 API 访问多种基础模型（Anthropic/Titan 等），保证数据不与第三方共享
|
||||
- [[Amazon-SageMaker]]：AWS 全托管机器学习平台，面向数据科学家和平台工程师
|
||||
- [[Amazon-Q]]：AWS 预构建 AI 系统，支持知识摘要、内容创建和洞察提取，自然语言连接多种数据源
|
||||
- [[Stephen-Frank]]：AWS AI 专家，主讲本次会议
|
||||
|
||||
## Connections
|
||||
- [[public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machin]] ← extends ← [[public-cloud-learning-sessions-opentext-generative-ai-prompt-engineering-2024111]]
|
||||
- [[Amazon-Bedrock]] ← is part of ← [[AWS]] AI 三层产品战略
|
||||
- [[Amazon-Q]] ← is part of ← [[AWS]] AI 三层产品战略
|
||||
- [[RAG]] ← depends_on ← [[Fine-Tuning]]
|
||||
|
||||
## Contradictions
|
||||
- 无明显内容冲突。本来源与 [[public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machin]] 和 [[public-cloud-learning-sessions-opentext-generative-ai-prompt-engineering-2024111]] 共同构成 Serverless & AI 知识链路，内容互补而非冲突。
|
||||
@@ -0,0 +1,51 @@
|
||||
---
|
||||
title: "Public Cloud Learning Sessions (OpenText) - Event Driven Architecture Part 1"
|
||||
type: source
|
||||
tags:
|
||||
- EDA
|
||||
- Event-Driven
|
||||
- AWS
|
||||
- Architecture
|
||||
- OpenText
|
||||
date: 2024-09-17
|
||||
last_updated: 2026-05-05
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/09_Serverless_AI/public-cloud-learning-sessions-opentext-event-driven-architecture-part-1-2024091]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：事件驱动架构（Event-Driven Architecture，EDA）入门与概述
|
||||
- 问题域：企业级云架构中的异步通信与松耦合集成设计
|
||||
- 方法/机制：主讲人 Dr. Anil Giri（AWS 解决方案架构师）介绍通过 Amazon EventBridge、SQS 和 SNS 探索事件驱动架构；会议录音包含开场介绍与主持人协调过程（演示过程中遭遇 Teams 屏幕共享技术故障）
|
||||
- 结论/价值：帮助参与者掌握企业级集成模式（Enterprise Integration Patterns），学习实用的云计算技能，为解决现实世界业务挑战打下基础
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- Amazon EventBridge、SQS 和 SNS 是实现事件驱动架构的核心 AWS 服务
|
||||
- 事件驱动架构能够帮助企业实现松耦合、可扩展的系统集成
|
||||
- 企业级集成模式（Enterprise Integration Patterns）是构建可靠分布式系统的理论基础
|
||||
|
||||
## Key Quotes
|
||||
> "探索企业级集成模式，掌握实用的云计算技能，通过使用 Amazon EventBridge、SQS 和 SNS 探索事件驱动架构，以解决现实世界中的业务挑战。" — Dr. Anil Giri，AWS 解决方案架构师，开场学习目标介绍
|
||||
|
||||
> "Give me a second. I'm trying to log in. Just give me a second." — 会议期间 Teams 屏幕共享故障场景
|
||||
|
||||
## Key Concepts
|
||||
- [[Event-Driven-Architecture]]：一种软件架构范式，其中组件通过事件的产生、消费和响应进行通信，强调松耦合
|
||||
- [[Enterprise-Integration-Patterns]]：企业集成模式，是构建可靠分布式系统时常见问题的可复用解决方案集合
|
||||
- [[Amazon-EventBridge]]：AWS 无服务器事件总线服务，用于连接应用程序与来自各种来源的事件
|
||||
- [[Amazon-SQS]]：AWS 简单队列服务，提供完全托管的消息队列服务
|
||||
- [[Amazon-SNS]]：AWS 简单通知服务，提供发布/订阅式的消息通知服务
|
||||
|
||||
## Key Entities
|
||||
- [[Dr.-Anil-Giri]]：AWS 解决方案架构师，Event Driven Architecture 系列主讲人
|
||||
- [[AWS]]：Amazon Web Services，云服务提供商，EventBridge/SQS/SNS 的托管方
|
||||
- [[OpenText]]：会议主办方，Public Cloud Learning Sessions 系列活动的组织者
|
||||
- [[Micro-Focus]]：原公司名称，现已被 OpenText 收购，学习会话的参与群体来源
|
||||
|
||||
## Connections
|
||||
- [[public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091]] ← part_of ← [[public-cloud-learning-sessions-opentext-event-driven-architecture-part-1-2024091]]（Part 1 与 Part 2 为同一系列，Part 2 包含具体演示内容）
|
||||
- [[public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee]] ← related_to ← [[Event-Driven-Architecture]]（Serverless 与 EDA 高度相关，Serverless 计算天然适合事件驱动场景）
|
||||
|
||||
## Contradictions
|
||||
- 与 [[ctp-topic-64-scaling-out-with-amazon-eks]] 在扩展方式上的差异——EDA 通过事件驱动异步扩展，EKS 通过容器编排横向扩展，两者适用于不同场景但可互补使用
|
||||
@@ -0,0 +1,62 @@
|
||||
---
|
||||
title: "Public Cloud Learning Sessions (OpenText) - Event Driven Architecture Part 2"
|
||||
type: source
|
||||
tags:
|
||||
- EDA
|
||||
- Event-Driven
|
||||
- Architecture
|
||||
- OpenText
|
||||
date: 2024-09-17
|
||||
last_updated: 2026-05-05
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/09_Serverless_AI/public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：事件驱动架构（EDA）进阶实践——最佳实践、团队独立性、常见消息模式
|
||||
- 问题域：如何在企业云环境中设计、落地和治理事件驱动架构
|
||||
- 方法/机制：Dr. Anil Giri（AWS 解决方案架构师）详解 EDA 三组件（事件生产者/消费者/代理）、事件路由器（EventBridge/SNS）与事件存储（SQS/Kinesis）、编排与编排模式（Choreography vs Orchestration）、幂等性、事件排序、团队去中心化所有权
|
||||
- 结论/价值：帮助团队掌握 EDA 生产级最佳实践，在保证弹性和可扩展性的同时实现团队独立自治
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- 事件代理分两类：事件路由器（EventBridge/SNS，按规则过滤路由）和事件存储（SQS/Kinesis，由消费者自己过滤）
|
||||
- EventBridge 比 SNS 功能更丰富，支持跨 AWS 服务的事件触发和工作流编排
|
||||
- 幂等性（Idempotency）是处理 EDA 消息重复的关键机制，AWS Lambda 异步调用会自动重试
|
||||
- SQS FIFO 和 Kinesis Data Streams 可保证事件顺序；标准 SQS 和 EventBridge 支持乱序处理
|
||||
- 团队独立性应采用去中心化所有权，云卓越中心（Cloud CoE）提供基础设防，团队自主消费事件
|
||||
- Fan-out 模式通过 SNS 主题或 EventBridge 规则将事件分发到不同团队
|
||||
|
||||
## Key Quotes
|
||||
> "Event is nothing but it's like a change in the state or an update." — Dr. Anil Giri，EDA 定义
|
||||
|
||||
> "Everything fails every time means like whatever you have designed and whatever workload you is running it may fail any time." — 容错设计哲学
|
||||
|
||||
## Key Concepts
|
||||
- [[Event-Driven-Architecture]]：一种软件架构范式，通过事件的生产、消费和响应实现松耦合通信
|
||||
- [[Choreography]]：编排模式的一种，各微服务自主通信，无需中央协调者
|
||||
- [[Orchestration]]：编排模式的一种，通过中央协调者（如 AWS Step Functions）控制工作流步骤
|
||||
- [[Idempotency]]：幂等性——同一操作执行一次或多次产生相同结果的特性
|
||||
- [[Fan-Out-Pattern]]：一对多消息分发模式，通过 SNS 主题或 EventBridge 规则将事件广播给多个消费者
|
||||
- [[Competing-Consumer-Pattern]]：竞争消费者模式，同一时间只有一个消费者可处理消息（SQS 实现）
|
||||
- [[Dead-Letter-Queue-DLQ]]：死信队列，用于处理失败事件，防止消息丢失
|
||||
|
||||
## Key Entities
|
||||
- [[AWS]]：Amazon Web Services，EventBridge/SQS/SNS/Lambda/Kinesis/AWS Step Functions 的托管方
|
||||
- [[Amazon-EventBridge]]：AWS 事件路由器，支持规则过滤、跨服务触发、Schema 注册
|
||||
- [[Amazon-SQS]]：AWS 消息队列服务，分标准队列（乱序/高效）和 FIFO 队列（有序/Exactly-Once）
|
||||
- [[Amazon-SNS]]：AWS 发布/订阅通知服务，实现 Fan-out 分发
|
||||
- [[AWS-Lambda]]：AWS 无服务器函数，EDA 的核心事件消费者，异步调用自动重试
|
||||
- [[AWS-Step-Functions]]：AWS 状态机编排服务，实现 Orchestration 模式
|
||||
- [[Kinesis-Data-Streams]]：AWS 流数据服务，支持事件持久化和有序处理
|
||||
- [[Dr.-Anil-Giri]]：AWS 解决方案架构师，Event Driven Architecture 系列主讲人
|
||||
- [[OpenText]]：会议主办方，Public Cloud Learning Sessions 系列活动的组织者
|
||||
|
||||
## Connections
|
||||
- [[public-cloud-learning-sessions-opentext-event-driven-architecture-part-1-2024091]] ← part_of ← [[public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091]]（Part 1 与 Part 2 为同一系列，Part 2 补充具体演示内容）
|
||||
- [[public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee]] ← related_to ← [[Event-Driven-Architecture]]（Serverless 天然适合事件驱动，Lambda 是 EDA 的核心执行单元）
|
||||
- [[Event-Driven-Architecture]] ← depends_on ← [[Amazon-EventBridge]]（EventBridge 是 AWS EDA 的核心事件总线）
|
||||
- [[Event-Driven-Architecture]] ← uses ← [[Idempotency]]（幂等性是 EDA 生产级落地的必要保障）
|
||||
|
||||
## Contradictions
|
||||
- 与 [[ctp-topic-64-scaling-out-with-amazon-eks]] 在扩展方式上的差异——EDA 通过事件驱动异步扩展（消费者按需处理），EKS 通过容器编排横向扩展（Pod 副本数调整），两者适用于不同场景但可互补使用
|
||||
@@ -0,0 +1,66 @@
|
||||
---
|
||||
title: "Public Cloud Learning Sessions (OpenText) - Generative AI & Prompt Engineering - 20241112"
|
||||
type: source
|
||||
tags:
|
||||
- Generative-AI
|
||||
- Prompt-Engineering
|
||||
- OpenText
|
||||
- AWS
|
||||
date: 2024-11-12
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/09_Serverless_AI/public-cloud-learning-sessions-opentext-generative-ai-prompt-engineering-2024111.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：AWS 生成式 AI 服务与提示工程基础，由 OpenText 技术客户经理 Shikad Holtzman 主讲
|
||||
- 问题域：企业如何在 AWS 上构建有业务价值的生成式 AI 应用
|
||||
- 方法/机制：Amazon Bedrock 全托管基础模型服务、RAG（检索增强生成）、微调、持续预训练、Amazon Q 助手、提示工程技巧
|
||||
- 结论/价值：企业数据是差异化关键，通过 Bedrock 连接自有数据，无需重训练即可构建专属生成式 AI 应用；提示工程通过清晰指令、上下文、示例和链式思维可显著提升 LLM 输出质量
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- Shikad Holtzman（以色列技术客户经理）通过 AWS 生成式 AI 堆栈三层架构（基础设施/服务/应用）介绍了创新机会与行业通用场景
|
||||
- 生成式 AI 通过创造新体验、提升员工生产力、提取洞察、激发创造力四大路径为企业创造价值；应用场景涵盖客服聊天机器人、代码生成摘要、文档处理和图像生成
|
||||
- 企业数据是生成式 AI 应用从通用走向专属、产生实际业务价值的关键差异化因素
|
||||
- RAG（检索增强生成）是成本最低、最快速的定制化方法，连接多数据源无需重训练模型；微调通过标注示例重训练模型；持续预训练用无标签数据适配特定领域
|
||||
- Amazon Bedrock 是全托管服务，提供来自 Anthropic、Meta、Amazon（Titan）的多种基础模型（含多模态和图像模型），并内置 RAG 知识库、微调、Agents 和 Responsible AI 能力，且用户数据和提示不会与模型提供商共享
|
||||
- Amazon Bedrock Guardrails 允许用户根据自身策略过滤有害内容
|
||||
- Amazon Q 分为企业版（连接多数据源进行搜索/摘要/洞察提取，维持现有权限）和开发者版（专注代码生成、单元测试和代码迁移）
|
||||
- 提示工程是创建、设计和优化提示词以引导 LLM 响应的过程，需清晰、准确、具体，遵循迭代测试优化；提示包含指令、上下文、用户输入和输出指示器四部分
|
||||
- 少样本提示（One-shot/Few-shot）通过提供示例帮助模型理解任务模式；链式思维（Chain of Thoughts）通过逐步推理引导模型解决复杂任务
|
||||
|
||||
## Key Quotes
|
||||
> "Your data is your differentiator and it is what makes the difference between generic application to a specific application that can actually bring business to your value." — Shikad Holtzman，强调企业数据是生成式 AI 差异化的核心
|
||||
|
||||
> "None of your data nor not the prompts, not the data that you are using for customizing the model is being shared with the model providers." — 强调 Amazon Bedrock 的数据隔离承诺
|
||||
|
||||
## Key Concepts
|
||||
- [[RAG]]：检索增强生成，通过连接外部数据源，无需重训练即可让基础模型回答特定领域问题，是成本最低的定制化路径
|
||||
- [[Prompt-Engineering]]：提示工程，通过设计清晰指令、上下文、示例和输出指示器引导 LLM 生成准确相关响应的技术和迭代过程
|
||||
- [[Chain-of-Thought]]：链式思维，一种提示工程技巧，通过让模型展示逐步推理过程来提升复杂任务表现
|
||||
- [[One-Shot-Prompting]]：单样本提示，一种提示技巧，通过提供一个示例帮助模型理解任务格式和期望
|
||||
- [[Few-Shot-Prompting]]：少样本提示，通过提供多个示例（通常2-5个）让模型从示例中学习模式和规则
|
||||
- [[Responsible-AI]]：负责任 AI，Amazon Bedrock 内置的能力，包括内容过滤和道德准则实施
|
||||
- [[Guardrails-for-Amazon-Bedrock]]：Bedrock 护栏，允许用户配置自定义策略过滤有害内容的基础安全功能
|
||||
|
||||
## Key Entities
|
||||
- [[Shikad-Holtzman]]：OpenText 技术客户经理（驻以色列），本次学习会议讲师，专注于 AWS 生成式 AI 应用与创新机会分享
|
||||
- [[Amazon-Bedrock]]：AWS 全托管基础模型服务，提供多提供商模型（Anthropic/Amazon Titan/Meta），内置 RAG、微调、Agents 和 Responsible AI 能力
|
||||
- [[Amazon-SageMaker]]：AWS 托管服务，覆盖基础模型构建、训练和部署全生命周期；SageMaker JumpStart 提供公开可用基础模型和第三方模型访问
|
||||
- [[Amazon-Q]]：AWS AI 助手，分企业版（多数据源连接、搜索摘要）和开发者版（代码生成、单元测试、代码迁移）
|
||||
- [[AWS-Trainium]]：AWS 专用训练芯片，用于基础模型训练
|
||||
- [[AWS-Inferentia]]：AWS 专用推理芯片，用于模型推理部署
|
||||
- [[AWS]]：Amazon Web Services，OpenText Cloud 转型计划的云服务提供商
|
||||
|
||||
## Connections
|
||||
- [[Amazon-Bedrock]] ← extends ← [[Foundation-Models]]
|
||||
- [[RAG]] ← part_of ← [[Amazon-Bedrock]]
|
||||
- [[Amazon-Q]] ← part_of ← [[AWS-Generative-AI-Stack]]
|
||||
- [[Prompt-Engineering]] ← uses ← [[Chain-of-Thought]]
|
||||
- [[Prompt-Engineering]] ← uses ← [[Few-Shot-Prompting]]
|
||||
- [[Amazon-SageMaker]] ← part_of ← [[AWS-Generative-AI-Stack]]
|
||||
- [[public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machin]] ← related ← [[public-cloud-learning-sessions-opentext-generative-ai-prompt-engineering-2024111]]（同属 AWS AI/ML 入门系列）
|
||||
- [[public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee]] ← related ← [[public-cloud-learning-sessions-opentext-generative-ai-prompt-engineering-2024111]]（同属 OpenText Serverless & AI 专题）
|
||||
|
||||
## Contradictions
|
||||
- 与 [[ctp-topic-64-scaling-out-with-amazon-eks]] 在扩展方式上的差异：EDA 通过事件驱动异步扩展，EKS 通过容器编排横向扩展，两者适用于不同场景但可互补使用
|
||||
@@ -0,0 +1,62 @@
|
||||
---
|
||||
title: "Public Cloud Learning Sessions - Serverless Computing - 20240903"
|
||||
type: source
|
||||
tags:
|
||||
- Serverless
|
||||
- AWS
|
||||
- Lambda
|
||||
- Step-Functions
|
||||
- API-Gateway
|
||||
- OpenText
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/09_Serverless_AI/public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：AWS 无服务器计算（Serverless Computing），聚焦 AWS Lambda、Step Functions 和 API Gateway
|
||||
- 问题域：企业如何在云环境中简化应用管理、降低运维负担、加快上市时间
|
||||
- 方法/机制：Lambda 事件驱动函数 → Step Functions 工作流编排 → API Gateway API 管理，AWS 与客户共担运维责任（AWS 管基础设施，客户管代码）
|
||||
- 结论/价值：Serverless 模式通过"按需付费、自动扩展、内置安全"实现更快的市场响应和更低的 TCO
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- AWS Lambda 将运维任务（负载均衡、自动扩展、安全）转移给云厂商，使开发团队专注业务逻辑
|
||||
- Lambda 函数支持同步、异步、事件源映射三种触发模式，可精细控制执行行为
|
||||
- Lambda 权限模型分为执行角色（决定函数能做什么）和资源策略（决定谁能触发函数）
|
||||
- Step Functions 提供 Standard 和 Express 两种工作流类型，分别适用于长时任务和高频场景
|
||||
- SAM（Serverless Application Model）基于 CloudFormation 构建，支持本地开发和测试 Lambda 函数
|
||||
- Lambda Layers 允许跨函数共享公共代码，提高复用率；ARM64 架构提供更优性价比
|
||||
|
||||
## Key Quotes
|
||||
> "Whenever you see that you have written code and you want that this code is final, you can publish as a new version." — Lambda 版本发布的核心理念
|
||||
|
||||
## Key Concepts
|
||||
- [[Serverless-Computing]]：将运维任务（负载均衡、自动扩展、安全补丁）转移给云厂商，使开发团队专注业务代码，无需管理服务器
|
||||
- [[Event-Driven-Architecture]]：Lambda 函数由事件触发——状态的任何变化即为事件，是 Serverless 的核心执行模型
|
||||
- [[Lambda-Permissions-Model]]：执行角色（Execution Role）决定函数能调用哪些 AWS 资源，资源策略（Resource-Based Policy）决定谁能触发该函数，两者分离实现最小权限原则
|
||||
- [[Step-Functions]]：无服务器工作流编排服务，基于状态机协调多个 AWS 服务，支持 Standard（长时）和 Express（高频）两种工作流类型
|
||||
- [[API-Gateway]]：托管式 API 创建、发布和安全服务，提供边缘优化（Edge-Optimized）、区域（Regional）和私有（Private）三种部署选项
|
||||
- [[SAM-Serverless-Application-Model]]：基于 CloudFormation 的无服务器应用开发工具，支持本地测试和部署 Lambda 函数
|
||||
|
||||
## Key Entities
|
||||
- [[AWS Lambda]]：AWS 无服务器计算核心服务，开发者只需提供业务逻辑，AWS 负责其余所有运维工作
|
||||
- [[AWS Step Functions]]：AWS 无服务器工作流编排服务，用于协调多个 Lambda 函数和 AWS 服务的执行顺序
|
||||
- [[Amazon API Gateway]]：AWS 托管式 API 管理服务，用于创建、发布和维护安全的企业级 API
|
||||
- [[Amazon EventBridge]]：AWS 事件总线服务，用于在应用程序之间路由事件（属于 AWS Serverless 服务组合）
|
||||
- [[AWS Fargate]]：AWS 无服务器容器计算服务（与 Lambda 互补，提供容器层的 Serverless 选项）
|
||||
- [[Amazon Q]]：AWS AI 助手，可用于调试 Lambda 函数（CloudWatch 集成）
|
||||
- [[CloudWatch]]：AWS 监控服务，Lambda 将指标（请求数、错误数、延迟、节流）上报至此
|
||||
- [[Serverless-Application-Model-SAM]]：AWS 官方开源工具，基于 CloudFormation 简化无服务器应用的本地开发和部署
|
||||
|
||||
## Connections
|
||||
- [[AWS-Lambda]] ← is_a ← [[Serverless-Computing]]
|
||||
- [[AWS-Step-Functions]] ← orchestrates ← [[AWS-Lambda]]
|
||||
- [[Amazon-API-Gateway]] ← exposes ← [[AWS-Lambda]]
|
||||
- [[Amazon-EventBridge]] ← triggers ← [[AWS-Lambda]]
|
||||
- [[SAM-Serverless-Application-Model]] ← builds_on ← [[CloudFormation]]
|
||||
- [[CloudWatch]] ← monitors ← [[AWS-Lambda]]
|
||||
- [[Serverless-Computing]] ← extends ← [[Cloud-Transformation-Programme]]
|
||||
|
||||
## Contradictions
|
||||
- 无已知冲突
|
||||
Reference in New Issue
Block a user