DevOps&CICD

DevOps、CI/CD

DevOps

DevOps起源

我们知道,一个软件从零开始到最终交付,大概包括以下几个阶段:规划、编码、构建、测试、发布、部署和维护。

最初,程序比较简单,工作量不大,程序员一个人可以完成所有阶段的工作。随着软件产业的日益发展壮大,软件的规模也在逐渐变得庞大。软件的复杂度不断攀升。一个人已经hold不住了,就开始出现了精细化分工。除了软件开发工程师之外,又有了软件测试工程师,软件运维工程师。

分工之后,传统的软件开发流程是这样的:软件开发人员花费数周和数月编写代码,然后将代码交给QA(质量保障)团队进行测试,然后将最终的发布版交给运维团队去部署。所有的这三个阶段,即开发,测试,部署

早期所采用的软件交付模型,称之为瀑布(Waterfall)模型

1
2
3
4
5
- 需求
- 设计
- 开发
- 测试
- 部署

瀑布模型就是等一个阶段所有工作完成之后,再进入下一个阶段

这种模型适合条件比较理想化(用户需求非常明确、开发时间非常充足)的项目。大家按部就班,轮流执行自己的职责即可。

随着时间推移,用户对系统的需求不断增加,与此同时,用户给的时间周期却越来越少。在这个情况下,大家发现,笨重迟缓的瀑布式开发已经不合时宜了。

于是,软件开发团队引入了一个新的概念,那就是大名鼎鼎的——敏捷开发(Agile Development)

1
2
瀑布开发:设计--开发-------------------------测试------部署--
敏捷开发:设计--开发---测试---开发---测试---开发---测试---部署--

敏捷开发大幅提高了开发团队的工作效率,让版本的更新速度变得更快。

很多人可能会觉得,“更新版本的速度快了,风险不是更大了吗?”

其实,事实并非如此。敏捷开发可以帮助更快地发现问题,产品被更快地交付到用户手中,团队可以更快地得到用户的反馈,从而进行更快地响应。而且,敏捷开发小步快跑的形式带来的版本变化是比较小的,风险会更小。即使出现问题,修复起来也会相对容易一些。

虽然敏捷开发大幅提升了软件开发的效率和版本更新的速度,但是它的效果仅限于开发环节。研发们发现,运维那边,依旧是铁板一块,成为了新的瓶颈。

运维工程师,和开发工程师有着完全不同的思维逻辑。运维团队的座右铭,很简单,就是“稳定压倒一切”。运维的核心诉求,就是不出问题

什么情况下最容易出问题?发生改变的时候最容易出问题。所以说,运维非常排斥“改变”

传统开发经常碰到的问题

在传统开发周期中,开发团队将新发布的软件“隔墙扔给”运维人员,意味着自己的工作已经顺利完成。

运维人员接手开发者的成果,准备开始进行部署。运维人员手工修改由开发者提供的部署脚本,当然更多时候这些脚本都是运维人员自己维护的。

运维人员还需要手工修改配置文件,以反映生产环境的需求,而生产环境往往与开发或 QA环境有很大差异。

就算最理想的情况,运维人员可能只是做了一些在上一个环境中已经做过的重复工作,而最糟糕的情况,可能会引入或发现新的 Bug。

随后 IT 运维团队开始讨论他们所认为的,目前最正确的部署流程,然而由于开发和运维在脚本、配置、流程,甚至环境等方面的差异,基本上等同于要从零开始将所有工作重新执行一遍。

当然这一过程中不可避免会遇到问题,他们联系开发者希望进行排错。运维称开发者提供的代码本身有问题,开发者则回应称代码在自己的环境中一切正常,因此错误肯定源自运维端。

由于配置、文件位置,以及面临这种状态所执行的操作与自己的预期等因素存在较大差异,开发者甚至很难对这样的问题进行诊断。变更窗口留下的时间所剩无几,当然也没什么足够靠谱的方法将环境回滚至上一个正常状态。

那么原本应该一帆风顺的部署过程,为什么最后却变成了“众志成城”的应急演习?必须经历大量指责和错误才能最终让生产环境恢复可用状态?

