独家揭秘：阿里云Docker容器服务开发内幕
从诞生到现在，Docker就被吸引了全世界的关注，甚至被认为是能够改变世界的那只“箱子”，关于Docker技术的任何新闻都能引起业界的强烈关注。毋庸置疑，这一领域吸引了众多的创业者，许多年轻的创业者开始在这个领域开拓自己的事业，那么，对于一项可能颠覆云计算领域的技术而言，自然少不了众多大型云计算厂商的身影，包括Google，Amazon、都相继推出了自己的容器服务。那么，作为国内公有云的代表厂商，阿里云的一举一动始终牵动着众多开发者的目光。不久前，我们CSDN采访到了阿里云资深技术专家易立（花名微垣），他带我们带来了阿里云容器服务的独家揭秘。
阿里云资深技术专家 易立(微垣)
易立，阿里资深专家，目前负责阿里云容器技术相关的产品的研发工作。易立毕业于北京大学，获得学士和硕士学位；加入阿里之前，曾在IBM中国开发中心工作14年，担任资深技术专员，作为主要架构师负责IBM企业平台云产品线PureApplication System的研发工作；还作为架构师、主要开发人员负责和参与了一系列IBM在Web 2.0，SOA中间件的研发和创新，也曾为全球客户提供SOA技术咨询和项目实施。
以下是采访实录：
CSDN:请介绍下阿里云容器服务，目前的公测情况？
微垣:阿里云容器服务从去年12/21开始公测，现在已经有很多企业和开发者参与到公测过程中；我们为客户提供了钉钉群，旺旺群和客户及时沟通解决用户问题；我们每周迭代都会发布新的功能特性，并根据用户反馈持续改进产品。
在云栖社区，我们建立了团队博客http://yq.aliyun.com/teams/11，把一些典型示例和方法展示给大家，方便大家。
CSDN:阿里云容器服务的定位和主要业务场景是什么？
微垣:阿里云以服务化的方式提供了容器基础设施，能够让用户关注于自己的应用而非基础架构设施：
容器仓库服务提供了Docker镜像管理加速能力，可以方便的创建、分享镜像，也可以和三方代码托管工具，构建服务配合，支持持续集成和发布。
容器服务提供了高性能可伸缩的容器管理服务，支持在一组阿里云云服务器集群上通过Docker容器来运行或编排应用。容器服务免去了你对容器管理集群的搭建，整合了负载均衡SLB、专有网络VPC等云产品，让你通过控制台或API进行容器生命周期管理。
每个容器集群是基于独立的ECS实例资源，不同用户之间不会共享计算资源，可以更好的保障用户应用的安全性和服务质量。
容器服务提供了标准化的兼容接口，用户可以使用Docker命令行工具或REST API与容器服务交互，支持任意Docker镜像和Docker Compose模板。
容器服务考虑了用户的扩展性需求，我们允许用户，自由的添加和定制自己的日志和监控能力
阿里云解决了容器应用整个生命周期中，镜像构建，分发、编排、运维的基础问题；同时提供了和三方服务的接口，用户可以定制、集成自己的流程和方案。
容器服务目前主要支持的应用场景：包括Web应用，微服务架构应用，持续集成和持续交付的场景；我们会针对这些典型场景，结合容器技术简化和优化开发运维流程。
CSDN: 阿里云容器服务和目前市场上的Docker初创容器服务区别有哪些？
微垣:容器技术是近年来云计算领域的热点，国内外初创公司（包括Docker收购的Tutum）和云计算巨头Google，Amazon都推出了容器服务。在这个领域大家都在探索如何结合容器技术和云计算，提升整个软件开发交付的效率。阿里云也是根据自身的优势和技术积淀，推出了我们的容器服务。我们推出的服务除基本的容器集群和应用管理能力之外，也希望为用户带来一些特有的价值
- 在阿里云上一键创建容器集群，动态调整集群规模，可以方便的将现有ECS实例加入容器集群。大大简化用户安装Docker、配置网络、管理集群等成本。
另外针对阿里云基础服务的特点来对容器化应用进行优化，提供更好的服务质量 比如在网络层面：容器间网络通信同时支持经典网络和VPC（虚拟专有网络）；比如，在VPC内容器应用不但可以有更好的安全隔离和混合云连接，而且利用VPC网络能力提供的跨宿主机容器网络能够提供更优秀的网络带宽；在阿里云上使用容器仓库服务，可以使用内网流量，节约公网流量成本和带宽,容器应用的负载均衡，可以利用SLB服务，进行流量分发，提升应用的可用性,支持跨可用区（AZ）的应用部署，在保证性能的前提下最大程度的提供应用的可用性。在存储支持上：容器应用的持久化数据可以直接利用云盘提供的块存储或OSS提供的对象存储能力，覆盖不同存储场景需求。
容器服务的一个出发点就是拥抱生态，兼容现有的Docker API，Docker命令行和基于Docker API的三方工具；支持所有Docker Image, Docker Compose模板；这些最大限度的重用用户已有的技术资产，也大大降低了上云的成本
- 器技术不是银弹解决不了所有问题；目前而言，容器服务对于无状态的应用类型是非常适合的，但对于数据库等有状态的服务，完全基于容器的管理和运维还是比较有难度的。阿里云容器服务会让用户在容器编排中，方便的引用阿里云的RDS，KVStore等服务实例；这样无需对现有容器化应用做修改就可以连接用成熟的云服务。
CSDN:能否介绍下你们在打造阿里云容器过程中遇到的坑，你们做了哪些重点改进？
微垣:其实我个人不喜欢使用踩坑这些词 :-)，因为我们团队的使命就是搭桥修路，帮助用户少走些弯路，更好的利用容器技术解决实际问题；我们团队也很享受这样的探索和成长历程。
在我们的工作中，如果是对于Docker基础设施的修复，我们会及时将修复贡献到社区： 比如我们在内部使用Registry V2进行镜像管理，我们发现在大镜像上传方面存在性能问题，我们修复了其上传过程中冗余校验的问题大大加快了上传性能；其他还有libnetwork无法支持发现服务支持子目录，Swarm调度逻辑缺陷等等，我们的修正都已合并到社区版本。
在和容器编排等应用领域紧密相关的问题，我们会在兼容现有Docker生态的基础上（支持Docker API，镜像，编排模板），根据提供一些扩展来简化典型场景，提供很多接地气的特性：
比如，我们支持跨宿主机节点容器之间的链接，这样用户可以方便的利用Docker Compose模板部署一个分布式应用。另一个例子，很多应用需要等待所依赖的服务启动才能正常运行，在官方Docker和Compose模板中， 只能通过容器连接描述容器的启动依赖，而容器启动并非意味着其内部服务能够提供服务，很多时候会导致应用启动失败，利用阿里容器服务，用户可以简单的（利用label）定义服务间的依赖顺序
同时阿里云自身发展过程中，已经积累了很多技术优势：比如在容器集群资源调度方面，我们的调度逻辑能够更好的支持应用的部署约束，比如跨AZ的约束、服务间约束、运行时动态添加节点标签等。2015年阿里云飞天平台在国际排序竞赛夺冠，资源调度是关键技术，未来我们会逐渐加强这方面的能力为用户提供更好的资源管理能力。
CSDN:平台在调度、网络、存储以及安全等方面使用到哪些关键技术？
微垣:编排和生命周期管理：兼容Docker Compose模板，并完善的生命周期管理;
集群管理，资源调度：Swarm集群管理方案的基础之上，做了大量的改进、扩展和优化的调度;
网络：利用Docker libnetwork的扩展机制，提供针对阿里云的网络存储插件支持VPC网络等;
存储：利用Docker volume扩展机制，支持云盘提供的块存储，支持OSS为基础的分布式文件存储.
CSDN:在平台打造过程中，哪些问题是Docker目前无法解决的？你们的解决方案是怎样的？
微垣:目前Docker还是有几个问题还是会给客户造成影响：比如，Docker Engine目前还有单点失效问题，Engine失效或更新会导致一个节点上所有容器终止；另外Docker容器目前还无法再节点之间方便的迁移，这阻碍了对应用进行动态调度和可用性的需求。
但是Docker发展很快，这些问题也都在社区的日程表上，已经计划在利用runC改造libcontainer之后支持。
目前我们会采用务实方法解决这些问题，比如建议用户在应用层进行调整，将应用逻辑和持久化状态分离，这样无状态的应用可以轻松的分布式部署，或者当容器失效了可以在其他节点拉起并利用分布式存储能力保持数据不丢。同时通过良好的资源调度和自动化故障恢复降低对用户的影响；
在阿里云内部，也有一些前沿性的工作在进行，探索容器技术和虚拟化技术更好的结合。
此外Docker和我们自身大量的组件都采用Go开发的，为了确保系统间RESTful API通信的安全性，所有跨防火墙的通信都基于HTTPS。但是Go 1.5和之前的版本都没有包含CPU指令级别对SSL加速能力，导致HTTPS性能很差，我们是通过在负载均衡服务实现SSL termination来降低CPU加解密压力。期待今年Go 1.6出现后，新的加密解密包能够改善Go应用HTTPS性能。
CSDN:目前，阿里内部有哪些业务使用了Docker？能介绍下目前的一些应用情况吗？
微垣:阿里内部使用容器的业务很多，比如:
蚂蚁金服利用容器技术提供金融解决方案，提高资源的利用率与交付速度，并用来隔离底层IaaS的不同;
阿里应用托管平台ACE底层也是利用容器服务提供PaaS解决方案，实现资源隔离，为用户提供完整软件开发生命周期的支持;
阿里云内部的服务管控系统，也越来越多基于Docker方式部署和管理，提升系统的运维效率。
CSDN:随着Docker官方安全和网络问题的逐渐解决，你认为docker进入生产环境还有哪些门槛或者挑战？
微垣:容器技术在2015年有了巨大的进步:Registry V2让镜像管理更加安全、有效；Docker提供了更多的可扩展性，日志、网络、存储的插件结构可以适应更加广泛的场景；Docker工具链和编排技术的完善，大大拓展了Docker技术的范围；开放容器计划(Open Container Initiative) 让整个产业界达成共识，在开放的框架下共谋发展；
但是目前还有很多用户在观望如何在生产环境中使用容器应用；2015年O’Reilly的调查问卷中，指出了阻碍用户在生产环境使用Docker技术所面对的三个主要挑战
第一个就是容器技术自身的成熟度：
比如拿Docker 1.9推出的libnetwork，虽然支持的跨节点overlay网络的支持是一个巨大的进步，但是还有很多不足，比如容器间域名解析发现要到将要发布的Docker 1.10才能比较完善；同时跨节点网络性能依然存在问题，我们需要结合虚拟化技术一体解决； Docker自身的安全性虽然已经得到很大提升，但是依然需要继续增强：比如用户名空间的支持还在试验阶段；对容器镜像的渗透检测、来源追踪、授权管理等对生成环境管控很重要，但目前相关工具和产品还不完善等等
当然，作为一个理性的乐观派，我们相信随着整个社区的努力会逐渐解决这些问题。
第二个问题是服务编排刚刚起步
Kubernetes, Mesos，Docker Swarm等不同的编排模型都在起步，都有适用的场景和需要改进之处；这个方面我们也会和社区一起推动把这些技术完善和成熟起来。
第三个问题是管控能力的缺失
在分布式环境下，对动态容器进行应用管理、监控、日志收集对依然存在挑战；目前Docker原生方案，流行的开源方案还有很多初创公司都在提供自己的解决方案试图解决这些问题。在应用架构层面，微服务架构一方面很好的解决了移动互联网时代对扩展性和敏捷性需求；但另一方面由于分布式系统和弹性部署的引入增加了运维的复杂性，同时可能造成技术的碎片化；这就需要容器平台能够更加自动化的进行运维，为用户提供以应用中心的管控视图。
在和用户的交流过程中，我的一个切身感受是：很多用户还急需一些系统化指导和实践经验来帮助容器技术落地。
在国内一些互联网公司、初创企业和大型科技企业，由于有强烈的业务驱动和很好的技术储备，他们成为了容器技术的先行者。但是还有更多企业和开发者才刚刚开始尝试容器技术，需要社区和产业界一起努力从软件架构，开发测试，到部署运维各个方面帮助用户解决容器化应用的实际问题，带来实际的效益和价值。
责编：魏伟，关注Docker和openstack，欢迎加入我们CSDN微信群交流，搜索微信号“k15751091376”拉入，备注姓名和公司。