amramer101/Strata-Ops

# Strata-Ops：终极 DevSecOps 演进之旅 [](https://opensource.org/licenses/MIT) [](https://github.com/amramer101/Strata-Ops) [](https://www.terraform.io/) [](https://kubernetes.io/) [](https://aws.amazon.com/) [](https://owasp.org/) [](https://github.com/features/actions) ## 📑 目录 1. [项目概述](#-project-overview) 2. [6 个阶段的演进之旅](#-the-journey-through-6-phases) 3. [项目路线图与演进](#-project-roadmap--evolution) 4. [阶段 1：本地基础](#-phase-1-local-foundation) 5. [阶段 2：AWS 平移](#-phase-2-aws-lift--shift) 6. [阶段 3：云原生 PaaS](#-phase-3-cloud-native-paas) 7. [阶段 4.1：容器化与 Ansible](#-phase-41-containerization--ansible) 8. [阶段 4.2：无服务器容器 (ECS Fargate)](#-phase-42-serverless-containers-ecs-fargate) 9. [阶段 5.1：自管理 Kubernetes](#-phase-51-self-managed-kubernetes-on-ec2) 10. [阶段 5.2：Helm 打包与模板化](#-phase-52-helm-packaging--templating) 11. [阶段 6.1：使用 GitOps 的生产级 EKS](#-phase-61-production-eks-with-gitops--oidc) 12. [性能与成本对比](#-performance--cost-comparison) 13. [最佳实践与经验总结](#-best-practices--lessons-learned) 14. [仓库结构](#-repository-structure) ## 🌍 项目概述 **Strata-Ops** 不仅仅是一个代码仓库——它是一段通过基础设施演进的六个递进阶段记录的**全面 DevOps 学习之旅**。 ### 这有什么不同？ - **教育基础**：每个阶段都自成一体，并建立在先前知识的基础之上 - **生产级就绪代码**：不是纯理论——而是实际可部署的基础设施 - **完整文档**：截图、图表和分步指南 - **安全第一**：全面集成 DevSecOps 实践 - **可复现**：Infrastructure as Code 实现 100% 的一致性 - **真实指标**：部署时间、成本分析和性能数据 ### 应用程序：VProfile（5 层 Java 应用） ``` ┌─────────────────────────────────────────────────┐ │ 🌐 Nginx (Web Tier) │ │ Reverse Proxy • Port 80 │ └──────────────────┬──────────────────────────────┘ │ ┌──────────────────▼──────────────────────────────┐ │ ☕ Tomcat (App Tier) │ │ Java Application Server • Port 8080 │ └──┬────────────┬──────────────┬──────────────────┘ │ │ │ ▼ ▼ ▼ ┌─────┐ ┌─────────┐ ┌──────┐ │MySQL│ │Memcached│ │RabbitMQ│ │ DB │ │ Cache │ │ Queue │ └─────┘ └─────────┘ └──────┘ ``` **服务：** - **Tomcat**：运行 VProfile 的 Java 应用服务器 - **MySQL**：关系型数据库（用户账号、配置信息） - **Memcached**：内存缓存层 - **RabbitMQ**：用于异步操作的消息代理 - **Nginx**：反向代理和前端网关 ## 🗺️ 6 个阶段的演进之旅 本项目采用**分层地质模型**构建，其中每个阶段都代表对基础设施工程更深层次的理解： ``` 🌍 Surface │ ┌─────▼─────┐ │ Phase 6 │ ← Production EKS with GitOps (CURRENT) ├───────────┤ │ Phase 5 │ ← Kubernetes Mastery ├───────────┤ │ Phase 4 │ ← Containerization & Orchestration ├───────────┤ │ Phase 3 │ ← Cloud-Native Services ├───────────┤ │ Phase 2 │ ← AWS Infrastructure ├───────────┤ │ Phase 1 │ ← Local Foundation └───────────┘ ``` 每个阶段都会增加复杂性，引入新技术，并建立在前一层理解的基础之上。 ## 📊 项目路线图与演进 这个仓库代表的不仅仅是代码迁移；它更是**工程思维**的演进： | 阶段 | 平台 | 部署策略 | 安全态势 | 可观测性 | 状态 | 耗时 | 核心学习点 | | :--- | :--- | :--- | :--- | :--- | :---: | :---: | :--- | | **1** | VirtualBox (本地) | 手动 SSH/SCP | 基础 SSH 密钥 | 日志文件 | ✅ | 45m | 基础知识 | | **2** | AWS EC2 (IaaS) | Jenkins Pipeline | 安全组 | Prometheus/Grafana | ✅ | 20m | Infrastructure as Code | | **3** | Elastic Beanstalk (PaaS) | AWS CodePipeline | WAF + Secrets Manager | CloudWatch | ✅ | 15m | 托管服务 | | **4.1** | Docker Compose | Ansible Playbooks | 容器 Lint | Docker Stats | ✅ | 12m | 容器化 | | **4.2** | AWS ECS Fargate | GitHub Actions | Trivy + Checkov | Datadog APM | ✅ | 8m | DevSecOps CI/CD | | **5.1** | 自管理 K8s | Kubeadm (手动) | 网络策略 | Metrics Server | ✅ | 25m | Kubernetes 内部机制 | | **5.2** | Kubernetes (Helm) | Helm Charts | RBAC + Secrets | Prometheus Stack | ✅ | 10m | Helm 模板化 | | **6.1** | **AWS EKS (生产)** | **GitOps (OIDC)** | **IRSA + 不可变标签** | **CloudWatch + X-Ray** | ✅ **运行中** | **3m** | **企业级生产** | ## 🏗️ 阶段 1：本地基础 **目标：** 建立基线本地环境，以了解 3 层架构组件。 ### 你将学到什么 - ✅ 多层应用架构原则 - ✅ 手动服务配置与开通 - ✅ 网络连接与防火墙规则 - ✅ 数据库初始化与 Schema 管理 - ✅ 所有未来自动化的基础 ### 关键亮点 - **基础设施：** 通过 Vagrant 和 VirtualBox 创建 3-5 台虚拟机（应用、数据库、负载均衡器、缓存、队列） - **挑战：** 手动管理版本兼容性（Java、Tomcat、MySQL） - **成果：** 一个可运行的本地应用，为云端迁移做好准备 - **设置时间：** 45-60 分钟 ### 🔗 资源 - **[📖 完整的阶段 1 文档 →](1-Local-Foundation/README.md)** - **手动设置：** [1.1-Local-Setup-Manual/README.md](1.1-Local-Setup-Manual/README.md) - **自动设置：** [1.2-Local-Setup-Automated-Vagrand/README.md](1.2-Local-Setup-Automated-Vagrand/README.md) ### 快速开始 ``` cd 1-Local-Foundation vagrant up # 然后手动配置每个服务 (参见 documentation) ``` ## ☁️ 阶段 2：AWS 平移 **目标：** 在自动化基础设施配置 的同时迁移至 AWS IaaS。 ### 你将学到什么 - ✅ Infrastructure as Code 基础 - ✅ AWS 网络（VPC、子网、安全组） - ✅ EC2 自动扩缩容与弹性负载均衡 - ✅ 托管数据库服务 - ✅ 使用 Jenkins 的 CI/CD - ✅ 使用 Prometheus 和 Grafana 的可观测性 ### 关键亮点 - **基础设施：** 由 Terraform 管理的 Auto Scaling Group 中的 EC2 实例 - **数据库：** 迁移至 Amazon RDS (MySQL) 以实现托管备份和高可用 (HA) - **CI/CD：** 用于自动化构建 WAR 包和部署的 Jenkins Pipeline - **可观测性：** 用于实时指标可视化的 Grafana 和 Prometheus - **部署时间：** 20 分钟（提升：55% ⬇️） ### 📸 架构图 ### 🔗 资源 - **[📖 完整的阶段 2 文档 →](2-AWS-Lift-And-Shift/README.md)** - **[Terraform 代码 →](2-AWS-Lift-And-Shift/terraform/)** - **[Jenkins 配置 →](2-AWS-Lift-And-Shift/jenkins/)** ### 快速开始 ``` cd 2-AWS-Lift-And-Shift terraform init terraform plan terraform apply ``` ## 🌩️ 阶段 3：云原生 PaaS **目标：** 通过利用 AWS 平台即服务 来降低运维开销。 ### 你将学到什么 - ✅ 托管应用平台 - ✅ 流水线自动化 - ✅ 安全服务（WAF、Secrets Manager） - ✅ 降低运维复杂性 - ✅ 基础设施抽象与扩缩容 ### 关键亮点 - **平台：** AWS Elastic Beanstalk 实现抽象化应用托管 - **CI/CD：** AWS CodePipeline 实现与源码控制的无缝集成 - **安全：** 集成 AWS WAF 和 Secrets Manager 以进行凭证管理 - **优势：** 焦点完全转移至代码开发而非服务器管理 - **部署时间：** 15 分钟（提升：67% ⬇️） ### 📸 架构图 ### 🔗 资源 - **[📖 完整的阶段 3 文档 →](3-Cloud-Native-PaaS/README.md)** - **[CloudFormation 模板 →](3-Cloud-Native-PaaS/cloudformation/)** ## 🐳 阶段 4.1：容器化与 Ansible **目标：** 使用 Docker 将应用与基础设施解耦，并确保环境一致性。 ### 你将学到什么 - ✅ Docker 基础与多阶段构建 - ✅ 容器网络与卷 - ✅ 用于本地编排的 Docker Compose - ✅ 使用 Ansible 进行基础设施配置 - ✅ 配置管理最佳实践 ### 关键亮点 - **技术：** 使用 Docker Compose 进行本地多容器编排 - **配置：** 使用 Ansible Playbooks 自动化服务器配置 - **优势：** 消除“在我的机器上能运行”的问题 - **部署时间：** 12 分钟 - **手动步骤：** 显著减少 ### 📸 架构图 ### 🔗 资源 - **[📖 完整的阶段 4.1 文档 →](4.1-Docker-Compose-Ansible/README.md)** - **[Dockerfile →](4.1-Docker-Compose-Ansible/Dockerfile)** - **[Docker Compose 文件 →](4.1-Docker-Compose-Ansible/docker-compose.yml)** - **[Ansible Playbooks →](4.1-Docker-Compose-Ansible/ansible/)** ## ⚡ 阶段 4.2：无服务器容器 (ECS Fargate) **目标：** 在无需管理服务器的情况下运行容器，并与现代 CI/CD 流水线集成。 ### 你将学到什么 - ✅ AWS ECS 和 Fargate 无服务器容器 - ✅ 容器注册中心 - ✅ 使用 GitHub Actions 的高级 CI/CD - ✅ DevSecOps 最佳实践（安全左移） - ✅ 容器安全扫描（Trivy、Checkov） - ✅ 分布式追踪 ### 关键亮点 - **平台：** AWS ECS Fargate（无服务器计算） - **CI/CD：** 集成安全扫描的 GitHub Actions（Trivy、Checkov） - **可观测性：** 集成 Datadog APM 实现分布式追踪 - **安全：** 容器 Lint 检查和漏洞扫描 - **部署时间：** 8 分钟（提升：60% ⬇️） - **手动步骤：** 端到端自动化 ### 📸 架构图 ### 🔗 资源 - **[📖 完整的阶段 4.2 文档 →](4.2-ECS-Fargate-GitHub-Actions/README.md)** - **[Terraform 代码 →](4.2-ECS-Fargate-GitHub-Actions/terraform/)** - **[GitHub Actions 工作流 →](.github/workflows/4.2-ECS-CICD.yml)** ## 🎮 阶段 5.1：EC2 上的自管理 Kubernetes **目标：** 通过从头构建集群来深入了解 Kubernetes 内部机制。 ### 你将学到什么 - ✅ Kubernetes 架构与组件 - ✅ 控制平面和工作节点设置 - ✅ CNI (Container Network Interface) 设置 - ✅ Etcd、kubelet 和 API server 配置 - ✅ 高可用与容灾 - ✅ 大规模生产环境故障排查 ### 关键亮点 - **实现：** 在 EC2 实例上使用 `kubeadm` 手动创建集群 - **网络：** Calico CNI 用于 Pod 网络，MetalLB 用于 LoadBalancer 服务 - **控制：** 手动管理控制平面、Etcd 和工作节点 - **核心学习点：** 理解升级、高可用 (HA) 和网络连接的复杂性 - **部署时间：** 25 分钟 - **复杂性：** 高（但对理解 K8s 极具价值） ### 📸 架构图 ### 🔗 资源 - **[📖 完整的阶段 5.1 文档 →](5.1-Self-Managed-Kubernetes-on-EC2/README.md)** - **[Terraform 代码 →](5.1-Self-Managed-Kubernetes-on-EC2/terraform/)** - **[Kubeadm 设置脚本 →](5.1-Self-Managed-Kubernetes-on-EC2/scripts/)** ## 📦 阶段 5.2：Helm 打包与模板化 **目标：** 使用包管理来标准化并简化复杂的 Kubernetes 部署。 ### 你将学到什么 - ✅ Helm v3 作为 Kubernetes 包管理器 - ✅ Chart 创建与模板化 - ✅ 跨环境的 Values 管理 - ✅ 依赖管理 - ✅ Release 版本控制与回滚 - ✅ Helm 最佳实践与模式 ### 关键亮点 - **：** Helm v3 作为 Kubernetes 包管理器 - **特性：** - 用于多环境的可复用模板 (Dev/Prod) - 数据库、缓存和消息队列的依赖管理 - 具有内建回滚能力的版本化发布 - **优势：** “一次编写，随处部署”的一致性与速度 - **部署时间：** 10 分钟 - **可复用性：** 跨环境达到 100% ### 📸 架构集成 *(Helm 集成到阶段 5.1 的架构中以管理应用生命周期)* ### 🔗 资源 - **[📖 完整的阶段 5.2 文档 →](5.2-Application-Packaging-and-Templating-with-Helm/README.md)** - **[Helm Chart →](5.2-Application-Packaging-and-Templating-with-Helm/eprofile-chart/)** ## 🚀 阶段 6.1：使用 GitOps 和 OIDC 的生产级 EKS **目标：** 终极生产就绪环境：安全、可扩展且完全自动化。 这个阶段代表了**项目的巅峰**，集成了企业级 Kubernetes 部署的全球最佳实践。 ### 🔑 核心特性 1. **✅ OIDC 认证：** 安全地将 GitHub Actions 连接到 AWS IAM，无需长期有效的密钥 2. **✅ IRSA (IAM Roles for Service Accounts)：** 为每个 Pod 提供精细化的最小权限 3. **✅ 多层安全：** Checkov (IaC)、Kube-score (Manifests)、Trivy (镜像) 4. **✅ 不可变标签：** 防止 ECR 中的镜像标签被覆盖以确保完整性 5. **✅ 高级 Ingress：** AWS Load Balancer Controller 用于自动预置 ALB 6. **✅ 密钥管理：** 通过 External Secrets Operator 将 AWS SSM 参数自动同步到 K8s Secrets ### 🏛️ 高级架构 从开发者到最终用户的完整流程，展示了 AWS 服务与 Kubernetes 组件的集成。 ### 🔐 OIDC 与 IAM 认证流程 GitHub Actions 如何在不存储密钥的情况下安全地代入 AWS IAM 角色。 ### 🛡️ 镜像安全：不可变标签 防止注册中心中的容器镜像被恶意覆盖。 ### 🏗️ 集群就绪状态 在部署前验证控制平面健康状态和节点组状态。 ### 🔄 CI/CD 流水线成功 3 阶段 GitHub Actions 流水线的成功执行。 ### 🕵️ 高级安全扫描 (SARIF) 将安全发现直接集成到 GitHub Security 选项卡中。 ### 🚦 Ingress 与流量路由 K8s Controller 自动预置 Application Load Balancer。 ### 🌐 应用在 EKS 上运行上线 关键时刻：通过公共互联网访问应用程序。 ### 🔑 登录验证 测试认证流程与数据库连接。 ### ⚡ 缓存层性能 验证用于会话和数据缓存的 Memcached 集成。 ### 💾 数据一致性检查 确保应用全栈的端到端数据完整性。 ### 📊 阶段 6.1 指标 | 指标 | 值 | |--------|-------| | **EKS 版本** | 1.29 | | **节点组大小** | 2-4 个节点 (自动扩缩容) | | **流水线任务** | 3 (安全 → 构建 → 部署) | | **安全扫描器** | 3 (Checkov、Kube-score、Trivy) | | **部署时间** | ~3 分钟 (端到端) | | **手动步骤** | 0 (完全 GitOps) | | **硬编码凭证** | 0 (基于 OIDC) | | **部署的容器** | 5 (应用、数据库、缓存、队列、Web) | ### 🔗 资源 - **[📖 完整的阶段 6.1 文档与命令 →](6.1-EKS-Provisioning-with-Push-Based-CICD/README.md)** - **[Terraform 配置 →](6.1-EKS-Provisioning-with-Push-Based-CICD/terraform/)** - **[Helm Chart →](6.1-EKS-Provisioning-with-Push-Based-CICD/eprofile-chart/)** - **[GitHub Actions 工作流 →](.github/workflows/6.1-EKS-CICD.yml)** ### 快速开始 ``` cd 6.1-EKS-Provisioning-with-Push-Based-CICD # 1. 配置 EKS cluster terraform init terraform plan terraform apply # 2. 配置 kubectl aws eks update-kubeconfig --name strata-eks-cluster --region eu-central-1 # 3. 通过 Helm 部署 application helm upgrade --install vproapp ./eprofile-chart --wait # 4. 验证 deployment kubectl get pods kubectl get ingress ``` ## 📈 性能与成本对比 各阶段的关键指标是如何演变的？ ### ⏱️ 部署时间演进 | 阶段 | 部署时间 | 提升 | 关键因素 | | :--- | :--- | :--- | :--- | | **阶段 1** (本地手动) | 45-60 分钟 | - | 全手动 | | **阶段 2** (Jenkins EC2) | ~20 分钟 | 55% ⬇️ | 基础设施自动化 | | **阶段 3** (CodePipeline) | ~15 分钟 | 67% ⬇️ | 托管服务 | | **阶段 4.1** (Docker Compose) | ~12 分钟 | 73% ⬇️ | 容器化 | | **阶段 4.2** (ECS Fargate) | ~8 分钟 | 82% ⬇️ | 无服务器计算 | | **阶段 5.1** (自管理 K8s) | ~25 分钟 | 高复杂性 | 学习开销 | | **阶段 5.2** (Helm) | ~10 分钟 | 78% ⬇️ | 基于模板 | | **阶段 6.1** (EKS GitOps) | **~3 分钟** | **93% ⬇️** | **完全自动化 + 推送** | ### 🔒 手动步骤减少 | 阶段 | 手动步骤 | 自动化级别 | 依赖 | | :--- | :--- | :--- | :--- | | 阶段 1 | 15+ 步 | 完全手动 | 0% | | 阶段 2 | 8 步 | 半自动化 | 40% | | 阶段 3 | 5 步 | 大部分自动化 | 70% | | 阶段 4.1 | 6 步 | Docker 驱动 | 60% | | 阶段 4.2 | 2 步 | CI/CD 驱动 | 95% | | 阶段 5.1 | 8 步 | 复杂手动 | 50% | | 阶段 5.2 | 2 步 | Helm 模板化 | 90% | | **阶段 6.1** | **0 步** | **完全 GitOps** | **100%** | ### 💰 预估每月成本 (开发环境) *基于 `eu-central-1` 区域的成本估算。* | 阶段 | 每月成本 | 组件 | 备注 | | :--- | :--- | :--- | :--- | | 阶段 1 | $0 | 本地资源 | 仅用于开发 | | 阶段 2 | ~$60/月 | EC2 (固定) | 持续运行 | | 阶段 3 | ~$45/月 | Elastic Beanstalk | 托管，成本依然较高 | | 阶段 4.1 | $0 | 本地 Docker | 仅用于开发 | | 阶段 4.2 | ~$35/月 | Fargate + ECR | 按需付费 | | 阶段 5.1 | ~$50/月 | EC2 节点 | 仍存在手动运维开销 | | 阶段 5.2 | ~$50/月 | EC2 节点 | 无成本缩减 | | **阶段 6.1** | **~$75/月** | **EKS ($72 + 节点)** | **生产级，扩展性更好** | **成本分析：** - ✅ EKS 成本较高，但包含托管控制平面 ($72)、CloudWatch 日志和自动扩缩容能力 - ✅ 由于高可用 (HA)、安全特性 (IRSA、OIDC) 和多可用区分布，更适合生产环境 - ✅ Fargate 对于简单工作负载最具成本效益，但缺乏 Kubernetes 可移植性 - ✅ 自管理 K8s 需要大量运维开销（未体现在计算成本中） ## 🛡️ 最佳实践与经验总结 ### 1. Infrastructure as Code (IaC) ✅ **状态锁定：** 始终使用 Terraform 状态锁定（例如通过 S3 + DynamoDB）以防止并发修改冲突。 ``` terraform { backend "s3" { bucket = "strata-ops-terraform-state" key = "prod/terraform.tfstate" region = "eu-central-1" encrypt = true dynamodb_table = "terraform-locks" } } ``` ✅ **模块化：** 将代码分解为可复用的模块（Network、DB、App、K8s）以提高可维护性。 ``` terraform/ ├── modules/ │ ├── networking/ │ ├── eks/ │ ├── ecr/ │ └── rds/ └── main.tf ``` ### 2. 安全 ✅ **安全左移：** 尽早扫描漏洞： - **Checkov** (IaC 扫描) — 在基础设施创建之前检测错误配置 - **Kube-score** (K8s manifests) — 验证 YAML 中的安全最佳实践 - **Trivy** (容器镜像) — 在推送到注册中心之前扫描 CVE 漏洞 ✅ **最小权限：** 在 EKS 中使用 IRSA (IAM Roles for Service Accounts) 仅向特定 Pod 授予权限，而不是整个节点。 ``` apiVersion: v1 kind: ServiceAccount metadata: name: vproapp annotations: eks.amazonaws.com/role-arn: arn:aws:iam::ACCOUNT_ID:role/vproapp-role ``` ✅ **禁止硬编码密钥：** 永远不要提交密钥。请使用： - 搭配 External Secrets Operator 的 **AWS Secrets Manager** - 搭配自动 K8s Secret 同步的 **AWS Parameter Store** - 用于 CI/CD 凭证的 **GitHub Secrets**（静态加密） ### 3. Kubernetes 编排 ✅ **托管 > 自管理：** 生产环境请使用 EKS，以避免管理控制平面的繁重负担。 | 方面 | 自管理 (阶段 5.1) | EKS (阶段 6.1) | |--------|----------------------|-----------------| | 控制平面 | 由你管理 | 由 AWS 管理 | | 更新 | 手动，风险高 | 自动化，滚动更新 | | 高可用 | 设置复杂 | 内置 | | 成本 | 运维开销较高 | 计算成本较高 | | 学习价值 | 极其宝贵 | 生产就绪 | ✅ **Helm 是必需的：** 在生产环境中避免使用原生的 `kubectl apply`。请使用 Helm 以实现： - 版本控制与发布管理 - 内置的回滚能力 - 特定环境的 Values (dev/prod) - 依赖管理 ✅ **资源限制：** 始终为 CPU/RAM 定义 `requests` 和 `limits` 以防止资源匮乏。 ``` resources: requests: cpu: "100m" memory: "128Mi" limits: cpu: "500m" memory: "512Mi" ``` ### 4. CI/CD 工程 ✅ **临时运行器：** 相比持久化的 Jenkins 服务器，更倾向于使用 GitHub Actions 运行器，因为： - 更好的安全性（没有长期存在的基础设施） - 更低的成本（按执行次数付费） - 更容易维护（无需管理虚拟机） ✅ **不可变构件：** 永远不要重新构建相同的标签。请使用： - 用于完全可追溯性的 Git SHA 标签 - 用于发布的语义化版本控制 - ECR 中的不可变标签以防止被覆盖 ``` - name: Push to ECR run: | docker tag vproapp:${{ github.sha }} $ECR_REGISTRY/$ECR_REPOSITORY:${{ github.sha }} docker push $ECR_REGISTRY/$ECR_REPOSITORY:${{ github.sha }} ``` ✅ **密钥轮换：** 使用 OIDC 获取临时凭证，而不是使用长期有效的密钥。 ### 5. 可观测性与监控 ✅ **多层可观测性：** - **指标**：Prometheus/CloudWatch 用于基础设施和应用健康状态 - **日志**：集中式日志记录 (CloudWatch Logs、ELK、Datadog) - **追踪**：分布式追踪 (X-Ray、Jaeger) 用于请求流 - **告警**：使用 SNS/PagerDuty 进行自动化告警 ✅ **需要监控的关键指标：** - Pod 重启次数（稳定性指标） - 节点资源利用率（扩缩容触发器） - 应用错误率（健康指标） - 部署成功率（流水线健康度） ### 6. 成本优化 ✅ **合理调整规模：** - 采用 Compute Optimizer 的建议 - 监控实际使用与请求资源的对比 - 在非工作时间缩减规模 ✅ **Spot 实例：** 为非关键工作负载使用 AWS Spot 实例（最高可节省 70%）。 ✅ **预留实例：** 为可预测的生产工作负载购买预留实例。 ## 📂 仓库结构 ``` Strata-Ops/ │ ├── README.md # 📍 Master Documentation (This File) │ ├── 1-Local-Foundation/ # Phase 1: VirtualBox & Vagrant Setup │ ├── 1.1-Local-Setup-Manual/ │ │ ├── README.md │ │ └── Vagrantfile │ │ │ └── 1.2-Local-Setup-Automated-Vagrand/ │ ├── README.md │ ├── Vagrantfile │ ├── mysql.sh │ ├── memcache.sh │ ├── rabbitmq.sh │ ├── tomcat_ubuntu.sh │ └── nginx.sh │ ├── 2-AWS-Lift-And-Shift/ # Phase 2: EC2, Jenkins, Terraform │ ├── README.md │ ├── terraform/ │ │ ├── main.tf │ │ ├── vpc.tf │ │ ├── security_groups.tf │ │ ├── asg.tf │ │ ├── rds.tf │ │ └── variables.tf │ └── jenkins/ │ └── Jenkinsfile │ ├── 3-Cloud-Native-PaaS/ # Phase 3: Elastic Beanstalk, CodePipeline │ ├── README.md │ ├── cloudformation/ │ │ └── beanstalk-template.yaml │ └── buildspec.yml │ ├── 4.1-Docker-Compose-Ansible/ # Phase 4.1: Containerization & Ansible │ ├── README.md │ ├── Dockerfile │ ├── docker-compose.yml │ ├── ansible/ │ │ ├── playbook.yml │ │ └── roles/ │ └── .dockerignore │ ├── 4.2-ECS-Fargate-GitHub-Actions/ # Phase 4.2: Serverless Containers │ ├── README.md │ ├── terraform/ │ │ ├── ecs.tf │ │ ├── ecr.tf │ │ ├── alb.tf │ │ └── variables.tf │ └── .github/workflows/ │ └── 4.2-ECS-CICD.yml │ ├── 5.1-Self-Managed-Kubernetes-on-EC2/ # Phase 5.1: Deep Dive K8s │ ├── README.md │ ├── terraform/ │ │ ├── main.tf │ │ ├── security_groups.tf │ │ └── variables.tf │ ├── scripts/ │ │ ├── master-setup.sh │ │ ├── worker-setup.sh │ │ └── network-setup.sh │ └── manifests/ │ └── application.yaml │ ├── 5.2-Application-Packaging-and-Templating-with-Helm/ # Phase 5.2: Helm Charts │ ├── README.md │ └── eprofile-chart/ │ ├── Chart.yaml │ ├── values.yaml │ ├── values-prod.yaml │ └── templates/ │ ├── deployment.yaml │ ├── service.yaml │ ├── ingress.yaml │ ├── configmap.yaml │ └── _helpers.tpl │ ├── 6.1-EKS-Provisioning-with-Push-Based-CICD/ # Phase 6.1: Production EKS │ ├── README.md │ ├── terraform/ │ │ ├── main.tf │ │ ├── eks.tf │ │ ├── iam.tf │ │ ├── ecr.tf │ │ ├── alb.tf │ │ ├── oidc.tf │ │ └── variables.tf │ ├── eprofile-chart/ │ │ ├── Chart.yaml │ │ ├── values.yaml │ │ └── templates/ │ │ ├── deployment.yaml │ │ ├── service.yaml │ │ ├── ingress.yaml │ │ ├── configmap.yaml │ │ ├── serviceaccount.yaml │ │ └── _helpers.tpl │ └── scripts/ │ ├── setup-oidc.sh │ └── deploy.sh │ ├── .github/ │ └── workflows/ │ ├── 4.2-ECS-CICD.yml │ └── 6.1-EKS-CICD.yml │ ├── media/ # 🖼️ Architecture Diagrams & Screenshots │ ├── Lift-shift/ │ │ ├── local-arch.png │ │ └── lift-shift-arch.png │ ├── cloud-native/ │ │ └── cloud-native-arch.png │ ├── Docker-compose/ │ │ └── docker-compose-arch.png │ ├── Docker-ECS/ │ │ └── End-to-End_DevSecOps_CICD_Pipeline.png │ ├── k8s/ │ │ └── strata_ops_k8s_architecture.png │ └── EKS/ │ ├── strata_ops_architecture.png │ ├── aws-alb-provisioned.png │ ├── aws-ecr-immutable-image-tags.jpg.png │ ├── aws-eks-cluster-ready.png │ ├── github-actions-pipeline-success.png │ ├── github-advanced-security-sarif.png │ ├── kubectl-pods-ingress-status.png │ ├── vprofile-app-live-on-eks.png │ ├── login-vprofile-app-live-on-eks.png │ ├── cache-vprofile-app-live-on-eks.png │ └── data-from-cache-vprofile-app-live-on-eks.png │ └── .gitignore # Version control exclusions ``` ## 🎓 这展示了什么 ### **基础设施工程** - 从手动到完全自动化配置的演进过程 - 具有网络隔离的多层 VPC 设计 - 托管与自托管方案的权衡分析 - 采用 ECS Fargate 的无服务器计算 - 企业级规模的托管 Kubernetes (EKS) - 使用 Terraform 的 Infrastructure as Code (100% 可复现) ### **DevSecOps** - 在每次构建前通过漏洞扫描实现安全左移 - 在所有阶段使用 AWS Secrets Manager 实现零硬编码凭证 - 与 GitHub Advanced Security 仪表板集成的 SARIF - 多层扫描：IaC (Checkov)、Manifests (Kube-score)、镜像 - 基于 OIDC 的认证（临时的、轮换的） - 用于供应链安全的不可变容器镜像标签 ### **CI/CD 工程** - 搭配 JCasC 的 Jenkins（整个状态纳入版本控制） - 带有质量门以阻止劣质代码的 AWS CodePipeline - 搭配运行时 SSM 参数获取的 GitHub Actions - 流水线拥有的密钥（绝不出现在代码中） - 具备自动回滚的多阶段部署 - 上线前的健康检查与冒烟测试 ### **可观测性** - 用于基础设施指标的 Prometheus + Grafana - 用于托管平台告警的 CloudWatch + SNS - 搭配 APM 追踪 + JVM 指标 + 日志路由的 Datadog 全栈监控 - 应用级指标（响应时间、错误率、吞吐量） - 基础设施级指标（CPU、内存、磁盘、网络） - 跨所有微服务的分布式追踪 ### **容器工程** - 用于优化镜像的多阶段 Docker 构建 - 具备健康感知的容器依赖链 - 用于注入可观测性的 Sidecar 模式 - 用于容器间 APM 通信的共享 unix socket 卷 - 容器注册中心最佳实践（不可变标签、扫描） - 网络策略与服务网格基础 ## 📖 入门指南 ### DevOps 新手？ 从 **阶段 1** → **阶段 2** → **阶段 3** 开始，以建立基础理解。 ### 对 Kubernetes 感兴趣？ 走 **阶段 4.1** → **阶段 5.1** → **阶段 5.2** → **阶段 6.1** 以完成 K8s 的进阶。 ### 想要生产就绪？ 直接跳到 **阶段 6.1**（但请先理解基础）。 ### 容器优先方案？ 从 **阶段 4.1** → **阶段 4.2** → **阶段 6.1** 开始（跳过传统基础设施）。 ## 🤝 贡献 本项目开放以下形式的贡献： - 🐛 Bug 报告与修复 - 📝 文档改进 - 🎨 架构图更新 - 🔍 安全增强 - ✨ 额外阶段的实现（6.2: ArgoCD，阶段 7: 多云） ## 📝 许可证 本项目基于 **MIT 许可证** 授权 - 详情请参阅 [LICENSE](LICENSE) 文件。

标签：Ansible, AWS, DevOps演进, DevSecOps, Docker, DPI, EC2, ECR, ECS, ECS, EKS, EKS最佳实践, Fargate, GitHub Actions, GitOps, Helm, IaC, Java应用, NIDS, OIDC, PaaS, RDS, Shift-Left安全, Terraform, Terraform, Vagrant, 上游代理, 云成本优化, 云迁移, 五层架构, 子域名突变, 安全左移, 安全防御评估, 容器化, 无服务器容器, 本地开发环境, 生产级Kubernetes, 生成式AI安全, 系统提示词, 自动化运维, 自动笔记, 自定义请求头, 虚拟机, 请求拦截, 迁移上云, 配置修复