高薪运维项目经验分享——业务容器化改造实践（二）

本文较长，故拆分成三篇文章发送，大家可以好好去阅读和理解，本文是难得的优秀的运维项目经验讲解，大家掌握后可以自己尝试搭建，然后作为自己的项目经验写在简历上。并且，这篇文章可以更好的让你去掌握自动化运维技能。

2.3 构建基于容器的CI/CD平台

在构建CI/CD发布流水线之前，我们在Kubernetes容器云管理平台中搭建了容器化的Gitlab代码仓库和Jenkins持续集成交付工具集。

Gitlab中新创建项目，并上传商城系统的代码，每个独立部署的功能模块的代码作为独立的项目，在Gitlab中对应自己的代码仓库。涉及到代码的功能模块为前端的Vue.js项目和后端的Java项目，配套的数据库、缓存等不涉及代码。

Jenkins自身支持Master-Slave架构，即使用一个Jenkins作为Master服务器（节点），用于管理多个Slave服务器（节点），Slave服务器的用途是执行具体的构建任务，这样的好处是将构建任务的压力分摊给多个Slave节点来执行，避免master的压力过大造成的构建任务阻塞。

Jenkins支持基于kubernetes的Slave，即可以在kubernetes集群中启动jnlp容器，作为Slave服务器来执行构建任务，这样将带来更多的好处：

容器化

Jenkins Slave节点是运行在kubernetes集群中的一个POD，该POD中可以有多个具体执行构建步骤的容器，容器本身的环境是标准化的，可以自己定制容器镜像，具备很强的版本控制和可移植性。同时每个构建任务具备自己的Slave节点，与其他构建任务之间具备很好的隔离性。

Slave容器全生命周期管理

当构建任务触发时，将会自动在kubernetes集群中创建用于本次构建的Slave节点，并自动在其中执行构建任务，当构建任务结束时（无论是成功或失败）将自动销毁该Slave节点，并释放资源。

高并发

当有多个构建任务同时触发时，将会在Kubernetes集群中创建多个用于执行构建任务的Slave节点。

资源共享

所有用于执行构建任务的Slave节点共享一个Kuberenetes集群的资源。

因此我们采用Master Slave的架构来部署Jenkins，在Kubernetes中部署持续运行的Jenkins Master，在Jenkins中配置用于执行构建任务的Jenkins Slave，Slave节点只在执行构建任务的时候才会启动运行。

2.4 构建CI/CD发布流水线

利用Gitlab和Jenkins构建CI/CD发布流水线时，考虑到流水线的配置管理和版本管理，以及随代码的快速迁移性，采用了“流水线（Pipeline）”的方式来实现，将运行任务的Jenkins-Slave节点、执行的步骤等全部配置到Jenkinsfile文件中。在新建任务的时候，只需配置代码仓库，并选择Jenkinsfile即可；之后执行构建的时候将自动依照Jenkinsfile中定义好的步骤执行操作。

在Jenkinsfile中定义构建步骤时，可以根据实际的业务情况，加入代码质量检查、代码测试、代码的编译、软件制品归档、制作容器镜像、部署到Kubernetes集群、通知任务执行结果等步骤；根据实际的业务逻辑，设定步骤之间或者任务之间的串行和并行。

配置任务时，可以根据实际需要配置任务执行的触发器，可根据实际情况配置为定时轮询触发、自动触发或手动触发。如果为了实现快速的代码测试及功能发布测试，即每一次提交代码之后需要立即查看构建结果时，可以采用自动触发的方式；如果是需要正式上线，建议在触发之前，加一步人工确认环节，确认代码功能正常、符合上线要求之后，再触发构建任务，保证上线成功。

2.4.1 CI/CD发布流水线原理

通常情况下，针对一个项目，利用Gitlab和Jenkins构建的CI/CD发布流水线的原理如下图所示。

开发人员编写好程序代码，通过git提交到本地的代码仓库，提交时，需要包含后续打包成镜像的Dockerfile，以及部署到Kubernetes集群中的YAML资源配置模板。

将本地所有的程序代码及相关的配置文件都推送到远端的gitlab代码仓库服务器中，进行统一的管理。

gitlab与jenkins之间配置有webhook，可以触发jenkins进行后续的集成和交付步骤。

Jenkins配置的流水线任务触发之后，会自动拉取gitlab中的项目代码，然后对源代码进行测试、编译，最终形成软件制品，如JAR包、WAR包等。

