#云原生征文# 持续集成CI/CD之CD的完整版最佳实践 原创 精华
CI&CD解读
概述
CI/CD 是一种通过在应用开发阶段引入自动化来频繁向客户交付应用的方法。CI/CD 的核心概念是持续集成、持续交付和持续部署。作为一个面向开发和运营团队的解决方案,CI/CD 主要针对在集成新代码时所引发的问题(亦称:“集成地狱”)。
具体而言,CI/CD 可让持续自动化和持续监控贯穿于应用的整个生命周期(从集成和测试阶段,到交付和部署)。这些关联的事务通常被统称为"CI/CD 管道",由开发和运维团队以敏捷方式协同支持。
CI 是什么?CI 和 CD 有什么区别?
缩略词 CI / CD 具有几个不同的含义。CI/CD 中的"CI"始终指持续集成,它属于开发人员的自动化流程。成功的 CI 意味着应用代码的新更改会定期构建、测试并合并到共享存储库中。该解决方案可以解决在一次开发中有太多应用分支,从而导致相互冲突的问题。
CI/CD 中的"CD"指的是持续交付和/或持续部署,这些相关概念有时会交叉使用。两者都事关管道后续阶段的自动化,但它们有时也会单独使用,用于说明自动化程度。
持续交付通常是指开发人员对应用的更改会自动进行错误测试并上传到存储库(如 GitHub 或容器注册表),然后由运维团队将其部署到实时生产环境中。这旨在解决开发和运维团队之间可见性及沟通较差的问题。因此,持续交付的目的就是确保尽可能减少部署新代码时所需的工作量。
持续部署(另一种"CD")指的是自动将开发人员的更改从存储库发布到生产环境,以供客户使用。它主要为了解决因手动流程降低应用交付速度,从而使运维团队超负荷的问题。持续部署以持续交付的优势为根基,实现了管道后续阶段的自动化。
CI/CD 既可能仅指持续集成和持续交付构成的关联环节,也可以指持续集成、持续交付和持续部署这三项构成的关联环节。更为复杂的是,有时"持续交付"也包含了持续部署流程。
归根结底,我们没必要纠结于这些语义,您只需记得 CI/CD 其实就是一个流程(通常形象地表述为管道),用于实现应用开发中的高度持续自动化和持续监控。因案例而异,该术语的具体含义取决于 CI/CD 管道的自动化程度。许多企业最开始先添加 CI,然后逐步实现交付和部署的自动化(例如作为云原生应用的一部分)。
CI 持续集成(Continuous Integration)
现代应用开发的目标是让多位开发人员同时处理同一应用的不同功能。但是,如果企业安排在一天内将所有分支源代码合并在一起(称为"合并日"),最终可能造成工作繁琐、耗时,而且需要手动完成。这是因为当一位独立工作的开发人员对应用进行更改时,有可能会与其他开发人员同时进行的更改发生冲突。如果每个开发人员都自定义自己的本地集成开发环境(IDE),而不是让团队就一个基于云的 IDE 达成一致,那么就会让问题更加雪上加霜。
持续集成(CI)可以帮助开发人员更加频繁地(有时甚至每天)将代码更改合并到共享分支或"主干"中。一旦开发人员对应用所做的更改被合并,系统就会通过自动构建应用并运行不同级别的自动化测试(通常是单元测试和集成测试)来验证这些更改,确保这些更改没有对应用造成破坏。这意味着测试内容涵盖了从类和函数到构成整个应用的不同模块。如果自动化测试发现新代码和现有代码之间存在冲突,CI 可以更加轻松地快速修复这些错误。
CD 持续交付(Continuous Delivery)
完成 CI 中构建及单元测试和集成测试的自动化流程后,持续交付可自动将已验证的代码发布到存储库。为了实现高效的持续交付流程,务必要确保 CI 已内置于开发管道。持续交付的目标是拥有一个可随时部署到生产环境的代码库。
在持续交付中,每个阶段(从代码更改的合并,到生产就绪型构建版本的交付)都涉及测试自动化和代码发布自动化。在流程结束时,运维团队可以快速、轻松地将应用部署到生产环境中。
CD 持续部署(Continuous Deployment)
对于一个成熟的 CI/CD 管道来说,最后的阶段是持续部署。作为持续交付——自动将生产就绪型构建版本发布到代码存储库——的延伸,持续部署可以自动将应用发布到生产环境。由于在生产之前的管道阶段没有手动门控,因此持续部署在很大程度上都得依赖精心设计的测试自动化。
实际上,持续部署意味着开发人员对应用的更改在编写后的几分钟内就能生效(假设它通过了自动化测试)。这更加便于持续接收和整合用户反馈。总而言之,所有这些 CI/CD 的关联步骤都有助于降低应用的部署风险,因此更便于以小件的方式(而非一次性)发布对应用的更改。不过,由于还需要编写自动化测试以适应 CI/CD 管道中的各种测试和发布阶段,因此前期投资还是会很大。
CI&CD集成流程
架构流程设计
(1)制品库制作;(2)提交部署服务与版本;(3)选择服务部署;(4)查看服务情况;
gitlab-ci构建制品库
制作制品库,使用了gitlab自带的CI/CD,代码编译与镜像制作都使用容器环境构建。
java制品库模板
本模板所有编译都采用容器环境,适用于父子结构的java工程;工程结构如下
运行CI之前,需要在代码库组的CI/CD参数中需要设置CI_REGISTRY
:docker仓库地址;CI_REGISTRY_USER
:docker仓库账号; CI_REGISTRY_PASSWORD
:docker仓库password;CI_NAME_SPACE
:镜像的仓库路径[项目名称空间];CI_MAVEN_REPO
:maven本地仓库路径;CI_SETTING
文件类型maven的setting.xml
参数说明
MODULES
:是子模块列表以“,”隔开
MODULE_PREFIX
:用于更正子模块名称不带前缀情况。
运行结果如图
vue制品库模板
本模板所有编译都采用容器环境,适用于vue工程;工程结构如下
运行CI之前,需要在代码库组的CI/CD参数中需要设置CI_REGISTRY
:docker仓库地址;CI_REGISTRY_USER
:docker仓库账号; CI_REGISTRY_PASSWORD
:docker仓库password;CI_NAME_SPACE
:镜像的仓库路径[项目名称空间];
运行结果如图
服务部署列表与版本跟踪
因为需要发布到生产环境,需要跟踪发布的过程,本实践采用git来跟踪脚本。
本jenkins部署脚本时将成品的docker镜像,通过jenkins直接发布到k8s环境测试或者生产环境。使用git地址存储编写的jenkinsfile脚本,利用git与jenkins自身的功能完成发版的可追溯、可回滚等等
采用jenkins-pipeline的声明式部署,部署都使用容器化,不依赖主机。相关的文件都使用jenkins系统变量、凭证配置。
部署发版的工程结构如下
部署yaml文件
模板部分参数占位符说明:
__NAME_SPACE__
: 部署空间占位符;
__DOMAIN_NAME__
:部署服务名称占位符;
__REPLICAS_NUM__
:部署实例数量占位符;
__DOCKER_IMAGE__
:docker镜像地址占位符;
java部署模板k8s-java.yaml
vue部署模板k8s-vue.yaml
版本定义文件
version-app.sh定义部署服务的列表、版本、实例、内存使用、服务类型等等
可以操作以下案例定义
Jenkins部署文件
本文件以部署到k8s为例,只有一个步骤。
jenkins构建部署
jenkins任务创建
-
选择新建任务
-
输入一个任务名称:[脚本工程名称] -->选择流水线–>确定
-
丢弃旧的构建–>保持构建的天数:[7]–>保持构建的最大个数:[7]
-
选择参数化构建–>添加active choices parameter -->名称:[project] -->Groovy Script
-
选择参数化构建–>添加Active Choices Reactive parameters -->名称:[modules] -->–>Choice Type: [Check Boxes]–>Referenced parameters:[project]
Script
Groovy Script:
如图
- 流水线–>定义:[pipeline script from SCM] -->SCM:[git]–>Repository URL:[工程的git地址]–>Credentials:[访问git的账号password] --> 指定分支(为空时代表any): --> 脚本路径:[Jenkinsfile文件路径,Jenkinsfile]
注意:新建任务前,需要将Jenkinsfile文件注释的前3点,在jenkins系统中配置好。
jenkins版本发布
具体步骤如下
-
点击进入任务(上节创建的任务)
-
点击Build with Parameters
-
project参数:选择发布服务分类
-
modules:参数选择需要发布的具体服务
-
点击开始构建
部署环境运维操作
上述版本发布后,查看服务的具体情况需要使用运维管理工具进行查看,以k8s为例,我们选择rancher进行服务查看等
查看部署的服务
查看日志
重启服务
进入容器
【本文正在参加云原生有奖征文活动】,活动链接:https://ost.51cto.com/posts/12598
大神,请继续分享干货
干货满满,学习了
很不错,赞起!