Compose: 定义默认情况下未启动的服务

为选项1 +1

我认为添加实际上不是组合的一部分但恰好需要链接/附加的服务是一个糟糕的设计选择。 还有一些其他用例可以通过允许某种形式的包含语法来解决。 使用一个功能解决多个问题总是很不错的。

其中一些问题（处理仅数据容器的问题，＃942，@ cpuguy83的最后评论）实际上已由＃1754解决，我认为我们不再需要考虑它们了（在1.5之后）。

我们开发Magento扩展。 为此，我们需要一种简单的方法来在LAMP堆栈上运行网络商店。 撰写变得容易。 但是我们也想运行phpunit，各种静态分析工具，文档构建器等。实际上，我们的绝大多数“服务”只是命令，如docker-compose run --rm phplint 。 理想情况下，使用不合格的命令

docker-compose up -d

只会启动长期运行的服务（实际上是_services_），并且不会不必要地触发其他效果，例如phpunit。 （同样重要的是，不要触发混乱的事情，例如在Web服务启动之前运行Selenium测试。）

我们真正想做的就是将环境管理的痛苦从开发人员身上转移开，而不是运行生产服务。 我不知道@dnephin的评论是否可以代表Compose前进的方向，但对我而言，Compose是否仍计划服务于开始发展的利基市场似乎并不明确。（因为，很明显，我认为选项1不支持开发人员需要使用的易用性，如图所示。）我完全理解Compose是否不想承担多重责任，但我希望有人可以让我们清楚地知道，如果将我们的产品用于快速，隔离的开发环境的人应该朝另一个方向发展。

@kojiromike ，关于（1）不适合您的用例的是什么？ 它只是关于命令语义（ docker-compose run --rm phplint vs. docker-compose --file phplint.yml up ）吗？

docker-compose up -d尝试“启动” phplint，而docker-compose ps报告phplint“服务”已关闭。 实际上，它不是服务容器，而是工具容器，不应包含上/下概念。 据我了解，码头工人已经拥抱了工具容器（它如何运行redis-cli之类的东西，显然不是“服务”），尽管我在开发中更多地使用它们，但我认为它们也有生产场所。 例如为什么要说awk安装在生产机器或容器中，为什么不通过链接运行容器来获得可预测的行为呢？

：+1：我通常发现自己想与其他服务一起创建tests容器来封装正在运行的单元测试。 我的“解决方法”是将命令设置为“ / bin / true”，并使用CLI上指定的unit test命令运行容器。 能够指定哪个容器应该以up时间开始会很棒！

（顺便说一句，周围的人都很好，伙计们）

cc @jameydeorio

@ryneeverett语义是其中一部分。 这是一个自我证明和可发现性的问题。 目前，我们告诉开发人员docker-compose run --rm foo bar 。 我们邀请他们创建一个shell函数或别名，但是我们不为项目维护标准的别名/ rcfile。 （我们不想将容器外部的东西标准化；我们想使用Docker _to_ standardize。）为某些命令添加新文件会创建重要性层次结构：docker-compose.yml文件成为重要的“默认”文件事情，“其他”文件变得不那么重要。

另一件事就是维护服务之间的关系变得更加繁重。 仅仅因为我们希望某些东西默认不运行并不意味着它不使用长期运行的服务中的link或volume 。 extends实际上并没有提供将服务链接到“命令”（单次运行服务）所需的所有功能。 即使这样做，如果我们必须使用多个yaml文件，我们也将不得不使用extends ，否则我们将不需要。

扩展实际上并没有提供将服务链接到“命令”（一次性运行服务）所需的所有功能。 即使这样做，即使我们必须使用多个yaml文件，我们也将不得不在其他情况下不需要的地方使用扩展。

@kojiromike这就是我所怀疑的。 我想知道您是否会对改进的extends支持+在单个docker-compose.yml执行子命令（功能上与extends相同）感到满意。 但也许后者与（4）相同。

2）为服务添加一个选项，以使其默认情况下不启动

我投票给选项2。例如，类似start: false指令的东西。 优点是我们避免了使用多个compose.yml文件或额外的配置文件，您只需阅读一个compose.yml即可了解整个应用程序堆栈。

我认为我们为https://github.com/docker/compose/issues/1987#issuecomment -139632238建议的解决方案将解决此问题。 可以将“ admin”服务定义为单独的配置，并在需要针对组合运行admin命令时将其添加为-f 。

@dnephin ＃1987（注释）中的解决方案_does_处理“管理服务”，但_doesn't_处理“仅数据容器”，对吗？ 您仍然必须使用command: /bin/true解决方法。

您不需要带有compose的仅数据容器，因为compose将为您处理将卷交换为重新创建的容器的过程。

@ cpuguy83在下面的示例中，数据容器并不是真正必需的，但是如果要更改音量，则只需要查看一个指定的位置即可。

nginx:
  image: nginx:1.9
  volumes_from:
  - data

php:
  image: php:5.6-fpm
  volumes_from:
  - data

data:
  image: debian:jessie
  volumes:
  - ./:/app

但是，我同意这是一个特例，添加其他语法可能不值得。 我只是说提议的解决方案无法处理这种情况。

的确，数据量仍然需要一些命令，因此您必须使用最小的映像来支持该命令。

我尚未完全了解即将推出的新卷API，但我希望我们能够添加volumes:部分来撰写，以更好地处理数据量（而不是为他们要求一个容器）。

这不一定是正确的选择，但我认为应该考虑学习曲线/易于理解。

我觉得（2）是最容易理解的。 我真的没有办法确认这一点，但是我的直觉说，大多数不熟悉docker-compose的所有选项的人都遇到了我们要在这里解决的问题， “我希望有某种方法可以使容器在我运行docker-compose up ，”他们看到start: false和bam，我们做得很高兴。

他们没有说：“如果只有一种方法，我可以创建一个带有尴尬的链接故事的第二个文件来解决这个问题……”（因此，我意识到https://github.com/docker/compose/issues/ 1987＃issuecomment-139632238帮助解决“尴尬的链接故事”，是吗？

（4）有点模糊，但像这样的脚本和一次性工具的专用途径符合此“合理”的要求。

今天，我正好在寻找(2)但最后找到了我最不喜欢的解决方案，第二个YML文件。 我的用例：

我有几个容器，它们都链接到同一个mongo容器。 我想为自己和团队提供将夹具加载到mongo数据库中的能力，并且我认为最简单的方法是使用另一个名称fixtures加载mongo容器本身链接到mongo，然后运行mongorestore --host mongo --port 27017 --drop /dump 。 由于我们不想一直加载设备，因此使用start: false感到很自然，但是最终为两个容器fixtures和mongo拥有了一个单独的YML文件

效果很好，但是start: false是更干净的IMO。 如果我要对这个所谓的Fixture容器进行10个或更多的排列，那么start: false将是一个坏主意，我将使用(1) 。

只需制作一个撰写文件，其中某些服务不应使用docker-compose up -d命令执行。 对我来说，选项（2）是解决我的问题的最佳方法。

我也碰到过这一点。 不确定哪种方式是最佳解决方案，但对我而言，我需要能够构建用作合成一部分的图像的能力。 它们用于临时容器，但是我需要准备使用该图像，以便可以按需运行该容器。

嗨！ 同样的问题，很高兴有一个很好的分组问题，很棒的工作！

就我而言，我有一个python堆栈，可以处理几个带有服务的容器。 一切工作正常，但我刚刚发现了一个盒子。 我正在用bower管理静态依赖项，并且想在容器内运行bower命令，它只是一个脚本，我们会偶尔运行一次。

在我们拥有的compose结构中运行此脚本会很棒。 我想像的东西：
docker-compose运行节点Bower安装

所以我喜欢第4个选项中的第2个。 只需要不启动服务，就不需要：P

如果达成共识，我可以尝试发送请求“重启”的请求
开始：总是
也许...不知道。

对方案2再次投票。

我也希望选择2。 可以在docker-compose文件中指定新的Docker数据容器，但不需要运行它们就可以使用。

我也可以选择2

选项2很棒。

为选项2 +1

选项2的+1。维护多个文件并输入文件名只是浪费时间。 一个布尔标志将全部统治。 ：啤酒：

为选项+1 +1
如果我必须选择第二个收藏夹，则选择2。

没错，如果我可以同时为+1和+1的话，最好的选择是2,4，那就是我要做的，如果我不反对，我将投多数票并投2票。

投票2

2和4都很棒。
+1 2

我认为没有必要为任务引入新概念。 在我看来，这些内容读起来非常好，并且无需做很多修改就可以实现：

// 'task' being a service that manages all my tasks, probably with some custom entrypoint script
docker-compose run task tests

// 'tests' being a service specifically for testing with the default command set to run my tests
docker-compose run tests

在我看来，带有单独撰写文件的当前“解决方案”并不是真正的解决方案。 正如@xaka所说，没人愿意输入所有这些内容：

docker-compose -f default-file.yml -f additional-tasks-file.yml  run task myTask

您最终将得到一个./run-task脚本，该脚本会为您添加myTask之前的所有样板。 但是现在您已经向您的multi-container-app添加了另一个入口点和接口。 开发人员看到docker-compose.yml并认为：_“哦，太棒了，这是一个编写应用程序。我知道如何处理这个问题！” _现在您必须告诉他们：_”对，您可以使用docker-compose来管理它。

start: false / up: false / some-additional-flag-to-a-service: false可能是最简单的实现，但也很可能也是最清晰，最容易理解的。 它将大大提高可用性。

@sherter说了什么。 ：arrow_up：

：+1：为此。 单独的dockerfile是一个巨大的痛苦，尤其是在涉及网络时

start: true|false方法太有限。 如果将某些服务用于测试，将其他服务用于管理员，将其余服务用于正常操作该怎么办？

我希望将分组的概念添加到服务中。

    myservice:
       group: `admin`

如果未定义group属性，则假定default 。
这样，我们可以使用docker-compose up -g admin -d启动默认服务和管理服务。

更好的是，将groups做成一个数组。

创建服务的组类似乎是一项强大的功能，但似乎也与此问题相关。

在docker-compose版本2上，每个容器都在services:顶级项目中声明。
使用start: never声明服务以运行脚本听起来是错误的。
因此，考虑到新格式，我们是否应该在_services _，_ volumes_和_networks_之外声明一个额外的顶级项目？

我的建议：

• 向v2添加一个新的scripts: ， transients: （或认为更好的名称）顶级商品。
• 在瞬态内部，您可以定义容器，就像处理任何服务一样
• 唯一的区别是它们默认情况下不会_start，因为它们仅用于临时使用。

例：

version: "2"

services:
  web:
    image: myapp
    networks:
      - front
      - back
    volumes:
      - /usr/src/app/
  redis:
    image: redis
    volumes:
      - redis-data:/var/lib/redis
    networks:
      - back

scripts:
  bower:
    image: my_image_with_bower
    volumes_from: web
    working_dir: /usr/src/app/static
    command: "bower"
// maybe would be great to place something like "bower $@"
// to define where you want the cli arguments to be placed, by default at the end.

volumes:
  redis-data:
    driver: flocker

networks:
  front:
    driver: overlay
  back:
    driver: overlay

然后您可以运行：

docker-compose script bower <EXTRA_CMD_ARGUMENTS |  default nothing>

docker-compose script bower install

顾虑：

• 听起来OverPowered只是为了管理启动而创建另一个顶层项目，但这是由于新格式声明了顶层行为而引起的。
• 我试图想象这可能会增加额外的灵活性（和问题）。

最后，在_groups功能上，听起来不错，但是如果您有这么多的分组，我看不到为每个文件创建docker-compose文件的问题。 可能您想要的功能是docker-compose文件继承，这真棒！

PD： @bfirsh也许，如果您喜欢这个想法，可以将其添加到“可能的建议”中

第二，这是对第四个建议的修改，因为即将推出新格式的声明服务。

