2017 OpenStack Days China不仅仅是中国OpenStack技术与方案的展示，更是汇聚了来自亚洲各国OpenStack大咖的技术趴！最全面的行业案例展示分享、最细致的讲解如何从开发到运维、最丰富的技术干货、最好的参会体验

淡成：大家好，我叫淡成。今天介绍的主题叫《当DevOps遇到容器》，两个关键字，DevOps和容器现在都非常火，我们今天这个大会有两个分会场就专门讲这两个技术。

为什么会想到介绍这个话题，因为我是售前工程师，我的日常工作会和各个不同企业的客户去沟通他们遇到的一些技术上的问题。最近一段时间，在企业里面我在沟通的时候遇到最多的问题是这样的，很多客户说我们现在听到了我们自己用了很多DevOps的工具，比如像Jenkins，比如像代码检查的工具。现在社区里面的容器技术又这么火，我自己的DevOps其实已经做得挺成熟了，我用了Jenkins，每天可以发布一个版本，发布一次可能也就十几二十分钟。在这种情况下你说我还有必要使用容器吗，用容器能给我带来更进一步的好处吗。因为我们在公司内部推广的时候，我们的技术人员其实是有一定抵触的，他不管开发还是运维人员，他都需要掌握新的技术，他要了解怎么在容器开发，怎么做容器的部署和运维。我觉得有必要在这里面和大家讨论一下，到底DevOps整个流程过程中哪一些地方可以使用到容器，容器可以带来什么样的好处，它有什么样一些技术的限制。

DevOps的概念前面几位嘉宾都已经讲了，2008、2009年就已经有了，其实在实践里面刚开始做得最好的就是这个片子，2009年Flickr做图像管理的公司，每天部署十次，这个在以前其实是不可想象的，现在可能有来自互联网公司的同事，大家觉得我一个应用单一的服务一天去部署十次，这个其实再正常不过了，很简单。但是在2009年的时候，那个年代我们阿里的同学曾经在不同场合分享过，2009年的时候阿里是怎么做这个发布的，他在很多个数据中心里通过手动的方式登录到不同的数据中心里人工去进行发布，发布的过程中出现错误的时候需要人工的去进行回滚。2011年我们上线了12306，12306在上线最初的时候，它的更新是有时间窗口的，做一次更新需要4个小时的时间窗口，那个时候开发和运维人员几乎需要通宵去加班。

我们从DevOps发展背景来看一下，为什么说现在很多的企业都想去做DevOps，其实这个有两个方面的原因，一个方面，IT部门在我们企业内部的重要程度越来越重要，在以前，IT部门一般来说是一个企业的支撑部门，重要程度很一般，一般是运维在自己的数据中心里管理几个服务器，做一些运维的工作。随着一些技术的发展，比如说企业发现通过大数据可以影响到自己企业的业务，使自己的业务增长。我们会发现IT部门在企业内部的地位越来越高了，参与业务的程度也越来越高了。再往后发展，我们通过容器，现在很多企业想去做数字化的转型，甚至很多企业现在他的IT系统就是他主要的业务，他的业务就是他的IT系统，比如现在互联网金融、打车软件、今日头条这种内容提供商，他的核心业务就是他的IT系统。IT系统的重要程度越来越高，也就直接导致了IT系统里它所遵循的这些流程，DevOps程度越高，它的核心竞争力就越高。我们从参与人员的角度看一下DevOps，以前来讲，我们大家都认为DevOps就是开发和运维人员，其实整个DevOps目标是使我们的业务更加灵活、更加敏捷的适应市场和业务的变化。所以广义上来讲，我们希望整个企业内部所有的和业务相关的人员都能参与到DevOps中间来。但是传统企业由于组织架构的问题，它会导致DevOps很难推广，因为每个部门考核的目标以及他所关注的点是不一样的。我作为售前，我经常去客户不同的部门去交流，我有个很明显的感触，每个部门关注的点是不一样的，比如你在和运维人员沟通的时候，你告诉他说我这个开发语言多么先进，可以减少50%的代码量，运维人员一般的反应就是“哦”，如果你去开发部门告诉他们说我这个工具可以实时监控网络、存储状态，可以在你的系统发生故障的时候给你自动恢复，开发人员一般的反应是“呵呵，在我的环境里不会出现故障的”。可以看到这就我们开发人员和运维人员他们之间由于他的背景知识，他所关注的点不一样，造成这样一个问题。DevOps你就去改变企业的组织架构，让大家形成一个融合的团队。如果改变组织架构有难度，你就要去做一个标准化的交付物或者交付流程的衔接，让不同部门之间沟通和交流的壁垒更加清晰。

