德国设计网站,北辰做网站公司,几级英语可以做外贸网站seo,网站做抢红包活动广告语大家好#xff0c;欢迎来到《云原生核心技术》系列的最终章#xff01;
我们一起走过了漫长而充实的旅程。从 Docker 的集装箱#xff0c;到 K8s 这座自动化的数字港口#xff1b;从部署单个 Pod#xff0c;到构建复杂的有状态应用。现在#xff0c;我们站在了实现全自动…大家好欢迎来到《云原生核心技术》系列的最终章
我们一起走过了漫长而充实的旅程。从 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...。把这两项复制下来后面会用到。 使用 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 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_CONFIGType: 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: 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 查看详细的实时日志输出。 验证部署 当 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 作为管理基础设施和应用的唯一真实来源。
希望这个系列能为你打开一扇通往云原生世界的大门。保持好奇持续学习愿你在这片广阔的数字海洋中乘风破浪扬帆远航
感谢你的一路相伴我们的系列到此结束。江湖再见
