云原生核心技术 (12/12): 终章：使用 GitLab CI 将应用自动部署到 K8s (保姆级教程)

大家好，欢迎来到《云原生核心技术》系列的最终章！

我们一起走过了漫长而充实的旅程。从 Docker 的集装箱，到 K8s 这座自动化的数字港口；从部署单个 Pod，到构建复杂的有状态应用。现在，我们站在了实现全自动化的最后一站。

在上一篇中，我们理解了 CI/CD 的核心理念——那条连接开发与运维、通往高效与可靠的自动化高速公路。今天，我们不再纸上谈兵，而是要亲手铺设这条公路的每一块砖石。

我们将使用一个强大且整合度极高的工具——GitLab CI/CD，为我们第十篇中的 Spring Boot + MySQL + Redis 应用项目，打造一条从代码提交到自动部署至 Kubernetes 的完整流水线。

读完并实践本篇文章，你将获得一项在现代软件工程中极具价值的技能：将 DevOps 思想落地，实现应用的自动化、可靠化交付。

准备好，让我们开始最后的施工，为这个系列画上一个完美的句号！

第一步：环境准备与规划

在开始之前，请确保你已经拥有：

1. 一个 GitLab 账号和项目：你可以使用 GitLab.com 的免费版，或者自建的 GitLab 实例。将我们第十篇的 Spring Boot 项目代码推送到这个 GitLab 仓库中。
2. 一个运行中的 K8s 集群：继续使用我们的 Minikube 集群。minikube start
3. 一个 Docker 镜像仓库：比如 Docker Hub。你需要一个可以推送镜像的账号。
4. kubectl 和 helm 命令行工具：Helm 是 K8s 的包管理器，我们将用它来方便地安装 GitLab Runner。

我们的流水线规划如下：

• test 阶段：运行 Maven 测试，确保代码质量。
• build 阶段：使用 Docker 构建 Spring Boot 应用的镜像。
• push 阶段：将构建好的镜像推送到 Docker Hub。
• deploy 阶段：使用 kubectl 命令更新 K8s 中对应 Deployment 的镜像版本，触发滚动更新。

第二步：在 K8s 中安装 GitLab Runner

GitLab Runner 是执行 .gitlab-ci.yml 文件中定义任务的代理程序。最云原生的方式，就是把它直接安装在我们的 K8s 集群里。

