从代码到发版：揭秘基于GitLab + Jenkins + Kubernetes的自动化流水线

🌟 从代码到发版：揭秘基于GitLab + Jenkins + Kubernetes的自动化流水线 🌟

🚀 场景代入：将软件交付比作“智能物流系统”

想象你经营一家全球物流公司，货物（代码）从工厂（开发环境）生产后，需要标准化打包（Docker镜像）、贴上物流标签（Git Tag）、自动分拣（Jenkins流水线），最终精准配送至目的地（Kubernetes集群）。下面带你拆解这条全自动流水线！

📦 第一阶段：开发与打包——货物的“生产与封装”

1. 工程师本地准备

源码开发：编写业务代码（如Java/Python）、单元测试。

Dockerfile编写：定义镜像构建规则，确保环境一致性。

FROM openjdk:11-jdk-slim
COPY target/*.jar /app.jar
EXPOSE 8080
ENTRYPOINT ["java","-jar","/app.jar"]

Helm Charts编写：Kubernetes应用模板，包含Deployment、Service等配置。

# charts/values.yaml
image:
  repository: myapp
  tag: latest
service:
  port: 8080

2. 提交代码到GitLab

推送本地代码到GitLab仓库，目录结构如下：

├── src/              # 源码
├── Dockerfile        # 镜像构建文件
├── Jenkinsfile       # 流水线定义
└── charts/           # Helm Charts
    ├── Chart.yaml
    ├── values.yaml
    └── templates/

🏷️ 第二阶段：版本控制——为货物“贴标签”

研发创建Git Tag：标记版本号（如v1.2.0），触发自动化流程。
```
git tag -a v1.2.0 -m "Release version 1.2.0"
git push origin v1.2.0
```

🏭 第三阶段：持续集成（Jenkins流水线）——全自动分拣中心

1. Jenkins监听GitLab Tag事件

Webhook配置：GitLab推送Tag时触发Jenkins任务。

Checkout代码：拉取对应Tag的代码和Helm Charts。

pipeline {
    agent any
    stages {
        stage('Checkout') {
            steps {
                git branch: '${TAG}', url: 'git@gitlab.com:your-project.git'
            }
        }
        // 后续阶段...
    }
}

2. 代码编译与打包

Maven构建：生成可执行JAR包。

stage('Build') {
    steps {
        sh 'mvn clean package -DskipTests'
    }
}

3. Docker镜像构建与推送

构建镜像：使用Dockerfile生成镜像，并注入版本号。

stage('Docker Build') {
    steps {
        script {
            dockerImage = docker.build("harbor.example.com/library/myapp:${TAG}")
        }
    }
}

推送至Harbor：需提前配置Harbor仓库认证。

stage('Docker Push') {
    steps {
        docker.withRegistry('https://harbor.example.com', 'harbor-cred') {
            dockerImage.push()
        }
    }
}

4. Helm Chart打包与上传

打包Chart：生成.tgz文件。

stage('Helm Package') {
    steps {
        sh 'helm package charts/ --version ${TAG}'
    }
}

推送至Helm Museum：存储Chart版本。

stage('Helm Push') {
    steps {
        sh 'helm push myapp-${TAG}.tgz museum-repo'
    }
}

🚚 第四阶段：Kubernetes发版——精准配送至“客户”

1. Jenkins触发K8s更新

更新Helm Release：使用新版本Chart和镜像。

stage('Deploy to K8s') {
    steps {
        sh '''
            helm upgrade myapp museum-repo/myapp \
            --set image.tag=${TAG} \
            --namespace production
        '''
    }
}

2. Kubernetes拉取资源

Helm指令解析：
- 从Helm Museum拉取最新Chart。
- 从Harbor拉取对应Tag的Docker镜像。
滚动更新：K8s逐步替换旧Pod，确保零停机。

📊 全流程可视化

graph LR
  A[开发者提交代码+Helm Chart] --> B[GitLab打Tag]
  B --> C{Jenkins流水线}
  C --> D1[Maven构建]
  C --> D2[Docker镜像推送至Harbor]
  C --> D3[Helm Chart推送至Museum]
  D1 & D2 & D3 --> E[K8s Helm Upgrade]
  E --> F[服务上线]

🔧 关键技术点解析

版本一致性：
- Git Tag、Docker镜像Tag、Helm Chart版本三者严格对齐，避免环境错乱。
安全认证：
- Jenkins需配置Harbor账号、Helm Museum凭证、K8s集群kubeconfig。
回滚机制：
- 通过helm rollback myapp <revision>快速回退版本。

🚨 常见问题与排查

镜像推送失败：检查Harbor仓库权限或网络连通性。
Helm部署卡顿：确认K8s集群资源是否充足。
版本不匹配：确保Jenkins参数${TAG}传递正确。

🎯 总结：自动化流水线的核心价值

标准化：从代码到镜像再到Chart，全链路版本控制。
高效协同：研发专注代码，运维专注流程，互不干扰。
可追溯：任何版本均可快速定位代码、镜像及配置。

📢 互动话题
你的团队是如何设计发布流程的？遇到过哪些“坑”？欢迎分享你的经验！
（比如：曾经因Tag命名不规范导致生产环境崩了？镜像仓库被意外覆盖？）