Auto-sync: 2026-04-19 00:02
This commit is contained in:
@@ -14,6 +14,9 @@ tags: []
|
||||
|
||||
| 日期 | 时间 | 服务器 | 备份文件 | 状态 |
|
||||
| ---------- | ----- | -------- | ------------------------------------ | ---- |
|
||||
| 2026-04-18 | 22:00 | Mac Mini | openclaw-macmini-20260418220007.tar | ✅ 成功 |
|
||||
| 2026-04-18 | 22:00 | Ubuntu1 | openclaw-ubuntu1-20260418220033.tar | ✅ 成功 |
|
||||
| 2026-04-18 | 22:00 | Ubuntu2 | openclaw-ubuntu2-20260418220042.tar | ✅ 成功 |
|
||||
| 2026-04-17 | 22:00 | Mac Mini | openclaw-macmini-20260417220007.tar | ✅ 成功 |
|
||||
| 2026-04-17 | 22:00 | Ubuntu1 | openclaw-ubuntu1-20260417220025.tar | ✅ 成功 |
|
||||
| 2026-04-17 | 22:00 | Ubuntu2 | openclaw-ubuntu2-20260417220026.tar | ✅ 成功 |
|
||||
|
||||
235
openclaw/每日复盘/2026-04-18.md
Normal file
235
openclaw/每日复盘/2026-04-18.md
Normal file
@@ -0,0 +1,235 @@
|
||||
---
|
||||
## 【xinghui】星辉 每日复盘 - 2026-04-18
|
||||
|
||||
**日期**: 2026-04-18(周六)
|
||||
**Sessions**: 1 (cron) | **Messages**: 1 (cron trigger)
|
||||
**时间范围**: 21:45:02 - 21:47:27
|
||||
|
||||
---
|
||||
|
||||
### 主要活动
|
||||
|
||||
#### 1. sync_sessions Cron Job 执行 (21:45)
|
||||
- **触发源**: cron ID `83f21f14-d882-4dc7-88b0-f2979dc41333`
|
||||
- **执行内容**:
|
||||
- 在 Mac Mini、Ubuntu1、Ubuntu2 上运行 `sync_sessions.py`
|
||||
- 同步 sessions 到 Django Admin (192.168.3.45:8765/api/sessions/bulk_upsert/)
|
||||
- 同步 cron jobs 和 runs 到 Django Admin
|
||||
- **使用 session**: nova-shoal (pid 94232)
|
||||
|
||||
#### 2. 进程 SIGKILL 问题 (21:47:20)
|
||||
- **现象**: nova-shoal session 的进程被 SIGKILL 终止
|
||||
- **推测原因**:
|
||||
- 命令执行超时(系统默认超时?)
|
||||
- SSH 连接在某个服务器上超时
|
||||
- 内存或资源限制
|
||||
|
||||
---
|
||||
|
||||
### 错误记录
|
||||
|
||||
| 时间 | 错误 | 严重程度 | 可能原因 |
|
||||
|------|------|---------|---------|
|
||||
| 21:47:20 | 进程 SIGKILL (nova-shoal, pid 94232) | 中 | 超时/内存/资源限制 |
|
||||
|
||||
---
|
||||
|
||||
### 经验教训
|
||||
|
||||
1. **sync_sessions 稳定性**: 多服务器 SSH 同步时需要注意进程存活时间
|
||||
2. **SIGKILL 根因**: 需要进一步确认是主动超时还是被动杀死
|
||||
3. **Cron Job 监控**: 建议添加 sync_sessions 执行成功/失败的监控
|
||||
|
||||
---
|
||||
|
||||
### Suggested Action
|
||||
|
||||
1. 检查 sync_sessions.py 的超时设置,考虑增加超时时间
|
||||
2. 验证三个服务器 SSH 连接稳定性(是否有丢包或延迟)
|
||||
3. 在 sync_sessions 脚本中添加重试机制处理部分服务器失败
|
||||
4. 当前 session (每日复盘) 在 23:00 执行,未计入今日日报(因为 session 仍在进行)
|
||||
|
||||
---
|
||||
|
||||
*本复盘由星辉自动生成 | 2026-04-18 23:00 CST*
|
||||
|
||||
---
|
||||
## 【xingjiang】星匠 每日复盘 - 2026-04-18
|
||||
|
||||
**📝 主要活动:**
|
||||
- 响应并执行每日复盘 Cron 任务。
|
||||
- 使用 `agent-browser` 读取 Django Admin 上的个人今日活动报告。
|
||||
- 主动排查、诊断并解决了当天日报因未同步而显示“Not Found”的问题,将远程 `sync_sessions.py` 脚本拉取至本地运行,成功增量推送了当天的 3 个 Session、249 条 Messages。
|
||||
- 提取并分析了当天的活动数据,形成了系统自我优化经验。
|
||||
|
||||
**⚠️ 错误与异常:**
|
||||
1. 页面访问 "Not Found":未意识到 Django 数据需要先行触发同步。
|
||||
2. 尝试通过 Docker `exec` 运行同步脚本失败:脚本并不在 `agent-base` (web) 容器内部,而是存放在 ubuntu2 的宿主服务器 `/home/shenwei/docker/agent-base/scripts/` 目录中。
|
||||
|
||||
**💡 经验教训:**
|
||||
1. **数据同步前置**:在进行基于 Django Admin 数据的任务前,如果遇到缺失,必须先执行 `sync_sessions.py` 将最新 `.jsonl` session 数据上报给 API。
|
||||
2. **本地执行同步最稳妥**:与其在远程通过 SSH 反向读取,不如直接在数据所在节点(macmini)运行同步脚本,将数据 `bulk_upsert` 推送至 `http://192.168.3.45:8765`,可完全避免 SSH 密钥认证或权限卡死的问题。
|
||||
|
||||
|
||||
---
|
||||
## 【xingyao】星曜 每日复盘 - 2026-04-18
|
||||
|
||||
**日期**: 2026-04-18(周六)
|
||||
**Agent**: xingyao(SRE / DevOps)
|
||||
**时间范围**: 01:00 - 23:10 CST
|
||||
|
||||
---
|
||||
|
||||
### 主要活动
|
||||
|
||||
#### 1. 技能同步到 Ubuntu 服务器 (01:00)
|
||||
- **任务**: 通过 rsync 同步 ~/.openclaw/skills/ 到 Ubuntu1 和 Ubuntu2
|
||||
- **结果**: ✅ 成功
|
||||
- Ubuntu1: 318 files, ~2MB, 速度 1.6MB/s
|
||||
- Ubuntu2: 318 files, ~2MB, 速度 463KB/s
|
||||
- 同步技能数量: 各 28 个
|
||||
|
||||
#### 2. OpenClaw 安全检查 (07:00)
|
||||
- **执行**: 在 Mac Mini、Ubuntu1、Ubuntu2 三台服务器上并行运行 openclaw security audit
|
||||
- **发现**:
|
||||
- 🔴 **CRITICAL**: Mac Mini gemini-1.5-flash-8b sandbox=off + web工具开启
|
||||
- 🟡 Ubuntu1: exec.security=full + autoAllowSkills 信任范围过大
|
||||
- 🟡 三台服务器均存在 allowInsecureAuth=true
|
||||
- 🟢 Ubuntu2: 仅 2 个 WARN,安全状态良好
|
||||
- ⚠️ Ubuntu1/2: 存在过时 openclaw-weixin 配置条目
|
||||
- **报告**: 已通过 Telegram 发送给用户
|
||||
|
||||
#### 3. Mac Mini 服务器性能检查 (07:15)
|
||||
- **执行**: 收集 Mac Mini 系统指标(CPU/内存/磁盘/Docker)
|
||||
- **发现**:
|
||||
- CPU: Apple M4, idle 86%, 负载 2.64(正常)
|
||||
- 内存: 16GB, 459MB free(macOS 正常行为)
|
||||
- 磁盘: 228GB/16% 使用率,健康
|
||||
- Docker: vaultwarden 运行健康,portainer/rabbitmq 已停用 3-4 周
|
||||
- **报告**: 已通过 Telegram 发送给用户
|
||||
- **建议**: 清理已停用 Docker 容器
|
||||
|
||||
#### 4. Grafana 监控截图发送 (15:58-16:00)
|
||||
- **任务**: 用户请求三个服务器 Grafana 监控截图
|
||||
- **执行**: 使用 agent-browser 登录 Grafana,截取三台服务器监控面板
|
||||
- **结果**: ✅ 全部成功发送至 Telegram
|
||||
- Mac Mini (192.168.3.189): msg 3550
|
||||
- Ubuntu1 (192.168.3.47): msg 3551
|
||||
- Ubuntu2 (192.168.3.45): msg 3552
|
||||
|
||||
---
|
||||
|
||||
### 错误与异常
|
||||
|
||||
| 时间 | 错误 | 严重程度 | 原因 |
|
||||
|------|------|---------|------|
|
||||
| 07:15 | Glances 端口 61208 未监听 | 低 | Glances 服务未在 Mac Mini 运行 |
|
||||
| 07:00 | SSH 执行 openclaw 命令 "command not found" | 中 | Ubuntu1/2 PATH 未包含 npm 全局路径 |
|
||||
|
||||
---
|
||||
|
||||
### 经验教训
|
||||
|
||||
1. **小模型安全风险**: 8B 参数小模型 + sandbox=off + web工具 = CRITICAL 风险,必须优先处理
|
||||
2. **Ubuntu openclaw 命令路径**: SSH 远程执行必须用完整路径 `/home/shenwei/.npm-global/bin/openclaw`
|
||||
3. **exec.full 过度信任**: Ubuntu1 fengchi 的 exec.security=full + autoAllowSkills 扩大了攻击面
|
||||
4. **Docker 清理**: portainer 和 rabbitmq 已停用 3-4 周,应定期清理
|
||||
5. **过时配置清理**: openclaw-weixin 插件条目在 Ubuntu1/2 配置文件中有残留
|
||||
|
||||
---
|
||||
|
||||
### Suggested Action
|
||||
|
||||
1. 🔴 优先处理 Mac Mini gemini-1.5-flash-8b 安全配置(开启 sandbox 或禁用 web 工具)
|
||||
2. 🟡 审查并收紧 Ubuntu1 fengchi 的 exec 策略(考虑从 full 降级到 allowlist)
|
||||
3. 🟡 三台服务器 allowInsecureAuth=true 需评估是否可关闭
|
||||
4. 🟢 清理 Ubuntu1/2 配置文件中的 openclaw-weixin 过时条目
|
||||
5. 🟢 清理 Mac Mini 已停用的 Docker 容器(portainer、rabbitmq)
|
||||
6. 🟢 Mac Mini 更新到 OpenClaw 2026.4.15
|
||||
|
||||
---
|
||||
|
||||
### 关键指标
|
||||
|
||||
| 指标 | 数值 |
|
||||
|------|------|
|
||||
| 定时任务执行 | 4 个(技能同步、安全检查、性能检查、Grafana截图) |
|
||||
| Telegram 消息发送 | 5 条(含报告和截图) |
|
||||
| 新增学习条目 | 3 条(LEARNINGS.md) |
|
||||
| 安全问题 | 1 个 CRITICAL,4 个 WARN |
|
||||
|
||||
---
|
||||
|
||||
*本复盘由星曜自动生成 | 2026-04-18 23:10 CST*
|
||||
|
||||
---
|
||||
## 【xingshu】星枢 每日复盘 - 2026-04-18
|
||||
|
||||
**日期**: 2026-04-18(周六)
|
||||
**Agent**: xingshu(战略枢纽 / 协调调度)
|
||||
**时间范围**: 16:05 - 18:47 CST
|
||||
|
||||
---
|
||||
|
||||
### 主要活动
|
||||
|
||||
#### 1. Wiki HTML→Markdown 批量转换(16:07 - 16:11)
|
||||
- **用户请求**: 将 ESM SaaS Wiki Export (HTML)/ICSD 目录下所有 HTML(含 attachments/ 子目录)转换为 Markdown,保持原目录结构
|
||||
- **执行过程**:
|
||||
1. 扫描源目录:共 428 个 HTML 文件(根目录 + attachments/ 子目录)
|
||||
2. 检测 `defuddle` 工具(/opt/homebrew/bin/defuddle 内部报 `pandoc not found` 但 defuddle 本身可用)
|
||||
3. 编写 Python 批处理脚本(`convert_html_to_md.py`)
|
||||
4. 首次运行报 f-string 语法错误(`SyntaxError: f-string: unmatched ']'`),快速修复后成功
|
||||
- **结果**: 428 个 HTML → 428 个 MD,0 失败
|
||||
- **输出**: `~/Workspace/nexus/knowledgebase/csd-wiki/ICSD/`
|
||||
|
||||
#### 2. OpenClaw Skills 状态笔记整理(18:40 - 18:47)
|
||||
- **用户请求**: 将 `openclaw skills` 输出保存为笔记,带状态图标,保留原始英文 description 并翻译中文
|
||||
- **执行过程**:
|
||||
1. 首次解析脚本(parse_skills.py)解析失败(识别 0 个 skills)——因为终端渲染的 Unicode 表格格式难以正则解析
|
||||
2. 重写为 parse_skills2.py:先将原始输出写入文件再解析,成功识别 94 个 skills(62 ready,32 needs setup)
|
||||
3. 用户补充要求:保留原始英文 + 中文翻译双语格式
|
||||
4. 最终更新为 parse_skills3.py,输出双语描述版本
|
||||
- **结果**: 94 个 skills,双语描述,已保存至 `~/Workspace/nexus/knowledgebase/openclaw-skills-status.md`
|
||||
|
||||
---
|
||||
|
||||
### 错误记录
|
||||
|
||||
| 时间 | 错误 | 严重程度 | 根因 | 解决方案 |
|
||||
|------|------|---------|------|---------|
|
||||
| 16:09 | Python f-string SyntaxError | 低 | f-string 嵌套 `[]` 未转义 | 将 `len()` 结果存入变量 |
|
||||
| 18:45 | parse_skills.py 识别 0 skills | 中 | 解析终端 Unicode 表格格式失败 | 改为先写文件再解析 |
|
||||
|
||||
---
|
||||
|
||||
### 经验教训
|
||||
|
||||
1. **Python f-string 嵌套括号**:字典/列表字面量在 f-string 中需将所有 `[]` 转为 `{{}}`,或将运算结果存为变量以避免
|
||||
2. **解析格式化终端输出**:复杂 Unicode 表格(如 `┌─┬┐` 边框)不能简单按空格 split,应先保存原始文件再处理
|
||||
3. **defuddle 内部 pandoc 警告**:defuddle 会在 `/opt/homebrew/bin/defuddle` 下检测 pandoc 是否安装,失败时打印警告但不影响实际使用(defuddle 有内置解析器)
|
||||
4. **用户需求渐进澄清**:用户首次说"用图标标识 status",补充要求"保留原始英文 description 并翻译中文"——两次请求叠加,需仔细理解完整需求再动手
|
||||
|
||||
---
|
||||
|
||||
### Suggested Action
|
||||
|
||||
1. 将 `convert_html_to_md.py` 脚本固化到 `~/.openclaw/temp/xingshu/scripts/` 供后续复用
|
||||
2. 将 `parse_skills3.py` 保留为 skills 快照定期更新脚本
|
||||
3. 确认 defuddle 警告是否影响附件目录中的图片/文件转换(当前仅转换 HTML 文本内容)
|
||||
|
||||
---
|
||||
|
||||
### 关键指标
|
||||
|
||||
| 指标 | 数值 |
|
||||
|------|------|
|
||||
| HTML→MD 转换 | 428 个(0 失败) |
|
||||
| Skills 解析 | 94 个(62 ready / 32 needs setup) |
|
||||
| 学习条目新增 | 3 条(LEARNINGS.md) |
|
||||
| 新增/修改笔记 | 2 个(csd-wiki/ICSD/、openclaw-skills-status.md) |
|
||||
|
||||
---
|
||||
|
||||
*本复盘由星枢自动生成 | 2026-04-18 23:15 CST*
|
||||
|
||||
18
wiki/concepts/AMI-End-of-Life.md
Normal file
18
wiki/concepts/AMI-End-of-Life.md
Normal file
@@ -0,0 +1,18 @@
|
||||
---
|
||||
title: "AMI End-of-Life"
|
||||
type: concept
|
||||
tags: [AWS, Cloud, Infrastructure, Lifecycle]
|
||||
---
|
||||
|
||||
## Definition
|
||||
AMI End-of-Life 是指操作系统版本到达生命周期终点,AWS 不再提供更新和支持。
|
||||
|
||||
## Timeline
|
||||
- CentOS 7 → Rocky Linux (2024年6月)
|
||||
- Red Hat 7 → Rocky Linux (2024年6月)
|
||||
- OpenSUSE Leap 15 → (2024年12月)
|
||||
- OEL 7 → (2024年12月)
|
||||
|
||||
## Migration Path
|
||||
- CentOS 7 迁移到 Rocky Linux
|
||||
- 保持现有应用兼容性的同时完成操作系统升级
|
||||
43
wiki/concepts/AMI-Roadmap.md
Normal file
43
wiki/concepts/AMI-Roadmap.md
Normal file
@@ -0,0 +1,43 @@
|
||||
---
|
||||
title: "AMI Roadmap"
|
||||
type: concept
|
||||
tags:
|
||||
- AWS
|
||||
- AMI
|
||||
- Roadmap
|
||||
---
|
||||
|
||||
## Definition
|
||||
AMI 路线图(AMI Roadmap)是 CCOE 规划的操作系统支持计划,涵盖当前支持的 AMI 版本和新操作系统的添加时间表。
|
||||
|
||||
## Current Supported AMIs
|
||||
- Ubuntu(3个版本)
|
||||
- CentOS 7 和 8
|
||||
- Rocky 8.4 ARM
|
||||
- Amazon Linux 2
|
||||
- Windows(4个版本)
|
||||
|
||||
## Roadmap Timeline
|
||||
| 时间 | 新增 AMI |
|
||||
|------|----------|
|
||||
| 2022年11月 | SLES 15, RHEL 9 |
|
||||
| 2023年1月 | OpenSUSE 15, Amazon Linux 2022 |
|
||||
| 2023年3月 | Rocky 8, Rocky 9 |
|
||||
| 2023年5月 | RHEL 9.4 ARM, Ubuntu 22.04 ARM |
|
||||
|
||||
## EOL (End of Life) Schedule
|
||||
- Windows Server 2008/2008 R2:2020年1月
|
||||
- CentOS 8:2021年12月
|
||||
- Windows Server 2012:2023年10月
|
||||
- RHEL 7 + CentOS 7:2024年6月
|
||||
|
||||
## Priority Management
|
||||
路线图优先级由 ADM 需求决定,如需调整需通过需求管道(Demand Pipeline)流程。
|
||||
|
||||
## Related
|
||||
- [[Standard AMI]]
|
||||
- [[AMI-End-of-Life]]
|
||||
- [[CCOE]]
|
||||
|
||||
## Last Updated
|
||||
2026-04-18
|
||||
29
wiki/concepts/AMI-Sharing.md
Normal file
29
wiki/concepts/AMI-Sharing.md
Normal file
@@ -0,0 +1,29 @@
|
||||
---
|
||||
title: "AMI Sharing"
|
||||
type: concept
|
||||
tags: [AWS, AMI, Cloud]
|
||||
---
|
||||
|
||||
## Definition
|
||||
AMI Sharing(镜像共享机制)是 AWS 允许账户持有者通过授权方式与其他 AWS 账户共享 AMIs 的功能,避免了跨账号复制带来的额外存储成本和复制时间。
|
||||
|
||||
## Mechanism
|
||||
- 通过 AWS Resource Access Manager (RAM) 或控制台共享
|
||||
- 接收账户在自身账户中使用共享的 AMI 启动实例
|
||||
- 无需物理复制镜像到目标账户
|
||||
|
||||
## Benefits
|
||||
- 避免存储重复镜像
|
||||
- 快速分发到多个账号和区域
|
||||
- 降低存储成本
|
||||
- 简化镜像管理
|
||||
|
||||
## Use Cases
|
||||
- 中央镜像库分发标准 AMI
|
||||
- 跨账号环境标准化
|
||||
- ISV 镜像产品分发
|
||||
|
||||
## Related Concepts
|
||||
- [[Foundation AMI]] — 通过 AMI Sharing 分发的镜像类型
|
||||
- [[Standard AMI]] — 企业标准镜像
|
||||
- [[AWS Organizations]] — 跨账号管理
|
||||
24
wiki/concepts/CIS-Benchmarks.md
Normal file
24
wiki/concepts/CIS-Benchmarks.md
Normal file
@@ -0,0 +1,24 @@
|
||||
---
|
||||
title: "CIS Benchmarks"
|
||||
type: concept
|
||||
tags: [Security, Compliance, AWS]
|
||||
---
|
||||
|
||||
## Definition
|
||||
CIS Benchmarks(互联网安全中心基准)是由 CIS(Center for Internet Security)制定的安全配置基准,用于衡量系统是否符合行业最佳安全实践。
|
||||
|
||||
## Purpose
|
||||
- 提供标准化的安全配置指南
|
||||
- 评估系统安全状态
|
||||
- 符合合规性要求
|
||||
- 减少系统攻击面
|
||||
|
||||
## Application
|
||||
- 操作系统(Linux, Windows)
|
||||
- 云平台(AWS, Azure, GCP)
|
||||
- 应用软件
|
||||
|
||||
## Related Concepts
|
||||
- [[Foundation AMI]] — 应用 CIS Benchmarks 的镜像类型
|
||||
- [[OS Hardening]] — 实施基准的技术手段
|
||||
- [[Standard AMI]] — 企业标准化镜像
|
||||
28
wiki/concepts/Checkpoint-Firewall.md
Normal file
28
wiki/concepts/Checkpoint-Firewall.md
Normal file
@@ -0,0 +1,28 @@
|
||||
---
|
||||
id: Checkpoint-Firewall
|
||||
title: "Checkpoint Firewall"
|
||||
type: concept
|
||||
tags:
|
||||
- AWS
|
||||
- Cloud-Security
|
||||
- Firewall
|
||||
- Tagging
|
||||
date_added: 2026-04-18
|
||||
---
|
||||
|
||||
## Definition
|
||||
部署在云环境中的虚拟防火墙,通过集成 AWS 标签实现动态的对象识别和流量过滤。
|
||||
|
||||
## Key Features
|
||||
- 基于标签而非 IP 的动态安全控制
|
||||
- 支持地理屏蔽、BU 隔离、产品隔离及环境隔离
|
||||
- 与 Transit Gateway 集成,作为跨 VPC、访问本地或互联网的流量检查节点
|
||||
|
||||
## Use Case
|
||||
- 在 AWS Landing Zone 中实现精细化的流量过滤
|
||||
- 通过有序层逻辑按优先级执行安全策略
|
||||
|
||||
## Related Concepts
|
||||
- [[Transit Gateway]]
|
||||
- [[Tagging Methodology]]
|
||||
- [[Ordered Layer]]
|
||||
21
wiki/concepts/CloudFront.md
Normal file
21
wiki/concepts/CloudFront.md
Normal file
@@ -0,0 +1,21 @@
|
||||
---
|
||||
title: "CloudFront"
|
||||
type: concept
|
||||
tags:
|
||||
- CDN
|
||||
- AWS
|
||||
- Content-Delivery
|
||||
date-added: 2026-04-18
|
||||
---
|
||||
|
||||
## Description
|
||||
Amazon CloudFront 是 AWS 的内容分发网络(CDN)服务,用于在全球边缘位置缓存和分发静态内容(如图像、视频、应用程序等),降低延迟并提高用户体验。
|
||||
|
||||
## Role in SaaS Landing Zone
|
||||
- 在 Product Accounts 中可用作 CDN
|
||||
- 加速静态内容分发
|
||||
- 与 WAF 集成提供安全防护
|
||||
|
||||
## Related
|
||||
- [[AWS]]:云服务提供商
|
||||
- [[ctp-topic-7-saas-landing-zone-design]]:SaaS Landing Zone 设计
|
||||
38
wiki/concepts/DNS-Anycast.md
Normal file
38
wiki/concepts/DNS-Anycast.md
Normal file
@@ -0,0 +1,38 @@
|
||||
---
|
||||
title: "DNS Anycast"
|
||||
type: concept
|
||||
tags:
|
||||
- DNS
|
||||
- Networking
|
||||
- High Availability
|
||||
---
|
||||
|
||||
## Definition
|
||||
DNS Anycast 是一种网络寻址和路由方法,使多个 DNS 服务器共享同一个 IP 地址,将请求路由至地理位置最近的节点,提供极高的冗余性和低延迟。
|
||||
|
||||
## Characteristics
|
||||
- **低延迟**:请求自动路由到最近的节点
|
||||
- **高可用性**:单个节点故障不影响服务,流量自动切换到其他节点
|
||||
- **全球分布**:支持全球范围内部署
|
||||
|
||||
## Comparison: Infoblox vs AWS
|
||||
|
||||
| 特性 | Infoblox (On-prem) | AWS EC2 |
|
||||
|------|-------------------|---------|
|
||||
| Anycast 支持 | ✅ 原生支持 | ❌ 不支持 |
|
||||
| 故障转移 | 自动 | 手动维护 IP 列表 |
|
||||
| 延迟优化 | 自动就近解析 | 需手动配置 |
|
||||
|
||||
## Security Features
|
||||
- 防 DNS 隧道攻击
|
||||
- 防数据外泄
|
||||
- 防缓存污染
|
||||
|
||||
## Use Cases
|
||||
- 企业内网 DNS 高可用
|
||||
- DNS 负载均衡
|
||||
- 全球化服务的就近解析
|
||||
|
||||
## Connections
|
||||
- [[Infoblox]] ← uses ← [[DNS-Anycast]]
|
||||
- [[DNS-Anycast]] ← optimizes ← [[Hybrid-DNS-Resolution]]
|
||||
18
wiki/concepts/EC2-Image-Builder.md
Normal file
18
wiki/concepts/EC2-Image-Builder.md
Normal file
@@ -0,0 +1,18 @@
|
||||
---
|
||||
title: "EC2 Image Builder"
|
||||
type: concept
|
||||
tags: [AWS, Cloud, Infrastructure]
|
||||
---
|
||||
|
||||
## Definition
|
||||
EC2 Image Builder 是 AWS 的镜像构建服务,用于创建和维护自定义 Amazon Machine Images (AMIs)。
|
||||
|
||||
## Features
|
||||
- 自动化镜像构建管道
|
||||
- 跨区域复制和共享
|
||||
- 内置验证和测试
|
||||
|
||||
## Use Cases
|
||||
- Standard AMI 构建
|
||||
- 企业镜像标准化
|
||||
- 安全合规镜像管理
|
||||
26
wiki/concepts/Foundation-AMI.md
Normal file
26
wiki/concepts/Foundation-AMI.md
Normal file
@@ -0,0 +1,26 @@
|
||||
---
|
||||
title: "Foundation AMI"
|
||||
type: concept
|
||||
tags: [AWS, AMI, Security]
|
||||
---
|
||||
|
||||
## Definition
|
||||
Foundation AMI(基础亚马逊机器镜像)是基于市场主流操作系统(CentOS, Ubuntu, Windows 等)进行深度加固的镜像,集成了 CIS 安全基准、防病毒软件、日志管理及单点登录功能。
|
||||
|
||||
## Components
|
||||
- OS 加固(OS Hardening)
|
||||
- CIS Benchmarks 安全配置
|
||||
- 防病毒软件(McAfee EPO)
|
||||
- 日志管理(Syslog-ng)
|
||||
- 单点登录(AD 集成)
|
||||
- SSM Agent 预装
|
||||
- SiteScope 监控预选件
|
||||
|
||||
## Usage
|
||||
"即插即用"型镜像,确保所有实例从启动之日起符合组织的安全合规标准。
|
||||
|
||||
## Related Concepts
|
||||
- [[Standard AMI]] — 更广泛的标准化镜像概念
|
||||
- [[OS Hardening]] — 操作系统加固技术
|
||||
- [[CIS Benchmarks]] — 安全配置基准
|
||||
- [[SSM Agent]] — AWS 系统管理器代理
|
||||
37
wiki/concepts/Hybrid-DNS-Resolution.md
Normal file
37
wiki/concepts/Hybrid-DNS-Resolution.md
Normal file
@@ -0,0 +1,37 @@
|
||||
---
|
||||
title: "Hybrid DNS Resolution"
|
||||
type: concept
|
||||
tags:
|
||||
- DNS
|
||||
- Networking
|
||||
- Hybrid Cloud
|
||||
---
|
||||
|
||||
## Definition
|
||||
混合云 DNS 解析(Hybrid DNS Resolution)指通过配置转发规则,使云端资源能解析本地域名,同时本地资源也能解析云端域名的机制。
|
||||
|
||||
## Architecture Components
|
||||
|
||||
### AWS Side
|
||||
- [[Route-53-Private-Hosted-Zone]]
|
||||
- [[Route-53-Resolver-Endpoint]](入站/出站)
|
||||
- IAM 角色和策略控制
|
||||
|
||||
### On-Premise Side
|
||||
- Active Directory 托管 DNS
|
||||
- DNS 转发器
|
||||
|
||||
## Key Capabilities
|
||||
- **跨区域弹性**:在出站规则中配置多个区域的 AD 域控制器 IP,确保故障转移
|
||||
- **就近解析**:优化 Office 365 等全球化服务的访问性能
|
||||
- **安全防护**:防 DNS 隧道攻击、数据外泄、缓存污染
|
||||
|
||||
## Workflow
|
||||
1. VPC 内的资源发起 DNS 查询
|
||||
2. Route 53 Resolver 检查是否有匹配的转发规则
|
||||
3. 如果有,通过 Outbound Endpoint 转发到本地 AD 域控制器
|
||||
4. 本地 DNS 返回解析结果
|
||||
|
||||
## Connections
|
||||
- [[Route-53-Resolver-Endpoint]] ← implements ← [[Hybrid-DNS-Resolution]]
|
||||
- [[Active-Directory]] ← provides ← 域控制器 ← [[Hybrid-DNS-Resolution]]
|
||||
31
wiki/concepts/IPAM.md
Normal file
31
wiki/concepts/IPAM.md
Normal file
@@ -0,0 +1,31 @@
|
||||
---
|
||||
title: "IPAM"
|
||||
type: concept
|
||||
tags:
|
||||
- Networking
|
||||
- IP Address
|
||||
---
|
||||
|
||||
## Definition
|
||||
IPAM(IP Address Management,IP 地址管理)是一种用于规划、追踪和管理网络中的 IP 地址空间及 DNS/DHCP 服务的工具或平台。
|
||||
|
||||
## Key Functions
|
||||
- IP 地址分配和追踪
|
||||
- DNS 记录管理
|
||||
- DHCP 服务配置
|
||||
- 地址空间规划
|
||||
- 合规性审计
|
||||
|
||||
## Common Tools
|
||||
- **Infoblox**:企业级 IPAM 解决方案,提供 NIOS 操作系统和 Infoblox Grid 架构
|
||||
- **phpIPAM**:开源 IPAM 工具
|
||||
- **GestióIP**:另一款开源 IPAM 工具
|
||||
|
||||
## Use Cases
|
||||
- 企业内网 IP 管理
|
||||
- DNS/DHCP 服务统一管理
|
||||
- 云环境与本地环境的 IP 地址协调
|
||||
|
||||
## Connections
|
||||
- [[Infoblox]] ← provides ← IPAM
|
||||
- [[Landing-Zone]] ← uses ← IPAM
|
||||
29
wiki/concepts/MPP.md
Normal file
29
wiki/concepts/MPP.md
Normal file
@@ -0,0 +1,29 @@
|
||||
---
|
||||
title: "MPP"
|
||||
type: concept
|
||||
tags: [AWS, Redshift, 并行处理]
|
||||
sources: [ctp-topic-68-introduction-to-redshift]
|
||||
last_updated: 2026-04-18
|
||||
---
|
||||
|
||||
## Summary
|
||||
|
||||
MPP(Massively Parallel Processing,大规模并行处理)是一种使查询能够跨多个计算节点并行执行的技术。
|
||||
|
||||
## Definition
|
||||
|
||||
- **全称**:Massively Parallel Processing
|
||||
- **作用**:提升查询速度和响应时间
|
||||
- **应用**:Redshift 等数据仓库系统
|
||||
|
||||
## Key Benefits
|
||||
|
||||
- 跨节点并行处理查询
|
||||
- 提升查询性能
|
||||
- 缩短响应时间
|
||||
- 支持 PB 级数据处理
|
||||
|
||||
## Connections
|
||||
|
||||
- [[AWS-Redshift]] → 使用 → [[MPP]]
|
||||
- [[Compute-Node]] → 执行 → [[MPP]]
|
||||
30
wiki/concepts/Management-Groups.md
Normal file
30
wiki/concepts/Management-Groups.md
Normal file
@@ -0,0 +1,30 @@
|
||||
---
|
||||
title: Management Groups
|
||||
type: concept
|
||||
tags: [Azure, Organization, Management]
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Definition
|
||||
Azure Management Groups 是用于组织和管理多个订阅的分层容器,类似于 Windows 父目录结构,允许跨订阅的统一策略应用和访问控制。
|
||||
|
||||
## Key Characteristics
|
||||
- 支持嵌套层级结构,最多 6 层深度
|
||||
- 可将策略和访问权限继承到下层订阅
|
||||
- 支持治理需求的企业级组织结构
|
||||
- 每个 Management Group 可包含多个订阅
|
||||
|
||||
## Use Cases
|
||||
- 按业务部门组织订阅
|
||||
- 按环境(生产、开发、测试)分离
|
||||
- 按产品线或项目分组
|
||||
- 统一应用安全合规策略
|
||||
|
||||
## Related Concepts
|
||||
- [[Subscription]]:Azure 订阅,资源隔离的容器
|
||||
- [[Azure Landing Zone]]:使用 Management Groups 实现组织结构
|
||||
- [[Service Control Policies]]:类似 AWS 的组织策略
|
||||
|
||||
## Connections
|
||||
- [[Management Groups]] ← organizes ← [[Subscription]]
|
||||
- [[Azure Landing Zone]] ← uses ← [[Management Groups]]
|
||||
28
wiki/concepts/OLAP.md
Normal file
28
wiki/concepts/OLAP.md
Normal file
@@ -0,0 +1,28 @@
|
||||
---
|
||||
title: "OLAP"
|
||||
type: concept
|
||||
tags: [数据库, 数据分析]
|
||||
sources: [ctp-topic-68-introduction-to-redshift]
|
||||
last_updated: 2026-04-18
|
||||
---
|
||||
|
||||
## Summary
|
||||
|
||||
OLAP(Online Analytical Processing,在线分析处理)是一种用于支持复杂分析查询和决策支持的数据库技术。
|
||||
|
||||
## Definition
|
||||
|
||||
- **全称**:Online Analytical Processing
|
||||
- **用途**:数据挖掘、报表分析、复杂查询
|
||||
- **对比**:OLTP(在线事务处理)
|
||||
|
||||
## Key Features
|
||||
|
||||
- 支持多维分析
|
||||
- 适合聚合和汇总查询
|
||||
- 处理大量历史数据
|
||||
- 支持复杂 SQL 查询
|
||||
|
||||
## Connections
|
||||
|
||||
- [[AWS-Redshift]] → 支持 → [[OLAP]]
|
||||
21
wiki/concepts/OS-Hardening.md
Normal file
21
wiki/concepts/OS-Hardening.md
Normal file
@@ -0,0 +1,21 @@
|
||||
---
|
||||
title: "OS Hardening"
|
||||
type: concept
|
||||
tags: [Security, Linux, AWS]
|
||||
---
|
||||
|
||||
## Definition
|
||||
OS Hardening(操作系统加固)是通过关闭不必要服务、优化内核参数和应用安全补丁来减少系统攻击面的技术过程。
|
||||
|
||||
## Techniques
|
||||
- 关闭不必要的端口和服务
|
||||
- 优化内核参数
|
||||
- 应用安全补丁
|
||||
- 配置防火墙规则
|
||||
- 禁用弱协议和算法
|
||||
- 实施最小权限原则
|
||||
|
||||
## Related Concepts
|
||||
- [[Foundation AMI]] — 应用 OS Hardening 的目标镜像
|
||||
- [[CIS Benchmarks]] — 安全配置基准
|
||||
- [[Standard AMI]] — 企业标准化镜像
|
||||
33
wiki/concepts/Ordered-Layer.md
Normal file
33
wiki/concepts/Ordered-Layer.md
Normal file
@@ -0,0 +1,33 @@
|
||||
---
|
||||
id: Ordered-Layer
|
||||
title: "Ordered Layer"
|
||||
type: concept
|
||||
tags:
|
||||
- AWS
|
||||
- Firewall
|
||||
- Security-Policy
|
||||
date_added: 2026-04-18
|
||||
---
|
||||
|
||||
## Definition
|
||||
防火墙策略的一种组织方式,按顺序执行多个过滤规则,优先级从高到低。
|
||||
|
||||
## Layer Priority
|
||||
1. **地理屏蔽** — 阻止特定地区的流量
|
||||
2. **BU 隔离** — 按业务单元隔离流量
|
||||
3. **产品隔离** — 按产品线隔离流量
|
||||
4. **环境隔离** — 开发环境与生产环境隔离
|
||||
|
||||
## Key Features
|
||||
- 逐层过滤,确保流量满足所有前置条件
|
||||
- 支持 PSDC 等共享服务的合法访问
|
||||
- 与 AWS 标签集成,实现动态策略执行
|
||||
|
||||
## Use Case
|
||||
- 在 Checkpoint 防火墙中实现多层次的流量控制
|
||||
- 确保跨 VPC、访问本地或互联网的流量受到精细化策略约束
|
||||
|
||||
## Related Concepts
|
||||
- [[Checkpoint Firewall]]
|
||||
- [[Tagging Methodology]]
|
||||
- [[Transit Gateway]]
|
||||
31
wiki/concepts/PIM-Privileged-Identity-Management.md
Normal file
31
wiki/concepts/PIM-Privileged-Identity-Management.md
Normal file
@@ -0,0 +1,31 @@
|
||||
---
|
||||
title: PIM(Privileged Identity Management)
|
||||
type: concept
|
||||
tags: [Azure, Security, Access-Control]
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Definition
|
||||
PIM(Privileged Identity Management,特权身份管理)是 Azure AD 的一项安全功能,用于管理和监控 Azure 环境中拥有提升权限的用户访问。PIM 通过实时审批流程和角色激活机制,减少长期特权账号带来的安全风险。
|
||||
|
||||
## Key Characteristics
|
||||
- 特权角色的临时激活
|
||||
- 多因素认证强制要求
|
||||
- 审批工作流支持
|
||||
- 详细审计日志记录
|
||||
- 访问权限到期自动撤销
|
||||
|
||||
## Use Cases
|
||||
- 按需激活管理员权限
|
||||
- 实施最小权限原则
|
||||
- 合规审计和报告
|
||||
- 紧急访问场景管理
|
||||
|
||||
## Related Concepts
|
||||
- [[Azure Active Directory]]:Azure 身份识别服务
|
||||
- [[Zero Trust Architecture]]:零信任架构
|
||||
- [[Azure Landing Zone]]:使用 PIM 实施访问管理
|
||||
|
||||
## Connections
|
||||
- [[PIM(Privileged Identity Management)]] ← manages ← [[Azure Active Directory]]
|
||||
- [[Azure Landing Zone]] ← uses ← [[PIM(Privileged Identity Management)]]
|
||||
25
wiki/concepts/Route-53-Private-Hosted-Zone.md
Normal file
25
wiki/concepts/Route-53-Private-Hosted-Zone.md
Normal file
@@ -0,0 +1,25 @@
|
||||
---
|
||||
title: "Route 53 Private Hosted Zone"
|
||||
type: concept
|
||||
tags:
|
||||
- AWS
|
||||
- DNS
|
||||
- Networking
|
||||
---
|
||||
|
||||
## Definition
|
||||
Route 53 Private Hosted Zone 是 AWS 提供的私有托管区域,仅对指定的 VPC 可见,用于管理内部网络域名。
|
||||
|
||||
## Characteristics
|
||||
- **私有性**:仅在指定的 VPC 内解析,不暴露到公网
|
||||
- **VPC 关联**:一个 Private Hosted Zone 可以关联到多个 VPC
|
||||
- **解析机制**:在关联的 VPC 内自动解析记录的域名
|
||||
|
||||
## Use Cases
|
||||
- 管理内部服务域名(如 `internal.example.com`)
|
||||
- 配合 Private Resolver 实现混合云 DNS 解析
|
||||
- Landing Zone 基础架构的核心组件
|
||||
|
||||
## Connections
|
||||
- [[Route-53]] ← manages ← [[Route-53-Private-Hosted-Zone]]
|
||||
- [[Route-53-Resolver-Endpoint]] ← integrates_with ← [[Route-53-Private-Hosted-Zone]]
|
||||
34
wiki/concepts/Route-53-Resolver-Endpoint.md
Normal file
34
wiki/concepts/Route-53-Resolver-Endpoint.md
Normal file
@@ -0,0 +1,34 @@
|
||||
---
|
||||
title: "Route 53 Resolver Endpoint"
|
||||
type: concept
|
||||
tags:
|
||||
- AWS
|
||||
- DNS
|
||||
- Networking
|
||||
---
|
||||
|
||||
## Definition
|
||||
Route 53 Resolver Endpoint 包括入站(Inbound)和出站(Outbound)终端节点,用于在 AWS VPC 与本地网络或其他云环境之间转发 DNS 查询。
|
||||
|
||||
## Types
|
||||
|
||||
### Inbound Endpoint
|
||||
- 允许本地网络向 Route 53 Resolver 发送 DNS 查询
|
||||
- 用于本地环境解析 AWS 内部域名
|
||||
|
||||
### Outbound Endpoint
|
||||
- 允许 VPC 内的资源向本地 DNS 服务器发送查询
|
||||
- 通过出站规则配置转发条件,将特定域名的查询转发到指定的 DNS 服务器(如 AD 域控制器)
|
||||
|
||||
## Use Cases
|
||||
- 混合云 DNS 解析
|
||||
- 跨区域 DNS 故障转移
|
||||
- 就近解析全球化服务(如 Office 365)
|
||||
|
||||
## Configuration Example
|
||||
- 在出站规则中配置多个区域的 AD 域控制器 IP
|
||||
- 确保即使某个区域发生故障,DNS 解析仍保持弹性
|
||||
|
||||
## Connections
|
||||
- [[Route-53]] ← provides ← [[Route-53-Resolver-Endpoint]]
|
||||
- [[Route-53-Resolver-Endpoint]] ← forwards_to ← [[Active-Directory]]
|
||||
36
wiki/concepts/Subscription.md
Normal file
36
wiki/concepts/Subscription.md
Normal file
@@ -0,0 +1,36 @@
|
||||
---
|
||||
title: Subscription
|
||||
type: concept
|
||||
tags: [Azure, Isolation, Resource]
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Definition
|
||||
Azure Subscription(订阅)是 Azure 资源隔离的基本容器,每个订阅有独立的资源配额、计费账单和访问控制策略。在 Landing Zone 架构中,不同用途的工作负载使用独立的订阅实现隔离和管控。
|
||||
|
||||
## Key Characteristics
|
||||
- 独立的资源配额(vCPU、存储等)
|
||||
- 独立的计费账单
|
||||
- 独立的资源访问控制
|
||||
- 可绑定到不同的 Azure Active Directory 租户
|
||||
|
||||
## Common Subscription Types in Landing Zone
|
||||
- **Platform Subscription**:平台服务(身份管理、连接)
|
||||
- **Landing Zone Subscription**:工作负载部署
|
||||
- **Decommission Subscription**:退役资源存放
|
||||
- **Sandbox Subscription**:实验和测试环境
|
||||
|
||||
## Design Principles
|
||||
- 每个订阅专注于特定用途
|
||||
- 实现故障隔离和资源管控
|
||||
- 最小化跨订阅依赖
|
||||
- 通过标签实现成本分摊
|
||||
|
||||
## Related Concepts
|
||||
- [[Management Groups]]:组织多个订阅
|
||||
- [[Azure Landing Zone]]:多订阅架构
|
||||
- [[Terraform Cloud]]:跨订阅自动化管理
|
||||
|
||||
## Connections
|
||||
- [[Subscription]] ← organized_by ← [[Management Groups]]
|
||||
- [[Azure Landing Zone]] ← contains ← [[Subscription]]
|
||||
39
wiki/concepts/Tagging-Methodology.md
Normal file
39
wiki/concepts/Tagging-Methodology.md
Normal file
@@ -0,0 +1,39 @@
|
||||
---
|
||||
id: Tagging-Methodology
|
||||
title: "Tagging Methodology"
|
||||
type: concept
|
||||
tags:
|
||||
- AWS
|
||||
- Tagging
|
||||
- Security
|
||||
- Automation
|
||||
date_added: 2026-04-18
|
||||
---
|
||||
|
||||
## Definition
|
||||
标签方法论,通过为资源定义标准化的元数据(如 Owner, BU, Product, Environment),作为自动化管理和安全策略执行的基础。
|
||||
|
||||
## Standard Tags
|
||||
- **Owner:** 资源所有者
|
||||
- **BU (Business Unit):** 业务单元
|
||||
- **Product:** 产品线
|
||||
- **Environment:** 环境(dev, staging, prod)
|
||||
|
||||
## Key Features
|
||||
- 替代传统基于 IP 的防火墙规则
|
||||
- 支持动态的安全策略执行
|
||||
- 通过 SCP 的"显式拒绝"逻辑强制执行标签合规性
|
||||
|
||||
## Use Case
|
||||
- 在 AWS Landing Zone 中实现基于标签的安全控制
|
||||
- 防止用户通过篡改标签绕过安全审计
|
||||
|
||||
## Related Concepts
|
||||
- [[Service Control Policies]]
|
||||
- [[Organizational Unit]]
|
||||
- [[Checkpoint Firewall]]
|
||||
- [[AWS Landing Zones]]
|
||||
|
||||
## Related Entities
|
||||
- [[AWS]]
|
||||
- [[Gruntwork]]
|
||||
22
wiki/concepts/WAF.md
Normal file
22
wiki/concepts/WAF.md
Normal file
@@ -0,0 +1,22 @@
|
||||
---
|
||||
title: "WAF (Web Application Firewall)"
|
||||
type: concept
|
||||
tags:
|
||||
- Security
|
||||
- AWS
|
||||
- Web-Protection
|
||||
date-added: 2026-04-18
|
||||
---
|
||||
|
||||
## Description
|
||||
Web Application Firewall(WAF)是一种保护 Web 应用免受常见攻击(如 SQL 注入、跨站脚本、XSS 等)的安全服务。在 SaaS Landing Zone 中,WAF 监控传入产品账号的流量。
|
||||
|
||||
## Role in SaaS Landing Zone
|
||||
- 监控 Product Accounts 的入站流量
|
||||
- 防护 Web 应用免受常见攻击
|
||||
- 可与 CloudFront 集成实现端到端安全
|
||||
|
||||
## Related
|
||||
- [[AWS]]:云服务提供商
|
||||
- [[CloudFront]]:CDN 服务
|
||||
- [[ctp-topic-7-saas-landing-zone-design]]:SaaS Landing Zone 设计
|
||||
27
wiki/concepts/列式存储.md
Normal file
27
wiki/concepts/列式存储.md
Normal file
@@ -0,0 +1,27 @@
|
||||
---
|
||||
title: "列式存储"
|
||||
type: concept
|
||||
tags: [存储, 数据仓库]
|
||||
sources: [ctp-topic-68-introduction-to-redshift]
|
||||
last_updated: 2026-04-18
|
||||
---
|
||||
|
||||
## Summary
|
||||
|
||||
列式存储(Columnar Storage)是一种将数据按列而不是按行存储的数据库存储方式,针对数据仓库操作进行了优化。
|
||||
|
||||
## Definition
|
||||
|
||||
- **优势**:更快的查询性能、更低的内存占用、更高的压缩效率
|
||||
- **适用场景**:OLAP 场景、大量聚合查询
|
||||
|
||||
## Key Benefits
|
||||
|
||||
- 按列读取特定列数据
|
||||
- 更高的压缩比(同一列数据类型相似)
|
||||
- 减少 I/O 操作
|
||||
- 提升聚合查询性能
|
||||
|
||||
## Connections
|
||||
|
||||
- [[AWS-Redshift]] → 使用 → [[列式存储]]
|
||||
38
wiki/entities/AWS-Redshift.md
Normal file
38
wiki/entities/AWS-Redshift.md
Normal file
@@ -0,0 +1,38 @@
|
||||
---
|
||||
title: "AWS Redshift"
|
||||
type: entity
|
||||
tags: [AWS, data-warehouse]
|
||||
sources: [ctp-topic-68-introduction-to-redshift]
|
||||
last_updated: 2026-04-18
|
||||
---
|
||||
|
||||
## Summary
|
||||
|
||||
AWS Redshift 是 Amazon 提供的完全托管的 PB 级云端数据仓库服务,专为数据仓库场景设计,支持 OLAP(在线分析处理)。
|
||||
|
||||
## Definition
|
||||
|
||||
- **类型**:数据仓库服务
|
||||
- **提供商**:AWS
|
||||
- **规模**:PB 级
|
||||
- **用途**:在线分析处理(OLAP),快速从大型数据集检索数据
|
||||
|
||||
## Key Attributes
|
||||
|
||||
- **架构类型**:Leader Node + Compute Node
|
||||
- **存储类型**:列式存储
|
||||
- **压缩**:支持 LZO 等压缩编码
|
||||
- **实例类型**:Dense Compute、Dense Storage、RA3
|
||||
|
||||
## Key Features
|
||||
|
||||
- 完全托管(Easy to install, maintain, backups)
|
||||
- 点时间恢复
|
||||
- 跨区域灾难恢复
|
||||
- 按使用量付费
|
||||
|
||||
## Connections
|
||||
|
||||
- [[AWS]] → 提供 → [[AWS-Redshift]]
|
||||
- [[AWS-Redshift]] → 管理通过 → [[Leader-Node]]
|
||||
- [[AWS-Redshift]] → 执行查询通过 → [[Compute-Node]]
|
||||
27
wiki/entities/Active-Directory.md
Normal file
27
wiki/entities/Active-Directory.md
Normal file
@@ -0,0 +1,27 @@
|
||||
---
|
||||
title: "Active Directory"
|
||||
type: entity
|
||||
tags:
|
||||
- Identity
|
||||
- Microsoft
|
||||
- Authentication
|
||||
date-added: 2026-04-18
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- AD
|
||||
- Windows Server AD
|
||||
|
||||
## Description
|
||||
Microsoft 的目录服务,提供身份验证和资源访问控制。在 SaaS Landing Zone 中,Active Directory Account 包含两个 AD 节点,用于域加入和控制资源访问。
|
||||
|
||||
## Role in Architecture
|
||||
- 支持 Windows 实例域加入
|
||||
- 身份验证和访问控制
|
||||
- 两个 AD 节点提供高可用性
|
||||
- 远程访问通过 AD 进行身份验证(从 Checkpoint VPN 迁移到 Pulse VPN)
|
||||
|
||||
## Related
|
||||
- [[Microsoft]]:开发公司
|
||||
- [[Domain Join]]:通过 SRE-provided AMIs 实现自动化域加入
|
||||
- [[ctp-topic-17-active-directory-services-in-gruntwork-aws-lzs]]:Gruntwork AWS Landing Zones 中的 AD 服务集成
|
||||
16
wiki/entities/Amazon-Inspector.md
Normal file
16
wiki/entities/Amazon-Inspector.md
Normal file
@@ -0,0 +1,16 @@
|
||||
---
|
||||
title: "Amazon Inspector"
|
||||
type: entity
|
||||
tags: [AWS, Security]
|
||||
---
|
||||
|
||||
## Definition
|
||||
Amazon Inspector 是 AWS 的自动化安全漏洞扫描服务,用于评估 AWS 资源的安全性和合规性。
|
||||
|
||||
## Functions
|
||||
- 漏洞扫描
|
||||
- 安全合规评估
|
||||
- 自动化测试集成
|
||||
|
||||
## Connections
|
||||
- 与 Standard AMI 集成,用于镜像验证
|
||||
32
wiki/entities/CCOE.md
Normal file
32
wiki/entities/CCOE.md
Normal file
@@ -0,0 +1,32 @@
|
||||
---
|
||||
title: "CCOE (Cloud Center of Excellence)"
|
||||
type: entity
|
||||
tags:
|
||||
- AWS
|
||||
- Cloud Governance
|
||||
aliases:
|
||||
- Cloud Center of Excellence
|
||||
---
|
||||
|
||||
## Definition
|
||||
CCOE(Cloud Center of Excellence,云端卓越中心)是推动云采纳和治理的核心组织单元,负责制定云标准、发布标准化 AMI、管理云最佳实践。
|
||||
|
||||
## Role in CTP
|
||||
- 每两个月发布一次符合安全标准的加固 AMI
|
||||
- 管理 AMI 路线图(Roadmap),规划新操作系统的添加
|
||||
- 通过 CCOE 通知邮件列表(PDL)发送 AMI 变更通知
|
||||
- 提供 Change Log,记录与上一版本的变更内容
|
||||
|
||||
## Key Activities
|
||||
- AMI 标准制定和安全加固
|
||||
- 操作系统生命周期管理(EOL 跟踪)
|
||||
- 新 AMI 集成验证流程
|
||||
- 与组织内各团队协调需求
|
||||
|
||||
## Related Concepts
|
||||
- [[Standard AMI]]
|
||||
- [[AMI-End-of-Life]]
|
||||
- [[EC2-Image-Builder]]
|
||||
|
||||
## Last Updated
|
||||
2026-04-18
|
||||
17
wiki/entities/Cloud-Technology-Design-Forum.md
Normal file
17
wiki/entities/Cloud-Technology-Design-Forum.md
Normal file
@@ -0,0 +1,17 @@
|
||||
---
|
||||
title: "Cloud Technology Design Forum"
|
||||
type: entity
|
||||
tags: [cloud, organization, micro-focus]
|
||||
---
|
||||
|
||||
## Summary
|
||||
Cloud Technology Design Forum 是微焦点(Micro Focus)内部的组织,旨在标准化和集中化其云交付产品,包括 Landing Zone 设计。
|
||||
|
||||
## Role
|
||||
- 组织内部用于推动云架构标准化的核心团队
|
||||
- 负责定义和维护企业级云交付标准
|
||||
|
||||
## Connections
|
||||
- [[Gruntwork Landing Zone]] — 提供参考架构标准
|
||||
- [[AWS]] — 云平台提供商
|
||||
- [[Gruntwork]] — Landing Zone 框架提供商
|
||||
24
wiki/entities/Compute-Node.md
Normal file
24
wiki/entities/Compute-Node.md
Normal file
@@ -0,0 +1,24 @@
|
||||
---
|
||||
title: "Compute Node"
|
||||
type: entity
|
||||
tags: [AWS, Redshift]
|
||||
sources: [ctp-topic-68-introduction-to-redshift]
|
||||
last_updated: 2026-04-18
|
||||
---
|
||||
|
||||
## Summary
|
||||
|
||||
Redshift 架构中的计算节点,负责实际查询执行。
|
||||
|
||||
## Definition
|
||||
|
||||
Redshift 集群中执行查询的节点,查询在切片(slice)上处理数据。
|
||||
|
||||
## Key Attributes
|
||||
|
||||
- **职责**:执行查询、处理数据、返回结果到 Leader Node
|
||||
- **资源**:取决于实例类型(CPU、RAM、存储)
|
||||
|
||||
## Connections
|
||||
|
||||
- [[AWS-Redshift]] → 使用 → [[Compute-Node]]
|
||||
28
wiki/entities/Infoblox.md
Normal file
28
wiki/entities/Infoblox.md
Normal file
@@ -0,0 +1,28 @@
|
||||
---
|
||||
title: "Infoblox"
|
||||
type: entity
|
||||
tags:
|
||||
- DNS
|
||||
- DHCP
|
||||
- Network
|
||||
---
|
||||
|
||||
## Definition
|
||||
Infoblox 是一家专注于 DNS、DHCP 和 IP 地址管理(IPAM)解决方案的企业软件公司。其核心产品包括 NIOS(Network Infrastructure Operating System)和 Infoblox Grid 架构。
|
||||
|
||||
## Key Products
|
||||
- **NIOS**:Infoblox 网络基础设施操作系统,运行在 Infoblox 设备上
|
||||
- **Infoblox Grid**:分布式架构,通过 Grid Master 统一管理全球分布的 DNS/DHCP 器具,确保配置的一致性和高可用性
|
||||
|
||||
## Key Capabilities
|
||||
- **DNS Anycast**:通过 DNS Anycast 技术实现全球范围内的低延迟和自动故障转移
|
||||
- **DNS Security**:防护 DNS 隧道攻击、数据外泄、缓存污染等高级威胁
|
||||
- **DHCP Automation**:自动化 IP 地址分配和管理
|
||||
|
||||
## Use Cases
|
||||
- 企业内网 DNS 服务
|
||||
- DNS 安全防护
|
||||
- IP 地址管理(IPAM)
|
||||
|
||||
## Connections
|
||||
- [[DNS-Anycast]] ← provided_by ← Infoblox
|
||||
25
wiki/entities/Jenkins.md
Normal file
25
wiki/entities/Jenkins.md
Normal file
@@ -0,0 +1,25 @@
|
||||
---
|
||||
title: "Jenkins"
|
||||
type: entity
|
||||
tags:
|
||||
- CI/CD
|
||||
- Automation
|
||||
- DevOps
|
||||
date-added: 2026-04-18
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- Jenkins CI
|
||||
- Jenkins Server
|
||||
|
||||
## Description
|
||||
开源自动化服务器,主要用于持续集成(CI)和持续交付(CD)。在 SaaS Landing Zone 架构中,Shared Account 托管主 Jenkins 服务器,通过 Lambda 函数触发各账号的 Jenkins slaves 执行部署任务。
|
||||
|
||||
## Role in Architecture
|
||||
- 主 Jenkins 服务器位于 Shared Account,负责管理部署流程
|
||||
- 通过 Lambda 函数在各账号触发 Jenkins slaves
|
||||
- 增强安全性:主 Jenkins 不直接暴露给 jobs 或 credentials
|
||||
|
||||
## Related
|
||||
- [[Terraform]]:用于基础设施即代码部署
|
||||
- [[Gruntwork Landing Zone]]:参考架构
|
||||
22
wiki/entities/Kishore-Garlopati.md
Normal file
22
wiki/entities/Kishore-Garlopati.md
Normal file
@@ -0,0 +1,22 @@
|
||||
---
|
||||
title: Kishore Garlopati
|
||||
type: entity
|
||||
tags: [person]
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Summary
|
||||
- 角色:讲师
|
||||
- 组织:Micro Focus
|
||||
- 贡献:介绍 Azure Landing Zone 架构设计与实现
|
||||
|
||||
## Key Facts
|
||||
- 在 CTP Topic 34 中讲解 Azure Landing Zone Architecture Overview
|
||||
- 阐述了在 Micro Focus 实施 Azure Landing Zone 的目标和策略
|
||||
|
||||
## Connections
|
||||
- [[Micro Focus]] ← works_at ← [[Kishore Garlopati]]
|
||||
- [[Kishore Garlopati]] ← presents ← [[Azure Landing Zone]]
|
||||
|
||||
## Aliases
|
||||
- Kishore
|
||||
23
wiki/entities/Leader-Node.md
Normal file
23
wiki/entities/Leader-Node.md
Normal file
@@ -0,0 +1,23 @@
|
||||
---
|
||||
title: "Leader Node"
|
||||
type: entity
|
||||
tags: [AWS, Redshift]
|
||||
sources: [ctp-topic-68-introduction-to-redshift]
|
||||
last_updated: 2026-04-18
|
||||
---
|
||||
|
||||
## Summary
|
||||
|
||||
Redshift 集群中的领导节点,负责 schema 管理、元数据存储和查询规划。
|
||||
|
||||
## Definition
|
||||
|
||||
Redshift 架构中的主节点,负责协调查询规划和结果返回。
|
||||
|
||||
## Key Attributes
|
||||
|
||||
- **职责**:Schema 管理、元数据存储、查询规划、指令分发、结果存储
|
||||
|
||||
## Connections
|
||||
|
||||
- [[AWS-Redshift]] → 使用 → [[Leader-Node]]
|
||||
24
wiki/entities/Pradeep.md
Normal file
24
wiki/entities/Pradeep.md
Normal file
@@ -0,0 +1,24 @@
|
||||
---
|
||||
id: Pradeep
|
||||
title: "Pradeep"
|
||||
type: entity
|
||||
tags:
|
||||
- AWS
|
||||
- Landing-Zone
|
||||
- CTP
|
||||
- Checkpoint
|
||||
date_added: 2026-04-18
|
||||
---
|
||||
|
||||
## Profile
|
||||
- **Role:** AWS Landing Zone 技术分享主讲人
|
||||
- **Affiliation:** Cloud Transformation Program (CTP)
|
||||
- **Topic:** Checkpoint 防火墙的有序层逻辑
|
||||
|
||||
## Notes
|
||||
- 在 CTP Topic 10 中演示 Checkpoint 防火墙的 Ordered Layer 逻辑
|
||||
- 讲解防火墙如何根据标签对流量进行分层过滤
|
||||
- 包括地理屏蔽、BU 隔离、产品隔离及环境隔离
|
||||
|
||||
## Aliases
|
||||
- Pradeep
|
||||
24
wiki/entities/Route-53.md
Normal file
24
wiki/entities/Route-53.md
Normal file
@@ -0,0 +1,24 @@
|
||||
---
|
||||
title: "Route 53"
|
||||
type: entity
|
||||
tags:
|
||||
- DNS
|
||||
- AWS
|
||||
date-added: 2026-04-18
|
||||
---
|
||||
|
||||
## Aliases
|
||||
- Amazon Route 53
|
||||
- AWS DNS
|
||||
|
||||
## Description
|
||||
Amazon 的 DNS 服务,在 SaaS Landing Zone 中,DNS Account 托管 Route 53,每个产品拥有自己的托管区域(Hosted Zone)用于管理 DNS 记录。
|
||||
|
||||
## Role in Architecture
|
||||
- 集中式 DNS 管理
|
||||
- 每个产品拥有独立的托管区域
|
||||
- 支持公有和私有托管区域
|
||||
|
||||
## Related
|
||||
- [[AWS]]:云服务提供商
|
||||
- [[ctp-topic-7-saas-landing-zone-design]]:SaaS Landing Zone 设计
|
||||
26
wiki/entities/Standard-AMI.md
Normal file
26
wiki/entities/Standard-AMI.md
Normal file
@@ -0,0 +1,26 @@
|
||||
---
|
||||
title: "Standard AMI"
|
||||
type: entity
|
||||
tags: [AWS, Cloud, Infrastructure]
|
||||
---
|
||||
|
||||
## Definition
|
||||
Standard AMI (Amazon Machine Image) 是 AWS 的标准化机器镜像,包含 OS 加固、最新安全补丁和补丁更新,并支持域集成、安全工具、端点保护、SSM agent、DNS 设置。
|
||||
|
||||
## Specifications
|
||||
- 每两个月构建、测试并发布
|
||||
- 支持 23 种不同操作系统
|
||||
- 最新三个版本在 12 个区域可用
|
||||
- 旧版本存档 12 个月
|
||||
|
||||
## Functions
|
||||
- OS 加固
|
||||
- 安全更新
|
||||
- 域集成
|
||||
- SSM agent 集成
|
||||
- DNS 设置
|
||||
|
||||
## Connections
|
||||
- 构建工具:[[EC2 Image Builder]]
|
||||
- 测试工具:[[Amazon Inspector]]
|
||||
- CI/CD:[[Jenkins]]
|
||||
23
wiki/entities/Steve-Jarman.md
Normal file
23
wiki/entities/Steve-Jarman.md
Normal file
@@ -0,0 +1,23 @@
|
||||
---
|
||||
id: Steve-Jarman
|
||||
title: "Steve Jarman"
|
||||
type: entity
|
||||
tags:
|
||||
- AWS
|
||||
- Landing-Zone
|
||||
- CTP
|
||||
date_added: 2026-04-18
|
||||
---
|
||||
|
||||
## Profile
|
||||
- **Role:** AWS Landing Zone 技术分享主讲人
|
||||
- **Affiliation:** Cloud Transformation Program (CTP)
|
||||
- **Topic:** AWS Landing Zones 部署流程、数据收集策略、标签安全控制
|
||||
|
||||
## Notes
|
||||
- 在 CTP Topic 10 中介绍 Landing Zone 的规划与自动化
|
||||
- 强调在部署前必须深入了解业务部门(BU)的资产清单、IP 地址空间及数据敏感性
|
||||
- 提及 DNS、Transit Gateway 等基础服务的创建已通过 SRE 团队实现了高度自动化
|
||||
|
||||
## Aliases
|
||||
- Steve Jarman
|
||||
@@ -39,8 +39,16 @@
|
||||
|
||||
- [Never write another prompt](sources/never-write-another-prompt.md) — 通过工具简化 AI 提示词创建流程
|
||||
|
||||
- [CTP Topic 34 Azure Landing Zone Architecture Overview](sources/ctp-topic-34-azure-landing-zone-architecture-overview.md) — Azure Landing Zone 架构设计,Management Groups、Subscription 分离、Terraform Cloud 自动化
|
||||
|
||||
- [CTP Topic 46 NetApps on AWS](sources/ctp-topic-46-netapps-on-aws.md) — NetApp on AWS (CVO) 架构、部署、数据分层、安全与迁移
|
||||
|
||||
- [CTP Topic 58 AWS EC2 Image Builder](sources/ctp-topic-58-aws-ec2-image-builder.md) — AWS EC2 Image Builder 服务,用于自动创建、管理和分发 AMIs 和 Docker 镜像
|
||||
|
||||
- [CTP Topic 26 Standard AMI – build, publish, share processes](sources/ctp-topic-26-standard-ami-build-publish-share-processes.md) — Foundation AMI 的构建、加固与分发流程
|
||||
|
||||
- [CTP Topic 50 AMI Roadmap for AWS AMIs](sources/ctp-topic-50-ami-roadmap-for-aws-amis.md) — AWS AMI 路线图与 CCOE 标准化 AMI 发布计划
|
||||
|
||||
- [养虾日记1:我用 OpenClaw 管了 28 万张照片:一次真实的多设备照片整理实战](sources/养虾日记1-我用-OpenClaw-管了-28-万张照片-一次真实的多设备照片整理实战.md) — 利用 AI Agent 自动化整理 28 万张照片(MD5 去重 + 批次任务 + Cron 定时执行)
|
||||
|
||||
- [教學 ChatGPT 先做知識整理,再讓 Canva、 Gamma AI 輸出簡報](sources/jiao-xue-chatgpt-xian-zuo-zhi-shi-zheng-li-zai-rang-canva-gamma-ai-shu-chu-jian-bao.md) — AI 简报制作四阶段工作流(ChatGPT 资料研究 + Canva/Gamma 设计)
|
||||
@@ -254,20 +262,39 @@
|
||||
|
||||
- [CTP Topic 28 AWS Tag Validation Tool](sources/ctp-topic-28-aws-tag-validation-tool.md) — AWS 标签验证工具,用于审计资源标签合规性
|
||||
|
||||
- [CTP Topic 22 Global DNS service offerings](sources/ctp-topic-22-global-dns-service-offerings.md) — AWS 云 DNS 服务架构与混合云 DNS 设计方案
|
||||
|
||||
- [CTP Topic 66 Exposing the differences between PostgreSQL RDS and Aurora](sources/ctp-topic-66-exposing-the-differences-between-postgresql-rds-and-aurora.md) — PostgreSQL on RDS 与 Aurora 的详细对比(架构、性能、成本、故障切换)
|
||||
|
||||
- [CTP Topic 72 Implementing an Enterprise DR Strategy using AWS Backup](sources/ctp-topic-72-implementing-an-enterprise-dr-strategy-using-aws-backup.md) — 使用 AWS Backup 实现企业级灾难恢复策略
|
||||
|
||||
- [CTP Topic 73 AWS Backup implementation of the Cloud Transformation Program](sources/ctp-topic-73-aws-backup-implementation-of-the-cloud-transformation-program.md) — AWS Backup 在 CTP 云转型计划中的实施
|
||||
|
||||
- [CTP Topic 68 Introduction to Redshift](sources/ctp-topic-68-introduction-to-redshift.md) — AWS Redshift 数据仓库架构与核心组件(MPP、列式存储、Leader Node、Compute Node)
|
||||
|
||||
- [CTP Topic 17 Active Directory Services in Gruntwork AWS LZs](sources/ctp-topic-17-active-directory-services-in-gruntwork-aws-lzs.md) — 在 Gruntwork AWS Landing Zones 中集成 Active Directory 服务实践
|
||||
|
||||
- [CTP Topic 25 Labs Landing Zone overview - ITOM teams](sources/ctp-topic-25-labs-landing-zone-overview-itom-teams.md) — Labs Landing Zone 架构概述,基于 Gruntwork reference architecture
|
||||
|
||||
- [CTP Topic 51 Architecting with AWS Purpose-Built Databases](sources/ctp-topic-51-architecting-with-aws-purpose-built-databases.md) — AWS 专用数据库架构,选择合适的数据库服务
|
||||
|
||||
- [CTP Topic 47 Enterprise Architecture Cloud Standards](sources/ctp-topic-47-enterprise-architecture-cloud-standards.md) — 企业云架构标准、Landing Zone 框架与 Cloud Guardrails
|
||||
|
||||
## Sources
|
||||
- [CTP Topic 40 SaaS Database Architecture On AWS Cloud](sources/ctp-topic-40-saas-database-architecture-on-aws-cloud.md) — AWS 云上 SaaS 数据库架构,SaaS 数据库团队全球运维实践
|
||||
|
||||
- [Learning Sessions Standard AMIs Updates 20231205](sources/learning-sessions-standard-amis-updates-20231205-160324-meeting-recording-2.md) — AWS Standard AMIs 概述、更新和发布流程(每两个月发布、支持 23 种操作系统)
|
||||
|
||||
- [CTP Topic 1 Gruntwork Landing Zone Architecture](sources/ctp-topic-1-gruntwork-landing-zone-architecture.md) — 基于 Gruntwork 的 AWS Landing Zone 架构设计
|
||||
- [CTP Topic 10 AWS Landing Zone (LZ) Data Collection, Tagging Related Security](sources/ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security.md) — AWS Landing Zone 部署流程、数据收集策略、基于标签的安全控制机制
|
||||
- [CTP Topic 35 AWS Landing Zone Design Refresher (SaaS Labs)](sources/ctp-topic-35-aws-landing-zone-design-refresher-saas-labs.md) — AWS Landing Zone 设计更新,SaaS(生产)与 Labs(开发)环境区分
|
||||
|
||||
- [CTP Topic 7 SaaS Landing Zone Design](sources/ctp-topic-7-saas-landing-zone-design.md) — 生产环境 SaaS Landing Zone 高级设计,单一 Landing Zone 策略
|
||||
|
||||
## Entities
|
||||
- [CCOE](entities/CCOE.md) — Cloud Center of Excellence,推动云采纳和治理的核心组织单元
|
||||
- [Kishore Garlopati](entities/Kishore-Garlopati.md) — Azure Landing Zone 技术分享主讲人
|
||||
- [Pradeep](entities/Pradeep.md) — AWS Landing Zone 技术分享主讲人,Checkpoint 防火墙专家
|
||||
- [Holger Rode](entities/Holger-Rode.md) — Octane Hub CTO 软件工厂团队负责人
|
||||
- [Femi George](entities/Femi-George.md) — AWS 数据库销售专家,CTP Topic 51 主讲人
|
||||
- [Duolingo](entities/Duolingo.md) — 案例公司,使用 DynamoDB + ElastiCache + Aurora
|
||||
@@ -297,6 +324,9 @@
|
||||
- [BMC](entities/BMC.md) — 企业软件和云解决方案提供商
|
||||
- [NetApp](entities/NetApp.md) — 企业级存储解决方案提供商,Cloud Volume ONTAP (CVO) 产品
|
||||
- [AWS](entities/AWS.md) — 全球最大公有云平台(EKS、RDS、S3、Lambda 等)
|
||||
- [AWS Redshift](entities/AWS-Redshift.md) — Amazon 提供的 PB 级云端数据仓库服务,支持 OLAP
|
||||
- [Leader Node](entities/Leader-Node.md) — Redshift 集群的领导节点,负责查询规划和结果返回
|
||||
- [Compute Node](entities/Compute-Node.md) — Redshift 架构中的计算节点,执行实际查询
|
||||
- [Aurora](entities/Aurora.md) — Amazon 自研云原生关系型数据库,6 个 EBS 卷跨 3 个 AZ
|
||||
- [Amazon DynamoDB](entities/Amazon-DynamoDB.md) — 键值和文档数据库,单数字毫秒延迟,支持每日数万亿请求
|
||||
- [Amazon DocumentDB](entities/Amazon-DocumentDB.md) — MongoDB 兼容文档数据库
|
||||
@@ -305,8 +335,13 @@
|
||||
- [Amazon Timestream](entities/Amazon-Timestream.md) — 时序数据库,专为 IoT 设计
|
||||
- [Amazon Keyspaces](entities/Amazon-Keyspaces.md) — Apache Cassandra 托管服务
|
||||
- [Gruntwork](entities/Gruntwork.md) — Gruntwork Landing Zones 框架提供商,定义 R&D 和 SAS 环境域名规范
|
||||
- [Infoblox](entities/Infoblox.md) — 企业级 DNS/DHCP 和 IPAM 解决方案提供商
|
||||
- [Active-Directory](entities/Active-Directory.md) — Microsoft 目录服务,提供 DNS 和身份验证
|
||||
- [Jenkins](entities/Jenkins.md) — 开源自动化服务器,用于 CI/CD,Shared Account 托管主 Jenkins 服务器
|
||||
- [swinford.net](entities/swinford-net.md) — R&D Labs 环境 Active Directory 域名
|
||||
- [intsas.local](entities/intsas-local.md) — SAS 生产环境 Active Directory 域名
|
||||
- [Route 53](entities/Route-53.md) — AWS DNS 服务,每个产品拥有独立托管区域
|
||||
- [Active Directory](entities/Active-Directory.md) — Microsoft 目录服务,提供身份验证和资源访问控制
|
||||
- [MIM](entities/MIM.md) — R&D 环境的安全组管理和权限申请自助服务解决方案
|
||||
- [SMACKS Ticket](entities/SMACKS-Ticket.md) — 内部服务管理工单系统,用于生产环境账号申请和密码重置
|
||||
- [GCP](entities/GCP.md) — Google Cloud Platform(GKE、GCS、Cloud SQL 等)
|
||||
@@ -327,6 +362,7 @@
|
||||
- [HIPAA](entities/HIPAA.md) — 美国健康保险便携性和责任法案
|
||||
- [GDPR](entities/GDPR.md) — 欧盟通用数据保护条例
|
||||
- [Open Alliance for Cloud Adoption (OACA)](entities/Open-Alliance-for-Cloud-Adoption-OACA.md) — 提出云成熟度模型定义的组织
|
||||
- [Cloud Technology Design Forum](entities/Cloud-Technology-Design-Forum.md) — 微焦点内部云架构标准化组织
|
||||
- [GitHub](entities/GitHub.md) — 全球最大代码托管平台
|
||||
- [OWASP](entities/OWASP.md) — Web 安全标准和 Top Ten 漏洞列表
|
||||
- [SonarQube](entities/SonarQube.md) — 开源代码质量和安全分析平台
|
||||
@@ -465,18 +501,38 @@
|
||||
|
||||
## Concepts
|
||||
- [Service Control Policies](concepts/Service-Control-Policies.md) — AWS Organizations 的策略类型,管理组织内账户的最大权限边界
|
||||
- [Management Groups](concepts/Management-Groups.md) — Azure 组织管理结构,用于组织和管理多个订阅的分层容器
|
||||
- [Subscription](concepts/Subscription.md) — Azure 资源隔离的基本容器,每个订阅有独立的配额和访问控制
|
||||
- [PIM(Privileged Identity Management)](concepts/PIM-Privileged-Identity-Management.md) — Azure 特权身份管理,控制提升权限的访问
|
||||
|
||||
- [Tagging Methodology](concepts/Tagging-Methodology.md) — 标签方法论,通过为资源定义标准化的元数据(如 Owner, BU, Product, Environment),作为自动化管理和安全策略执行的基础
|
||||
|
||||
- [Checkpoint Firewall](concepts/Checkpoint-Firewall.md) — 部署在云环境中的虚拟防火墙,通过集成 AWS 标签实现动态的对象识别和流量过滤
|
||||
- [WAF (Web Application Firewall)](concepts/WAF.md) — Web 应用防火墙,保护 Web 应用免受常见攻击
|
||||
- [CloudFront](concepts/CloudFront.md) — AWS 内容分发网络(CDN),加速静态内容分发
|
||||
|
||||
- [Ordered Layer](concepts/Ordered-Layer.md) — 有序层,防火墙策略的一种组织方式,按顺序执行地理屏蔽、BU 隔离、环境隔离等逻辑
|
||||
|
||||
- [Boto3](concepts/Boto3.md) — AWS SDK for Python,允许通过 Python 代码调用 AWS API
|
||||
|
||||
- [Gruntwork Landing Zone](concepts/Gruntwork-Landing-Zone.md) — Gruntwork 提供的预配置 AWS 基础架构框架,分为 R&D Labs(swinford.net)和 SAS(intsas.local)环境
|
||||
- [Enterprise Architecture](concepts/Enterprise-Architecture.md) — 企业架构,帮助阐明云架构并传达可用资源
|
||||
- [Cloud Guardrails](concepts/Cloud-Guardrails.md) — 云守护栏,捕获可扩展性、成本最小化和灵活性的强制性要求
|
||||
- [Route 53 Private Hosted Zone](concepts/Route-53-Private-Hosted-Zone.md) — AWS 私有托管区域,仅对指定 VPC 可见
|
||||
- [Route 53 Resolver Endpoint](concepts/Route-53-Resolver-Endpoint.md) — Route 53 入站/出站终端节点
|
||||
- [DNS Anycast](concepts/DNS-Anycast.md) — DNS 寻址和路由方法,共享 IP 地址实现低延迟和高可用
|
||||
- [IPAM](concepts/IPAM.md) — IP 地址管理工具,用于规划、追踪和管理 IP 地址空间
|
||||
- [Hybrid DNS Resolution](concepts/Hybrid-DNS-Resolution.md) — 混合云 DNS 解析机制
|
||||
- [Domain Join](concepts/Domain-Join.md) — 通过 SRE-provided AMIs 实现自动化将 Windows/Linux 实例加入 AD 域的技术
|
||||
- [Cloud Volume ONTAP](concepts/Cloud-Volume-ONTAP.md) — NetApp 云端存储解决方案,运行在 AWS EC2 实例上,支持数据分层到 S3
|
||||
- [SRE-provided AMIs](concepts/SRE-provided-AMIs.md) — SRE 团队预构建的机器镜像,内置自动域加入脚本
|
||||
- [语义形状系统](concepts/语义形状系统.md) — fireworks-tech-graph 将语义概念映射为固定 SVG 形状的词汇表
|
||||
- [Purpose-Built Database](concepts/Purpose-Built-Database.md) — 专用数据库,根据用例选择最佳工具而非一刀切
|
||||
|
||||
- [MPP](concepts/MPP.md) — 大规模并行处理技术,使查询跨多个计算节点并行执行
|
||||
- [OLAP](concepts/OLAP.md) — 在线分析处理,用于复杂查询和决策支持的数据库技术
|
||||
- [列式存储](concepts/列式存储.md) — 按列存储数据的数据库存储方式,针对数据仓库操作优化
|
||||
|
||||
- [记忆后端](concepts/记忆后端.md) — Camp 1 类别的记忆工具,从对话中提取事实并存储到向量数据库
|
||||
- [上下文基质](concepts/上下文基质.md) — Camp 2 类别的记忆架构,通过维护结构化文件实现上下文累积
|
||||
|
||||
|
||||
114
wiki/log.md
114
wiki/log.md
@@ -1,3 +1,93 @@
|
||||
## [2026-04-18] ingest | CTP Topic 22 Global DNS service offerings
|
||||
- Source file: raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-22-global-dns-service-offerings.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: AWS 云环境与本地数据中心的混合云 DNS 设计方案,Route 53 Private Hosted Zones + Resolver Endpoints,Infoblox DNS Anycast 对比
|
||||
- Concepts created: Route 53 Private Hosted Zone(新增), Route 53 Resolver Endpoint(新增), DNS Anycast(新增), IPAM(新增), Hybrid DNS Resolution(新增)
|
||||
- Entities created: Infoblox(新增), Active-Directory(已有), Route 53(已有)
|
||||
- Source page: wiki/sources/ctp-topic-22-global-dns-service-offerings.md
|
||||
- Notes:
|
||||
|
||||
## [2026-04-18] ingest | CTP Topic 50 AMI Roadmap for AWS AMIs
|
||||
- Source file: raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-50-ami-roadmap-for-aws-amis.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: AWS AMI 路线图与 CCOE 标准化 AMI 发布计划,涵盖当前支持的 AMI 版本、EOL 时间表、新 AMI 添加流程
|
||||
- Concepts created: AMI Roadmap(新增), AMI-End-of-Life(已有)
|
||||
- Entities created: CCOE(新增)
|
||||
- Source page: wiki/sources/ctp-topic-50-ami-roadmap-for-aws-amis.md
|
||||
- Notes:
|
||||
|
||||
## [2026-04-18] ingest | CTP Topic 40 SaaS Database Architecture On AWS Cloud
|
||||
- Source file: raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-40-saas-database-architecture-on-aws-cloud.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: AWS 云上 SaaS 数据库架构设计,SaaS 数据库团队全球运维实践,管理 500+ 数据库和 1000+ 服务器,支持 Oracle、Postgres、DynamoDB 等多种数据库,使用 Oracle Data Guard、Postgres Active-Passive 实现高可用
|
||||
- Concepts created: Multi-Tenant Management(已有), High-Availability(已有), 故障转移(已有)
|
||||
- Entities created: AWS(已有), Amazon Aurora(已有), Amazon DynamoDB(已有), Amazon ElastiCache(已有), Oracle(已有), PostgreSQL(已有)
|
||||
- Source page: wiki/sources/ctp-topic-40-saas-database-architecture-on-aws-cloud.md
|
||||
- Notes:
|
||||
|
||||
## [2026-04-18] ingest | CTP Topic 25 Labs Landing Zone overview - ITOM teams
|
||||
- Source file: raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-25-labs-landing-zone-overview-itom-teams.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: Labs Landing Zone 架构概述,基于 Gruntwork reference architecture,ITOM 团队视角,多账号策略,Terraform IaC 管理
|
||||
- Concepts created: Gruntwork Landing Zone(已有), Multi-Account Strategy(已有), Infrastructure as Code(已有), Terraform(已有), Transit Gateway(已有), Service Control Policies(已有)
|
||||
- Entities created: Gruntwork(已有), Jenkins(已有), swinford.net(已有), AWS(已有)
|
||||
- Source page: wiki/sources/ctp-topic-25-labs-landing-zone-overview-itom-teams.md
|
||||
- Notes:
|
||||
|
||||
## [2026-04-18] ingest | CTP Topic 7 SaaS Landing Zone Design
|
||||
- Source file: raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-7-saas-landing-zone-design.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: 生产环境 SaaS Landing Zone 高级设计,单一 Landing Zone 策略,Core/Baseline/Shared Services 账户分离,Terraform 模块化部署
|
||||
- Concepts created: WAF (Web Application Firewall)(新增), CloudFront(新增), Multi-Account Strategy(已有), Gruntwork Landing Zone(已有), Domain Join(已有), SRE-provided AMIs(已有)
|
||||
- Entities created: Jenkins(新增), Route 53(新增), Active Directory(新增), AWS(已有), Gruntwork(已有), Cloud Technology Design Forum(已有)
|
||||
- Source page: wiki/sources/ctp-topic-7-saas-landing-zone-design.md
|
||||
- Notes:
|
||||
|
||||
## [2026-04-18] ingest | CTP Topic 34 Azure Landing Zone Architecture Overview
|
||||
- Source file: raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-34-azure-landing-zone-architecture-overview.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: Azure Landing Zone 架构设计,Management Groups 四区域划分、Subscription 分离、Terraform Cloud 自动化
|
||||
- Concepts created: Management Groups(新增), Subscription(新增), PIM(Privileged Identity Management)(新增)
|
||||
- Entities created: Kishore Garlopati(新增), Azure(已有), Azure Active Directory(已有), Checkpoint Firewall(已有)
|
||||
- Source page: wiki/sources/ctp-topic-34-azure-landing-zone-architecture-overview.md
|
||||
- Notes:
|
||||
|
||||
## [2026-04-18] ingest | CTP Topic 35 AWS Landing Zone Design Refresher (SaaS Labs)
|
||||
- Source file: raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-35-aws-landing-zone-design-refresher-saas-labs.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: AWS Landing Zone 设计更新,区分 SaaS(生产)和 Labs(开发)环境,明确 Gruntwork Landing Zone 账户结构
|
||||
- Concepts created: Gruntwork Landing Zone(已有), Multi-Account Strategy(已有), Cloud Guardrails(已有), Infrastructure as Code(已有)
|
||||
- Entities created: Gruntwork(已有), AWS(已有), Cloud Technology Design Forum(新增)
|
||||
- Source page: wiki/sources/ctp-topic-35-aws-landing-zone-design-refresher-saas-labs.md
|
||||
- Notes:
|
||||
|
||||
## [2026-04-18] ingest | CTP Topic 10 AWS Landing Zone (LZ) Data Collection, Tagging Related Security
|
||||
- Source file: raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: AWS Landing Zone 部署流程、数据收集策略、基于标签的安全控制机制,涵盖 Checkpoint 防火墙有序层逻辑
|
||||
- Concepts created: Tagging Methodology(新增), Checkpoint Firewall(新增), Ordered Layer(新增)
|
||||
- Entities created: Steve Jarman(新增), Pradeep(新增)
|
||||
- Source page: wiki/sources/ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security.md
|
||||
- Notes:
|
||||
|
||||
## [2026-04-18] ingest | CTP Topic 73 AWS Backup implementation of the Cloud Transformation Program
|
||||
- Source file: raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-73-aws-backup-implementation-of-the-cloud-transformation-program.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: AWS Backup 在 CTP 云转型计划中的实施,涵盖 SRE 备份模型、DR 账户备份、AWS Backup Audit Manager 审计
|
||||
- Concepts created: SRE(已有)
|
||||
- Entities created: AWS(已有), CTP(已有)
|
||||
- Source page: wiki/sources/ctp-topic-73-aws-backup-implementation-of-the-cloud-transformation-program.md
|
||||
- Notes:
|
||||
|
||||
## [2026-04-18] ingest | Learning Sessions Standard AMIs Updates 20231205
|
||||
- Source file: raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/learning-sessions-standard-amis-updates-20231205-160324-meeting-recording-2.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: AWS Standard AMIs 概述、更新和发布流程,每两个月发布,支持 23 种操作系统,包含 OS 加固、SSM agent、DNS 设置
|
||||
- Concepts created: Standard AMI(新增), AMI End-of-Life(新增), EC2 Image Builder(新增)
|
||||
- Entities created: Standard AMI(新增), Amazon Inspector(新增)
|
||||
- Source page: wiki/sources/learning-sessions-standard-amis-updates-20231205-160324-meeting-recording-2.md
|
||||
- Notes:
|
||||
|
||||
## [2026-04-18] ingest | CTP Topic 72 Implementing an Enterprise DR Strategy using AWS Backup
|
||||
- Source file: raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-72-implementing-an-enterprise-dr-strategy-using-aws-backup.md
|
||||
- Status: ✅ 成功摄入
|
||||
@@ -1761,3 +1851,27 @@
|
||||
- Source page: wiki/sources/ctp-topic-28-aws-tag-validation-tool.md
|
||||
- Notes: 与 Gruntwork Landing Zone 关联,标签验证用于 Landing Zone 治理
|
||||
|
||||
|
||||
## [2026-04-18] ingest | CTP Topic 58 AWS EC2 Image Builder
|
||||
- Source file: raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-58-aws-ec2-image-builder.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: AWS EC2 Image Builder 服务,用于自动创建、管理和分发 AMIs 和 Docker 镜像,涵盖 Image Pipeline、Image Recipe、Component、Infrastructure Configuration 和 Distribution Settings
|
||||
- Concepts created: EC2 Image Builder(已有), Infrastructure as Code(已有), CI/CD Pipeline(已有)
|
||||
- Entities created: AWS(已有), Terraform(已有), CTP(已有), Amazon Inspector(已有)
|
||||
- Source page: wiki/sources/ctp-topic-58-aws-ec2-image-builder.md
|
||||
- Notes: 解决当前 AMI 构建流程的效率问题,提供测试、安全加固和跨账号分发能力
|
||||
|
||||
## [2026-04-18] ingest | CTP Topic 26 Standard AMI – build, publish, share processes
|
||||
- Source file: raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-26-standard-ami-build-publish-share-processes.md
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: Foundation AMI 的构建、加固与分发流程,涵盖 HashiCorp Packer + Jenkins 自动化构建流水线、CIS 安全基准、AMI Sharing 跨账号共享机制、N-2 版本保留策略
|
||||
- Concepts created: Foundation AMI(新增), OS Hardening(新增), CIS Benchmarks(新增), AMI Sharing(新增)
|
||||
- Entities created: CCOE(已有), Jenkins(已有), AWS(已有), Standard AMI(已有)
|
||||
- Source page: wiki/sources/ctp-topic-26-standard-ami-build-publish-share-processes.md
|
||||
- Notes: 与 Standard AMI、EC2 Image Builder 形成知识关联,完善 AWS 镜像管理知识体系
|
||||
- Status: ✅ 成功摄入
|
||||
- Summary: AWS Redshift 数据仓库架构与核心组件,MPP 并行处理、列式存储、Leader Node、Compute Node、Sort Key、Dist Key
|
||||
- Concepts created: MPP(新增), OLAP(新增), 列式存储(新增), Sort Key(新增), Dist Key(新增), 数据压缩(新增)
|
||||
- Entities created: AWS Redshift(新增), Leader Node(新增), Compute Node(新增), AWS(已有)
|
||||
- Source page: wiki/sources/ctp-topic-68-introduction-to-redshift.md
|
||||
- Notes: 添加 Redshift 数据仓库概念,与现有 AWS 服务形成知识体系
|
||||
|
||||
@@ -19,7 +19,11 @@ AI 开源项目、Cloud & DevOps、Vibe Coding、AI时代个人发展、跨境
|
||||
- ITSM(IT 服务管理):从工单系统演进为战略推动者,实现运营卓越、风险缓解和创新加速
|
||||
- Multi-Account Strategy(多账号策略):AWS 推荐的企业级云架构模式,通过将工作负载分离到多个 AWS 账号来提升安全性、治理能力和故障隔离
|
||||
- Gruntwork Landing Zone:Gruntwork 提供的预配置 AWS 基础架构框架,基于 Reference Architecture 包含核心账户和工作负载账户
|
||||
- CCOE(Cloud Center of Excellence):推动云采纳和治理的核心组织单元,负责 AMI 标准制定和发布
|
||||
|
||||
- Standard AMI:AWS 标准机器镜像,包含 OS 加固、最新安全补丁,并支持域集成、SSM agent、DNS 设置,每两个月发布一次
|
||||
- Cloud Guardrails:云守护栏,捕获可扩展性、成本最小化和灵活性的强制性要求和最佳实践
|
||||
- Tagging Methodology:标签方法论,通过为资源定义标准化的元数据(如 Owner, BU, Product, Environment),作为自动化管理和安全策略执行的基础
|
||||
- RTO(Recovery Time Objective):系统允许的最大停机时间,是灾难恢复的核心指标
|
||||
- RPO(Recovery Point Objective):可接受的最大数据丢失量,是数据保护的核心指标
|
||||
- 开源平替:功能可替代闭源商业产品的开源项目
|
||||
@@ -205,7 +209,11 @@ AI 开源项目、Cloud & DevOps、Vibe Coding、AI时代个人发展、跨境
|
||||
- **Ubuntu 服务器通过 rsync 实现日常增量备份** — 使用 rsync 实现 Ubuntu 服务器到 NAS 的增量备份,涵盖 NFS 永久挂载和灾难恢复
|
||||
|
||||
- **CTP Topic 46 NetApps on AWS** — NetApp Cloud Volume ONTAP (CVO) 架构、部署、数据分层(EBS→S3)、安全加密与灾备(SnapMirror)
|
||||
- **CTP Topic 34 Azure Landing Zone Architecture Overview** — Azure Landing Zone 架构设计,Management Groups 四区域划分、Subscription 分离、Terraform Cloud 自动化
|
||||
- **CTP Topic 7 SaaS Landing Zone Design** — 生产环境 SaaS Landing Zone 高级设计,单一 Landing Zone 策略、Core/Baseline/Shared Services 账户分离
|
||||
- **CTP Topic 40 SaaS Database Architecture On AWS Cloud** — AWS 云上 SaaS 数据库架构设计,SaaS 数据库团队全球运维实践(500+ 数据库、1000+ 服务器,Oracle/Postgres/DynamoDB 等多种数据库,高可用设计)
|
||||
- **CTP Topic 28 AWS Tag Validation Tool** — AWS 标签验证工具,通过 YAML 配置文件审计资源标签合规性,生成 CSV 报告
|
||||
- **CTP Topic 73 AWS Backup implementation of the Cloud Transformation Program** — AWS Backup 在 CTP 云转型计划中的实施,涵盖 SRE 备份模型、DR 账户备份、AWS Backup Audit Manager 审计
|
||||
- **如何在Ubuntu Server上通过NFS挂载Synology NAS上的共享文件夹** — <20><> Ubuntu Server 上通过 NFS 协议挂载 Synology NAS 共享文件夹
|
||||
- **Ubuntu 禁用合盖休眠** — 在 Ubuntu 24.04 中通过修改 systemd-logind 配置禁用笔记本合盖休眠行为
|
||||
- **群晖NAS科学上网方法** — 在群晖 NAS 上通过 V2RayA 配置透明代理,使 Docker 可以科学上网
|
||||
|
||||
@@ -2,8 +2,9 @@
|
||||
title: "RTO vs RPO: Key Differences for Modern Disaster Recovery"
|
||||
type: source
|
||||
tags: [灾难恢复, 业务连续性, 持续交付, 特性管理]
|
||||
date: 2019-01-18
|
||||
sources: ["https://launchdarkly.com/blog/rto-vs-rpo/"]
|
||||
last_updated: 2025-07-26
|
||||
last_updated: 2026-04-18
|
||||
---
|
||||
|
||||
## Source File
|
||||
|
||||
@@ -0,0 +1,58 @@
|
||||
---
|
||||
id: ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security
|
||||
title: "CTP Topic 10 AWS Landing Zone (LZ) Data Collection, Tagging Related Security"
|
||||
type: source
|
||||
tags:
|
||||
- AWS
|
||||
- Landing-Zone
|
||||
- Tagging
|
||||
- Security
|
||||
- CTP
|
||||
date: 2026-04-14
|
||||
sources:
|
||||
- NAS /volume2/work/Public Cloud Learning Sessions/CTP _ Topic 10_ AWS Landing Zone (LZ) Data Collection, Tagging _ Related Security.mp4
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题:AWS Landing Zone 部署流程、数据收集策略、基于标签的安全控制机制
|
||||
- 问题域:传统网络安全向云原生安全的转型
|
||||
- 方法/机制:Landing Zone 规划与自动化、基于标签的安全策略、Checkpoint 防火墙的有序层逻辑
|
||||
- 结论/价值:利用标签和 SCP 强制执行标签合规性,实现精细化的流量过滤和隔离
|
||||
|
||||
## Key Claims
|
||||
- Landing Zone 部署前必须深入了解业务部门(BU)的资产清单、IP 地址空间及数据敏感性
|
||||
- 基于标签的安全控制机制可替代传统基于 IP 的防火墙规则
|
||||
- 通过 OU(组织单元)和 SCP(服务控制策略)可防止用户篡改标签绕过安全审计
|
||||
- Checkpoint 防火墙通过有序层逻辑实现地理屏蔽、BU 隔离、产品隔离及环境隔离
|
||||
|
||||
## Key Quotes
|
||||
> "DNS、Transit Gateway 等基础服务的创建已通过 SRE 团队实现了高度自动化" — Steve Jarman
|
||||
> "通过 SCP 的'显式拒绝'逻辑,系统能够强制执行标签规范,确保资源在创建时即具备正确的归属" — 视频内容
|
||||
|
||||
## Key Concepts
|
||||
- [[AWS Landing Zones]]:能够按照最佳实践快速设置、安全且多账号的 AWS 环境的基础架构框架
|
||||
- [[Tagging Methodology]]:标签方法论,通过为资源定义标准化的元数据(如 Owner, BU, Product, Environment),作为自动化管理和安全策略执行的基础
|
||||
- [[Service Control Policies]]:服务控制策略,用于管理组织中的权限,强制执行标签合规性
|
||||
- [[Organizational Unit]]:组织单元,AWS Organizations 中账号的分组容器
|
||||
- [[Checkpoint Firewall]]:部署在云环境中的虚拟防火墙,通过集成 AWS 标签实现动态的对象识别和流量过滤
|
||||
- [[Transit Gateway]]:传输网关,作为网络中心枢纽,连接 VPC 与本地网络
|
||||
- [[Ordered Layer]]:有序层,防火墙策略的一种组织方式,按顺序执行地理屏蔽、BU 隔离、环境隔离等逻辑
|
||||
- [[SRE]]:站点可靠性工程,负责 Landing Zone 部署中的自动化脚本编写与基础架构维护
|
||||
|
||||
## Key Entities
|
||||
- [[AWS]]:全球最大公有云平台
|
||||
- [[Gruntwork]]:Gruntwork Landing Zones 框架提供商
|
||||
|
||||
## Connections
|
||||
- [[CTP Topic 1 Gruntwork Landing Zone Architecture]] ← depends_on ← [[CTP Topic 10 AWS Landing Zone (LZ) Data Collection, Tagging Related Security]]
|
||||
- [[CTP Topic 28 AWS Tag Validation Tool]] ← extends ← [[Tagging Methodology]]
|
||||
- [[CTP Topic 17 Active Directory Services in Gruntwork AWS LZs]] ← depends_on ← [[AWS Landing Zones]]
|
||||
|
||||
## Contradictions
|
||||
- 与传统基于 IP 的防火墙方案冲突:
|
||||
- 冲突点:网络边界防护模式
|
||||
- 当前观点:基于标签的动态安全控制
|
||||
- 对方观点:基于 IP 的静态防火墙规则
|
||||
57
wiki/sources/ctp-topic-22-global-dns-service-offerings.md
Normal file
57
wiki/sources/ctp-topic-22-global-dns-service-offerings.md
Normal file
@@ -0,0 +1,57 @@
|
||||
---
|
||||
title: "CTP Topic 22 Global DNS service offerings"
|
||||
type: source
|
||||
tags:
|
||||
- DNS
|
||||
- Networking
|
||||
- AWS
|
||||
- CTP
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-22-global-dns-service-offerings.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题:企业在全球范围内的 DNS 服务架构与配置方案
|
||||
- 问题域:AWS 云环境与本地数据中心的混合云 DNS 设计
|
||||
- 方法/机制:Route 53 Private Hosted Zones、Route 53 Resolver Endpoints(入站/出站)、Infoblox DNS Anycast
|
||||
- 结论/价值:实现跨区域和混合云的域名解析高可用性,采用"就近解析"优化 Office 365 等全球化服务访问性能
|
||||
|
||||
## Key Claims
|
||||
- Route 53 Private Hosted Zones 是 AWS 环境的核心 DNS 服务
|
||||
- Route 53 Resolver 出站规则中配置多个区域的 AD 域控制器 IP 可确保 DNS 解析弹性
|
||||
- Infoblox 平台利用 DNS Anycast 技术实现全球低延迟和自动故障转移
|
||||
- AWS EC2 不原生支持 DNS Anycast,需手动维护 IP 列表
|
||||
|
||||
## Key Quotes
|
||||
> "公司正在进行的云转型计划,旨在构建一个高可用、多区域的 Landing Zone 基础架构"
|
||||
|
||||
> "通过在出站规则中配置多个区域的 AD 域控制器 IP,确保即使在某个区域发生故障时,DNS 解析仍能保持弹性"
|
||||
|
||||
> "本地环境采用了 Infoblox 平台,利用 DNS Anycast 技术实现了全球范围内的低延迟和自动故障转移,而 AWS 目前在 EC2 基础架构上尚不支持 Anycast"
|
||||
|
||||
## Key Concepts
|
||||
- [[Route-53-Private-Hosted-Zone]]:AWS 提供的私有托管区域,仅对指定的 VPC 可见
|
||||
- [[Route-53-Resolver-Endpoint]]:入站和出站终端节点,用于 AWS VPC 与本地网络或其他云环境之间转发 DNS 查询
|
||||
- [[DNS-Anycast]]:一种网络寻址和路由方法,使多个 DNS 服务器共享同一个 IP 地址
|
||||
- [[IPAM]]:IP 地址管理工具(如 Infoblox)
|
||||
- [[Landing-Zone]]:预配置好的多账号 AWS 环境
|
||||
- [[Hybrid-DNS-Resolution]]:混合云 DNS 解析机制
|
||||
|
||||
## Key Entities
|
||||
- [[AWS]]:Amazon Web Services,云服务提供商
|
||||
- [[Route-53]]:AWS 的 DNS 服务
|
||||
- [[Active-Directory]]:Microsoft 目录服务
|
||||
- [[Infoblox]]:DNS/DHCP 设备提供商
|
||||
|
||||
## Connections
|
||||
- [[Route-53]] ← manages ← [[Route-53-Private-Hosted-Zone]]
|
||||
- [[Route-53-Resolver-Endpoint]] ← depends_on ← [[Active-Directory]]
|
||||
- [[Hybrid-DNS-Resolution]] ← uses ← [[Route-53-Resolver-Endpoint]]
|
||||
- [[Infoblox]] ← provides ← [[DNS-Anycast]]
|
||||
|
||||
## Contradictions
|
||||
- Infoblox Anycast:本地环境自动实现全球低延迟
|
||||
- Infoblox 方案:自动故障转移,无需手动维护
|
||||
- 当前 AWS 方案:EC2 不支持 Anycast,需手动维护 IP 列表
|
||||
@@ -0,0 +1,61 @@
|
||||
---
|
||||
title: "CTP Topic 25 Labs Landing Zone overview - ITOM teams"
|
||||
type: source
|
||||
tags:
|
||||
- AWS
|
||||
- Landing-Zone
|
||||
- Labs
|
||||
- ITOM
|
||||
- CTP
|
||||
category: DevOps & SRE/01_AWS-Landing-Zone
|
||||
date-added: 2026-04-18
|
||||
sources:
|
||||
- raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-25-labs-landing-zone-overview-itom-teams.md
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-25-labs-landing-zone-overview-itom-teams.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题:Labs Landing Zone 架构概述,基于 Gruntwork reference architecture 和 AWS 标准,采用多账号策略
|
||||
- 问题域:企业级 AWS 云基础设施规划与部署
|
||||
- 方法/机制:IaC(Terraform)管理、标签驱动防火墙策略、CI/CD 自动化(Jenkins + Terragrunt)
|
||||
- 结论/价值:Labs Landing Zone 提供标准化的多账号基础设施框架,通过代码实现一致性、版本控制和自动化治理
|
||||
|
||||
## Key Claims
|
||||
- Labs Landing Zone 基于 Gruntwork reference architecture 和 AWS 标准构建
|
||||
- 整个技术栈通过 Terraform 管理,所有资源必须使用代码机制部署
|
||||
- Shared Account 托管 Jenkins 主服务器、hardened AMIs 和 Docker 容器存储
|
||||
- Logs Account 安全存储 AWS Config 和 CloudTrail 日志,访问权限由安全团队控制
|
||||
- Security Account 管理用户账户和跨账户访问,采用联合身份认证
|
||||
- Active Directory 账户管理 Windows 实例和 IDPs(使用 swimford.net 域名)
|
||||
- DNS 账户管理 AWS Swimford.net,允许本地域或引用更广泛的基础设施
|
||||
- Network Account 是网络通信中心,通过 Transit Gateway 和 JetPult 防火墙管理流量
|
||||
- 所有互联网访问通过该账户路由,通过标签由网络团队管理
|
||||
- Shared Service Accounts 提供监控服务(如 45 arc site)和 Qualys 安全服务
|
||||
- Product Account 是主要工作环境,使用标准化 IaC 模块构建,可包含多个账户(production、staging、development)
|
||||
- 部署 Product Account 时需定义 IP 地址范围,并与网络团队协商防火墙访问的标签
|
||||
- Jenkins 流水线持续扫描 GitHub Enterprise 仓库,根据分支运行 Terragrunt plan 或 apply
|
||||
- 互联网连接受限,访问特定企业网络位置需向网络服务团队申请
|
||||
|
||||
## Key Concepts
|
||||
- [[Gruntwork Landing Zone]]:Gruntwork 提供的预配置 AWS 基础架构框架
|
||||
- [[Multi-Account Strategy]]:AWS 推荐的多账号策略,通过分离工作负载提升安全性和治理能力
|
||||
- [[Infrastructure as Code]]:通过代码实现基础设施管理,确保一致性和版本控制
|
||||
- [[Terraform]]:HashiCorp 开发的 IaC 工具,用于声明式定义云资源
|
||||
- [[Transit Gateway]]:AWS 中心网络路由服务,连接 VPCs 和本地网络
|
||||
- [[Service Control Policies]]:AWS Organizations 的策略类型,管理组织内账户的最大权限边界
|
||||
|
||||
## Key Entities
|
||||
- [[Gruntwork]]:Landing Zone 框架提供商
|
||||
- [[Jenkins]]:开源自动化服务器,用于 CI/CD 流水线
|
||||
- [[swinford.net]]:R&D Labs 环境的 Active Directory 域名
|
||||
|
||||
## Connections
|
||||
- [[Gruntwork Landing Zone]] ← builds_on ← [[AWS Organizations]]
|
||||
- [[Product Account]] ← deploys_via ← [[Terraform]]
|
||||
- [[Network Account]] ← manages ← [[Transit Gateway]]
|
||||
- [[Logs Account]] ← stores ← [[CloudTrail]]
|
||||
|
||||
## Contradictions
|
||||
- (暂无)
|
||||
@@ -0,0 +1,52 @@
|
||||
---
|
||||
title: "CTP Topic 26 Standard AMI – build, publish, share processes"
|
||||
type: source
|
||||
tags: [AWS, AMI, Build-Process, CTP, Cloud-Learning]
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-26-standard-ami-build-publish-share-processes.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题:Foundation AMI(基础亚马逊机器镜像)的构建、加固与分发流程
|
||||
- 问题域:企业级 AWS 镜像标准化与安全合规
|
||||
- 方法/机制:HashiCorp Packer + Jenkins 自动化构建流水线,AMI Sharing 跨账号共享机制
|
||||
- 结论/价值:通过标准化 Foundation AMI 实现"即插即用",确保所有实例从启动之日起符合安全合规标准
|
||||
|
||||
## Key Claims
|
||||
- Foundation AMI 是基于市场主流操作系统(CentOS, Ubuntu, Windows 等)进行深度加固的镜像
|
||||
- Foundation AMI 集成 CIS 安全基准、防病毒软件(McAfee EPO)、日志管理(Syslog-ng)及单点登录(AD 集成)
|
||||
- 镜像通过跨账号共享(Sharing)而非物理复制(Copying)的方式分发到全球多个区域
|
||||
- 镜像每两个月更新一次,遵循 N-2 的版本保留策略
|
||||
|
||||
## Key Quotes
|
||||
> "Foundation AMI 的主要优势在于'即插即用',确保所有实例从启动之日起就符合 Micro Focus 的安全合规标准,并预装了 SSM Agent 和 SiteScope 监控预选件" — Srihari, Alan, Praveen
|
||||
|
||||
## Key Concepts
|
||||
- [[Foundation AMI]]:经过安全加固、集成标准组件并预配置好的操作系统模板
|
||||
- [[OS Hardening]]:操作系统加固,通过关闭不必要服务、优化内核参数和应用安全补丁来减少系统攻击面
|
||||
- [[CIS Benchmarks]]:互联网安全中心制定的安全配置基准
|
||||
- [[HashiCorp Packer]]:开源机器镜像自动化构建工具
|
||||
- [[SSM Agent]]:AWS 系统管理器代理,用于实现实例的远程管理
|
||||
- [[AMI Sharing]]:镜像共享机制,通过授权其他账号访问中央镜像
|
||||
- [[N-2 Version Policy]]:保留最近两个版本的政策
|
||||
|
||||
## Key Entities
|
||||
- [[Standard AMI]]:AWS 标准机器镜像,由 CCOE 维护
|
||||
- [[AWS]]:亚马逊公有云平台
|
||||
- [[Jenkins]]:开源自动化服务器,用于 CI/CD
|
||||
- [[CCOE]]:Cloud Center of Excellence,负责提供安全的基础镜像
|
||||
|
||||
## Connections
|
||||
- [[Standard AMI]] ← provides ← [[Foundation AMI]]
|
||||
- [[Jenkins]] ← builds ← [[HashiCorp Packer]]
|
||||
- [[CCOE]] ← maintains ← [[Standard AMI]]
|
||||
- [[EC2 Image Builder]] ← related_to ← [[Standard AMI]]
|
||||
|
||||
## Contradictions
|
||||
- (暂无)
|
||||
|
||||
## Related Sources
|
||||
- [[Learning Sessions Standard AMIs Updates 20231205]] — AWS Standard AMIs 概述、更新和发布流程
|
||||
- [[CTP Topic 58 AWS EC2 Image Builder]] — AWS EC2 Image Builder 服务详解
|
||||
@@ -0,0 +1,50 @@
|
||||
---
|
||||
title: CTP Topic 34 Azure Landing Zone Architecture Overview
|
||||
type: source
|
||||
tags: [Azure, Landing-Zone, CTP]
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-34-azure-landing-zone-architecture-overview.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题:Azure Landing Zone 在 Micro Focus 的架构设计与实现
|
||||
- 问题域:云采用框架、订阅组织、访问管理
|
||||
- 方法/机制:Management Groups、Subscription 分离、Terraform Cloud 自动化、PIM 权限管理
|
||||
- 结论/价值:通过模块化、自动化的 Landing Zone 设计,各团队可独立部署工作负载,最小化跨团队依赖
|
||||
|
||||
## Key Claims
|
||||
- Azure Landing Zone 通过Management Groups 将组织划分为四个区域:Platform(平台)、Landing Zones(着陆区)、Decommission(退役)、Sandbox(沙盒)
|
||||
- Platform 包含 Identity Management(身份管理)和 Connectivity(连接)两个订阅,分别由专门团队管理,增强安全性
|
||||
- Connectivity 订阅作为所有入站和出站 Azure 流量的中心hub,集成 DDoS 防护和 Checkpoint 防火墙
|
||||
- Landing Zones 设计为可扩展、模块化、完全自动化的模板,为新项目提供标准化基础
|
||||
- Terraform Cloud 使用 Terraform States 管理订阅间的依赖关系,实现分层访问控制
|
||||
|
||||
## Key Quotes
|
||||
> "The core reason of these individual or isolated subscriptions is you are basically containing a subscription for a specific purpose." — 核心设计理念:每个订阅专注于特定用途,实现隔离和管控
|
||||
|
||||
> "This sandbox is an interesting one because these landings on subscriptions allows your workloads." — Sandbox 订阅为实验工作负载提供隔离环境
|
||||
|
||||
## Key Concepts
|
||||
- [[Management Groups]]:Azure 组织管理结构,类似于 Windows 父目录,用于组织订阅
|
||||
- [[Subscription]]:Azure 订阅,隔离的资源容器,每个订阅有特定用途
|
||||
- [[Terraform Cloud]]:HashiCorp 的云基础设施自动化平台,管理 IaC 状态和执行
|
||||
- [[PIM(Privileged Identity Management)]]:Azure 特权身份管理,控制提升权限的访问
|
||||
- [[Azure Landing Zone]]:云采用的起点架构,为工作负载提供安全的标准化基础
|
||||
|
||||
## Key Entities
|
||||
- [[Micro Focus]]:案例公司,正在实施 Azure Landing Zone
|
||||
- [[Kishore Garlopati]]:讲师,介绍 Azure Landing Zone 架构
|
||||
- [[Azure]]:Microsoft 公有云平台
|
||||
- [[Azure Active Directory]]:Azure 身份识别服务,用于用户认证
|
||||
- [[Checkpoint Firewall]]:企业级防火墙解决方案
|
||||
|
||||
## Connections
|
||||
- [[Azure]] ← hosts ← [[Azure Landing Zone]]
|
||||
- [[Azure Landing Zone]] ← uses ← [[Management Groups]]
|
||||
- [[Azure Landing Zone]] ← automates ← [[Terraform Cloud]]
|
||||
- [[Azure Active Directory]] ← authenticates ← [[PIM]]
|
||||
|
||||
## Contradictions
|
||||
- (暂无)
|
||||
@@ -0,0 +1,44 @@
|
||||
---
|
||||
title: "CTP Topic 35 AWS Landing Zone Design Refresher (SaaS Labs)"
|
||||
type: source
|
||||
tags: [AWS, Landing-Zone, SaaS, Labs, CTP]
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-35-aws-landing-zone-design-refresher-saas-labs.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题:AWS Landing Zone 设计更新,区分 SaaS(生产)和 Labs(开发)环境
|
||||
- 问题域:企业级多账号 AWS 架构设计、基础设施即代码
|
||||
- 方法/机制:基于 Gruntwork Terraform 模板的基础设施即代码(IaC)部署
|
||||
- 结论/价值:明确 SaaS 用于生产、Labs 用于开发的定位,统一云交付标准
|
||||
|
||||
## Key Claims
|
||||
- Landing Zone 的核心目标是支持多样化的 AWS 用例,同时确保复用、控制、审计和管理
|
||||
- AWS SaaS landing zones 提供客户专用环境,产品账户连接共享服务账户进行安全、日志和网络管理
|
||||
- Gruntwork 账户管理 AMIs、日志和跨账户安全
|
||||
- 近期更新包括网络分段阻止直接连接到 SaaS 工作负载,停用 Gruntworks CloudTrail,改为 CCOE CloudTrail
|
||||
|
||||
## Key Quotes
|
||||
> "Our AWS landing zones, they're built infrastructure as code as you'd expect on terraform templates using the grunt work framework." — 基础设施即代码实现方式
|
||||
> "Basically, the only answer is that SAS is production, Labs is development." — SaaS 与 Labs 的核心区别
|
||||
|
||||
## Key Concepts
|
||||
- [[Gruntwork Landing Zone]]:Gruntwork 提供的预配置 AWS 基础架构框架
|
||||
- [[Multi-Account Strategy]]:AWS 多账号架构策略,分离工作负载提升安全性和治理能力
|
||||
- [[Cloud Guardrails]]:云守护栏,捕获可扩展性、成本最小化和灵活性的强制性要求
|
||||
- [[Infrastructure as Code]]:通过代码实现一致性、版本控制的基础设施管理
|
||||
|
||||
## Key Entities
|
||||
- [[Gruntwork]]:Landing Zone 框架提供商
|
||||
- [[AWS]]:全球最大公有云平台
|
||||
- [[Cloud Technology Design Forum]]:标准化和集中化微焦点云交付产品的组织
|
||||
|
||||
## Connections
|
||||
- [[Gruntwork Landing Zone]] ← depends_on ← [[AWS Organizations]]
|
||||
- [[Gruntwork Landing Zone]] ← uses ← [[Terraform]]
|
||||
- [[Multi-Account Strategy]] ← implements ← [[Cloud Guardrails]]
|
||||
|
||||
## Contradictions
|
||||
- (暂无记录)
|
||||
50
wiki/sources/ctp-topic-36-sendgrid-as-an-email-service.md
Normal file
50
wiki/sources/ctp-topic-36-sendgrid-as-an-email-service.md
Normal file
@@ -0,0 +1,50 @@
|
||||
---
|
||||
title: "CTP Topic 36 SendGrid as an email service"
|
||||
type: source
|
||||
tags:
|
||||
- SendGrid
|
||||
- Email Service
|
||||
- CTP
|
||||
- Cloud Transformation
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-36-sendgrid-as-an-email-service.md]]
|
||||
|
||||
## Summary
|
||||
|
||||
- 核心主题:SendGrid 被采用为云转换计划的标准化邮件服务
|
||||
- 问题域:替换不安全的语义网关和受限制的 SES 方案
|
||||
- 方法/机制:直接发送(需 TLS)或通过中继服务器发送架构
|
||||
- 结论价值:SendGrid 提供 1000 收件人/邮件限制、实时监控、双因素认证、端到端加密
|
||||
|
||||
## Key Claims
|
||||
|
||||
- SendGrid 已被采用为经典和新 landing zones 的标准邮件服务
|
||||
- 当前语义网关存在安全问题:通过 port 25 中继到公网,且托管在即将停用的本地网络
|
||||
- 当前 SES 限制为每邮件仅 50 个收件人
|
||||
- SendGrid 支持每邮件最多 1000 个收件人
|
||||
- 支持计划涵盖每月 500 万封邮件
|
||||
- 日志保留 7 天,API 密钥每 180 天轮换
|
||||
|
||||
## Key Concepts
|
||||
|
||||
- [[SendGrid]]:Twilio 旗下的企业级邮件服务,被 CTP 采用为标准
|
||||
- [[Cyber-Suite]]:PSAC 更新发布的网络安全标准文档
|
||||
|
||||
## Connections
|
||||
|
||||
- [[CTP-Topic-35]] ← depends_on ← SendGrid 部署
|
||||
- [[CTP-Topic-7]] ← extends ← Landing Zone 邮件架构
|
||||
- [[CTP-Topic-46]] ← similar ← 企业服务标准化
|
||||
|
||||
## Key Quotes
|
||||
|
||||
> "SendGrid is being adopted as the standard email service for both classic and new landing zones"
|
||||
|
||||
> "Almost 30 billion emails per month customers are already used across the whole country"
|
||||
|
||||
---
|
||||
|
||||
*摄取时间:2026-04-19*
|
||||
@@ -0,0 +1,49 @@
|
||||
---
|
||||
title: "CTP Topic 40 SaaS Database Architecture On AWS Cloud"
|
||||
type: source
|
||||
tags: [SaaS, Database, Architecture, AWS, CTP]
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-40-saas-database-architecture-on-aws-cloud.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题:AWS 云上 SaaS 数据库架构设计,SaaS 数据库团队的全球运维实践
|
||||
- 问题域:多区域数据库运维、多租户数据隔离、数据库高可用与灾备
|
||||
- 方法/机制:Oracle Data Guard、Postgres Active-Passive、RDS High Availability
|
||||
- 结论/价值:提供 24/7 支持,管理 500+ 数据库和 1000+ 服务器,支持 Oracle、Vertica、Postgres、DynamoDB、SQL Server、MongoDB、MySQL 等多种数据库
|
||||
|
||||
## Key Claims
|
||||
- SAS 数据库团队分布在全球多个国家(美国、加拿大、印度、以色列),提供全天候支持
|
||||
- 团队拥有 Oracle 认证专家、DBA 和安全专业人员
|
||||
- 数据库主要部署在应用 VPC 中,集成安全措施
|
||||
- 使用 Oracle Data Guard 实现高可用,Postgres 使用 Active-Passive 机制,计划迁移到 Active Active
|
||||
- 数据库运行在区域内两个可用区,主数据库在第一区,备用在第二区,第三区作为观察者管理故障转移
|
||||
|
||||
## Key Quotes
|
||||
> "The idea was to move those databases seamless without downtime or with minimum downtime." — 数据库迁移目标
|
||||
|
||||
> "Reporting databases have a read-only warehouse in the third availability zone, with secure VPN access for customers to run operational warehousing queries." — 报表数据库架构
|
||||
|
||||
## Key Concepts
|
||||
- [[Multi-Tenant Management]]:多租户 SaaS 数据库管理
|
||||
- [[High-Availability]]:高可用架构设计
|
||||
- [[故障转移]]:自动故障转移机制
|
||||
- [[Database Migration]]:数据中心迁移到云端
|
||||
|
||||
## Key Entities
|
||||
- [[AWS]]:AWS 云平台
|
||||
- [[Amazon Aurora]]:Postgres Aurora 数据库
|
||||
- [[Amazon DynamoDB]]:DynamoDB 数据库
|
||||
- [[Amazon ElastiCache]]:ElastiCache Redis 缓存
|
||||
- [[Oracle]]:Oracle 数据库
|
||||
- [[PostgreSQL]]:PostgreSQL 数据库
|
||||
|
||||
## Connections
|
||||
- [[CTP Topic 35 AWS Landing Zone Design Refresher (SaaS Labs)]] ← uses ← [[ctp-topic-40-saas-database-architecture-on-aws-cloud]]
|
||||
- [[CTP Topic 51 Architecting with AWS Purpose-Built Databases]] ← extends ← [[ctp-topic-40-saas-database-architecture-on-aws-cloud]]
|
||||
- [[CTP Topic 66 Exposing the differences between PostgreSQL RDS and Aurora]] ← relates_to ← [[ctp-topic-40-saas-database-architecture-on-aws-cloud]]
|
||||
|
||||
## Contradictions
|
||||
- (暂无)
|
||||
50
wiki/sources/ctp-topic-50-ami-roadmap-for-aws-amis.md
Normal file
50
wiki/sources/ctp-topic-50-ami-roadmap-for-aws-amis.md
Normal file
@@ -0,0 +1,50 @@
|
||||
---
|
||||
title: "CTP Topic 50 AMI Roadmap for AWS AMIs"
|
||||
type: source
|
||||
tags:
|
||||
- AWS
|
||||
- AMI
|
||||
- Roadmap
|
||||
- CTP
|
||||
date: 2026-04-18
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-50-ami-roadmap-for-aws-amis.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题:AWS AMI(Amazon Machine Image)路线图与标准化 AMI 维护策略
|
||||
- 问题域:企业云环境中的机器镜像治理,涵盖操作系统版本支持生命周期、新 AMI 添加流程、标准化功能集成
|
||||
- 方法/机制:CCOE(Cloud Center of Excellence)每两个月发布一次加固 AMI,遵循安全标准
|
||||
- 结论/价值:标准化 AMI 体系确保环境一致性、安全合规性,路线图透明化管理便于规划
|
||||
|
||||
## Key Claims
|
||||
- CCOE 每两个月发布一次符合安全标准的加固 AMI
|
||||
- 当前支持的 AMI 包括:Ubuntu(3个版本)、CentOS 7/8、Rocky 8.4 ARM、Amazon Linux 2、Windows(4个版本)
|
||||
- 路线图按 ADM 需求优先级排序,如需调整需通过需求管道流程
|
||||
|
||||
## Key Quotes
|
||||
> "The CCOE provides hardened AMIs on a bi-monthly basis aligned with security standards."
|
||||
|
||||
> "Any requirements to change the prioritization of the roadmap should go through the demand pipeline process."
|
||||
|
||||
> "The AMIs are shared with every account in the organization, including the AMI itself, EBS volumes, and KMS keys."
|
||||
|
||||
## Key Concepts
|
||||
- **Standard AMI**:AWS 标准机器镜像,包含 OS 加固、最新安全补丁,支持域集成、SSM agent、DNS 设置
|
||||
- **AMI 路线图**:按月发布计划,2022年11月 SLES 15 + RHEL 9,2023年1月 OpenSUSE 15 + Amazon Linux 2022,2023年3月 Rocky 8 + Rocky 9,2023年5月 RHEL 9.4 ARM + Ubuntu 22.04 ARM
|
||||
- **EOL(End of Life)**:Windows Server 2008/2008 R2(2020.01),CentOS 8(2021.12),Windows Server 2012(2023.10),RHEL 7 + CentOS 7(2024.06)
|
||||
- **Change Log**:CCOE 门户提供与上一版本的变更记录
|
||||
- **AMI 添加流程**:服务集成→功能启用→构建测试
|
||||
|
||||
## Key Entities
|
||||
- [[AWS]]:云平台,提供 EC2 和 AMI 服务
|
||||
- [[CCOE]]:Cloud Center of Excellence,负责 AMI 标准制定和发布
|
||||
|
||||
## Connections
|
||||
- [[Standard AMI]] ← depends_on ← [[AWS EC2]]
|
||||
- [[CTP Topic 26 Standard AMI]] ← extends ← [[CTP Topic 50]]
|
||||
- [[Gruntwork Landing Zone]] ← uses ← [[Standard AMI]]
|
||||
|
||||
## Contradictions
|
||||
- 与非标准 AMI 对比:企业需要平衡自定义灵活性与标准化安全合规要求
|
||||
57
wiki/sources/ctp-topic-58-aws-ec2-image-builder.md
Normal file
57
wiki/sources/ctp-topic-58-aws-ec2-image-builder.md
Normal file
@@ -0,0 +1,57 @@
|
||||
---
|
||||
title: "CTP Topic 58 AWS EC2 Image Builder"
|
||||
type: source
|
||||
tags: [AWS, EC2, Image Builder, CTP]
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-58-aws-ec2-image-builder.md]]
|
||||
|
||||
## Summary
|
||||
|
||||
- **核心主题**: AWS EC2 Image Builder 服务,用于自动创建、管理和分发 AMIs 和 Docker 镜像
|
||||
- **问题域**: 企业镜像构建标准化、CI/CD 流程优化、安全加固自动化
|
||||
- **方法/机制**:
|
||||
- Image Pipeline 定义 AMI 发布方式,包括安装、安全加固和发布计划
|
||||
- Image Recipe(YAML 格式)定义源 AMI 和输出 AMI 规格
|
||||
- Component 定义在源 AMI 中执行的具体步骤(安装包或 shell 命令)
|
||||
- Infrastructure Configuration 定义实例属性(实例类型、VPC、子网、安全组)
|
||||
- Distribution Settings 管理跨区域和账号的 AMI 分发
|
||||
|
||||
## Key Claims
|
||||
|
||||
- Image Builder 通过自动化提高生产力,在构建过程中集成测试,加载安全加固标准
|
||||
- 与 AWS Organizations 和 AWS RAM 集成,支持跨托管账号分发 AMI
|
||||
- 当前 AMI 发布流程存在缺陷:修改周转时间长、AMI 不兼容、手动流程自动化程度低
|
||||
|
||||
## Key Quotes
|
||||
|
||||
> "A component is basically just a particular step that you want to execute in order to achieve the output AMI."
|
||||
|
||||
> "Due to these limitations, product teams try to cater to their requirements by developing their own workflow or CI/CD pipelines, consuming the CCOE AMI and installing their required packages."
|
||||
|
||||
## Key Concepts
|
||||
|
||||
- [[EC2 Image Builder]]: AWS 托管服务,用于自动化创建、管理和分发 AMIs 和 Docker 镜像
|
||||
- [[Standard AMI]]: 包含 OS 加固脚本、安全补丁的标准化机器镜像
|
||||
- [[Infrastructure as Code]]: 通过 Terraform 模块创建和管理 Image Builder 资源
|
||||
|
||||
## Key Entities
|
||||
|
||||
- [[AWS]]: Amazon Web Services,云服务提供商
|
||||
- [[Terraform]]: 基础设施即代码工具,用于创建和管理 Image Builder 资源
|
||||
- [[CTP]]: Cloud Transformation Program,云转型计划项目
|
||||
|
||||
## Connections
|
||||
|
||||
- [[AWS]] ← provides ← [[EC2 Image Builder]]
|
||||
- [[EC2 Image Builder]] ← uses ← [[Terraform]] ← manages_infrastructure ← [[Standard AMI]]
|
||||
- [[CTP]] ← consumes ← [[Standard AMI]]
|
||||
|
||||
## Contradictions
|
||||
|
||||
- **与手动 AMI 构建流程**:
|
||||
- **冲突点**: 手动 AMI 构建和 EC2 Image Builder 的取舍
|
||||
- **当前观点**: 手动流程效率低,周转时间长,不适合大规模自动化
|
||||
- **对方观点**: 手动流程提供更多控制,适合特定场景
|
||||
62
wiki/sources/ctp-topic-68-introduction-to-redshift.md
Normal file
62
wiki/sources/ctp-topic-68-introduction-to-redshift.md
Normal file
@@ -0,0 +1,62 @@
|
||||
---
|
||||
title: "CTP Topic 68 Introduction to Redshift"
|
||||
type: source
|
||||
tags: [AWS, Redshift, Data-Warehouse, CTP]
|
||||
sources: []
|
||||
last_updated: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-68-introduction-to-redshift.md]]
|
||||
|
||||
## Summary
|
||||
|
||||
- 核心主题:AWS Redshift 数据仓库架构与核心组件
|
||||
- 问题域:云端数据仓库服务、数据仓库架构设计
|
||||
- 方法/机制:MPP 并行处理、列式存储、数据压缩、Sort Key、Dist Key
|
||||
- 结论/价值:Redshift 是完全托管的 PB 级云端数据仓库解决方案,支持 OLAP,提供易用的安装维护、备份恢复和跨区域灾备
|
||||
|
||||
## Key Claims
|
||||
|
||||
- Redshift 是一种完全托管的 PB 级云端数据仓库服务,专为数据仓库场景设计,支持 OLAP(在线分析处理)
|
||||
- Redshift 架构包含 Leader Node(领导节点)和 Compute Node(计算节点),Leader 节点负责 schema 管理、元数据和查询规划,计算节点执行查询
|
||||
- RA3 实例类型使用 AWS 托管的 NVMe 存储,具有成本效益和大存储容量
|
||||
- MPP(大规模并行处理)使查询能够跨多个计算节点并行处理,提升查询速度和响应时间
|
||||
- 列式存储针对数据仓库操作进行了性能优化,相比行式存储具有更快的性能和更低的内存占用
|
||||
- Sort Key 和 Dist Key 在优化查询性能和管理计算节点间数据分布方面起关键作用
|
||||
|
||||
## Key Quotes
|
||||
|
||||
> "Redshift is a fully managed, petabyte-scale data warehouse solution in the cloud. It is designed for data warehousing, enabling quick data retrieval from large datasets." — 视频摘要
|
||||
|
||||
> "The leader node manages schema, warehouse metadata, and query planning, distributes instructions to compute nodes." — 视频摘要
|
||||
|
||||
> "The leader node then stores results in buffers for quick retrieval, enhancing performance." — 视频摘要
|
||||
|
||||
## Key Concepts
|
||||
|
||||
- [[MPP]]:大规模并行处理,使查询跨多个计算节点并行处理
|
||||
- [[列式存储]]:针对数据仓库操作优化的存储方式,提高查询性能
|
||||
- [[Sort-Key]]:排序键,决定数据在磁盘上的物理排序顺序
|
||||
- [[Dist-Key]]:分布键,决定数据在计算节点间的分布方式
|
||||
- [[数据压缩]]:Redshift 支持多种压缩编码(如 LZO),减少存储空间和 I/O
|
||||
- [[OLAP]]:在线分析处理,用于复杂查询和数据分析
|
||||
|
||||
## Key Entities
|
||||
|
||||
- [[AWS]]:Amazon Web Services,Redshift 数据仓库服务提供商
|
||||
- [[AWS-Redshift]]:Amazon Redshift,PB 级云端数据仓库服务
|
||||
- [[Leader-Node]]:领导节点,Redshift 集群的管理节点
|
||||
- [[Compute-Node]]:计算节点,执行实际查询的节点
|
||||
|
||||
## Connections
|
||||
|
||||
- [[AWS]] → provides → [[AWS-Redshift]]
|
||||
- [[AWS-Redshift]] → uses → [[Leader-Node]]
|
||||
- [[AWS-Redshift]] → uses → [[Compute-Node]]
|
||||
- [[Compute-Node]] → supports → [[MPP]]
|
||||
- [[列式存储]] → optimizes → [[AWS-Redshift]]
|
||||
|
||||
## Contradictions
|
||||
|
||||
- 暂无
|
||||
58
wiki/sources/ctp-topic-7-saas-landing-zone-design.md
Normal file
58
wiki/sources/ctp-topic-7-saas-landing-zone-design.md
Normal file
@@ -0,0 +1,58 @@
|
||||
---
|
||||
title: "CTP Topic 7 SaaS Landing Zone Design"
|
||||
type: source
|
||||
tags:
|
||||
- AWS
|
||||
- Landing-Zone
|
||||
- SaaS
|
||||
- CTP
|
||||
- Cloud-Learning
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-7-saas-landing-zone-design.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题:生产环境 SaaS Landing Zone 的高级设计
|
||||
- 问题域:多账号架构、基础设施自动化、安全隔离
|
||||
- 方法/机制:单一 Landing Zone 策略、Terraform 模块化部署、TerraGrant 权限管理
|
||||
- 结论/价值:统一 Landing Zone 降低开销和复杂度,与开发实验室的每产品组(PG) Landing Zone 模式区分
|
||||
|
||||
## Key Claims
|
||||
- SaaS 生产环境采用单一 Landing Zone 策略,服务所有产品组,降低基础设施开销和运维复杂度
|
||||
- Shared Account 托管硬化的 SRE-provided AMIs 和主 Jenkins 服务器,通过 Lambda 函数触发各账号的 Jenkins slaves 执行部署任务
|
||||
- Logs Account 集中收集所有账号的 CloudTrail、Config、Flowlogs,安全团队拥有完全访问权限,产品团队仅可访问自身日志
|
||||
- Security Account 承载跨账号继承的 IAM Role,各账号所有者可附加额外策略限制 Role 使用范围
|
||||
|
||||
## Key Quotes
|
||||
> "The SAS landing zone will use a single landing zone for all the product groups." — 单一 Landing Zone 策略的核心声明
|
||||
>
|
||||
> "The workload itself is going to be under private subnet." — 产品账号工作负载部署模式
|
||||
|
||||
## Key Concepts
|
||||
- [[Multi-Account Strategy]]:AWS 推荐的企业级云架构模式,通过将工作负载分离到多个 AWS 账号提升安全性和治理能力
|
||||
- [[Gruntwork Landing Zone]]:基于 Grant 工作参考架构的预配置 AWS 基础架构框架
|
||||
- [[Terraform]]:基础设施即代码工具,用于自动化部署和管理 AWS 资源
|
||||
- [[SRE-provided AMIs]]:SRE 团队预构建的机器镜像,内置自动域加入脚本
|
||||
- [[Domain Join]]:通过 SRE-provided AMIs 实现自动化将实例加入 AD 域的技术
|
||||
|
||||
## Key Entities
|
||||
- [[AWS]]:全球最大公有云平台,提供计算、存储、网络等基础架构服务
|
||||
- [[Gruntwork]]:Gruntwork Landing Zones 框架提供商
|
||||
- [[Jenkins]]:开源自动化服务器,用于持续集成和持续部署
|
||||
- [[Route 53]]:AWS DNS 服务,用于管理域名解析
|
||||
- [[Active Directory]]:Microsoft 目录服务,用于身份验证和资源访问控制
|
||||
- [[CloudFront]]:AWS 内容分发网络(CDN),用于加速静态内容分发
|
||||
- [[WAF]]:Web Application Firewall,Web 应用防火墙,用于保护 Web 应用免受攻击
|
||||
- [[Check Point]]:网络安全公司,提供防火墙和 VPN 解决方案
|
||||
- [[Pulse Secure]]:VPN 解决方案供应商,提供安全的远程访问
|
||||
|
||||
## Connections
|
||||
- [[ctp-topic-35-aws-landing-zone-design-refresher-saas-labs]] ← similar_architecture ← [[ctp-topic-7-saas-landing-zone-design]]
|
||||
- [[ctp-topic-1-gruntwork-landing-zone-architecture]] ← builds_on ← [[ctp-topic-7-saas-landing-zone-design]]
|
||||
- [[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]] ← relates_to ← [[ctp-topic-7-saas-landing-zone-design]]
|
||||
- [[ctp-topic-17-active-directory-services-in-gruntwork-aws-lzs]] ← depends_on ← [[ctp-topic-7-saas-landing-zone-design]]
|
||||
|
||||
## Contradictions
|
||||
- 与 Labs 环境的区别:生产环境采用单一 Landing Zone,Labs 环境采用每个产品组独立的 Landing Zone
|
||||
@@ -0,0 +1,48 @@
|
||||
---
|
||||
title: "Learning Sessions Standard AMIs Updates 20231205"
|
||||
type: source
|
||||
tags: [AWS, AMI, Cloud, DevOps]
|
||||
date: 2023-12-05
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/learning-sessions-standard-amis-updates-20231205-160324-meeting-recording-2.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题:AWS Standard AMIs(标准机器镜像)的概述、更新和发布流程
|
||||
- 问题域:云基础设施标准化、企业镜像管理
|
||||
- 方法/机制:每两个月构建测试发布、JMES 多分支流水线、Jenkins自动化
|
||||
- 结论/价值:提供包含 OS 加固、最新的安全补丁和域集成的标准化 AMIs,支持 23 种不同操作系统
|
||||
|
||||
## Key Claims
|
||||
- Standard AMIs 基于 AWS AMIs,增加了 OS 加固、最新补丁、安全更新,并支持域集成、安全工具、端点保护、SSM agent、DNS 设置
|
||||
- AMIs 每两个月构建、测试并共享到所有 AWS 账户,立即作为私有 AMIs 可用
|
||||
- 目前支持 23 种不同 AMIs,包括各种 Amazon Linux、CentOS、Oracle、Red Hat、Rocky Linux、SUSE、Ubuntu 和 Windows Server 版本
|
||||
- 使用机器人框架将单个 AMI 的验证时间从 3-4 天缩短到 60 分钟
|
||||
|
||||
## Key Quotes
|
||||
> "The AMIs are built, tested, and shared to all AWS accounts every two months, and are immediately available as private AMIs."
|
||||
> — 镜像发布机制说明
|
||||
|
||||
> "We integrated a robotic framework and we reduced the validation time for one AMI from three-four days to 60 minutes."
|
||||
> — 自动化验证效果
|
||||
|
||||
## Key Concepts
|
||||
- [[Standard AMI]]:AWS 标准机器镜像,包含 OS 加固、安全更新的预配置镜像
|
||||
- [[AMI Roadmap]]:AMI 路线图,规划未来操作系统版本支持
|
||||
- [[EC2 Image Builder]]:AWS EC2 镜像构建器,用于创建和维护自定义 AMIs
|
||||
- [[AMI End-of-Life]]:操作系统到达生命周期终点,需要迁移替代方案(如 CentOS 7 迁移到 Rocky Linux)
|
||||
|
||||
## Key Entities
|
||||
- [[AWS]]:Amazon Web Services,云服务提供商
|
||||
- [[Jenkins]]:开源自动化服务器,用于 CI/CD 流水线
|
||||
- [[Amazon Inspector]]:AWS 安全漏洞扫描服务
|
||||
|
||||
## Connections
|
||||
- [[Standard AMI]] ← uses ← [[EC2 Image Builder]]
|
||||
- [[Standard AMI]] ← tested_by ← [[Amazon Inspector]]
|
||||
- [[Standard AMI]] ← built_by ← [[Jenkins]]
|
||||
- [[AMI Roadmap]] ← managed_by ← [[AWS]]
|
||||
|
||||
## Contradictions
|
||||
- (暂无)
|
||||
Reference in New Issue
Block a user