InfoQ：持续交付一直是敏捷的终极目标，DaoCloud的官网也提出了这样的口号：『让应用交付更便捷』，你们是如何面对不同的行业和技术栈，实现更便捷的交付的？

郭峰：提高用户的持续交付能力，DaoCloud 拥有两大法宝，Docker 容器技术和最佳实践的自动化。 以 Docker 为代表的容器技术自2013年起在 IT 领域得以迅猛发展，Docker 之所以受到巨大的关注一个重要的原因就是 Docker 不仅仅是一个容器技术，它还提出了应用的统一交付件－Docker 镜像。基于 Docker 镜像交付的应用，可以跨平台的无差别运行，这一点为持续交付奠定了重要基础。

之前企业实施 CI／CD 很难，尤其是在应用微服务化的大背景下，企业应用是由很多个服务组件组成的，由不同开发部门开发的服务组件使用的技术框架都各不相同，对测试部署环境的要求也千差万别，这种差异性使得持续交付流程必须对各个服务组件提供专门的集成，这样不可避免造成实施持续交付非常难，需要企业持续的投入。当我们的应用的交付方式都是容器镜像，运行方式都是容器，那我们就很容易的在多样化的应用组件中找到统一点，持续交付流程中针对不同技术栈的多条羊肠小道，都归结到仅面向 Docker 容器的康庄大道。 不同行业的应用，虽然它们解决的问题，所处的领域都很不一样，但是应用的开发测试发布流程却差别不大。

【DaoCloud 的工程师根据多年在企业应用开发中积累的经验，总结出了企业应用持续发布的最佳实践，并把这些最佳实践物化到了产品功能上，用户在 DaoCloud 应用平台上的应用，从代码托管，持续集成测试，应用版本控制到应用最终发布都在潜移默化的遵循着最佳实践流程，并且整个流程都能够高效的自动化运行，把最佳实践的门槛降到最低，这样就实现了迅速提升用户持续交付能力，让应用交付更便捷的目标。 】【这段可以略去，如果可以的话，再补充下上面说的】

InfoQ：相对于传统的GAE式的服务，容器云有什么样的优势？

郭峰：在 DaoCloud 之前，我在 PaaS 领域工作了很多年，当时遇到的最头疼的两个问题，一是为了上云，用户的应用实现需要做适配；二是出现问题，帮用户定位问题很困难。第一个问题是因为缺乏统一标准，各个云对应用的要求不一样，在本地可以跑的应用在云上不能跑，在一个云上能跑的应用在另外一个云上不能跑，这无疑会提高用户应用上云的门槛。第二个问题是PaaS平台要承载各种不同语言不同框架编写的应用，一旦用户的应用在你的平台起不来或者出现问题，虽然绝大部分问题都是应用自己的问题导致的，但是你不得不深入应用实现去帮助用户定位问题，这对云应用的管理维护带来了巨大挑战。

基于容器的应用云平台从根本上解决了这两大难题，容器的跨平台无差别运行的特性使得只要用户的应用容器在本地可以跑，调度到云端后肯定可以跑，而且跑出来的应用行为是一致的。这样，应用上云不需要做适配，本地可以跑，无需修改轻松云化，而且PaaS平台不需要在关心应用实现细节，仅需对容器负责，用户和PaaS云平台的接口被统一到了容器上。

InfoQ：你们在自动化运维领域有哪些实践？

郭峰：随着 DaoCloud 平台规模的扩大以及提供服务的多样化，我们的部署规模已经由初期的几台服务器发展到了横跨4个数据中心的大规模混合云部署，这对 IT 运维管理，实施质量和响应速度都提出了很高的要求，传统的人工运维方式不仅运维质量不能保证，而且响应时间也不能满足平台动态弹性需求。
尤其是作为一个初创企业，人少事多不可避免，这也倒逼我们仅有的半个运维人员（一半时间是开发）摸索了一套标准化，自动化运维流程。首先，DaoCloud 平台是有超过 40 个微服务组成的，各个服务所使用的编程语言和技术框架各有不同，为了从各个语言的差异性中解脱出来，我们要求所有的DaoCloud平台组件都是Docker化部署的，组件的开发人员的职责延伸到组件整个生命周期，开发人员不仅要对代码负责，还要提供一整套支撑组件运行的配置，包括容器镜像，Docker Compose描述文件等，这样运维能力仅需要围绕容器生命周期管理进行。其次，平台弹性扩展过程完全自动化，对于一个云平台，平台的弹性扩展是平台运维的最常见的任务之一，扩展自动化不仅能够更快响应弹性需求而且还减少了人为操作失误的可能性，当然这个也对云平台的实现提出了挑战，支持弹性的组件以及其他相关组件，要支持服务注册和自发现。

InfoQ：对于部署在DaoCloud上的应用，是如何得到安全保障的，DaoCloud提供了哪些监控手段？

郭峰：首先，容器技术本身就会对现有应用的安全性起到一定的增强，在容器中运行的应用拥有完全独立的进程树，文件系统以及命名空间，再加上容器使用资源的限制，使得应用容器间互相影响的可能性降到最低。其次，在网络层面我们还采用了白名单安全策略，仅平台允许的访问请求才会被分发到应用容器中，同时容器间的访问也是被严格限制的。最后，为了应对公有云上的各种恶意应用，平台会实时监控容器的运行状态，一旦发现可疑应用容器，就会触发自动化应对策略，谨防恶意应用影响其他用户应用容器。【安全这块可以细谈吗，因为大家都知道目前安全问题是容器的弱项】

InfoQ：分布式的应用，如何在DaoCloud上得到统一的日志服务？

郭峰：应用日志是检查应用状态，排查问题的重要依据，提供应用日志是应用云平台必须要提供的一个功能，同时也是一个很大的挑战，尤其是面对一个分布式应用，应用由多个容器组成，容器分布在不同的部署节点上，我们不仅要保持log的实时性还要高效准确的归集属于相同应用不同容器产生的日志。我们的做法是所有容器的日志通过标准化的syslog协议发送至一个专门的日志收集组件，这个组件能够高效分析处理日志元信息，根据应用对日志做归集并添加必要元信息，再存放在支持高速查询的日志存储系统中。当用户查看应用日志时，通过日志存储系统查询应用日志，从而实现高效统一的日志服务。【如果这里有个图就更好了】

InfoQ：对于部署在DaoCloud上的应用，是如何得到伸缩性支持的，是否有良好的容错机制？

郭峰： 我们从设计的第一天就考虑了对应用伸缩性的支持，不仅能做到便捷的不终止服务前提下的应用弹性伸缩，还在应用容器放置策略上考虑了很周详的容错机制，把应用当机的可能性降到最低。首先，容器放置策略上，我们尽量把应用的不同容器放置在不同的可用区中，相同可用区中的容器也尽量分布在不同的部署节点上，这样当某个意外发生时，把应用受影响的容器控制在一定范围内，保证了应用不当机。同时，我们还实时监控应用的容器状态，当发现容器状态和期望的不一致，自动触发应对策略，保证应用容器按照计划运行。【这里可否展开谈下伸缩性这块，从容器编排或者架构谈】