非开发人员看Devops--从一张图谈起

Posted 2021-04-16 大魏分享

时至今日，DevDops是一个很火的概念。各大软件厂商也纷纷推出自己的DevOps解决方案。笔者并非开发出身，本文按照自己的理解、用通俗的语言，解释从敏捷开发到DevOps的相关概念，最后一部分，截取了一些测试中的图，以便读者理解。

需要声明的是，本文不代表任何厂商的官方观点。文章书写过程中，参考了RackSpace关于DevOps的介绍。

 

DevOps的历史

DevOps是什么？Dev指的development，Ops指的是的Operations，用一句话来说DevOps就是开发运维一体化，而实现敏捷开发。

 

笔者在2015年初参加过为期两天的敏捷开发的课程（忽略具体培训机构，拒绝广告），当时对敏捷开发理念如何落地一直不得其解，直到最近，参加了一些和DevOps相关的项目讨论，有了一些体会。

 

敏捷开发是由软件开发引入的。我们知道，在人类历史上，在计算机和软件业的兴起，相比于历史长河，还是很短的时间段。软件依赖于计算机硬件。计算机的出现是在1946年。在刚刚投入实际使用，往往只是为了一个特定的应用而在指定的计算机上设计和编制，采用密切依赖于计算机的机器代码或（笔者在读大学的时候学过汇编语言，相当被虐。）软件的规模比较小，文档资料通常也不存在，很少使用系统化的开发方法，设计软件往往等同于编制程序，基本上是个人设计、个人使用、个人操作、自给自足的私人化的软件生产方式。60年代中期，大容量、高速度的出现，使计算机的应用范围迅速扩大，急剧增长。因此诱发了软件危机，软件危机的本质上由于开发效率低和无序造成的。

 

那个时候的人们，对于软件开发管理还不太擅长，但是工程学是人类所擅长的，比如盖楼，盖桥等等。因此，1968年，人们将工程学的方法应用到软件领域，由此产生了软件工程。软件工程一定程度上解决了之前的软件危机，带来的后果是：重量级的瀑布开发模型，太多的文档、控制、会议。在这种模式下，客户对应用有变化的需求时，软件厂商的重新开发或者软件变更压力是很大的，但如果不变，则对影响公司在市场上的竞争力。因此，正是由于商业环境的压力，所以软件厂商需要改进开发方式。

2001年初，在美国滑雪胜地snowbird，17位专家聚集在一起，概括了一些可以让软件开发团队更具有快速工作、相应变化的能力和价值观原则。他们称自己为“敏捷联盟”。

敏捷开发的主要价值观如下：

个体和互动	高于	流程和文档
工作的软件	高于	详尽的文档
客户合作	高于	合同谈判
相应变化	高于	遵循计划

有了敏捷联盟，有了敏捷开发价值观，必然会产生开发的流派。主要的敏捷开发流派有：

极限编程（XP）、Scrum、水晶方法等。在XP流派中的12个实践中，有一种有意思的方式可能很多人听说过：结对编程。它是指两位程序员肩并肩地坐在同一台电脑前合作完成同一个设计、同一个算法以及同一段代码，并且两人的角色可以随时互换。其他的方法，由于和本文关系不是很大，不做详细介绍。

 

至此，敏捷开发有理念、有方法、有实践，似乎一些完美了。但是（凡事重点都在但是后面），随着云计算概念的兴起，IAAS的不断落地，敏捷开发是不是也应该引入工具、引入自动化呢？

 

从敏捷开发到DevOps

上面谈到了敏捷开发，那么敏捷开发和DevOps有什么关系呢？

首先敏捷开发是开发域里的概念，从敏捷开发到DevOps，需要通过如下途径完成：

持续集成（CI）==>持续交付==>持续部署==>Devops。

在四个阶段中，前一个阶段是后一个阶段的基础，随着阶段的提升，每个概念覆盖的流程越来越多，而DevOps则是终极目标。

持续集成的目的，在保证高质量的基础上，就是让产品可以快速迭代。它的核心措施是，代码集成到主干之前，必须通过自动化测试。只要有一个测试用例失败，就不能集成。

持续交付（Continuous delivery）指的是，频繁地将软件的新版本，交付给质量团队或者用户，以供评审。如果评审通过，代码就进入生产阶段。所以说，持续交付，持续交付是将持续集成产生的软件，进行自动化测试。

