docker-compose是什么
Compose是定义和运行多容器Docker应用程序的工具。 使用Compose，您可以使用YAML文件来配置应用程序的服务。 然后，使用单个命令，您可以创建并启动配置中的所有服务。
Compose适用于所有环境：生产，开发，测试以及CI工作流程。使用Compose基本上是一个三步过程：
- 使用Dockerfile定义应用程序的环境，以便在任何地方进行复制。
- 在docker-compose.yml中定义组成应用程序的服务，以便它们可以在隔离的环境中一起运行。
- 运行docker-compose并撰写开始并运行你的整个应用程序。
可以参考docker-compose官方说明详细了解：https://docs.docker.com/compose/overview/
还没有完全理解的朋友，用通俗的语言来说：
docker-compose 是用来做docker 的多容器控制，docker-compose 是一个用来把 docker 自动化的东西，有了 docker-compose 你可以把所有繁复的 docker 操作全都一条命令，自动化的完成。来看看下面这张图你也许又能更好的理解了：
从上图可以看到，这位compose哥们非常开心的把N多个容器抓在一起，根据自己的心情来编排部署。
谈谈容器编排与部署
?Docker有很多优势，但对于运维或开发者来说，Docker最大的有点在于它提供了一种全新的发布机制。这种发布机制，指的是我们使用Docker镜像作为统一的软件制品载体，使用Docker容器提供独立的软件运行上下文环境，使用Docker Hub提供镜像统一协作，最重要的是该机制使用Dockerfile定义容器内部行为和容器关键属性来支撑软件运行。
?Dockerfile作为整个机制的核心。这是一个非常了不起的创新，因为在Dockerfile中，不但能够定义使用者在容器中需要进行的操作，而且能够定义容器中运行软件需要的配置，于是软件开发和运维终于能够在一个配置文件上达成统一。运维人员使用同一个Dockerfile能在不同的场合下“重现”与开发者环境中一模一样的运行单元（Docker容器）出来。
为什么要使用Compose
?先来想一下我们平时是怎么样使用docker的？把它进行拆分一下：
1、docker search 镜像，是不是先查找一个镜像；
2、docker run -itd 镜像名称 ，然后在运行这个镜像；
3、然后如果你要在运行第二个镜像、第三个镜像.....等等镜像，你是不是又要docker search、docker run运行。
?上面“ docker run it 镜像名称 ”这只是最小的动作， 如果你要映射硬盘，设置nat网络或者映射端品，等等…你就要做更多的 docker 操作， 这显然是非常没有效率的，况且如果你要大规模部署，是不是觉得就很麻烦了。
?但是我们写在 docker-compose.file 里面就很好了。你只需要写好后只运行一句：
?docker-compose up -d
?一切都是那么的简单！！！
了解下编排和部署
编排，即orchestration，它根据被部署的对象之间的耦合关系，以及被部署对象环境的依赖，制定部署流程中各个动作的执行顺序，部署过程所需要的依赖文件的存储位置和获取方式，以及如何验证部署成功。这些信息都会在编排工具中以指定的格式（比如配置文件或者特定的代码）来要求运维人员定义并保存起来，从而保证这个流程能够随时在全新的环境中可靠有序地重现出来。
部署，即deployment，它是指按照编排所指定的内容和流程 ，在目标机器上执行编排指定环境初始化，存放指定的依赖和文件，运行指定的部署动作，最终按照编排中的规则来确认联署成功。
这么来解释吧，编排是一个指挥家，他的大脑里存储了整个乐曲的演奏流程，对于每一个小节每一段音乐的演奏方式、开始、结束他都了然于胸；部署就是整个乐队，他们严格按照指挥家的意图用乐器来完成乐谱的执行，在需要时开始演奏，又在适当的时机停止演奏。最终，两者通过协作就能把每一位演奏者独立的演奏通过组合、重叠、衔接来形成高品位的交响乐。
而在Compose的世界里，编排和部署的组合结果，就是一朵“容器云”。
一探究竟~~ Compose原理
docker-compose的调用过程扁平的像一张纸，仅用一张简单的模块图就足够解释明白，如下图所示：
?首先，用户执行的docker-compose up指令调用了命令行中的启动方法。功能很简单明了，一个docker-compose.yml定义了一个docker-compose的project，docker-compose操作提供的命令行参数则作为这个project的启动参数交由project模块去处理。
?其次，如果当前宿主机已经存在与该应用对应的容器，docker-compose将进行行为逻辑判断。如果用户指定可以重新启动已有服务，docker-compose就会执行service模块的容器重启方法，否则就将直接启动已有容器。这两种操作的区别在于前者会停止旧的容器，创建启动新的容器，并把旧容器移除掉。在这个过程中创建容器的各项定义参数都是从docker-compose up 指令和docker-compose.yml中传入的。
?接下来，启动容器的方法也很简洁，这个方法中完成了一个Docker容器启动所需的主要参数的封装，并在container模块执行启动。该方法所支持的参数我想大多数朋友过是有所了解的。
?最后，container模块会调用docker-py客户端执行向Docker daemon发起创建容器的POST请求，再往后就是Docker处理的范畴了，相信看过我这篇文章 Docker：架构拆解请添加链接描述 的朋友就明白了。
总结思考
大家想想，仅仅使用Compose，就可以构建自己的容器云吗？答案显然是否定的。docker-compose解决的问题局限在“编排”二字，甚至连“部署”范畴都涉足甚少，而在一个能够服务于大众的云平台中，编排与部署也仅仅是其中的一个组成部分而已。来一起分析一下它的局限制会有哪些：
- docker-compse是面向单宿主机部署的，这是一种部署能力的欠缺。在更多的场合下，管理员需要面对大量物理服务器（或者虚拟机），这时如果要实现基于docker-compose的容器自动化编排与部署，管理员就得借助成熟的自动化运维工具（ansible、puppet、chef、saltstack）来负责管理多个目标主机，将docker-compose所需的所有资源（配置文件、用户代码）交给目标主机，然后在目标主机上执行docker-compose指令。
- 同样网络和存储也比较棘手，Docker不能提供跨宿主机的网络，完全面向Docker daemon的docker-compose当然也不支持。这意味着管理员必须部署一套类似于Open vSwich的独立网络工具，而且管理员还需要完成集成工作。当好不容易把容器编排都安排妥当之后，又会发现容器还处在内网环境中，于是负载均衡、服务发现等一堆问题就面临而来了，这些问题很快能消耗掉工程师所有的耐心。
那么，是否有一种能够提供完善的面向服务器集群的Docker编排和部署方案呢？Docker官方给出的答案是Compose同Machine和Swarm联动，其实还有大家近期经常听到了kubernetes（k8s）。后期笔者会更新出这些内容和大家一起来讨论。
原文地址：http://blog.51cto.com/ganbing/2083806