云原生下的DevOps与持续交付

课程概要
2009年，一场演讲在O’Reilly Velocity大会上一炮而红，演讲中有一句话深得人心：“由于开发和运维需要在Flickr（一个图片存储和视频托管网站）上合作，这导致开发者每天至少得进行十次部署。”演讲结束后，“DevOps之父”Patrick Debois受该演讲启发，在比利时发起一场名为DevOps之日的运动，号召开发和运维们，应该破除对立、走向合作。

DevOps是一个合成词，由开发（Developments）和运维（Operations）两个单词组成，其主要目的是拆断不同部门之间隔离的墙。 简而言之，DevOps可以让公司的流程更快、更有效，并且更可靠。那么，持续交付和DevOps到底有什么关系？为什么要放到一起说？

4月1日，京东云与AI云产品研发部架构师井亮亮，讲授了《六周玩转云原生》第三讲：云原生下的DevOps与持续交付，让我们来回顾一下精华内容吧！

关于云原生的解释有很多种，这张PPT里列了常见的两种说法，大体意思是云原生是持续交付+DevOps+微服务+容器化。

六周玩转云原生

云原生下的DevOps与持续交付

— 京东智联云 井亮亮—

概念与简介

关于云原生的解释有很多种，这张PPT里列了常见的两种说法，大体意思是云原生是持续交付+DevOps+微服务+容器化。

也就是说，云原生是一个概念集合，既包含微服务、容器，也包含更多的管理方法，比如持续交付、DevOps和重组等。

那么如何定义云原生？下面这张图是CNCF官网对于云原生的定义，也是相对来说比较靠谱的定义。而想了解云原生，就得先了解K8S，因为它是云原生的基石。

- K8S

K8S是CNCF的第一个项目，云原生整个生态都是依靠K8S构建出来的。云原生的代表技术包括容器、微服务、服务网格、不可变基础设施和声明式API等。

- DevOps

每当大家提起DevOps，总把它比作盲人摸象，很多公司的叫法也不一样。有的企业会把内部上线平台说成这是自己构建的DevOps。

但我们先看维基百科的定义：即透过自动化“软件交付”和“构建变更”的流程，来使得构建、测试、发布软件能够更加快捷、频繁和可靠。

-持续集成、持续交付和持续部署

持续交付可以让软件交付变得更快更频繁，即随时都可以发布，它的目标是让软件的构建、测试与发布变得更快、更频繁。要确保效率，就只能交付得更快，但交付更快的前提是确保质量。说起持续交付，很多人还听过持续集成、持续部署。如下图所示，这三者之间存在着一定差别。

在传统软件开发中，开发者在项目结束后都需要做集成，这一过程少则几星期、多则几个月。软件开发在中早期时，需要频繁地进行集成，频繁集成的好处就是，避免到最后环节才发现问题。

很多人可能会说，我们团队早就集成了，那么你们多久构建一次？是不是每次发布时才走构建流程？如果是这样就要考虑一下持续集成。因为持续集成是持续交付的第一步。

而持续交付就是把前面所有东西集成在一块去交付给客户。当然不同公司对于这个阶段的叫法也有所不同，有些叫“测试-生产”，有些叫“测试-准生产”或者“上线”等等。

持续部署的意思是，所有环节都是自动化的，开发者提交完代码之后，可以自动化部署到生产环境里。持续部署跟持续交付唯一的区别就是，开发者能否把产品自动化地发布到生产环境里。

近年来，技术名词更新非常快。关于此，在基础设施方面体现得最为明显，几年前发布一个应用去部署时一般有如下几种选择：最好最根本的办法就是建机房，但所有的硬件、网络、水电等问题都得考虑进去；其次是搞服务器、装操作系统，最后再部署或者虚拟化一下。

再后来，我们会做类似VMware的虚拟机，即在上面虚拟化一下部署方式，直接写一些脚本执行一下就能跑起来。再往后，大家都开始搞类似OpenStack一类的私有云技术。

无论方法如何变化，也无论你用什么基础设施，最后都会演变成混合云或者多云的方式，你的交付不仅要支持这些模式、更要支持容器包。当前这个过程也变得越来越自动化，且越来越能满足业务诉求。比如，我们会用弹性伸缩技术，来满足业务需求和成本诉求。

持续交付-流水线？

持续交付需要一系列的过程，在这一系列的环境中，不论是测试、预发、生产，越往后就越接近客户的环境。尽管每个阶段关注的问题都不一样，但你会发现，每一个过程和环境都需要做发布做验证。

而通过流水线的方式，就能很好地把这一系列过程自动化起来，开发者构建的效率和发布的质量也会借此提高。

- 软件交付的挑战和问题

