从代码到上线, 云端Docker化持续交付实践

2016云栖大会·北京峰会于8月9号在国家会议中心拉开帷幕,在云栖社区开发者技术专场中,来自阿里云技术专家罗晶(瑶靖)为在场的听众带来《从代码到上线,云端Docker化持续交付实践》精彩分享。

关于分享者:

罗晶,花名瑶靖。在加入阿里云之前,先后在支付宝平台数据技术事业群、百度基础架构部任职。现主要负责阿里云容器服务产品的集群管理系统的研发,从事容器的持续交付、持续集成的方案设计与实现。

演讲内容架构

  • 大话持续交付

  • 持续交付的前世

  • 容器化DevOps

  • 持续交付的今生

演讲主要内容

持续集成指的是,频繁地(一天多次)将代码集成到主干。持续集成的目的,就是让产品可以快速迭代,同时还能保持高质量。它的核心措施是,代码集成到主干之前,必须通过自动化测试。只要有一个测试用例失败,就不能集成。

从代码到上线, 云端Docker化持续交付实践

持续交付(Continuous delivery)指的是,频繁地将软件的新版本,交付给质量团队或者用户,以供评审。如果评审通过,代码就进入生产阶段。

持续交付可以看作持续集成的下一步。它强调的是,不管怎么更新,软件是随时随地可以交付的。

从代码到上线, 云端Docker化持续交付实践

持续集成和持续交付保证了软件的持续运行和有效反馈。

从代码到上线, 云端Docker化持续交付实践

不同环境,不同交付运维方式。即便按照流程去做持续交付,系统地搭建出来整个持续集成的系统环境,一样会遇到七七八八这样的问题。就算是同一种语言,每一个开发者所依赖语言环境、依赖的包不一样,就会导致有非常多的编译环境,维护起来就很困难。

从代码到上线, 云端Docker化持续交付实践

传统持续交付问题的根源在于:

  • 开发者交付的只有代码以及代码的依赖;

  • 运维者需要除了代码之外的运行环境,以及运行环境之间的依赖。

从代码到上线, 云端Docker化持续交付实践

交付方式的变革

Docker的出现改变软件交付的方式。经济学家说过:没有集装箱,不可能有全球化。Docker就像把一堆零散的代码和我要的所有东西装在集装箱里,真正去交付给运维时,相当于把这个集装箱运行起来。它包含所有的环境依赖,所以在任何地方运行集装箱所达到的结果都是一样的。因为达到了环境一致性。

从代码到上线, 云端Docker化持续交付实践

Docker之所以这么火,是由于它的敏捷、可移植、可控的特性决定的。敏捷意味着Docker可以秒级应用启动、轻量级隔离、细粒度资源控制、低性能损耗;可移植代表着Docker的环境无关的交付、部署方式、可用于软件生命周期中不同运行环境;可控表示容器级别的资源隔离和流控。

从代码到上线, 云端Docker化持续交付实践

Docker Compose是Docker推出来的一个对多容器的编排技术,简单好用,便于开发。使用Docker Compose,可以一键构建本地开发环境,在团队中可以共享一份配置文件。它的优点是:

  • 简单好用,便于开发

  • 本地环境沙箱

  • UT环境

  • 编排容器、存储和网络

当然,它也存在不足:面向开发和部署,不支持自动化运维。

从代码到上线, 云端Docker化持续交付实践

Docker Swarm把一组Docker引擎抽象成一个Docker引擎,以前所有在单机上对一个Docker引擎的工作,都可以透明的变成对一组Docker集群上的节点的操作。Docker Swarm它的优点是:

  • 支持标准的 Docker API;

  • 灵活、可扩展、可插拔的容器调度。

当然,它也存在不足:面向容器、缺少服务生命周期支持。

从代码到上线, 云端Docker化持续交付实践

容器服务上有三个层面的概念:

  • 资源层面——集群,节点。

  • 内容层面——Compose模板,镜像。

  • 应用层面——应用,服务,容器。

从代码到上线, 云端Docker化持续交付实践

容器化DevOps,可以实现:

  • 开发环境到生产环境的一致

  • 可编程基础设施

  • Infrastructure as Code

  • 不可变基础架构

  • Immutable infrastructure

  • 全流程工具化、自动化、持续交付

  • 降低试错成本,鼓励快速迭代

从代码到上线, 云端Docker化持续交付实践

简单的容器化持续交付流程如下图所示:

从代码到上线, 云端Docker化持续交付实践

复杂的容器化持续交付流程:开发人员在除了代码 、Config、Test脚本还要写Dockerfile。把这些代码传(Push)到代码仓库,有一个CI service通过代码仓库hook告诉你代码仓库有一个新的提交。把代码拉下来复制,进行两件事情 : Build和UT。在build的过程中,会从Docker Registry上面去拉下来( Pull )依赖的image,当build通过了之后会push image到这个Docker Registry单位里面去。然后CI 会有一个hook去通知CD,deploy Service根据Docker和image描述以及compose描述,把image部署到预发、测试或者生产环境。

从代码到上线, 云端Docker化持续交付实践

持续交付“最后一公里”

发布时持续交付的“最后一公里”,常见的发布策略有蓝绿发布、金丝雀发布(灰度发布)、ABTest,在国内的开发者中,对这几个概念有独立的理解。

Rolling Update

  • 依次停止老容器,启动新容器

  • 整个过程自动化,无需用户手动操作

  • 适合于多副本的应用发布

从代码到上线, 云端Docker化持续交付实践

蓝绿发布(热部署)

  • 不会停止老容器,为新服务启动新容器

  • 需要用户设置路由权重,实现不同版本应用的上线、下线

  • 适合于版本的快速发布,不会停机影响用户

从代码到上线, 云端Docker化持续交付实践

金丝雀发布(灰度)

  • 不会停止老容器,为新服务启动新容器

  • 需要用户设置路由权重,实现不同版本应用的共存

  • 支持A/B测试,适合多方案选择

从代码到上线, 云端Docker化持续交付实践

相关推荐