Kubernetes中，微服务自动化发布系统详解

实施微服务架构后，原先单一的系统结构统变成了数量众多的微服务应用，开发、测试、运维部署等都会面临不少挑战。在微服务架构下如何提高工程研发效率，确保开发、测试、运维部署等流程上的顺畅，是微服务技术体系能够真正落地产生效益的关键。

要实现上述目标就需要基于DevOps（开发运维）思想构建一套高度自动化的发布系统，在该系统中开发人员可以随时随地构建代码并将其发布至指定的运行环境中，这个过程也就是我们通常所说的CI/CD（持续集成/持续交付）流程。

关于DevOps的具体实践，不同的公司一般会根据自身的发展阶段和实际需要来选择具体落地的方案。具备条件的公司可以研发功能丰富的可视化发布系统，而条件有限的创业公司则可以通过开源或现有的技术组件（如GitLab、Jenkins等）来实现操作相对简陋但功能完备的自动化发布系统。

在本篇文章中我将以Spring Cloud微服务技术体系为背景，通过GitLab自带的CI/CD机制并基于Kubernetes容器化技术来实现一套具备相对完整CI/CD流程的自动化发布系统。

CI/CD流程概述

============================================================================

实际上DevOps并不是微服务架构流行之后才产生的概念，而是业界在多年软件开发实践中积累的理论、工具的集合。本文所要讨论的自动化发布系统实际上是要通过搭建CI/CD流水线来建立一套应用程序构建、测试、打包及发布的高效自动化方法。关于CI(持续集成)/CD（持续交付）的概念并不是指某一种具体的技术，而是一种软件工程文化加一系列操作原则和具体实践的集合。

其中CI（持续集成）的主要目标是通过建立一致的自动化构建方法来打包程序代码，使得团队成员能够以更频繁地动作提交代码、更早地进行代码集成，以及时发现和解决代码中的问题、提高协作开发效率及软件交付质量。可持续集成（CI）的基本流程如图所示：

从实现流程上来说CI的主要过程就是将开发人员提交的代码以高度自动化的方式打包成可以在具体基础架构环境运行的程序包（例如Docker镜像）。而这个过程可以由一组工具如GitLab Runner（CI Pipeline）、Sonar（代码检测工具）等去完成，具体构建CI流程时根据实际需要集成运用即可。

持续交付（CD）的主要逻辑则是将CI流程中构建的程序镜像从镜像仓库自动发布到具体的基础架构环境（如测试/生产Kubernetes集群），实现CD的工具主要有GitLab Runner（CD Pipeline）、Helm（Kubernetes软件包管理工具）等。

实际上CD的核心就是通过输入的各种用户参数（如yaml文件、环境配置参数等）最终自动生成具体的发布指令（如Helm指令），并根据参数中设置的相应信息来配置程序的具体运行环境。可持续交付（CD）的基本运行流程如下图所示：

以上就是CI/CD的基本概念及流程，也是自动化发布系统的实现的依据。在后面的内容中将主要围绕这两个阶段来实现自动化发布系统的基本流程逻辑。

系统的基本组成

==========================================================================

本文所要描述的自动化发布系统主要是利用GitLab提供的GitLab CI机制，实现当代码发生提交或合并等事件时自动触发预设的CI/CD流程。其中CI流程主要包括基本的代码编译、构建、打包等阶段，并在完成上述步骤后将打包好的应用Docker镜像发布至镜像仓库。

而CD阶段则是从镜像仓库拉取应用Docker镜像，并根据设置的CD流程将应用发布至指定的Kubernetes集群。具体系统结构如下图所示：

如上图所示，该自动化发布系统主要由GitLab、Harbor镜像仓库及Kubernetes集群组成。其中GitLab主要承担代码版本的管理，以及CI/CD流程定义和触发， Harbor负责应用Docker镜像的存储和分发，而Kubernetes集群则是应用容器运行的基础架构环境。

GitLab-CI自动化发布系统的关键实现

========================================================================================

前面我们描述了基于GitLab-CI机制实现自动化发布系统的基本组成，要具体实现这套系统你需要安装部署GitLab服务器并配置GItLab Runner功能，私有镜像仓库服务（Harbor或JFrog）以及Kubernetes集群（具体可参见本专栏的其他文章）。

由于GitLab服务器是CI/CD流程执行的主要承载点，如果你的服务是基于Maven构建的Java服务，那么还需要在GitLab服务器中安装Maven客户端，并配置Maven私服的地址，以提高构建速度。此外GitLab服务器在CI/CD流程执行中还会运行Docker镜像打包构建，将镜像push到Docker镜像仓库以及将Docker镜像从私有仓库发布至Kubernetes集群等逻辑，所以GitLab服务器还需要安装Docker环境及kubelet客户端。

如果环境都OK，那么我们就可以在Gitlab项目根目录代码中创建“.gitlab-ci.yml”文件并定义具体的CI/CD流程了。但在具体定义之前，我们需要在Maven项目中添加应用Docker镜像打包的插件配置及Dockerfile文件定义，具体如下：

com.spotify

dockerfile-maven-plugin

1.4.13

build-image

package

build

docker/Dockerfile

