大家好，我来自希云cSphere，今天给大家分享的主题:“容器是DevOps的必由之路”——“标准化带来DevOps”。
谈到DevOps话题特别大，我从容器的角度给大家分享一下，为什么容器是DevOps的必有之路。
首先简单介绍我自己，我比较遵守“恪守契约精神，务实开放合作”的精神，同时这也是希云cSphere的公司文化。我从2013年开始接触到Docker技术，并且有幸加入到希云cSphere这家专门为企业客户提供容器云平台的公司。在近3年时间，我一直在为企业提供容器云解决方案。今天我和大家分享一下什么是创造力，提到这个词大家会想到飘忽不定。人的大脑思维状态大致有两种：一种是专注状态，这种状态下的大脑模式被称为“Executive Network”，执行网络，,简称EN。另一种是放空状态，相应开启的是“Default Network”，默认网络，简称DN。专注模式我们比较熟悉，我们在学校接受教育主要训练的就是EN，它是大脑中靠近前侧头盖骨的区域，能助你专注和完成任务。但是光靠EN是不能产生创造力的，还需要一个能帮助我们放空的网络DN，它是我们突破性想法的聚集地，但是很多时候我们并意识不到它的存在。
那么一个伟大的创造中，EN和DN如何协同工作?根据神经研究表明，如果说EN帮助你专注和完成一件事，那DN则是帮助你从更高的角度纵观事情的复杂程度，透视全局。所有我们需要同时具备开启两种模式的能力，而且能在它们之间自由切换。
我之所以和大家分享什么是创造力，主要是想说明现在随着企业业务的迅速发展，IT系统也要能及时响应业务的需求。我们需要一种全新的思维、全新的方法来构建企业的IT系统。
DevOps主要用于开发、测试以及运维之间的协作管理，并且通过自动化流程，更加快捷、频繁、易重复且可靠的构建软件、测试及发布部署。
在容器没有出现之前也有DevOps，并且发展了这么多年，企业常用的做法是通过自动化脚本去实现配置引擎，例如：Puppet、Chef、Ansible等工具。基于以上工具来实践DevOps，为什么没有使得DevOps发展起来，而且在企业中落地艰难。其中第一个原因包括是脚本缺陷。主要体现在：人员强依赖：比如这个脚本是我写的，另外一同事不一定能把这个脚本用起来;不具备收敛：发现问题，首先要使问题收敛，目前使用的方法是不具备收敛的;非标准：不同人脚本的写法是不一样的，但实现的结果都一样;不具备回退：没有做版本管理。讲到版本管理，我们的代码都有版本管理，但是我们的代码的运行环境，这个环境是没有做过版本管理的，所以回退操作难度高;第二个原因是配置引擎的缺陷，像DSL语言，使用门槛太高。解耦也不够，特定的人去特定的事，如果这个人因为生病了或者请假了，这个发布就会终止。这些问题都导致了DevOps无法在企业落地。
给大家分享一个客户实践DevOps失败后的案例这位客户是个国企。对于国企来说，招人难度很高，很难招到技术特别高的人才，而且他们也想要通过DevOps这个技术实现增长，难度也就比较大。另外开发和运营分裂，系统开发是第三方厂商，真正运营的时候是自己在运营。两团队不在同一个公司，要让开发掌握这些工具，难度更大。而且开发根本不关心底层的机器是什么，他们说尽可能不让我们看到机器好，这他们真正的诉求。说白了，为什么DevOps这么难落地，就是在企业中很难形成从开发到测试再到生产的统一的一致性的流水线工作。
接下来给大家说说容器是什么，在这里我可以肯定地告诉大家，容器不是虚拟机。大家可以从PPT上看到容器、虚拟机、物理机的对比。容器到底是什么，先来看第一张图，物理机和容器，物理机安装OS，在安装Docker引擎，然后容器就可以运行在物理机中了;第二张图，物理机之上运行虚拟机，然后容器运行在虚拟机之上，这种架构，我们看到它有两个OS，一个OS是物理机的，一个是虚拟机的，然后上面才是容器;第三张图，不知道大家有没有想过，容器就是一个进程，对于KVM虚拟机其实在容器来看，它也只是一个进程而已，所以可以把一个虚机跑到一个容器里。重点说一下第三张图，容器运行在虚拟机下层，容器是直接跑到裸机里的。说到这里大家会问，容器到底跑虚机好还是跑裸机好，回答这个问题主要从2个方面来考虑，因为容器技术也有限制，比如我们的业务系统，多个系统之间对安全性没有特别强的需求，此时可以跑裸机里面;如果隔离性是强需求，那么推荐运行到虚拟机中，使用虚拟机来做彻底地隔离，容器是没法实现多租户的。容器是增强版的进程，我们来看传统的Linux，如我们去装系统或者装软件，都通过RPM包，容器是使用镜像来安装，`yum -y install` 后会安装很多包，包与包之间的依赖关系复杂，很难一眼看出是谁依赖谁。对于传统的Linux是一个普通的进程，所有的程序、所有的进程是在同一个平面上，通过容器相当于给每个进程都做了一个"箱子"，虽然“容器”都是运行在操作系统中，但彼此之间相互做了隔离。
容器镜像的一个机制-COW，大家比较熟，我就不多说了。大家比较关注的是容器的性能，这个测试报表是基于IBM服务器机器做的，可以看到物理机和容器性能之间是基本一致，无损耗，但虚拟机损耗大约在50%，损耗比较大。
为什么说容器技术恰恰能克服这些阻力呢。第一，开发使用简单，因为在开发的时候不需要关注这个机器还有运行环境是什么，而能更加清晰的规划开发和运维的界面。第二、抽象层次足够高，解耦彻底，而且容器是行业通用的标准，DevOps发展那么多年，为什么说它没有流行起来，比如说刚才提到实现DevOpsd平台多种技术多种工具，这些工具的标准搬到其他的公司它未必适用，不同公司的文化也不一样。容器标准的生命力特别强，容器可以让DevOps普及发展以及流行，并且走出阴霾，证明DevOps的先进性，也确实是可以落地的。
那么容器在开发领域是怎么样的流程呢。如果是银行的朋友就会知道服务目录，我们称作应用商店，开发可以从应用商店中选择所需的环境。通过编排做交付，容器编排功能决定是不是可以把非常复杂的系统编排起来，实现整体交付。前不久我们给客户做POC的时候，客户给了一个微服务，27个服务整个编排仅用了2个小时左右，而且无需对镜像做修改，就实现了一键部署。环境部署完后，开发就可以专心写代码了，代码提交到代码仓库，触发Jenkins构建，构建完成后自动部署应用。对于测试来说也特别简单，可以基于版本库进行一键部署，应用模板加镜像包括了代码、运行环境、和配置信息，测试环境同样是整体交付。大家从PPT上可以看到基于容器建设的整个DevOps的流程，包括从提交代码到Jenkins构建镜像，再到应用部署。有容器可以不安装Jenkins Salve节点，只要这台机器装了Docker就可以作为构建机器。实践推荐可以专门找两台主机做构建，构建完后上传到镜像仓库，构建任务多的话，多配置几台服务器就行。多环境之间交付，如：测试环境、生产环境、UAT环境，每个环境之间会有不同，不同是指配置参数的值不同，而底层环境和代码版本要一致，保证多环境之间的一致性，这也是容器的价值。
为什么说其他技术路线为什么会必然失败。刚才我提到了，之前的标准都是小标准，个别企业的标准不一定代表着行业的标准，PPT中的这张图是一个快递的箱子，收快递的人很难判断我是骑个车还是开个货车去呢?很难统一做考量。另外，小标准的生命力非常弱，难推广。现在通过容器，就像集装箱，我们可以知道原先的码头有好多人力在去背麻袋，在装货、卸货，但是发现这种效率是极低的，而且出问题也比较多。集装箱出现后整个运输行业做到了标准化、自动化。
DevOps有一个很强的需求，更小、更频繁的变更。没有容器的话，应用变更很难，如：1.构建环境不确定，比如我这一次的构建也许会用了上一次构建失败的库，所以导致这一次构建也失败。2.DSL语言编写起来特别麻烦，在2015年的时候遇到一个银行的客户，问我Puppet如果升级的话有没有什么风险，市面上是否有Puppet的大牛能做技术顾问。3.发布结果不一致，在不同的时间点，因为网络的因素或者其他因素，要么是全部失败，要么是全部成功。4.回滚周期长。
有容器的话，1.构建环境首先是确定的，因为容器是一个集装箱，把所有东西都包起来了。2.可视化操作，门槛特别低。3.发布结果一致，就好比把上海的集装箱拉到北京，只要箱子在，里面的东西就自然会在。4.周期短、秒级回滚。
DevOps的又一个需求，让开发人员尽可能的去控制生产环境，当然这个控制是有限度的控制，包括可视化的操作，要有操作审计功能等，任何一个人做了什么操作，实现的结果，都会有记录，最后是可视化的查询。没有容器怎么来控制，控制力度难控制，命令行操作，依赖外部系统，系管理系统分散，有些其他的运维平台是只监不控，对企业来说，其实维护这么多系统也非常麻烦，同样希望能一套系统又可以监控又可以管理。使用容器的优点，细力度的授权，可以开放给开发，全都是可视化的操作，简化了开发使用的门槛。精密审计，记录了增删改等操作。高度集成，一套平台可以做到监控和管控。
以应用程序为中心，来理解基础设施。代码会依赖配置文件、依赖操作系统、依赖其他的外部系统等。依赖程序非常难管，开发人员手动修改，但是没有及时记录到文档或者是其他系统中;配置管理与代码是分离的，尤其是配置文件;依赖的修改会比较复杂，速度比较慢即使是虚拟机或puppet。基础设施管理复杂度比较高，经常的变更会导致系统已经不一样了，还要同时管理不同版本的操作系统。容器作为应用的基础设施，首先有一个概念“镜像”，镜像包含了应用代码以及依赖的运行环境，可通过Dockerfile文件进行描述，同代码一起管理。变更更快速，pull镜像start容器，主机上只要运行一个容器引擎就可以了，基本上不用做变更，而且对操作系统是弱依依赖的。
定义简单明了的流程。以前的方案流程复杂，不同类型应用的程序、项目组的项目，都会有不同的部署、升级回滚流程，这个复杂度是比较高的。开发人员对代码、架构的调整，都会导致运维人员做出很多相应配置变更的工作。这是一个博弈的过程，开发要求变化，运维追求的是稳定。
接下来分享一个基于容器实践DevOps的案例。总目标有2个，第一个如何用容器克服第三方开发商和企业IT管理之间的协作，系统开发涉及到开发厂商，包括北京的研发和广州的研发，不改变已有开发习惯，代码写完后提交到GitLab就可以。Jenkins构建出来的镜像都push到中央镜像仓库，基于cSphere平台的应用编排，将寿险业务编排起来，实现业务的部署、升级及版本回退。基于容器建设整个DevOps流水线，我们已经在不同行业，不同客户的IT环境中实践过了，这几年以来，为什么能在企业中基于容器实践DevOps能成功，很重要的一点就是容器是行业标准，并且结合希云cSphere容器平台降低了使用门槛，和推广难度。
最后我们看一下客户效果收益，标准化第三方开发商交付物，所有的人员都必须通过镜像来作为交付物，对于中英运营人员标准统一进行部署和管理。2个月完成2个应用的开发、测试、上线。服务器资源提升70%、交付时间缩短60%以上，整体工作效率提升80%，包括第三方开发厂商还有甲方。
我今天分享的主题是容器是DevOps的必由之路，根据近几年项目实践，我相信，未来容器是DevOps的必由之路。今天时间有限，就不与大家一一交流了，如有其它问题可以随时与我联系，谢谢大家。
热门专题