这个时候,我们的DevOps,隆重登场了。

DevOps到底是什么

DevOps是一组过程、方法与系统的统称,用于促进开发、技术运营和质量保障(QA)部门之间的沟通、协作与整合。DevOps通过自动化完成“软件交付”和“架构变更”流程,来更加快捷、频繁和可靠地构建、测试、发布软件

对比前面所说的瀑布式开发和敏捷开发,我们可以明显看出,DevOps贯穿了软件全生命周期,而不仅限于开发阶段。

1
2
3
瀑布开发:设计--开发-------------------------测试------部署--
敏捷开发:设计--开发---测试---开发---测试---开发---测试---部署--
DevOps:设计--开发--测试--部署--开发--测试--部署--开发--测试--部署--

CI/CD

敏捷开发和DevOps是更好更快发布产品的常用的两种理念,而CI和CD是实现这两种理念的一种方法。他们之际的关系可以粗暴的用下图表示:

CI(持续集成)

CI是Continuous integration的简称,持续集成指频繁地(一天多次)将代码集成到主干,其实就是将编码、代码的编译、打包、单元测试执行、静态代码的分析,甚至包括自动化的功能性测试等,这一套动作将其自动化运行起来的过程叫持续集成。核心措施是,代码集成到主干之前,必须通过自动化测试。只要有一个测试用例失败,就不能集成。CI的目得是让产品可以快速迭代,同时还能保持高质量。

优势:

  1. 快速发现错误。每完成一点更新,就集成到主干,可以快速发现错误,定位错误也比较容易。
  2. 防止分支大幅偏离主干。如果不是经常集成,主干又在不断更新,会导致以后集成的难度变大,甚至难以集成。

CD(持续交付/持续部署)

CD包括Continuous Delivery(持续交付)和Continuous Deployment(持续部署)

Continuous Delivery(持续交付)

持续交付可以看作持续集成的下一步,指频繁地将软件的新版本,交付给质量团队或者用户,以供评审,如果评审通过代码进入待生产部署状态,也就是说不管怎么更新,软件具备随时交付到生产环境的能力,但还没有真正部署到生产。

Continuous Deployment(持续部署)

持续部署是持续交付的下一步,指代码通过评审以后可自动部署到生产环境,也就是说代码具备随时部署到生产的能力。持续部署的前提是能自动化完成测试、构建、部署等步骤。持续部署是自动,持续部署是持续交付的最高阶段

Docker、Kubernetes的CI/CD实现思路

客户端将代码push推送到Git仓库,GitLab上配置了一个WebHook的东西可以触发Jenkins的构建。进入到Jenkins虚线范围内,它所做的事情非常多,从mvn构建代码,对代码进行静态分析,做单元测试,测试通过之后就可以build镜像,镜像构建成功后就把镜像push推送到Harbor镜像仓库中,镜像push推送到镜像仓库后,我们就可以调用kubernetes集群的restAPI更新服务,而后kubernetes接收到了更新的指令,从Harbor镜像仓库pull拉取镜像,从而完成服务的更新与重启,最后我们从客户端来访问kubernetes集群的服务。

  1. 开发从镜像库里获取基础镜像,对应用进行容器化开发

  2. 开发提交代码到GitLab(在Kubernetes中实现GitLab服务,并通过持久化存储保存用户数据)

  3. GitLab收到代码提交请求后通过webhook触发Jenkins master

  4. Jenkins master收到请求后在slave节点中对源码进行打包

  5. 在源码打包完成后根据流水线,从GitLab中获取dockerfile,在slave节点中生成docker images

  6. Docker镜像生成之后上传到Docker 私有仓库harbor

  7. 通过Jenkins流水线在Kubernetes测试环境拉取镜像,部署应用

  8. 测试成功之后,通过Jenkins流水线在Kubernetes生产环境进行应用的部署上线

参考


----------- 本文结束啦感谢您阅读 -----------

赞赏一杯咖啡

欢迎关注我的其它发布渠道