Devops的概念

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

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

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

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

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

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

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

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

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

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

定义典型的DevOps的工作流程&＃xff0c;典型的DevOps工作流程可以简化4个阶段&＃xff1a;

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

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

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

1.开发从镜像库里获取基础镜像&＃xff0c;对应用进行容器化开发&＃xff1b;

2.开发提交代码到Gitlab&＃xff08;在Kubernetes中实现Gitlab服务&＃xff0c;并通过持久化存储保存用户数据&＃xff09;&＃xff1b;

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

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

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

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

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

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

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

发布应用场景&＃xff1a;

• 蓝绿发布&＃xff1a;两套环境交替升级&＃xff0c;旧版本保留一定时间便于回滚。

• 灰度发布&＃xff1a;根据比例将老版本升级&＃xff0c;例如80%用户访问是老版本&＃xff0c;20%用户访问是新版本。

• 滚动发布&＃xff1a;按批次停止老版本实例&＃xff0c;启动新版本实例。

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

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