云原生核心技术 (12/12): 终章:使用 GitLab CI 将应用自动部署到 K8s (保姆级教程)
大家好,欢迎来到《云原生核心技术》系列的最终章!
我们一起走过了漫长而充实的旅程。从 Docker 的集装箱,到 K8s 这座自动化的数字港口;从部署单个 Pod,到构建复杂的有状态应用。现在,我们站在了实现全自动化的最后一站。
在上一篇中,我们理解了 CI/CD 的核心理念——那条连接开发与运维、通往高效与可靠的自动化高速公路。今天,我们不再纸上谈兵,而是要亲手铺设这条公路的每一块砖石。
我们将使用一个强大且整合度极高的工具——GitLab CI/CD,为我们第十篇中的 Spring Boot + MySQL + Redis
应用项目,打造一条从代码提交到自动部署至 Kubernetes 的完整流水线。
读完并实践本篇文章,你将获得一项在现代软件工程中极具价值的技能:将 DevOps 思想落地,实现应用的自动化、可靠化交付。
准备好,让我们开始最后的施工,为这个系列画上一个完美的句号!
第一步:环境准备与规划
在开始之前,请确保你已经拥有:
- 一个 GitLab 账号和项目:你可以使用
GitLab.com
的免费版,或者自建的 GitLab 实例。将我们第十篇的 Spring Boot 项目代码推送到这个 GitLab 仓库中。 - 一个运行中的 K8s 集群:继续使用我们的 Minikube 集群。
minikube start
- 一个 Docker 镜像仓库:比如 Docker Hub。你需要一个可以推送镜像的账号。
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 集群里。
-
获取 Runner 注册信息:
- 打开你的 GitLab 项目,在左侧导航栏找到
Settings
->CI/CD
。 - 展开
Runners
部分。你会看到一个 URL (https://gitlab.com/
) 和一个注册令牌 (registration token),类似GR13489...
。把这两项复制下来,后面会用到。
- 打开你的 GitLab 项目,在左侧导航栏找到
-
使用 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 中会用它来选择 Runnertags: "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 Helm 仓库:
第三步:配置 GitLab CI/CD 变量
为了安全,我们不能把敏感信息(如 Docker Hub 密码、K8s 凭证)直接写在 .gitlab-ci.yml
文件里。我们需要将它们存储在 GitLab 的 CI/CD 变量中。
进入 Settings
-> CI/CD
,展开 Variables
部分。添加以下变量:
-
Docker Hub 凭证:
DOCKER_USER
: 你的 Docker Hub 用户名。DOCKER_PASS
: 你的 Docker Hub 密码或访问令牌 (Access Token)。(建议设置为Masked
类型)
-
K8s 集群凭证 (
kubeconfig
):- 我们需要让 GitLab Runner 能够访问我们的 Minikube 集群。
- 在你的本地电脑上,找到
~/.kube/config
文件,并将其内容完整复制下来。 - 在 GitLab 变量设置中,创建一个新变量:
- Key:
KUBE_CONFIG
- Type:
File
(这很重要,它会将变量内容作为文件提供给 Runner) - Value: 粘贴你刚才复制的
kubeconfig
全部内容。
- Key:
第四步:编写 .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: testimage: $MAVEN_IMAGEscript:- echo "Running Maven tests..."- ./mvnw testtags:- kubernetes # 指定使用我们安装在 K8s 里的 Runner# --- 阶段二:构建 Docker 镜像 ---
docker_build:stage: build# 使用 Docker-in-Docker (dind) 镜像,以便在容器内执行 Docker 命令image: docker:20.10.16services:- docker:20.10.16-dindscript:- echo "Building Docker image..."- docker build -t $IMAGE_NAME:$IMAGE_TAG .# 保存镜像为 tar 文件,以便在后续阶段使用- docker save $IMAGE_NAME:$IMAGE_TAG > image.tar# artifacts 用于在不同阶段之间传递文件artifacts:paths:- image.tartags:- kubernetes# --- 阶段三:推送 Docker 镜像 ---
docker_push:stage: pushimage: docker:20.10.16services:- docker:20.10.16-dind# 需要上一个阶段构建的镜像文件needs:- docker_buildscript:- 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_TAGtags:- kubernetes# --- 阶段四:部署到 Kubernetes ---
deploy_to_k8s:stage: deploy# 使用一个包含 kubectl 的镜像image:name: bitnami/kubectl:latestentrypoint: [""]needs:- docker_pushscript:- 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 用户名。
第五步:触发流水线,见证自动化魔法!
现在,一切准备就绪。
-
提交并推送代码:将包含
.gitlab-ci.yml
的项目推送到你的 GitLab 仓库。git add . git commit -m "feat: Add GitLab CI/CD pipeline for automated deployment" git push
-
观察流水线:
- 立刻打开你的 GitLab 项目页面,进入
CI/CD
->Pipelines
。 - 你会看到一个新的流水线被触发了,状态为
running
。 - 点击这个流水线,你可以看到我们定义的四个阶段
test
,build
,push
,deploy
正在依次执行。你可以点击每一个 job 查看详细的实时日志输出。
- 立刻打开你的 GitLab 项目页面,进入
-
验证部署:
- 当
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 作为管理基础设施和应用的唯一真实来源。
希望这个系列能为你打开一扇通往云原生世界的大门。保持好奇,持续学习,愿你在这片广阔的数字海洋中,乘风破浪,扬帆远航!
感谢你的一路相伴,我们的系列到此结束。江湖再见!