投票选择选项2：最清晰，最易读且不需要学习新概念
只想要默认情况下不启动的服务

像disabled: true这样的东西呢？

@ cpuguy83这似乎意味着整个服务都被禁用，即使是run 。 我会感到困惑。

@qcho hmm，既然我从1.6开始就熟悉Docker，我可以看到您和@gittycat在说什么。 从这个意义上说，我真的很喜欢@gittycat的方法。 我想象（蓝天）一个界面，像：

groups: # if no groups, all services are in the "default" group by…default
    - foo
    - bar
services:
  foo:
    image: imagine
    groups: foo
  bar:
    image: energy
    groups: bar
  baz:
    image: money
    # no groups, so "default"
   quux:
    image: word
    groups:
      - bar
      - default

同时，在外壳中…

docker-compose up -d # Up all services in default group, so 'baz' and quux
docker-compose up -d --groups foo # Up all services in the foo group
docker-compose up -d --groups foo,default # You get the idea
docker-compose run --rm bar somecommand # We never started 'bar', so it can be a one-off command

这样的方法太棒了，并且不需要此票，但是确实超出了其范围。

@kojiromike我不这么认为。 这就是初始化系统引用不应自动启动的服务的方式。

它也很简单，任何“混乱”都可以通过文档解决。
我还发现它比这种分组要少得多，后者与服务启动的概念完全无关。

@ cpuguy83我认为“服务”的语义首先就是令人困惑的。 我同意，分组是范围蔓延。 从这种意义上讲，我更喜欢选项4 / @qcho的方法，在此方法中，它们将“服务”与“非服务性事物”区分开来。

就是这一点，为什么我应该将一个永远不会运行服务的容器放在“服务...已禁用”类别下。 听起来像某人制作的丑陋补丁，而且不直观。

也许格式的“版本2”已经考虑到了这个问题。 例如，另一个规格可能是

version: 3?
containers:
  webserver:
    ...
  database:
    ...
  cache:
    ...
  some_script_container:

services: (they are groups):
  production:
    webserver:
      ...
    database:
      ...
    cache:
      ...
  development:
    webserver:
      ... DEFINE SOME CUSTOM DEV STUFF ABOVE basic container definition
    database:
      ...
    cache:
      ...     

好的，现在我们有了适当的服务，并具有组定义。 我可以开始生产或开发服务小组。 或者只是在some_script_container中运行脚本。 由于未在任何服务中定义它，因此不会启动任何人

@qcho取决于服务的定义，但是在任何情况下，我都会质疑只应偶尔运行的某些东西，只有人可以确定是否应该运行它。

因此，假设compose采用了类似job对象的方式。

1. 作业只能运行一次
2. 服务后开始工作
3. 预计工作将退出
4. ???

现在，compose还需要保留有关该作业的一些本地状态，而该状态目前根本不执行。

这就是为什么添加简单的auto-up: false或autorun: false是处理此问题的最简单，最不令人毛骨悚然的方式。

@ cpuguy83我认为您正在用更复杂的内容扩展我的意思。 我不想让docker知道任何工作或工作流程。 可以为此编写外部脚本。 我打算让docker-compose定义整个堆栈以使应用程序运行。

我可以想象自己创建一个脚本并保持您说的状态。 甚至在服务启动之前（而不是在启动之后）调用脚本。 我没有想到的是我自己解析了composer文件，因为我需要检查需要导入哪些卷，或者需要在未知容器上从中提取哪些配置才能运行适用于该文件的脚本。 所以我认为docker-compose应该给我那个容器； 运行脚本并保持状态是我的问题。

我不明白为什么人们一直这么说

services:
  my-script-container:
    auto-up:false

比以下简单：

scripts/containers/transients/you_name_it:
  my-script-container:

这是相同级别的复杂性。 但是从语义上讲，这种做法不那么容易破解。

要在一个线程上获得想法，请参考＃2803

用例：您有一个包含许多组件和用户的项目，用户可以选择并选择要安装的组件，但是他撰写的文件可以将它们全部安装。

提案：我们添加了一个选项以将docker-cmpose.overrider.yml放入其中，以排除docker.compose中定义的图像

即

一些图像：
排除：是

行为将是忽略docker-compose.yml中的该条目

您能否让我知道团队的想法，我会对更改有所兴趣。

投票第二名...今天也遇到了这种需要。

@jimzucker的建议也可以使用，尽管我喜欢在主.yaml文件中看到“ start：false”的想法，以立即提示您该“服务”将无法运行，除非您明确地调用它。 否则，您（或者在我的情况下，您将docker-compose文件交给的最终用户/开发人员）需要记住寻找替代文件。

+1（代表2）。我遇到一种情况，我需要在compose中构建一个docker映像，但它不能作为服务运行。 其他服务（内部装有docker袜子）每隔一段时间就会从映像运行容器。

+1表示2，+ 1表示“自动启动”或“自动运行”。

服务组的情况（如@gittycat所述）不能通过环境变量ala“自动启动：$ {ADMIN}”来处理吗？

我还看到在docker-compose.yml标记服务的实际用例不是用简单的docker-compose up自动启动，而是仅显式启动。

解决方案1）现在是一种可能的方法，但我认为这太麻烦了，因为必须指定一个或多个yml文件，而不是仅调用docker-compose up并且必须拆分甚至复制这些文件。

因为我真的很想看类似解决方案2）的东西（就像其他许多人一样），所以我在＃3047中实现了这一点的概念验证，因此您可以尝试一下它，看看它是否可行解。

为选项2 +1

为选项2 +1

为选项2 +1

为选项2和4 +1

为选项2和4 +1

选项4的+1。脚本不应进行某些配置（例如：重新启动：始终）

使用选项2，可能会出现以下奇怪的情况：

service:
  run_tests:
    build: ./tests/
    restart: always
    auto-start: "false"

那是什么意思？

@mathroc ：这意味着：“在执行compose时不要自动启动此容器。当此容器停止（显式启动后）时，无论退出代码如何都重新启动。” 这有什么奇怪的？

@niko哦，对了，我应该在发布之前再考虑一下...

将选项2的“投票”更改为+1

为选项2 +1，我在多个项目中都需要这样做。

ping @bfirsh @dnephin ：
您能否提供有关此问题的最新消息？ 由于此处的大多数评论都支持选项2，目前是否有任何计划来实现类似选项（或选项3/4）？
如果可以考虑合并请求，则可以完善我的请求（＃3047）并完成测试和文档。

谢谢。

为选项2 +1

为选项2 +1

为选项2 +1

我认为选项1可以起作用，但是我们需要一种更好的方法来减少以下内容的冗长性：

docker-compose -f docker-compose.yml -f docker-compose.tests.yml up

也许可以添加一个简化/增加标志？ docker-compose --augment tests up并自动解析它是否是docker-compose.yml的变体-否则用户将需要明确。

我真的很喜欢新的顶级关键字的想法，也许suites和commands吗？

以下配置将允许：

docker-compose run -s application
docker-compose run -c cache-clear

suites:
    application:
        services:
            - database
            - memcached
            - application
    tests:
        extends: application
        services:
            - application

commands:
    cache-clear:
        service: application
        workdir: /var/www
        command/entrypoint: php app/console ca:cl

我在代码中看到，已经有了“ oneoff”服务的概念（恕我直言，仅在调用docker-compose run 。
可以重用吗？
如果我用com.docker.compose.oneoff=True标记一个容器，它将尝试启动它吗？

否则，我投票给选项2。

我只是偶然发现了这个，所以这里有两个用例：

1. “全局”环境变量：这里建议的方法是使用extends ，我很好...但是现在我需要为我要扩展的东西定义一个image ，甚至不能使用scratch （因此以https://hub.docker.com/r/tianon/true/结尾）。
2. “扩展”服务：默认情况下，我有一个MongoDB实例，但是对于某些测试，我想定义第二个非活动实例，可以为那些测试提出该实例。 在另一个文件中使用extends似乎是一个可行的想法（仍在学习docker / docker-compose及其涉及的最佳实践）。

为选项2 +1

为选项2 +1

为选项2 +1
似乎是一个简单的变化...

+1选项2

在多个容器共享一组通用的env和配置的用例中，构建一个基础容器以从其扩展但实际上不会启动该容器是有意义的

auto-start:true|false

自去年9月以来有一个不错的解决方案叫做rocker-compose ，我建议运行：_always_ | _once_ | _决不_。 我也喜欢状态：_running_ | _ran_ | _created_。

不喜欢为此功能使用单独的项目，我最终从tianon / true项目中窃取了True asm代码命令，直到实现

我最初还以为选项2最好，但现在我开始认为它的限制性太强，添加后很快就出现了运行一次任务的需求。 实际上，我现在正在一个项目中，我需要以下用例：

• 在堆栈中，我希望能够定义在初始部署时运行一次的容器，而将来的运行仅在外部触发（例如，计划/事件，通过API调用等），以便它们可以初始化/更新主服务容器的状态在同一堆栈中（例如，DB数据/架构，填充数据量等）
• 在堆栈中，我希望能够定义仅在外部触发的容器，以便可以用于封装实用程序/管理任务（例如状态/数据检查等）和按计划触发的过程（例如备份），或者通过外部事件（例如，触发对S3存储桶更改的过程）

在我的情况下， state: created （运行0次）和state: ran （运行> = 1次）之间的区别很重要，因为某些实用程序/管理任务可能具有破坏性，只能用于在某些情况下，例如迁移服务。

鉴于我现在更倾向于state: running | ran | created如在rocker-compose或选项4中一样，具有顶级_task_或_job_ object +表达依赖项的能力，以便服务可以触发任务在其自身之前/之后运行。

我想提一下，这对我的用例很重要。 我使用docker-compose创建测试环境并运行测试套件。 一次启动所有容器的问题在于，在运行测试套件之前，我无法轻松地允许服务容器（例如数据库或celery worker）进行初始化。

最好能够完成以下任务：

$ docker-compose --file="docker-compose-testing.yml" up -d --exclude=tests
$ sleep 5
$ docker-compose --file="docker-compose-testing.yml" run --rm tests

您可以想象，可以编写比sleep 5更为复杂的代码来验证是否发生了初始化，但是对于示例片段而言，这不是必需的。

我没有阅读有关cli标志的选项。 因此，我建议将--exclude标志添加到选项列表中。 --exclude标志将告诉up命令不要启动指定的容器。 将分析--exclude标志，以便可以根据需要从启动中排除多个容器。

：+1：

考虑另一种用例，其中选项2是合适的解决方案：在现有应用程序中迭代新的子服务。 该项目上的大多数开发人员都不需要新服务，您当然不希望它的问题妨碍他们的工作，但您也可能希望避免在较长的时间内维护树外分支。时间。

一个单独的“ docker-compose-experimental.yml”文件可以工作，但这意味着在该组件仍处于实验阶段时，需要以一种方式编写用于处理该组件的所有文档，然后在成为标准集的一部分时对其进行修订。服务。

+1到选项2

选项2的+1

为选项2 +1

为选项2 +1

为选项2 +1

@acran我想看到您提交拉取请求，看看我们是否可以在这方面取得一些进展，也许如果您为消除＃3047上的冲突而改头换面，它将被捡起，不确定如何引起注意。

@jimzucker好＃3047已经是请求请求，我仍在等待开发人员对此发表评论：失望：

参见我上面的评论：使PR具有可合并性还需要一些改进，例如更新相关文档和测试用例。 但是我宁愿不做这项工作，也不知道这种方法将被上游公司认为是集成的。 否则我对此所做的努力可能毫无意义。

+1选项2

@acran ，我想帮助您更新相关的文档和测试用例。 可以吗

+1选项2

还是像Kubernetes那样定义一种工作？

为选项2 +1

我们有一个包含多个服务的docker-compose，其中之一（数据库）必须在开发环境上启动，而不能在生产环境上启动。 因此，我们必须维护两个docker-compose文件。 选项2正是我们想要的！

：+1：对于选项2

+1选项2

