Devops的概念

1、什么是DevOps?

答:DevOps是产品开发过程中开发(Dev)和运营(Ops)团队之间的灰色区域。DevOps是一种在产品开发周期中强调沟通,集成和协作的文化。因此,它消除了软件开发团队和运营团队之间的孤岛,使他们能够快速,连续地集成和部署产品。

DevOps 就是开发(Development)、测试(QA)、运维(Operations)这三个领域的合并。DevOps是一种软件开发方法,涉及软件在整个开发生命周期中的持续开发,持续测试,持续集成,持续部署和持续监控。
编码——》打包——》测试——》发布——》部署——》运维——》监控

2、什么是持续集成?

答:持续集成(Continuous integration,缩写为CI)是一种软件开发实践,团队开发成员经常继承他们的工作。利用自动测试来验证并断言其代码不会与现有代码库产生冲突。 理想情况下,代码更改应该每天在CI工具的帮助下,在每次提交时进行自动化构建(包括编译,发布,自动化测试),从而尽早地发现继承错误,以确保合并的代码没有破坏主分支。

3、什么是持续交付

答:持续交付(Continuous delivery,缩写为CD)以及持续集成为交付代码包提供了完整的流程。在此阶段,将使用自动化构建工具来编译工件,并使其准备好交付给最终用户。它的目标在于让软件的构建、测试与发布变得更快以及更频繁。这种方式可以减少软件开发的成本与时间,减少风险。

4、什么是持续部署

答:持续部署(Continuous deployment)是通过集成新的代码更改并将其自动交付到发布分支,从而将持续交付提升到一个新的水平。更具体地说,一旦更新通过了生产流程的所有阶段,便将它们直接部署到最终用户,而无需人工干预。因此,要成功利用连续部署,软件工件必须先经过严格建立的自动化测试和工具,然后才能部署到生产环境中。

  • 好处:通过持续部署,开发人员可以完全专注于产品,因为他们在管道中的最后任务是审查拉取请求并将其合并到分支。通过在自动测试后立即发布新功能和修复,此方法可实现快速部署并缩短部署持续时间。

5、实施DevOps的原因

(1)Devops为什么重要?Devops如何使团队在软件交付方面受益?
答:在当今的数字化世界中,组织必须重塑其产品部署系统,灵活。Devops在为整个软件开发管道(从构思到部署,再到最终用户)产生移动性和敏捷性方面发挥着至关重要的作用。Devops是将不断更新和改进产品的更简化,更高效的流程整合在一起的解决方案。

(2)解释Devops对开发人员有何帮助?
答:在没有DevOps的世界中,开发人员的工作流程将首先建立新代码,交付并集成它们,然后,操作团队有责任打包和部署代码。之后,他们将不得不等待反馈。而且如果出现问题,由于错误,他们将不得不重新执行一次,在项目中涉及的不同团队之间的无数手动沟通。

由于CI/CD实践已经合并自动化了其余任务,因此应用Devops可以将开发人员的任务简化为仅构建代码。随着流程变得更加透明并且所有团队成员都可以访问,将工程团队和运营团队相结合有助于建立更好的沟通和协作。

(3)简而言之,精心规划和执行良好的CI/CD管道可以加快发布速度和可靠性,同时减轻产品的代码更改和缺陷。这最终将导致更高的客户满意度。

6、如何有效实施DevOps

定义典型的DevOps的工作流程,典型的DevOps工作流程可以简化4个阶段:

  • 版本控制:这是存储和管理源代码的阶段。版本控件包含代码的不同版本
  • 持续集成:在这一步中,开发人员开始构建组件,并对其进行编译,验证,然后通过代码审查,单元测试和集成测试进行测试。
  • 持续交付:这是持续集成的下一个层次,其中发布和测试过程是完全自动化的。CD确保将新版本快速,可持续地交付给最终用户。
  • 持续部署:应用程序成功通过所有测试要求后,将自动部署到生产服务器上以进行发布,而无需任何人工干预。

7、DevOps使用哪些工具?

持续开发:Git、SVN、Mercurial、CVS、Jira
持续整合:Jenkins、Bamboo、CircleCI
持续交付:Nexus、Archiva、Tomcat
持续部署:Puppet、Chef、Docker
持续监控:Splunk、ELK Stack、Nagios
持续测试:Selenium、Katalon Studio

在这里插入图片描述
由客户端将代码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

代码变更→触发jenkins build→拉取代码到jenkins节点→mvn打war包→测试→dockerfile打成镜像→docker tag →docker push到harbor → k8s部署

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

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

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

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

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

8、发布应用场景

发布应用场景:

  • 蓝绿发布:两套环境交替升级,旧版本保留一定时间便于回滚。

  • 灰度发布:根据比例将老版本升级,例如80%用户访问是老版本,20%用户访问是新版本。

  • 滚动发布:按批次停止老版本实例,启动新版本实例。

  • 蓝绿发布:
    项目逻辑上分为AB组,在项目系统时,首先把A组从负载均衡中摘除,进行新版本的部署。B组仍然继续提供服务。
    当A组升级完毕,负载均衡重新接入A组,再把B组从负载列表中摘除,进行新版本的部署。A组重新提供服务。
    最后,B组也升级完成,负载均衡重新接入B组,此时,AB组版本都已经升级完成,并且都对外提供服务。

  • 灰度发布:
    灰度发布只升级部分服务,即让一部分用户继续用老版本,一部分用户开始用新版本,如果用户对新版本没什么意见,那么逐步扩大范围,把所有用户都迁移到新版本上面来。

本图文内容来源于网友网络收集整理提供,作为学习参考使用,版权属于原作者。
THE END
分享
二维码
< <上一篇
下一篇>>