Docker在蚂蚁金融云平台中的探索与实践

问题导读：

1.Docker在整个平台架构中扮演怎么样的位置？

2.在PaaS层面，如何屏蔽底层不同IaaS的区别？

3.容器的安全问题怎么解决？

4.如何将基于Docker的系统与原有系统对接？

蚂蚁金融云是蚂蚁金服推出的针对金融行业的云计算服务，旨在将蚂蚁金服的大型分布式交易系统中间件技术以PaaS的方式提供给相应客户。在整个的PaaS产品中，蚂蚁金服通过基于Docker的CaaS层来为上层提供计算存储网络资源，以提高资源的利用率与交付速度，并用来隔离底层IaaS的不同，IaaS、CaaS 与PaaS三层相互借力，互相配合。为了进一步了解蚂蚁金融云的整个体系架构，InfoQ采访了蚂蚁金服基础技术部系统组leader吴峥涛。另外，吴峥涛也是QCon上海《容器与云计算》专题的讲师，他在大会上将分享题为《蚂蚁金服金融云PaaS Docker实践》的演讲。
吴峥涛表示金融云PaaS是从2014年中开始研发的，目前已经承载了网商银行以及另外两个核心业务，后续会以公有云和专有云两种模式对外提供。之所以会有金融云PaaS这个项目，是因为蚂蚁这些年来在大型分布式系统领域涉及的SOA、消息通讯、水平扩展、分库切片、数据一致、监控、安全等技术方向积累了大量的中间件以及与之完整配套的监控运维研发流程体系，这一切在性能和稳定性以及扩展性上做的都不错，能够有效的支撑蚂蚁的业务发展，并应对『双11』这样的高负荷挑战。很多金融客户与伙伴都对此非常感兴趣，所以我们希望能够把这一整套的技术上云并产品化，以 PaaS的方式整体对外输出，帮助金融行业的客户使用云计算技术去IOE，帮助他们解决我们已经解决的技术问题，让他们能专注于业务逻辑。上帝的归上帝，凯撒的归凯撒。

吴峥涛表示遇到的问题有很多，最主要的问题包括：

• 金融云PaaS是承载在阿里云IaaS上的，最初的方案是，用户部署应用的时候，根据所属技术栈，由系统解析软件包（例如sofa4依赖CloudEngine、Tengine、cronolog、JDK等等），下载安装配置并启动。这样的资源交付、应用部署周期比较长，客户体验不太好。
• 蚂蚁的应用架构采用的是基于服务发现、消息总线的SOA方案，模块间通过服务接口调用；服务可以是本地接口也可以是远程接口，对于调用者是解耦合的。在实际部署的时候，我们会
  根据业务纬度切分大量的服务模块出来，以金融云PaaS中枢为例，目前已经有几十种服务模块。这样的话，我们希望资源粒度越小越好，原有以VM为粒度的资源分配方式已经不能满足我们的需求。同时资源交付速度慢导致扩容缩容慢，影响资源利用率。
• 金融云PaaS如果对外输出，可能使用非阿里云的IaaS，所以需要一个中间层屏蔽多种IAAS的区别。
• 镜像管理比较麻烦，无法自动化，也不是白盒。
  

而遇到的这些问题，都可以通过Docker来解决。

吴峥涛表示我们在PaaS和IaaS之间插了一个AntCaaS层，这是一个基于Docker的管控平台，他的职责是：

• 以微容器（Docker）为载体，为用户（PaaS、SaaS）按需提供计算存储网络资源，提高资源的利用率与交付速度。
• 对PaaS、SaaS屏蔽IaaS实现细节。
• 实现容器、集群级别的标准化与可复制、可迁移。
  

