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

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

3.5 配置CI/CD流水线任务

配置CI/CD流水线时，需要选择“流水线（Pipeline）”类型的任务，其中配置项目对应的代码仓库和使用的Jenkinsfile即可，具体配置方法如下：

新建任务

新建一个任务（Job），类型选择“流水线（Pipeline）”。

配置任务触发器

在“Build Triggers”中配置触发该构建任务的条件，可以配置为定时构建（轮询SCM也是定时构建），或者配置为自动触发构建。配置为Gitlab自动触发构建时，需要安装gitlab webhook插件，并需要将此处的 URL 配置到gitlab项目中的webhook中（gitlab中设置的路径为 进入项目“设置”“集成”，然后填写url，添加webhook，测试成功返回HTTP200即可）。

配置流水线

在“Pipeline”中配置本任务的流水线，因为流水线的配置文件Jenkinsfile文件是放在代码仓库中的，因此这里需要配置代码仓库的地址，并选择相应的Jenkinsfile配置文件。

下面是各个配置项的选择和填写方法：

Definition：定义，确定本次任务的流水线配置文件的方式，一种是“Pipeline Script”，即在这里直接填写Jenkinsfile的内容；一种是“Pipeline Script from SCM”，即表明Jenkinsfile是来自于代码仓库的。因为我们的Jenkinsfile是放在代码仓库中管理的，所以选择“Pipeline Script from SCM”。

SCM：源代码管理，表明代码仓库的类型，比如Git、SVN等等。

Repository URL：代码仓库地址，填写源代码的代码仓库地址，注意：执行构建任务的Jenkins-slave节点必须能够访问并从该地址下载代码。

Credentials：访问代码仓库的凭据，即登录代码仓库的用户名和密码。

Branch to Build：Git代码仓库的分支，即构建时拉取代码的分支，默认是“Master”。

Script Path：流水线脚本的路径，即Jenkinsfile的路径，该路径是相对于源代码的根目录的，假设配置文件名称为Jenkinsfile，且在源代码的最顶层，那么此处可以直接填写Jenkinsfile即可。

3.6 方案验证

在方案验证环节，需要验证的主要内容有：代码提交后是否触发Jenkins中的构建任务？构建任务执行的过程和结果是否正常？镜像仓库中是否有指定版本的镜像上传？Kubernets集群中的应用是否进行了升级？

Jenkins任务触发的验证

Jenkins中任务的触发方式有多种，比如定时轮询和代码仓库自动触发。使用代码仓库自动触发构建时，当代码仓库有代码PUSH上来时，在Jenkins中可以看到对应的任务会自动启动，且任务的上有类似“Started by GitLab push by xxx”的标识，说明该任务是由Gitlab的Push动作触发的。

监控Jenkins任务的执行过程

在Jenkins中，进入对应的任务，可以看到相关的构建历史，选择正在运行的构建，进入“控制台输出（Console Output）”，可以查看构建任务的执行日志。如果使用blueocean版本的Jenkins，可以进入blueocean中查看日志。在日志中将会看到所有的执行日志，包括agent的创建日志、每个步骤的执行日志、Docker镜像的构建过程日志、Kubernetes部署资源的日志、以及错误日志。

在构建任务执行时，可以到Kubernetes集群中，可以看到启动的Jenkins-slave POD，里面包含定义好的容器，实际的构建任务在这些容器中运行。

通常情况下，构建任务在执行的过程中，如果前面的步骤出现错误，任务将会自动跳过后续的步骤并结束。

确认镜像构建及上传到镜像仓库

当任务中的镜像构建步骤执行成功后，在Harbor镜像仓库中可以看到对应版本的镜像。

观察应用的升级过程

构建任务的最后一步通常是将应用部署到Kubernetes集群中，当任务执行成功后，在Kubernetes集群中可以看到对应的应用根据设置的升级策略在执行滚动升级，比如先停止旧的POD，再启动新的POD，新的POD使用的是新的镜像，应用正常启动后，就可以访问到新版本的应用。

四、总结

我们从业务的微服务化拆分、构建容器云管理平台、构建CI/CD发布流水线各方面介绍了传统业务的容器化改造方案。其中构建容器云管理平台、搭建私有镜像仓库、搭建私有代码仓库、部署CI/CD持续集成交付工具集均属于基础平台的构建。在此基础之上通过配置对应的CI/CD发布流水线实现了从代码提交、编译，到容器镜像的构建，再到部署到容器云管理平台，实现了业务容器化改造和部署的过程，最终达到一键式部署、一次构建打包、一次配置发布的目标，这部分属于DevOps体系的构建。

业务容器化改造时，需要围绕开发、测试和运维三个角色，构建更利于组织内部协调工作的DevOps文化，不断完善和提高企业的标准化流程，从管理层面解决容器化之后管理混乱和发布上线困难的问题。