1. 获取 Runner 注册信息：

   • 打开你的 GitLab 项目，在左侧导航栏找到 Settings -> CI/CD。
   • 展开 Runners 部分。你会看到一个 URL (https://gitlab.com/) 和一个注册令牌 (registration token)，类似 GR13489...。把这两项复制下来，后面会用到。

2. 使用 Helm 安装 GitLab Runner：

   • 添加 GitLab Helm 仓库：

     helm repo add gitlab https://charts.gitlab.io
     helm repo update
     

   • 创建一个 values.yaml 配置文件，用于定制我们的 Runner。

     # values.yaml
     gitlabUrl: "https://gitlab.com/"  # 填入你复制的 GitLab URL
     runnerRegistrationToken: "GR13489..." # 填入你复制的注册令牌
     
     # Runner 的配置
     runners:
       # Runner 的标签，后面在 .gitlab-ci.yml 中会用它来选择 Runner
       tags: "kubernetes,minikube"
     

   • 执行 Helm 安装命令：

     helm install --namespace gitlab-runner --create-namespace gitlab-runner \
     -f values.yaml \
     gitlab/gitlab-runner
     

   • 验证安装：稍等片刻，然后检查 Pod 是否在 gitlab-runner 命名空间中成功运行。

     kubectl get pods -n gitlab-runner
     # 你应该能看到一个名为 gitlab-runner-gitlab-runner-xxxx 的 Pod 正在运行
     

   • 回到 GitLab 项目的 Runner 设置页面，你应该能看到一个新的 Runner 已经注册成功并显示为绿色可用状态。

第三步：配置 GitLab CI/CD 变量

为了安全，我们不能把敏感信息（如 Docker Hub 密码、K8s 凭证）直接写在 .gitlab-ci.yml 文件里。我们需要将它们存储在 GitLab 的 CI/CD 变量中。

进入 Settings -> CI/CD，展开 Variables 部分。添加以下变量：

1. Docker Hub 凭证：

   • DOCKER_USER: 你的 Docker Hub 用户名。
   • DOCKER_PASS: 你的 Docker Hub 密码或访问令牌 (Access Token)。(建议设置为 Masked 类型)

2. K8s 集群凭证 (kubeconfig)：

   • 我们需要让 GitLab Runner 能够访问我们的 Minikube 集群。
   • 在你的本地电脑上，找到 ~/.kube/config 文件，并将其内容完整复制下来。
   • 在 GitLab 变量设置中，创建一个新变量：
     • Key: KUBE_CONFIG
     • Type: File (这很重要，它会将变量内容作为文件提供给 Runner)
     • Value: 粘贴你刚才复制的 kubeconfig 全部内容。

第四步：编写 .gitlab-ci.yml，定义流水线

这是最核心的一步。在你的 Spring Boot 项目根目录下，创建 .gitlab-ci.yml 文件，内容如下：

# .gitlab-ci.yml

# 定义流水线的各个阶段，任务会按此顺序执行
stages:
  - test
  - build
  - push
  - deploy

# 定义一些全局变量
variables:
  # Maven 镜像，用于测试阶段
  MAVEN_IMAGE: maven:3.8-openjdk-17
  # Docker 镜像名称。$CI_PROJECT_NAME 是 GitLab 预定义变量，代表项目名
  IMAGE_NAME: $CI_REGISTRY_USER/$CI_PROJECT_NAME
  # 镜像标签。$CI_COMMIT_SHORT_SHA 是提交的短哈希值，确保每次构建的标签唯一
  IMAGE_TAG: $CI_COMMIT_SHORT_SHA

# --- 阶段一：测试 ---
maven_test:
  stage: test
  image: $MAVEN_IMAGE
  script:
    - echo "Running Maven tests..."
    - ./mvnw test
  tags:
    - kubernetes # 指定使用我们安装在 K8s 里的 Runner

# --- 阶段二：构建 Docker 镜像 ---
docker_build:
  stage: build
  # 使用 Docker-in-Docker (dind) 镜像，以便在容器内执行 Docker 命令
  image: docker:20.10.16
  services:
    - docker:20.10.16-dind
  script:
    - echo "Building Docker image..."
    - docker build -t $IMAGE_NAME:$IMAGE_TAG .
    # 保存镜像为 tar 文件，以便在后续阶段使用
    - docker save $IMAGE_NAME:$IMAGE_TAG > image.tar
  # artifacts 用于在不同阶段之间传递文件
  artifacts:
    paths:
      - image.tar
  tags:
    - kubernetes

# --- 阶段三：推送 Docker 镜像 ---
docker_push:
  stage: push
  image: docker:20.10.16
  services:
    - docker:20.10.16-dind
  # 需要上一个阶段构建的镜像文件
  needs:
    - docker_build
  script:
    - echo "Pushing Docker image..."
    # 加载镜像文件
    - docker load < image.tar
    # 登录 Docker Hub，使用我们之前定义的 CI/CD 变量
    - echo $DOCKER_PASS | docker login -u $DOCKER_USER --password-stdin
    - docker push $IMAGE_NAME:$IMAGE_TAG
  tags:
    - kubernetes

# --- 阶段四：部署到 Kubernetes ---
deploy_to_k8s:
  stage: deploy
  # 使用一个包含 kubectl 的镜像
  image:
    name: bitnami/kubectl:latest
    entrypoint: [""]
  needs:
    - docker_push
  script:
    - echo "Deploying to Kubernetes..."
    # 配置 kubectl，让它使用我们通过变量传入的 KUBE_CONFIG
    - export KUBECONFIG=$KUBE_CONFIG
    # 使用 kubectl set image 命令来更新 Deployment 的镜像，触发滚动更新
    # 将 'springboot-app-deployment' 替换为你在 K8s 中实际的 Deployment 名称
    - kubectl set image deployment/springboot-app-deployment springboot-app=$IMAGE_NAME:$IMAGE_TAG
    - echo "Deployment updated successfully!"
  tags:
    - kubernetes

请注意：

• 将 springboot-app-deployment 和容器名 springboot-app 替换成你在第十篇中使用的实际名称。
• $CI_REGISTRY_USER 默认是你的 GitLab 用户名，你也可以硬编码为你的 Docker Hub 用户名。

第五步：触发流水线，见证自动化魔法！

现在，一切准备就绪。

1. 提交并推送代码：将包含 .gitlab-ci.yml 的项目推送到你的 GitLab 仓库。

   git add .
   git commit -m "feat: Add GitLab CI/CD pipeline for automated deployment"
   git push
   

2. 观察流水线：

   • 立刻打开你的 GitLab 项目页面，进入 CI/CD -> Pipelines。
   • 你会看到一个新的流水线被触发了，状态为 running。
   • 点击这个流水线，你可以看到我们定义的四个阶段 test, build, push, deploy 正在依次执行。你可以点击每一个 job 查看详细的实时日志输出。

3. 验证部署：

   • 当 deploy 阶段成功完成后，打开你的终端。
   • 检查你的 Deployment，你会看到它的镜像已经被更新为最新的版本（带有新的 commit 哈希标签）。

     kubectl describe deployment springboot-app-deployment
     

   • 检查 Pod，你会看到 K8s 已经完成了滚动更新，新的 Pod 正在运行。

     kubectl get pods
     

现在，尝试修改一下 Spring Boot 代码中的某个字符串，然后再次 git push。你将再次看到整个自动化流程被触发，几分钟后，你的线上应用就被无缝地更新了！

总结与展望：你的云原生之旅，才刚刚开始

恭喜你！你已经成功地走完了从 Docker 到 Kubernetes 再到自动化 CI/CD 的全过程！

回顾这12篇的旅程，我们从最基础的概念开始，一步一个脚印，最终搭建起了一套现代、高效、自动化的云原生应用交付系统。你不再是一个简单的代码编写者或服务器管理者，而是一个能够掌控从代码到生产完整生命周期的现代工程师。

但这并不是终点，而是一个全新的起点。 云原生的世界浩瀚无垠，还有更多激动人心的领域等待你去探索：

• 服务网格 (Service Mesh): 使用 Istio, Linkerd 来实现更高级的流量管理、可观测性和安全性。
• 可观测性 (Observability): 深入学习 Prometheus, Grafana, Jaeger，打造全方位的监控、日志和追踪系统。
• Serverless/FaaS: 探索 Knative, OpenFaaS，让你的应用真正做到按需运行，极致弹性。
• GitOps: 学习 ArgoCD, Flux，将 Git 作为管理基础设施和应用的唯一真实来源。

希望这个系列能为你打开一扇通往云原生世界的大门。保持好奇，持续学习，愿你在这片广阔的数字海洋中，乘风破浪，扬帆远航！

感谢你的一路相伴，我们的系列到此结束。江湖再见！