@acran我正在与SF中的一些连接处联系，以找到正确的过程/渠道以获得反馈，以便可以继续前进，敬请期待；）

👍对于选项2

为选项2 +1

+1选项2

+1选项2

我也投票给选项2

另一个想法：现在我们有了顶级networks和volumes ，我们也可以添加images选项。 这暗示了Compose必须拖动或构建这些图像才能使应用程序正常工作，但是当您执行docker-compose up时，它们将不会运行。

这将适用于两个用例，而这几乎是我的脑袋：

1）这里的常见问题是您要在其中运行某种管理命令。 如果服务不存在，则docker-compose run可能会退回到正在运行的映像。
2）像这样的应用程序运行Docker映像，但它们并非一直运行。

/ cc @dnephin @aanand @

除了能够在docker-compose文件中配置短期容器需要的所有选项（即卷/挂载点，网络，链接，名称等）会很好，这样您就不必每当您需要运行该容器时，都必须继续添加它们...

在CDT于2016年9月13日凌晨3:58:41，本·菲什曼[email protected]写道：

另一个想法：现在我们有了顶级networks和volumes ，我们可以
还要添加images选项。 这可能暗示着这些
必须提取或构建图像才能使应用程序正常工作，但是它们
当您执行docker-compose up时将不会运行。

这将适用于两个用例，而这几乎是我的脑袋：

1）这里常见的问题，您需要某种管理
命令运行。 docker-compose run可能会回到正在运行的图像
如果该服务不存在。
2）类似的应用这跑
Docker映像，但它们并非一直运行。

/ cc @dnephin @aanand @

您收到此邮件是因为您发表了评论。
直接回复此电子邮件或在GitHub上查看：
https://github.com/docker/compose/issues/1896#issuecomment -246618909

使用K-9 Mail从我的Android设备发送。 请原谅。

我同意@mgriego 。 想一想生成生成的容器-最好将所有命令和选项都设置好，仅docker-compose up foo并让其执行生成和退出操作。

试图在这里获得更多的理解：选项2）是否只是更通用的“我们想要docker-compose.yml的initial_scale值”的特殊情况？ （请参阅＃1661，＃2496等）。

@ankon一点也不。

添加images [section]

@bfirsh，这开始朝我使用https://github.com/dnephin/dobi的方向发展

1. networks和volumes从未真正直接操作过，它们只是根据容器的需要创建的。 将图像分为自己的部分不会改变我们现在的行为，只会使Compose配置更加复杂。 如果只想生成映像，请运行docker-compose build 。
2. 我认为它实际上无法解决此问题中确定的问题。 人们需要容器，而不仅仅是图像

重新阅读该线程以及＃2496中有关在撰写文件中声明缩放约束的讨论，我开始倾向于选择Option 4（即新的顶层部分），而不是Option 2。

具体来说，像utilities这样的节名称将是一个很好的选择：通常不需要的组件，但是当您确实需要它们时，您希望预先配置它们链接到的其他组件，而不必让人们自己构造合适的docker run咒语。

这样，该方法不仅将覆盖一次性的管理命令，而且还将覆盖辅助调试和自省服务，例如pgweb和Celery Flower（在开发中运行非常方便，但是由于额外的安全性，通常您不希望在生产中使用）他们创建的威胁表面积）。

定义这些新的“非服务”的语义也变得容易得多：它们与services完全相同（包括将来对该格式的所有更改），唯一的例外是不合格的命令，例如docker-compose build ， docker-compose pull和docker-compose up完全忽略它们-如果要处理“实用程序”中列出的任何组件而不是“服务”，则需要专门命名（尽管有可能是--all选项，类似于当前的docker-compose rm ）。 但是，用于通过名称与这些实用程序进行交互的CLI与用于与普通服务进行交互的CLI相同（与现状不同，在这种情况下，您需要指定额外的实用程序配置文件），而docker-compose将负责防止名称冲突服务和实用程序定义之间。

尽管可能会（＃）使用＃2496中的缩放建议来实现此目的，但它仍然感觉像是一种解决方法，而不是经过适当设计的功能。

我喜欢这种设计，@ ncoghlan。

代替utilities命名.services怎么样？ 这自然表明services和.services使用完全相同的语义，唯一的区别是默认情况下不运行.services 。 这与默认情况下不显示的文件名非常相似。 我认为缺点是两者之间的区别有些微妙。

我喜欢@ncoghlan谈论的基本想法，但是…

1. 不同意_all_不合格的命令默认情况下应忽略这些实用程序。 我认为，除了那些会导致容器运行的命令外，所有命令都应正常运行。 （因此，基本上是up和start 。）
2. 关于@dsem的评论，我比'.services'更喜欢'utility'的语义。 我了解unixy隐藏文件的推理，但是这些东西不仅仅是隐藏的服务，它们还是服务的助手。

@bfirsh @ncoghlan我完全同意@dnephin的观点：

我认为它实际上无法解决此问题中确定的问题。 人们需要容器，而不仅仅是图像

我-而且我认为这里的大多数人-我所需的工作流程所需要的是简单的服务； 它们的定义类似于任何常规服务，它们的启动/停止类似于常规服务等。
_only_的区别在于，默认情况下它们不会由简单的docker-compose up自动启动，而是仅在显式指定（或作为依赖项引入）时自动启动。

因此，对于这些一次性容器，我认为不需要新的顶级部分或全新概念，而只能选择每个服务配置参数。
我在请求请求＃3047中实现了这一点，作为概念证明。 这是一个很小的更改，但完全可以满足我的用例。 因此，如果我还有其他工作要做，请合并为我，

对于任何想要测试它的人，请在此处在容器中构建和运行docker-compose的命令：

# download and build
git clone [email protected]:acran/compose.git -b auto_up
cd compose
docker build -t docker-compose .

# create an example docker-compose.yml
cat > docker-compose.yml <<EOF
version: "2"
services:
  foo:
    image: busybox
    auto_up: false
    command: echo foo
  bar:
    image: busybox
    auto_up: false
    command: echo bar
    depends_on:
      - foo
  baz:
    image: busybox
    command: echo baz
EOF

# start all default services only, i.e. baz
docker run --rm -v /var/run/docker.sock:/var/run/docker.sock -ti -v $(pwd):$(pwd) -w $(pwd) docker-compose up

# start service foo only
docker run --rm -v /var/run/docker.sock:/var/run/docker.sock -ti -v $(pwd):$(pwd) -w $(pwd) docker-compose up foo

# start service bar, foo is pulled in as a dependeny
docker run --rm -v /var/run/docker.sock:/var/run/docker.sock -ti -v $(pwd):$(pwd) -w $(pwd) docker-compose up bar

# clean up all services, i.e. foo, bar and baz
docker run --rm -v /var/run/docker.sock:/var/run/docker.sock -ti -v $(pwd):$(pwd) -w $(pwd) docker-compose down

@acran ，我想帮助您更新相关的文档和测试用例。 可以吗

@ dattran-vn01当然，我会很高兴：smiley：

在您的示例中， @ acran是唯一一个与当前Compose行为不同的命令是第一个命令，可以使用up baz来完成该行为。
您还可以通过使用多个Compose文件来完成同一件事。

让某些命令在默认服务的不同列表上运行似乎很令人困惑，这也是我不喜欢此功能的原因之一。

在您的示例中， @ acran是唯一一条与当前Compose行为不同的命令是第一个命令，并且可以使用up baz完成该行为。
您还可以通过使用多个Compose文件来完成同一件事。

@dnephin是的，确切地，我知道，在此示例中，这是最简单的方法。
但请想象一下，这里有10个服务，而只有一个一次性服务（例如“ init”或“ backup” /“ dump”）：在这种情况下，您必须在命令行上列出所有服务，但只有一个单项服务-关闭服务，例如docker-compose up service1 service2 ... service10 （请参见下文）。 特别是您必须记住所有服务，并手动跟踪docker-compose.yml的任何更改。

我也知道使用多个YAML文件的可能性，请参见上面的第一条评论，并且在命令行上明确提供所有服务的确确实涵盖了此处所述的大多数用例。 但感觉更像是一种解决方法。

下面是另一个示例docker-compose.yml以可视化该问题：

version: "2"
services:
  init:
    image: busybox
    auto_up: false
    command: echo "I do one-time initializing"
  service1:
    image: busybox
    command: echo "I'm service #1"
  service2:
    image: busybox
    command: echo "I'm service #2"
  service3:
    image: busybox
    command: echo "I'm service #3"
  service4:
    image: busybox
    command: echo "I'm service #4"
  service5:
    image: busybox
    command: echo "I'm service #5"
  service6:
    image: busybox
    command: echo "I'm service #6"
  service7:
    image: busybox
    command: echo "I'm service #7"
  service8:
    image: busybox
    command: echo "I'm service #8"
  service9:
    image: busybox
    command: echo "I'm service #9"
  service10:
    image: busybox
    command: echo "I'm service #10"

一个简单的docker-compose up _with_ auto_up属性从此处开始，除服务init之外的所有服务。 要在没有它的情况下实现相同的功能，则需要输入更长的命令并提供10个服务，或者拆分YAML文件并必须指定多个文件。

因此，此处要求的功能更多地是关于便利性，而在cli上键入的内容较少，而不是一项全新的功能。

关于“使用多个配置文件”选项（这确实是目前最好的选项），其可用性问题在于实际上它是这样的：

$ docker-compose up one-shot-command
ERROR: No such service: one-shot-command
$ docker-compose up -f docker-compose.yml -f docker-compose-utils.yml one-shot-command
# Actually goes & does the requested thing

然后，差异会感染项目文档和自动化的_all_：您必须确保_two_ compose文件可供想要运行实用程序命令的任何人使用，您必须确保对实用程序文件中的命令进行了完整调用，如果有命令或服务曾经从“始终运行”降级为“仅在明确请求时运行”，您需要查找任何不提供配置文件名的调用并将其添加。

这就是全部_doable_，与在撰写文件中说“仅在我明确要求您运行时才运行，默认情况下从不运行”相比，这很烦人。

曾经有人告诉我：_“如果几个聪明的人不能决定哪种方法最好，那么通常都不好。最坏的是什么也没做。”

这张卡似乎是一个很好的例子：）

鉴于docker现在为长期运行的命令本机支持服务的概念，我认为最好的方法是添加一个名为command的新部分，该部分除了提供重新启动策略外，还应具有与服务相同的功能，但应禁止该策略。

在我的设置中，我在docker-compose中有运行我的基础结构所需的服务（nginx，数据库，Web服务器，消息队列...）。 我还定义了仅出于调试原因而需要的其他服务（例如，数据库Web gui）。

我希望“调试”服务不会自动启动，但是如果我要添加它们，我可以使用一个简单的docker-compose up -d database-gui ，而只是添加它。

另外：有时我改变主意，并希望这些服务之一始终启动... =>使用选项2）我可以只更改一个标志

=>为选项二投票，因为它很简单，而且似乎可以满足每个人的要求。 所有其他解决方案对我来说都感觉像是过度设计...基于很少或仅想到的用例，而不是根据实际需要，为配置增加了复杂性。

请在这里添加我的+1。 我正在Django应用程序上运行，在docker中运行它们时，最好有一个可以运行shell或测试的容器，或者就此而言，迁移命令。 但是我不想每次启动应用程序时都运行这些程序。 虽然可以使用多个配置文件，但需要键入，编写脚本或为英里长的命令行添加别名。 如果我想做到这一点，我根本就不会使用compose，我只会用shell脚本编写我的容器（或者用python编写脚本...也许添加一个统一的YAML文件来存储容器配置...等等...）不想做docker-compose -f common.yml -f dev.yml -f local.yml -f commands.yml up migrate类的事情只是为了在我的容器上运行数据库迁移。 另一种方法是使用/bin/true作为命令，并执行docker-compose -f common.yml -f dev.yml -f local.yml up commands 'python3 manage.py migrate'类的命令，但也不是很优雅。 因此，将一次命令存储在配置中的某个位置对我来说非常有用。 选项2、3和4中的任何一个都对我有用。

