5.4 KiB
5.4 KiB
tags, create time
| tags | create time | |||||
|---|---|---|---|---|---|---|
|
2026-05-05 |
CI/CD 与 GitOps
概述
微服务需要独立部署。上百个服务的手工发布是不可想象的——必须用自动化流水线保证每次变更都能安全、快速地推送到生产环境。
flowchart LR
CODE["代码提交"] --> TEST["测试 & 静态分析"]
TEST --> SCAN["安全扫描"]
SCAN --> BUILD["构建镜像"]
BUILD --> PUSH["推送仓库"]
PUSH --> STAGING["Staging 验证"]
STAGING -->|"人工审批"| PROD["Production 部署"]
style CODE fill:#e3f2fd
style TEST fill:#fff3e0
style SCAN fill:#fce4ec
style BUILD fill:#e8f5e9
style PUSH fill:#f3e5f5
style STAGING fill:#e0f7fa
style PROD fill:#c8e6c9
CI/CD 设计原则
| 原则 | 说明 |
|---|---|
| 一次构建，多处部署 | 镜像不随环境重新编译，只改 K8s ConfigMap/环境变量 |
| 语义化版本 | 镜像 tag 用 v1.2.3，tag 即版本溯源 |
| 路径过滤 | 只对相关服务的代码变更触发构建 |
| Commit SHA 作为镜像 tag | 保证精确回滚 |
| 分阶段部署 | Staging → Production 的审批关卡不可跳过 |
GitHub Actions Pipeline 实战
# .github/workflows/deploy.yml
name: Deploy order-service
on:
push:
branches: [main]
paths:
- "services/order/**"
env:
REGISTRY: registry.example.com
IMAGE: order-service
jobs:
# ========== Stage 1: Build & Test ==========
build-and-test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Run tests
run: make test
- name: Security scan
uses: aquasecurity/trivy-action@master
with:
scan-type: 'fs'
severity: 'CRITICAL,HIGH'
- name: Build Docker image
run: |
docker build -t ${{ env.REGISTRY }}/${{ env.IMAGE }}:${{ github.sha }} \
-t ${{ env.REGISTRY }}/${{ env.IMAGE }}:v${{ github.run_number }} \
-f services/order/Dockerfile \
services/order
- name: Push to registry
run: |
echo "${{ secrets.REGISTRY_PASSWORD }}" | docker login -u ${{ secrets.REGISTRY_USER }} --password-stdin
docker push ${{ env.REGISTRY }}/${{ env.IMAGE }}:${{ github.sha }}
docker push ${{ env.REGISTRY }}/${{ env.IMAGE }}:v${{ github.run_number }}
# ========== Stage 2: Deploy to Staging ==========
deploy-staging:
needs: build-and-test
runs-on: ubuntu-latest
environment: staging
steps:
- name: Deploy to staging
run: |
kubectl set image deployment/order-service \
order=${{ env.REGISTRY }}/${{ env.IMAGE }}:${{ github.sha }} \
--namespace=staging
kubectl rollout status deployment/order-service \
--namespace=staging --timeout=120s
# ========== Stage 3: Deploy to Production ==========
deploy-production:
needs: deploy-staging
runs-on: ubuntu-latest
environment: production
steps:
- name: Canary release (10% → 50% → 100%)
run: |
kubectl patch canary order-service --type merge \
-p '{"spec":{"weight":10}}'
# ... 等待监控确认，逐步放大流量
echo "Monitor metrics before proceeding..."
GitOps 工作流
GitOps 的核心思想：K8s 集群的状态 = Git 仓库中声明式配置的当前状态。
flowchart LR
Dev["开发者 PR"] -->|"修改 K8s manifest"| Git[(Git Repo)]
subgraph Cluster["K8s Cluster"]
Argo["ArgoCD / Flux"] -->|同步| K8sState["Pod/Service/ConfigMap"]
end
Git -.->|Webhook| Argo
Argo -->|"检测到差异"| Diff{"状态一致?"}
Diff -- 否 --> Sync["自动同步到 K8s ✅"]
Diff -- 是 --> OK["已一致 ⏸️"]
style Git fill:#e3f2fd
style Argo fill:#fff3e0
style K8sState fill:#e8f5e9
与传统 CI/CD 的区别
| 维度 | 传统 CI/CD | GitOps |
|---|---|---|
| 部署驱动 | CI 服务器主动推送 | Git 仓库变动触发拉取 |
| 状态源 | CI pipeline 的历史记录 | Git commit history |
| 回滚方式 | 回到上一次的 pipeline | git revert + 自动同步 |
| 漂移检测 | 通常无 | 持续比对，自动修复不一致 |
| 代表工具 | Jenkins / GitLab CI / GitHub Actions | ArgoCD / Flux |
GitOps 的优势
- 审计完整 — 所有变更都在 Git 中可追溯
- 回滚简单 —
git revert就是回滚操作 - 自修复 — ArgoCD 持续监测并修复集群状态偏离
- 多人协作 — 通过 PR Review 流程管控配置变更
Helm — K8s 的包管理
当每个服务都有几十行 YAML 时，Helm 能大幅简化部署：
# 创建 Chart 模板
helm create order-service
# 使用 values.yaml 参数化部署
helm upgrade --install order-service ./charts/order-service \
--set image.tag=v1.2.3 \
--set replicas=3 \
--namespace=production
[!tip] 为什么需要 Helm？
没有 Helm 时，每个服务都要手动维护 Deployment、Service、Ingress、ConfigMap 等几十个 YAML 文件。Helm 允许你把通用模板抽出来，只在 values.yaml 里改差异化配置。
关联笔记
- 05-部署运维/01-容器化 — Docker 镜像构建是 CI/CD 的第一步
- 05-部署运维/02-Kubernetes — K8s 是部署的目标平台
- 05-部署运维/04-SRE实践 — 错误预算影响发布策略