属性来支持软件运行。但是实际的生产环境往往需要定义数量庞大的 docker 容器，并且容器之间具有错综复杂的联系。手动的记录和配置这些复杂的容器关系，不仅效率低下而且容易出错。所以，我们迫切需要一种像 Dockerfile 定义 docker 容器一样能够定义容器集群的编排和部署工具。于是，Docker Compose 出现了(其实应该说 Fig 出现了，docker 收购了 Fig 并改名为 compose)。

文件和被部署文件的存储位置和获取方式，以及如何验证部署成功。这些信息都会在编排工具中以指定的格式(比如配置文件或特定的代码)来要求运维人员定义并保存起来，从而保证这个流程能够随时在全新的环境中可靠有序地重现出来。

内容和流程，在目标机器上执行环境初始化，存放指定的依赖文件，运行指定的部署动作，最终按照编排中的规则来确认部署成功。

》中演示了官方的示例，本文不再赘述，接下来我们去探索 compose 的工作原理。先来了解两个 compose 中常常提及的概念：

首先，用户执行的 docker-compose up 命令调用了命令行中的启动方法，功能非常简单。一个 docker-compose.yml 文件定义了一个 project，docker-compose up 提供的命令行参数则作为这个 project 的启动参数交由 project 模块处理。

然后，如果当前宿主机已经存在与该应用对应的容器，docker-compose 则进行行为逻辑判断。如果用户指定可以重新启动已有服务，docker-compose 就会执行 service 模块的容器重启方法，否则就直接启动已有容器。这两种操作的区别在于前者会停止旧的容器，创建并启动新的容器，并把旧容器移除掉。在这个过程中创建容器的各项自定义参数都是从 docker-compose up 命令和 docker-compose.yml 中传入的。

接下来，启动容器的方法也很简洁，这个方法中完成了一个 docker 容器启动所需的主要参数的封装，并在 container 模块执行启动。

最后，contaier 模块会调用 docker-py 客户端来执行向 docker daemon 发起创建容器的 POST 请求。

中提到的官方 demo)。

强制 recreate 删除现有的容器并且重新创建新的容器，为 docker-compose up 命令指定 --force-recreate 选项可以强制 recreate 容器：

删除了，docker-compose up 命令会新建相关的容器：

文章中进行介绍。