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组版本都已经升级完成，并且都对外提供服务。

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