AntCaaS提供container、app、cluster三层接口，可以把他当作一个轻量级的IaaS，区别仅仅是提供Container而不是VM，然后也提供PaaS层的接口。
一个比较有特色的功能是，通过『镜像中心+集群template+环境相关参数列表』，我们实现了集群的快速复制，目的是为了应付突发的负载高峰。
吴峥涛表示目前AntCaaS可以直接运行在物理机上也可以运行在经典网络的ECS VM集群中，VPC、ECS支持还在开发过程中。在AntCaaS中，我们采用三层架构，通过创建不同pool来兼容不同的IaaS。pool包含了：

• 多个node（container的载体）。
• ZK用以监控node和container。
• scheduler 调度器，负载container的创建调度。
• manager，对master提供管控的HTTP Rest接口。
• registry-proxy 保证网络联通性以及cache镜像数据，加速镜像下载。
• 在node内起cadvisor监控container。
  

Docker默认的bridge/host网络模式不能满足我们的需要，根据IaaS提供的网络功能不同，我们扩展了vlan/vxlan 两种网络driver，第三者vpc driver还在开发中。

• vlan模式，事先为container分配一个与node不一样的网段
  

vxlan模式，首先通过ovs实现跨node的私有网络，然后通过zk缓存同步vpcid、vpc ip、node ip的映射关系，极端情况下，如果一个vpc有1000个container分布在1000个node上，那么新建一个container加入这个vpc 时，需要通知所有的node。

另外在VPC内，我们提供轻量级的DNS，用于内部域名解析；轻量级的LB，用于内部的负载均衡。

下图是可扩展的容器创建流程。

吴峥涛表示基于pool-node-container的三层解决方案。用户和pool是1对多的关系，所以 pool的node必然都属于同一个用户，同一个node上的container属于同一个用户。pool和pool之间根据IaaS不同采用不同的隔离方案，经典网络的ECS使用安全组隔离，vpc ecs使用vpc隔离。

吴峥涛表示碰到过，我们的架构设计允许Docker Daemon和Container挂掉。使用了集团的一个Docker Patch，在Docker Daemon挂掉后，不影响container运行。出现比较多的场景是docker pull时候。

吴峥涛表示为了与现有的运维流程管控SCM系统对接，帮助现有系统迁移，以及帮助开发同学转换开发模式，我们做了不少妥协方案。作为Docker fans，理想的开发模式是下面这样。

但是实际上蚂蚁目前已经有1000多个应用，几千的开发人员，很难让他们一下都切换到Docker这种以镜像为中心的研发模式上；但是如果一个团队一个团队的推广，那么耗时不可控。并且蚂蚁原有的运维、监控、SCM等系统都是以VM为纬度的，基于Docker的运维发布系统需要与原有系统对接集成难度比较大。

所以我们的第一个策略是，首先解决线上环境的Docker化部署问题，开发者的本地开发环境Docker化问题暂且不管，希望通过线上环境Docker化来吸引开发人员学习使用Docker。

接下来的问题是，谁来写Dockerfile，首先各个研发团队的人不关心是否使用Docker部署，所以不可能写Dockerfile，由 Docker团队或者运维同学负责，没有应用代码的编辑权限，同时工作量太大并且不了解应用容易出问题。所幸蚂蚁的业务应用大多数都是基于sofa3或 sofa4框架的Java应用，所以我们做了sofa3/4的基础镜像以及提供一个辅助工具，使用sofa3/4镜像启动一个container，然后使用原有的发布工具将应用的tgz包（类似war）发布到container中。这样就不需要写Dockerfile，同时原有运维系统也能把 container当作VM，无缝对接。

吴峥涛表示关于跨机房镜像中心的解决方案要点：

• 将镜像数据存在OSS写三份，保证数据安全性；
• Registry本地不保存数据，是无状态的服务，可以水平扩展；
• Registry 上跑一个Nginx，提高镜像数据访问速度；
• 在每个pool中部署一套Nginx，开启文件缓存，对常见镜像进行预热，构建缓存；
  

原文链接：http://www.infoq.com/cn/articles/docker-in-the-antgroup-cloud-platform