在生产环境中，单个主机上的Docker Swarm与Docker Compose相比如何选择？

Question

在生产环境中，部署单个主机时，是否有使用docker-swarm的原因而非使用docker-compose?

我正在重写一个已有的应用程序。我的前任使用docker-swarm来设置应用程序。但我不明白为什么: 应用程序只包括单个主机运行几个服务。这些服务将通过REST-API向Kubernetes集群提供客户网络上的一些本地信息（因此没有真正的负载或添加其他主机的理由）。

我查看了Docker网站，除了在单个主机dev环境中测试部署外，没有找到使用docker-swarm来部署单个主机的原因。

与使用docker-compose相比，使用docker-swarm在部署、网络等方面是否有优势?

- fradeco

Answer 1

Docker Swarm和Docker Compose本质上是不同的工具。Compose是一个构建工具，它允许您定义和配置一组相关容器，而swarm是一个编排工具，以一种让您可以将多个Docker引擎(有些)视为单个单位的方式管理这些引擎。Swarm公开了一个API，它与Docker远程API大多兼容，这使得现有应用程序可以使用Swarm进行水平扩展，而无需完全改造容器引擎的现有接口。

也就是说，Docker Compose中与Docker Swarm重叠的许多功能是逐步添加的。Compose随着时间的推移发展壮大，两者之间的区别有所缩小。最终将Swarm集成到了Docker引擎中，并引入了Docker Stack，它允许直接使用Docker读取compose.yml文件，而无需使用Compose。

因此，真正的问题可能是：docker compose和docker stack之间有什么区别？ 没有太大区别。Compose实际上是一个独立的项目，用Python编写，在内部使用Docker API。Stack和Compose执行很多相同的任务，但已经集成到Docker中。Stack还需要预先构建的镜像，而Compose会为您处理这些镜像构建，这使得Compose对于开发非常方便。

您正在处理的可能是这两个工具更为不同的时期的产物。Docker Swarm是Docker的一部分，如果需要轻松进行扩展(即使您现在不需要，将来也可能需要)。另一方面，Compose(依我之见)对于您正在对镜像进行频繁调整和重建的开发情况更有用。

- Z4-tier