Jenkins+GitLab CI/CD流水线搭建：自动化部署与故障回滚实战

CI/CD流水线是DevOps实践中连接代码提交和生产部署的核心基础设施。Jenkins作为持续集成引擎配合GitLab代码仓库，能实现从代码提交到自动化部署的全流程闭环。本文给出完整的流水线搭建步骤和故障回滚方案。

CI/CD流水线架构设计

典型流水线分为五个阶段：代码检出、单元测试、镜像构建、灰度发布、全量发布。每个阶段失败都会触发流水线中断和通知。灰度发布阶段只更新10%的节点，观察5分钟无异常后自动推进到全量发布。

pipeline {
    agent {
        kubernetes {
            yaml '''
            apiVersion: v1
            kind: Pod
            spec:
              containers:
              - name: docker
                image: docker:24.0
                command: ['sleep', '99']
                volumeMounts:
                - name: docker-sock
                  mountPath: /var/run/docker.sock
              volumes:
              - name: docker-sock
                hostPath:
                  path: /var/run/docker.sock
            '''
        }
    }
    environment {
        REGISTRY = 'registry.yunthe.com'
        IMAGE = "${REGISTRY}/app:${env.BUILD_NUMBER}"
    }
    stages {
        stage('Checkout') {
            steps {
                git branch: 'main', url: 'https://gitlab.com/team/app.git'
            }
        }
        stage('Test') {
            steps {
                sh 'mvn test -B'
                junit 'target/surefire-reports/*.xml'
            }
        }
        stage('Build') {
            steps {
                sh "docker build -t ${IMAGE} ."
                sh "docker push ${IMAGE}"
            }
        }
        stage('Deploy-Canary') {
            steps {
                sh "kubectl set image deploy/app app=${IMAGE} -n prod --record"
                sh "kubectl rollout status deploy/app -n prod --timeout=300s"
            }
        }
    }
}

GitLab Webhook触发配置

代码推送到GitLab后自动触发Jenkins流水线，需要在GitLab项目中配置Webhook。Jenkins侧安装GitLab插件后创建多分支流水线任务，GitLab侧配置推送事件触发。

# GitLab Webhook配置
URL: https://jenkins.yunthe.com/project/app-cicd
Trigger: Push events (main分支)
Secret Token: Jenkins生成的token

# Jenkinsfile中的触发器配置
triggers {
    gitlab(
        triggerOnPush: true,
        triggerOnMergeRequest: true,
        branchFilterType: 'NameBasedFilter',
        includeBranchesSpec: 'main',
        secretToken: env.GITLAB_TOKEN
    )
}

Webhook配置后，每次push到main分支会自动触发流水线。Merge Request触发时会运行测试阶段但不执行部署，保证合并前代码质量。

Docker镜像构建与多阶段优化

镜像构建使用多阶段Dockerfile减小最终镜像体积。构建阶段包含编译工具链，运行阶段只保留二进制文件和运行时依赖。

# Dockerfile - 多阶段构建
FROM maven:3.9-eclipse-temurin-17 AS builder
WORKDIR /build
COPY pom.xml .
RUN mvn dependency:go-offline
COPY src/ src/
RUN mvn package -DskipTests -B

FROM eclipse-temurin:17-jre-alpine
RUN addgroup -S app && adduser -S app -G app
WORKDIR /app
COPY --from=builder /build/target/app.jar .
RUN chown -R app:app /app
USER app
EXPOSE 8080
HEALTHCHECK --interval=30s --timeout=5s --retries=3 \
    CMD wget -qO- http://localhost:8080/actuator/health || exit 1
ENTRYPOINT ["java", "-jar", "app.jar"]

多阶段构建将镜像从850MB压缩到180MB。依赖离线下载（go-offline）配合Docker层缓存，构建时间从3分20秒降到45秒。

故障应急响应与自动回滚策略

部署失败的自动回滚通过Kubernetes的rollout undo实现。在流水线中增加健康检查和自动回滚阶段，部署后等待60秒检查应用健康状态，异常则触发回滚。

stage('Health-Check') {
    steps {
        script {
            def healthy = false
            for (int i = 0; i < 6; i++) {
                sleep 10
                def status = sh(
                    script: "kubectl get deploy app -n prod -o jsonpath='{.status.conditions[?(@.type==\"Available\")].status}'",
                    returnStdout: true
                ).trim()
                if (status == "True") {
                    healthy = true
                    break
                }
            }
            if (!healthy) {
                echo "Health check failed, rolling back..."
                sh "kubectl rollout undo deploy/app -n prod"
                error "Deployment rolled back due to health check failure"
            }
        }
    }
}

stage('Notify') {
    steps {
        script {
            if (currentBuild.result == 'FAILURE') {
                withCredentials([string(credentialsId: 'dingtalk-webhook', variable: 'WEBHOOK')]) {
                    sh """
                        curl -s -X POST "${WEBHOOK}" \
                        -H 'Content-Type: application/json' \
                        -d '{"msgtype":"text","text":{"content":"CI/CD部署失败: ${env.JOB_NAME} #${env.BUILD_NUMBER} 回滚状态: 已执行自动回滚"}}'
                    """
                }
            }
        }
    }
}

回滚策略的触发条件包括：Pod启动失败超过3次、健康检查端点连续返回非200状态码、部署后60秒内可用副本数为0。自动回滚将故障恢复时间从人工介入的15-20分钟缩短到70秒以内。

日志分析与监控集成

流水线运行日志和部署事件需要集中收集。Jenkins日志通过Filebeat采集到ELK集群，部署事件通过Kubernetes Event exporter推送到Prometheus。通过Grafana面板可以查看部署频率、成功率、平均部署时长等指标。

# Filebeat采集Jenkins日志
filebeat.inputs:
- type: log
  paths:
    - /var/lib/jenkins/jobs/*/builds/*/log
  fields:
    source: jenkins
  fields_under_root: true

output.elasticsearch:
  hosts: ["elasticsearch:9200"]
  index: "jenkins-logs-%{+yyyy.MM.dd}"

CI/CD流水线的成熟度评估看四个指标：部署频率（目标每日多次）、变更前置时间（目标小于30分钟）、变更失败率（目标低于5%）、平均恢复时间（目标小于1小时）。这套Jenkins加GitLab方案在多个项目中达到部署频率每日3-5次、变更失败率低于3%的水平。