Auto-sync: 2026-04-19 14:51
This commit is contained in:
@@ -1,8 +1,8 @@
|
||||
---
|
||||
title: "GOG-CLI 安装配置指南"
|
||||
type: source
|
||||
tags: [gog, gog-cli, macos, google-workspace, oauth]
|
||||
date: 2026-03-15
|
||||
tags: [gog-cli, macos, google-workspace, oauth]
|
||||
date: 2026-04-19
|
||||
---
|
||||
|
||||
## Source File
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
title: "Last30Days 使用指南"
|
||||
type: source
|
||||
tags: [hackernews, instagram, last30days, polymarket, scrapecreator, tiktok, x, youtube]
|
||||
date: 2026-04-18
|
||||
date: 2026-04-19
|
||||
---
|
||||
|
||||
## Source File
|
||||
@@ -25,6 +25,7 @@ date: 2026-04-18
|
||||
> "Polymarket 赔率是最高置信度的数据" — 使用指南
|
||||
|
||||
## Key Concepts
|
||||
- [[Comparative Mode]]:对比模式,通过 "X vs Y" 格式生成并排对比研究
|
||||
- [[Last-30-Days-Skill]]:Matt Van Horn 开发的 Reddit/X 研究技能,获取过去 30 天用户痛点
|
||||
- [[Market-Research]]:通过用户反馈和数据分析识别产品机会的过程
|
||||
- [[MVP]]:最小可行产品,用最少的资源验证核心产品假设
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
title: "Obsidian 必装 Skills"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-04-18
|
||||
date: 2026-04-19
|
||||
---
|
||||
|
||||
## Source File
|
||||
|
||||
@@ -5,7 +5,7 @@ tags: [cloud-computing, public-cloud, private-cloud, hybrid-cloud]
|
||||
date: 2025-06-18
|
||||
source_file: raw/Cloud & DevOps/Public vs Private vs Hybrid Cloud Differences Explained.md
|
||||
sources: []
|
||||
last_updated: 2025-06-18
|
||||
last_updated: 2026-04-19
|
||||
---
|
||||
|
||||
## Source File
|
||||
@@ -55,4 +55,4 @@ last_updated: 2025-06-18
|
||||
| 可扩展性 | 高 | 中至高 | 高 |
|
||||
| 控制力 | 低 | 高 | 中 |
|
||||
| 合规性 | 中 | 高 | 高 |
|
||||
| 典型用例 | 开发测试、弹性需求 | 敏感数据、高合规要求 | 多元化业务需求 |
|
||||
| 典型用例 | 开发测试、弹性需求 | 敏感数据、高合规要求 | 多元化业务需求 |
|
||||
@@ -0,0 +1,66 @@
|
||||
---
|
||||
title: "CTP Topic 11 AD Integration and Login using AD accounts"
|
||||
type: source
|
||||
tags:
|
||||
- AWS
|
||||
- AD
|
||||
- IAM
|
||||
- SSO
|
||||
- CTP
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
|
||||
- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/02_IAM/ctp-topic-11-ad-integration-and-login-using-ad-accounts.md]]
|
||||
|
||||
## Summary
|
||||
|
||||
- 核心主题:Jenkins 与 Active Directory 集成实现自动登录,以及 CI/CD 流水线自动化安全检查
|
||||
- 问题域:DevOps 身份认证、基础设施代码质量控制
|
||||
- 方法/机制:AD 集成实现用户自动认证,pre-commit 框架嵌入 terraform fmt、TFLint、Checkov 工具
|
||||
- 结论/价值:简化用户入职/离职的账号管理,自动化检测"坏代码"和安全漏洞,提升 IaC 安全性和稳定性
|
||||
|
||||
## Key Claims
|
||||
|
||||
- AD 集成后无需手动创建本地用户,实现基于 AD 账号的自动登录
|
||||
- 下一步将利用 AD 组策略实现 RBAC 权限管理(只读、读写、流水线创建权限)
|
||||
- pre-commit 框架在代码提交阶段执行 terraform fmt、TFLint、Checkov 三大检查
|
||||
- 分层治理模式:Commit 阶段仅自动化检查 → PR 阶段执行检查+terraform plan → 合并后人工审核+terraform apply
|
||||
|
||||
## Key Quotes
|
||||
|
||||
> "通过 AD 集成,团队告别了过去手动创建本地用户的繁琐流程,实现了基于 AD 账号的自动登录。这不仅简化了用户入职与离职的账号管理,还为未来实施基于角色的访问控制(RBAC)奠定了基础。"
|
||||
|
||||
> "pre-commit 框架用于管理和维护多语言预提交钩子,在代码提交至仓库前识别简单问题。"
|
||||
|
||||
> "工作流设计强调'左移'思想:在功能分支的每次提交时仅触发自动化检查;在 PR 阶段触发检查与 terraform plan;只有在代码合并至 Master 分支并经过人工审核后,才会执行最终的 terraform apply。"
|
||||
|
||||
## Key Concepts
|
||||
|
||||
- [[AD Integration]]:将 Jenkins 安全域与企业 AD 关联,实现用户身份统一认证
|
||||
- [[RBAC]]:基于角色的访问控制,通过 AD 组策略决定用户在 Jenkins 中的操作权限
|
||||
- [[Pre-commit Framework]]:管理预提交钩子的框架,提交前自动检查代码
|
||||
- [[terraform fmt]]:Terraform 内置格式化工具,统一代码风格
|
||||
- [[TFLint]]:Terraform 静态分析工具,检查代码错误、过时语法、缺失参数
|
||||
- [[Checkov]]:IaC 安全扫描工具,检测安全配置错误
|
||||
- [[Static Analysis]]:静态分析,不运行代码而检查潜在错误/漏洞
|
||||
- [[CI/CD 左移]]:在流水线早期阶段嵌入质量门禁
|
||||
|
||||
## Key Entities
|
||||
|
||||
- [[Jenkins]]:开源自动化服务器,用于 CI/CD
|
||||
- [[Niranjan]]:本次 DevOps Cloud Learning Session 主讲人
|
||||
|
||||
## Connections
|
||||
|
||||
- [[Jenkins]] ← 使用 ← [[AD Integration]]
|
||||
- [[AD Integration]] → 依赖 → [[Active Directory]]
|
||||
- [[Pre-commit Framework]] → 调用 → [[terraform fmt]]
|
||||
- [[Pre-commit Framework]] → 调用 → [[TFLint]]
|
||||
- [[Pre-commit Framework]] → 调用 → [[Checkov]]
|
||||
- [[CI/CD 左移]] → 包含 → [[Pre-commit Framework]]
|
||||
|
||||
## Contradictions
|
||||
|
||||
- (暂无)
|
||||
@@ -0,0 +1,51 @@
|
||||
---
|
||||
title: "CTP Topic 29 Cloud Monitoring – SaaS LZ accounts"
|
||||
type: source
|
||||
tags:
|
||||
- AWS
|
||||
- Monitoring
|
||||
- SaaS
|
||||
- Landing-Zone
|
||||
- CTP
|
||||
- OpsBridge
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/ctp-topic-29-cloud-monitoring-saas-lz-accounts.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题:AWS 云监控解决方案 OpsBridge 在 SaaS Landing Zone 多账号环境中的应用
|
||||
- 问题域:企业级多账号 AWS 环境的集中化监控挑战
|
||||
- 方法/机制:Micro Focus OpsBridge 容器化解决方案,通过 IAM 角色跨账号读取 CloudWatch 数据,存储于 Optic 数据湖(Vertica 数据库)
|
||||
- 结论/价值:支持监控 20+ AWS 数据服务,提供事件视角、拓扑视图和性能仪表板,标签驱动监控最佳实践
|
||||
|
||||
## Key Claims
|
||||
- OpsBridge 可在本地或 AWS EKS 上部署,支持监控超过 20 个 AWS 数据服务
|
||||
- 数据存储在 Optic 数据湖(Vertica),支持高性能仪表板和报表
|
||||
- 使用只读 IAM 角色从 CloudWatch 获取指标,单一实例可监控多个账号和区域
|
||||
- 基于标签的监控是最佳实践,自动化识别缺失标签
|
||||
|
||||
## Key Quotes
|
||||
> "Cloud Monitoring is enabled within OpsBridge, requiring a one-time IAM role setup in customer accounts for read-only access."
|
||||
|
||||
> "Tag-based monitoring is emphasized as a best practice, with automation to identify missing tags."
|
||||
|
||||
## Key Concepts
|
||||
- [[OpsBridge]]:Micro Focus 运营桥监控平台,用于 AWS 云监控
|
||||
- [[CloudWatch]]:AWS 监控和可观测性服务,OpsBridge 从中获取指标数据
|
||||
- [[CMDB]]:配置管理数据库,存储和管理 IT 基础设施配置项
|
||||
- [[Tagging-Methodology]]:标签方法论,驱动资源识别和监控策略
|
||||
- [[Multi-Account-Strategy]]:AWS 多账号架构策略,SaaS LZ 环境中的应用
|
||||
|
||||
## Key Entities
|
||||
- [[AWS]]:公有云平台,提供 EKS 容器化部署能力
|
||||
- [[Micro-Focus]]:企业软件公司,OpsBridge 产品提供商
|
||||
- [[CCOE]]:Cloud Center of Excellence,推动云采纳和治理的核心组织
|
||||
|
||||
## Connections
|
||||
- [[ctp-topic-8-implementation-of-cloud-monitoring-using-micro-focus-operations-bridge]] ← extends ← [[CTP Topic 29]]
|
||||
- [[ctp-topic-60-monitor-aws-using-hyperscale-observability-with-grafana]] ← relates_to ← [[CTP Topic 29]]
|
||||
|
||||
## Contradictions
|
||||
- (暂无)
|
||||
53
wiki/sources/ctp-topic-37-secrets-certificates-management.md
Normal file
53
wiki/sources/ctp-topic-37-secrets-certificates-management.md
Normal file
@@ -0,0 +1,53 @@
|
||||
---
|
||||
title: "CTP Topic 37 Secrets Certificates Management"
|
||||
type: source
|
||||
tags:
|
||||
- AWS
|
||||
- Secrets-Manager
|
||||
- Certificates
|
||||
- Security
|
||||
- CTP
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/07_Security/ctp-topic-37-secrets-certificates-management.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题:云转型项目中的密钥与证书管理方案选型与实施
|
||||
- 问题域:企业级 secrets 管理工具评估与标准化
|
||||
- 方法/机制:AWS Secrets Manager、HashiCorp Vault、CyberArk PAM 三方案对比,30天试点验证
|
||||
- 结论/价值:选择 AWS Secrets Manager 作为企业标准,集成 Control Tower 实现 CI/CD 流程中的密钥自动化管理
|
||||
|
||||
## Key Claims
|
||||
- AWS Secrets Manager 与 AWS RDS、Redshift、DynamoDB 有内置集成,支持高可用和灾备
|
||||
- HashiCorp Vault 免费版缺乏企业级能力(高可用、多租户)
|
||||
- AWS Secrets Manager 在账户级别管理密钥,可降低成本并提升安全性
|
||||
|
||||
## Key Quotes
|
||||
> "AWS Secrets Manager is easy and simple to implement."
|
||||
> "The pilot phase included HashiCorp Vault and AWS Secrets Manager."
|
||||
> "Implementation phase involves removing clear text passwords and keys from CI/CD processes, starting with Control Tower."
|
||||
|
||||
## Key Concepts
|
||||
- [[Secrets Management]]:数字认证凭证、密钥、API Token 等敏感信息的管理
|
||||
- [[Secret Rotation]]:自动轮换密钥以提升安全性的机制
|
||||
- [[CI/CD Secrets Management]]:在持续集成/部署流程中安全管理密钥
|
||||
|
||||
## Key Entities
|
||||
- [[AWS]]:云服务提供商,Secrets Manager 所属平台
|
||||
- [[AWS Secrets Manager]]:AWS 托管的密钥管理服务
|
||||
- [[HashiCorp Vault]]:自托管密钥管理工具
|
||||
- [[CyberArk PAM]]:特权访问管理解决方案
|
||||
- [[AWS Control Tower]]:AWS 账户治理服务
|
||||
|
||||
## Connections
|
||||
- [[AWS Secrets Manager]] ← chosen_as ← [[Secrets Management]]
|
||||
- [[AWS Control Tower]] ← implements ← [[CI/CD Secrets Management]]
|
||||
- [[AWS]] ← provides ← [[AWS Secrets Manager]]
|
||||
|
||||
## Contradictions
|
||||
- 与 [[CTP Topic 62 AWS Secrets Manager]] 冲突:
|
||||
- 冲突点:两份文档都涉及 AWS Secrets Manager
|
||||
- 当前观点:本文描述选型过程,Topic 62 描述实施细节
|
||||
- 对方观点:Topic 62 聚焦分阶段实施方法和 JDBC Wrapper 无密码登录
|
||||
@@ -0,0 +1,44 @@
|
||||
---
|
||||
title: "CTP Topic 39 Implementing EKS in the AWS Lab Landing Zone"
|
||||
type: source
|
||||
tags: [AWS, EKS, Kubernetes, Landing-Zone, CTP]
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/ctp-topic-39-implementing-eks-in-the-aws-lab-landing-zone.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题:在 AWS Lab Landing Zone 中实现 EKS(Elastic Kubernetes Service)
|
||||
- 问题域:IP 地址有限导致 EKS 部署困难
|
||||
- 方法/机制:创建私有子网、使用 Terraform/Terragrunt 模块、配置自定义网络
|
||||
- 结论/价值:EKS 模块支持自定义网络配置标志,通过 Terraform 实现 EKS 集群部署
|
||||
|
||||
## Key Claims
|
||||
- EKS 模块提供自定义网络配置标志控制 IP 分配
|
||||
- 私有子网方案可解决 IP 地址有限问题
|
||||
- Terragrunt 模块用于自动化 EKS 部署
|
||||
|
||||
## Key Quotes
|
||||
> "They utilized Terraform and Terragrunt modules to create the lab, working with SRE to enable EKS to create its own subnet and use its own IPs within each pod."
|
||||
|
||||
> "Within the spec configuration, we basically have to put host network equals true."
|
||||
|
||||
## Key Concepts
|
||||
- [[EKS]]:AWS 托管 Kubernetes 服务
|
||||
- [[Terraform]]:基础设施即代码工具
|
||||
- [[Terragrunt]]:Terraform 封装工具
|
||||
- [[Landing Zone]]:云基础架构框架
|
||||
|
||||
## Key Entities
|
||||
- [[AWS]]:云平台提供商
|
||||
- [[Spencer]]:演讲者
|
||||
- [[Guy]]:演讲者
|
||||
- [[Octane]]:Microfocus SaaS 应用
|
||||
|
||||
## Connections
|
||||
- [[CTP Topic 70 EKS Deployment using IAC]] ← relates_to ← [[EKS Deployment]]
|
||||
- [[Terraform]] ← used_in ← [[EKS Deployment]]
|
||||
|
||||
## Contradictions
|
||||
- (暂无)
|
||||
52
wiki/sources/ctp-topic-42-grafana-observability-dashboard.md
Normal file
52
wiki/sources/ctp-topic-42-grafana-observability-dashboard.md
Normal file
@@ -0,0 +1,52 @@
|
||||
---
|
||||
title: "CTP Topic 42 Grafana Observability Dashboard"
|
||||
type: source
|
||||
tags: [Grafana, Observability, Dashboard, CTP, DevOps]
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/ctp-topic-42-grafana-observability-dashboard.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题:Grafana 可观测性平台与仪表盘设计
|
||||
- 问题域:云监控可视化、企业级监控告警
|
||||
- 方法/机制:Grafana 数据源集成、Terraform 自动化、IAM 跨账户访问、Prometheus 网络监控
|
||||
- 结论/价值:Grafana 作为统一监控平台,支持多数据源集成和 Terraform 自动化部署,计划替代 Micro Focus 工具实现端到端监控
|
||||
|
||||
## Key Claims
|
||||
- Grafana 是开源数据可视化平台,支持多种数据源(Metrics、Logs)
|
||||
- Grafana 通过 IAM Role 策略访问多 AWS 账户的监控数据
|
||||
- Terraform 模块实现 Grafana 资源自动化配置
|
||||
- Prometheus 作为数据源用于网络设备监控(Checkpoint、Firewall)
|
||||
- 未来规划:告警规则细化、应用专用仪表盘、推广 Terraform 模块
|
||||
|
||||
## Key Quotes
|
||||
> "Grafana does not exist differently data source by itself. It needs to be expressed from the data, all kinds of data sources." — Grafana 数据无关性,需从数据源表达
|
||||
|
||||
> "We would like to build application specific dashboards which can basically give us key insight with respect to our applications that are running over there." — 构建应用专用仪表盘提供关键洞察
|
||||
|
||||
## Key Concepts
|
||||
- [[Grafana]]:开源数据可视化平台,通过图表和仪表盘展示监控数据
|
||||
- [[可观测性]](Observability):系统内部状态的可度量程度,包含 Metrics、Logs、Traces 三大信号
|
||||
- [[Prometheus]]:开源监控系统,作为数据源为网络设备(Checkpoint、Firewall)提供指标采集
|
||||
- [[Terraform]]:基础设施即代码工具,用于自动化 Grafana 资源配置
|
||||
- [[IAM Role]]:AWS 身份访问管理角色,用于跨账户访问控制
|
||||
|
||||
## Key Entities
|
||||
- [[AWS CloudWatch]]:AWS 原生监控服务,Grafana 集成的数据源之一
|
||||
- [[AWS EKS]]:Amazon Elastic Kubernetes Service,视频所属的云学习主题
|
||||
- [[Micro Focus OpsBridge]]:当前企业监控平台,计划被 Grafana 替换
|
||||
|
||||
## Connections
|
||||
- [[Grafana]] ← integrates ← [[AWS CloudWatch]]
|
||||
- [[Grafana]] ← integrates ← [[Prometheus]]
|
||||
- [[Grafana]] ← provisions_with ← [[Terraform]]
|
||||
- [[Grafana]] ← accesses_via ← [[IAM Role]]
|
||||
- [[CTP Topic 42]] ← part_of ← [[Public Cloud Learning Sessions]]
|
||||
|
||||
## Contradictions
|
||||
- 与 [[TikTok Shop - Apache Superset Dashboard设计思路]] 冲突:
|
||||
- 冲突点:数据可视化工具选择
|
||||
- 当前观点:Grafana 用于基础设施和应用监控
|
||||
- 对方观点:Apache Superset 用于电商业务数据可视化
|
||||
@@ -0,0 +1,56 @@
|
||||
---
|
||||
title: "CTP Topic 5 - AWS Identity and Access Management (IAM)"
|
||||
type: source
|
||||
tags: [AWS, IAM, Security, CTP, cloud-learning]
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/02_IAM/ctp-topic-5-aws-identity-and-access-management-iam.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题:AWS IAM 用户、组、角色和策略的管理,以及通过 CLI 和联合访问 AWS 的方式
|
||||
- 问题域:Landing Zone 账号访问控制、联邦认证、权限管理
|
||||
- 方法/机制:IAM 用户(服务账号)、联合访问(AD 组映射角色)、角色与策略、Terraform 模块定义
|
||||
- 结论/价值:联邦访问是用户管理的首选方式,角色和策略是权限管理的核心,遵循最小权限原则
|
||||
|
||||
## Key Claims
|
||||
- 联合访问是用户管理的首选方法,IAM 用户仅用于服务账号
|
||||
- 角色不执行操作,而是将"谁"和"能做什么"关联在一起
|
||||
- 策略定义允许或拒绝的具体操作和资源
|
||||
- 最小权限原则是 IAM 策略设计的核心指导原则
|
||||
|
||||
## Key Quotes
|
||||
> "Roles don't enable actions; they tie together who can do something and what they can do." — IAM 角色核心概念
|
||||
|
||||
> "We only want to allow the access that is strictly required." — 最小权限原则
|
||||
|
||||
> "Federated users log in via their organization's AD, which maps to an IAM role." — 联合访问流程
|
||||
|
||||
## Key Concepts
|
||||
- [[IAM]]: AWS 身份和访问管理服务
|
||||
- [[IAM-用户]]: IAM 身份,主要用于服务账号而非人员
|
||||
- [[IAM-组]]: IAM 组的概念在联合用户管理中较少使用
|
||||
- [[IAM-角色]]: 将主体与权限关联的 IAM 身份,可由服务或用户 assum
|
||||
- [[IAM-策略]]: 定义允许或拒绝操作的文档
|
||||
- [[联合访问]]: 通过 AD 组映射 IAM 角色的用户访问方式
|
||||
- [[PFSSO]]: 命令行联合访问工具
|
||||
- [[最小权限原则]]: 只授予完成任务所需的最小权限
|
||||
- [[内联策略]]: 绑定到特定角色的策略,可重用
|
||||
- [[托管策略]]: 可跨角色重用的 AWS 管理策略
|
||||
- [[Landing-Zone]]: AWS 多账号架构的基础环境
|
||||
- [[accounts-json]]: Landing Zone 根目录下的账号列表文件
|
||||
|
||||
## Key Entities
|
||||
- [[AWS]]: 全球最大公有云平台,提供 IAM 服务
|
||||
- [[Active-Directory]]: Microsoft 目录服务,用于联合用户身份验证
|
||||
- [[Gruntwork]]: Landing Zone 框架提供商
|
||||
|
||||
## Connections
|
||||
- [[AD]] ← maps_to_role ← [[IAM-角色]]
|
||||
- [[IAM-角色]] ← contains ← [[IAM-策略]]
|
||||
- [[联合访问]] ← requires ← [[PFSSO]]
|
||||
- [[Landing-Zone]] ← has ← [[accounts-json]]
|
||||
|
||||
## Contradictions
|
||||
- (暂无记录)
|
||||
60
wiki/sources/ctp-topic-54-esm-saas-log-analytics.md
Normal file
60
wiki/sources/ctp-topic-54-esm-saas-log-analytics.md
Normal file
@@ -0,0 +1,60 @@
|
||||
---
|
||||
title: "CTP Topic 54 ESM SaaS Log Analytics"
|
||||
type: source
|
||||
tags: [Log-Analytics, SaaS, ESM, CTP, EKS]
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/ctp-topic-54-esm-saas-log-analytics.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题:ESM(Enterprise Service Management)SaaS Log Analytics(日志分析)架构与实践
|
||||
- 问题域:云环境日志采集、存储、分析和可视化
|
||||
- 方法/机制:ELK Stack(Elasticsearch、Logstash、Kibana)/OpenSearch 架构,BEATS 代理采集,VPC 间私有流量传输,TLS 1.2 加密,RBAC 访问控制
|
||||
- 结论/价值:Log Analytics 是云运维可观测性的核心组件,不同解决方案(Logz.io、AWS OpenSearch、自托管 ELK、Microfocus OBA)在成本、管理复杂度和功能上有显著差异
|
||||
|
||||
## Key Claims
|
||||
- ELK Stack 是日志分析的标准开源方案,由 Elasticsearch(存储搜索)、Logstash(处理转换)和 Kibana(可视化)组成
|
||||
- 应用通过 BEATS 代理(Filebeat、Metricbeat 等)采集日志,Filebeat 作为容器持续将日志从应用 VPC 发送到日志 VPC
|
||||
- OpenSearch 是 AWS 的 ELK 开源替代方案,提供托管服务
|
||||
- 出于 GDPR 合规要求,日志农场按区域split(Oregon 美国、Europe 欧洲)
|
||||
- 静态加密使用加密节点和 NVMe 设备硬件级加密,传输加密使用 TLS 1.2
|
||||
- VPC 间流量走私有网络,不经过公网
|
||||
- 成本对比(单农场、14天保留、每日 100GB):Logz.io 约 $4,000/月,AWS OpenSearch 约 $1,500/月,自托管成本最低但维护量大
|
||||
- 可用性 SLA:Logz.io 99.8%,AWS OpenSearch 99.9%
|
||||
|
||||
## Key Quotes
|
||||
> "The application collects your log, it's called the BEATS." — Jackie, ITOM ESM SAS architect
|
||||
|
||||
> "Due to legal reasons like GDPR, farms are split regionally, with farms in Oregon, the US, and Europe." — 区域合规要求
|
||||
|
||||
> "We have already built up all the farms." — 实施状态
|
||||
|
||||
## Key Concepts
|
||||
- [[ELK Stack]]:Elasticsearch + Logstash + Kibana 开源日志分析技术栈
|
||||
- [[OpenSearch]]:AWS 的 ELK 开源分支,托管日志分析服务
|
||||
- [[Logstash]]:日志处理管道,聚合和转换日志数据
|
||||
- [[Kibana]]:日志可视化前端
|
||||
- [[BEATS]]:Elastic 开发的轻量级数据采集器家族(Filebeat、Metricbeat、Heartbeat 等)
|
||||
- [[Filebeat]]:运行在容器中的日志文件采集代理
|
||||
- [[Redis]]:可选的消息队列缓冲,防止 Logstash 过载
|
||||
- [[RBAC]]:基于角色的访问控制
|
||||
- [[GDPR]]:欧盟通用数据保护条例,合规驱动区域部署
|
||||
- [[TLS 1.2]]:传输层安全协议版本
|
||||
- [[Log Analytics]]:日志分析,日志数据的采集、存储、搜索和可视化
|
||||
|
||||
## Key Entities
|
||||
- [[Jackie]]:ITOM ESM SAS architect,演讲者
|
||||
|
||||
## Connections
|
||||
- [[ELK Stack]] ← depends_on ← [[BEATS]]
|
||||
- [[ELK Stack]] ← depends_on ← [[Logstash]]
|
||||
- [[ELK Stack]] ← depends_on ← [[Elasticsearch]]
|
||||
- [[ELK Stack]] ← depends_on ← [[Kibana]]
|
||||
- [[OpenSearch]] ← extends ← [[ELK Stack]]
|
||||
- [[Logstash]] ← uses_buffer ← [[Redis]]
|
||||
- [[Log Analytics]] ← implements ← [[Observability-Engineering]]
|
||||
|
||||
## Contradictions
|
||||
- (暂无)
|
||||
@@ -0,0 +1,57 @@
|
||||
---
|
||||
title: "CTP Topic 59 Achieving reliability with Amazon EKS"
|
||||
type: source
|
||||
tags: [AWS, EKS, Kubernetes, Reliability, CTP]
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/ctp-topic-59-achieving-reliability-with-amazon-eks.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题:Amazon EKS 可靠性实践,涵盖容器服务选型、共享责任模型、三层可靠性设计
|
||||
- 问题域:如何在 EKS 上构建高可靠性 Kubernetes 集群
|
||||
- 方法/机制:应用可靠性(Pod 分布、HPA、VPA、探针)、控制平面可靠性(监控、认证、集群升级)、数据平面可靠性(节点检测、资源预留、QoS)
|
||||
- 结论/价值:EKS 可靠性需要从应用层、控制层、数据层全面考虑,AWS 与客户按共享责任模型分工
|
||||
|
||||
## Key Claims
|
||||
- ECS 适合容器入门用户,EKS 适合熟悉 Kubernetes 生态的用户
|
||||
- 可靠性是指系统在故障发生时仍能提供可预测行为
|
||||
- AWS 负责管理控制平面(API Server、etcd、Scheduler、Controller Manager),客户负责数据平面(Worker Node、OS、应用配置)
|
||||
- Fargate 模式下客户无需管理节点和补丁升级
|
||||
- 应用可靠性通过 Pod 反亲和性、拓扑分布约束、HPA/VPA、探针、Pod 中断预算实现
|
||||
- 控制平面可靠性通过监控控制平面指标、安全认证、精心配置的 webhook、集群升级实现
|
||||
- 数据平面可靠性通过节点问题检测器、系统资源预留、QoS 资源配额实现
|
||||
|
||||
## Key Quotes
|
||||
> "Reliability in a system means it offers predictable behavior even when failures occur." — Surav Paul
|
||||
|
||||
> "ECS is a more AWS opinionated way of running containers." — Surav Paul
|
||||
|
||||
> "With Fargate, you don't have to worry about managing the nodes or worrying about patching or upgrading the nodes." — Surav Paul
|
||||
|
||||
## Key Concepts
|
||||
- [[EKS 可靠性]]:系统在故障发生时仍提供可预测行为
|
||||
- [[共享责任模型]]:AWS 管理控制平面,客户负责数据平面和应用
|
||||
- [[Pod 反亲和性]]:避免 Pod 部署在同一节点或可用区
|
||||
- [[拓扑分布约束]]:细粒度控制 Pod 在可用区间的分布
|
||||
- [[HPA]]:Horizontal Pod Autoscaler,根据 CPU/内存自动扩展 Pod
|
||||
- [[VPA]]:Vertical Pod Autoscaler,自动调整 Pod 资源请求
|
||||
- [[探针]]:Liveness、Readiness、Startup 探针用于 Pod 健康检测
|
||||
- [[Pod 中断预算]]:确保维护期间仍提供最低服务水平
|
||||
|
||||
## Key Entities
|
||||
- [[Surav Paul]]:AWS 高级解决方案架构师,本主题演讲人
|
||||
- [[AWS]]:公有云平台,提供 EKS 服务
|
||||
- [[EKS]]:Elastic Kubernetes Service,AWS 托管 Kubernetes 服务
|
||||
- [[ECS]]:Elastic Container Service,AWS 容器服务
|
||||
- [[Fargate]]:AWS 无服务器容器运行环境
|
||||
|
||||
## Connections
|
||||
- [[EKS]] ← 使用 [[共享责任模型]] ← [[AWS]]
|
||||
- [[Surav Paul]] ← 演讲 [[CTP Topic 59 Achieving reliability with Amazon EKS]]
|
||||
- [[CTP Topic 59 Achieving reliability with Amazon EKS]] ← 依赖 [[EKS]]
|
||||
- [[CTP Topic 70 EKS Deployment using IAC]] ← 关联主题
|
||||
|
||||
## Contradictions
|
||||
- (暂无)
|
||||
@@ -0,0 +1,47 @@
|
||||
---
|
||||
title: "CTP Topic 60 Monitor AWS using Hyperscale Observability with Grafana"
|
||||
type: source
|
||||
tags: [AWS, Grafana, Observability, Hyperscale, CTP, monitoring]
|
||||
sources: []
|
||||
last_updated: 2026-04-19
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/ctp-topic-60-monitor-aws-using-hyperscale-observability-with-grafana.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题:AWS 云监控与 Grafana 可观测性平台集成
|
||||
- 问题域:企业级 AWS 云监控解决方案
|
||||
- 方法/机制:Hyperscale Observability 架构,Grafana 与多数据源集成,Dashboard-as-Code,Terraform 模块自动化 provisioning
|
||||
- 结论/价值:通过 Grafana Enterprise License 实现全面的云资源监控、事件跟踪和告警集成
|
||||
|
||||
## Key Claims
|
||||
- Grafana 与多种数据源集成实现统一的监控可视化
|
||||
- 通过 Terraform 模块为产品团队自动创建 Grafana 组织、用户、文件夹、IAM 角色和仪表板
|
||||
- Optic DR 是将数据拉入 Grafana 仪表板的关键内部监控解决方案
|
||||
- Grafana 告警系统灵活配置,可转发到 OpsBridge 创建事件
|
||||
- 实例监控帮助识别资源利用情况,资源标签分类实现有效管理
|
||||
|
||||
## Key Quotes
|
||||
> "The product team can consume the modules by using sample telegram HCL file" — Terraform 模块的自服务消费方式
|
||||
|
||||
> "Default dashboards are provided for accounts onboarded to code" — 账户 onboarding 后自动提供默认仪表板
|
||||
|
||||
## Key Concepts
|
||||
- [[Grafana]]:可观测性数据可视化平台
|
||||
- [[Observability-Engineering]]:可观测性工程
|
||||
- [[Dashboard-as-Code]]:通过代码管理 Grafana 仪表板的实践
|
||||
- [[Hyperscale-Monitoring]]:超大规模监控能力
|
||||
|
||||
## Key Entities
|
||||
- [[Grafana]]:开源可视化监控平台
|
||||
- [[Prometheus]]:指标数据源
|
||||
- [[Loki]]:日志数据源
|
||||
|
||||
## Connections
|
||||
- [[Grafana]] ← 集成 ← [[Prometheus]]
|
||||
- [[Grafana]] ← 集成 ← [[Loki]]
|
||||
- [[Observability-Engineering]] ← 核心框架 ← [[Hyperscale-Monitoring]]
|
||||
|
||||
## Contradictions
|
||||
- (暂无)
|
||||
58
wiki/sources/ctp-topic-62-aws-secrets-manager.md
Normal file
58
wiki/sources/ctp-topic-62-aws-secrets-manager.md
Normal file
@@ -0,0 +1,58 @@
|
||||
---
|
||||
title: "CTP Topic 62 AWS Secrets Manager"
|
||||
type: source
|
||||
tags:
|
||||
- AWS
|
||||
- Secrets-Manager
|
||||
- Security
|
||||
- CTP
|
||||
- Cloud-Learning
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/07_Security/ctp-topic-62-aws-secrets-manager.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题:AWS Secrets Manager 在企业云环境中的实施与最佳实践
|
||||
- 问题域:敏感信息(密码、API密钥)管理、安全集中化、密钥轮换
|
||||
- 方法/机制:AWS Secrets Manager 集中化管理、分阶段实施(集中→自动化获取→轮换)、Lambda 函数实现数据库密码轮换、JDBC Wrapper 无密码登录
|
||||
- 结论/价值:AWS Secrets Manager 是 HashiCorp Vault 的成本效益替代方案,通过分阶段方法实现开发人员无需直接访问敏感信息
|
||||
|
||||
## Key Claims
|
||||
- AWS Secrets Manager 易于实施且成本效益优于 HashiCorp Vault
|
||||
- 分阶段实施方法:集中化敏感信息→调整自动化获取→启动密钥轮换
|
||||
- 开发人员实际上不需要直接访问敏感信息
|
||||
- Control Tower 堆栈重新设计确保所有堆栈使用相同的密钥
|
||||
- AWS Secrets Manager 不需要客户端(与 HashiCorp Vault 对比)
|
||||
|
||||
## Key Quotes
|
||||
> "AWS Secrets Manager is easy and simple to implement." — 演讲者
|
||||
> "With that idea, developers actually do not need to have direct access to their Secrets." — 标准文档核心理念
|
||||
|
||||
## Key Concepts
|
||||
- [[AWS Secrets Manager]]:AWS 云原生敏感信息管理服务
|
||||
- [[Secret Rotation]]:密钥轮换,自动更新存储的敏感信息
|
||||
- [[JDBC Wrapper]]:使用 AWS SDK 从 Secrets Manager 检索密钥的 JDBC 包装器
|
||||
- [[Control Tower]]:AWS Control Tower 用于设置安全的多账号 AWS 环境
|
||||
- [[HashiCorp Vault]]:企业级敏感信息管理工具(对比方案)
|
||||
- [[Lambda Rotation]]:使用 Lambda 函数执行数据库密码轮换
|
||||
|
||||
## Key Entities
|
||||
- [[Nurit]]:演讲者之一
|
||||
- [[Daniel]]:演讲者之一,分享实施机会
|
||||
- [[Victor]]:演示无密码 Oracle 数据库登录
|
||||
- [[SendGrid]]:集中邮件服务的密钥轮换目标
|
||||
- [[Oracle Database]]:通过 Lambda 实现密码轮换的数据库
|
||||
|
||||
## Connections
|
||||
- [[AWS Secrets Manager]] ← cost_effective_alternative ← [[HashiCorp Vault]]
|
||||
- [[CTP]] ← uses ← [[AWS Secrets Manager]]
|
||||
- [[Control Tower]] ← secured_by ← [[AWS Secrets Manager]]
|
||||
- [[Oracle Database]] ← rotates_password_via ← [[Lambda Rotation]]
|
||||
|
||||
## Contradictions
|
||||
- 与 HashiCorp Vault 对比:
|
||||
- 冲突点:选择哪个敏感信息管理平台
|
||||
- 当前观点:AWS Secrets Manager 成本效益更优,无需客户端
|
||||
- 对方观点:HashiCorp Vault 功能更全面,适合复杂企业需求
|
||||
51
wiki/sources/ctp-topic-64-scaling-out-with-amazon-eks.md
Normal file
51
wiki/sources/ctp-topic-64-scaling-out-with-amazon-eks.md
Normal file
@@ -0,0 +1,51 @@
|
||||
---
|
||||
title: "CTP Topic 64 Scaling out with Amazon EKS"
|
||||
type: source
|
||||
tags: [AWS, EKS, Kubernetes, Scaling, CTP]
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/ctp-topic-64-scaling-out-with-amazon-eks.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题:Amazon EKS 水平扩展与垂直扩展机制
|
||||
- 问题域:EKS 集群扩容、应用伸缩、IP 地址管理
|
||||
- 方法/机制:HPA(水平 Pod 自动扩缩容)、KEDA(事件驱动扩缩容)、Karpenter/C Cluster Autoscaler(容量扩缩容)、IPv6 解决 IP 耗尽
|
||||
- 结论/价值:多维度扩展策略保障 EKS 工作负载稳定性和成本效率
|
||||
|
||||
## Key Claims
|
||||
- HPA 是 Kubernetes 标准应用工作负载扩缩容机制,基于 CPU/内存指标计算副本数,支持自定义和外部指标
|
||||
- KEDA 支持基于外部事件的扩缩容,可从零副本启动,发布指标供 HPA 使用
|
||||
- Cluster Autoscaler 绑定 ASG(自动扩缩组),基于待调度 Pod 数量调整容量,考虑 CPU 和内存请求
|
||||
- Karpenter 是开源原生容量扩缩器,直接与 EC2 API 交互,支持动态按需供给,不依赖预配置节点组
|
||||
- IPv6 双栈 VPC 可解决 IP 耗尽问题,节点支持双栈 IP,Pod 仅需 IPv6 地址
|
||||
|
||||
## Key Quotes
|
||||
> "The horizontal pod autoscaler is going to pull the metrics and it is going to calculate how many replicas are required for your application workload."
|
||||
> "The scaling decision that is made by the cluster auto scaler, it is done on the number of pending pods in the cluster."
|
||||
|
||||
## Key Concepts
|
||||
- [[HPA]]:Horizontal Pod Autoscaler,Kubernetes 水平 Pod 自动扩缩容器
|
||||
- [[KEDA]]:Kubernetes Event-driven Autoscaling,事件驱动扩缩容框架
|
||||
- [[Karpenter]]:AWS 开源原生容量扩缩器,直接与 EC2 API 交互
|
||||
- [[Cluster Autoscaler]]:绑定 ASG 的 Kubernetes 容量扩缩器
|
||||
- [[IPv6 Networking]]:IPv6 网络解决 VPC IP 耗尽
|
||||
|
||||
## Key Entities
|
||||
- [[Suravpul]]:AWS 高级解决方案架构师,本次演讲嘉宾
|
||||
- [[AWS]]:Amazon Web Services,云服务提供商
|
||||
- [[EKS]]:Amazon Elastic Kubernetes Service,AWS 托管 Kubernetes 服务
|
||||
|
||||
## Connections
|
||||
- [[HPA]] ← uses ← [[Metrics Server]]
|
||||
- [[KEDA]] ← integrates_with ← [[HPA]]
|
||||
- [[Cluster Autoscaler]] ← depends_on ← [[ASG]]
|
||||
- [[Karpenter]] ← replaces ← [[Cluster Autoscaler]]
|
||||
- [[IPv6 Networking]] ← resolves ← [[IP Exhaustion]]
|
||||
|
||||
## Contradictions
|
||||
- 与 [[ctp-topic-59-achieving-reliability-with-amazon-eks]] 冲突:
|
||||
- 冲突点:EKS 扩展策略侧重点
|
||||
- 当前观点:本视频聚焦水平扩展机制(HPA、KEDA、容量扩缩器)
|
||||
- 对方观点:前视频聚焦可靠性保障机制
|
||||
@@ -0,0 +1,50 @@
|
||||
---
|
||||
title: "CTP Topic 67 Cloud Native Observability Using OpenTelemetry"
|
||||
type: source
|
||||
tags: [OpenTelemetry, Observability, Cloud-Native, EKS, AWS, CTP]
|
||||
sources: []
|
||||
last_updated: 2026-04-19
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/ctp-topic-67-cloud-native-observability-using-opentelemetry.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题:在 Amazon EKS 上实现云原生可观测性,基于 AWS 提供的 OpenTelemetry 实践课程
|
||||
- 问题域:云原生应用的可观测性实现,包括 Metrics、Logs、Traces 三大信号
|
||||
- 方法/机制:AWS Distro for OpenTelemetry (ADOT) 统一采集代理,支持多种部署模式
|
||||
- 结论/价值:提供厂商中立的标准化可观测性方案,降低多工具集成复杂度
|
||||
|
||||
## Key Claims
|
||||
- 可观测性是管理复杂系统的关键能力,构建可观测应用是开发者的责任
|
||||
- 三大信号(Traces、Metrics、Logs)支持响应式和主动式故障排查
|
||||
- ADOT 是经过安全加固的生产级方案,包含 AWS 自研组件和问题支持
|
||||
- OpenTelemetry 提供厂商中立的仪器化库,简化代码 instrumentation
|
||||
- ADOT 支持 sidecar、separate task、daemonset、high-availability replicas 等多种部署模式
|
||||
|
||||
## Key Quotes
|
||||
> "Observability is essential for managing complexity as systems evolve." — Surav, AWS
|
||||
> "Building observable applications is a developer responsibility." — Surav, AWS
|
||||
|
||||
## Key Concepts
|
||||
- [[OpenTelemetry]]:厂商中立的遥测数据采集框架,提供统一数据格式和 11 种语言 SDK
|
||||
- [[ADOT]]:AWS Distro for OpenTelemetry,经过安全加固的生产级发行版
|
||||
- [[OpenTelemetry Collector]]:使用 receivers、processors、exporters 管理信号
|
||||
- [[Trace]]:捕获应用调用栈中各层的处理时间
|
||||
- [[Metrics]]:从应用层和基础设施层收集的量化指标
|
||||
- [[Logs]]:应用运行日志,通过关联 ID 实现跨信号关联
|
||||
|
||||
## Key Entities
|
||||
- [[AWS]]:云服务提供商, 提供 EKS、CloudWatch、X-Ray 等可观测性服务
|
||||
- [[Amazon EKS]]:AWS 弹性 Kubernetes 服务
|
||||
|
||||
## Connections
|
||||
- [[OpenTelemetry]] ← is_basis_for ← [[ADOT]]
|
||||
- [[ADOT]] ← deployed_on ← [[Amazon EKS]]
|
||||
- [[ADOT]] ← integrates_with ← [[CloudWatch]]
|
||||
- [[ADOT]] ← integrates_with ← [[X-Ray]]
|
||||
|
||||
## Contradictions
|
||||
- 与 AWS CloudWatch/X-Ray 原生方案对比:
|
||||
- 原生方案:集成简单但供应商锁定
|
||||
- OpenTelemetry:标准化的 vendor-agnostic 方案,可灵活切换后端
|
||||
58
wiki/sources/ctp-topic-70-eks-deployment-using-iac.md
Normal file
58
wiki/sources/ctp-topic-70-eks-deployment-using-iac.md
Normal file
@@ -0,0 +1,58 @@
|
||||
---
|
||||
title: "CTP Topic 70 EKS Deployment using IAC"
|
||||
type: source
|
||||
tags:
|
||||
- AWS
|
||||
- EKS
|
||||
- IaC
|
||||
- Kubernetes
|
||||
- CTP
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/ctp-topic-70-eks-deployment-using-iac.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题:通过基础设施即代码(IaC)方式部署 EKS 集群
|
||||
- 问题域:EKS 集群部署方式、容器与虚拟机对比、自定义网络和自动扩展
|
||||
- 方法/机制:使用 Terraform 和 Service Catalog 两种 IaC 方式部署 EKS,ALB Ingress Controller 流量管理,EMI 自定义网络解决 CIDR 限制,Kubernetes Cluster Autoscaler 自动扩展
|
||||
- 结论/价值:EKS 提供完全托管的控制平面,支持零停机滚动部署和 IAM RBAC 最小权限访问
|
||||
|
||||
## Key Claims
|
||||
- EKS 是 AWS 提供的托管 Kubernetes 服务,具备完全托管的控制平面和工作节点自动扩展
|
||||
- 容器相比虚拟机具有更快的启动时间、内存效率和可移植性优势
|
||||
- 零停机滚动部署用于工作节点更新,IAM RBAC 映射实现最小权限访问
|
||||
- 自定义网络(EMI)解决 Pod 的 CIDR 限制问题
|
||||
|
||||
## Key Quotes
|
||||
> "EKS, a managed Kubernetes service by Amazon, offers features like fully managed control planes and autoscaling worker nodes."
|
||||
|
||||
> "The discussion begins with the differences between VMs and containers, highlighting the benefits of containers such as reduced boot time, memory efficiency, and portability."
|
||||
|
||||
## Key Concepts
|
||||
- [[Infrastructure as Code (IaC)]]:通过代码方式定义和管理基础设施
|
||||
- [[Kubernetes]]:用于弹性运行分布式系统的框架,支持自动化部署、回滚、负载均衡和 Pod 水平扩展
|
||||
- [[EKS]]:Amazon EKS,AWS 的托管 Kubernetes 服务
|
||||
- [[Terraform]]:HashiCorp 的 IaC 工具,用于定义 EKS 集群配置
|
||||
- [[Service Catalog]]:AWS 服务目录,用于创建和管理 EKS 集群
|
||||
- [[Cluster Autoscaler]]:Kubernetes 自动扩展器,根据资源需求自动扩展工作节点
|
||||
- [[ALB Ingress Controller]]:AWS 负载均衡器入口控制器,用于流量管理
|
||||
- [[CloudWatch]]:AWS 监控服务,结合 FluentBit 和 Container Insights 实现容器监控
|
||||
- [[FluentBit]]:日志转发器,以 DaemonSet 形式部署到 EKS 集群
|
||||
- [[Grafana]]:开源可视化平台,用于监控指标展示
|
||||
|
||||
## Key Entities
|
||||
- [[AWS]]:公有云平台,提供 EKS 服务
|
||||
- [[Terraform]]:IaC 工具供应商
|
||||
- [[Kubernetes]]:CNCF 开发的容器编排平台
|
||||
|
||||
## Connections
|
||||
- [[Infrastructure as Code (IaC)]] ← implements ← [[EKS]]
|
||||
- [[EKS]] ← manages ← [[Kubernetes]]
|
||||
- [[Cluster Autoscaler]] → scales → [[EKS Worker Nodes]]
|
||||
- [[ALB Ingress Controller]] → routes → [[EKS Services]]
|
||||
- [[CloudWatch]] ← monitors ← [[EKS Cluster]]
|
||||
|
||||
## Contradictions
|
||||
- (暂无)
|
||||
@@ -0,0 +1,56 @@
|
||||
---
|
||||
title: "CTP Topic 8 Implementation of Cloud monitoring using Micro Focus Operations Bridge"
|
||||
type: source
|
||||
tags: [cloud-learning, AWS, monitoring, OBM, CTP]
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/ctp-topic-8-implementation-of-cloud-monitoring-using-micro-focus-operations-brid.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题:使用 Micro Focus Operations Bridge Manager (OBM) 实现 AWS 云监控
|
||||
- 问题域:云环境监控能力补全,替代传统 Sitescope 方案
|
||||
- 方法/机制:OBM Management Packs + IAM Role-based Access + CloudWatch API 集成
|
||||
- 结论/价值:实现动态云监控,无需在客户账户安装服务器
|
||||
|
||||
## Key Claims
|
||||
- OBM 提供比 Sitescope 更灵活的动态监控能力
|
||||
- 通过 IAM Role 实现跨账户 CloudWatch 数据收集,无需共享 Access Key
|
||||
- Management Packs 定义监控策略,支持新实例自动部署监控
|
||||
- OBM 可监控任何公有云供应商(AWS、Azure、GCP)的 CloudWatch 指标
|
||||
|
||||
## Key Quotes
|
||||
> "The agent uses role-based access to collect data from CloudWatch API, eliminating the need to install servers in customer accounts and share sensitive access keys."
|
||||
|
||||
> "Whenever new instances are added, policies are automatically deployed, and monitoring begins, offering dynamic monitoring capabilities."
|
||||
|
||||
## Key Concepts
|
||||
- [[Operations Bridge Manager (OBM)]]:Micro Focus 云监控解决方案
|
||||
- [[Management Packs]]:OBM 管理包,定义监控策略和指标
|
||||
- [[Role-based Access]]:基于 IAM 角色的跨账户访问
|
||||
- [[CloudWatch API]]:AWS 监控数据接口
|
||||
|
||||
## Key Entities
|
||||
- [[Micro Focus]]:企业软件公司,OBM 产品提供商
|
||||
- [[AWS]]:公有云平台
|
||||
- [[CloudWatch]]:AWS 监控和可观测性服务
|
||||
|
||||
## Connections
|
||||
- [[Operations Bridge Manager (OBM)]] ← replaces ← [[Sitescope]]
|
||||
- [[Operations Bridge Manager (OBM)]] ← integrates_with ← [[CloudWatch]]
|
||||
- [[Operations Bridge Manager (OBM)]] ← uses ← [[IAM Role]]
|
||||
|
||||
## Architecture
|
||||
```
|
||||
Regional OBM (AWS Account)
|
||||
├── OBM Application
|
||||
├── Postgres RDS
|
||||
└── Operation Agent
|
||||
├── IAM Role (Cross-account access)
|
||||
├── Management Packs (AWS Mgmt Pack)
|
||||
└── CloudWatch API (Data Collection)
|
||||
↓
|
||||
On-premise Global OBM
|
||||
└── SMACKS Ticket (Event Escalation)
|
||||
```
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: How to Simplify Multi-Account Deployments Monitoring: Centralized Logs for AWS CloudFormation StackSets
|
||||
title: How to Simplify Multi-Account Deployments Monitoring:Centralized Logs for AWS CloudFormation StackSets
|
||||
type: source
|
||||
tags: [aws, cloudformation, stacksets, multi-account, centralized-logging, eventbridge, cloudwatch]
|
||||
date: 2025-10-25
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
title: "教學 ChatGPT 先做知識整理,再讓 Canva、 Gamma AI 輸出簡報"
|
||||
type: source
|
||||
tags: []
|
||||
tags: [AI简报, 工作流]
|
||||
date: 2025-10-26
|
||||
sources:
|
||||
- https://www.playpcesor.com/2025/10/chatgpt-canva-gamma-ai.html
|
||||
|
||||
@@ -0,0 +1,57 @@
|
||||
---
|
||||
title: "Learning Sessions Identity Governance VSM Replacement 20231128 160326 Meeting Recording"
|
||||
type: source
|
||||
tags:
|
||||
- Identity-Governance
|
||||
- VSM
|
||||
- CTP
|
||||
- IAM
|
||||
- IGA
|
||||
date: 2023-11-28
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/02_IAM/learning-sessions-identity-governance-vsm-replacement-20231128-160326-meeting-re.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题:Identity Governance(身份治理)以及用其替换 VSM(Virtual Service Manager)的计划
|
||||
- 问题域:IT 身份管理、访问控制、权限自动化
|
||||
- 方法/机制:使用 Micro Focus IGA(Identity Governance and Administration)通过工作流自动化访问审批和撤销
|
||||
- 结论/价值:实现内部和外部用户(包括合同工)的访问管理,支持时间限制访问,强化安全合规
|
||||
|
||||
## Key Claims
|
||||
- 身份治理框架用于高效管理数字身份、最大限度地降低风险并保持合规性
|
||||
- IGA 与 AWS Identity Center 集成,通过 IAM 提供资源访问
|
||||
- 计划用 IGA 替换所有账户的 VSM,采用相同架构但 IGA 连接到 Coptum 域
|
||||
- 访问请求通过审批流程,批准后自动授予访问权限
|
||||
|
||||
## Key Quotes
|
||||
> "Identity governance is a framework for managing digital identities efficiently, minimizing risk, and maintaining compliance." — 会议核心定义
|
||||
|
||||
> "Key questions addressed by identity governance: who currently has access to our systems, who should have access, and how is the access being done?" — 身份治理的核心问题
|
||||
|
||||
> "IG is used to provide access to both internal and external users, including contractors, with time-limited access." — IGA 的适用范围
|
||||
|
||||
## Key Concepts
|
||||
- [[Identity-Governance]]:管理数字身份、降低风险并保持合规的框架
|
||||
- [[VSM]]:Virtual Service Manager,DXC 工具,正在被 IGA 替换
|
||||
- [[IGA]]:Identity Governance and Administration,身份治理与管理解决方案
|
||||
- [[IGA-Portal]]:IGA 的用户门户,用于搜索资源、请求访问、填写表单
|
||||
- [[Active-Directory-Group]]:AD 组代表角色,IGA -governs 访问这些组
|
||||
- [[AWS-Identity-Center]]:AWS 身份中心,与 IGA 集成提供资源访问
|
||||
|
||||
## Key Entities
|
||||
- [[Micro-Focus]]:提供 IGA(Identity Governance and Administration)产品的公司
|
||||
- [[OpenText]]:举办本次 Learning Session 的公司
|
||||
- [[AWS-Identity-Center]]:AWS 身份认证和访问管理服务
|
||||
|
||||
## Connections
|
||||
- [[IGA]] ← provides_access ← [[AWS-Identity-Center]]
|
||||
- [[Active-Directory-Group]] ← governs ← [[IGA-Portal]]
|
||||
- [[VSM]] ← replaced_by → [[IGA]]
|
||||
|
||||
## Contradictions
|
||||
- 与 [[VSM]] 旧架构冲突:
|
||||
- 冲突点:VSM 使用旧的身份管理方式,IGA 提供更自动化的访问控制
|
||||
- 当前观点:通过 IGA 实现自动化工作流和审计
|
||||
- 对方观点:VSM 作为 DXC 传统工具仍被部分系统使用
|
||||
@@ -28,6 +28,8 @@ date: 2025-12-19
|
||||
- [[身份锁定 (Identity Locking)]]:通过参考图像保持特定人物或角色在生成新场景时面部特征不变的技术
|
||||
- [[思维模式 (Thinking Mode)]]:Nano-Banana Pro 默认生成中间思考图像(不收费)来优化构图后再渲染最终输出
|
||||
- [[Google Search Grounding]]:利用 Google 搜索实现实时数据可视化,减少时效性话题的幻觉
|
||||
- [[图像修补 (In-painting)]]:通过语义指令移除或添加对象,无需手动遮罩
|
||||
- [[维度转换]]:2D 与 3D 之间的相互转换,适用于室内设计、建筑、表情包创作
|
||||
|
||||
## Key Entities
|
||||
- [[Google]]:开发 Nano-Banana Pro 的公司
|
||||
@@ -37,6 +39,25 @@ date: 2025-12-19
|
||||
- [[Nano Banana Pro]] ← extends ← [[图像生成模型]]
|
||||
- [[Google AI Studio]] ← provides_interface ← [[Nano Banana Pro]]
|
||||
- [[提示语设计]] ← applies_to ← [[Nano Banana Pro]]
|
||||
- [[身份锁定 (Identity Locking)]] ← enables ← [[角色一致性]]
|
||||
|
||||
## Contradictions
|
||||
- (暂无冲突)
|
||||
- (暂无冲突)
|
||||
|
||||
## 10大核心能力
|
||||
1. **文本渲染与信息图表**:SOTA 级别的文本渲染能力,支持风格化文字和复杂信息可视化
|
||||
2. **角色一致性与病毒式缩略图**:支持14张参考图像,实现身份锁定
|
||||
3. **Google Search 锚定**:基于实时数据的图像生成,减少幻觉
|
||||
4. **高级编辑、修复与着色**:语义化指令进行图像处理
|
||||
5. **维度转换 (2D ↔ 3D)**:平面图转3D可视化或反之
|
||||
6. **高分辨率与纹理**:原生支持1K-4K分辨率输出
|
||||
7. **思考与推理**:通过中间思考图像优化构图
|
||||
8. **单次故事板与概念艺术**:生成连续艺术或故事板
|
||||
9. **结构控制与布局引导**:通过草图、线框图控制最终输出
|
||||
10. **后续发展**:UI 实验、App Gallery、AI Studio Build
|
||||
|
||||
## 4条黄金法则
|
||||
1. **编辑而非重新生成**:图像80%正确时不重新生成,通过对话修改
|
||||
2. **使用自然语言与完整句子**:像 briefing 人类艺术家一样描述
|
||||
3. **具体且具描述性**:定义主体、材质、纹理、环境、光线、情绪
|
||||
4. **提供上下文**:告诉模型"为什么"或"为谁"创作
|
||||
@@ -0,0 +1,55 @@
|
||||
---
|
||||
title: "Public Cloud Learning Sessions - AWS End User Compute Services - 20240430"
|
||||
type: source
|
||||
tags:
|
||||
- AWS
|
||||
- End-User-Computing
|
||||
- Workspaces
|
||||
- AppStream
|
||||
date: 2024-04-30
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/public-cloud-learning-sessions-aws-end-user-compute-services-20240430-160120-mee.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题:AWS 终端用户计算(EUC)服务介绍,涵盖虚拟桌面和应用流
|
||||
- 问题域:远程办公、混合工作模式下的终端用户计算解决方案
|
||||
- 方法/机制:AWS Workspaces(完全持久化虚拟桌面)、AppStream 2.0(非持久化应用流)、Workspace Core(通过 API 访问 VDI 基础设施)、Workspace Web(低成本安全浏览器)
|
||||
- 结论/价值:帮助组织根据用例选择合适的 AWS EUC 服务,平衡持久化需求、成本和安全要求
|
||||
|
||||
## Key Claims
|
||||
- AWS Workspaces 提供完全持久化虚拟桌面,用户数据和设置在会话之间保留
|
||||
- AppStream 2.0 提供非持久化桌面,适合实验室、培训和临时访问场景
|
||||
- Workspace Web 是访问内部网站和 SaaS 应用的低成本安全解决方案
|
||||
- 虚拟桌面选择应基于用户类型(知识工作者 vs 任务工作者)和使用场景
|
||||
|
||||
## Key Quotes
|
||||
- "With so many remote workers organizations are struggling to protect endpoints, as well as their IP and data from bad actors." — Christian O'Donough (AWS),阐述远程工作安全挑战
|
||||
- "AppStream 2.0 is a great low cost alternative for customers that don't require a fully persistent desktop." — AWS EUC 服务选型建议
|
||||
|
||||
## Key Concepts
|
||||
- [[VDI]]:Virtual Desktop Infrastructure,虚拟桌面基础设施,通过远程桌面协议提供虚拟计算环境
|
||||
- [[WSP-Protocol]]:Workspaces 流协议,专为高延迟网络设计
|
||||
- [[SAML]]:安全断言标记语言,用于单点登录和多因素认证
|
||||
- [[BYOD]]:Bring Your Own Device,自带设备,组织需要保护企业数据的同时允许个人设备访问
|
||||
- [[持久化桌面]]:每个用户独享虚拟机实例,应用状态和设置在会话间保持
|
||||
- [[非持久化桌面]]:每次登录分配新桌面,适合共享资源场景
|
||||
|
||||
## Key Entities
|
||||
- [[AWS]]:云服务提供商,提供 Workspaces 和 AppStream 2.0 等 EUC 服务
|
||||
- [[Christian-ODonough]]:AWS 演讲者,负责本次 EUC 服务介绍
|
||||
- [[OpenText]]:本次学习会议的主办方,Cloud Transformation Program 的一部分
|
||||
|
||||
## Connections
|
||||
- [[AWS]] ← provides ← [[AWS-Workspaces]]
|
||||
- [[AWS]] ← provides ← [[AppStream-2.0]]
|
||||
- [[AWS-Workspaces]] ← depends_on ← [[Active-Directory]]
|
||||
- [[AppStream-2.0]] ← uses ← [[SAML]]
|
||||
- [[VDI]] ← enables ← [[BYOD]]
|
||||
|
||||
## Contradictions
|
||||
- 与传统VDI解决方案(如VMware Horizon、Citrix)相比:
|
||||
- AWS Workspaces 是托管服务,无需管理底层基础设施
|
||||
- Workspace Core 允许使用第三方 VDI 解决方案,保留现有投资
|
||||
- 需要根据现有基础设施成熟度和运维能力进行选择
|
||||
@@ -0,0 +1,49 @@
|
||||
---
|
||||
title: "Public Cloud Learning Sessions - EKS Optimization Part 1 of 3 - Compute Optimization with Karpenter"
|
||||
type: source
|
||||
tags: [AWS, EKS, Karpenter, Cost-Optimization, Compute-Optimization]
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/public-cloud-learning-sessions-eks-optimization-part-1-of-3-compute-optimization.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题:EKS 计算优化,使用 Karpenter 实现自动扩缩容
|
||||
- 问题域:Kubernetes 集群资源管理、成本优化
|
||||
- 方法/机制:Karpenter 替代传统 Cluster Autoscaler,直接与 EC2 Fleet API 通信,基于成本和利用率进行工作负载放置和整合
|
||||
- 结论/价值:简化数据平面管理,降低节点管理复杂度,实现更优的成本效率
|
||||
|
||||
## Key Claims
|
||||
- Karpenter 与 Kubernetes workload scheduling constructs 原生集成
|
||||
- Karpenter 直接与 EC2 Fleet API 通信,降低延迟
|
||||
- Karpenter 提供工作负载放置和节点整合的原生体验
|
||||
- Karpenter 原生支持 Spot 中断处理,使用 EventBridge 和 SQS
|
||||
|
||||
## Key Quotes
|
||||
> "Carpenter not only does the auto-scaling bit, but it also removes the pain points of working with node groups."
|
||||
|
||||
> "Carpenter has native integration with Kubernetes and it complements the native Kubernetes spot pod scheduling constraints that is available for your workloads."
|
||||
|
||||
## Key Concepts
|
||||
- [[Karpenter]]:开源 Kubernetes compute management tool,替代 Cluster Autoscaler
|
||||
- [[Node-Pools]]:定义调度约束和容量限制
|
||||
- [[Node-Classes]]:定义实例配置细节(子网、节点角色、AMI)
|
||||
- [[Spot-Interruption]]:Spot 实例中断处理
|
||||
- [[Consolidation-Policies]]:整合策略,控制成本优化行为
|
||||
|
||||
## Key Entities
|
||||
- [[AWS]]:云服务提供商
|
||||
- [[EKS]]:Amazon Elastic Kubernetes Service
|
||||
- [[EC2-Fleet-API]]:AWS EC2 灵活计算实例 API
|
||||
- [[EventBridge]]:AWS 事件总线服务
|
||||
- [[SQS]]:AWS 简单队列服务
|
||||
|
||||
## Connections
|
||||
- [[Karpenter]] ← extends ← [[Cluster-Autoscaler]]
|
||||
- [[Karpenter]] ← integrates_with ← [[EC2-Fleet-API]]
|
||||
- [[Karpenter]] ← uses ← [[EventBridge]]
|
||||
- [[EKS]] ← manages ← [[Karpenter]]
|
||||
|
||||
## Contradictions
|
||||
- (暂无)
|
||||
@@ -0,0 +1,51 @@
|
||||
---
|
||||
title: "Public Cloud Learning Sessions - EKS Optimization part 2 of 3 - Running Containers with Bottlerocket OS"
|
||||
type: source
|
||||
tags: [AWS, EKS, Bottlerocket, OS, DevOps]
|
||||
date: 2026-04-19
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/public-cloud-learning-sessions-eks-optimization-part-2-of-3-running-containers-w.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题:Bottlerocket OS 运行容器化工作负载的优化
|
||||
- 问题域:EKS 容器运行时操作系统选择与配置
|
||||
- 方法/机制:Bottlerocket 最小化设计、安全更新机制、EKS 集成配置
|
||||
- 结论/价值:Bottlerocket 提供专为容器设计的精简、安全的操作系统,通过变体满足特定工作负载需求
|
||||
|
||||
## Key Claims
|
||||
- Bottlerocket 是专为托管容器而设计的 Linux 操作系统,仅包含必要组件,与通用操作系统不同
|
||||
- Bottlerocket 无包管理器、无默认 shell 解释器、无默认 SSH 访问,仅包含必要的内核组件
|
||||
- Bottlerocket 使用变体机制满足 GPU 等特定工作负载需求
|
||||
- 安全更新通过原地更新和节点替换实现,使用 dm-verity 验证根文件系统
|
||||
- 根文件系统默认不可变,/etc 是临时文件系统,SELinux 默认强制启用
|
||||
- Bottlerocket 集成 EKS,支持自托管节点组、托管节点组和 Carpenter 节点池
|
||||
|
||||
## Key Quotes
|
||||
> "Bottlerocket is a Linux-based operating system designed specifically for hosting containers, differing from general-purpose OSes by including only essential components."
|
||||
> "The root file system is by default immutable, you cannot change anything there."
|
||||
> "A variant is basically a combination of platform, supported platform, the processor architecture and the necessary binary components that are supported by the processor architecture and any additional packages and drivers that are required for your specific workloads."
|
||||
|
||||
## Key Concepts
|
||||
- [[Bottlerocket OS]]:专为容器设计的最小化 Linux 操作系统
|
||||
- [[EKS]]:Amazon Elastic Kubernetes Service,AWS 托管 Kubernetes 服务
|
||||
- [[Bottlerocket Variant]]:Bottlerocket 变体,满足特定工作负载需求的配置组合
|
||||
- [[dm-verity]]:内核子系统,用于验证根文件系统完整性
|
||||
- [[CIS Benchmark]]:互联网安全中心安全配置基准
|
||||
|
||||
## Key Entities
|
||||
- [[AWS]]:云计算服务提供商,Bottlerocket 核心维护者和赞助商
|
||||
- [[Bottlerocket]]:开源容器操作系统项目
|
||||
|
||||
## Connections
|
||||
- [[Bottlerocket OS]] ← supports ← [[EKS]]
|
||||
- [[Bottlerocket OS]] ← maintained_by ← [[AWS]]
|
||||
- [[Bottlerocket OS]] ← uses ← [[Bottlerocket Variant]]
|
||||
- [[Bottlerocket Variant]] ← provides ← [[GPU Support]]
|
||||
|
||||
## Contradictions
|
||||
- 与通用 Linux 发行版(如 Ubuntu、RHEL)对比:
|
||||
- 冲突点:通用 OS 提供完整功能集,Bottlerocket 仅提供最小化组件
|
||||
- 当前观点:Bottlerocket 更安全、更精简,适合容器化工作负载
|
||||
- 对方观点:通用 OS 更灵活,有更广泛的社区支持和工具链
|
||||
@@ -0,0 +1,54 @@
|
||||
---
|
||||
title: "Public Cloud Learning Sessions - EKS Optimization part 3 of 3 - Introduction to EKS Auto Mode - 20250304"
|
||||
type: source
|
||||
tags:
|
||||
- AWS
|
||||
- EKS
|
||||
- Auto-Mode
|
||||
- Cloud-Learning
|
||||
date: 2025-03-04
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/public-cloud-learning-sessions-eks-optimization-part-3-of-3-introduction-to-eks-.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题:EKS Auto Mode(EKS 自动模式)介绍,EKS 优化的第三部分
|
||||
- 问题域:Kubernetes 集群管理自动化,降低运维复杂度
|
||||
- 方法/机制:Carpenter 控制器管理基础设施、托管 EBS CSI 驱动、有状态工作负载支持、AWS 负载均衡器控制器
|
||||
- 结论/价值:EKS Auto Mode 将数据平面的管理职责扩展到 EKS 服务,自动管理实例、操作系统、补丁和安全更新,12% 溢价但大幅提升运维效率
|
||||
|
||||
## Key Claims
|
||||
- EKS Auto Mode 扩展了 EKS 服务的管理职责,从控制平面延伸到数据平面
|
||||
- Carpenter 是核心能力,负责基础设施管理(计算)
|
||||
- 默认包含两个节点池(general purpose 和 system)和一个节点类
|
||||
- 控制平面升级后,计算控制器会自动识别并跨集群滚动更新 AMI
|
||||
|
||||
## Key Quotes
|
||||
> "With Auto Mode, a majority of the operational concerns are being managed by the ECS service."
|
||||
— 核心运维工作由 EKS 服务自动管理
|
||||
|
||||
> "For every instance spun up in an Auto Mode cluster, there is a 12% premium charged for the automatic management of those instances."
|
||||
— 每个 Auto Mode 集群实例收取 12% 的溢价
|
||||
|
||||
## Key Concepts
|
||||
- [[EKS-Auto-Mode]]:AWS EKS 自动模式,自动管理数据平面实例、操作系统、补丁和安全更新
|
||||
- [[Carpenter]]:EKS Auto Mode 的计算控制器,负责基础设施管理和节点配置
|
||||
- [[BottleRocket]]:EKS Auto Mode 使用的操作系统,支持自动化补丁管理
|
||||
- [[Node-Pool]]:EKS Auto Mode 的节点池概念,默认包含 general purpose 和 system 两种
|
||||
- [[EBS-CSI-Driver]]:托管的 EBS 容器存储接口驱动,支持有状态工作负载
|
||||
|
||||
## Key Entities
|
||||
- [[AWS]]:全球最大公有云平台,EKS Auto Mode 的服务提供商
|
||||
- [[Kubernetes]]:CNCF 开发的开源容器编排平台
|
||||
- [[EKS]]:Amazon Elastic Kubernetes Service,AWS 托管 Kubernetes 服务
|
||||
|
||||
## Connections
|
||||
- [[AWS]] ← provides ← [[EKS]]
|
||||
- [[EKS]] ← manages ← [[EKS-Auto-Mode]]
|
||||
- [[EKS-Auto-Mode]] ← uses ← [[Carpenter]]
|
||||
- [[EKS-Auto-Mode]] ← includes ← [[EBS-CSI-Driver]]
|
||||
- [[EKS-Auto-Mode]] ← includes ← [[AWS-Load-Balancer-Controller]]
|
||||
|
||||
## Contradictions
|
||||
- (暂无)
|
||||
@@ -0,0 +1,62 @@
|
||||
---
|
||||
title: "Public Cloud Learning Sessions - Observability with OpenTelemetry - 20240402"
|
||||
type: source
|
||||
tags:
|
||||
- OpenTelemetry
|
||||
- Observability
|
||||
- AWS
|
||||
- EKS
|
||||
- DevOps
|
||||
date: 2024-04-02
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/public-cloud-learning-sessions-observability-with-opentelemetry-20240402-160113-.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题:OpenTelemetry 可观测性框架在 AWS 环境中的应用
|
||||
- 问题域:微服务架构下的系统可观测性挑战
|
||||
- 方法/机制:三大信号(Metrics、Logs、Traces)+ OpenTelemetry 统一采集方案 + AWS Distro for OpenTelemetry (ADOT)
|
||||
- 结论/价值:OpenTelemetry 提供厂商中立的端到端遥测数据采集标准,降低多供应商集成复杂度
|
||||
|
||||
## Key Claims
|
||||
- 可观测性是衡量从系统外部输出推断内部状态的能力 — Gartner 估计平均每年 87 小时停机时间,每小时损失 $42,000
|
||||
- OpenTelemetry 通过统一数据格式和 11 种语言 SDK 解决不同组件各自为政的 SDK 问题
|
||||
- AWS Distro for OpenTelemetry 是统一代理,支持自动检测应用语言并创建预配置的 Collector
|
||||
- OpenTelemetry Collector 通过 Receivers、Processors、Exporters、Extensions 四大组件实现数据标准化
|
||||
|
||||
## Key Quotes
|
||||
> "Observability is a measure of how well internal states of a system can be inferred from knowledge of its external outputs." — OpenText 学习会议定义
|
||||
|
||||
> "The output that Fluent Bit is sending the individual logs to is the OpenTelemetry endpoint on the port 55681." — Demo 演示说明
|
||||
|
||||
## Key Concepts
|
||||
- [[OpenTelemetry]]:厂商中立的遥测数据采集框架,提供统一数据格式和跨语言 SDK
|
||||
- [[OpenTelemetry-Collector]]:数据标准化组件,包含 Receivers、Processors、Exporters、Extensions
|
||||
- [[ADOT]]:AWS Distro for OpenTelemetry,统一代理自动检测应用语言并创建预配置 Collector
|
||||
- [[OTLP]]:OpenTelemetry Protocol,统一数据格式
|
||||
- [[Fluent-Bit]]:轻量级日志处理器,用于 EKS 环境日志收集和转发
|
||||
- [[Metrics]]:聚合的源统计数据,用于监控和告警
|
||||
- [[Logs]]:日志记录,用于问题根因分析
|
||||
- [[Traces]]:追踪,提供请求在系统中的完整视图
|
||||
- [[Trace-Span]]:追踪跨度,包含开始时间、持续时间和元数据
|
||||
- [[可观测性三大支柱]]:Metrics、Logs、Traces 及其关联关系
|
||||
|
||||
## Key Entities
|
||||
- [[AWS]]:云服务商,提供 CloudWatch、X-Ray、ADOT 等可观测性服务
|
||||
- [[Amazon-OpenSearch-Service]]:托管 OpenSearch 服务,用于存储和可视化日志、追踪数据
|
||||
- [[EKS]]:Amazon Elastic Kubernetes Service,演示应用的运行平台
|
||||
- [[Grafana]]:开源可视化平台,支持指标和日志展示
|
||||
- [[Prometheus]]:开源监控系统,用于指标采集
|
||||
- [[CloudWatch]]:AWS 原生监控服务
|
||||
- [[X-Ray]]:AWS 分布式追踪服务
|
||||
- [[Jay-Comer]]:AWS Solutions Architect,演讲者
|
||||
|
||||
## Connections
|
||||
- [[AWS]] ← provides ← [[ADOT]]
|
||||
- [[EKS]] ← hosts ← [[Fluent-Bit]] → forwards to → [[OpenTelemetry-Collector]]
|
||||
- [[OpenTelemetry-Collector]] → exports to → [[Amazon-OpenSearch-Service]]
|
||||
- [[Prometheus]] ← integrates with ← [[Grafana]]
|
||||
- [[Metrics]] ← part of ← [[可观测性三大支柱]]
|
||||
- [[Logs]] ← part of ← [[可观测性三大支柱]]
|
||||
- [[Traces]] ← part of ← [[可观测性三大支柱]]
|
||||
@@ -0,0 +1,56 @@
|
||||
---
|
||||
title: "Public Cloud Learning Sessions (OpenText) - GIS Security Policies"
|
||||
type: source
|
||||
tags:
|
||||
- OpenText
|
||||
- Security-Policies
|
||||
- GIS
|
||||
- Cloud-Learning
|
||||
date: 2024-10-15
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/07_Security/public-cloud-learning-sessions-opentext-gis-security-policies-20241015-160257-me.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题:OpenText 全球信息安全团队(GIS)的安全策略框架与组织结构
|
||||
- 问题域:企业级安全治理、合规管理、威胁检测与响应
|
||||
- 方法/机制:ISO 27001 框架、分层安全方法、第三方测试、红队演练、威胁情报
|
||||
- 结论/价值:构建以政策为基础的安全态势框架,通过多团队协作实现持续改进
|
||||
|
||||
## Key Claims
|
||||
- OpenText 采用分层安全方法,与多个团队协作定义"需要做什么",与其他团队确定"如何做"
|
||||
- 每月处理 2250 亿条日志,每月分类约 350 个案例
|
||||
- 安全态势框架基于 ISO 27001,2022 年更新增加了 11 个新控制方面
|
||||
- 年度第三方测试(包括桌面演练和红队演练)持续排名靠前
|
||||
|
||||
## Key Quotes
|
||||
> "Policies define what needs to be done, while providing flexibility for how it is implemented." — 政策定义目标,实现方式灵活
|
||||
|
||||
> "The focus is on how many people report suspicious activity." — 安全意识计划重点关注报告可疑活动的人数
|
||||
|
||||
## Key Concepts
|
||||
- [[ISO 27001]]:信息安全管理体系国际标准,OpenText 安全态势框架的基础
|
||||
- [[分层安全方法]]:与不同团队协作定义安全职责的分层方法
|
||||
- [[FedRAMP]]:联邦风险和授权管理计划,使 OpenText 能向政府和多个行业销售
|
||||
- [[红队演练]]:评估组织安全能力的无预先通知演练
|
||||
- [[威胁情报]]:整合 BrightCloud 等工具进行主动威胁检测
|
||||
|
||||
## Key Entities
|
||||
- [[OpenText]]:企业信息管理公司,GIS 组织的母公司
|
||||
- [[GIS (Global Information Security)]]:OpenText 的全球信息安全团队
|
||||
- [[Mike]]:GIS 团队成员,本次会议演讲者
|
||||
- [[Ed]]:GIS 团队成员,本次会议演讲者
|
||||
- [[BrightCloud]]:OpenText 自有威胁情报工具
|
||||
|
||||
## Connections
|
||||
- [[ISO 27001]] ← 框架基础 ← [[GIS 安全态势框架]]
|
||||
- [[安全运营团队]] ← 负责 ← [[网络响应中心、威胁情报、云安全]]
|
||||
- [[合规组织]] ← 负责 ← [[FedRAMP 认证、产品风险评估、持续合规]]
|
||||
- [[安全意识计划]] ← 降低风险 ← [[钓鱼测试]]
|
||||
|
||||
## Contradictions
|
||||
- 与 [[Modern ITSM]] 冲突:
|
||||
- 冲突点:ITSM 强调自动化和快速响应,GIS 强调人工审查和分层治理
|
||||
- 当前观点:安全运营需要人工审查和治理流程
|
||||
- 对方观点:ITSM 追求自动化优先
|
||||
Reference in New Issue
Block a user