很有可能DevOps这个运动会帮助我们创造出来新的岗位。我们知道关系型数据库在广泛应用之前，其实没有DBA这个角色。现在谷歌和Facebook里最活跃的岗位就是SRE，这个岗位在以前也是没有的，但是由于DevOps的运动，造就了一些新的岗位，这一点也是值得关注的。

我们可以从三个角度来看，一般对DevOps，对于企业组织的要求。第一是人员，前面几个嘉宾都提到需要有一个企业文化的重建，甚至组织架构的重建，使大家的目标和KPI是一致的。流程，通过敏捷，我们可以通过迭代尽早的发现问题，尽早的解决问题，这个其实在大部分的企业内部现在已经这么做了。通过DevOps流水线可以管理不同阶段、不同交付物的规格和质量。第三点是技术和工具，包括我们使用的CICD流水线、不可变基础设施等等这种技术来实现。

下面介绍一下实际我们的客户在使用容器，在DevOps实践中遇到的一些问题和他们是怎么解决的。所有的新技术它初始推广的时候其实都会遇到阻力的，大家知道在汽车诞生之初，开得也比较慢，声音又大，又老冒烟。最早汽车推广是很困难的，很多地方允许马车走，不允许汽车走，那时候马车的拥有者就会认为说我这个马车很舒服，出了问题坏了以后，随处都可以找到配件修理它。同样的问题在容器里也是一样的，很多企业客户提出的问题，我现在的系统坏了，我知道我有工具而且我有能力修好它，但是到了容器这个环境里以后，如果出现了问题我该怎么办，我没有这方面的技能。我们下来会从几个方面看一下容器在DevOps里遇到问题该怎么解决。

这块是一个简单的IT架构的发展趋势，可以看到这几个关键的技术点，微服务，DevOps，云计算，我们的应用架构从单体发展到多层，发展到微服务，我们的开发流程从敏捷发展到DevOps，我们应用的运行环境也发生了变化。有一点，DevOps的概念和微服务的概念提出的时间已经很长了，都是2008、2009年的概念，为什么在近一两年才开始在不同的企业里使用起来。其实有一个可能性，容器这个技术其实是一个催化剂，它帮助我们把微服务，帮助我们把DevOps更好的在企业落地。微服务我们一般建议用户以最合理的技术选型去实现微服务，比如我这个服务适合用Java开发，还有一个服务需要PHP开发，微服务建议用最短的时间最灵活的方式去实现你的业务逻辑。问题来了，开发人员是灵活了，运维人员就头大了，最早我的运维人员可能只掌握一个Java的运维知识就够了，现在你三天两头扔一个新的开发语言，运维人员的工作越来越难做了。所以说需要有一种标准化的交付物给这个运维人员，他可以不去关注我的容器里运行的什么语言，甚至什么业务都可以不用关注，是以容器为最小的调度单元去运维的。有了容器以后，微服务的可行性就变大了。同样的道理，在DevOps上也一样，以前我们一个一个应用，在做DevOps的时候，他可能需要自己开发不同的脚本，去适应你的Java应用或者是其他的应用。通过容器以后，我的工具链就变成单一的了。

环境那块不用讲了，我们以前一个应用迁移动不动需要两三天时间，用了容器以后，在公有云、私有云里来回迁移的时候可能就是一个模板文件或者几条命令就可以做到了。

在DevOps相关的领域，包括像发布管理、配置管理、运行时管理、环境制备和监控等一系列的方向，下面从几个方向看一下容器技术在里面怎么使用的。