上图是2016年一个DevOps的调查报告截图。大家都知道，软件交付的过程本身，意味着线上变更，变更就意味着有风险。交付最大的挑战是上线过程中遇到失败，失败的话肯定会引发线上故障。

2016年的调查报告显示，81%的团队能将失败比例控制在15%以内，但是能把失败比例控制在5%的团队只有35%。这意味着发布100次就有50次故障。所以，变更对于软件交付的质量相当重要。

既然质量这么重要，那该如何选择交付工具？下面这张图，供大家参考。

- 流水线

世界上的第一条流水线，由福特汽车提出并上线。在当时，流水线极大地提高了汽车生产效率。而开发者在提交完代码后，把软件交付到客户手里，同样也会经历一系列的过程。那么这个过程怎么去建模和运行？

这时就得结合流水线的目标来推进，流水线的目标是快速集成、快速交付，可以说流水线其实就是个管道，它并没有一个标准的流程，我们完全可以根据业务去定制。

比如说，当你要构建一个流水线，你可能需要代码扫描、代码测试、测试部署再预发等等一系列过程。但是你怎么确保自己做的流水线可以很好地运行？

这个问题并不难，做到以下三点就可以：

第一，一定要做自动化构建。很多开发者觉得已经做了自动化了、已经持续集成了。但是如果你在构建上不够自动化、也不够及时，那就谈不上测试或者集成。

第二，一定要做自动化测试。构建完之后产生的产物肯定要测试，无论是功能测试、性能测试、还是压力测试。这个测试过程是为了达到预期质量，但也要根据情况去做自动化，因为只有自动化才能提高效率。

第三，持续集成。流水线只有重复、快速、频繁地运行，才能发现问题、解决问题。

在整个软件行业，起码做到以上三点，才能达到持续交付的目标。世界上的第一条流水线，由福特汽车提出并上线。在当时，流水线极大地提高了汽车生产效率。而开发者在提交完代码后，把软件交付到客户手里，同样也会经历一系列的过程。那么这个过程怎么去建模和运行？

- 最基本的部署流水线

上图虽然是最基本的流水线，但是大家可以看到，它涵盖整个环节，包括源代码环节、提交环节构建、测试和代码分析等等，到了后面就是验收、UAT测试生产环境、制品发布到生产环境。

- 一些流水线实践

上图是一些流水线的实践，具体可以分为三方面：

- 二进制包只构建一次

二进制包只构建一次的意思是，开发者在每次写完代码后再构建一次，从而生成一个二进制包，然后再去进行后面的流程。这样不仅可以避免浪费时间、还能提升效率。

但即便是这样，仍然出现两次构建的结果不同的情况，这是因为虽然你的代码和ID没变，但是你的包可能会产生变化。

- 要采用同一部署方式在不同环境里

在发布部署时，所有部署的方式和环境，例如测试、预发和生产都采用同一种方式部署，而不是部署到测试环境时用Jenkins做持续集成，生产环境要发布时却通过另外一套工具去部署。部署工具不一样就有可能导致最终交付的产物不一样。

在线上生产环境时，不管用物理机、云主机还是虚拟化物理机，都要确保它的高可用性能。这时就需要堆一堆资源，来保障线上用户的可用性。

- 流水线管道要灵活

流水线存在的意义，是为了提升效率和确保质量，但是开发者的业务可能有Java的、可能有Go的。因此你的流水线，要满足各种各样的诉求。

比如说，有些团队一套测试环境就够了，另外一个项目可能觉得该项目要提供给别的团队做联调，这时就要确保测试环境的稳定性，比如构建两套测试环境，A环境可以团队自己拿来做工程验证，B环境则可以提供给第三方去联调。

最后需要做的，是验证整个流水线的落地，不能说你把整个流水线构建起来了，然后就按照这种方式去走。真正落地时，要考虑到每次代码提交完成后 ，是否完成了自动化触发测试的流程。

京东智联云在持续交付的实践

每个企业做持续交付的经验，都是一步一步趟出来的。

京东最早的固定上线日是周二和周四，为了确保稳定性，研发人员不能去操作线上环境，那么就得运维上线去操作。这时产品经理们就会在运维后面排队，但是排队的效率比较低，并且那时还没有上线工具，自动化能力也特别差，线上故障的修复也无法得到保障。直到后来，才开始想办法填平。

- 两条交付的流程

在京东早期的两条交付流程中，第一条交付流程从开发、编译构建、代码分析、抽包到整个上线都有涵盖到。

在工具上，私服用的是商业版Artifactory、构建用的是Jenkins、代码扫描用的是SonarQube、对象存储用的是内部一个私有云，发布用的是rsync。

在第二条交付流程中，最大的变化是我们把rsync替换成ANSIBLE了，这的确极大提升了效率，并且解决了排队问题。