我想建议您看看dobi ，这是我一直在部分基于此线程的反馈而致力于的工具。

compose旨在启动形成“环境”的长期运行的服务。
dobi专注于顺序项目构建任务。

您正在寻找的东西（运行外壳，运行单元测试，运行迁移）都是项目任务，因此它们在dobi模型中更适合。

dobi和compose可以很好地协同工作，您可以使用compose资源从dobi启动compose。

compose=dev-environment:
  files: [docker-compose.yml, local.yml]
  project: 'theprojectname'

您可以使用以下命令运行：

dobi dev-environment

这里有一个组成集成和运行数据库迁移的示例： https :

这里有许多工作流程的示例（包括运行测试，启动交互式shell，发布和构建最小图像）： http :

+1表示2）。 在我们看来，无需思考和讨论一次性命令之类的不常见用例，但是我们只想拥有已创建并可以使用的真实服务，但是可以在需要时按需启动（并且默认情况下不会消耗资源）。

“罕见的用例”？ 您运行数据库迁移吗？ 您是否运行单元测试？ 你跑皮棉吗？ webpack？

是的，我可以运行，但是我认为可以在容器内部实现和控制。 但是我不想贬低您的观点或要求，我们不要让讨论变得火热。 我们对docker compose的要求不一定会发生冲突。

我刚遇到这个线程，试图找到一种方法来为脚本创建一个docker-compose容器，该脚本擦除了mysql容器中的数据库并从下载的转储中重新加载了架构。 这是一个非常漫长和破坏性的过程，因此我不希望它在每次启动服务时都运行，但是它也需要使用自己的dockerfile在组成的一组容器中运行。

称它们为任务，命令等等，但是我有点没有它。

我偶然发现了其他东西，只是想加入一个用例...我们发现我们的开发人员最有能力定义应从其服务备份哪些数据。 由于使用了docker-compose.yml文件并使用了命名卷，因此我们决定使用它来定义备份策略...这是我们使用的旧docker-compose.yml的摘要示例。

version: '2'
services:
  gitlab:
    image: gitlab/gitlab-ce:latest
    restart: always
    ports:
      - "5555:5555"
    volumes:
      - gitlab_config:/etc/gitlab
      - gitlab_logs:/var/log/gitlab
      - gitlab_data:/var/opt/gitlab
      - certificates:/etc/gitlab/ssl
      - registry_data:/var/opt/gitlab/gitlab-rails/shared/registry
  gitlab-runner:
    image: gitlab/gitlab-runner:latest
    restart: always
    volumes:
      - certificates:/etc/gitlab-runner/certs
      - /var/run/docker.sock:/var/run/docker.sock
volumes:
    gitlab_config:
      driver: local
    gitlab_logs:
      driver: local
    gitlab_data:
      driver: local
    certificates:
      driver: local
    registry_data:
      driver: local

为了能够备份卷数据，我们决定使用一个busybox容器来压缩所需的数据，但是它必须灵活并且仅执行开发人员要备份的卷。 最后，我们应该能够分别备份每个卷。 为此，我们向所有docker-compose.yml添加了3个服务

  boot:
    image: busybox
    depends_on:
      - gitlab
      - gitlab-runner

  backup:
    image: busybox
    volumes:
      - gitlab_config:/data/gitlab_config
      - gitlab_data:/data/gitlab_data
      - registry_data:/data/gitlab_data
      - /backups/latest:/backup
    command: find . -type d -maxdepth 1 -mindepth 1 -exec tar cvf /backup/{}.tar {}  \;
    working_dir: /backup

  restore:
    image: busybox
    volumes:
      - gitlab_config:/data/gitlab_config
      - gitlab_data:/data/gitlab_data
      - registry_data:/data/gitlab_data
      - /backups/latest:/backup
    command: find . -type f -iname "*.tar" -maxdepth 1 -mindepth 1 -exec tar xvf {} \;
    working_dir: /backup

备份和还原服务只需要使用卷进行配置，其余的将由命令完成。 我们正在计划添加一些配置，以便能够选择要备份或还原的卷，但是现在，我们全部完成了...因为我们不希望这2个服务在每个docker-compose上启动up命令，我们需要指定所需的所有服务，这可能很繁琐...因此，我们添加了一个名为boot的虚拟服务，它所做的只是取决于所有需要运行的服务，我们在运行时就调用了该服务。 docker-组成。

这里充满了小技巧，但允许我们轻松运行docker-compose up backup来将备份存储在主机的/ backups / latest中，然后从那里运行版本控制/修剪逻辑。

我希望它能帮助那些试图实现类似目标的人...但是最后，能够告诉docker-compose不要启动这两项服务，我们不需要第三项服务就可以使docker-compose变得复杂命令。

在开发中，我们目前有4个docker-compose文件：

• docker-compose.yml ：定义完全运行我们的应用程序所需的核心服务，例如redis，MySQL，php-fpm，Laravel队列处理器，nginx，Solr
• docker-compose-utils.yml ：定义运行开发任务所需的实用程序服务，例如gulp，npm，artisan（Laravel），composer，redis-cli，通常与上述服务一起运行
• 另外2个docker-compose文件定义上述服务的环境和卷

此设置非常有效，因为在Docker之外，我们对开发环境的依赖性最低。 缺点是指定所有必需的.yml文件以运行简单实用程序所需的繁琐命令行。

我们在macOS，Windows和Linux上进行开发。 此外，我们的许多开发任务都需要某种类型的参数化（例如，创建数据库迁移，使用自己的参数运行composer / artisan / npm命令），因此我创建了schmich/runx作为零安装交叉代码，平台任务运行程序来捆绑我们的常见开发任务。

例如，这让我们说runx migrate：make create_some_table有效地运行docker-compose -f docker-compose.yml -f docker-compose-utils.yml -f docker-compose-dev.yml -f docker-compose-utils-dev.yml run --rm artisan migrate:make create_some_table ，或者说过时的runx npm查看我们过时的JS依赖关系。

我没有使用上面提到的dobi ，但是runx精神相似，尽管不太适合Docker环境。 最终，除了绝对需要的地方，我想避免到处都是依赖项：服务本身以及开发中所需的实用程序脚本。

任何新闻？ 我认为该功能非常好！ 我投票支持像default这样的顶级配置的解决方案，在这里我们可以指定必须运行的服务。
boot虚拟服务很好，但是我更喜欢将进程放在前台，因此当我完成这项工作后，我可以简单地关闭终端以关闭所有设备。 默认情况下附加输出也很好，并且在哑服务中不会发生这种情况。

由于noboby使用.env文件评论了用例，因此这里是我的：

我有4个撰写文件：docker-compose.yml，docker-compose.local.yml，docker-compose.prod.yml和docker-compose.ci.yml。 对于每种环境，我都有不同的.env：

CI .env:
COMPOSE_PROJECT_NAME=foo
COMPOSE_FILE=docker-compose.yml:docker-compose.ci.yml
WEB_PORT=8081
...

Test/dev/etc .env:
COMPOSE_PROJECT_NAME=foo
COMPOSE_FILE=docker-compose.yml:docker-compose.local.yml
WEB_PORT=80
...

等等...

用户和/或脚本不必担心要使用哪个撰写文件，因为已经对环境进行了单独配置。

但我有一个最终要运行的维护实例，无法在主docker-compose.yml内部进行配置，一种解决方案是创建docker-compose.worker.yml并执行带有3个“ -f”选项的命令行每个环境。 这太容易出错，因此不适合使用。

我发现的解决方案是创建一个目录“ worker”，将yml文件放在此处，将上方的.env文件链接到该目录，然后创建空的docker-compose。[ci | local | prod] .yml文件（否则我将拥有更改COMPOSE_FILE变量的值）。

这可以正常工作，但远非最佳。 OP的任何其他解决方案都可以解决这个问题。

我认为这里的讨论，许多示例用例以及经常出现的重复问题都清楚地表明，许多用户确实有可能“定义默认情况下未启动的服务”。 ”。

因此，我真的很想将讨论从_if_应当更多地实施到_how_应当如何实施。 我们是否可以所有人都同意这一点？

关于_how_，可以实现@bfirsh在开头的注释中列出了一些选项：

1）建议用户使用单独的撰写文件

这是该用例当前唯一可用的解决方案。 但是如上所述，在这种情况下，它是一种解决方法，因为它需要手动键入较长的命令行并记住要为哪个命令运行而要包含的Compose文件。
当然，在CI设置或自动部署到生产环境中，这不是问题，因为命令行只需要定义一次即可，而不必手动键入。 因此，这仅与非自动化环境（即开发）中的便利有关，根据docker-compose手册，这是Compose本身的主要用例之一：

这些功能共同为开发人员提供了一种方便的方式来开始项目。 Compose可以将多页的“开发人员入门指南”简化为单个机器可读的Compose文件和一些命令。

仅输入docker-compose -f docker-compose.yml -f docker-compose-utils.yml run init来初始化本地设置对我来说听起来并不方便，但更像是在多页“开发人员入门指南”中找到的东西。

并在此处考虑选项1b）：

建议用户使用包装脚本/工具来使用单独的撰写文件

如果仅为此需要引入其他工具和依赖项，为什么首先要使用docker-compose ？ 从理论上讲，由于docker-compose所做的一切都可以用一个自定义的shell脚本和本机docker客户端直接完成。
我在其标准用户界面中看到了docker-compose的主要优势（我克隆了一个项目，在其中看到了docker-compose.yml ，并且知道我只需要运行docker-compose up即可开始使用） 。 始终必须知道要使用哪个撰写文件来大幅削弱此优势。

2）为服务添加一个选项，以使其默认情况下不启动
3）添加顶级配置选项以定义默认服务

这两个选项基本相同：定义一个服务文件中默认应不启动的服务，选项2）将单个服务列入黑名单，选项3）将一组服务全局列入白名单。
考虑到大多数情况下，单个组合文件中的默认服务要比“一次性服务”多，因此将一项服务列入黑名单可能比将所有其他服务列入白名单以及每次获得默认服务时都要更新白名单要容易得多。添加或删除。 同样使用选项2）合并多个撰写文件可能更容易。

4）添加诸如服务之类的概念，但仅用于一次性命令（“脚本”，“任务”等）。

我认为选项4）只是选项2）或3）的一种专业化，因为在上面的大多数示例中，所需的一次性容器基本上像任何其他服务一样被定义，并且与普通服务几乎没有作用-除了它们默认情况下未启动。 （或者我错过了与“服务”的一些重大区别）。

因此，我认为选项2）是这里的最佳选择，因为它需要的更改最少，但同时又具有足够的灵活性，可以满足此处提到的大多数（或全部？）用例，并且同时使用非常方便。
不过，我也很高兴看到选项3）或4）合并到上游。 在经过一年多的讨论之后，是否有时间表，何时或是否会发生？

我同意选项2可能是侵入性最小的。 我看到选项4可能提供的唯一功能是能够在现有容器上运行命令（使用docker exec机制）。 例如，如果我只想运行数据库迁移或单元测试，那么如果我已经有运行我的应用程序的容器，则可能没有理由为其创建一个完整的单独的容器。 话虽如此，容器是轻量的，我对选项2非常满意。

@MadWombat我对选项4有相同的感觉，这就是为什么我为此用例提出了另一个功能：＃4096。 这里描述的功能有重叠之处，但我认为它可能单独使用或对此功能有用

@mathroc我使用docker exec提到了选项4，因为

我看到选项4可能提供的唯一功能是能够在现有容器上运行命令（使用docker exec机制）。

这确实是一个新的用例，它将证明（并要求）引入不同于服务的新顶级概念。 但是，只要不需要在已存在的服务容器中通过docker exec运行命令，现有的服务概念就足够了。

但是，我无法提出一个实际的用例，在该用例中，您将特别想在现有容器上运行命令，而不是为此目的而提出另一个类似的容器。

