LordSesay/incident-response-platform-eks

# incident-response-platform-eks ## 概览 incident-response-platform-eks 是一个云原生内部运维平台，旨在标准化告警接入、分类事件严重性，并通过 API 和仪表板向响应者暴露事件数据。 该项目展示了如何将多服务平台部署到 Amazon EKS，使用 GitHub Actions 进行 CI/CD、Terraform 进行基础设施供应、Docker 进行容器化，以及使用 CloudWatch / Prometheus 进行可观测性。 这不是一个通用的 Web 应用部署演示。 它是一个组合项目，旨在模拟平台与 DevOps 工程师如何在企业规模下支持内部工程运维。 ## 问题陈述 工程团队经常从多个系统接收告警，例如基础设施监控、应用日志和外部集成。在许多环境中，这些告警不一致、噪声大且难以快速归类。 常见的运维问题包括： - 由大量非结构化事件导致的告警疲劳 - 团队之间事件严重性分类不一致 - 因工具碎片化导致的响应延迟 - 缺乏对活跃事件的集中可见性 - 增加运维风险的 manual 部署工作流 该项目的目标是创建一个内部平台，集中接收告警、分类事件严重性、存储标准化事件记录，并在 Kubernetes 上提供一致的部署与可观测性模型。 ## 解决方案 该平台包含： - **告警摄入 API**：接收传入的事件或告警负载 - **分类服务**：规范化告警并分配严重性与归属 - **事件 API**：检索与管理事件记录 - **运营仪表板**：可视化活跃事件与平台健康状态 - **Amazon EKS**：Kubernetes 编排 - **Terraform**：基础设施即代码 - **GitHub Actions**：自动化构建、测试、推送与部署工作流 - **Amazon ECR**：容器镜像存储 - **CloudWatch 与 Prometheus**：日志与指标 ## 架构 ``` Developer Push | v GitHub Repository | v GitHub Actions CI/CD - test services - build Docker images - push images to ECR - deploy manifests to EKS | v Amazon EKS Cluster - ingestion-api - classifier-service - incident-api - dashboard | v DynamoDB / Incident Store | v CloudWatch + Prometheus + Grafana ``` ## 为何选择 EKS 在本项目中使用 Kubernetes 是合理的，因为该平台由多个具有不同运行时行为的独立可部署服务组成。 EKS 提供： - 用于更安全发布的滚动部署 - 内部服务之间的服务发现 - 针对摄入密集型工作负载的水平扩展 - 通过健康探针与 Pod 重启实现自愈 - 一个用于可观测性、RBAC 与工作负载隔离的真实平台 这使得该项目与更简单的 ECS 应用部署有实质区别。 ## 核心服务 ### 1. ingestion-api 通过 REST 端点接收传入告警。 示例职责： - 验证负载 - 分配请求 ID - 发布或持久化原始告警数据 - 转发规范化记录以进行分类 ### 2. classifier-service 应用事件分类规则。 示例职责： - 严重性映射 - 事件优先级分配 - 团队归属标签 - 状态初始化 ### 3. incident-api 向用户与内部工具暴露事件数据。 示例端点： - `GET /incidents` - `GET /incidents/{id}` - `PATCH /incidents/{id}` ### 4. dashboard 内部界面，供响应者查看事件、状态与指标。 ## 仓库结构 ``` incident-response-platform-eks/ ├── .github/ │ └── workflows/ │ ├── ci.yml │ └── deploy.yml ├── application/ │ ├── ingestion-api/ │ │ ├── src/ │ │ ├── tests/ │ │ ├── Dockerfile │ │ └── requirements.txt │ ├── classifier-service/ │ │ ├── src/ │ │ ├── tests/ │ │ ├── Dockerfile │ │ └── requirements.txt │ ├── incident-api/ │ │ ├── src/ │ │ ├── tests/ │ │ ├── Dockerfile │ │ └── requirements.txt │ ├── dashboard/ │ │ ├── src/ │ │ ├── Dockerfile │ │ └── package.json │ └── k8s/ │ ├── namespace.yaml │ ├── ingestion-api.yaml │ ├── classifier-service.yaml │ ├── incident-api.yaml │ ├── dashboard.yaml │ ├── configmap.yaml │ ├── secrets.yaml │ └── ingress.yaml ├── infrastructure/ │ ├── modules/ │ │ ├── vpc/ │ │ ├── eks/ │ │ ├── ecr/ │ │ ├── iam/ │ │ └── monitoring/ │ ├── environments/ │ │ ├── dev/ │ │ └── prod/ │ └── main.tf ├── docs/ │ ├── architecture.md │ ├── diagrams/ │ ├── runbooks/ │ ├── screenshots/ │ └── learning-notes.md ├── scripts/ │ ├── bootstrap.sh │ ├── deploy.sh │ └── smoke-test.sh ├── README.md └── QUICKSTART.md ``` ## CI/CD 工作流 部署流水线由 GitHub Actions 提供支持。 高层工作流： 1. 开发者将代码推送到 GitHub 2. 工作流运行变更服务的测试 3. 构建并标记 Docker 镜像 4. 镜像推送到 Amazon ECR 5. 更新或应用 Kubernetes 清单 6. 将工作负载部署到 Amazon EKS 7. 运行冒烟测试以验证部署成功 该流水线移除了手动部署步骤，并创建了可重复的发布流程。 ## 基础设施 Terraform 配置运行该平台所需的 AWS 环境，包括： - VPC 与网络 - EKS 集群与节点组 - ECR 仓库 - IAM 角色与策略 - 安全组 - 监控组件 - 可选的 DNS / 入口支持 ## 可观测性 平台在基础设施和工作负载层均提供可观测性。 **日志** - 使用 CloudWatch 集中存储应用与基础设施日志 **指标** - 使用 Prometheus 采集 Kubernetes 与服务指标 - 使用 Grafana 仪表板进行可视化 **健康验证** - 存活探针与就绪探针 - 部署滚动检查 - 部署后的冒烟测试 ## 安全性 本项目中演示的安全控制包括： - AWS 资源的 IAM 最小权限 - Kubernetes RBAC - 命名空间隔离 - 服务配置的秘密处理 - 容器化工作负载与受控部署路径 - 镜像扫描与策略强制执行（可选） ## 本地开发 ### 先决条件 - 已配置 AWS CLI - Terraform >= 1.0 - kubectl - Docker - Python 3.11+ - 为 CI/CD 配置好的 GitHub 仓库密钥 ### 克隆仓库 ``` git clone https://github.com/LordSesay/incident-response-platform-eks.git cd incident-response-platform-eks ``` ### 配置基础设施 ``` cd infrastructure terraform init terraform plan terraform apply ``` ### 配置 kubectl ``` aws eks update-kubeconfig --region us-east-1 --name incident-response-eks ``` ### 部署工作负载 ``` kubectl apply -f application/k8s/ ``` ## 实际执行目标 本项目旨在展示真实的平台工程经验，包括： - 设计多服务容器化系统 - 使用 Terraform 供应可重复的 AWS 基础设施 - 使用 GitHub Actions 自动化部署 - 在 Kubernetes 上部署与运维工作负载 - 实现监控、日志与部署验证 - 记录运维经验教训 ## 预期解决的挑战 随着项目演进，关键工程挑战将包括： - GitHub Actions 到 AWS 的身份验证 - ECR 镜像版本化与部署可追溯性 - Kubernetes 中服务到服务的通信 - 就绪探针与存活探针的调优 - Terraform 依赖管理 - 负载下的扩展与滚动行为 - 跨服务的可观测性与调试 随着构建推进，本节将更新实际的故障排查记录。 ## 未来增强 可能的未来改进包括： - Helm chart 打包 - 使用 ArgoCD 进行 GitOps 交付 - 事件通知集成 - 基于 SQS 或 SNS 的事件流 - 仪表板用户认证 - 高级路由与入口控制 - 多环境推广策略 ## 作者 **LordSesay**

标签：Amazon EC2, API服务, AWS, CloudWatch, Docker, DPI, ECS, EKS, GitHub Actions, Terraform, 严重性分级, 中央可见性, 事件响应平台, 事件数据存储, 仪表盘可视化, 企业级运维, 内部运营平台, 告警分类, 告警摄入, 告警疲劳, 安全防御评估, 平台工程, 标准化流程, 模拟企业场景, 特权提升, 碎片化工具, 自动化部署, 自动笔记, 自定义请求头, 观测性, 请求拦截, 运营支持, 逆向工具, 集中化告警