2018-03-21 15:30

　　大家好，今天主要分享一下如何借助开源PaaS技术，帮助客户更好地实现DevOps流程。

　　DevOps是一个比较大的课题，我理解DevOps就是帮助用户在软件开发过程中如何做到多快好省。可以从四个方面具体阐述，一是企业文化，整个公司是不是鼓励这种让员工发现问题，发现流程里面有没有一些可以自动化、可以优化的环节。二是组织架构，组织架构如果用DevOps来实现的话，鼓励扁平化，一个团队里尽量有多种角色共同参与。三是工具套件，DevOps每个流程都需要一定的工具实现，今天的分享就讲一下工具套件。工具套件就是DevOps能不能很通畅的进行下去，工具是不是完备，工具之间的耦合度高不高，是不是很好用，均对DevOps的执行有很大影响。

　　我们为了更好的帮助客户去实现DevOps流程，做了很多努力，首先是从客户那边了解他的需求，另外是我们也在看在开源社区里面有没有这方面的实践，因为开源的主要目的也是为了避免重复制造轮子。一是客户需求，二是调研之后的发现，发现openshift可以帮助用户实现从应用开发到测试，到上线全流程的管理，而且开发测试和运维的不同角色可以在一个平台上进行协作。

　　关于资源的分配，也是客户比较在意的，以前，不同的公司里面不同的项目组可能要单独申请资源，而且这些资源没法做统一管理、配额限定，有了DevOps可以做统一的资源管理调度，以及配额的管理。

　　总体技术架构，openshift目前包括的功能有应用框架的开发、中间件、软件定义网络、性能监控、自动化的集群管理。openshift总体技术做的比较好，它是对K8S以及Docker的封装。底层主要还是用Docker引擎，网络主要网络插件，存储目前推荐是ceph。基础设施这一块选择比较多，有本地、物理集群和云。这里有几个点，首先是界面不太好，不太符合国人的使用习惯。第二是管理，管理员级别需要后台命令，使用的时候要做定制化。但是它提供的IDE 插件，做下简单的配置就可以更方便的跟openshift集成，代码开发完成后提交后就可以构建，部署，还可以远程调试，这个对于开发来说是很方便的。

　　下面讲一下核心流程。首先是构建过程，构建其实是把代码从模型转换为另外一个模型的过程，传统更多是把代码打成一个可以部署的软件的代码的形式。但现在和容器融合之后，要从源代码转成Docker镜像。整个流程从大的方向，比如说第一步，可能要制作基础镜像，指定源码地址、确定镜像版本、设定部署触发器、自定义构建过程。这些都是它内置的多语言框架及中间件。

　　这个过程是它鼓励你使用的构建过程，还可以集成jenkins的方式，两样方式都支持，但这个S2I流程还是比较鼓励的，因为它比较简介，好用。

　　DevOps的核心流程就是应用的部署，比如传统的K8S里面原生的布置是我直接去部署一个应用，里面要做好多事。在整个应用部署的过程中，要声明一些比如资源、环境变量，还有一些比如是否需要弹性这些东西，这些东西都可以定义到部署配置里。有了这个定义之后，可以基于这个定义做若干次的部署。无需关心基础设施，按需申请。

　　整个部署过程，要是基于模板部署的话，把模板导入平台之后每次基于这个模板做应用的部署了。整个部署过程中有一个核心点，每次部署都会产生一个RC，RC是保证副本的数量，或者出现问题自动重启的操作。还有是定义一些健康检查策略，还有外部访问。

　　外部访问主要通过router实现，其实 Router 组件就是一个运行在容器内的 Haproxy ，是一个特殊定制的 Haproxy。 用户可以创建一种叫 Route 的对象，笔者称为路由 规则 。一个 Route 会与一个 Service 相关联，并且绑定一个域名 。 Route 规则会被 Router 加载。 当用户通过指定域名访问应用时，域名会被解析并指向 Router 所在的计算节点上。 Router 获 取这个请求，然后根据 Route 规则定义转发给与这个域名对应的 Service 后端所关联的 Pod 容器实例。

　　下面就是一个升级的过程，我们应用了DevOps之后，DevOps就是小的频繁的快速的发布，而且现在这种微服务也越来越多，如果没有这种工具帮助你做升级的话，整个过程就比较痛苦。有了这种工具之后，就可以做很多自动化的操作，比如我们提供滚动升级、灰色发布和回滚的方式。灰色版本是老版本应用做升级的时候，不会一下把老版本的服务全停掉，是有一个同时存在的过程，比如新的版本发布上去之后可能会存在一些大的问题，那这样的话，可能所有用户都会受到影响，灰色发布意思就是老版本和新版本同时并存，这样可以在发现问题的时候，就可以让少量的用户受到影响。回滚，不是每一次升级都会比较成功，以前回滚可能做很多操作，做升级的预案，回滚的预案。我们在每次升级的时候都有版本，比如1.0到2.0，都要定义这样的版本。比如升级到2.0，如果失败的话就可以做一个回滚操作，在这个里面只要一个命令就可以操作。

　　我们在实现DevOps的时候，它对监控以及日志的分析有很高的要求。因为一个日志上线之后不可避免会出现各种各样的问题，有监控系统的话可以提前预判，降低问题发生的概率以及它带来的风险。但这个应用不可能完全不会发生，当出了问题之后也需要日志分析系统帮助工程师做问题的梳理然后更快的解决问题。在这里面比如原来提供的日志系统，做日志的采集，做日志的分析。用这个插件来做分析完的展现，监控系统就是用这三个（cAdvisor,heapster,hawkular），这也是K8S目前比较成熟的方案，在每个节点上部署，最后做最终的存储以及做数据的展示，日志使用（Flutend，ElasticSearch，kibana）来实现。

　　它提供这种日志和监控系统已经做好了模板，其实也是通过容器的方式布在这个平台里，集群大了之后可以做水平的扩展。

　　最后做一个小结，我们也是帮客户做DevOps的建设，这一流程的梳理、建设，我们公司内部也在走DevOps流程，发现DevOps不是很快能完成的过程，中间过程还会出现比如要做组织架构调整的话，可能还会经历痛苦的过程。但是我觉得DevOps是一种趋势，毕竟是帮助你的应用，能更快的落地到产品，把产品交到用户手中。

　　我们也会在公司内部持续走DevOps流程，我们也会帮尽量多的客户把DevOps流程落地到他自己公司的流程里，我们也会持续分享我们在DevOps之路上的所见与所得，大家如果对这方面感兴趣，想从事这方面工作的话，可以通过邮箱、微信跟我们做交流。

　　最后是一个公司的介绍，我们是一个开始时间比较早的云计算公司，之前主要专注在行业云、私有云。如果感兴趣的话可以看一下我们公司的网站，谢谢大家。