本文主要从docker的编排技术，docker在一个大规模生产环境中的使用开始切入，围绕docker应用的深化，像谷歌，aws，阿里云都推出了这样的容器服务，分享并分析了新的概念——container as a service，着重讲解了微服务支持和devops，并谈及了容器服务解决了哪些问题，最后介绍了docker的最新发展趋势。
以下为整理内容：
docker编排技术
大家都已经了解了docker是什么样的技术，<b>docker</b><b>是标准化的构建、交付、运维手段。</b>但直到今天还有很多人在质疑，docker只不过是容器技术的一种实现，为什么会这么火呢？
<b> </b>
<b>docker</b><b>最大的价值不在于技术，而在于它使人们达成了某种共识，</b>以一种标准化的方法来开发、交付和运维软件，使得把我们的应用和应用运行过程中的依赖打成docker镜像，通过docker镜像，我们可以在开发、测试、线上等各个阶段来使用，我们也可以在笔记本、测试机或是云上来运行程序。通过这个标准化，催生了一个巨大的生态，让docker具有巨大的价值。
docker的核心亮点有以下几个方面：
<b>敏捷</b>：秒级应用启动、轻量级隔离、细粒度资源控制、低性能损耗。
<b>可移植性</b>： 环境无关的交付、部署方式；可用于软件生命周期中不同运行环境。
<b>可控</b>：标准化推动自动化，提高运维效率和规模；隔离性提升应用安全性；版本管理可追溯。
docker与虚拟化技术
docker不是虚拟化技术的颠覆者，docker容器和虚拟化技术是互补、双赢的。docker是一种轻量级的操作系统虚拟化方案，利用虚拟机提供弹性基础架构，更好的安全隔离，动态热迁移，可以更好的保证业务的安全性和连续性，而利用容器技术也可以简化迁云之路，实现无边界的云计算。
docker本身巨大的成功是根据几个巨大的趋势结合在一起才凸显了它的价值。docker重点介绍3个方向，docker在云计算上扮演着重要的工作，还有（microservices）微服务架构，企业最关心的是it部门的效率，最快速度的交付产品、最低成本的试错，才能快速的迭代、快速的演进，微服务架构可以帮助企业走向这步，微服务架构给底层的基础设施和部署带来巨大的挑战，利用docker可以解决这个问题。devops，开发人员和运维人员理解的devops是不一样的，docker可以使二者结合在一起。
<b>容器编排</b><b> </b><b>——</b><b> docker compose</b>
docker引擎是把应用包装在一个docker镜像里，然后启动docker镜像变成一个容器，但是它带来的帮助是有限的，任何一个复杂的应用不是一个容器就能完成的，一定是一组容器相互协同才能完成一个完整的应用栈。docker compose是docker推出来的一个对多容器的编排技术，简单好用，便于开发。使用docker compose，可以一键构建本地开发环境，在团队中可以共享一份配置文件。
docker compose面向开发和部署，不支持自动化运维，只是面向单机的一个环境。docker compose目前还只是一个开发工具，能够帮助部署一个docker化的多容器应用，部署后它就置之不理了。
<b>容器集群管理</b><b> </b><b>——</b><b>docker swarm</b>
docker swarm的优点：<b>兼容标准的</b><b>docker api</b><b>，灵活、可插拔的容器调度</b>。
在生产环境中，我们希望有一个集群。从流量的角度，我们希望有更大规模能够部署更多的应用，在高可用的情况下，不可能把应用部署在只有一台节点的机器上。docker swarm把一组docker引擎抽象成一个docker引擎，以前所有在单机上对一个docker引擎的工作，都可以透明的变成对一组docker集群上的节点的操作。在docker swarm集群中，有两类节点，一是docker swarm managers，这些managers负责接收用户的请求，并且根据集群的状态来做一些任务的下发，真正的任务是在work节点完成的，每个work上都会安装一个agent,work会上报到一个分布式的kv里，告诉这个节点的状态是死是活，有了这些信息，manager就可以做决策。
docker swarm也有它的不足，它的抽象级别太低，<b>面向容器、缺少微服务支持。</b>
我们在把容器技术应用到大规模生产环境中时，依然会有众多的挑战。在生产环境中还需要考虑很多，比如，集群怎么管理，怎样更有效的调度来充分利用这些资源，怎样解决在这个集群中容器和容器互相的网络通信，不同应用对存储的需求等等。
containers as a service (caas 容器服务)
caas一方面提供容器化的环境，运行支撑环境来覆盖容器化应用的整个生命周期，从构建到交付到运维，它面对的目标用户不仅是开发者，也包括运维人员。在构建到交付阶段是持续集成和持续测试的能力，交付阶段一定是以容器的方式交付应用，在交付到运行阶段，也是使用容器化的方法进行应用的部署和运维。caas另一方面是以服务化的能力来提供docker的运行支撑环境，对于企业客户来说，用户只需关心容器的应用自身即可，而整个应用支撑的环境是由云平台提供出来的。
传统云计算金字塔中，paas层带来的简化性是以牺牲整个对环境控制的灵活性为代价的，导致paas平台的市场接受度很低。而docker和caas的出现恰好填补了这个缺口，在paas领域进行了重新定位，<b>实现了简洁性和灵活性间的完美平衡。</b><b> </b>
caas的主要服务提供商既有谷歌、亚马逊以及docker自身，也有国内的阿里云和很多其他的创业公司，每一家的caas都有自己的一些特色。
阿里云容器服务概念模型
容器服务上有三个层面的概念：
资源层面——集群，节点。
内容层面——compose模板，镜像。
应用层面——应用，服务，容器。
<b>集成容器和云服务</b>
完全兼容 docker compose/swarm
声明的方式支持容器及云服务
支持微服务架构<b> </b>
<b>阿里云容器服务</b>
阿里云容器服务为图中中间部分，最底层为容器层，阿里云容器层可以支持不同云环境下的基础设施，包括公共云、专有云以及混合云，利用docker自身很好的可移植性，可以实现无边界的云计算，除了docker引擎外，我们更加关注存储和网络的不同需求，所有的支持我们都可以通过声明的方式利用起来，我们也支持第三方的扩展。在容器层之上是调度层，调度层的概念是如何在容器集群上使得容器和下面资源能更好的协作来完成一个应用栈需要的各种各样的能力。调度层之上还需要做更高层的抽象，没有人在乎容器，大家在乎的是自己的应用是怎样构建的，是怎么对外提供服务的，我们就提供了很好的对微服务架构的支持，支持服务的注册发现、弹性伸缩、灰度发布和不间断升级。
有了这样的容器化平台，我们还可以对接现有的中间件服务和阿里云上的其它服务，以及集成ci/cd这样的三方工具，可以完整的支持软件的开发的过程。容器也不该成为企业it治理的孤岛，它会与现有的it流程、现有的it平台的管控进行一个良好的集成。
<b>跨主机容器网络</b>
在云上搭建网络有其自己的特殊性，阿里云的跨主机容器网络有如下几个特性：
每个容器在这个网络上都有一个独立ip
容器跨宿主机直接通信
容器网络可以通过dns解析容器地址
<b></b>
微服务架构
微服务就是把一个大而全的单体应用拆分成一组解耦的、自治的、协同工作的服务，这些服务通过标准化的借口互相通讯，每一个服务都是由一个团队单独的运维，它可以被独立的部署，每个服务的部署更新不会影响到其它的服务。
微服务在实际操作过程中会遇到种种问题，比如当应用拆分后，从运维一个服务变成运维多个服务，而这些服务又是被动态的分布在分布式环境里的，对这些服务进行管控、访问就变得比以前更加复杂。容器服务提供了两种弹性路由的方案，如下：
弹性web路由方案1
我们可以为每一个容器服务取一个二级域名，让服务能够通过二级域名的方式进行访问。我们提供了一个分布式路由服务，它会根据发现服务里定义的各种各样的路由规则，去生成相应的haproxy路由规则，当发生修改的时候能够动态的重新启动haproxy，让规则生效。路由服务之上对接的是slb，在slb上只要绑定一个根域名，下面部署的各种各样的服务就可以通过二级域名的方式动态的接进来。
弹性web路由方案2
有时候用户希望对slb端有更灵活的配置，方案2就是利用声明式的机制让不同的容器服务挂载到不同的slb上，发现服务里记录了整个集群上所有服务对外的路由的信息，cluster master会去侦听发现服务上整个路由的变化，并根据这些变化，自动的修改slb后端的服务器配置。
<b>实现无关的服务发现与负载均衡</b>
只是利用dns这样的发现机制是不够的，我们通过一种声明化的方法，能够让一个服务访问另外一个服务，和dns服务发现相比：
支持灵活的负载均衡策略
避免ttl问题
支持健康检查
<b>监控与</b><b>autoscaling</b>
声明式方式定义弹性伸缩策略。
内置云监控集成。
提供插件机制支持开源、三方监控集成。
devops
devops最重要的有两点。一是“在一起”，开发和运维应该是一体化来考虑的过程，开发人员交付的产品必须是运维人员能够部署上线的东西。二是要有快速持续的反馈。
<b>利用容器实现持续集成和交付 build once and deploy everywhere</b>
docker可以在一处构建，就可以在各个地方部署。docker镜像在开发中可以使用，可以在测试中使用，可以进行验证，可以进行上线，一切都是以docker镜像为交付物的。此外，利用compose模板，可以开发出部署的资源，标准化一致的在各个环境复用，以便进行持续的集成和部署。通过docker镜像和compose模板，可以把一个应用对外界的依赖，以及服务和服务之间的关联，全部变成可追踪的代码，这可以通过非常好的版本管理进行更好的管控，以便快速上线和回滚。
<b>完整的容器化持续交付流程</b>
未来发展趋势
<b>最好的方式来编排docker</b><b>就是docker</b><b>自身。</b>
docker engine已经内置编排能力，更新后的docker将具备以下四点特性：
<b>swarm mode</b>
<b>cryptographic node</b>
identity
<b>service api</b>
<b>built-in routing mesh</b>
<b>docker swarm </b><b>模式</b>
docker swarm mode是由一组docker
engine构成，每个docker engine都可能扮演两种角色中的一种，manager和worker。在一个集群上可以有多个manager，多个manager可以自己通过分布式的同步协议实现一个高可靠的state store。
<b>服务</b><b></b>
services
新的docker提供了一个services api。如果出现节点失败，在这个节点上的容器将会被自动迁移到其他节点之上。docker swarm mode采用状态逼近的模式，它定义了服务的期望状态，它会在运行过程中不断检查当前的状态是否和期望的状态保持一致，如果不一致，它就会自动修复。
<b>routing mesh</b>
在一个集群中，整个服务容器的部署是根据调度规则去进行动态调度的，任何一个服务的容器可能部署在集群中的任意一个节点上，新docker提供了routing mesh的能力，其特性如下：
每个服务一个vip
ipvs实现负载均衡
动态/手工分配publishedport
每个worker参与路由
<b>distributed application bundle </b><b>与</b><b> stack</b>
一个dab部署后就会生成一个相应的stack，一个完整的应用栈。dab实际是一个json文件，用与docker compose类似的方式描述了一组服务，通过一个dab就可以一键的通过一个deploy命令来生成一个相应的docker stack。