Docker Machine, Swarm,和Compose编排分布式应用
基于下面的需求：
1. 虽然单个Docker容器能够100%移植到任何平台，但是如何确保多容器分布式应用也是100%可移植？涵括范围从准备阶段到生产阶段 或跨数据中心，或在公有云之间。
2.我们已经实现Docker标准化，但是如何在这些标准之上能够拓展 Docker生态系统的广度和深度？
3.如何重构应用程序交付流水线以便支持基于容器的快速迭代?
4.将传统整体型monolithic应用分解为微服务以后，有更多的组件需要跟踪和管理，Docker生态系统如何帮助我们做到？
Docker Machine, Docker Swarm, 和Docker Compose. 这三个组件分别覆盖分布式应用整个周期的不同阶段。并且是可以串联起来。
Docker Machine
Docker Machine能让你使用一个命令在几秒内直达Docker，(zero-to-Docker).
在Docker Machine之前, 一个开发者会需要登录主机，按照安装配置指令来对其主机和操作系统进行安装和配置。而如果使用Docker Machine, 无论是想让一个Docker守护进程后台运行在笔记本上或数据中心虚拟机中或一个公有云实例里，所有都是使用同样一个命令：
% machine create -d [infrastructure provider] [provider options] [machine name]
这个命令是在目标主机创建运行Dcoker容器，使用相同的接口，您可以管理多个Dcoker主机，无论它们的位置在哪里，你都可以在它们上面运行任何Docker命令。
Docker Machine的后端可插拔性允许用户充分利用Docker生态系统合作伙伴提供的Docker-ready基础设施，同时还可通过相同的接口访问这些基础设施。 这个驱动程序API可以让Docker工作在本地机器上或在数据中心的虚拟机或在一个公共云的实例上。 在这个Alpha版本中，Docker Machine附带驱动程序配置范围从本地Docker到Virtualbox以及远程数字海洋的实例；更多驱动库还包括AWS,Azure,VMware和其他基础设施。
请注意，Docker Machine与Docker引擎是分离的一个单独的项目。尝试 Docker Machine和驱动库巴见：仓储。
Docker Swarm
Docker Swarm是一个Dockerized化的分布式应用程序的本地集群。 它是继续DockerMachine后续步骤，实现优化主机资源利用率和提供故障转移服务。 具体地说，Docker Swarm允许用户创建主机的资源池来运行Docker守护进程，然后调度Docker容器在资源池上的运行，自动管理工作负载位置和维护集群状态。
Docker默认调度器是根据所在集群主机的可用的资源作为调度资源需求，然后使用 bin pack 自动优化所在位置的工作负载。 例如,我们如何安排一个Redis容器所需求的1 g内存？
% docker run -d -P -m 1g redis
为了支持特定的需求和基于策略的调度，Docker Swarm还提供了标准和自定义约束。 例如,说，为了确保你想要在SSD存储主机上运行MySQL容器的良好I / O性能， 你可以在调度MySQL工作量时表达约束如下:
% docker run -d -P -e constraint:storage=ssd mysql
除了资源优化，Docker Swarm提供高可用性和故障转移。 Docker Swarm不断检查Dockerde守护进程所在主机的健康，一旦发现其停机就会自动调整，通过转移后重新在一个新主机上启动失败的Docker容器。
Docker Swarm的独特的方面之一是它可以扩展应用程序的生命周期，这意味着开发人员可以从一个主机到“集群”，实现维护的一致接口应用，也可从1个主机扩展到2个甚至20或200主机。
最后，Docker Swarm有一个可插拔的架构，包括一个默认调度器。 为此，可以与中间层建立伙伴关系，Mesosphere 的Mesos可以成为Docker Swarm的“一等公民”实现着陆其平台上的Docker容器的负载。不管底层的调度器如何实现，接口对应用程序都保持一致，这意味着应用程序移植仍然是100%。
Docker Compose
Docker Compose是整个编排系统的最后一块拼图。 使用Docker Machine保证Docker守护进程能在任何位置的主机上运行，使用Docker Swarm对它们实现集群，现在可以使用Docker Compose在这些集群上组装运行多个容器的分布式应用。
第一步是使用Docker Compuse是通过一个简单的YAML文件来声明定义多个容器应用的情况状态:
containers:
web:
build: .
command: python app.py
ports:
- "5000:5000"
volumes:
- .:/code
links:
- redis
environment:
- PYTHONUNBUFFERED=1
redis:
image: redis:latest
command: redis-server --appendonly yes
<p class="indent">
|
这个例子显示了Docker Compose利用现有的容器的优点。 具体地说，在这个简单two-container应用声明配置文件中，配置了第一个容器是一个Python应用程序，每次从Dockerfile的当前目录构建。 配置的第二个Docker容器是从Docker Hub注册中心的redis官方仓储中构建。 links指令定义了Python应用程序容器取决于Redis容器的依赖关系。
启动应用很简单…
% docker up
通过这种简单的命令，Python容器将被Dockerfile自动构建，同时从注册中心拉取Redis容器构建。 links 指令表达的是Python和Redis容器之间的依赖关系，Redis容器是最先开始*first *构建，紧随其后的是Python容器。
目前这一项目还在开发中，Github
参考：使用Mesos和Marathon管理Docker集群
[该贴被banq于2014-12-06 08:42修改过]
分布式从Corba 到Java的EJB再到Docker，EJB因为将分布式的特点强加入到开发中，实际是最早的DevOps雏形，但是很多人不买账，因为他们不需要分布式部署集群，放在一台服务器上即可，不愿意为了运行时的扩展性牺牲开发的便利性。
因此， Spring这样的开发框架受到普遍欢迎，但是随着的规模发展，就产生了整体性monolithic铁板一块的大的模块系统，迁一动百，而且为了维护修改某个小功能，需要重启整个开发测试发布流程，非常重量。
Node.JS代表的直接基于端口的微服务开始受到欢迎，每个微服务器其实就是相互解耦的、且是有界上下文的服务，说白了，原来一个几百行 N多个组件类的大服务切割成一个个小服务了，彼此独立维护，每个微服务是一个小组team，自己可以独立开发测试和发布，而且可以用不同语言。
但是问题又来了，微服务数量增加以后，一台服务器肯定放不下，这就需要分布式部署，当初EJB分布式集群特性被否定之否定地提高再利用了。
使用一个Docker装一个微服务，而且不管这个Docker+微服务运行在本地 还是分布式环境 还是亚马逊这样公有云上，这些对于开发都是屏蔽的，这才是好的DevOps技术，虽然运营很重要，但不能像EJB那样粗暴干涉开发，使用Docker+微服务，开发者可以不管自己的微服务运行在单机还是云平台上，运营环节只要给其微服务配置上Docker，就可以游走无阻力了。
Docker+微服务也改变了DveOps的传统开发模式，DevOps顾名思义是开发运营合并，因此造成了一个产品队伍从开发到测试 部署和运营，数据库管理员等都存在，而改变以后的产品队伍变成了：微服务团队+平台团队，平台团队负责运营 数据库管理等等，每个微服务队伍只要提交Docker+微服务即可，微服务团队和平台团队之间通过API通讯，这样做到更大的松耦合。
Docker+微服务真正让业务内容和平台设计分离，帮助有实力的公司组织走向平台运营为主的互联网经营模式。