我能想到的最接近的情况是，例如更改容器中的配置文件并触发应用程序的重新加载。 使用＃4096中的@mathroc的示例：

version: "2"
services:
  my_service:
    image: my/service
shortcuts:
  start-debugging:
    service: my_service
    command: echo "debug=true" > /etc/myapp/conf.d/debug.conf && mydaemon --reload-config
  stop-debugging:
    service: my_service
    command: echo "debug=false" > /etc/myapp/conf.d/debug.conf && mydaemon --reload-config

尽管与此问题相关，但＃4096有其自己的用例，也许选项4）最好移到那里？

经过一年多的讨论，我们似乎再也没有做出决定了。 @bfirsh应该只是选择一种样式并使用它：smile：

+1

+1，这将是一个非常有用的功能。

选项2的另一个+1，如auto-start: false或enabled: false 。

我的用例是扩展服务。 不可能扩展设置了depends_on ，所以我想做的是定义一个服务模板，然后从中扩展几个服务。 显然，应该构建模板，但不能自动运行。

我创建了自己的解决方案，可以免费使用。
它仍然处于Beta中：）

https://github.com/jonathanborges/picles-docker

这里有很多很棒的选择。 对功能的需求是真实的。

选项2显然是更受欢迎的情况：

1-> 4
2-> 52
3-> 3
4-> 10

选项2的另一个👍

我们可以使用简单返回的初始入口点或命令在“工具”服务中相当轻松地处理此问题。 然后，我们使用替代命令运行此服务以执行所需的操作（例如，测试或播种数据）。 例如

docker-compuse up -d
docker-compose run tools tests

是的，工具服务将在docker-compose ps显示为“已停止”。 如果这是不可接受的，那么我的https://github.com/docker/compose/pull/2051的多文件选项可以工作。 例如

docker-compose -f docker-compose.yml -f docker-compose-tools.yml up -d
docker-compose -f docker-compose-tools.yml logs -f tools

尽管看起来很多编排助手正在为此需求而编写，但我也很努力地帮助一个编排者：）。

我个人认为，有足够的解决方法（例如上述两种方法；使用入口点/容器和/或使用带有外壳别名/帮助器的多文件方法来发挥创意），并且撰写可以保持简单。

@briceburg参见上面的讨论：这里的问题不是关于缺少任何其他方法无法完成的功能。 这里的人们几乎想要实现的所有目标都有解决方法。 但是它们是变通办法和肮脏的hack，而不是docker-compose的常规用例。

这是为了方便，不必在cli上手动输入docker-compose -f docker-compose.yml -f docker-compose-tools.yml up ，而是不必记住它是docker-compose run tools tests还是docker-compose run utils tests ，甚至不必依靠_多页的“开发人员入门指南” _，但是为开发人员提供了统一而简单的界面。

再次，CCing @ bfirsh ， @dnephin ：能否请您提供对此问题的反馈？ 有没有希望我们能在即将到来的路线图中以docker-compose看到类似的东西？

对于简单的环境， @ briceburg也许可以接受解决方法，但有时

rancher<strong i="7">@rancher</strong>:~/servers/sgi/docker$ ls -l 
total 64
-rwxrwxr-x 1 rancher rancher  303 Dec  8 20:05 cleanup.sh
drwxrwxr-x 3 rancher rancher 4096 Dec 16 15:26 conf
drwxrwxrwx 4 rancher rancher 4096 Dec 15 20:03 data
-rw-rw-r-- 1 rancher rancher   94 Dec 14 19:40 docker-compose.amt.yml
-rw-rw-r-- 1 rancher rancher  295 Dec  8 20:05 docker-compose.auth.yml
-rw-rw-r-- 1 rancher rancher  332 Dec  8 20:05 docker-compose.ci.yml
-rw-rw-r-- 1 rancher rancher  112 Dec  8 20:05 docker-compose.dbext.yml
-rw-rw-r-- 1 rancher rancher  347 Dec 14 19:40 docker-compose.dbint.yml
-rw-rw-r-- 1 rancher rancher  688 Dec 15 16:31 docker-compose.full.yml
-rw-rw-r-- 1 rancher rancher   81 Dec  8 20:05 docker-compose.local.yml
-rw-rw-r-- 1 rancher rancher  288 Dec 15 16:31 docker-compose.yml
-rwxrwxr-x 1 rancher rancher  721 Dec 14 19:40 redeploy.sh
-rwxrwxr-x 1 rancher rancher  861 Dec  8 20:05 setup.sh
-rwxrwxr-x 1 rancher rancher   66 Dec  8 20:05 shutdown.sh
-rwxrwxr-x 1 rancher rancher  269 Dec 14 19:40 startup.sh
drwxrwxr-x 2 rancher rancher 4096 Dec 14 19:40 worker

除了worker目录中配置了“默认情况下不启动”容器的文件外，我还有8个撰写文件（可以多种组合使用）。 worker目录（链接到父级的.env文件和一些空的compose文件，以符合父级的.env COMPOSE_FILE变量）是我的解决方法，但是当我们有解决方案时，我的生活会容易得多这个问题。

@vipseixas很难从文件列表中评估该解决方案的

在大多数情况下，您将需要确保在执行测试之前对相关服务/容器进行健康检查-例如，在这些测试执行之前，jenkins已启动并正在运行（接受：8080或其他连接）。 过去，我为此使用了dockerize。

如果我要提出一个灵丹妙药，那就是允许通过环境变量（例如DOCKER_COMPOSE_PROFILE =“ tests”）设置组合配置文件，并允许服务依赖于配置文件-所有服务默认为“默认” ”或其他内容。 我还要确保依赖于另一个服务的服务也依赖于该服务的HEALTHCHECK。 所以像

app:
  image: myapp:v1

tests:
  image: myapp:tests
  dependencies:
    - profile: "tests"
    - service: "app"
      healthcheck: true

# run the things
docker-compose up -d

# test the things
DOCKER_COMPOSE_PROFILE="tests" docker-compose up -d
DOCKER_COMPOSE_PROFILE="tests" docker-compose logs -f

为选项2 +1。

这里的许多人都提出了有趣的新功能，但是这里问题的核心是什么？ 我投票赞成让它尽可能简单。

就目前而言，我们假设docker-compose.yml中的所有服务都将在docker-compose up 。 我们所有人都在使用自己的自定义引导脚本，makefile，构建工具等，而且幸运的是，一旦厨房水槽“启动”，docker-compose和docker都公开了用于管理单个容器的广泛API。

我唯一需要做的就是使我进入此讨论的核心需求，是指定无论出于何种原因，我定义的那些服务之一都不是我默认要“启动”的服务。

为我们所有人“完成”的最简单的功能是什么？ 这是对docker-compose.yml规范（ @bfirsh最初的想法2）的微小更新，其中服务可以指定autostart: false

我投赞成票：“谢谢，为我们做点事。” 我们投票，现在至少需要一个答案。 4神！

为我们所有人“完成”的最简单的功能是什么？ 这是对docker-compose.yml规范（ @bfirsh最初的想法2）的微小更新，其中服务可以指定自动启动：false

那比任何其他替代方法都好:)

很简单
scale: 0
https://github.com/docker/compose/issues/1661

@drew -r什么？

@ jonathanborges1542这是docker-compose scale servname=2 。 docker-compose.yml文件中没有等效项。

@ drew-r scale: 0当前告诉docker守护进程将SIGTERM / SIGKILL发送到该服务的所有容器。 即使它尚未完成维护工作，这也会杀死它。 那是预期的行为。 更改此状态将是使当前明显的行为超负荷的糟糕情况。

我知道@gittycat ，但是我们在这里想要键入“ docker-compose up”，一切准备就绪。 然后，在那种情况下它将无法工作。

我已经关注这个主题一年多了（大多数帖子都在docker方面）。
我认为，与“服务”，“数量”和“网络”并存的新的顶级“职位”是最佳选择。 那是上面OP列表中的选项4。
这也是Docker存储库中的一项提案。
https://github.com/docker/docker/issues/23880

@briceburg

很难通过文件列表来评估此解决方案的合理性

目的只是为了表明我有许多文件组合，并且使用多个“ -f”选项太容易出错，无法手动完成。

我只建议您使用默认的入口点/命令，该入口点/命令对您不想自动启动的那些服务不起作用。

有时候，我们无法逃脱厄运。 但是我更喜欢我的解决方案：我使用了一个永远不会被“组合”的目录，因此不会有无用的停止容器污染我的环境。 这就是为什么我有一个工作目录，其中的“ .env”链接到父“ .env”。

如果我要提出一个建议，那就是允许通过环境变量（例如DOCKER_COMPOSE_PROFILE =“ tests”）设置撰写配置文件

那将是最好的解决方案。 但是我不认为开发人员倾向于增加复杂性...

我想构建一个基本映像，在同一docker-compose.yml中“扩展”此映像，然后仅启动第二个映像，此操作目前无法在一个步骤中完成。 使用选项2可以，但是更好和更清洁的方法可能是有一个“构建阶段”和“运行阶段”，在该阶段完成基础映像的创建。 目前，我必须运行2条命令，而不仅仅是一条命令。

+1 @ drew-r＃1661

是要在某个时候实施此问题，还是仅仅是撰写者不想做的事情？ 很高兴知道，这样社区可以开始寻找其他解决方案。

顺便说一句，我投票赞成备选案文2。

谢谢

为选项2 +1。
它会尊重显式依赖关系吗... links等？

如果我指定要使用docker-compose up [service]出哪个服务，那么很少会启动除该服务及其依赖项以外的任何服务。

选项2的另一票。甚至还有一个PR（https://github.com/docker/compose/pull/3047）， @ acran足以创建，因此撰写开发人员的工作量应该很小，因为他们只需要检查它（它很短很简单），而无需编写任何代码。

如果撰写开发者不想这样做，那么他们应该一劳永逸地声明它，然后关闭票证并将其锁定以防止发表评论。

@msabramo compose基本上受困扰。

该请求在docker引擎仓库https://github.com/docker/docker/issues/23880上进行了跟踪
那就是决定/工作的来历。

我建议关闭此问题。

@gittycat compose仍然可以选择是否告诉引擎启动服务。 这仍然是一个非常有效的请求。

我在生产中放弃了docker，出现了很多问题。 然后我迁移到无业游民。

再次投票赞成2）

再次投票赞成2和4。

只是指出一个用例，一些服务具有循环依赖关系，需要生成配置文件，运行测试套件等等。 我们可以将其与Docker脱钩，也可以使用其他工具，但是它增加了设置项目的不必要的复杂性。

使用简单的设置和/或测试命令会使事情变得更加整洁。

再次投2票！

我已经阅读了此主题，但是决定创建一个新帖子（https://github.com/docker/compose/issues/4650），该帖子已关闭，在这里已被推荐给我。 我想说明的是，尽管本线程中的大多数讨论都涉及禁用正在运行的容器的标志，但我的用例却处于第三种状态：创建容器。

我不仅要阻止容器运行，而且要永远从不创建容器（在我的用例中，我有一个用户驱动的过程来完成此任务）

@ekkis我很好奇这是怎么回事。 我的用例涉及到引用主容器映像并配置替代“操作”，可以使用bash之类的方法来完成，但使用Docker更有意义。

您是否愿意提供有关您的问题的更多详细信息？

@frnco ，不确定我是否了解您想要了解的更多信息。 在某些情况下，您需要构建映像而无需创建容器。 我的就是这种情况之一。 我想要一个给定的图像以及一堆其他图像，但是这个特定的图像将由我编写的过程使用。 我不想有两个单独的过程来构建和有build-only的标志可以解决这个问题

@ekkis我建议您看一下＃963，似乎与您想要的东西有关。

为选项2 +1

为选项2 +1

为选项2 +1

为选项2 +1

为选项2 +1

为选项2 +1