$docker.repository/springcloud-action/${app.name}

<JAR_FILE>target/${project.build.finalName}.jar</JAR_FILE>

在项目工程pom.xml文件中添加“dockerfile-maven-plugin”插件，该插件是早期“docker-maven-plugin”插件的替代品，支持将Maven项目构建打包为Docker镜像。上述配置中，针对Docker镜像的具体构建方式，是通过在标签中指定Dockerfile文件来实现的。具体可在项目工程中创建docker目录，并创建Dockerfile文件，内容如下：

FROM openjdk:8u191-jre-alpine3.9

ENTRYPOINT [“/usr/bin/java”, “-jar”, “/app.jar”]

ARG JAR_FILE

ADD ${JAR_FILE} /app.jar

EXPOSE 8080

配置好Maven打包插件后，就能支持通过Maven打包命令，将应用代码打包成Docker镜像了。此时我们在".gitlab-ci.yml"文件中定义具体的CI/CD构建Stages，示例如下：

#环境参数信息

variables:

#Docker镜像仓库地址&账号密码信息

DOCKER_REPO_URL: “10.211.55.11:8088”

DOCKER_REPO_USERNAME: admin

DOCKER_REPO_PASSWORD: Harbor12345

#Kubernetes相关信息配置(空间与服务端口)

K8S_NAMESPACE: “wudimanong”

PORT: “8080”

#定义CI/CD阶段

stages:

• test

• build

• push

• deploy

#执行单元测试阶段

maven-test:

stage: test

script:

• mvn clean test

#代码编译打包镜像阶段

maven-build:

stage: build

script:

• mvn clean package -DskipTests

#将打包的Docker镜像上传至私有镜像仓库

docker-push:

stage: push

script:

#对打包的镜像进行tag

• docker tag $DOCKE{R}_{R}EP{O}_{U}RL/$CI_PROJECT_PATH $DOCKE{R}_{R}EP{O}_{U}RL/$CI_PROJECT_PATH/$C{I}_{B}UIL{D}_{R}E{F}_{N}AME:${CI_COMMIT_SHA:0:8}

#登录私有镜像仓库

• docker login $DOCKER_REPO_URL -u $DOCKER_REPO_USERNAME -p $DOCKER_REPO_PASSWORD

#上传应用镜像至镜像仓库

• docker push $DOCKE{R}_{R}EP{O}_{U}RL/$CI_PROJECT_PATH/$C{I}_{B}UIL{D}_{R}E{F}_{N}AME:${CI_COMMIT_SHA:0:8}

• docker rmi $DOCKE{R}_{R}EP{O}_{U}RL/$CI_PROJECT_PATH/$C{I}_{B}UIL{D}_{R}E{F}_{N}AME:${CI_COMMIT_SHA:0:8}

• docker rmi $DOCKE{R}_{R}EP{O}_{U}RL/$CI_PROJECT_PATH

#将应用发布至Kubernetes测试集群（这里指定为手动确认方式）

deploy-test:

stage: deploy

when: manual

script:

• kubectl config use-context kubernetes-admin@kubernetes

• sed -e “s/REPLICAS/1/; s/PORT/KaTeX parse error: Expected group after '_' at position 10: PORT/; s/_̲_APP_NAME__/CI_PROJECT_NAME/; s/PROFILE/test/; s/IMAGE/KaTeX parse error: Undefined control sequence: \/ at position 16: DOCKER_REPO_URL\̲/̲{CI_PROJECT_PATH\/}/KaTeX parse error: Undefined control sequence: \/ at position 21: …UILD_REF_NAME//\̲/̲/\\/}:{CI_COMMIT_SHA:0:8}/” kubernetes/deploy.yaml | kubectl -n ${K8S_NAMESPACE} apply -f -

如上所述，我们在“.gitlab-ci.yml”文件中定义了”test、build、push、deploy”这4个stages阶段。这几个stages的具体说明如下：

• test：执行单元测试代码；

• build：执行构建打包指令，将应用构建打包为Docker镜像；

• push：该阶段主要是将build构建的本地Docker镜像经过tag处理后上传至Harbor镜像仓库，并在成功后清理掉本地镜像文件；

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数Java工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Java开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录大纲截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且后续会持续更新

如果你觉得这些内容对你有帮助，可以添加V获取：vip1024b （备注Java）

总结

在这里，由于面试中MySQL问的比较多，因此也就在此以MySQL为例为大家总结分享。但是你要学习的往往不止这一点，还有一些主流框架的使用，Spring源码的学习，Mybatis源码的学习等等都是需要掌握的，我也把这些知识点都整理起来了

一个人可以走的很快，但一群人才能走的更远。不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎扫码加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

，因此也就在此以MySQL为例为大家总结分享。但是你要学习的往往不止这一点，还有一些主流框架的使用，Spring源码的学习，Mybatis源码的学习等等都是需要掌握的，我也把这些知识点都整理起来了

[外链图片转存中…(img-fRstMPnH-1712857754006)]

[外链图片转存中…(img-Hs81i88s-1712857754007)]

一个人可以走的很快，但一群人才能走的更远。不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎扫码加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
[外链图片转存中…(img-2MyBroI1-1712857754007)]