有什么理由不在单个节点上使用Docker Swarm（而不是Docker-Compose）？ [英] Any reasons to not use Docker Swarm (instead of Docker-Compose) on a single node?

问题描述

有Docker Swarm（现已内置到Docker）和Docker-Compose。人们似乎仅在单个节点上运行容器时使用Docker-Compose。但是，Docker-Compose不支持任何 deploy 配置值，请参见 https://docs.docker.com/compose/compose-file/#deploy ，其中包括 mem_limit 和 cpus ，它看起来很不错/很重要。

There's Docker Swarm (now built into Docker) and Docker-Compose. People seem to use Docker-Compose when running containers on a single node only. However, Docker-Compose doesn't support any of the deploy config values, see https://docs.docker.com/compose/compose-file/#deploy, which include mem_limit and cpus, which seems like nice/important to be able to set.

因此，也许我应该使用Docker Swarm ？尽管我仅在单个节点上进行部署。另外，其他人也可以按照安装说明进行操作（他们不需要安装Docker-Compose）。

So therefore maybe I should use Docker Swarm? although I'm deploying on a single node only. Also, then the installation instructions will be simpler for other people to follow (they won't need to install Docker-Compose).

但是也许有一些原因我应该这样做不是在单个节点上使用Swarm？

But maybe there are reasons why I should not use Swarm on a single node?

我在下面发布了答案，但是不确定是否正确。

I'm posting an answer below, but I'm not sure if it's correct.

_{编辑：请注意，这不是基于意见的问题。如果您看下面的答案，您会发现关于此的必须 和不能做 事实。}

_{Please note that this is not an opinion based question. If you have a look at the answer below, you'll see that there are "have-to" and "cannot-do" facts about this.}

推荐答案

对于开发，请使用Docker-Compose。因为只有Docker-Compose才能读取您的Dockerfile并为您构建映像。相反，Docker Stack需要预先构建的 images 。另外，使用Docker-Compose，您可以轻松启动和停止单个容器，使用 docker-compose kill ... 和 ... start .. 。根据我的经验，这在开发过程中很有用。例如，查看在终止数据库时应用服务器的反应。然后，您不希望Swarm直接直接自动重新启动数据库。

For development, use Docker-Compose. Because only Docker-Compose is able to read your Dockerfiles and build images for you. Docker Stack instead needs pre-built images. Also, with Docker-Compose, you can easily start and stop single containers, with docker-compose kill ... and ... start .... This is useful, during development (in my experience). For example, to see how the app server reacts if you kill the database. Then you don't want Swarm to auto-restart the database directly.

在生产中，请使用Docker Swarm（除非：见下文），以便您可以配置内存限制。 Docker-Compose的功能比Docker Swarm少（例如，没有mem或cpu限制），并且没有Swarm 没有的任何东西（对吗？）。因此，没有理由在生产中使用Compose。 （除非您可能知道Compose的工作原理，并且不想花时间阅读新的Swarm命令。）

In production, use Docker Swarm (unless: see below), so you can configure mem limits. Docker-Compose has less functionality that Docker Swarm (no mem or cpu limits for example) and doesn't have anything that Swarm does not have (right?). So no reason to use Compose in production. (Except maybe if you know how Compose works already and don't want to spend time reading about the new Swarm commands.)

Docker Swarm不支持 .env 文件类似于Docker-Compose。所以你不能有 IMAGE_VERSION = 1.2.3 在 .env 文件中，然后在 docker-compose中。 yml 文件具有：图片：名称：$ {IMAGE_VERSION} 。参见 https://github.com/moby/moby/issues/29133 -相反，您'需要手动设置环境变量： IMAGE_VERSION = SOMETHING docker stack up ... （这实际上使我坚持使用Docker-Compose。+我没有迅速地通过Swarm找出如何查看容器的日志； Swarm似乎更复杂。）

Docker Swarm doesn't, however, support .env files like Docker-Compose does. So you cannot have e.g. IMAGE_VERSION=1.2.3 in an .env file and then in the docker-compose.yml file have: image: name:${IMAGE_VERSION}. See https://github.com/moby/moby/issues/29133 — instead you'll need to set env vars "manually": IMAGE_VERSION=SOMETHING docker stack up ... (this actually made me stick with Docker-Compose. + that I didn't reasonably quickly find out how to view a container's log, via Swarm; Swarm seemed more complicated.)

这篇关于有什么理由不在单个节点上使用Docker Swarm（而不是Docker-Compose）？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！