docker-swarm与docker-compose在生产中的单个主机上

Question

是否有理由在生产中的单个主机上使用docker-swarm而不是docker-compose？

我当前正在重新创建一个已经存在的应用程序。我的前任在docker-swarm上设置了应用程序。但是我不明白为什么：该应用程序仅由运行几个服务的单个主机组成。这些服务将仅通过REST-Api向kubernetes集群提供客户网络的一些本地信息（=>没有实际负载/没有理由添加其他主机）。

与docker-compose相比，使用docker-swarm在部署，网络等方面有好处吗？

我浏览了docker网站，找不到用于在单个主机上使用docker-swarm的原因，appart vom在单个主机开发环境中测试了部署。

Answer 1

Docker Swarm和Docker Compose本质上是不同的动物。 Compose是一个构建工具，可让您定义和配置一组相关的容器，而swarm是一个编排工具，以某种方式管理多个Docker引擎，使您（某种程度上）将它们视为一个单元。 Swarm公开了一个与Docker Remote API大部分兼容的API，该API允许现有的应用程序使用Swarm进行水平扩展，而不必完全检修到容器引擎的现有接口。

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

所以真正的问题可能是： docker compose和docker stack有什么区别？不是很多。实际上，Compose是一个单独的项目，用Python编写，在后台使用Docker API。堆栈与Compose具有许多相同的功能，但已集成到Docker中。 Stack还需要预先构建的图像，而compose会为您处理这些图像构建，这使得compose非常便于开发。

您正在处理的可能是这两种工具截然不同的时代的产物。 Docker Swarm是Docker的一部分，它允许在需要时轻松扩展（即使您现在不需要它，在将来也可能会很不错）。另一方面，Compose（无论如何，我认为）对于需要对图像进行频繁调整和重建的开发情况非常有用。