持续部署（continuous deployment）是持续交付的下一步，指的是代码通过评审以后，自动部署到生产环境。

持续部署的目标是，代码在任何时刻都是可部署的，可以进入生产阶段。持续部署的前提是能自动化完成测试、构建、部署等步骤。它与持续交付的区别，可以参考下图。

而DevOps则是覆盖从开发到运维的全流程，并且是自动化完成的。

DevOps带来的好处

DevOps能够带来的好处是显而易见的。

传统的软件开发流程是：PMO收集一线业务部门和客户的需求，这些需求可能是新功能需求，也可能是对产品现有功能做变更的需求。然后进行评估、分析，将这些需求，制定产品的Roadmap，并且分配相应的资源进行相关工作。PMO将需求输出给开发部门。开发工程师写代码，写好以后，就由不同的部门的人员进行后续的Build、QA、SIT、UTA，最后给生产部门。这样带来的问题是，开发周期比较长，并且如果有任何变更，都要重新走一遍开发流程，在商场如战场的今天，软件一个版本推迟一年发布，可能到时候这个版本在发布的时候在市场上就已经OUT了。而DevOps的目的在于让开发和运维一体化，这样两者相互沟顺畅、迅捷，更能适应市场的变化。

 

没有DevOps，开发人员的工作状态是这样的：

运维人员的工作状态是这样工作的：

开发和运维的沟通则是这样的(隔墙扔板砖)：

有了DevOps以后，开发和运维是这样工作的：

而真正实现开发运维一体化是关键是：让开发环境=生产环境，最终实现开发运维一体化，并非只是让开发和运维的人坐在一起那么简单。这里面关键是要有一个包含了操作系统+Runtime+应用的标准交付物。如果开发交付给运维的还是一些war包，运维人员拿到code以后，再去部署操作系统和Runtime，安装软件包，那么他们仍然处于上图展示的“隔着墙扔板砖”的局面。

那么，通过什么技术实现打包呢？我们知道，虚拟化技术（VM）实现了操作系统对硬件的解耦，如果通过VM方式打包，显然太重了（还有其他问题，这里不再具体展开）。而这个时候，docker被派上用场了。

 

 

至此，通过docker的镜像打包技术，加上DevOps的理念和方法论，也就是，我们有了新的理念，新的技术，似乎一切又完美了？不对，还缺点东西。

 

我们还缺Devops工具，准确地说，是解决方案。

 

红帽的DevOps解决方案

红帽针对DevOps的解决方案是OpenShift。我之前的文章《同时面向运维和开发的企业级PaaS平台--OpenShift》已经对它的架构以及面向运维（容器云）的功能做了介绍。本次将介绍它面向运维的功能：DevOps。

OpenShift实现DevOps的第一步是要解决Build的问题。Build是软件开发中的一个环节，从字面解释是将输入参数转换为结果对象的过程。常见的就是将源代码转换为可运行的镜像。Build有多重方式，OpenShift推荐使用S2I（Source to Image）的方式。

使用S2I，开发者写的代码，经过一系列自动化/手动化测试以后，最终交付给生产的是，可直接运行的镜像。S2I依赖的镜像打包就是就是Docker。

上图描述的是一个S2I的场景：一个/多个开发人员，提交完代码(新代码或者代码变更)以后，（步骤1）SCM识别到，准备触发build（步骤2）获取registry中的JBOSS基础镜像，将源代码导入到jboss基础镜像。（步骤3）S2I调用maven打包进行build和测试应用，测通过后，将新的镜像存放到另外一个registry中，触发升级（需要用户自己配置触发时机和触发动作）

S2I也可以对接Jenins等开源工具来做。下图展示的是在Jenins创建Maven项目。SI2与Jenins的对接是在集成测试阶段，也就是步骤3.

下图展示的是，当S2I与Jenins集成以后，当代码发生了变更，会自动触发build：

至此，笔者完成了从敏捷开发到DevOps相关概念的介绍。OpenShift作为优秀的解决，即可实现DevOps。

总结：

笔者在之前的文章中，曾经介绍过红帽的混合云解决方案，CloudForms。CloudForms除了可以管理虚拟化平台，如RHEV,vSphere，还可以管理OpenStack以及OpenShift，也就是说，通过CloudForms,您可以实现横跨IAAS和PAAS层面的混合云统一解决方案。