：+1：对于选项2，是否对此功能有任何疑问？ 最好的解决方法是什么？ 据我所知，需要列出我所有的服务，例如：

docker-compose up service1 service2 service3

...并忽略那些我不想默认启动的

在开源社区中，我们有什么方法可以帮助贡献此功能，而这似乎是人们所迫切需要的？

为选项2 +1。
指定“阶段”的方法会很棒。 说，该服务将仅在生产中运行。

为选项2 +1。

为选项2投票

up命令过滤将是完美的– docker-compose up service1 service3

：+1：用于选项2和4

在这一点上，似乎选项2是用户想要的。 接下来要做什么？

对于选项2，这里为+1遇到了这个问题，希望此功能已经存在。

在选项2上+1

...还有一个+1用于选项2

为选项2 +1

选项2的+1 ：-)

为选项2和4 +1

大家好，
+1选项2

恕我直言，当您具有基于微服务或六边形体系结构的应用程序时，该选项在本地环境中将非常有用； 作为开发人员，我只能为我最近的工作运行必要的元素；

选项2是大多数用户想要的选项。 是否仍要对此做出决定，或者已经开始对此进行开发并在其他地方进行跟踪？

我认为当我在几个月内完成大学学习并有更多时间时，自己实现该功能会更快（尽管我还没有学过Python（我认为是在其中编写的）），但是我看到了大量的投票和请求，在两年内，没有任何进步，而自我实施似乎是未来五年的解决方案（直到该功能正式实施）。

当然，选项2是+1000

+1选项2

如果我投票给选项2，会有所不同吗？ 似乎不太可能。

到目前为止，这里的评论变得尖酸刻薄，并且还没有真正的新反馈浮出水面，这使我考虑锁定此线程。 在此处进行互动时，请保持文明。

这是维护人员小组在此问题上的当前正式职位。 虽然我们是否要添加此功能或类似功能作为便利选项仍在考虑中，但出于突出显示的原因以及存在其他更适合此功能的工具，它并不是优先考虑的事情。

@ shin-在锁定之前，我可以这样吗？因为我们可以弄清社区是否愿意发展，如果核心团队符合团队的标准，核心团队是否可以将其合并？ 在线程中有一个实现，社区成员愿意完成它，他们只是在寻找一些确认，这不会浪费他们的投资。 如果我们能得到一些反馈，我将跟踪这些线程以进行移动，以查看是否可以将其移至闭包。

@jimzucker否-因为这里的问题不是实现； 对于一般的开发人员而言，此操作的基本实施将花费半天的时间。 我们在这里关心的是一个基本的设计问题。

1. 什么是服务？ 通过设计，服务是一个明确定义的，长期运行的过程，可与其他服务交互以形成应用程序。 这是Compose在其下运行的基本假设，它指导了我们实现的大多数（即使不是全部）功能的设计。
2. 根据该定义，“默认情况下未启动的服务”实际上不是服务[1]-它更多是预定义的任务，在容器中运行并作用于应用程序，而不是其中的一部分。
3. 因此，将其称为服务是错误的（从根本上说，是设计使然）。 到那时，我们需要考虑在Compose文件中创建一种新的定义类型（为简便起见，我将其称为“任务”，此处的确切术语无关紧要）。
4. 由于任务本质上是运行时间短的流程，因此与服务相比，它们使用不同的选项集。 例如，我们可以认为任务不需要公开端口[2]。 另一方面，诸如CID文件之类的选项对于服务几乎没有意义，对于任务而言可能确实有用。
5. 现在，在大多数项目中，任务倾向于具有依赖关系链（这就是为什么在传统的非容器世界中，我们具有Makefile）的原因-因此我们至少需要基本的依赖关系实现，并具有并行性，并且能够分辨如果该JAR构建任务始终需要10分钟，那么确实需要再次运行。
6. 然后，某些服务实际上取决于在启动之前已经运行的任务，这给我们计算和处理依赖关系的方式增加了另一层次的复杂性。
7. 有些任务需要一些服务才能运行（例如，数据库迁移）。

在这一点上，这已成为全新的代码，在范围和复杂性方面可能匹配或超过cmake 。 这就是为什么我们长期以来一直拒绝实现此功能的原因-部分是因为这根本不是Compose设计的目的，还因为我们[3]根本没有时间或资源来实现或维护此功能。必须变得对人们真正有用。

希望这可以使事情变得更多。 我知道人们对此线程的响应（或缺乏响应）感到沮丧和失望，我不确定这是否可以以任何方式缓解这种情况，但是确实如此。

[1]有些人确实提到希望拥有“可选服务”，但这不是该线程中提到的最常见的用例。 据我所知，大多数人都想要“任务”功能。
[2]我敢肯定有人会通过一个确实需要暴露端口的任务的例子来与我相矛盾，这只会表明决定每个选项适用于哪些选项的练习并非易事。
[3]在这一点上，我的意思是“我”，因为我是此时唯一致力于docker-compose维护者。

@ shin-我明白了。 我追求的是您脚注中的“可选服务”，而用例而非任务的概念，我们能否以某种方式就如何实现这一点达成共识，因为那是我试图支持的主题的一部分，并且我的票显然在关闭该路线的那条路上。 如果我们可以将其与您明确定义为“任务”的要点分开，我们可以取得一些进展。 人们在我的阅读中对选项2进行+1时，是对可选服务的了解。 很高兴将此离线讨论，然后我们可以返回论坛，我是[email protected]

@ shin-您的观点2错误。 服务是一项服务，无论它是否正在运行。 有数不清的用例，其中依赖项不可用时，依赖服务将修改行为，因此您的应用程序层可能不（也不得）要求所有“服务”始终可用

如果您以最传统的方式来考虑它，则认为Web服务器是一种“服务”，但可以将其关闭或配置为默认不在给定主机上启动，但是除了服务之外，没有人会考虑它

我认为很多要求此功能的人都不想运行任务，而希望运行可选服务。 例如，如果您有一组作为Docker容器运行的微服务，并且将它们全部作为一个整体部署，那么也许有一天您的需求会发生变化，并且您不需要在所有服务器上运行所有容器，因为在这种情况下，您可以不需要非强制性容器中包含的特定功能。

另外，我认为这对于开发环境是一个不错的功能； 如果要修复特定容器中的错误，则无需为此启动所有容器。

确实，使用一个简单的布尔字段，我们可以轻松地从.env文件中启用/禁用服务，并避免编辑yaml文件。

@ekkis我认为您在某种程度上混淆了容错性和可分配性。 另外，请参见我关于该主题的脚注，我承认确实存在一些用例。

所有人：请记住，如果某些服务对于您的应用程序是可选的，则已经可以使用当前功能来处理。 推荐的方法是使用-f标志包含一个单独的Compose文件，该文件可以包含或排除。 对于添加此选项，它们并不是一个非常有说服力的参数。

@ shin-感谢您抽出宝贵时间与我们进行对话。 我同意有几种方法可以执行此操作，因为您建议使用多个yml文件，也可以传递服务列表，但是这些服务不方便，并且会导致用户错误，从而造成操作风险。 尤其是在商业产品的情况下，我们希望分发一个撰写文件，并且默认情况下会获得所需的常见行为并给出高级选项的说明，一个文件使开发，CI / CD和分发都变得更加整洁。 ENV变量的默认设置增加了对我们的帮助，并且消除了拥有许多yml文件的需要，这将是管理描述部署的单个文件的又一步。

核心团队是否愿意以任何形式接受对此LMK的贡献。

@shin ，我没有提及容错或可分配性。 我只是对“服务”的定义提出了意见，即该服务是否运行不是该定义的固有内容。

@ shin-我非常同意@ekkis ：默认情况下未启动_默认情况下_不违反成为服务的定义，因此，您的观点2是_necessarily_ true的假设，连续的观点也并非如此，因为它们基于假设2。

例如：当我使用mysql DB开发应用程序时，通常会定义一个额外的_service_ phpmyadmin 。 这是一项真正的服务：长期运行的公开端口，取决于其他服务。
但是我不想默认启动该服务，而仅在开发中按需启动。
目前，我通过将此服务放入一个额外的docker-compose.yml并通过将两个文件都提供给docker-compose来启动它，正如您在上面所建议的那样。

因此，是的，已经有可能的方法来实现这一目标。 通过将服务拆分为多个文件，或者只是使用docker-compose以外的工具即可。 但是正如我在上面已经写的：这个问题不是关于全新的功能/功能或新概念（即_tasks_），而是关于便利性，尤其是在开发环境中。
必须输入docker-compose -f docker-compose.yml -f docker-compose-tools.yml up并不是很方便，因此docker-compose不能实现自己的承诺：

这些功能共同为开发人员提供了一种方便的方式来开始项目。 Compose可以将多页的“开发人员入门指南”简化为单个机器可读的Compose文件和一些命令。

通常在_multi-page“开发人员入门指南”中找到要启动哪些服务或在哪种环境中使用哪个yml文件-如果完全可以找到...

因此，以我的观点，正如@jimzucker所写，此处大多数+1确实是为“可选服务”提供的，而不是一种新的任务概念。 至少使用简单的布尔值来标记_service_是否默认启动，至少它们都是更好的选择。

正如我的PoC显示的那样，对于“可选服务”而言，所需的代码更改非常易于管理，并且为大多数人提供了极大的便利性。 选项2-读作“将服务标记为可选的_可能性”是解决此问题的合理折衷方案。

@ shin-您是否会同意让用户可以将服务标记为可选服务-但它们仍然是服务-会对他们有很大帮助？
当减少为“将_services_标记为可选/默认未启动”时，是否会接受并合并对此问题的拉取请求？

@shin ，除了上述docker -compose只构建某些服务，因为这些服务将由使用name的其他服务运行。 考虑一下，每次“启动”时，我都会得到一堆名为project_app_1 ， project_otherapp_1等的“服务”，这些没有意义，因为它们需要使用数据库中的信息来运行（我有一个启动它们的主服务） 。 所以我总是要杀了他们所以对我来说，NO_RUN或BUILD_ONLY标志是完全有意义的。 这样方便

@acran

您是否同意让用户有可能将服务标记为可选服务-但它们仍然是服务-会极大地帮助他们吗？

我对此有多大意见不一-我认为“大大”夸大了。 在您的示例中，仅具有一个docker-compose.phpmyadmin.yml可以选择包括在内，这比在主文件中设置环境变量/修改服务定义没有更多的负担或复杂（根据说明“开发人员指南”）。
我也正在考虑在并非绝对必要的时候给开发人员“步枪”的权衡。

当减少为“将服务标记为可选服务/默认情况下未启动”时，此问题/对此的拉取请求会被接受并合并吗？

见上文–该功能可用后，人们将开始将其用于除其预期用途以外的其他用途，并期望我们实施新的功能集以支持它。 也是cc @jimzucker ; 我目前无法想到可以阻止这种情况发生的实现。 如果可以的话，这个问题早就可以解决了。

@ekkis如果您永远不想自己启动这些服务，为什么将它们隔离在单独的文件中到底是个问题？ 我真的很困惑为什么这是挂断电话。

@shin如果可以使用docker-compose.yml来构建服务，则它是集中化我的构建过程的最有用的工具。 实际上，从某种意义上来说，我可能想（有条件地）在运行服务之前先构建服务，我为此功能表示赞赏

所以docker-compose文件也是我的makefile 。 但是仅仅因为我建造了东西并不意味着我要运行它。 对于docker-compose来说，假设我要运行服务，为其创建一个名称并在没有适当参数/环境变量/等的情况下运行它是没有意义的。

坦白说，我不确定我对这个简单补丁有什么异议。 这将是对我很大的有用

我在较早的帖子中明确指出了为什么团队的正式职位是您不应该将Compose文件用作Makefile。 如果您认为我们在此问题上错了并且仍然想要这样做，那是您的特权，但是坚持要求我们添加功能来支持它有点荒谬。

@胫-