所以在发布过程中，我们原来是抽包模式，后来全部改成全量包的方式。另外一块是提测，原来我们只做功能测试，后来安全测试也做，原来只是对接静态代码扫描，后来也做安全漏洞的筛查。这两条流水线有一个共性问题，即每条流水线都会有一条测试包、一条生产包。

目前京东智联云的实践，基本分为三套环境，一套测试、一套预发、一套生产，测试、预发、生产与网络之间又是相互隔离的。

如上图所示，京东智联云的流水线会从源代码、构建、代码检查、测试依次进行，预发环节和生产环节基本都有涵盖到，假如核心功能自动化这块失败了，开发者得确保部署到测试环境后能够做到自动化验证测试环境的功能，最起码确保测试环境的核心功能没有问题。

从设计角度来说，整个流水线本身就是一个管道，管道里面每一个原子的功能都是独立的，像安全代码检测肯定是安全团队更专业，京东智联云在这一块就是安全团队去做的，他们提供安全机制，确保原子能力建设，我们通过流水线把它接过来。

- 持续交付最核心的就是规范

可以说，持续交付就是一个编排，大家都知道Jenkins特别流行，那为什么京东智联云的持续交付不能直接用Jenkins呢？因为持续交付最核心的一块就是规范。部署平台好比在大草原上放羊，一定得有牧羊犬管理羊群。

- 京东智联云如何做规范

京东智联云所有线上的操作都以同一套上线平台控制系统去做，这样的好处首先是减少风险，另外是统一控制系统能够做到秒级回滚。

其次，部署平台要用统一的帐号去做发布，出问题后好操作。而统一规范的实例部署路径、日志路径，都是按照一定目录去做，目录如果出问题，很快能够通过日志平台或者京东智联云内部平台“门神”去快速找到问题。

此外，京东智联云内部有整套DevOps平台，该DevOps平台涵盖各个方向，目标就是解决软件全生命周期的问题，包括开发、测试、运维，让开发者通过工具更好地工作。整个工具层面包含项目协作部分、开发工具和测试部分。

在配置管理方面，京东智联云的配置管理不仅涵盖应用层面的一些服务管理，比如人员角色的权限等。当把这些东西作为基础数据的核心，那后面的业务逻辑，包括监控、发布、日志等所有的服务基础数据都已经有了。

京东智联云是按照App的维度，向上是整个组织结构，向下会把整个模块和机器的信息管理起来，这时就不需要考虑发布机器的情况，只需要考虑发布哪个App，以什么流量切换的方式去发布它。持续交付真正的核心是靠流水线把整个环节去打通，京东智联云的监控是一个比较全链路的监控，不仅仅包括技术层面的监控、底层基础设施、容器、物理机，还支持混合云。

现在的企业一般不可能只用一种云或者只用自己构建的私有云，公有云也可能不会只用一家的，可能有A家的、有B家的，这种模式的话，不管是交付还是监控，都要做到支持基础设施混合云的模式。这样的话，就得在上层做到统一调度，所有监控部署的Agent也要做统一管控。此外，如下图所示，在这方面京东智联云也会对外输出自己的经验。

- 如何落地方案

在企业里面实施DevOps，很大一部分情况是企业已经用了一些东西，然后想用Jenkins提高一些能力。这时就要考虑为什么要做改变，并且说服你的老板或同事去做内部DevOps工具链条的改变。

这里有两种改变的方式，一种是国家信通院跟DevOps社区出具了一个DevOps标准，这个标准是上百个专家力量一起写的，大家可以参考一下。

云原生下持续交付

京东智联云上的工具链条比较多，目前我们正在做公测的过程中，未来会把内部项目管理的实践，以原生的方式开放给大家。

Ops部分则包含日志服务、监控、云拨测、云事件、运维的堡垒机能力，这一块也是我们内部自研的一款叫做“门神”的产品，这款产品已经支撑京东内部好几年了，0故障。当下，京东智联云以云原生的方式，进行的开发，预计会在下一步开源出去。

另外，京东智联云也支持Terraform和Packer能力，可以帮助开发者快速构建基础设施。整个京东智联云是以原生的方式，把工具以各种原生做法提供各种API，其目的就是希望帮助大家在原生云下构建属于自己的能力。

TIPS：在这样一顿操作之后，很多参加课程的小伙伴都纷纷表示我们这个系列的课程「帮助小白走近云原生的大门」，并对下次课程充满期待！

这里提醒大家一下，《六周玩转云原生》的第四期课程走近监控与日志，云原生基石探秘即将和你相见！

小伙伴们千万不要错过！扫码关注社区，追踪更多课程信息吧

云原生的时代已来，而你，也将成为这个新时代的构建者之一！

欢迎点击“更多”观看视频回顾。