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

Question

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

我目前正在重写现有的应用程序。我的前辈使用 docker-swarm 设置了应用程序。但我不明白为什么：该应用程序将仅由运行几个服务的单个主机组成。这些服务只会通过 REST-Api 向 kubernetes 集群提供客户网络上的一些本地信息（因此没有真正的负载或添加额外主机的理由）。

我浏览了 Docker 网站docker-swarm，除了在单个主机开发环境上测试部署之外，找不到用于部署单个主机的理由。

与部署、网络等docker-swarm相比，使用是否有好处docker-compose？

Answer 1

Docker Swarm 和 Docker Compose 是根本不同的动物。Compose 是一种构建工具，可让您定义和配置一组相关的容器，而 swarm 是一种编排工具，可管理多个 docker 引擎，让您（在某种程度上）将它们视为一个单元。Swarm 公开了一个与 Docker 远程 API 大部分兼容的 API，它允许现有应用程序使用 Swarm 进行水平扩展，而无需彻底改造现有的容器引擎接口。

也就是说，Docker Compose 中与 Docker Swarm 重叠的大部分功能都是增量添加的。随着时间的推移，Compose 不断发展，两者之间的区别已经缩小了一点。Swarm 最终被集成到 Docker 引擎中，并引入了 Docker Stack，允许compose.ymlDocker 直接读取文件，而无需使用 Compose。

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

您正在处理的可能是这两种工具更加不同的时代的产物。Docker Swarm 是 Docker 的一部分，如果需要，它允许轻松扩展（即使您现在不需要它，它可能会很好）。另一方面，Compose（在我看来）对于经常调整图像和重建的开发情况更有用。