@jmmills您不能启动您的容器，例如：“docker-compose scale worker=5”并且该服务将从 5 开始？

aanm 于 2015-07-06

👎16

@aanm是的，但我认为该功能应该被镜像为服务定义中的默认值。也许我有一组最少的工作人员应该始终运行，我希望将其明确声明为默认值。

jmmills 于 2015-07-06

@ @aanm您是否希望docker-compose up应该考虑scale参数？我看到的唯一问题是我们在声明性配置中引入了与底层 Docker/Docker API 概念不兼容但非常特定于 Docker Compose 的参数。

如果我们要继续这样做；我建议如下：

#!yaml worker: build: rqworker $scale: 5 links: - redis command: rqworker -u tcp://redis

其中$<parameter>表示 Docker Compose 特定的东西。

prologic 于 2015-07-07

我们已经反复讨论scale属于 YAML；之前有一个 PR 添加它（#630）。我仍然认为大多数人不应该在他们的配置中加入比例数字，因为它降低了可移植性，但我理解这样做的用例。

现在我们已经有了用extends来扩充 Compose 文件的基本方法（希望很快会有更好的 - #1380、#758），我在https://github.com/docker/compose 中提出的问题

aanand 于 2015-07-07

我想在我的 yml 中为我通常不想启动的测试相关服务设置scale=0 。我只想使用docker-compose run或显式scale显式创建这些服务。

jamshid 于 2015-07-15

👍30

@jamshid我经常想要那个，一个设置环境但默认不运行的定义。我已经被降级为创建一个基本图像（零/无操作比例也有助于），我在其中运行我的单元测试（通过docker run ），然后我的容器组合消耗了基础图像。

像这样的东西对于开发配置似乎非常有用

myproject:
    build: .
    command: nosetests
    scale: 0
    links:
       - redis
redis:
    image: redis
apiserver:
    image: myproject
    command: plackup
    links:
       - redis
workerserver:
    image: myproject
    command: rqworker
    links:
        - redis

jmmills 于 2015-07-19

👍1

@jamshid @jmmills每个服务的 YAML 文件中的enabled参数/键怎么样？这样您就可以禁用/启用服务？

prologic 于 2015-07-20

@prologic当“比例”参数可以解决这两种需求时，为什么要这样做？
如果你想把一个正在运行的进程/容器想象成一个类的实例，你甚至可以将它命名为instances

jmmills 于 2015-07-21

@jmmills我只是想为您的用例找到一个 _solution_ ，它不涉及破坏当前的docker-compose 。我确实倾向于认为scale=0似乎不太合适，我对scale=X是否应该成为 Compose 本身的一部分有两种看法。

prologic 于 2015-07-21

在我看来，规模（或副本数）是服务组成的一部分，因此应该包括在 compose.yml 中。

jmmills 于 2015-07-25

好吧，我认为我们要么有scale=0或disabled密钥。

prologic 于 2015-07-25

:+1: 能够为实例设置默认的scale大小。我同意，一旦有了 scale，就不需要disabled键，因为您只需将 scale 设置为 0。

JeanMertz 于 2015-07-30

+1

Filirom1 于 2015-08-03

另外，另一个用例：如果我想扩展容器的数量但不想将所有服务置于后台，或者必须跳到另一个终端（或进程）并设置我的扩展数字怎么办...
例如：

$ docker-compose up && docker scale thing=4

不起作用，因为 up 不退出。
但是如果我的合成文件设置了我的容器的比例......

$ docker-compose up

成为 DWIM。

jmmills 于 2015-08-04

我不确定我是否真的喜欢这个；突然间up具有两个功能：

调出任何没有scale参数的容器。
调出任何带有scale=0容器。

我们现在真的在滥用“up”命令。 “规模”也有了新的含义，因为它现在做了两件事：

