Unified platform operations gu…

# 阿里云ACK GitLab CI/CD流水线方案

一、总体架构

• 代码托管与流水线：GitLab（自建或极狐SaaS）+ GitLab Runner（部署在ACK集群内，使用Kubernetes Executor）
• 制品管理：GitLab Container Registry 或阿里云容器镜像服务ACR（推荐企业版，支持安全扫描）
• 部署目标：ACK集群，12个微服务共用一套流水线模板，通过变量差异化

二、流水线阶段设计

1. 代码检查与构建

• 阶段：lint → 单元测试 → 构建镜像 → 安全扫描
• 触发规则：master分支推送或打tag触发
• 镜像tag建议使用：分支名-commit短SHA-构建号，避免用latest
• 测试覆盖率低于阈值则流水线失败

2. 部署测试环境

• 自动部署到 dev/staging 命名空间
• 集成测试通过后方可进入生产流程（手动审批：when: manual）

三、灰度发布方案

推荐方案：服务网格Istio（MSE或开源）或 Nginx Ingress 注解

• 无Istio场景：基于ACK的Nginx Ingress，通过canary注解实现按Header/Cookie/权重分流
• Deployment策略：新增灰度Deployment（如 svc-v2-canary），按比例（5% → 20% → 50% → 100%）逐步放量

灰度流程

1. 部署灰度版本，初始流量5%

2. 自动观察10-15分钟：检查错误率、P99延迟（调用Prometheus API判断）

3. 指标达标 → 自动放量下一档；不达标 → 触发回滚

4. 全量后删除旧版本Deployment

四、自动化回滚机制

触发条件

• 部署后健康检查失败（Readiness Probe持续异常）
• Prometheus告警：错误率突增（如5xx比例超过阈值）、延迟超基线
• kubectl rollout status 超时

实现方式

• 流水线中 after_script 或独立 rollback stage，检测到异常执行 kubectl rollout undo deployment/xxx
• 保留每次部署的版本记录（GitLab Environment功能，支持一键回滚到历史版本）
• 回滚动作同步推送钉钉/企业微信通知

五、工程实践要点

• 配置管理：使用Helm Chart统一管理12个服务，values按服务拆分
• 权限控制：生产环境部署需GitLab Protected Branch + 手动审批
• 密钥管理：使用阿里云KMS或Sealed Secrets，禁止明文入仓
• 可观测性：对接ARMS/Prometheus + Grafana，部署后自动看板

如需，我可以进一步提供 .gitlab-ci.yml 模板和灰度切流的具体配置示例。