根据项目代码中的Dockerfile，开始构建Docker镜像，镜像中包含了软件的制品及运行所需的环境。

将构建好的Docker镜像推送到私有的镜像仓库Harbor中，进行统一的管理，方便后续下载使用。

根据项目代码中的YAML资源配置模板，通过脚本将其中的变量替换为本次构建实际的输入值，生成最终可以在Kubernetes集群中部署的YAML资源配置文件。

调用Kubernetes的API，执行部署。

Kubernetes集群将依据YAML资源配置文件，从镜像仓库中拉取镜像，分配资源，并启动相关的容器和服务，开始对外提供服务。

2.4.2 CI/CD发布流水线流程及人员分工

使用Jenkins构建CI/CD发布流水线之后，工作流程实现了标准化，不仅减少了人工的工作量，而且降低了人工执行的故误操作率。同时原先大部分依靠人工来执行的工作都由流水线自动执行，因此人员的分工及工作内容可能也会与原先的不同，人员将更加专注于核心工作本身。

针对一个通用的软件项目来说，一般情况下涉及到的人员有开发人员、运维人员和测试人员。开发人员现在只需要提交自己的代码源码，以及将代码容器化Dockerfile（Dockerfile也可以由运维人员编写），而不用关心其他。运维人员则提交在Kubernetes中运行容器的配置文件。当所有的源代码和配置文件提交到代码仓库之后，Jenkins触发构建任务，进行自动的代码编译、代码测试、代码打包、制作镜像、上传镜像、部署到Kubernetes集群，当任务执行成功后，将得到一个部署好的、可用的应用系统。测试人员可以在系统中进行测试，以验证系统的功能。当测试通过之后，确认可以向生产环境部署，则可以人工确认，触发部署到生产环境的流水线，实现系统的上线。

因此，最终的人员分工及CI/CD发布的流程图如下图所示：

三、CI/CD发布流水线的实现

3.1 总览

本项目中，无论是前端的项目，还是后端的项目，二者的发布过程基本一致，都是开发、运维提交代码和配置之后，由Jenkins将代码编译并制作成容器镜像，最终再部署到Kubernetes集群中。因此实现时，在源代码的基础之上，需要加入以下三类文件：将源程序制作成镜像的配置文件（Dockerfile）、在Kubernetes集群中部署应用的配置文件（Template.yaml），以及定义CI/CD流水线的配置文件（Jenkinsfile）。

下面将介绍这三类文件的编写方式，并进行CI/CD流水线的发布和验证。

3.2 编写Dockerfile

项目代码分为两类，Vue.js和Java，二者的编译环境和步骤有区别，因此分开介绍。

3.2.1 前端Vue.js项目

Vue.js项目的编译和运行环境是nodejs，为了保证编译之后，在运行环境中拥有所有的依赖包，我们可以在构建镜像的过程中安装依赖包，再将项目代码打包到镜像中，形成最终的可以启动项目的镜像。

具体的制作镜像的Dockerfile文件内容如下：

3.2.2 后端Java项目

后端Java项目的编译环境是maven，编译之后将形成可以直接运行的jar包，运行环境是java，因此我们在maven环境中编译，然后将编译后的制品jar包打包到镜像中，形成最终可以穷项目的镜像。

具体的制作镜像的Dockerfile文件内容如下：

3.3 编写YAML配置模板

由于前后端项目均为无状态应用，每个项目的功能模块都可以运行多个副本，对应同一个服务，达到负载均衡和高可用的目的。因此项目模块可以采用Kubernetes中的Deployment资源来运行，对应的服务采用Service资源运行，后端项目的服务端口不需要对集群外部开放，前端项目的服务可通过Ingress等方式对外暴露端口。

因此，最终的Template.yaml根据运行应用的不同，需要配置Deployment、Service、Ingress等资源。下面是前端项目的YAML配置模板，模板中可以配置变量，比如镜像的名称版本、服务的名称等，在实际部署时将会替换为实际的值。下例中，镜像的标签中设置了一个变量：TAG_ID。

3.4 编写Jenkinsfile

Jenkinsfile中需要定义运行构建任务的agent，以及所需执行的步骤，下面是针对前端项目的Jenkinsfile文件的内容，其中的agent就是要执行构建任务的Jenkins-slave节点，stages是需要执行的构建步骤。文件中针对配置内容的说明，请参考：