在您的示例中，仅包含一个docker-compose.phpmyadmin.yml（可以选择包括在内），就比在主文件中设置环境变量/修改服务定义那样繁重或复杂（根据“开发人员指南”的说明）。

实际上，我现在还没有考虑过涉及环境变量。 我期望的工作流“可选服务”最终将如下所示：

• 我复制/克隆一个新项目
• 我看到其中有一个（单个） docker-compose.yml文件，因此我知道，我所要做的就是运行docker-compose up然后构建并运行该应用程序
• 现在，我想为开发目的启动可选服务之一（例如，其他调试，phpMyAdmin）。 我所要做的就是docker-compose up phpmyadmin 。

对我来说，这比使用多个docker-compose.yml文件更方便，而且据我了解，这里的大多数其他人也很方便。 在这里拥有“可选服务”的好处是

• 对于开发人员来说，不必在多个文件之间重复任何内容，也不必仔细考虑要在哪个文件中放置哪个定义，而只需要在服务上设置一个布尔标志（ auto_up: false ）
• 对于无需知道/记住哪些文件要包含哪些服务的用户：我是否需要运行
  
  
  
  • docker-compose -f docker-compose.phpmyadmin.yml up
  
  
  • docker-compose -f docker-compose.yml -f docker-compose.phpmyadmin.yml up甚至
  
  
  • docker-compose -f docker-compose.phpmyadmin.yml -f docker-compose.yml up ？
  
  
• 相反，用户唯一需要知道的就是有一个名为phpmyadmin ，并且用户立即知道如何启动它。

参见上文–该功能可用后，人们将开始将其用于除其预期用途以外的其他用途，并期望我们实施新的功能集以支持该功能

不要误会我的意思，我不仅在这里理解您的担忧，也同意我的看法：总会有一些用户弯腰此功能或任何其他（！）功能以适合其所需的工作流程，即使这些功能从不意味着这样使用。
但是，对于“可选服务”的任何请求，如果缺少“任务”的功能，您都可以轻松地辩称服务不是任务，并且需要首先将任务作为新概念引入，因此尚不支持（尚未）。 也就是说，除了将服务标记为可选服务以外，还可以朝着任务概念迈进（例如，选项4），并且两者之间有明确的界限。

通过将_service_标记为可选功能，我们仍然位于该剪切的右侧。 “该功能本身实施起来并不太复杂，但是可能会诱使用户错误地使用它”，目前，唯一反对该功能的真实（尽管有效！）论点不能令人满意，这是不实施该功能的原因-至少对于使用正确的方式™可以从中获得很多便利的用户。

我有责任将我的请求＃3047移交给当前的管理员，并进行任何必要的抛光以使其被接受，请让我知道;）

我的用例是，我们不会将所有映像都推送到docker hub或码头，也不会拥有自己的注册表，并且能够将服务标记为默认情况下不会运行在docker-compose.yml中定义了一个无法启动的基本映像，然后其他容器使用该映像或在其上进行构建。

我倾向于使用仅用于此单一功能的docker-compose叉子来实现此功能。

@ shin-尽管我认为我们都理解您的观点并表示同情，但我认为“它可能会被滥用”对于存在-显然-许多可行用例的事物不是一个很好的论据。 当然会被滥用。 这正是软件和新思想的发展方式。 完全不应该使用技术。 如果在过去的25年中我们没有滥用所有提供的技术，那么今天的网络将不是今天。

无论如何。
根据您的观点-简化-服务和任务之间的区别是生命周期。 很有道理，我理解您将它们视为两个不同的概念，并认为这是蠕虫的潜在可能。 但是，此区别在文档中没有任何地方阐明或阐述。 也没有任何地方指出docker并非旨在用于扩展临时进程。
我的意思是，如果码头工人团队对此持坚定立场，则应从一开始就明确指出。
也。 任务或服务，显然存在重叠。 将服务标记为可选服务绝对不是任务端唯一的东西。
从实际的角度来看，我绝对同意@acran-与拥有相比，拥有一个

呵呵，我记得我们在游说允许“浏览器”显示图像时进行了激烈的讨论，反对者的主要论点是它被称为超文本传输协议。
很抱歉旧时回味旧屁。

@ shin-如果不应将docker-compose用作makefile，则它不应提供makefile功能。 如果它允许我构建项目（好极了！），那么就认为它不是makefile是可笑的

@看起来，你们不必实施任何您不想使用的功能，无论您的理由多么不合理，或该功能多么有用。 只是它使该工具对使用它的我们这些人有用。 我们是用户，我们知道用例-工具只有在满足用例时才有用，有价值

对我来说，这只是一个小小的刺激，我必须手动杀死一堆没有充分理由而产生的东西-每次我使用服务时-。 对其他人来说这可能是一个障碍，刺激的严重程度会有所不同

我知道官方立场是我们应该使用dobi，即使它对于我们所需的功能而言过于严格。 但是该官方职位并未说明您不愿接受有用的PR的依据。 当对docker-compose的需求太大或重叠部分足以迁移时，我们仍然可以使用dobi，但这是一个很小的更改，它将使我们的生活变得更好

顺便说一句，我并不是在“刻板”，而是锁定线程以防止进一步的讨论将是不民主和专制的。 开源是建立在开放的原则，我会用审查制度和独裁的战术管理的也很不愿意看到这个项目

@rysiekpl这是我们正在https://github.com/docker/cli/pull/452 （一旦语法经过深思熟虑，它将进入Compose和v2中，好）

@creynders我认为这是一个错误的特征-没有人说不应该存在可选服务（事实上，正如我所指出的，有一些方法可以通过使用单独的文件来声明它们）。 这类似于辩论是否明确关闭<img>标签是否有效以及我们的特定浏览器是否应支持它。

另外，请注意：

但是，此区别在文档中没有任何地方阐明或阐述。 也没有任何地方指出docker并非旨在用于扩展临时进程。

这实际上是https://docs.docker.com/compose/overview/页面（重点是我的页面）的第一段：

Compose是用于定义和运行多容器Docker应用程序的工具。 通过Compose，您可以使用Compose文件配置应用程序的服务。 然后，使用单个命令，从您的配置中创建并启动所有服务。

@ekkis我真的很高兴Compose实际上对您的项目有所帮助！ 我希望我不会在所有这些事情中都表现得很真诚，如果那是您想要使用该软件的方式，那绝对可以。 但是，我要说的是，从长远来看，朝着这个方向进一步发展可能会使其恶化。 我们都知道尝试执行过多操作的应用程序会发生什么（尽管我想Emacs会将它撤出了：stuck_out_tongue：）

我不认为自己是“独裁者”，但也许我没有正确表达自己的意思。 我的目的是鼓励人们在交流中保持文明和积极。 该线程仍处于解锁状态，只要人们避免变得卑鄙或无礼，该线程将继续存在。

您可以从配置中创建并启动所有服务。

我想我们的争论是应该读“创建和/或开始”，尽管为了对这种语言公平起见，人们不必指出“或”，因为它隐含在“与”中。 换句话说，您确实可以创建和启动服务，但这并不意味着它必须同时执行

我们都知道尝试做太多事情的应用程序会发生什么

是的，我很感激您正在管理域的边界

我不认为我是“专制主义者”

我喜欢开源运动。 我们可以有分歧，但我们仍然在一起。 比特币社区内的战争令人震惊，我想我仍然对此感到困惑，所以感谢您站在文明的一边

作为分手的想法，我想请您重新审查https://github.com/docker/compose/issues/4650 ，它与对此线程的请求不同（如您在关闭时所指出的），但可以适应我的使用情况，即此处讨论的标志不是二进制而是三进制

我真的很喜欢定义多个文件的想法。 但是，包括所有包含多个-f包括原始文件）似乎是完全过头了。

实际上，有一种更实用的方法对我有用（请参见下面的PS）：将您不想运行的所有服务放在docker-compose.override.yml 。 并使用docker compose -f docker-compose.yml up进行正常启动（请注意，这是一个一次性命令）。 在所有连续的呼叫中，将覆盖优先级...

总体而言，这都是非常不直观的，并且有些不令人满意。 添加其他：

• 禁用服务的选项很有意义，特别是对于更复杂的覆盖

• -f选项很小，但不是很直观，仅添加附加替代的-F <name>选项非常受欢迎（即docker-compose。.yml。 一种替代方法是使用作为所有.yml文件来源的目录：连同符号链接，其功能与/etc/apache/sites.available -> /etc/apache/sites.enabled类似

另一方面：任何人都可以为其外壳提供一个simpe包装器脚本（函数）以模拟此行为...

PS：我的用例是将调试器定义为服务。 显然，并非始终需要此服务，而是需要链接（出于安全原因）才能正常工作。

选项2很好的另一个用例：

假设您有一个团队从事同一项目。 其中一些可以访问AWS托管服务，但是其中一些需要将相应资源作为本地容器​​运行。 因此，根据我的工作流程，我将始终在合成星座中使用_always_或_never_来使用Redis和MySQL容器。

我要断然地说，在这种情况下，管理多个撰写文件是愚蠢的。 重叠的数量是可笑的。 维护多个文件是一个步枪-它们_将_失去同步并引起混乱。 坦率地说，对于任何人都认真对待该选项，我感到有些震惊。

能够快速启用和禁用服务而无需注释大的配置块（在YAML中很尴尬，如果不慎犯则非常混乱）本身就是很棒的。 但是，如果有一天compose能够将变量插值到配置中，则此功能将自动变得指数级更强大。 在那之前，它只是有用的。

完全同意@campadrenalin。

就我所知，整个讨论基本上是由很多人提供实施选项2的很多很好的理由，而开发人员拒绝了，因为假设某些人可能会误解此功能的存在并要求其他不相关的功能。

OT：

但是，如果有一天compose能够将变量插值到配置中，则此功能将自动变得指数级更强大。

此功能长期没有可用吗？ 请参阅https://docs.docker.com/compose/compose-file/#variable -substitution。 我使用它来允许通过使用.env文件（例如，源代码位置，端口映射等）来自定义我们的Compose开发环境。自从撰写2.1版本的文件以来，甚至shell样式变量default（ ${VARIABLE:-default} / ${VARIABLE-default ）。

就我所知，整个讨论基本上是由很多人提供实施选项2的很多很好的理由，而开发人员拒绝了，因为假设某些人可能会误解此功能的存在并要求其他不相关的功能。

我觉得这可能是-语气有些刺耳，但本质上是有效的-@rysiekpl的非常好的总结。
那么，@ shin-，我们是否就此问题做出了更接近的决定？ 是否只是将其关闭或实施/接受选项2的PR？

我完全理解并理解了您的担忧，但同时看到的好处远胜于可能滥用此功能的人的风险，因为这是一个很小的变化，但为很多人提供了更多便捷工作流的更多可能性。

无论如何，从长期来看，docker-compose似乎都已被废弃，转而支持docker堆栈，我建议大家尽快使用新的v3格式和docker stack工具。

使用群集上的堆栈（甚至在1个节点上），可以指定以下内容：

        deploy:
            mode: replicated
            replicas: 0

拥有零个副本实际上会禁用该服务。

如果要应用环境变量替换，只需使用其他工具来生成yml，例如envsubst。

然后，您可以在yml中使用占位符：

        deploy:
            mode: replicated
            replicas: ${R}

并以这种方式处理：

export R=0
docker stack deploy stack1 --compose-file=<(envsubst <docker-compose.yml) 

因此，如果从长远来看，将不建议使用docker-compose ，那么合并已经存在的docker-compose像渡渡鸟一样前进，“有人会请求奇怪的功能”是一个真正的问题吗？

由于docker-compose似乎长期被丢弃而有利于docker stack

因此，从长远来看，如果不建议使用docker-compose

等一下，w？ docker-compose对于很多人来说是至关重要的，因为他们的开发工作流程几乎不需要团队管理器。 您能否指出Docker在这方面的一些官方声明？

我可能读错了，但这听起来像docker swarm和docker stack与docker cloud services紧密相连。 这些东西是否可以在独立的脱机系统上配置？