首先发布管理，容器在DevOps的发布管理里最大的作用就是标准化的交付件，不可变基础设施，每当发布以后我这个里面的内部就不会变了，它是一个标准的格式，我在任何的底层的异构的环境里都可以运行。简化运维，现在很多地方使用容器的运维人员，他其实已经不需要掌握我们传统的比如java运维等等这种能力了，我的平台容器发生故障的时候，我可能只是做一个健康检查，如果不健康杀掉就行了，没有其他动作。通过Dockerfile它的配置和部署工作，被提前到了编译时，以前我们做好应用在不同的环境发布，再去手动调整环境变量，但是现在所有这些工作都被提到了编译时，由于环境造成的问题的可能性降到最低。最后一点是代码管理，我们以前可能只对代码管理，其实我们对配置、对基础设施也可以以代码的形式去管理。比如对基础设施来讲，我一个Dockerfile，我可以把它当成代码进行版本管理，不同的人对它进行修改，在不同的版本里。对于环境问题我们也是一样，我在发布的时候，我的应用运行的环境其实是可以被版本化的。以前我们在一个应用出现故障的时候，你想把它回滚到一个月以前的版本，我们通过什么方式来做，虚拟机，虚拟机有什么问题，虚拟机是把环境和应用绑定在一起的，你没法把环境和应用分开，你要回滚到一个月前的版本，你的应用也会回滚到一个月前的版本。而通过容器，不仅应用代码有环境控制，我的基础设施Dockerfile也有版本控制，我的环境也有版本控制，这三者组合起来，可以选定代码的版本、环境的版本、基础设施的版本，把它们三个随时组装成一个你想要的状态。这是通过容器可以做到的。

第二个是配置管理，我们以前在做应用的时候可能是写一些配置文件，这些配置文件最大的问题，你在运行时需要手动去修改文件的，比如有时候你需要登录到你的生产欢迎里做一些配置文件的修改。使用容器，我们可以把配件文件和代码完全分离开。有镜像管理和流转，通过镜像仓库。环境的版本控制刚才也介绍过了，这一点对于我们的运维是非常重要的，大家可以下来看一些关于环境的版本控制这方面的最佳实践。我可以在任何时间把我这个系统会回滚到以前的任何一个时间点上去。

运行时管理，指的是应用上线以后，DevOps还有很多工作要做。DevOps很重要一点是要形成反馈回路，在你运行时有很多工作，比如你部署的时候，你要通过模板来部署，你的服务之间的关系，用DevOps一定要有一定的发布能力，比如说通过灰度发布或蓝绿发布。我们现在很多企业其实已经实现了这种灰度或蓝绿发布的方式，但是据我所知绝大多数企业还是以手动的方式来做。举个例子，红帽有些客户他在做灰度和蓝绿的时候，他是在生产环境，人工的登录到Nginx的服务器里去手动的切换路由，这个里面的风险点和不可控点就非常多了。如果一个容器平台本身把这些能力一直内置到平台里了，对于我们要去做DevOps就变得非常可控，而且非常简单。这些脚本，首先你不用写这些脚本了，这是平台的能力。第二，你也不用人工做这些操作，平台会自动帮我们做，你只要告诉它我的灰度发布的规则是什么，通过配置就可以了。容错，弹性，比如我的某一个服务由于请求量过大的是不需要人工再去写脚本，去监测资源利用率去做拓展，平会自动帮我做这些。这些都是我们平时在做DevOps运营过程中经常会遇到的能力，目前大部分的能力都是以和应用强相关的一些脚本或者自己定义的工具来实现的。但是如果有这么一个平台，它把我们所有不同类型的服务都抽象成了一个标准的处理方式，不管你是Java的应用，还是PHP的应用，你遇到问题的时候我都可以以一个标准化的处理方式来处理。

环境制备，这个很好理解了，通过一个容器的平台，刚才我们上一位嘉宾讲的，如果说一个环境没有控制，可能会有很多人将来用很多虚拟机、服务器，导致资源滥用。如果每一个开发人员或者测试人员上来就是一个租户，你不管在里面使用多少个容器多少个应用，你只要不超过这个上限，就可以随意使用。而且资源制备随着非常快，通过用户登录以后就可以使用整个平台里面所有的资源。

监控，DevOps里的最佳实践里监控非常重要的，如果让我们手动管理DevOps应用，那会很麻烦，现在大部分的应用都是分布式的应用，你的这些日志的收集、监控数据的收集，都需要你通过一些定制化的工具来实现。如果说有这么一个平台，它可以帮助我们把日志和监控数据都给我集中的收集起来，并且它帮我定义了一个通用的健康检查的接口。以前这个健康检查在企业内部使用的时候，每个应用会有自己相应健康检查的实现方式，有的通过监听某个接口，有的通过访问某个URL，如果有一个平台给我提供标准的健康检查的标准，我的开发人员在发布应用的时候就把这个健康检查挂载进去了，对于运维人员来讲，他几乎不需要来关心我容器运行的健康程度，你发布以后，只要出现故障的时候，容器会自动被平台杀掉，启动新的容器来帮你提供服务。还包括其他功能，像计费、报表、分布式追踪，在传统的单体应用里面，你可能通过一个调用堆栈就能看到你的应用哪块慢了，但是在分布式环境里，你的某一个业务经历了好几个服务的调用，到底是哪块出了问题，导致你的服务故障或者是比较慢。这个平台如果能提供这种分布式追踪的能力，就会帮助我们很好的实现DevOps的实践。

