自动化发布流水线 - 运维技术服务中心

案例 01

Jenkins Pipeline 全自动 CI/CD 流水线搭建

背景描述

某团队 15 个微服务，每次发布需要人工执行：拉代码 → 编译 → 单元测试 → 打包 Docker 镜像 → 推送 Harbor → 更新 K8s Deployment。耗时 2 小时且步骤遗漏频发。

解决方案

搭建 Jenkins Master + 3 Agent 架构，编写声明式 Jenkinsfile 定义 CI/CD 流水线。GitLab Webhook 触发 → 自动构建 → 质量门禁 → 制品推送 → 滚动更新 K8s。全流程 12 分钟。

技术要点

Jenkins Docker Agent 动态创建销毁，资源池化
SonarQube 质量门禁：覆盖率 <80% 或 Bug >10 阻塞发布
Harbor 镜像仓库 + Trivy 安全扫描
K8s 滚动更新 + 自动回滚（监控异常比例 >5% 自动回滚）

// Jenkinsfile（声明式流水线）
pipeline {
  agent { label 'docker-agent' }
  environment {
    HARBOR = 'harbor.example.com'
    IMAGE = "${HARBOR}/prod/${env.JOB_NAME}:${env.BUILD_NUMBER}"
  }
  stages {
    stage('Checkout') { steps { git branch: 'main', url: '' } }
    stage('Test') {
      parallel {
        stage('Unit Test') { steps { sh 'mvn test' } }
        stage('SonarQube') { steps {
          script {
            withSonarQubeEnv('sonar') { sh 'mvn sonar:sonar' }
            timeout(3) { def qg = waitForQualityGate()
              if (qg.status != 'OK') error("Quality Gate Failed")
            }
          }
        }}
      }
    }
    stage('Build & Push') { steps {
      sh "docker build -t ${IMAGE} ."
      sh "docker push ${IMAGE}"
    }}
    stage('Deploy to K8s') { steps {
      sh """
        kubectl set image deployment/${env.JOB_NAME} \
          app=${IMAGE} --record
        kubectl rollout status deployment/${env.JOB_NAME} \
          --timeout=5m
      """
    }}
  }
  post {
    failure {
      sh "kubectl rollout undo deployment/${env.JOB_NAME}"
      emailext body: "Pipeline Failed", subject: "Build #${env.BUILD_NUMBER}", to: 'devops@example.com'
    }
  }
}

案例 02

GitLab CI + ArgoCD 实现 GitOps 发布

背景描述

某互联网公司 K8s 集群已有 50+ 应用，使用 kubectl 直改 YAML 发布，无法追溯变更历史，回滚困难。需引入 GitOps 理念。

解决方案

GitLab CI 负责 CI（构建镜像、跑测试），ArgoCD 负责 CD（监听 Git 仓库中 K8s YAML 变化并自动同步到集群）。所有变更通过 PR 审批，Git 完整审计记录。

技术要点

ArgoCD Application 监听 Git Repo，AutoSync 自动修复漂移
Kustomize 管理多环境差异（base + overlays/）
PR 预览环境：每个 PR 自动创建临时 namespace 部署
回滚：git revert + ArgoCD 自动同步（1 分钟内完成）

# ArgoCD Application 定义
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: app-service
spec:
  project: default
  source:
    repoURL: git@gitlab.example.com:platform/k8s-manifests.git
    targetRevision: main
    path: overlays/prod
  destination:
    server: https://kubernetes.default.svc
    namespace: prod
  syncPolicy:
    automated:
      prune: true       # 自动删除 Git 中移除的资源
      selfHeal: true    # 自动修复手动修改的配置
    syncOptions:
      - CreateNamespace=true

# GitLab CI .gitlab-ci.yml
build:
  stage: build
  script:
    - docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA .
    - docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA
    - |
      cd k8s-manifests/overlays/prod
      kustomize edit set image app=$CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA
      git commit -am "[CI] Update image to $CI_COMMIT_SHORT_SHA"
      git push origin main
  # ArgoCD 检测到 Git 变更后自动同步

案例 03

蓝绿部署与金丝雀发布方案落地

背景描述

某支付系统对可用性要求极高，传统滚动更新仍需等待新旧版本并存期间的不一致风险。需实现蓝绿部署零停机，并支持按流量百分比金丝雀发布。

解决方案

基于 K8s Service Selector 切换实现蓝绿部署：部署两套 Deployment（blue/green），Service 指向当前版本，切换时修改 Selector。金丝雀使用 Istio VirtualService 按权重分流。

技术要点

蓝绿切换：修改 Service label selector，流量瞬间全部切换
金丝雀：Istio VirtualService weight 实现 5% → 20% → 50% → 100% 渐进式放量
监控指标驱动的自动回滚（Prometheus + Flagger）

# 蓝绿部署 - Service 两套 Deployment
# blue-deployment.yaml (当前生产)
apiVersion: apps/v1
kind: Deployment
metadata: { name: app-blue }
spec: { template: { metadata: { labels: { version: blue } } } }

# green-deployment.yaml (新版本待上线)
apiVersion: apps/v1
kind: Deployment
metadata: { name: app-green }
spec: { template: { metadata: { labels: { version: green } } } }

# Service 切换 selector 实现蓝绿切换
kubectl patch service app-svc \
  -p '{"spec":{"selector":{"version":"green"}}}'

# 金丝雀发布 - Istio VirtualService
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata: { name: app-vs }
spec:
  hosts: ["app.example.com"]
  http:
  - match: [{ headers: { canary: { exact: "true" } } }]
    route: [{ destination: { host: app-svc, subset: v2 } }]
  - route:
    - destination: { host: app-svc, subset: v1, weight: 80 }
    - destination: { host: app-svc, subset: v2, weight: 20 }