这些东西是否可以在独立的脱机系统上配置

是的，您可以离线使用它们。

在我看来，docker-swarm上的堆栈最终将成为docker-compose功能的超集。 我认为描述符文件已经非常相似。 希望这种过渡不会太困难。 我可以看到的最大烦恼是与堆栈分开管理群集。 对我来说，更多的开销工作是因为我对跨多个节点运行组合应用程序没有兴趣。

还是我误会了一切...？

在选项2上+1！
而且我认为docker compose的减少将有利于群体堆栈，这将是社区的一大弊端。 Docker compose非常简单易用！

@tberne我同意这一点。 docker-compose很简单，简单是一件好事。 我们应该投票保留它

嘿，这是一个广泛的讨论！ 不要太在意这个评论，只有我的两分钱。

起初，我同意大多数人的意见，只是添加了一种enabled标志。
然后，我看到了按组划分分支的命题，并认为这是一个好主意。
然后我阅读了有关Dobi的文章，尝试了一下，确保它现在不能在我的项目中使用，然后继续阅读。
然后我阅读了@ shin-的论点，并认为它们足够好，尽管我也同意一些反对意见。

我当前的解决方案是创建一些docker-compose yamls并编写一些bash包装脚本以不手动运行docker-compose。

例如，这就是我运行运行网站的容器的方式（ ./docker/scripts/up脚本）：

#!/usr/bin/env bash

def_opts="-d"

cd "$(dirname "$0")"/../

# A separate bash file with functions like: get_args, add_hosts...
. ./functions.sh

docker-compose -p ${PROJECT} up ${def_opts} $(get_args "options services" "$@") && \

# Adding host to /etc/hosts
add_hosts "$HOSTS" web && \
add_hosts "$HOSTS_MAIL" mail

大+1表示选项2或3。

为选项2或3 +1。

提出的“组”概念听起来也很有趣！

为选项2 +1

_有太多+1 on option x ，我什至找不到原始语句。 请改用帖子下方的反应按钮。_

要添加新想法：

我们不能仅将默认比例设置为0吗？

web:
  image: busybox:latest
  command: echo 'scaled'
  scale: 0

您应该只执行选项2（但也许不使用nostart或其他方法），因为人们已经等待了多年，然后由于工具太有限而将docker-compose包装到他们自己的配置管理器中，这在执行docker compose应该做的事情时没有用在做。 再过两年，也可以创建自己的更强大的docker-compose。 这个问题已经解决了很多时间。

从长远来看，应该对真实选项分组进行一些考虑。 有些仅与构建相关，有些仅与运行相关，而有些则是相互的（您确实希望至少嵌套一层用于运行，或者只是将其分离出来，并有一个生成部分，问题已解决）。 目前，尽管很多事情在配置中有问题，但我只想在版本5中重新制作，但要在那个时候弄清楚（主要是通过在技术级别的域中表示真实内容，而不是尝试使其映射使用）或过于简单的域，而是在正确的目标之上为这些目标创建一个配置层，您不能反向进行。） 我认为由于这种情况，快速解决是有道理的。

为选项2或4 +1

如果目前没有任何计划添加此功能，我想在docker-compose的文档中编写在组合中运行此类服务（或任务）的方式。

这是一个旧线程，我同意docker-compose不会关心不会从start_运行的_services。

但是我通常也会添加test服务，所以这是我做的：

1. 覆盖服务的entrypoint 。

2. 在新的entrypoint ，检查是否有tty （默认情况下docker-compose run使用--tty ，而up不使用）。

   # Check if there is a tty
   if [ ! -t 1 ] ; then
     echo "No tty available."
     exit 0
   fi
   

   当不使用tty （例如，使用docker-compose up ）运行时，而仍然使用docker-compose run运行时，这将始终使服务退出

@paulodiovani看起来更像是hack，而不是解决方案。

为功能请求+1。
黑客喜欢拥有什么都不做的命令，即使该容器没有运行，也必须对其进行构建，初始化等。

我在项目中通过提供一个简单的bash脚本解决了此问题，该脚本根据提供的参数调用适当的docker-compose命令。

现在，如果我做./docker-compose.sh -e testing up ，结果是一样的，如果我做了docker-compose -f docker-compose.yml -f docker-compose.testing.yml up 。
如果我只是做./docker-compose.sh up ，我就会如您所愿得到常规的docker-compose up 。

因此，我的-e ${environment}选项（ --env的缩写）基本上是-f docker-compose.yml -f docker.compose.${environment}.yml的别名。 这导致docker-compose.yml是基本/默认撰写文件，而像docker-compose.testing.yml是其扩展名。

这通过强制执行默认值，在某种程度上解决了@acran的问题，即用户不知道要将docker-compose命令包括（以及按什么顺序）包括哪些文件。 这不是一个非常可靠的解决方案，因为有些人可能会使用更复杂的撰写文件组合，但是我认为docker-compose应该能够执行类似的操作。 大多数docker-compose文件很可能以docker-compose.开头并以.yml结尾，所以为什么我总是必须键入这么长的命令（ docker-compose -f docker-compose.yml -f docker-compose.testing.yml up ）是否只需要为我的测试环境提供一项附加服务？

不需要envsubst，docker-compose config会执行环境变量，然后docker stack从stdin中获取它：

docker-compose config | docker stack deploy --prune --compose-file -

让我们也使用docker-compose .env替换。

@kogli我认为这里的问题是选择一个选项。 都有优点和缺点。 正如我之前所说：

对于某些用例，每种解决方案都将更好，而对于其他用例，则将变得更糟（甚至无用）。 如果实施了某些措施，那么管理人员将永远这样做，因此我相信他们花一些时间来这是明智的。

@ shin-我想你是一个要问的问题：考虑这一点是否有意义？ 考虑到团队的当前位置，设计团队的难度以及那里的众多工具，简单地告诉人们这不会发生会更容易吗？ 大多数人（如果不是每个在这里发表评论的人）都找到了一种解决方法。

解决这个问题似乎很不错，而且您可以专注于重要的事情，没有人想知道他们是否应该提出请求请求以及如何同时满足所有这些需求。 他们可以去构建其他东西，甚至可以发布它来帮助他人。

仅作记录：我的解决方案并不完美，但是比我花了2天的时间来安装依赖项并修复大量的东西并使项目运行（它已经使用Docker）要好得多。 仅3个命令，其中Docker和Docker Compose是唯一的依赖项。 是的，有比我想要的更多的代码。 是的，运行命令很糟糕。 是的，还有一点需要牢记。 Wiki页面涵盖了这些内容。 很好，如果我自己这么说，这意味着Docker Compose做到了，我还需要其他东西。

重点是：如果超出范围，那就是浪费时间继续讨论它。 许多人只是在这里停下来询问此事并发表意见，然后才试图决定要做什么。 如果关闭，他们仍然会发现或构建其他东西，只是速度更快。 这样您就可以减少保姆的工作量。

编辑：只是想出一种好的方法：如果没有明确的标准接受PR，并且核心团队中没有人参与或计划在可预见的将来对其进行研究，那么这不是“问题”，只是一个想法。

我认为没有理由将问题列表弄得一团糟，我相信这里的许多想法都是好的，但我认为它们或多或少都属于其他地方。 将近3年，而且情况有一天会发生变化，您随时可以重新打开它，或打开有关它的新期刊。

由于此功能非常简单，因此只需一天的时间即可实现。 但是，经过2年的讨论，仍然一无所获。 伤心。

@rubycut是的，这就是所谓的“更高原则”接管可用性和用户友好性时发生的情况。 我完全理解开发人员不想用不合逻辑的功能阻塞产品。 但是，这个特别需要的功能实际上似乎很有意义。 当开发人员认为他们比用户更了解时，这很可悲。 （再次，他们通常这样做。但并非总是如此。这次不是。）

@rubycut Talk很便宜，请告诉我代码。 如果可以，发送PR，如果不能，则报告并等待。

@wangwenpei你在跟我开玩笑吗？ 首先，您不是该项目的维护者。 如果维护人员接受此想法，并放置“ help wanted”标签，我相信有人可以提供拉取请求。 但是他们说他们不感兴趣。 因此，如果不接受请求，为什么还要麻烦将其拉出。

仅供参考，“代码”已经存在：＃3047

@wangwenpei好吧，＃3047，有拉取请求...
等待至少两年的反馈。 最近关门了

由于https://github.com/docker/compose/issues/1896#issuecomment -322285976中突出显示的原因

说实话，这很激怒我，因为https://github.com/docker/compose/issues/1896#issuecomment -322285976中给出的参数与拉取请求没有任何关系：

1. 什么是服务？ 通过设计，服务是一个明确定义的，长期运行的过程，可与其他服务交互以形成应用程序。 这是Compose在其下运行的基本假设，它指导了我们实现的大多数（即使不是全部）功能的设计。
2. 根据该定义，“默认情况下未启动的服务”实际上不是服务[1]-它更多是预定义的任务，在容器中运行并作用于应用程序，而不是其中的一部分。

我认为断言By that definition, a "service that is not started by default" is not really a service是不正确的。 默认情况下未启动的服务只是默认情况下未启动的服务，仅此而已。 无论是否默认启动，都不会说该服务是否长时间运行，是否成为应用程序的一部分，只是说默认情况下不会启动。

这也正是pull请求中所做的更改：添加将服务标记为默认启动或不启动的功能。
无需引入新的概念，例如执行此任务的任务。 实际上， https: //github.com/docker/compose/issues/1896#issuecomment -322285976中的所有其他参数都源自错误的前提2，因此不适用于不尝试执行任何操作的请求请求其他。

仅出于完整性考虑：

[1]有些人确实提到希望拥有“可选服务”，但这不是该线程中提到的最常见的用例。 据我所知，大多数人都想要“任务”功能。

是的，有一些一次性任务的示例，但也有根据您的定义的_real_服务的示例，即此功能的合法用例。
能够使用它也可以一次执行一次任务，我不能真正接受它作为对此的有效论据。 在完全有效的docker-compose.yml已经可以定义一个_service_，它不会长时间运行，不暴露任何端口并且不是应用程序的必要组成部分。

实际上，这也是建议的解决方法之一！ 只需将_tasks_拆分为单独的docker-compose.yml 。
提到的其他解决方法是使用您自己的（依赖于平台的）自制脚本，这与docker-compose的自我陈述目的完全矛盾，请参阅上面的评论，或仅切换至其他工具，即完美地丢弃您运行良好的工具链只是为了方便地获得这一小功能，可以在您当前的工具链中轻松实现（docker-compose）。

唯一的真实参数与选项2的最基本实现背道而驰-即具有_some way_告诉docker-compose默认情况下不启动特定服务，仅此而已，没有新概念或任何东西-是，这可能be_somehow_被_some_用户滥用。
但是，与对它的需求以及此处提出的合法用例相比，该论点还很弱。

@胫-

也是因为我们[3]根本没有时间或资源来实现或维护此功能才能真正对人们有用。
[3]在这一点上，我的意思是“我”，因为我是此时唯一积极从事docker-compose工作的维护者。

一方面强调只有一个活跃的维护者，另一方面却忽略了请求请求，因此浪费任何机会让其他开发人员参与该项目并不是我所能理解的。
＃3047中提供的代码更改已经实现了对[许多]人员确实有用的功能-也许不是所有用例的人，但这里的大多数人。

所有其他要求-必须引入全新的概念，新的依赖项管理，以及高达cmake类的复杂性-只是在错误的前提下进行！

几天前，我遇到了这个问题，因为我正在寻找这样的功能。

由于不幸的是没有实现，并且据我所知，官方支持的替代方法是使用多个yaml文件。

好吧，我发现对多个默认不运行的服务使用yaml文件的想法，与对一个默认不运行的服务包含一个附加设置的所有服务使用一个yaml文件的想法相比，是一个糟糕的选择。

因此，这是我的+1。