放大/缩小容器
通过` scale=0禁用容器/服务

prologic 于 2015-08-04

为什么会调出带有scale=0容器？
Build 将使用scale=0构建图像，从而促进基本图像需求。

jmmills 于 2015-08-04

我_可能是错的_但阅读你的最后一条评论有点暗示:)

prologic 于 2015-08-04

让我详细说明：

base_thing:
    build: .
    scale: 0

thing:
    image: base_thing
    # scale: 1 implied by default

workers_for_thing:
    image: some_other_image
    scale: 4
    links:
      - thing

test_harness:
    image: base_thing
    command: nosetests --where=my_test_code_dir --all-modules
    scale: 0

现在，预期行为： docker-compose build使用“build”构建任何容器（是否在构建时 compose 拉入外部图像？不记得了）， docker-compose up将运行任何具有正比例的东西（默认为1)，如果需要， docker-compose run test_harness将构建“base_thing”并运行我的一个命令。精明？ :)

编辑： docker-compose up将运行1 "thing" 和4 "workers_for_thing"

jmmills 于 2015-08-04

👍7

好的谢谢; 你的例子更有意义，更清楚scale=0的意图

我认为docker-compose在up / run上“拉”图像。

prologic 于 2015-08-04

我需要创建配方来指示测试、生产、质量保证等的实例（规模）数量。

Miuler 于 2015-08-08

+1 为scale=X 。这将非常有帮助。
并为@jmmills评论+1，

mclate 于 2015-08-11

好极了！对于scale=x 。初始化一组容器肯定有助于在设置集群配置时识别潜在的竞争条件。

verges-io 于 2015-08-12

+1 为scale=x （包括scale=0以禁用初始docker-compose up ）

michaelcontento 于 2015-08-24

+1 为scale=x 。

gnoymmij 于 2015-09-08

x是 NaN，我建议改为-1 。

aanm 于 2015-09-08

😄1

+1 表示比例=x。

samuelololol 于 2015-09-17

+1

sutyrin 于 2015-10-04

+1

PaulPetring 于 2015-10-05

我们停止 +1 怎么样，好吗？

petarmaric 于 2015-10-05

👍7

+1'ing 可用于查看对某项功能的兴趣程度。

shofetim 于 2015-10-05

@shofetim我知道一个更好的方法来做到这一点：实现有问题的功能并发出拉取请求......

petarmaric 于 2015-10-05

+1ing 也是让人们就提议的解决方案达成一致的好方法。它在 github 上的行为非常普遍。如果出现问题，单击通知中的取消订阅按钮将关闭这些通知。

coconitro 于 2015-10-05

👍1

嗯，看起来像这样的人。撰写待办事项中有一个类似的项目（从图中遗留下来），我很确定我在某个时候对它发表了评论。我会在今晚晚些时候尝试跟进。
本周大部分时间我都在 PuppetCon，所以希望这能给我一些黑客时间 - 我会看看我是否可以写这个。

jmmills 于 2015-10-06

这是“scale = 0”用例的解决方法：

app:
  build: .
  environment:
    - DATABASE_URL=postgres://user:password<strong i="6">@host</strong>:5432/dbname
  command: sleep 999999999999

app_web:
  extends:
    service: app
  ports:
    - "3000:3000"
  command:
    # intentionally blank to use Dockerfile's default RUN command

app_worker:
  extends:
    service: app
  command:
    rake jobs:work

wkonkel 于 2015-10-08

@wkonkel是的，我过去做过类似的事情。

jmmills 于 2015-10-09

我目前正在努力让自己熟悉 compose 代码库，一旦我知道 compose 的所有东西在哪里，我就会为 scale 配置参数编写一个 PR。
看起来它不会太难，项目有一个scale方法，它是 cli 界面的后端，所以我真正需要做的就是在字段架构，请确保如果在容器创建后调用它...然后确保它不运行容器，如果它设置为零。

jmmills 于 2015-10-09

实际上有一个非常古老的公关公开：#630。

问题是规模是一个操作问题，它不是应用程序定义的一部分，所以它并不真正适合撰写文件。

支持默认比例级别的配置会很好，但我认为撰写文件不适合它。

#1754 应该已经解决了scale: 0情况。 “无操作”容器只能有一个立即退出的命令（echo、true 等）。需要scale: 0情况通常是以下两种情况之一：数据量容器或“临时/管理任务”。

很快我们就不需要数据卷容器了，因为卷正在获得新的 API 端点，而且我们将能够在不需要容器的情况下定义卷。

#2051 可以更好地处理管理任务。您可以定义admin.yml来扩展核心docker-compose.yml并允许您将管理任务链接到“核心组合”，而不会混淆每个的定义。

这两个更改现在都在 master 中，并将在 1.5.0 版本中可用（即将发布）。

所以这只会留下默认情况下希望将服务扩展到 > 1 的情况。编写这样的脚本已经很容易了，但是能够将它放在配置文件中仍然很好。我想我们将在 #745 中探索单独配置的想法。我认为这个新配置对于不属于应用程序定义的内容（项目名称、默认网络名称、默认比例等）来说是一个好地方。

dnephin 于 2015-10-09

恕我直言，我不同意规模只是一个运营问题。应用程序可以关心正在运行的服务的最小数量。
就无操作容器而言，当该容器的目的是触发要在其中构建其他容器用于其image字段的基本映像时，实际运行容器感觉很笨拙。

jmmills 于 2015-10-09

应用程序可以关心正在运行的服务的最小数量。

你能举个例子吗？

就无操作容器而言，当该容器的目的是触发要在其中构建其他容器用于其图像字段的基本图像时，实际运行容器感觉很笨拙

是否有理由将基本映像作为同一构建的一部分？正如我在 #1455 中所说的，compose 主要不是“docker build”工具。它的目标是在运行时提供容器的组合。尝试支持所有可能的构建场景极大地增加了组合的范围，并将焦点从容器组合上移开。即使是围绕构建图像而设计的工具也很难支持这些请求中的每一个。我认为更好的方向是尽可能多地避免构建复杂性，并让用户用适当的构建工具代替docker-compose build 。

dnephin 于 2015-10-09

我关心的用例是 scale=0 （也许 abstract=true 会是一个更好的描述符）。我想在不同的命令之间共享图像和环境变量。具体来说，我希望一台 Web 服务器运行，一台后台作业服务器运行，两者都具有相同的代码和相同的环境变量。

wkonkel 于 2015-10-09

@wkonkel使用您的示例，我想这也行吗？

app_web:
  build: .
  ports:
    - "3000:3000"
  environment:
    - DATABASE_URL=postgres://user:password<strong i="7">@host</strong>:5432/dbname

app_worker:
  extends:
    service: app_web
  command: rake jobs:work
  ports: []

您将拥有无操作覆盖的抽象服务command换成无操作覆盖的无抽象服务ports 。听起来对吗？

1988 与抽象服务有关。

dnephin 于 2015-10-09

@dnephin是的，这对我来说确实有效。

wkonkel 于 2015-10-09

实际上，我收回了它......我只是用 docker-compose-1.4.2 尝试过它，似乎“ports: []”没有覆盖父级，所以 app_worker 无法以“端口已经分配”开头”。

wkonkel 于 2015-10-09

@dnephin该线程可能有更好的解释，但我会尝试在此处阐明它。

首先想到的是作业系统，其中运行相同代码的单独容器可以建模为 parent->fork()->child pool 类型的服务，其中默认应用程序配置需要最少数量的 worker 来实现并发。

我对此的灵感来自一个应用程序，该应用程序使用附加到不同队列的 RQ 工作线程，这些队列共享包含我的 Python 包（工作线程代码）的基本映像，但每个队列都有多个实例运行。由于长时间运行的作业，并发的最低可用性是应用程序的要求。

我只是认为拥有 no-op 命令似乎是一种资源浪费，只是为了以与其他应用程序堆栈相同的方式构建共享基础映像。您最终会得到一个仅用于基本图像的 while/sleep 循环，这是一个很酷的解决方法，但似乎不是实现此目的的直观方法。更不用说在我们的流程树中留下一个没有运行时功能的项目。

如果 docker-compose 真的不交叉到编码图像构建关系的领域，那么构建选项可能应该消失，并且应该创建一些其他构建定义系统，以便我可以定义构建目标来构建基本图像，然后是使用一些修改过的工件/配置并以正确顺序消耗该基础的其他图像？

或者，我只是太固执己见，应该将我的 docker compose 命令包装在 shell 脚本中，以按比例启动我的服务，并将我的所有图像构建定义为具有依赖项的 make 目标。

jmmills 于 2015-10-09

我只是认为拥有 no-op 命令似乎是一种资源浪费，只是为了以与其他应用程序堆栈相同的方式构建共享基础映像。

#1754（在下一个版本中）不再需要了。一个服务可以退出并且不会停止其余的服务。所以你可以让基地退出而不必担心。

dnephin 于 2015-10-09

@dnephin Cool，那么您是否会向该基础/中间容器提供link以确保它首先被构建？

jmmills 于 2015-10-09

@dnephin ：我有一个 CI runner，它相当于docker compose up 。我希望我的测试环境运行多个版本的服务（即规模）。我可以复制整个配置块，但这需要重复我自己。在这种情况下，它不仅仅是“操作问题”，它是我在开发集群应用程序时在我的开发环境中需要的东西，目前完全描述为一个撰写文件。目前，我将不得不进行一些带外规模配置，然后以某种方式调用docker-compose scale ，我想，但这似乎并不理想，并且会引入更多失败和竞争的机会。

pwaller 于 2015-10-31

在生产情况下，您可能希望以最小规模为您的服务加星。例如，假设您正在从一个集群迁移到另一个集群，为了示例的简单性，让我们保留迁移的一些困难部分作为复制数据；并且您确实需要从一开始就开始处理一些流量，因此您需要使用 docker-compose 部署至少 (n) 个某些服务的实例，比如 web。

在配置文件上的服务下进行扩展将真正解决这个问题。这也是一个可用性用例，因为如果用例实际上公开了至少 (n) 个运行的服务实例的要求，而不仅仅是一个在开始点。

在我看来，比例实际上是拓扑和组合的定义参数。

bitgandtter 于 2015-11-20

@dnephin

你能举个例子吗？

Consul、MariaDB Master-Master 或 Swarm 上的任何其他分布式应用程序确实需要集群中至少有 3 个节点才能可靠。配置文件中肯定有可用服务数量的用例，我不明白您为什么如此反对它。大：+1：从我这里。

nazar-pc 于 2015-12-01

我不反对配置比例的方法，我只是认为它不属于撰写文件，因为它是独立于撰写文件而更改的状态。

以这个例子为例，它假设我们向撰写文件添加了一些比例配置：

我将服务的初始比例设置为 3
我运行docker-compose up -d ，我的服务扩展到 3
我跑docker-compose scale service=4
我做了一些更改并重新部署docker-compose up -d .. 会发生什么？它会再次缩小到 3 吗？它现在完全忽略了规模吗？

这些场景听起来都不是很好或合适，这只是一个忽略实例故障的简单示例（这使得它变得更加复杂）。

如果要将其添加到撰写文件中，我想我们希望删除scale命令，这样它们就不会发生冲突。

您提供的示例是操作要求的示例。您不需要多个 master 来运行应用程序，您需要它来保证服务的可靠性（操作）。你仍然可以用scale db=x 。

dnephin 于 2015-12-01

使用@dnephin上面给出的示例：

首先，我认为 scale 命令也是一个幼稚的命令，因为您无法判断是否要扩大或缩小服务，有两个 diff 命令仅通过告诉有多少服务来解释扩大或缩小的意图你想分别创建或删除，会好很多。

@dnephin提出的问题的答案是，我希望运行的服务/容器与修改前一样多。

Compose 是一个无状态工具，它不知道或监视它使用 docker api 来帮助 Ops 编排我认为问题所在的服务/容器，compose 旨在成为一个帮助工具，而不是一个完整的编排服务，现在我们需要那个，我们有一个运行良好的引擎，我们有机器可以提供，我们有 swarm 将所有这些加入一个集群，但我们泄漏了一个真正的编排服务/工具，它使我们能够灵活地配置并像 k8s 一样管理部署的服务/容器。现在 compose 与它非常相似，但如果这个项目的未来没有发展成更大的东西，最好的想法是由官方开发人员和维护人员告诉它，这样我们就可以找到另一个可以做到的工具。

就我个人而言，我认为发展 compose 会更好，因为它是一个很棒的工具，并且为我们所有人所熟知。

bitgandtter 于 2015-12-01

我会很高兴看到这个： docker-compose > docker compose 。
不确定其他工具，但为此，与引擎进行有状态的集成会非常好。抱歉有点跑题了。

nazar-pc 于 2015-12-01

我已经创建了 #2496 用于删除 scale 命令并将其替换为 scale 选项的建议（来自上面的帖子）。对这个提议的反馈会很好。

dnephin 于 2015-12-04

@dnephin使用 #2496 compose 失去了轻松放大或缩小的能力，我们需要重新配置 compose 文件，然后在我们只需要缩小或放大一个实例时再次运行 compose up，我认为这很漂亮复杂的。

我们再次失去了这一点，即所有这些场景都来自于 compose 是一个无状态工具，因此它无法控制服务的状态以及在某个时刻有多少服务。

您在新提案中提到的场景将通过全状态服务/工具 new-compose 轻松解决。

bitgandtter 于 2015-12-04

+1

npetzall 于 2015-12-18

+1

AdamAJeng 于 2015-12-18

+1

kubaracek 于 2016-01-13

@dnephin如果你这样做，行为会不会一样：

$ docker-compose up -d && docker-compose scale node=4 && docker-compose up -d

这不是撰写如何在内部保持规模的更多问题。

jmmills 于 2016-01-14

就是这样，“编写应用程序”是无状态的。唯一的状态是 1) 撰写文件，以及 2) 由引擎管理的 docker 容器标签。

撰写文件只能由人工编辑，而不是由撰写。尝试用相同的注释、顺序和结构写出 yaml 将是一团糟。 pyyaml 不支持它，无论如何这不是我们真正想做的事情。

docker 引擎不知道规模，因此它无法存储该状态。有可能进行更大的架构更改，但这有点超出了本问题的范围。

现在我们的选择基本上是将比例作为命令行选项保留，或者将其移动到撰写文件中，但正如我在 #2496 中所描述的，我认为同时拥有两者会令人困惑并导致不正确的行为。

up && scale && up现在实际上做正确的事。 up将重新创建所有容器，并且由于配置中没有比例值，因此不会混淆所需的比例应该是多少。它已经由 scale 命令设置，并由容器标签跟踪。

dnephin 于 2016-01-14

@dnephin我想我同意你所说的，[我在这个假设中可能是错的] 你真正质疑的是 _if_ 组件实例的数量实际上是服务组合（一组容器运行不同的组件容器）。我会说它目前正在解决这个问题，只是需要注意 cli 和组合定义 (yaml) 之间缺乏奇偶校验。

如果责任范围确定规模不是组合的关注点，那么规模应该作为 cli 选项删除（可能激怒很多用户），或者如果确定规模是服务组合的关注点cli 和 yaml 之间应该存在奇偶校验，并额外支持最少实例，以解决需要 N+1 的集群实例。

jmmills 于 2016-01-14

同意@jmmills尤其是在运行数据容器集群时，当可用性和复制齐头并进时，至少scale是应用程序的一部分：如果没有适当的规模，它甚至可能无法工作

ffissore 于 2016-01-28

👍3

+1

Jasperswaagman 于 2016-02-05

+1

lutskanu 于 2016-02-06

+1

bugcy013 于 2016-02-07

目前我需要声明这样的事情：

硒铬1：
...
硒铬2：
...

会很好：
硒铬：
规模：2

+1

caioquirino 于 2016-02-10

👍3

正是@caioquirino所说的。 +1

docker-compose up应该会带来一个不需要其他工作的工作环境。启动需要多个节点的服务的唯一方法是使用@caioquirino提到的模式。忽略此处的 DRY 违规，当您尝试使用 scale 命令添加另一个节点时，该模式会出现错误，因为不清楚应该扩展哪个“服务”。

yml 文件中的缩放修复了这个问题。

BrianAdams 于 2016-02-11

Big +1，我还想用它来定义最初将 scale 设置为 0 的服务。

沿着...

consul_bootstrap:
  build: ./consul
consul_master:
  build: ./consul_master
  scale: 0

这个想法是您可以使用相同的 docker-compose.yml 并从开发环境无缝过渡到生产环境。 consul_master 实例将通过执行docker-compose scale consul_master=3自动加入 raft 并建立法定人数。这会很酷。

affixalex 于 2016-02-11

👍1

回复@dnephin...

以这个例子为例，它假设我们向撰写文件添加了一些比例配置：
我将服务的初始比例设置为 3
我运行 docker-compose up -d，我的服务扩展到 3
我运行 docker-compose scale service=4
我做了一些更改并使用 docker-compose up -d 重新部署.. 会发生什么？它会再次缩小到 3 吗？它现在完全忽略了规模吗？
爱它
好吧
我还在你身边
我认为现有部署和新部署之间应该有一些区别，以便可以为正在接收持续更新的现有部署保持规模的连续性。单个部署将包括 DOCKER_HOST env 等，以及每个组件的规模、映像 ID 和重新部署的历史记录。这可能是连接上层机制（如持续部署或蓝绿部署）的好地方？我正在设想一个稍微更适合生产的工作流程，因此您可以简单地连接到不同的 DOCKER_HOST 并执行docker-compose up -d ，然后提供挂钩，以便 upstack 工具可以管理诸如 CI 和蓝/绿推出之类的事情。也许添加类似 DOCKER_COMPOSE_ENV={"testing" || “生产” || “开发”}？

affixalex 于 2016-02-11

恕我直言，“硬编码” scale ，对 3 说，它应该从 3 个容器开始

ffissore 于 2016-02-11

我认为通过将 YAML 参数命名为“initial_scale”或“default_scale”可以缓解关于“scale”参数与“scale”命令的很多混淆。这很清楚，如果没有某种覆盖，它只是一个将被使用的值。同样（至少恕我直言）这个“initial_scale”参数只会在 docker-compose 第一次启动服务时被引用，而不是在服务的某些实例已经运行的情况下再次运行 docker-compose up 时引用。

ceejatec 于 2016-02-19

👍11

+1 表示“initial_scale”，它也会明确地将此参数描述为特定于 compose 的，因为 docker 本身没有这样的参数。

honsiorovskyi 于 2016-02-26

发生了一件有趣的事情，在博客文章https://blog.docker.com/2016/02/video-containers-as-a-service-caas/中的视频“48.56 显示，在新发布的 docker 数据中心上，您可以在堆栈创建点实际设置要运行多少个容器实例。所以这个想法对 docker 团队来说并不新鲜，希望它被包含在下一个 compose 版本中

bitgandtter 于 2016-02-26

+1

migueleliasweb 于 2016-02-26

👎3 👍3

+1

jeffersonsouza 于 2016-03-09

👎3 👍3

数以百万计的问题和请求 scale/initial_count 等等......但仍未计划。

看到其他好的项目很难过，但人们只会找借口，创造新的和重复的问题，解决问题和“做”工作。

gochev 于 2016-03-12

+1

melya 于 2016-03-17

👎3

+1

EricMeallier 于 2016-03-21

👎3

+1

AndreyUtka 于 2016-03-21

👎3

+1

AndrianBdn 于 2016-03-21

👎4

请停下！
不要加+1！
只需订阅这个问题！

pierrre 于 2016-03-21

+1（ @pierrre抱歉）

draev 于 2016-03-21

👎8

+1 它非常重要（ @pierrre ，抱歉）

aka-toxa 于 2016-03-21

👎7

我同意，但我不想收到 100000 条关于您的“+1”的通知！

pierrre 于 2016-03-21

👍13 😄4 ❤1

/me fork docker compose 并开始学习代码库。

jmmills 于 2016-03-24

selection_126

sergeyklay 于 2016-03-24

😄5 👎1

上面的许多有效点，看起来在配置文件中有一个default/inital scale参数+ scale cli 命令将解决这两个问题。要添加支持初始规模选项的用例，请考虑集群服务，其中仲裁由 X 个节点组成，否则不应运行（例如不少于 3 个）。 docker-compose是拥有一个完整包含的此类系统的描述符。

aperepel 于 2016-03-29

我的用例是：

我使用一些常用设置扩展了一项服务，以减少重复。但是，创建了基本服务（在未明确指定服务名称的情况下运行时），然后我手动将其关闭。我希望基础服务的初始规模为 0。

jasonf20 于 2016-03-29

我普遍同意。虽然在我看来，这个问题和链接/相关问题归结为一个稍微不同的问题： up和scale最终希望成为相同的命令。

他们有时已经：

docker-compose up service
docker-compose scale service=1 。

并且，如果scale暴露了up所做的所有 cli 选项（例如--force-recreate ），或者如果up知道计数，那么它们基本上会。

如果，正如这个问题所提议的，“初始比例”指令被添加到docker-compose.yml ，那么up将不得不学习计数。在这一点上， up不应该只支持计数语法docker-compose up service=10 （它可以覆盖 yaml 中定义的任何比例）？

“初始比例”和“比例”之间存在区别，这可能是不同命令的域。但是因为up是幂等的并且被设计为重复运行而不必改变状态，所以我认为这种区别并不严格。我认为我们应该考虑让up蚕食scale 。

mattgiles 于 2016-04-03

👍1

@mattgiles我同意，这就是我要使用 #2496 的地方，但是我没想到service=count可以添加到up 。我认为这可能会处理这种情况。我看到的唯一问题是目前up web表示仅启动 Web 服务及其依赖项。试图做up web=3将不得不继续意味着同样的事情。这意味着没有办法up一切并立即覆盖比例计数，但这可能没问题。

我会在#2496更新提案

dnephin 于 2016-04-04

@dnephin我错过了最近的提议。惊人的！

FWIW，我认为这是完全直观的docker-compose up web=3带来了三个集装箱的“网络”服务，以及任何依赖关系......在YAML定义的比率（每有点像scale指令）。这样，撰写文件将继续管理，除非被命令行覆盖。

up后续调用可以继续，就像他们现在所做的那样，不理会现有的容器。只有当当前规模小于 yaml 中定义的规模时，它才会更改计数以符合被禁止的规模。没有定义的等级将继续暗示等级为 1。

如果计数高于 yaml 中定义的值，诸如--force-recreate也应该单独保留计数，但仍然重新创建所有容器以符合其他属性。

对我来说，通过调用诸如docker-compose up web=2类的东西来杀死容器也很有意义，就像目前使用scale一样。

mattgiles 于 2016-04-05

👍8

+1

OferE 于 2016-06-20

+1（只是为了惹恼@pierrre ；））

foxx 于 2016-06-24

😄2 👎1

+1

artemkaint 于 2016-07-11

+1 表示比例=x。

ramsrib 于 2016-07-20

与此相关，我很想用一种方式来描述单身人士。 scale=1

bfosberry 于 2016-07-23

👍2

使用缩放选项在此处取得任何成功

lavvy 于 2016-08-09

+1

astewart-twist 于 2016-08-10

我还没有从上游看到任何关于这个的新东西，我个人没有机会看看我是否可以为它编写补丁。

谢谢，
杰森米尔斯

由手机发出。

在2016年8月8日，5:19 PM，lavvy [email protected]写道：
使用缩放选项在此处取得任何成功
—
你收到这个是因为你被提到了。
直接回复此邮件，在 GitHub 上查看，或将线程静音。

jmmills 于 2016-08-10

+1

drew-r 于 2016-08-16

+1

pablolibo 于 2016-08-22

+1

alirezaDavid 于 2016-08-24

+1

cgarciae 于 2016-08-31

+1（再次惹恼@pierrre ）

foxx 于 2016-09-05

+1

darkdefender27 于 2016-09-11

我想重述这个案子

比例=0
用于测试、调试。探测等服务，您通常不想启动，但您想要定义 - 因为它们通常在文件中的其他服务的上下文中使用。

规模=1
因为我想要其中只有一个 - _ever_。在 MariaDB 集群中，在某些情况下，我可能只想要单个节点配置特定的存储引擎（例如 Spider、ColumnStore 等）。

比例=n
因为有时我知道我需要运行“n”个服务，例如，在 MariaDB 集群中，我将始终拥有一个主节点（及其配置）和两个辅助节点（具有不同的主节点配置）。

alvinr 于 2016-09-14

👍3

对我来说很有意义@alvinr。默认值应该是 1。

boyvinall 于 2016-09-14

免责声明：我不是 Marathon 或 Mesosphere 的代表

这是一个相当简单的功能请求的另一个例子，该请求已被 docker 支持团队放弃/推迟了一年多。 https://github.com/docker/docker/pull/12749是另一个例子。 Kubernetes 和 Marathon 有这些选项已经有一段时间了（“instances”：marathon.json 文件中的 3），甚至实现了自动缩放。是 docker 支持小组的不情愿让我远离 docker data center & swarm 有一段时间了。

westlakem 于 2016-09-14

👍7

Kontena 也将其作为instances: 3 (https://www.kontena.io/docs/references/kontena-yml)

matti 于 2016-09-15

我们可以执行此操作的另一种方法是在撰写文件版本 2 上添加scale部分。

它不会与服务中使用的 docker-only 选项混合。

一个例子是：

version: "2"

services:
  worker:
    image: something
    command: work

scale:
  worker: 2

hugochinchilla 于 2016-09-26

👍7

这具有指定scale: 0可能会用一颗石头杀死两只鸟，另一个是https://github.com/docker/compose/issues/1896

drew-r 于 2016-09-26

👍5

这似乎是没有道理的。

我想用 3 或 4 个 nodejs 实例部署 nginx+nodejs+mongodb。每次我启动应用程序。

如果您有一个命令行选项可以做到这一点，为什么不在 yml 文件中呢？

docker-compose up scale nodejs=4

会做。

mschwartz 于 2016-10-17

👍5

这很简单。他们想走“别人建造，我们
将尝试支持它”。除了基础 docker，他们还没有创建
任何事物。 Compose 是他们消费的不同产品，现在他们拥有
不知道如何支持/扩展它，这就是为什么像 marathon 和
kubernetes 比 swarm 更受欢迎。

2016 年 10 月 16 日晚上 9:36，“Michael Schwartz”通知@github.com
写道：

这似乎是没有道理的。
我想用 3 或 4 个 nodejs 实例部署 nginx+nodejs+mongodb。每一个
我启动应用程序的时间。
如果您有一个命令行选项可以做到这一点，为什么不在 yml 文件中呢？
docker-compose up scale nodejs=4
会做。
—
您收到此消息是因为您发表了评论。
直接回复本邮件，在GitHub上查看
https://github.com/docker/compose/issues/1661#issuecomment -254093296，
或静音线程
https://github.com/notifications/unsubscribe-auth/AES98nZt1uIejnIU9iajVt54QbzdlVK1ks5q0tETgaJpZM4FS8ZQ
.

westlakem 于 2016-10-17

👍1

老实说，我有点惊讶这有_任何_的阻力，因为它似乎很明显......

jeremysmitherman 于 2016-10-20

👍5

@westlakem让我们希望 MacOS 的 Docker 不会遭受同样的命运，希望 Unikernel 的人坚持下去。

foxx 于 2016-10-21

一口气提出一个功能大小的完整堆栈会很好。在我们当前的用例中，服务堆栈需要“workers=16”才能正常工作。

这太可怕了：

docker-compose up -d
docker-compose scale workers=16
docker-compose down
docker-compose up --abort-on-container-exit

显然可以用以下内容替换：

docker-compose up --abort-on-container-exit --scale workers=16

编辑：我看到“Rancher”具有类似 docker-compose 的语法并支持初始缩放参数： https :

hholst80 于 2016-10-28

👍1

一种解决方法是使用 YAML 锚点和合并功能，并在 docker-compose 文件中复制服务。

services:
  toscale: &my_service
     ... # all paramteres
  # second instance
  toscale2: 
     << : *my_service
     ports:
       - 81:80 # override port if needed

等等 ...

maxigit 于 2016-11-15

👍1

这将非常有用！

hugodes 于 2016-11-27

👍2

这太奇怪了，这不存在......

我可能最终不得不创建重复的服务，因为我太懒了。

aphillipo 于 2017-01-06

这已经在作曲家文件 v3 https://github.com/aanand/compose-file/blob/master/schema/data/config_schema_v3.0.json上的工作，它将在 docker-compose v1 上得到支持。 10.0-rc1

bitgandtter 于 2017-01-06

👍2

他们的“服务”产品内置了参数。很遗憾，作为一个
此问题的订阅者开发团队中没有人告诉我们
它出现在服务产品中，有人必须阅读 RC 说明
1.10 的任何见解。码头代表在哪里？

2017 年 1 月 6 日星期五上午 6:30，Yasmany Cubela Medina <
[email protected]> 写道：

这已经在作曲家文件 v3 https://github.com/aanand/
compose-file/blob/master/schema/data/config_schema_v3.0.json 这将是
并且它已经在 docker-compose v1.10.0-rc1 上得到支持
—
你收到这个是因为你被提到了。
直接回复本邮件，在GitHub上查看
https://github.com/docker/compose/issues/1661#issuecomment-270886347 ，
或静音线程
https://github.com/notifications/unsubscribe-auth/AES98nOAW-h0BVaR8D9uQfLpMCQRfdyfks5rPiXEgaJpZM4FS8ZQ
.

westlakem 于 2017-01-06

😕1

+1

charneykaye 于 2017-01-16

+1

mantisbayne 于 2017-01-23

你好，我有一个相关的问题。
我一直想知道docker-compose up能记住我设置的比例。

例如，我运行docker-compose scale nodejs_web=4然后docker-compose down ，
然后我再次启动docker-compose up ，它将启动 4 个 nodejs_web。

我想知道scale命令在哪里保存数字 4？

docker-compose.yml 可以是：

version: '2'
services:
  nodejs_web:
    image: node
    command: node

jjqq2013 于 2017-01-25

👍2

我支持#2496 上的@dnephin提案
请给我们这个基本功能。

alwaysastudent 于 2017-03-20

👍1

新版 Docker 中的服务确实提供了“副本”功能。

在星期一，2017年3月20日，在下午3:28，alwaysastudent [email protected]
写道：

我支持@dnephin https://github.com/dnephin关于 #2496 的提议
https://github.com/docker/compose/issues/2496
请给我们这个基本功能。
—
你收到这个是因为你被提到了。
直接回复本邮件，在GitHub上查看
https://github.com/docker/compose/issues/1661#issuecomment-287870998 ，
或静音线程
https://github.com/notifications/unsubscribe-auth/AES98uWGEnbyCFyxNSSlv7QkXy5oBek1ks5rntNBgaJpZM4FS8ZQ
.

westlakem 于 2017-03-21

@westlakem - 该功能适用于 swarm。它不适用于常规服务扩展。

alwaysastudent 于 2017-03-21

👍1

这么多优点，几个缺点。这个问题是怎么回事？

cgarciae 于 2017-04-07

在https://github.com/docker/compose/issues/2496 中有一个关于完全删除 scale 命令的最新提议

我真的不明白为什么或为什么在撰写文件中没有initial_scale: 3选项（我明白为什么它不能只是scale: 3 ）

matti 于 2017-04-08

在 1.13.0 中实现。感谢大家的反馈和耐心。

shin- 于 2017-07-18

🎉5

@shin- 为什么这被认为是关闭的？在管理一切都是自动化和版本控制的大型应用程序时，我现在必须修改我的 Ansible，它执行 Docker 以定义将运行多少个服务实例。

Ansible 应该设置一切以便 Docker 可以运行。 Docker 应该定义应用程序需要多少个服务实例。现在知道服务清单是 Docker 的责任，但是 Ansible 有责任调用 Docker 以便它知道要启动多少个容器？

greenscar 于 2017-07-24

@greenscar抱歉，我不太确定问题是什么 - 您是否对该功能的实现方式不满意？如果是这样，我们可以通过什么方式使它变得更好？

shin- 于 2017-07-24

为什么这在第 3 版中不存在？由于“deploy.replicas”和“up”不是等价的，因此非常令人困惑，您可以说 v3 中缺少此功能。

cgarciae 于 2017-08-03

@cgarciae deploy.replicas与scale用途相同。为什么在您看来它们不相等？

shin- 于 2017-08-03

@shin-如果我不想创建一个群而只使用docker-compose up -d ，docker compose 会告诉我它将忽略“部署”设置。

cgarciae 于 2017-08-03

👍1

@cgarciae如果您不想创建 Swarm，为什么要使用 v3 文件？

shin- 于 2017-08-03

😕1

我认为使用 docker 的每个人都希望 scale 参数适用于 docker 2 或 3 文件。没有理由不这样做，它甚至可以为 deploy.replicas 设置默认值。如果设置了 deploy.replicas，则它会覆盖 swarm 中的规模。除了每个人都希望发生的事情之外，这张图片有什么问题（当然，如果您不喜欢它，则无需在您的 docker-compose.yml 中使用它）？

aphillipo 于 2017-08-03

缺少的 scale 参数导致 servie 失败，因为我忘记像上次重新部署后那样扩展它 -.- 为什么这不是一个可以节省服务甚至生命的东西，这取决于它的运行

boscowitch 于 2017-09-20

👍2

也刚碰到这个问题。似乎没有办法指定从 docker compose 配置中启动多少服务？更令人困惑的是，docker compose 文档中有很多文档是针对与 docker-compose 不兼容的东西...

tsloughter 于 2017-10-03

哦等等，所以如果我将我的 docker compose 配置更改为version: "2.2"那么我可以使用scale: 2但是如果有人想要使用更高版本，则不再有这样做的选项？

tsloughter 于 2017-10-03

👍2

好的，我看到这个“版本”问题并不是真的意味着版本已经被提出， https://github.com/docker/compose/issues/4693

tsloughter 于 2017-10-03

我使用 v3.6，因为我需要一些 2.2 中不存在的配置。对于本地开发，我不使用 swarm，但我想将 scale=0 设置为我的 docker-compose.overrides.yml 中的某些容器。因为其中一些仅用于前端构建容器之类的构建过程。此容器与其他正在运行的容器共享一些卷，但不应与 docker-compose up 上的这些其他容器一起启动。所以 buildcontainer 只用 run 命令运行。是的，我可以在调用 docker-compose up 时设置 --scale 参数，但我认为最好将它直接写入配置。 :)

freesh 于 2018-07-01

感谢您提供比例参数。我能够在非生产docker-compose.yml使用它，以便任何人都可以使用 Consul 和 Vault 的 HA 配置。 scale 参数使配置本地 HA 配置变得容易。 https://github.com/samrocketman/docker-compose-ha-consul-vault-ui

在这种情况下，仅适用于在 HA 配置中尝试 Consul 和 Vault 并使用 Consul DNS 的人。

samrocketman 于 2018-09-12

您正在运行哪个版本的 docker compose？自 v3 以来，此功能已被删除（删除，我的意思是从未实现过），因此它被忽略了。见https://docs.docker.com/compose/reference/scale/

jjsaunier 于 2018-09-12

由于缺少功能，我从不使用 v3 格式。我倾向于使用最低的 2.1 或 2.2 格式，具体取决于我使用的功能。

编辑：并不是说我避免使用 v3 格式。只是当我去编写一个撰写文件时，它通常会缺少我想要使用的内容。

samrocketman 于 2018-09-12

好吧，我猜你说的是 docker compose with swarm stack，这就是原因。我从来没有尝试过，但是在没有 Orchestrator 和 mutli 节点的情况下用 docker compose 谈论 HA 很奇怪。是为了“poc”还是测试目的？无论如何，我从未在这种情况下尝试过

jjsaunier 于 2018-09-12

在这种情况下，HA 只是指 consul 集群和 vault 集群。它旨在作为可用于实验和易于引导的概念证明。 HA 并不是指 docker HA 甚至多机 HA。这只是 HA，因为进行实验的人可以杀死集群容器之一，并看到 consul 和/或保险库服务不受影响。

samrocketman 于 2018-09-13

Compose: 功能请求：在yml中添加比例参数

最有用的评论

所有146条评论

1988 与抽象服务有关。

相关问题