从刚才这五个层面讲到DevOps要关注这五个点，容器要在这五个点里都有一些最佳最好的实践。什么东西可以帮我提供什么健康检查、日志，下面是广告时间，我们在做DevOps的时候，如果说你想通过容器实现刚才DevOps那五个层面的功能，比如说标准化的健康检查、弹性扩展、自动扩容、监控、日志等等，使用红帽的OPENSHIFT，包括了所有我们在日常DevOps落地的过程中所需要的这些工作。

最后总结一下基于容器的DevOps的实施步骤，这个是我们在一些客户里总结出来的流程。首先我们要去做一个基础架构，也就是我们说的容器平台，如果你要基于容器去做DevOps，首先你对容器管理平台架构要构建好。其次，可以用容器平台去做一些自动化的发布管理，比如说用Jenkins和你的容器平台做一个对接，做我们软件生命周期管理的后半部分，你的应用镜像可能已经build好了，把这个应用镜像发布到平台的容器平台的工作可以来做。第三个阶段可以引入开发，从源代码开始，通过CICD的Pipeline构建成应用心的镜像，然后把镜像发布到容器平台上去进行管理，再去利用刚才我们讲的容器平台里的功能，去反馈回开发。

这是一些最佳实践，首先要注重持续集成，从一个应用或者从一个小的团队开始，有一些在做容器的DevOps的时候，一开始要一些非常大的应用来上线，其实这个是不太好的一个实践。比较好的方法，用一个小的团队，一个小的应用，先把这个流程给试通了，确实可以在企业内部达到高效的效果以后，在其他的部门和其他的应用里去进行推广。确定衡量的指标，这块其实挺有意思，以前咱们国内的开发人员衡量我们自己的KPI，以后是代码行数，你解了几个Bug。现在是以业务结果为导向，比如说你的应用运行过程中的故障率，你做一次上线花了多长时间，是以实际最终用户来使用业务系统为目标。这个也可以解释为什么很有可能在可见的一段时间我们的开发人员和运维人员会有一个融合的过程，融合成一个一个以业务为导向的单元去协同工作。

最后总结一下，通过容器来做DevOps可以改进我们的质量和速度，容器在DevOps里面它的这些好处，刚才那五个方面都已经介绍了，不管是从发布阶段、运行时阶段、监控阶段，都是有一定优势的。但是使用容器会带来一系列的挑战，这个挑战包括人员的培养，你的开发人员的技能和运维人员的技能，以前可能没有容器的背景，他要去重新学习新的背景。第二点，使用容器以后，很有可能你的业务单元就变成从一个单体式的应用变成一个分布式的应用，那么你要引入一些分布式应用的复杂度，这个是需要你的平台具备分布式应用运维的这些能力，你再去上容器。最后是选择合适的容器平台，其实是可以帮助我们快速的实现DevOps。其实一个好的容器平台，它应该具备刚才我们看到的所有的功能，这些功能现阶段在各个企业里面都有对应的工具或者是脚本在做，但是最大的问题什么，就是不够标准化，一个应用会有一套这样的脚本和工具。现在我们都在讲微服务，你将来一个企业内部可能会有几十个上百个微服务，你每一个服务都要做这么一组的脚本和工具，那么它的可扩展性就会受到限制。回到最初我们讲到的，很多客户在问，我到底有没有必要上这个容器，我一般这么告诉他们，假如说你企业内部的IT系统已经稳定了，在可预期的未来你也不会做任何的增长和业务的变化，其实你没有必要上容器。但是我们都知道，在这个时代，没有哪个公司的业务可以长时间不变化、不新增，当你新增业务或者服务的时候，你又要有新的人去做重复的工作。我们做IT的人最讨厌的就是重复的工作，最有动力的就是把以前一些人工的事情给自动化，变成可复用的。一个好的容器平台它就可以极大的节省你的这些精力，把一些以前要重复的劳动变成自动化的工作。

这就是我今天介绍的主要内容，谢谢大家!