compose 🚀 - 建议：使项目名称持久化。

项目名称并不重要。我喜欢一个随机项目名称的想法。更好的是–我们可以生成fig.yml路径的哈希并使用它吗？

bfirsh 于 2014-12-22

👎152 😕17 👀1

我实际上认为项目名称非常重要。如果您希望对CI管道中的图像执行任何操作，则需要知道项目名称才能将其重新标记为其他名称。

能够从环境变量中覆盖项目名称，使保持这些变量的唯一性和可预测性变得容易。我认为无论发生什么情况，我们都需要支持环境变量的覆盖。

我很喜欢从文件中配置项目名称的想法。我认为类似的讨论发生在（＃45）中。在.fig/project-name使用项目名称似乎会导致产生很多非常小的文件。我认为将其放入fig.yml本身会更容易（就像在＃45中建议的那样，而docker组成建议之一）。

将其放在单独的目录和文件中有什么好处？

dnephin 于 2014-12-22

👍67 👎1

将其放在单独文件中的原因有很多，我将尽力解释我的想法。

保留用于启动项目的名称（即--project-name=foobar ），该名称可以与自动项目名称不同。
在同一个服务器上运行一个项目的多个实例或_versions_，而又彼此不冲突
或者，简而言之， .fig/project-name拥有项目的那个实例的名称。

也许该文件应称为instance-name或类似名称。

我很喜欢从文件中配置项目名称的想法

尽管_possible_为此提案（通过手动创建project-name文件）来做到这一点，但我的主要用例是_fig_创建文件以保存使用的名称。

会导致很多非常小的文件。

的确，替代方法是跳过.fig目录，但是，如果将来需要其他操作，则可以添加额外的文件，而不会弄乱项目的根目录。 Git的做法与此类似，我认为这是一种干净的方法。

我认为将它放到fig.yml中会更容易

我认为这两种选择可以互补。如果名称未被标志或env变量覆盖，则使用fig.yml中的名称作为默认名称。将实际用于启动项目的名称放在.fig/project-name

能够从环境变量中覆盖项目名称，使保持这些变量的唯一性和可预测性变得容易。我认为无论发生什么情况，我们都需要支持环境变量的覆盖。

好奇; 您如何处理多个项目的管理？即cd project-a && fig ps然后cd project-b fig <something> ？

感谢您的反馈意见！

thaJeztah 于 2014-12-22

好奇; 您如何处理多个项目的管理？

我通常从python-tox运行fig ，这使我可以设置环境，所以我从来没有真正在shell中设置它。我也倾向于使用tmux，因此每个项目都有不同的shell。

我认为这两种选择可以互补

太酷了，我同意。

我不知道我是否以.fig/instance-name出售，而不是说.fig-instance.yml可以包含任何实例特定的替代，但是我认为这只是次要的一点。

dnephin 于 2014-12-22

考虑项目名称；如果我正确理解了您的情况，那么能够控制正在生成的_images_至关重要，例如myapp:build12345或_containers_的名称？只是为了获得“感觉”适合您的情况。

我对“随机”项目名称的想法是，只要Fig能够找到一个项目的容器，漂亮的名称就不重要了。如果我作为用户可以通过服务的服务名称（例如fig stop web ）访问服务的容器，则实际容器的名称无关紧要。

甚至一直在想，fig可以按ID跟踪.fig目录中本地存储中的容器（这在运行大量容器的机器上可能会提高性能）。但这确实是另外一个问题。

关于“隐式”创建“项目名称”文件或通过fig init “显式”创建文件的任何想法？也许，如果我在即将到来的假期中有时间，我可以做一些实验（不要用Python编写任何代码，因此将是_really_experimental :)）

thaJeztah 于 2014-12-23

重要的是要能够控制所生成的图像，例如myapp：build12345或容器的名称？

我想映像是非常重要的一个，但是能够确保容器名称不冲突在共享主机上也非常重要。我认为这项提议实际上也旨在解决该问题。

但是我确实认为容器的可预测名称仍然很重要。我可以想到几个任务，对于外部系统（不仅仅是图），能够通过名称识别容器很重要：

清理脚本以删除旧容器，从而能够识别哪个项目创建了容器
调试/检查容器

这两个现在都非常容易，因为我已经知道容器的名称了。如果我必须查找一个名称，则涉及更多。

甚至一直在想，fig可以通过.fig目录内本地存储中的ID跟踪容器

的确可以提高性能，但是我担心这是错误的方法。向无花果添加任何持久状态会引入许多错误（状态附带）的可能性。我更希望看到这是由dockerd中的标签系统处理的。如果fig能够仅标记容器，然后使用该标签查询所有容器，它将所有状态保持在一个地方（dockerd）。我知道有人在谈论这一点，我不确定它是否在路线图上。

关于“隐式”创建“项目名称”文件或通过fig init“显式”创建任何想法？

我想暗含的将更加向后兼容。除非绝对必要，否则我想避免使用fig init 。我可以看到它隐式创建了项目名称<basename>-<4 digit random id> ，而不是使用basedir

dnephin 于 2014-12-23

我只能说，如果无花果现在开始生成随机名称，我将不再使用它，因为我在单个主机上运行了1000多个容器，当我再也无法通过名称识别它们时，对我来说什么都不是。

frank-dspeed 于 2015-01-10

@ frank-dspeed感谢您添加用例。如果我理解正确，您可以使用fig来启动您的容器，但是之后直接通过Docker来“管理”它们，并使用Fig所使用的命名约定？

也许您也对此感兴趣： https :

thaJeztah 于 2015-01-10

嗯，是的，我做了很多这样的提议，例如，简单地添加新的filds，但是在这种情况下，我只添加了ENV就结束了，然后我得到了costum fild，我可以解析它：dart：

frank-dspeed 于 2015-01-10

我认为管理项目名称的明确性不应该是无花果的责任。

当我正确理解您的建议时，生成一个随机名称将使FIG_PROJECT_VARIABLE和--project-name -option无效。这对于“模板化”服务非常方便。

funkyfuture 于 2015-01-17

我认为管理项目名称的明确性不应该是无花果的责任。

我不确定; 图“无声地”覆盖了另一个项目的容器，因为如果碰巧位于同名目录中，有时会很麻烦。

当我正确理解您的建议时，随机名称的生成将使FIG_PROJECT_VARIABLE和--project-name-option无效。这对于“模板化”服务非常方便。

经过以上讨论，我认为类似的方法会起作用

如果提供了--project-name ，请使用它（并写入/更新.project-name吗？不确定）
没有提供--project-name ，但是提供了FIG_PROJECT_NAME ，请使用FIG_PROJECT_NAME （并写入/更新为.project-name吗？）
以上皆非，但已设定.project-name ，请使用.project-name
以上都不是; 创建一个_random_名称并将其写入.project-name

thaJeztah 于 2015-01-17

👍1

从某人的角度来看，谁在脚本中使用无花果处理名称，然后将其传递给无花果，将名称存储在项目中（在我的情况下是模板）就没有意义。

而且，当我刚运行fig up时，我感觉非常直观，即在生成的容器的名称中使用了目录名称。
并说，您看看docker ps -a ，如果它充满了随机名称，将不会有很大帮助。

选项--random-name对您的情况有帮助吗？
除此之外，我认为能够在一些[a-zA-Z0-9_].*前面添加一些名称空间以反映更广泛的部署将很有用。

funkyfuture 于 2015-01-17

👍1

使用fig.yml存储此类信息怎么办？

schema-version: 1.1
project_name: foo
containers:
  web:
    build: .
   command: python app.py
    links:
     - db
    ports:
     - "8000:8000"
  db:
    image: postgres

并保持BC，在compose / project.py :: from_config中

<strong i="9">@classmethod</strong>
    def from_config(cls, name, config, client):
        if 'schema-version' not in config:
            config = {
                'schema-version': '1.0',
                'containers': config
            }
        dicts = []
        for service_name, service in list(config.containers.items()):
            if not isinstance(service, dict):
                raise ConfigurationError('Service "%s" doesn\'t have any configuration options. All top level keys in your docker-compose.yml must map to a dictionary of configuration options.' % service_name)
            service['name'] = service_name
            dicts.append(service)
        return cls.from_dicts(name, dicts, client)

jderusse 于 2015-02-12

👍19

@jderusse我非常喜欢您建议的东西。也许您想将提案添加到＃45，因为这可能是讨论该提案的更好地方？

mikehaertl 于 2015-03-31

无论如何要解决这张票？看起来，建议的＃1233通过让用户确定要采取的预期操作而又不破坏任何向后兼容性，为您提供了两全其美的选择。

michaeljs1990 于 2015-09-23

最初，我希望在docker-compose.yml中使用该名称，但经过更多考虑之后，我真的很喜欢单独文件的想法。

如果需要，可以使用一个单独的文件将其保留在版本控制之外（如果您希望每个用户都可以使用不同的项目名称）。

借助新的网络支持，功能请求也能够配置网络名称（默认为项目名称）。因此，使用单独的配置文件，我们可以包含默认网络名称，默认比例等内容。所有元配置不是应用程序定义的一部分，但仍与运行组合有关。

dnephin 于 2015-10-09

👎7 👍3

我同意dnephin所说的。文件.docker-compose怎么样？我们可以在那里列出所有命令行参数的默认选项。

mikehaertl 于 2015-10-09

@dnephin sgtm

@mikehaertl我在示例中使用了.docker-compose文件夹，但是文件也可以正常工作，具体取决于我们要存储的信息量

thaJeztah 于 2015-10-09

@thaJeztah哦，对不起。我错过了。

mikehaertl 于 2015-10-09

@mikehaertl刚刚将它们从.fig重命名为.docker-compose ;-)

thaJeztah 于 2015-10-09

对：）

实际上，我更喜欢一个简单的文件。 ini风格怎么样？全局选项位于最上方，在部分中命令特定选项：

project-name = blabla

[build]
no-cache

mikehaertl 于 2015-10-09

我们可能希望将半相关信息存储在同一文件或同一目录中的一些想法：

网络名称（用户可能希望使用与项目名称不同的网络名称。我们已经对此提出了要求。）
客户端api版本
码头工人主机
默认比例值

既然我们支持多个撰写文件，那么包含构成文件的路径以用作配置也可能很有趣。

dnephin 于 2015-10-20

客户端api版本

可能docker_host ？

thaJeztah 于 2015-10-20

听起来也不错（添加）

dnephin 于 2015-10-20

我只是遇到了这个问题。

我已经确定了Docker配置的基本结构，现在将其复制到其他服务。由于所有项目都具有相同的结构，因此它们都使用相同的子目录（因此使用默认项目名称）。这意味着我不能安全地在同一主机上假脱机处理2个服务。

我可能必须更改结构，以使项目目录名称最终成为默认名称，但我不是100％肯定在映像构建时复制文件的操作。

jdmarshall 于 2016-01-15

同样在这里，我用Makefile目标解决了类似的问题。但是，当您要执行自定义docker-compose命令时，需要使用-p customname 。

schmunk42 于 2016-01-15

现在，我正在尝试弄清楚如何防止/home/alice/myproject和/home/bob/myproject docker-compose设置踩到彼此的容器。有没有一种方法可以从完整的文件路径中获取容器名称，而不仅仅是最后一个目录名称？

chris-martin 于 2016-01-21

@ chris-martin这只是一个解决方法...

alias docker-compose="docker-compose -p ${PWD}"

schmunk42 于 2016-01-22

docker-compose从项目名称中删除/ ，但是？

是否记录了项目名称中允许使用哪些字符？

chris-martin 于 2016-01-22

我确实改变了目录结构，并将docker-compose.yml放入项目根目录，这是一个不错的解决方法

如果您倾向于将所有git存储库都放在同一个目录（例如$ HOME或$ HOME / projects）中，则可以提供某种保护，但是如果您使用其他结构（例如，每个组织使用一个目录，就像我这样），就会带来麻烦。经常这样做），或者如果您的计算机使用的是boot2docker，则除非您小心确保docker-machine为您提供了不同的VM，否则这往往会在同一盒子上的用户之间泄漏信息。

我认为＃2294或更简单地使用docker-machine也会解决我的问题。

jdmarshall 于 2016-01-22

我还建议将其放在项目根目录中，并使用其他文件夹名称。

schmunk42 于 2016-01-22

就我而言，我想设置初始项目名称，因为我在AWS上有一台共享计算机，尽管我的根目录中有docker-compose.yml，但用户可以将存储库克隆到具有不同名称的目录中。如果当前发生这种情况，那么它们会在启动/停止容器方面遇到问题。

josephearl 于 2016-01-25

使用新的v2语法，可以像在https://github.com/docker/compose/issues/745#issuecomment -74028861中提到的那样实现

它实际上只是一个container_name_prefix ，不是吗？

schmunk42 于 2016-01-25

👎1 👍1

@ schmunk42

它实际上只是一个container_name_prefix，不是吗？

它也被用作volume_name_prefix ， image_name_prefix和network_name_prefix ，所以我猜project_name是一个更通用的术语。

.docker-compose docker-compose.override.yml在很多方面对.docker-compose听起来很熟悉。另外，为什么在我们已经拥有YAML时又引入另一种配置格式（例如ini）呢？
因此，在＃745（注释）中，我支持@jderusse的建议，在docker-compose.yml添加project_name键，以启用@JosephEarl的用例。

通过使用docker-compose.override.yml并通过.gitignore排除特定于用户的自定义，已经可以实现。
如果需要第三个明确针对用户的替代文件，建议使用.docker-compose.local-override.yml 。

关于YAML的结构，我建议创建一个名为project的新顶级密钥，其中包含project_name ，将来可能还会包含其他变量。这样可以避免污染顶级名称空间。为了显示：

project:
  project_name: "your-project"
  network_prefix: "abc"

请注意，与其使用network_prefix ，不如直接自定义网络本身的名称可能更容易理解。据我了解，有两种情况：

第一种情况是“只给网络起一个唯一的名字，但我不在乎哪个是确切的”。在这种情况下， project_name就足够了。
另一种情况是外部系统引用的网络。在这种情况下，无论如何，明确指定网络名称本身可能会更好。

cr7pt0gr4ph7 于 2016-02-09

👍17

上面的建议对我来说听起来不错，我同意我们不想引入任何额外的配置文件

josephearl 于 2016-02-09

+1这个问题的概念
但也可以+1使用docker-compose.yml的密钥，而不是在我们的存储库中添加另一个文件。

simonvanderveldt 于 2016-02-09

👍5

总结以前的评论：关于项目名称查找顺序的一项建议如下：较早的项目优先于较晚的项目：

如果指定，请使用--project-name
如果指定，请使用COMPOSE_PROJECT_NAME 。
使用project_name从关键docker-compose.yml （或者不管在哪里设置存储）。
使用项目目录的basename

我不确定2比3的优先级。

为了与--project-name保持一致， COMPOSE_PROJECT_NAME应该绝对覆盖project_name: 。
但是：使COMPOSE_PROJECT_NAME优先于project_name: ，由于设置了环境变量，可能会意外使用错误的项目名称；这可能很难调试。在这种情况下，可能会出现警告消息？

cr7pt0gr4ph7 于 2016-02-10

👍27

关于引入具有默认值%(project_name)s_%(service_name)s_%(instance_number)s的新属性container_name_pattern %(project_name)s_%(service_name)s_%(instance_number)s来保持BC的内容
此参数使我们可以自由地将其更改为hardcodedproject_%(service_name)s_%(instance_number)s并最终解决此问题

jderusse 于 2016-02-10

👍1

寻找此功能10分钟后，我才刚遇到此问题。

我做的第一件事就是寻找撰写文件参考文档在右侧键，所以+1 project_name关键docker-compose.yml

atd 于 2016-02-10

👍13

：+1： @ cr7pt0gr4ph7策略

dmitry 于 2016-02-10

为@ cr7pt0gr4ph7策略+1

zeroows 于 2016-02-10

Compose具有用于环境替换的语法。与其使用环境变量作为项目名称，不如让人们在需要时自己动手做？

另一方面，泊坞窗机器使用末端来确定将在其上构建组合构建的机器，因此项目名称和目标应该可以相同地工作。嗯，这很难。

jdmarshall 于 2016-02-10

👍1

https://github.com/docker/compose/issues/745#issuecomment -182296139听起来不错。环境变量将优先于compose文件中的值，该文件充当默认值（假设项目名称属于compose文件）。

需要考虑的事情，当您使用多个分别定义项目名称的撰写文件时会发生什么？

我不认为这应该是一个错误，它会强制文件为“主”或“扩展名”，目前情况并非如此。任何文件都可以单独使用或与其他文件结合使用。

警告可能是合理的，或者我们可能只是完全忽略它（因为也可以通过设置选项或环境变量来忽略该值）。

dnephin 于 2016-02-10

需要考虑的事情，当您使用多个分别定义项目名称的撰写文件时会发生什么？

如果您执行类似docker-compose -f compose1.yml -f compose2.yml up并且两个文件都定义了项目名称，则使用的名称应为compose2.yml 。

josephearl 于 2016-02-10

我认为每个人都在使用我已经喜欢的解决方案：-）即docker-compose.yaml中的project_name 。我只想提及在docker-compose.yaml文件中具有项目名称的另一个用例：

在我项目的HTTP 500 Internal Server Error页面中，我告诉开发人员如何解决问题或进行故障排除，例如，我告诉他/她如果服务器发现没有PostgreSQL数据库且他/她可以zcat database-dump.tgz | docker exec -i projectname_db_1 psql用户已经创建-然后我要自己选择projectname ，否则不能将帮助消息复制粘贴到控制台中。

kajmagnus 于 2016-02-15

同意当COMPOSE_PROJECT_NAME覆盖compose.yml中的项目名称时应该发出警告-这种行为基于现有的Docker命令是有意义的，但是对于新手来说不是特别合理或显而易见。

josephearl 于 2016-02-15

为@ cr7pt0gr4ph7策略+1

omercnet 于 2016-02-17

尝试在自己打开问题之前先搜索一些东西，因为我找不到任何东西。
docker.compose.yml文件中的project_name +1。对于v2，我想这变得越来越有意义。

intellix 于 2016-02-21

同意当COMPOSE_PROJECT_NAME覆盖compose.yml中的项目名称时应该发出警告-这种行为基于现有的Docker命令是有意义的，但是对于新手来说不是特别合理或显而易见。

环境变量覆盖配置设置，命令行参数覆盖配置设置和环境变量是很正常的行为。
我们真的为此警告吗？并非有人会意外地创建一个名为COMPOSE_PROJECT_NAME的环境变量。

创建只使用project_name的docker-compose.yml来实现这一目标的PR可以吗？还是我们想要额外的东西，例如使用立即引用的最后yml文件中的project_name值？

simonvanderveldt 于 2016-03-03

这个怎么样？

version: "2"
project:
    default_name: "app"

我将更改此格式的实现（https://github.com/docker/compose/pull/3118）。但我不确定是否需要project部分...。

fesor 于 2016-03-15

👍1

+1渴望看到此功能

timgriffiths 于 2016-04-04

@timgriffiths ，通过在您的项目中添加环境文件，可以在最新的RC中实现：

deizel 于 2016-04-04

👍7 🎉2

@deizel所以我查看了环境文件，但是我仍然认为有一个很好的用例，可以在compose文件中定义项目名称。

在我们的情况下，我们只有Prod，Staging，UAT，Dev组成文件，因此我们可以启动应用程序堆栈的不同版本，有时我们想在同一组上支持Staging和UAT环境，因此我可以使用环境变量或其他变量，但这取决于用户，所有人都记得要进行设置，就好像它在compose文件中一样，所有内容都将被检入到存储库中，并且我们可以使所有内容保持内联且易于在所有用户中解释。

timgriffiths 于 2016-04-05

👍4

+1我们遇到的情况是我们的撰写文件引用了预配置的远程卷。 Compose会自动将项目名称添加到那些卷名称中，然后由于名称不匹配而无法挂载。能够在compose yml文件中显式设置项目名称将使命名约定对参与项目的其他人更加明显，而不是将环境变量隐藏在可能随环境而变化的晦涩的外部文件中。

edevenport 于 2016-04-05

在您的情况下， @ edevenport可以使用命名卷的外部选项：

# docker-compose.prod.yml
volumes
  dbdata:
    external:
      name: my-project-db-data

fesor 于 2016-04-05

谢谢@fesor-我应该详细介绍一下。我实际上是使用类似于以下的配置来安装glusterfs卷：

    ...
    volumes:
      - media:/data/media:ro

volumes:
  media:
    driver: glusterfs

在这种情况下， media在主机上将变成projectname_media ，并且无法装载，除非使用项目名称提前创建了glusterfs卷。我曾考虑过手动将glusterfs卷安装在主机上，并在docker-compose文件中使用external ，但是我宁愿不必提前在所有节点上手动进行操作。

edevenport 于 2016-04-06

@edevenport我明白这一点。但是您可以只使用docker volume create手动添加该卷并使用它：

    volumes:
      - media:/data/media:ro

volumes:
  media:
    external:
      name: my-glusterfs-media

因此，无需更改项目，也无需删除任何前缀。

@timgriffiths的情况更为复杂，并且没有任何解决方法。我在docker-compose周围使用了简单的包装，只是为了不记得项目名称。

fesor 于 2016-04-06

@fesor，因此我们通过将撰写文件粘贴在描述性文件夹名称中来解决了该问题，从而避免了此限制。但是很高兴在以后的版本中添加它

timgriffiths 于 2016-04-07

@timgriffiths我进行了PR（https://github.com/docker/compose/pull/3118）-也许这会有所帮助。但是，如果您有多个撰写文件，则无法解决您的情况。

fesor 于 2016-04-07

@fesor PR是完美的，是否有可能将其合并？

timgriffiths 于 2016-04-07

现在Compose提供了Environment文件，因此项目名称可以在此处持久保存。

mkuzmin 于 2016-04-24

🎉5

@mkuzmin很遗憾有COMPOSE_FILE但没有COMPOSE_OVERRIDE_FILE 。

fesor 于 2016-04-24

@fesor AFAIK，您可以指定多个文件

schmunk42 于 2016-04-24

@ schmunk42我也可以指定项目名称。但这不能解决问题。我想要在部署脚本中添加以下内容：

docker-compose up -d

代替

docker-compose -f $COMPOSE_FILE -f $COMPOSE_OVERRIDE_FILE \
            up -d

上面示例中的COMPOSE_PROJECT_NAME由CI指定。和.env文件之类的功能很酷，但是...在项目名称持久化的情况下没有用。

我使用.env来DRY env变量（对于docker-compose <1.7，我有一个简单的包装器），但是它不能解决任何其他问题。 @timgriffiths已经指出了在群集集群上部署的情况。

fesor 于 2016-04-24

COMPOSE_FILE=one.yml:two.yml是如何设置多个文件。因此，只需在$COMPOSE_FILE包含替代文件

dnephin 于 2016-04-24

@dnephin错过了该功能，很酷。

好吧...关于群部署，我已经通过jenkin的job ENV变量中的COMPOSE_PROJECT_NAME处理了，所以只有手动部署有问题。而且我的实现不允许覆盖默认项目名称，因此...

fesor 于 2016-04-24

该问题已存在将近2年，但仍未解决。我想知道到底是什么在阻碍Docker团队最终添加适当的修复程序。为docker-compose.yml文件添加一个简单的新配置指令真的很难吗？

虽然.env的解决方法很好，但它并不总是可用（ .env文件可能已被您的应用程序使用）。而且这仍然是一种解决方法。

而且我什至还看到了其他与项目名称有关的新问题，这些问题逐渐演变为最新版本（＃3966）。

那到底是什么问题呢？

mikehaertl 于 2016-09-21

为docker-compose.yml文件添加一个简单的新配置指令真的很难吗？

没有！这个问题从来都不是难以实施的。

虽然.env的解决方法很好，但它并不总是可用（ .env文件可能已被您的应用程序使用）。而且这仍然是一种解决方法。

这不是解决方法，而是解决方案！ .env文件包含要由Compose读取的环境变量。如果您有应用程序要读取的环境变量，请将它们放在另一个文件中（例如app.env ），然后使用env_file选项对其进行引用。

那到底是什么问题呢？

将项目名称添加到docker-compose.yml文件中会降低其可移植性，这不是我们要鼓励的。现在，有一种方法（使用.env ）可以持久地指定项目名称而不牺牲docker-compose.yml的可移植性，因此将其添加为配置选项的情况比较弱。这是此问题没有解决的主要原因。

aanand 于 2016-09-21

👎12 👍4

将项目名称添加到docker-compose.yml文件会降低其可移植性，

这不是可选的吗？就我个人而言，我从不签入docker-compose.yml而只在本地调整的回购中提供docker-compose-example.yml 。例如，在开发过程中，我可能会添加一些额外的环境变量或将其他卷映射到我的容器中。为什么不同时给我们指定项目名称的选项呢？

根据您的论点，您还应该将所有network选项移至.env因为它们通常根本无法移植，并且取决于主机的网络设置。

换句话说，什么使项目名称如此特别？ docker-compose.yml中已经有许多其他选项不是真正可移植的。为什么不让开发人员选择最适合其用例的选项呢？

mikehaertl 于 2016-09-21

👍8

我也认为应该提供该选项。随着Docker的使用变得越来越广泛，只有一名开发人员在其工作流中使用容器化的项目将变得越来越普遍。在这些用例中，项目名称为常数是可以的。另一个具有这种灵活性的项目的一个很好的例子是他们的Vagrantfile流浪汉。他们意识到大型团队肯定有用例，但同时也认识到了孤独的开发人员场景。

我认为在此处实施项目名称选项对于采用非常重要。它可能会甩掉那些不在乎“可扩展项目名称配置策略”的开发人员。

axsuul 于 2016-09-21

将项目名称添加到docker-compose.yml文件使其可移植性降低，这不是我们要鼓励的。现在，有了一种方法（.env）可以在不牺牲docker-compose.yml的可移植性的情况下持久地指定项目名称，将其添加为配置选项的情况就更弱了。这是此问题没有解决的主要原因。

如何将项目名称添加到docker-compose.yml使其具有较低的可移植性？

恕我直言，实际上是相反的，如@mikehaertl创建的＃3966所示。这个问题清楚地表明，没有将项目名称存储在docker-compose.yml实际上使事情变得不那么容易移植（例如：与来自同一计算机的其他撰写项目发生冲突的可能性更大），因为Compose依赖于以下约定：许多人（至少最初不知道）不知道的容器文件夹名称。

添加添加.env文件不仅为想要采用Compose的新人添加了额外的东西，而且我还必须将其添加到docker-compose.yml旁边的仓库中，以防止出现这些情况冲突除了在docker-compose.yml定义项目名称外，我看不出有什么不同的可移植性。

simonvanderveldt 于 2016-09-21

👍11

我也想将名称添加到docker-compose.yml中。 .env文件在我使用的其他框架中使用，重要的是不要使用回购协议。但是，为了在我的开发人员中维护本地化的容器，他们对docker的了解越少（起初）就越好。我想要一个不会与其他项目冲突的简单入口点。我不想解释为什么事情就是这样。只是一个简单的

克隆回购
码头工人组成

我现在的解决方法仍然是创建@ schmunk42建议的文件。

fiveanddone 于 2016-09-21

👍31 🚀1

容器本身不关心项目名称。为什么使用环境变量作为仅供主机关心的机制？

joequery 于 2016-12-20

我希望在docker-compose.yml文件中看到对此的支持。如果需要通过环境变量进行设置，则可以在.env文件中定义（如果未在主机上直接设置），并可以通过docker-compose.yml文件中的变量替换来使用。

thasmo 于 2016-12-29

如果允许命名容器，为什么不允许命名项目？

.yml文件中的项目名称定义很方便的用例如下：
对于不同的Web服务器，我们具有相同的docker-compose文件（不同的数据库凭据，不同的数据量，一些小的差异（如徽标等））。每个应用程序正在运行的服务有3个，它们在一个compose文件中进行配置。当多个服务器并排运行时，很高兴看到哪个服务属于哪个项目。

使用$ COMPOSE_PROJECT_NAME作为前缀，可以方便地在容器名称中进行变量替换。我很了解.env文件解决方案，但这使它在（CI）部署环境中不更加“对开发人员友好”。

hsimilli 于 2017-01-03

我认为，由于没有设置-p或环境变量，并且您在“ docker”子文件夹中创建了docker-compose，因此使一个docker-compose杀死了一个完全不同的docker-compose容器，这是一个严重的错误。

在严重的部署中，错误的余地太大了。只是忘记指定项目名称，无论是在-p，.env还是其他位置：您都会离线一段时间，直到注意到发生了什么。更糟糕的是：碰撞服务脱机，而不是您正在使用的服务。您将有一个快乐的一天:(

RobIsHere 于 2017-01-23

👍18

@dnephin到底是什么

mikehaertl 于 2017-01-23

👍14 😄4 ❤2 🎉2

也许我是唯一对此有疑问的人，但是无论如何。
在我们的设置中，我们仅修改.env和app.env文件用于切换环境，但这依赖于具有多个文件并合并yml文件。

如果这一点得以实施，请考虑卑诗省。

例如。如果在docker-compose.yml和.env定义了项目名称，则后者优先。否则，依靠.env来管理它的人会遇到重叠堆栈类似的问题，例如当前的工作流程和依赖的文件夹名称。

schmunk42 于 2017-01-23

@ schmunk42我们并不是说应该删除.env功能。如果您希望将项目名称包含在.env则只需不在docker-compose.yml 。

但是其他人更喜欢将其包含在docker-compose.yml ，如此处的讨论清楚所示。如果需要，他们应该能够这样做。这是一项可选功能。如果同时配置了两者，则优先级是定义一个简单的约定。

mikehaertl 于 2017-01-23

👍16

抱歉，请添加命名的项目。用例：
项目一：
docker-compose up --build --remove-orphans

Nginx的
静态内容
项目二：
docker-compose up --build --remove-orphans
Nginx的
静态内容

当第二个项目启动时，它将通过出口137（代码128 + 9级）杀死一个项目的容器。

现在，我必须每天运行docker system prune并重建网络，以防止自己拥有数十个死容器。

davidjeddy 于 2017-02-24

export COMPOSE_PROJECT_NAME=somethingnew

dnephin 于 2017-02-24

👎11

核心团队中的某人也许可以最终解释一下，该功能是什么造成的？令人沮丧的是，没有充分的理由如何阻止如此容易修复的内容。

到目前为止，唯一的论据是保持docker-compose.yml可移植性。这没有任何意义，因为

composer文件中的项目名称不会自动使其不再可移植
并不是每个人都有这个要求
- 我们已经有其他可以用相同方式限制可移植性的选项： networks ， port ，...

这完全取决于特定的用例。但是，仅因为某些人不希望使用此选项，并不意味着每个人都必须听取他们的意见！

mikehaertl 于 2017-02-26

👍12

@mikehaertl您已经有了永久项目名称。只需将.env文件放入并在其中设置COMPOSE_PROJECT_NAME变量即可。我不再在撰写文件中看到项目名称的任何好处。

fesor 于 2017-02-26

👎7

@fesor我通常不会在版本控制下拥有.env文件，因为它们包含特定于机器/环境的设置-这也是为什么我希望在docker-compose.yml文件中看到可配置项目名称的原因。

thasmo 于 2017-02-26

👍2

@fesor ：我认为@thasmo在此compose.yml文件中指定，因为如果它与使用该项目的所有开发人员都相关，则应该在版本控制中。

nhooey 于 2017-02-26

@fesor对不起，但我认为个人喜好不是真正的论点。真正的问题不是，为什么我们不想使用.env或环境变量。反过来说：为什么它没有放在所属的配置文件中？

几乎可以在命令行上传递给docker所有选项都可以在该文件中指定。由于某些神秘原因，仅将项目名称排除在外。这是论点之间的种族隔离形式吗？：PI对所有人都享有平等权利！让开发人员决定，不要对它们施加人为的约束。

再说一遍：没有人会放弃您的旧选项-我们最终只想要这个额外的选项。那是公平的。

mikehaertl 于 2017-02-26

👍11

@dnephin ：看来您和其他所有人对cr7pt0gr4ph7对这个问题的完善中所述的解决方案感到满意。

您是否愿意接受实现它的请求请求，还是打算让一位维护者编写请求？

@ cr7pt0gr4ph7

nhooey 于 2017-02-26

@dnephin @fesor在*

davidjeddy 于 2017-02-27

我不清楚项目名称为何如此重要。配置文件的任何部分都不应依赖任何特定的项目名称。

项目名称的唯一重要特征是，它与任何其他项目的名称均不冲突，这实际上是反对将其放入docker-compose.yml文件中的论点。项目的开发人员通常会为每个项目使用不同的目录名称，因此默认值通常对于大多数用例都是正确的。

如果默认值不正确，则开发人员可以使用一种方法来覆盖它（ -p或COMPOSE_PROJECT_NAME ），它可以是别名，也可以放在.env文件中。

我不反对定义项目名称的项目文件，我只是想了解为什么此功能对某些人如此重要。如果是因为Compose文件需要特定的项目名称，那么我认为这是一个单独的问题，应该以不同的方式解决，

dnephin 于 2017-02-27

👎9 😕2

我想在1个目录中有4个撰写文件。默认情况下，此目录名称错误。我唯一的选择是.env，它仅适用于1个目录中的1个撰写文件。

_为什么我排除COMPOSE_PROJECT_NAME和-p：_
我认为COMPOSE_PROJECT_NAME和-p不在生产中保存，因为您必须记住对其进行设置。或创建启动脚本，并记住不要直接使用docker编写。当人员A依靠这种机制而人员B不知道它时，那肯定是失败的。
（我已经在上面详细介绍了）

RobIsHere 于 2017-02-27

👍6

@dnephin对于我和我的团队来说，应用程序逻辑通常存储在项目文件夹中的htdocs文件夹中。这使我们可以将其他相关文档/资源放在一个目录中。作为开发人员，与远程开发人员一起工作。如果我不必假设他们的文件夹结构很简单，让他们采用Docker就很容易。我过去曾说过，.env对我来说不是一个选择，因为它通常不是我们所有人共享的回购的一部分。

fiveanddone 于 2017-02-27

我不清楚项目名称为何如此重要。配置文件的任何部分都不应依赖任何特定的项目名称。

这不止一次发生在我身上，我在主机上进行了一个“ docker-compose down”操作，并让一个与我想要的容器不同的容器出现故障！只是因为我不记得， .env文件中也有配置。

项目名称的唯一重要特征是，它与任何其他项目的名称均不冲突，这实际上是反对将其放入docker-compose.yml文件的论点。项目的开发人员通常会为每个项目使用不同的目录名称，因此默认值通常对于大多数用例都是正确的。

也许这对您来说是对的-对我和其他许多人都不是。我的应用程序结构类似于myapp/app/docker-compose.yml 。因此，我所有的应用程序都共享目录名app 。而且我的主机上有多个容器。

如果默认值不正确，则开发人员可以使用一种方法来覆盖它（-p或COMPOSE_PROJECT_NAME），该方法可以是别名，也可以放入.env文件中。

认真地说，我开始觉得自己在读卡夫卡小说。显然，您可以将docker所有命令行选项都放入docker-compose.yml -除了这一大例外之外？

为何没有人一遍又一遍地问我们而忽略了我们的答案，为什么有人最终不能证明抵抗是正确的。不，“……但我不需要”不是有效的论点！

mikehaertl 于 2017-02-27

👍7

@dnephin我在自己的gitdocker的子文件夹中（构建上下文变为.. ，效果都很好）。

要在单个服务器上运行多个项目，我目前必须在每个存储库中创建docker/.env.dist在cp docker/.env.dist docker/.env之后创建git clone 。否则，项目名称仅为docker ，我显然不希望这样做。在少数情况下， .env包含密码等，因此无论如何都需要复制.env.dist ，但是在大多数情况下， .env存在仅仅是因为无法定义COMPOSE_PROJECT_NAME在docker-compose.yml 。

据我所知，有可能是在容器如何启动和停止毛刺如果同一COMPOSE_PROJECT_NAME用于内两次docker-compose.yml ，但如果我忘记拷贝一个已经发生了.env.dist或在同一服务器上的两个不同.env文件中意外分配相同名称时。对我来说，如果我可以在docker-compose.yml定义default_compose_project_name ，然后重写.env的值，那是很理想的，如果我想运行某个项目的临时副本。这将是100％BC，但是更加方便。

kachkaev 于 2017-02-27

👍3

我过去曾说过，.env对我来说不是一个选择，因为它通常不是我们所有人共享的回购的一部分。

也许，这就是所有问题的根本原因，在此之前，我曾说过docker-compose “劫持”了这个文件，然后我们被迫将自己的东西重命名为app.env 。

也许docker-compose.env是正确的选择。

FWIW：我们只更改生产中的.env文件，如果需要，将yml文件与docker-compose.override.yml合并。

一种解决方法也是以某种方式定义您的yml文件，例如，如果没有.env文件，它们就不会启动。使用变量image: $IMAGE 。

schmunk42 于 2017-02-27

这是@ schmunk42上方1个目录中4个docker-compose文件的解决方法？真？

RobIsHere 于 2017-02-27

@RobIsHere但是您还是需要使用-f对吧？

schmunk42 于 2017-02-27

在此评论中回复@dnephin ：

我不清楚项目名称为何如此重要。

这很重要，因为它会影响docker-compose管理的Docker容器的名称。如果您忘记设置项目名称，则docker-compose ps将找不到docker-compose --project-name <project_name> up -d <container_name>之前创建的容器。

另外，当您运行全局命令docker ps ，项目名称将包含在正在运行的容器列表中，因此您知道它们来自何处。例如，如果您一次测试多个都使用MySQL的代码项目，并且每个代码项目都有一个mysql容器，则docker ps将显示一个模糊的容器列表。因此，项目名称在同一台机器上运行的许多Docker项目的上下文中很重要。

配置文件的任何部分都不应依赖任何特定的项目名称。

必须将项目名称设置在与_与Docker Compose project关联的其他变量无关的其他位置。

项目名称的唯一重要特征是，它与任何其他项目的名称均不冲突，这实际上是反对将其放入docker-compose.yml文件的论点。

出于我在第一段中提到的原因，这不是“项目名称唯一重要的品质” _。这是为了易于使用和理解。

项目的开发人员通常会为每个项目使用不同的目录名称，因此默认值通常对于大多数用例都是正确的。

在非默认情况下，开发人员将与所有相关的Docker文件放在docker目录中，这是组织Docker项目的一种非常合理的方法，设置项目名称的魔力将创建冲突的项目名称。因此，在这种特殊情况下，您提到的冲突也会发生。无论如何，当开发人员明确设置项目名称时，您无需保护开发人员免遭项目名称冲突。

如果默认值不正确，则开发人员可以使用一种方法来覆盖它（-p或COMPOSE_PROJECT_NAME），该方法可以是别名，也可以放入.env文件中。

设置环境变量是不必要的额外级别的复杂性。当您使用版本控制在开发人员之间共享项目时，仅使用文件是有意义的。每次调用都必须包含命令行参数，这很繁琐且容易出错。 .env文件不能在版本控制中共享，因为它应该包含_user-specific_变量，而不是_project-specific_变量。因此，当前设置项目名称的方法是不够的。

我不反对定义项目名称的项目文件，我只是想了解为什么此功能对某些人如此重要。如果是因为Compose文件需要特定的项目名称，那么我认为这是一个单独的问题，应该以不同的方式解决，

影响docker-compose功能的所有变量应放在docker-compose.yml文件所在的位置。当前设置项目名称的方法引入了不必要的复杂性。

几乎每个订阅此问题的人都同意这些观点。

添加在docker-config.yml设置项目名称的功能甚至不会与任何当前功能冲突。没有理由不执行它。

nhooey 于 2017-02-27

👍5

@ schmunk42上次我检查时，

第一次采用Docker时，我发现这是一个真正的难题，因为就像@RobIsHere所示。我所有的项目目录都是myapp/htdocs/docker-compose.yml格式。在采用Docker的早期，我不小心删除了其他我不打算使用的容器。如果docker随机命名它的项目而不是在我的情况下使用文件夹名称，那会更好。

我还有其他一些远程开发人员正在开始采用Docker。作为一个团队，我总是很容易地指示这些开发人员始终/仅docker-compose up来使这些应用程序运行。这些早期采用者对Docker的了解越少，那就越好。一旦他们了解背后的力量，他们就会自己接手。

fiveanddone 于 2017-02-27

综上所述，用例似乎是默认值不合适的情况。已经有一些方法可以覆盖默认值，但是这些方法可能容易出错，并且对早期采用者不明显。

默认值不合适的情况是：

同一目录中的多个撰写文件（已经要求您指定-f来运行它们）
为所有项目使用相同的目录名（我猜这也需要您指定-f ，可能的解决方法是使用唯一的目录名）。

dnephin 于 2017-02-27

👍4

我要补充一点@dnephin ，这是Docker的早期采用者少了的绊脚石。

fiveanddone 于 2017-02-27

@dnephin您在此评论中也有这些担忧：

最初，我想在docker-compose.yml中使用该名称，但经过更多考虑之后，我真的很喜欢单独文件的想法。如果需要，可以使用一个单独的文件将其保留在版本控制之外（如果您希望每个用户都可以使用不同的项目名称）。

像这样设置项目名称解析的优先顺序将解决该问题（较大的数字将覆盖较小的数字）：

docker-compose.yml
COMPOSE_PROJECT_NAME环境变量
--project-name命令行选项

nhooey 于 2017-02-27

上次我检查时，docker不允许我们选择.env文件的名称。

@fiveanddone AFAIK您不能这样做，但这也只会解决问题，因为您必须知道该项目需要哪个ENV文件。

在phd5的情况下，我们将（app）环境移至src/而.env仅是“ control-environment-file”，我试图在此处进行解释。
我不喜欢这样，也不会自己更改。我知道对于许多项目来说这可能是不可能的。
但有一个.env您在同一水平上您的应用程序docker-compose.yml成为超级讨厌的，因为：a）你在你的“控制环境”，这不属于那里和b变量）您必须将这些变量转发到您的容器，如果在那里需要它们，并且c）您不能再在app.env文件中覆盖/更改它们。

@dnephin引入docker-compose.env作为首选的环境文件，并使用.env作为后备。您一次用fig.yml做过同样的事情。

schmunk42 于 2017-02-27

我认为这不能解决每个人的问题。 .env文件的命名对我来说是一个不同的问题。

我认为问题的症结在于：

docker-compose up的原始设计是您可以运行以使服务运行的单个（简短）命令。这就是开发人员所期望的。但是，某些用户无法实现该行为（在这种情况下）。

有很多方法可以解决此问题，但似乎没有一种方法适用于所有人。

我认为优先顺序（从最高到最低）必须是这样的：

--project-name （总是优先）
COMPOSE_PROJECT_NAME环境变量
用户定义的默认值，与任何版本化文件分开
项目定义的默认值，可以将其签入
目录名称（不指定任何内容时的默认名称）

（3）可以使用.docker/project-name文件来实现（如OP中所建议）
（4）可以通过docker-compose.yml文件中的字段来实现

不幸的是，需要使用许多不同的方法来设置项目名称。

dnephin 于 2017-02-27

👍2

@dnephin关于3，让用户设置默认值，这就是env vars的用途，无需创建文件

simonvanderveldt 于 2017-02-27

嗯...如果我们稍微推广一下问题，然后在docker-compose.yml简单地引入default_environment部分呢？这样，我们将能够设置COMPOSE_PROJECT_NAME而不在yaml中引入特殊字段，但是还能够定义其他默认变量，这些变量可能存在于整个文件的其他位置。这样可以减少需要将.env.dist复制到.env的情况，而这样做的成本会更少。

用法示例：

# ~/projects/sketches/sketch-42/docker/docker-compose.yml
version: "2"
default_environment:
  - SUBDOMAIN=sketch-42
  - ROOT_HOST=example.com
  - COMPOSE_PROJECT_NAME=sketch-42
services:
  web:
    build:
      context: ../
      dockerfile: docker/Dockerfile
    environment:
      - VIRTUAL_HOST=${SUBDOMAIN}.${ROOT_HOST},www.${SUBDOMAIN}.${ROOT_HOST}
      - VIRTUAL_PORT=80
      - VIRTUAL_NETWORK=proxy
      - LETSENCRYPT_HOST=${SUBDOMAIN}.${ROOT_HOST},www.${SUBDOMAIN}.${ROOT_HOST}
      - LETSENCRYPT_EMAIL=admin@${ROOT_HOST}
    restart: always
    networks:
      - proxy

networks:
  proxy:
    external:
      name: proxy

这个Yaml与我经常使用的Yaml非常相似-它描述了一个vis草图，该草图始终具有名为web ，但也可以由小型API服务器以及可能带有数据库的容器进行备份。假定https://github.com/jwilder/nginx-proxy位于所有内容的前端，并监听真实的端口80和443。

此刻，无论我是在本地计算机上还是在远程服务器上，我都需要记住要维护.env并确保在此设置了_all_环境变量。假设我忘记了SUBDOMAIN ，那么容器将启动，但是Web服务器仍然损坏。

使用default_environment部分，我可以将所有生产变量放在一个文件中，并且在服务器上时不必复制.env.dist 。在本地计算机上，在上面的示例中，我只是将一个变量放入.env ，这将是ROOT_HOST=example.com.dev （或者我甚export ROOT_HOST=example.com.dev可以在bash配置文件中输入

总之， default_environment第docker-compose.yml ，不仅可以解决目前我们正在讨论这个问题，而且还可以使一些额外的不错的技巧，同时为公元前100％，易于理解！

WDYT？

kachkaev 于 2017-02-28

👍7

听起来不错，在某些情况下可能对我有用。

但是，请注意，根据以上（激烈的）讨论，您的
解决方案大致可解释为：“与其将新文件添加到
yml，我们添加一个新部分怎么样？” :)

2017年2月28日，星期二，00：02 Alexander Kachkaev [email protected]
写道：

嗯...如果我们将问题概括一下再简单介绍一下
docker-compose.yml中的default_env部分。这样我们定义
COMPOSE_PROJECT_NAME并未在Yaml中引入特殊字段，但是
还将能够定义其他默认变量，这些默认变量可能是
出现在整个文件的其他位置。这样可以减少案件数量
需要将.env.dist复制到.env时以及忘记
这样做会更少。
用法示例：
〜/ projects / sketches / sketch-42 / docker / docker-compose.yml
版本：“ 2”
default_env：
SUBDOMAIN = sketch-42
ROOT_HOST = example.com
COMPOSE_PROJECT_NAME = sketch-42
服务：
网络：
建立：
上下文：../
dockerfile：docker / dockerfile
环境：
-VIRTUAL_HOST = $ {SUBDOMAIN}。$ {ROOT_HOST}，www。$ {SUBDOMAIN}。$ {ROOT_HOST}
-VIRTUAL_PORT = 80
-VIRTUAL_NETWORK =代理
-LETSENCRYPT_HOST = $ {SUBDOMAIN}。$ {ROOT_HOST}，www。$ {SUBDOMAIN}。$ {ROOT_HOST}
-LETSENCRYPT_EMAIL = admin @ $ {ROOT_HOST}
重启：总是
网络：
- 代理
网络：
代理：
外部：
名称：代理
这个Yaml与我经常看到的非常相似-它描述了
草图，该草图始终具有称为Web的服务，但也可以备份
通过小型API服务器，可能还有一个带有数据库的容器。假设
https://github.com/jwilder/nginx-proxy坐在最前面并听
到实际的端口80和443。
此刻，无论我是在本地计算机上还是在远程服务器上，
我需要记住维护.env并确保所有
在此设置环境变量。如果，如果我忘记了
SUBDOMAIN，容器启动，但是Web服务器仍然损坏。
使用default_env部分，我可以完成所有生产
变量到位，我不必在服务器上复制.env.dist。
在本地计算机上，我只需将一个变量放入.env中，这将是
ROOT_HOST = example.com.dev（或者我什至可以导出
bash配置文件中的ROOT_HOST = example.com.dev？）
总而言之，docker-compose.yml中的default_env部分不仅可以
解决我们现在讨论的问题，但也可以启用一些更好的用法
场景！
WDYT？
-
您收到此消息是因为您已订阅此线程。
直接回复此电子邮件，在GitHub上查看
https://github.com/docker/compose/issues/745#issuecomment-282885661或静音
线程
https://github.com/notifications/unsubscribe-auth/AAQJJZumr10j3i17gPxrSyA-n8CwvsXTks5rg1X_gaJpZM4DLBNs
。

gergelypolonkai 于 2017-02-28

😄1

在docker-compose.yml中包含“ project_name”将解决我们的堆栈问题。
我们有一个带有标准树的整体仓库，可处理多个项目，看起来或多或少像这样：

projectA/infrastructure/docker-compose.yml
projectB/infrastructure/docker-compose.yml
...

它显然比现实世界中的复杂，因此我们不能仅将docker-compose.yml文件移动到“ projectA / projectB”文件夹中。

我们在根目录有一个CLI，该CLI询问要引导哪些项目，并且由于项目名称直接取决于docker_compose.yml的父文件夹，因此我们面临冲突。

由于我们没有自己编写docker-compose命令（包装在CLI脚本中），因此我们不能仅手动将“ -p” arg添加到命令中。
我们的解决方案是始终在CLI脚本中生成一个project_name，因此基于绝对路径，在调用docker-compose时始终有一个“ -p”，但这听起来很奇怪。

这里有人说：“大多数情况下，它在大多数项目上都有效，因为docker-compose.yml位于项目的根文件夹内，并且项目具有不同的名称，以避免冲突”，我只是不同意这个。它并不总是在根文件夹中。

为什么可以在服务的docker-compose.yml文件中定义“ container_name”（禁用缩放），却无法在与docker-compose.yml文件本身相同的级别上定义“ project_name” “版本” /“服务” /“网络” /“卷”？

oliviermadre 于 2017-05-17

👍1

似乎必须使用scale使容器名称显而易见。（例如<project_name>_<container_name>_1 ）。

使用dns的容器名称时，这将有所帮助。

shaunwarman 于 2017-05-23

来到这里希望做到这一点。左失望。 3年以上

jbogatay 于 2017-06-01

👍34 😄1

是的，这是Docker最愚蠢的可用性问题之一，并且尚未解决。

我们花了很多时间与开发人员争论，即使达成共识，也不能否认这是一个糟糕的设计。

nhooey 于 2017-06-01

👍2

它之所以令人沮丧是因为用户对此提供了明显的支持，但是由于它不适合开发人员自己的用例，因此我们年复一年地重新进行哈希处理。

jbogatay 于 2017-06-01

👍1

如果我们需要使用cli添加选项，docker-compose有什么意义？
多亏了命名方案，我的一些容器被覆盖了。

src386 于 2017-06-12

今天，我正在建立另一个docker-compose项目和另一个.env文件，为该项目赋予永久名称。因此，我认为自从上次检查以来已经有好几年了，我才检查了这个问题。但是据我所知，这里没有什么新鲜的东西吗？我猜我将不得不继续使用.env解决方法。对我来说，在yaml文件中命名项目似乎是您可以做的最基本的事情，但是我想我对此还有些不了解，因为尚未解决。

jonaskello 于 2017-07-01

😕9 👍1

有从外部指定项目名称（通过命令行或变量），但暂时无法将其设置在docker-compose.yml文件-文件指定绝对一切-仅仅是盲目的。在许多情况下，无论父目录名称，shell环境或特定.env是否存在特定行，进程都可能需要基于任意docker-compose.yml文件处理特定服务栈。 .env文件。我不希望我的CI职位必须不断“弄清楚”项目名称是什么-应该在docker-compose.yml清楚地说明，以便我的职位可以提取和使用它。

这个项目似乎一次又一次地发生。 Docker是一项了不起的技术，但有时我想知道开发人员是否真的有任何实际经验，或者他们都是18岁的认为自己最了解的黑客？人们希望将这些东西用于实际工作，而不是花费时间不断寻找解决方法。

DavidAntliff 于 2017-08-30

👍2

我的猜测是，团队同时忽略了这个问题。试图说服Docker开发人员可能是一个痛苦的说法。

清晰的论点与一些没有多大意义的怪异逻辑相抵触。所有出于相同原因来到这里的现实世界用户的意见都将被忽略。这是一个耻辱。

mikehaertl 于 2017-08-30

👍4

我不希望我的CI工作必须不断“弄清楚”项目名称是什么-应该在docker-compose.yml中明确说明，以便我的工作可以提取并使用它。

是否存在您的堆栈被命名为“ build1234”的问题，和/或您想如何在另一个地方使用堆栈的名称，例如docker exec build1234_myservice script.sh ？

可能不适合任何用例，但要说的是...

在我们的设置中，我们仅在设置（克隆）项目时更改.env文件。如果需要更改或动态配置，则可以重复使用.env中docker-compose.yml .env中的变量。一个优点是，如果缺少变量，则docker-compose会警告您（或失败）。

我不想告诉您必须更改工作流程，因为这个问题也让我感到恼火。
基本上是这样，我们将对docker-compose.yml更改视为对源代码的更改，而将.env仅仅是配置。但我也同意docker-compose.yml中有几个选项，例如network高度依赖项目。回到上面；我将为网络定义一个.env变量。 🤐

schmunk42 于 2017-08-30

我不想告诉您必须更改工作流程，因为这个问题也让我感到恼火。

我考虑了一下自己的情况。我实际上没有在外部设置项目名称的问题，实际上我使用-p <project_name>标志来完成此操作，这使得可以在CI中隔离堆栈的唯一实例，并在同时运行多个堆栈的情况下必要。只有该CI链需要知道该项目名称，以便它可以自动生成或随机（但已知），没有问题。使用环境变量覆盖默认名称也没有问题，但是我确实发现.env技巧不是很明显。

但是，在其他情况下，在某处显式定义项目的_default name_很有用。那么为什么要以父目录名称作为此名称的来源呢？对我而言，这是这里的弱点。它可以从任何地方获取-选择父目录似乎是任意的，没有太多理由（例如，在几乎所有项目中， docker-compose.yml文件位于名为docker的子目录中）。因此，如果要随意使用，请将其存储在更明确的位置（例如yml文件），而不要通过影响父目录名来创建外部副作用，在许多情况下，父目录名应完全独立于目录的内容（基于年份）使用可重用资源的经验）。

DavidAntliff 于 2017-08-30

👍2

它可以从任何地方获取-选择父目录似乎是任意的，没有太多理由（例如，在几乎所有我的项目中，docker-compose.yml文件位于一个名为docker的子目录中）。

如果您需要随机ID之外的其他东西，那么我看不到父目录的真正替代品。至少您有机会知道堆栈的“来源”。
但我也同意您的看法，因为在我们的项目中，我们已经在tests文件夹中测试堆栈，而在没有.env文件的情况下，它们也会相互冲突。这就是为什么我建议选择一个名为docker-compose.env ，恕我直言。

schmunk42 于 2017-08-31

👍1

你们是要么关闭这个错误以承认自己不在乎，要么实施我们绝大多数人想要的非常简单的事情？ 2.86年后。下锅。拥有自己的决定或纠正错误。但是，您想看看它。多做事。

matsaman 于 2017-11-01

👍11

@matsaman和所有对此发表评论的人：

你们是要么关闭这个错误以承认自己不在乎，要么实施我们绝大多数人想要的非常简单的事情？ 2.86年后。下锅。拥有自己的决定或纠正错误。但是，您想看看它。多做事。

谁是“你们”？在开源中，社区拥有决策并纠正其他人的错误。 Docker是开源的。考虑提交拉取请求，而不是抱怨。

我也感到遗憾的是，这还没有实现。但是，在开源中，我们要么贡献力量，要么耐心等待。

benjaminwood 于 2017-11-08

👍8 👎2

CLI参数：

$ cd foo
$ docker-compose up
$ docker-compose -p bar up
... some time later wanting to take down bar forgetting '-p'
$ docker-compose down
Stopping foo_nginx_1 ... done
Stopping foo_mysql_1 ... done
Removing foo_nginx_1 ... done
Removing foo_mysql_1 ... done
$ FU@$_!@*#%$(!_*@
-bash: FU@!@*#%$: command not found

失败。

信封文件：

$ cd foo
$ source foo.env
$ docker-compose up
$ source bar.env
$ docker-compose up
... some time later wanting to take down foo forgetting to `source .foo.env`
$ docker-compose down
Stopping bar_nginx_1 ... done
Stopping bar_mysql_1 ... done
Removing bar_nginx_1 ... done
Removing bar_mysql_1 ... done
$ FU@$_!@*#%$(!_*@
-bash: FU@!@*#%$: command not found

失败。

yml文件中具有项目名称的建议解决方案：

$ cd foo
$ docker-compose -f foo.yml up
$ docker-compose -f bar.yml up
... some time later
$ docker-compose down
ERROR:
        Can't find a suitable configuration file in this directory or any
        parent. Are you in the right directory?

        Supported filenames: docker-compose.yml, docker-compose.yaml

好极了！

colinmollenhour 于 2017-11-09

$ COMPOSE_PROJECT_NAME=foo docker-compose up -d
$ COMPOSE_PROJECT_NAME=bar docker-compose up -d
... some time later
$ docker-compose down -v
Removing network project_default
WARNING: Network project_default not found.

O /

schmunk42 于 2017-11-09

谁是“你们”？

@benjaminwood这是该项目的维护者。如果我们谈论的是一项复杂的变化，没有人会花时间来做，那么您的论点就很有意义。

这在这里不是很明显：熟悉代码库的人可能很容易实现，而外部人员则很难。因此，并不是没有人有时间这样做，而是维护者不想这样做。鉴于此问题已经存在很长时间了，并且这里的：+1：数量很多，这就是支持者们极为恼的地方。

在这里一次又一次发布的解决方法都是众所周知的，但并不适用于所有人。而且我仍然找不到答案，为什么在docker-compose.yml的功能中几乎只剩下项目名称。如果有人认为它不属于那里，那就不要使用它！ 但是，如果对需求的需求是如此明显，请不要对他人发表意见。

mikehaertl 于 2017-11-09

👍1

让我们从其他角度来看。

如果我位于带有docker-compose.yml文件的文件夹中，如何找出我的堆栈具有哪个项目名称？
这是一个相当基本的问题，但是没有简单的答案。

当前（按优先级排序）：

-p
您的环境中COMPOSE_PROJECT_NAME的值
.env文件中COMPOSE_PROJECT_NAME的值
当前目录名称

要成为魔鬼的拥护者，为什么还要在这个已经令人困惑的设置中添加第五个？

尽管做出了这样的决定，但是应该有一个关于当前名称的“可干运行”信息。 docker-compose config都没有，而堆栈未运行时也没有docker-compose ps 。
也许docker-compose create是目前可用的最佳选择，但还远远不够完美。

至少应该有类似docker-compose config --project-name 。目前，我需要知道上述位置并按正确的顺序检查它们。

schmunk42 于 2017-11-09

如果我位于带有docker-compose.yml文件的文件夹中，如何找出我的堆栈具有哪个项目名称？

再说一遍：如果您不想使用它，那就不要使用它！ 如果您对解决方案感到满意-对您有好处！！ 什么都不会改变，所以您完全不会感到困惑！

但是您不能接受其他人有不同的要求吗？我们想要的只是最后添加了这个逻辑上缺失的部分。

要成为魔鬼的拥护者，为什么还要在这个已经令人困惑的设置中添加第五个？

可能造成混淆的唯一原因是因为项目名称最初是从docker-compose.yml中删除的。否则，所有内容将立即保存在该文件中。我们可以定义优先级列表-没问题。

目前，我需要知道上述位置并按正确的顺序检查它们。

您为什么不知道项目的泊坞窗名称，为什么它甚至与您相关？如果对您造成极大的困扰，为什么不在所有项目中使用相同的机制呢？

mikehaertl 于 2017-11-09

👍2

再说一遍：如果您不想使用它，那就不要使用它！如果您对解决方案感到满意-对您有好处！！什么都不会改变，所以您完全不会感到困惑！

我的问题不是使用新功能，而是缺少现有功能。项目名称是docker-compose用于启动和停止一组特定容器的唯一且唯一的相关信息。
该线程中的人们抱怨杀死错误的容器，因为项目名称不是堆栈的

但是您不能接受其他人有不同的要求吗？我们想要的只是最后添加了这个逻辑上缺失的部分。

如果添加了此选项，人们将抱怨杀死错误的容器，因为它是堆栈的

可能造成混淆的唯一原因是，项目名称最初是从docker-compose.yml中删除的。否则，所有内容将立即保存在该文件中。我们可以定义优先级列表-没问题。

实际上，您不能以BC方式添加此名称，因为它必须具有较低的优先级作为目录名称，这将使其无效。这就是为什么我问“如何获得项目名称”的原因。

您为什么不知道项目的泊坞窗名称，为什么它甚至与您相关？

因为我通常使用目录名称，但有时会使用.env的自定义值-这很重要，因为项目名称定义了对其运行操作的容器。

cd /some/path/test
docker-compose up -d
cd /a-completely-different-path
docker-compose -p test down -v --remove-orphans

这将杀死您的第一个堆栈，与yml文件中的项目名称相同。

如果对您造成极大的困扰，为什么不在所有项目中使用相同的机制呢？

是的，我只是使用默认的docker-compose功能；在大多数情况下，目录名都很好，但是如果我需要重命名，但又想继续使用同一组容器，则可以添加.env文件。

schmunk42 于 2017-11-09

👎1

如果添加了此选项，人们将抱怨杀死错误的容器，因为它是堆栈的一部分，因为它事先使用了目录名。

那没有道理。如果有人没有将项目名称添加到docker-compose.yml ，则不会有任何改变。如果他们添加了它，那是因为他们想要它！除非他们需要，否则没人会添加它。

即使他们这样做，一切都很好。我不明白您尝试在此处构造哪个问题。您太复杂了。

如果混合使用所有可以配置项目名称的选项，那么我想这就是您的问题。你根本不应该那样做。

mikehaertl 于 2017-11-09

👍2

一旦目录中有多个命名的compose文件，优先级树中的4个选项中的3个就一文不值。不要告诉我创建子目录，因为我仍然在它们之间共享一个.env文件。

YoJeff 于 2017-11-09

不要告诉我创建子目录，因为我仍然在它们之间共享一个.env文件。

您是否共享env_file使用的应用程序特定的.env文件？
还是使用一个docker-compose ？
还是混合使用？

那没有道理。如果有人没有将项目名称添加到docker-compose.yml，则不会有任何改变。

那不是问题，但是当添加它时，行为会急剧变化。

当我们将堆栈复制到新目录以生成临时实例（即用于测试升级）时，我们根本不必触摸docker-compose.yml 。但是，如果这是堆栈的一部分，则需要确定是否要用.env覆盖它，还是要在docker-compose.yml更改。

是的，可能它不应该首先添加，但是在此处使用其他选项也不会使事情变得更简单和简洁。

schmunk42 于 2017-11-09

👎1

我有一个公共的.env文件，有4个名为compose的文件（在同一目录中）使用。没有环境变量。没有外壳脚本。我只用撰写。

我更喜欢这个

docker-compose -f service1.yml up -d

相反，它更像这样

docker-compose -f service1.yml up -d
# F#&$, forgot the -p flag.   Curse the compose devs for 3 years of c#*$blocking
docker-compose -f service1.yml down
docker-compose -f service1.yml -p service1 up -d

YoJeff 于 2017-11-09

@ schmunk42您认真地认为，这是一种解决方案，可以为每个docker-compose命令

colinmollenhour 于 2017-11-09

您不能为每个服务使用一个文件夹，但顶部文件夹中仍然有.env文件吗？

docker-compose -f service1/docker-compose.yml up -d
docker-compose -f service2/docker-compose.yml up -d

只需将项目名称写入文件（-path）😉

schmunk42 于 2017-11-09

我放弃。显然，客户基础已经改变。

YoJeff 于 2017-11-09

😕1

让我知道我对您提出的建议有什么问题。

一开始我也有同样的担忧，但是我们已经将工作流程调整为可用的功能。

我不记得在过去的两年中，我们团队中没有一个人偶然杀死了一个堆栈。我们正在以这种方式运行200多个堆栈，其中包含大约1.000个容器和1.000s的自动或手动重新部署。

schmunk42 于 2017-11-09

👎3

我真的不想在这里参与……但我无法抗拒。

给定现在的方式，“解决方案”与给定存在的可能性的“正确”解决方案之间存在非常重要的区别。这个问题应该重点放在寻找“正确的”解决方案上，就我而言，这是显而易见的，尽管有些人可能仍然不同意。

nixpulvis 于 2017-11-09

👍2

@ schmunk42 ＆

我不记得在过去的两年中，我们团队中没有一个人偶然杀死了一个堆栈。

我要问我看到你们都是codemix org的一部分。你是同事吗？开始怀疑两个人是否在幕后。

benjaminwood 于 2017-11-09

😄3

当前（按优先级排序）：
-p的值
您环境中的COMPOSE_PROJECT_NAME的值
您的.env文件中的COMPOSE_PROJECT_NAME的值
当前目录名称
要成为魔鬼的拥护者，为什么还要在这个已经令人困惑的设置中添加第五个？

我看到的问题是_environment-specific_，当前可以使用的_every single value_。无法提供特定于项目的选项。

1 + 2。必须由用户调用命令手动提供。

可以共享，但是实际上.env应该被忽略，并且出于充分的原因不应该共享。（我通过共享.env.example解决此问题，但这仍然需要额外的手动步骤。）
实际上是随机的，并且特定于用户/环境。（我也将其视为回退，因为将_needs_命名为项目名称。这甚至不是很好的回退，因为在不同目录中可能存在名称相同的项目，这可能会发生冲突。）

我认为，以及该线程中的许多线程，应该有一个介于3到4之间的选项，其中可以在用于该项目的任何docker-compose文件中提供默认项目名称_can_，并将其用作第一个倒退。然后，部署此项目的任何人都将共享此值。选项1-3将覆盖该值，而选项4仅在未提供时使用。

joshuajabbour 于 2017-11-09

👍1

@benjaminwood我可以向您保证，没有人会嘲笑这个问题。是的，我们彼此认识已有一段时间了，这不是我们第一次根本不同意。我可能对这里的一些用户感到烦恼，但这不是我的意图。实际上，我想分享我的经验并提出解决方案。我相信我对此主题有丰富的经验。如果按照建议的方式引入该功能，则会在我们的设置中引入大量可能的错误。

schmunk42 于 2017-11-09

👍2

@joshuajabbour

可以共享，但是在实践中，.env应该被忽略，并且出于充分的原因不应该共享。

这取决于您的设置，我们在所有项目存储库中都忽略了此设置。
但是，我们不会在暂存和生产堆栈专用存储库中忽略它。如果您要共享在docker-compose.yml提交的名称，则还可以提交.env （此文件仅用于docker-compose命令-别无其他）

实际上是随机的，并且特定于用户/环境。

它的随机性不会比docker-compose.yml的值多多少少，您需要将堆栈配置作为一个文件夹而不是单个文件查看。如果这样做，则可以在.env使用名称或子文件夹名称。

对于所有人，我还有最后一种选择：

docker stack deploy -c docker-compose.yml the-project-name

（*）仅在群体模式下可用

我看不到将来如何将项目名称放入yml文件中，这完全与堆栈定义的思想相矛盾。

schmunk42 于 2017-11-10

谢谢@ schmunk42。我相信您和我认为您在此主题中显示的所有强烈意见中都处理得很好。

benjaminwood 于 2017-11-10

这会在我们的设置中引入大量可能的错误源。

有摩擦。解决问题。

YoJeff 于 2017-11-10

这取决于您的设置，我们在所有项目存储库中都忽略了此设置。但是，我们不会在暂存和生产堆栈专用存储库中忽略它。

因此，不应引入其他所有人想要的此功能，因为它会破坏您异常的存储库体系结构吗？

如果您要共享在docker-compose.yml提交的名称，则还可以提交.env （此文件仅用于docker-compose命令-别无其他）。

好吧，如果我的.env文件中唯一的东西是COMPOSE_PROJECT_NAME ，那么可以。但是它填充了许多其他我不想提交的_secure_变量。然后使用environment属性将它们导入docker-compose。这就是.env文件通常用于...

我仍然真的不明白这将如何破坏您的设置，因为在我的建议中，它仅覆盖从目录中获取的默认项目名称。并且如果您依赖于此（因为它是将目录提交到您的仓库中，而不是您的仓库被克隆到的目录），那么它将如何被docker-compose.yml设置覆盖（因为它也已提交）回购；您可以同时控制两种情况）？

joshuajabbour 于 2017-11-10

👍3

@ schmunk42您所说的是“我不需要新功能，因为其他原因我不再理解我的项目设置”。

认真吗这就是您的观点，为什么您希望其他需要此服务的人都不要这样做？

仅作记录：我也在这里。随时关闭问题。这里的讨论变得毫无意义。

mikehaertl 于 2017-11-10

因此，不应引入其他所有人想要的此功能，因为它会破坏您异常的存储库体系结构吗？

我很担心这可能会引入其他错误源。

好吧，如果我的.env文件中唯一的东西是COMPOSE_PROJECT_NAME，那么可以。但是它填充了许多其他我不想提交的安全变量。然后使用environment属性将它们导入docker-compose中。

使用secrets.env并将其通过env_file导入。
这将如何影响您的工作流程？

这就是.env文件通常用于的...

是的，但是我仍然认为问题在于docker-compose劫持了.env文件。

如果可以在名为docker-compose.env的文件中设置这些变量以及docker-compose.yml的顶级变量（如IMAGE_VERSION ）中使用的变量，那会怎么样？

直到现在我都不敢提出COMPOSE_COMMAND_ENV_FILENAME=.env -

我仍然真的不明白这将如何破坏您的设置，...

的确，它并不会立即中断，但这仅是我的第一点-并介绍了更多选项。

考虑使用多个文件-f docker-compose.A.yml -f docker-compose.B.yml ，假设A是您的项目，并依靠目录的项目名称（我们这样做，因为我们可以控制它！），而B是一个带有project_name: extra组额外服务，在包含.env文件的文件夹中测试时意外引入，该文件用COMPOSE_PROJECT_NAME=testing覆盖了项目名称。

但是现在，任何没有.env文件开始的项目都将被命名为extra 。 💥

我们在多个级别上合并文件，包括多个*.env文件，这是一个非常有效的用例。

schmunk42 于 2017-11-10

认真吗这就是您的观点，为什么您希望其他需要此服务的人都不要这样做？

警告：稍微偏离主题，但仍与docker相关...

@mikehaertl我真的很想知道您是否这样看;）

schmunk42 于 2017-11-10

嘿伙计，

我们在该主题中进行了热情洋溢的讨论（谢谢那些保持文明和亲切的人！），尽管我们仍然从根本上相信项目名称不属于Compose文件，但我们确实提出了我们认为以下PR是合理的中间立场：＃5378。也就是说，我们非常感谢您对此提供的反馈意见，以确保它能够满足您的需求。

这是要点：

您可以在Compose文件中添加x-project-name条目。默认情况下，此键被忽略。
当COMPOSE_X_PROJECT_NAME在您的环境（或设置.env文件），撰写将尝试恢复从项目名称x-project-name您撰写文件中的条目。
此选项的优先级低于COMPOSE_PROJECT_NAME和--project-name

很高兴解决与此有关的任何问题或疑虑。

shin- 于 2017-11-15

👎7 👍2

@ shin-因此必须将COMPOSE_X_PROJECT_NAME设置为1才能激活该功能？

如果是这样， COMPOSE_ENABLE_X_PROJECT_NAME可能也是要考虑的名称，但这只是我的2美分-无论如何我都不会使用它😄

schmunk42 于 2017-11-15

@ schmunk42任何“真相”值都可以使用，但是是的，就是这个主意。

shin- 于 2017-11-15

@matsaman很酷，感谢您提供有用且可行的反馈。

shin- 于 2017-11-15

您不是在告诉我们必须告诉最终用户设置变量或调用参数，而是在告诉我们必须告诉最终用户设置变量或调用参数。

老实说，而且确实不是一无是处，我无法想象您如何以任何方式将其视为解决方案。

matsaman 于 2017-11-15

@ shin-我将解释此更改不会产生任何有用的变化：

必须设置环境变量才能在撰写文件中查找项目名称，这与为项目名称本身设置环境变量的工作量，遗忘风险和便利性大致相同。

在组合文件中设置项目名称的全部目的是避免必须使用环境变量。您可以在项目名称环境变量中使用优先级，以使用户可以选择覆盖撰写文件中的项目名称。

nhooey 于 2017-11-15

👍6

我认为这是一个很好的解决方案，因为它不会破坏BC，而且会避免合并过程中引入错误（如上所述）。

schmunk42 于 2017-11-15

👎1

必须设置环境变量才能在撰写文件中查找项目名称，这与为项目名称本身设置环境变量的工作量，遗忘风险和便利性大致相同。

并非如此，您可以在您的环境中全局一次地进行此设置-无需在每个项目中都进行此设置。

schmunk42 于 2017-11-16

👎5 👍1

并非如此，您可以在您的环境中全局一次地进行此设置-无需在每个项目中都进行此设置。

我假设您是指在计算机上产生的所有外壳中的全局名称。如果这样做，则可能在完全不相关的项目中出现不良行为。当开发人员从版本控制中拉出项目而忘记设置环境变量时，也会引起混乱。

将项目名称包含在compose文件中的最重要目标之一是确保将与compose项目相关的每个变量都存储在版本控制中。

nhooey 于 2017-11-16

👍1

@nhooey @matsaman
它专门用于帮助在同一目录中具有多个撰写文件的用户，对于这些人来说， .env文件解决方案不是可选项。如果您的项目需要始终启用此功能，则可以轻松地在.env文件， .profile或其他可确保始终使用x-project-name位置进行设置考虑在内。

您不是在告诉我们必须告诉最终用户设置变量或调用参数，而是在告诉我们必须告诉最终用户设置变量或调用参数。

我们对此的主要关注始终是“最终用户”拥有自己的项目，并希望不惜一切代价避免名称冲突。在这方面，他们应该控制项目名称，而不是发行人。如果要向客户交付“交钥匙”项目，在关联的.env文件中设置COMPOSE_X_PROJECT_NAME同样很简单-老实说，我很困惑这其中的一部分。

shin- 于 2017-11-16

如果这样做，则可能在完全不相关的项目中出现不良行为。

你能举个例子吗？我仅在shell中设置COMPOSE_X_PROJECT_NAME就无法想到任何有害行为。

将项目名称包含在compose文件中的最重要目标之一是确保将与compose项目相关的每个变量都存储在版本控制中。

您为什么不能为此使用.env ？没有人禁止在版本控制中存储.env （是的，这并不常见）。

schmunk42 于 2017-11-16

一开始我们有.env 。您显然错过了整个谈话。

matsaman 于 2017-11-16

@matsaman您非常需要调低态度。自从您开始在此线程中发表评论以来，您一直很讨厌，它除了使谈话变得更糟之外，什么也没做。如果您在分享自己的想法时不敢与众不同，我们可以在没有您的意见的情况下做。

shin- 于 2017-11-16

👍3

为了澄清一些混乱

你已经可以做到了

以前，您可以使用环境变量来设置项目名称。新的环境变量不是名称，它是一个启用了功能的开关，可让您在撰写文件中设置项目名称。

我假设您是指在计算机上产生的所有外壳中的全局名称。如果这样做，则可能在完全不相关的项目中出现不良行为。

如果您原本是指“其他项目”，那么“那些没有组成的东西可能会读懂并破坏”，我认为这是不现实的。每个shell中都设置了很多环境变量。环境变量已正确命名为“ COMPOSE_X_”。

如果您的意思是“其他撰写项目”，那么我认为您实际上是在争论为什么需要此变量。如果默认情况下启用了此功能，那么依赖当前默认行为的任何人都会崩溃。

如果都不是，请进行说明。

当开发人员从版本控制中拉出项目而忘记设置环境变量时，也会引起混乱。

如果一个项目只能使用特定的项目名称，那么我认为还有其他问题。项目永远都不会只有一个名称。

我将其视为不将项目名称放入Compose文件中的另一个参数。如果项目名称在撰写文件中，则任何两个项目都可以使用相同的名称，从而导致冲突，这将破坏两个项目。该名称确实应该由知道其他正在使用的项目名称的开发人员设置。

dnephin 于 2017-11-16

👍2

不幸的是，由于我一年多前已经提到的原因，这对我也无济于事。

一个涉及环境变量的解决方案将要求用户首先需要知道如何制作它们。我知道似乎难以置信，但并不是每个人都在终端内部工作。同样，将.env放入存储库对我来说不是一种选择。

docker-compose的优点是up 。没有有关如何设置该呼叫的说明。

fiveanddone 于 2017-11-16

👍1

@fiveanddone

同样，将.env放入存储库对我来说不是一种选择。

您可以对此进行扩展吗？我完全听说您的技术知识较低，但是如果他们不打算与代码或环境交互，为什么在项目中包含.env文件会成为问题？

shin- 于 2017-11-16

@ shin-是的，没问题。

在某些情况下，我已将该文件包含在存储库中，但并非一直都有效。我的用例主要涉及Web开发，开发人员的技术知识可能相差很大。

.env包含在其他框架中使用的参数。 .env内部的一些变量是SMTP等外部服务的凭据。我们团队中的大多数开发人员都使用自己的.env文件将这些服务指向自己的终结点。如果.env不存在，

对于技术含量较低的开发人员，他们可能只想更改一些CSS，因此在没有.env文件的情况下，该应用程序可以正常运行。假设他们没有为每个项目文件夹命名相同。 :)

看起来似乎不多，但是当您与遍布全国的多个开发商和设计师合作时，越简单越好。

Docker使我的生活变得如此轻松，我对此项目深表谢意，但我可以将与此线程有关的挫败感与之联系起来。

fiveanddone 于 2017-11-16

@fiveanddone谢谢您的见识！因此，如果将.env文件称为docker-compose.env （或类似文件），那可以减轻您的担心吗？

shin- 于 2017-11-16

👍2 🎉1

@胫-

是的，这将适合我的用例。

fiveanddone 于 2017-11-16

env文件是否由Docker Compose自动加载？

如果没有，是否可以自动加载docker-compose.env ？

nhooey 于 2017-11-16

@nhooey如果将env文件命名为.env ，则会自动加载该文件。您还可以分别为每个服务指定环境文件。参见docs 。

AyushyaChitransh 于 2017-11-16

👍1

如果将env文件命名为.env，则会自动加载它。您还可以分别为每个服务指定环境文件。参见文档。

不能成为这里的挑剔者，但这是不正确的。恕我直言，这是整个话题的最大误解。

如果您不使用$$$ 则不会将任何

env_file: 
  - .env

要么

environment:
  - VAR_FROM_DOTENV
  - FOO=${ANOTHER_VAR_FROM_DOTENV}

是的， .env文件是自动加载的，但是无需进一步配置，它仅适用于这些Compose CLI环境变量。

我强烈支持默认情况下将其重命名为docker-compose.env甚至更好-该变量，因此可以在BC方式中使用，只需设置一个ENV-var。

schmunk42 于 2017-11-16

（感谢那些保持文明和亲切的人！）

我听到您的声音，并且我一定会感到内not，因为我并不总是保持镇定状态。抱歉一些评论有时确实使我开始...将对此有所帮助。

如果项目名称在撰写文件中，则任何两个项目都可以使用相同的名称，从而导致冲突，这将破坏两个项目。

我们对此的主要关注始终是“最终用户”拥有自己的项目，并希望不惜一切代价避免名称冲突。在这方面，他们应该控制项目名称，而不是发行人。

@ shin-这听起来很普遍， docker-compose.yml始终是项目的一部分，并位于项目存储库中。我说那不一定是真的。我们中有些人不共享docker-compose.yml而是希望保留其本地版本以及本地自定义设置（例如，开发设置，试用版等）。

关于“避免名称冲突”：在文件系统级别上，我们现在有了一种（IMO）方式更严重的名称冲突： .env是项目用来定义其名称的通用名称应用特定的设置。除非开发人员确实想要这样做，否则不应使用docker设置对其进行污染。但是这个决定应该留给开发者。

这是一个建议：如何为项目名称添加其他两个选项并在.env的V4中弃用docker-compose.yml ？一个是project_name中的docker-compose.yml ，另一个是文件.dockerproject ，其中仅包含名称，并且永远不应提交给存储库。它应该是本地文件。

这是我对优先级的建议（最高优先）：

-p CLI参数
.dockerproject文件
project_name中的docker-compose.yml （应避免，如果docker-compose.yml与项目一起分发）
来自环境的COMPOSE_PROJECT_NAME
COMPOSE_PROJECT_NAME的.env （已弃用）
目录名

这样，即使有人将其硬编码在分布式docker-compose.yml最终用户仍然可以始终覆盖.dockerproject的项目名称。

更新：我也可以使用.dockerenv或docker.env代替.dockerproject 。但是它应该具有更高的优先级来解决该问题，这里有些需要重写docker-compose.yml硬编码项目名称。

mikehaertl 于 2017-11-16

👍2 👎1

大家好，

首先，感谢@dnephin和@

我已针对以下用例验证了测试项目上的PR 5378： A default project name defined by the project, that can be checked in （https://github.com/docker/compose/issues/745#issuecomment-282858900）。为此，我制作了一个git repo来说明不同的可能性： https :

我发现PR＃5378部分覆盖了用例。问题在于该解决方案需要COMPOSE_X_PROJECT_NAME env变量。可能的解决方案：

将env变量保留在项目的文件夹中。我尝试了.env文件，但是当从另一个位置调用docker-compose时它不起作用（请参阅命令示例，撰写文件）
全局定义COMPOSE_X_PROJECT_NAME（.profile或等效文件）。那可以用，但是不能在项目中指定，即它不是我们用例defined by the project, that can be checked in的解决方案
还有其他选择吗？

希望我设法说明了这里解决的用例。

尊敬的维护者，请考虑PR＃5369如何解决用例，该PR＃5369在docker-compose文件中引入了可选的project_name属性。此属性的优先级较低，但与环境或工作目录无关。

estarter 于 2017-11-16

还有其他选择吗？

有此选项docker-compose --project-directory <PATH> （指定备用工作目录）。还应该与.env文件一起使用。

schmunk42 于 2017-11-16

要将另一个细微的用例添加到组合中：
在我的用例中，我有两个存储库，一个用于主项目（用于构建/部署），另一个用于devops（包含Dockerfile，docker-compose.yml等）。
在我们当前的设置中，主项目存储库位于根目录./，而devops存储库则检出到子目录./devops/

在此设置中，无法使用.env文件，因为它必须是：

放置在执行docker-compose命令的文件夹中（当前工作目录）。
（文件参考）

哪个无效，因为它被调用为： docker-compose -f devops/docker-compose.yml
当然，我们可以在此处添加-p参数，这是我们当前正在使用的参数，但是如上所述，它很容易发生人为错误。

如果可以从docker-compose.yml所在的目录中读取.env（或建议的docker-compose.env）文件，则定义项目名称对我来说将是有效的。

在docker-compose.yml中使用env_file指令不起作用，因为这些env var仅应用于容器内部，而不应用于容器的创建。

最终，我的目标是使与devops相关的文件保持独立，这种方式不会污染我的实际项目代码库，但仍可以与该库并行访问/运行。

benjaminbradley 于 2017-11-16

👍1

有这个选项docker-compose --project-directory（指定备用工作目录）。还应该使用.env文件。

@ schmunk42可能是一个不错的选择，但是--project-directory不适用于.env文件。我尝试如下，.env文件已被忽略（项目文件）：

docker-compose -f PR_5378/docker-compose.yml -f PR_5378/docker-compose2.yml --project-directory PR_5378 down

estarter 于 2017-11-16

展望未来，我将以建设性的方式删除对对话无用的评论。我对与孩子互动没有兴趣。

shin- 于 2017-11-16

👍3 😕1

具有可设置的.env名称
使用环境变量指定要使用哪个.env文件的问题在于，它本质上是循环依赖项。我们必须在解释环境变量的方式中引入一个例外，尽管这是明智的，但本质上是违反直觉的。

在.env本身上
到目前为止，很明显， .env名称已由许多软件和框架使用，通常并不意味着要在版本控制中提交。我们对做出重大更改非常敏感，但是如果前者不存在，我们可以引入一个替代名称（例如docker-compose.env ），并在.env文件中使用后备名称，目的是它可能与其他用户共享。

在将project_name到Compose文件中
我们已经多次重申了我们的立场-出于我们反对进行更改的某些原因，请参阅Daniel的最新评论。不是说这很困难。不是我们没有考虑过。我们花了很多时间来评估它，并且我们觉得项目的质量会因此而遭受损失，以至于不能证明以这种形式添加它是合理的。实际上，＃5378可能是我们可以使它以选择加入和向后兼容的方式进行工作的最佳让步（编辑：当然，我愿意接受在这些参数内改进该建议的建议）

在--project-directory
有点切线，但是我知道这个选项现在有点破了。回想起来，我宁愿完全不添加它，因为它带来的问题多于解决的问题。我将花一些时间来看看它是否可修复，但是它有很多奇怪的边缘情况，因此确实不可靠。

综上所述，是否有人对docker-compose.env +＃5378不是一个令人满意的解决方案？我知道这可能不是您最喜欢的解决方案，但我想知道它是否在做出您可以应付的合理让步。

shin- 于 2017-11-16

🎉4

除了开玩笑...

我仍然不明白Daniel的最新评论是如何与“项目质量”相关的。此外，通常的经验法则是，向字典添加密钥绝不会导致向后兼容性破坏。在某些情况下，程序员以某种方式实现事情并非如此，但我离题了。

我认为想要project-name （或其他）字段的阵营是合理的，因为项目的“名称”对于工具的许多方面都是至关重要的。该营地中的人们可能只想在石头上写下这个名字，以避免出现诸如环境变量或标志之类的临时解决方案所带来的问题。

我希望这是建设性的。

nixpulvis 于 2017-11-16

@estarter我认为这是一个错误，也许值得为此

实际上，我希望它可以与目录PR_5378的.env文件一起使用：

docker-compose --project-directory PR_5378 -f docker-compose.yml -f docker-compose2.yml down

schmunk42 于 2017-11-17

在将project_name添加到Compose文件时

@ shin-似乎已经做出了决定。但是我仍然尝试了解背景。我之前曾问过这个问题，但从未得到答案（这就是为什么讨论让我感到烦恼的原因之一）。

您能否帮助我理解，为什么我们在container_name有network docker-compose.yml ？第一个也可能是潜在冲突的根源。后者是高度主机特定的。按照您的逻辑，这两个（和其他）也不应该存在。我看不到与project_name的区别。

请，不要再忽略这个问题。

mikehaertl 于 2017-11-17

👍6

@ michael-k您是说project_name与container_name吗？如果您这样说，那么我想告诉您，一个项目可能包含多个容器。还是我误会了你？

对于network ，它不一定是特定于主机的。在许多情况下，项目需要一个中央隔离的网络，其中一个容器与另一个网络进行交互。其配置存储在docker-compose.yml 。

AyushyaChitransh 于 2017-11-17

👍1

@AyushyaChitransh你误会了。问题是：为什么不允许container_name ， network和docker-compose.yml而不允许将project_name放在其中？它们都具有相同的潜在冲突或不应共享的主机特定配置。

mikehaertl 于 2017-11-17

👍2

@aanand我知道这个机会。另外，关于容器名称的信息可能相同，但是我们确实有机会在撰写文件中设置容器名称，对吗？

是的，但是我不认为添加一个好主意。

来自相关讨论在docker-compose file中指定网络名称。

schmunk42 于 2017-11-17

👎1

@estarter我认为这是一个错误，也许值得为此

@ schmunk42我看到维护者意识到这一点-请参阅Joffrey的注释中的On --project-directory以及＃4709，＃4933和＃4841

实际上，我希望它可以与目录PR_5378中的.env文件一起使用：
docker-compose --project-directory PR_5378 -f docker-compose.yml -f docker-compose2.yml down

您假设--project-directory影响-f参数。
实际上并非如此，此命令给出IOError: [Errno 2] No such file or directory: u'./docker-compose.yml'

--project-directory不会影响-f非常好-否则想象一下使用--project-directory和多个docker-compose文件都在不同目录中将是一场噩梦。

estarter 于 2017-11-17

对于我认为已解决的问题进行了如此多的讨论，我感到非常惊讶。

这是我惯常看到的优先顺序：

硬编码
cli选项
环境
project.rc
健全的默认

对于project_name我们目前没有选项＃1或选项＃4。这是人们面临的基本问题，并且似乎很容易以向后兼容的方式解决。

我们似乎对纯净性有哲学上的争论，这可能无济于事。另一方面，使用非常常见的OSS级联配置方案非常有帮助。

thedeeno 于 2017-11-22

我们似乎对纯净性有哲学上的争论，这可能无济于事。

确实不是这个目的。从一开始，我们就非常清楚关于在Compose文件中定义项目名称的立场。

但是让我对此保持透明。这将永远不会在docker-compose 。如果这是您愿意接受的唯一解决方法，那么您将不得不执行OSS流程，即分叉项目并自己完成。该代码可用，并与非常宽松的许可证共享。

您能否帮助我理解，为什么我们在docker-compose.yml中有container_name甚至网络？第一个也可能是潜在冲突的根源。后者是高度主机特定的。按照您的逻辑，这两个（和其他）也不应该存在。我看不到project_name的区别。

对于container_name ，该选项在项目生命周期的很早就引入了。正如@ schmunk42所指出的，如果我们要再做一次，那肯定不在规范范围内。它一直被滥用，并且多年来一直是用户无数问题的根源。
至于network ，我不完全确定它与您的想法相比如何？

shin- 于 2017-11-22

👍1

那我提到的选项4呢？我看到一些关于为本地目录特定设置引入.docker-compose的讨论。这比引入_x_环境标志（仍然需要环境管理）更可取（imo）。

就像这样：

# <my-project-dir>/.docker-compose
project_name: foobar

以上与环境变量选项不同，在优先级列表中较低。

这很好地解决了我的用例，并从列表中剔除了另一个标准配置路径。

thedeeno 于 2017-11-22

@thedeeno在我们看来， COMPOSE_PROJECT_NAME .env文件中的COMPOSE_PROJECT_NAME已经完成了此任务（优先级顺序与大纲中的顺序相同）。但是，我们听说您对.env的名字选择不佳，这就是为什么我们考虑将docker-compose.env作为替代方法。那对你有用吗？

shin- 于 2017-11-22

👍2

我们认为，.env文件中的COMPOSE_PROJECT_NAME已经完成了

@ shin-这是我们不同意的地方。我不这样认为。

我个人很喜欢我们获得.env文件的来源。这是放置本地机密和其他本地硬件特定配置的非常传统的地方。

这对于协助number 3以上基于环境的配置非常有用。

当我们不希望环境拥有项目名称时，它不会给我们提供逃生阴影（ number 4 ）。

就我而言，我们的开发人员将各自拥有自己的.env文件（不是VC）。它包含用于注入docker-compose.yaml秘密。喜欢这个。

但是，我们不希望开发人员控制项目名称，因为它与某些工具紧密关联。由于.env不在版本控制中，因此我们必须让开发人员使用这种方法手动设置COMPOSE_PROJECT_NAME ；这是一件事，不像其他事，因为这不是秘密。

因此，遗憾的是，仅更改.env的默认源路径对我们没有帮助。我们实际上很喜欢.env是自动来源的。我们只是不想以这种方式指定项目名称。

thedeeno 于 2017-11-22

👍4 😕1

我将通过实践展示一个用例：

我使用.env文件指定图像版本，并避免奇怪的sed / awk / perl /任何解析，我只是覆盖CI中的值：

    echo APP_VERSION=$CI_COMMIT_REF_NAME > .env
    docker-compose pull
    docker-compose up -d

稍后在docker-compose.yml ，图像指定为：

    image: my.registry.example.net/app:${APP_VERSION}

现在，如果我需要更多此类变量，则需要进行一些解析，除非支持多个.env文件。

因此，也许还添加了“目录”支持，例如： docker-compose.env.d/*或.docker-compose.env.d/*或docker-compose.d/* 。

但由于这样的glob会立即造成匹配编辑器备份的问题（ *~ ， *.bak ），因此最好使用一些扩展名： docker-compose.env.d/*.sh

...但是再说一次，也许只是使其在docker-compose.yml可配置， .env文件，否则会带来鸡鸡蛋问题？我不知道配置解析器如何工作:)

glensc 于 2017-11-22

👎1

有点题外话，但COMPOSE_PROJECT_NAME env不允许完全控制前缀，它仍然会被剥离以匹配A-Za-z0-9_ ...我想在前缀中使用- 。（我现在找不到我在哪里报告此问题，但无法解决此问题）

允许使用docker本身所限制的相同字符是合乎逻辑的。

glensc 于 2017-11-22

👍3

@glensc这是用于管理环境的大量基础结构。我个人不认为这是docker-compose的责任。

我看到的其他项目唯一要做的就是自动获取.env

thedeeno 于 2017-11-22

@glensc @thedeeno因此，理想情况下，我们将有两个*.env文件，一个文件打算与其他用户共享，一个文件保持私有，当两个文件都定义相同的var时，后者将覆盖前者？

上周，我在评论中提到了可配置的.env名称。

shin- 于 2017-11-22

拥有一个公开的docker-compose.env （同时仍然自动采购私有的.env ）对我们来说很好！

我们将其视为rc文件，并提交给其源代码管理。

thedeeno 于 2017-11-22

我认为拥有公共/私有环境文件可能会解决这里提到的大多数用例。如果在项目名称中也允许- ，那就太好了。

glensc 于 2017-11-22

@thedeeno @glensc您能否给出一个用例，其中需要一个私有ENV文件来覆盖公共文件中的值？

机密不应该在docker-compose.env ，因为它们不会自动转发到容器。您仍然可以使用.env文件，然后对其进行任何操作。但这让我混淆了docker-compose和堆栈中的容器。

schmunk42 于 2017-11-23

@ schmunk42我没有用例，所以在那里我不会有太多帮助。我只需要将project_name提交到版本控制即可。 docker-compose.env解决了这个问题。

不确定我是否遵循您的第二段。我们使用.env作为秘密，然后将它们手动注入docker-compose.yaml 。

thedeeno 于 2017-11-23

@ schmunk42 https://github.com/docker/compose/issues/745#issuecomment -346491062

只是因为只为image值定义${variables}地方似乎是.env文件。

glensc 于 2017-11-23

@glensc同意！

但是，我建议使用docker-compose.override.env使其与yml文件的当前替代功能对齐。

docker-compose.env
docker-compose.override.env
docker-compose.override.yml
docker-compose.yml

不确定我是否遵循您的第二段。我们使用.env作为秘密，并将其手动注入docker-compose.yaml中。

@thedeeno我假设您正在这样做：

environment:
  - ${SECRET_VAR_FROM_DOTENV}

docker-compose.override.env也应该可行。或者您可以这样做：

env_file:
  - .env

schmunk42 于 2017-11-23

您是否建议删除.env以支持更具体的docker-compose
路径？

如果我们跳过.env的自动来源，将会对我的网站产生负面影响
团队的工作流程。我们依靠此文件进行其他工具。我们最终会
将我们的秘密分为两个（.env和您建议的另一个文件）
如果docker-compose停止查看.env，则放置该位置。

2017年11月23日，星期四，上午1:15 Tobias Munk [email protected]
写道：

@glensc https://github.com/glensc同意！
但是相反，我建议使用docker-compose.override.env将其与
yml文件的当前替代功能。
docker-compose.env
docker-compose.override.env
docker-compose.override.yml
docker-compose.yml
不确定我是否遵循您的第二段。我们使用.env作为秘密，
手动将它们注入docker-compose.yaml中。
@thedeeno https://github.com/thedeeno我假设您正在这样做：
环境：
$ {SECRET_VAR_FROM_DOTENV}
docker-compose.override.env也应该可行。或者您
能做：
env_file：
.env
-
您收到此邮件是因为有人提到您。
直接回复此电子邮件，在GitHub上查看
https://github.com/docker/compose/issues/745#issuecomment-346538315或静音
线程
https://github.com/notifications/unsubscribe-auth/AAFIdxtbI7y3wW2TFa401Go6Msj0gC74ks5s5Q1vgaJpZM4DLBNs
。

thedeeno 于 2017-11-23

您是否建议删除.env以支持更具体的docker-compose
路径？

不一定，对于BC， docker-compose仍然可以查看.env如果找不到其他），与一次fig.yml 。尽管确定以下情况可能很棘手：

.env
docker-compose.env

.env
docker-compose.override.env

.env
docker-compose.env
docker-compose.override.env

.env在最后一种情况下不会使用，但是我不确定如何处理前两个，因为有些用户会使用.env作为替代，而另一些会作为后备。

schmunk42 于 2017-11-23

对我来说，在所有情况下都应使用.env。这是一个具有特殊含义的文件
在更广泛的生态系统中。

在第三种情况下，它只是优先级最低的文件。

我需要的只是一种将项目名称提交到源代码管理的方法。我不
特别关心更复杂的级联环境
管理。我实际上更希望这个项目名称策略没有什么可做的
使用环境变量。

如果配置文件不在桌面上，则有一种方法可以提交我的
您正在使用的带有该环境级联的project_name，我会很乐意使用它
虽然！

2017年11月23日星期四，上午1:31 Tobias Munk [email protected]
写道：

您是否建议删除.env以支持更具体的docker-compose
路径？
不一定，对于BC docker-compose，如果
找不到其他，与一次使用fig.yml相同。虽然可能是
难以决定以下情况：
.env
docker-compose.env
.env
docker-compose.override.env
.env
docker-compose.env
docker-compose.override.env
.env不会在最后一种情况下使用，但我不确定如何处理
到前两个，因为某些用户将使用.env作为替代，而其他用户则将
倒退。
-
您收到此邮件是因为有人提到您。
直接回复此电子邮件，在GitHub上查看
https://github.com/docker/compose/issues/745#issuecomment-346539891或静音
线程
https://github.com/notifications/unsubscribe-auth/AAFId95kZQISIWp488JyPQOtGJju0OPbks5s5RFbgaJpZM4DLBNs
。

thedeeno 于 2017-11-23

👍2

至于网络，我不完全确定您的想法如何？

@胫-

services:
    web:
        build: ./
        networks:
            - my_project_network_on_my_localhost
networks:
    my_project_network_on_my_localhost:
        external: true

猜猜我做错了，因为我从未将docker-compose.yml提交给我的仓库。它始终包含高度主机特定的设置。它在开发生产中可以具有完全不同的内容。

mikehaertl 于 2017-11-23

我是“ 4 project.rc”的粉丝，尽管我可能会使用docker-project.yaml之类的格式，而不是其他格式。这正是原始问题所描述的。就我而言，有关将项目名称放入撰写文件的任何讨论都应该放在单独的问题中。

我需要的只是一种将项目名称提交到源代码管理的方法。

我仍然不明白这一点。应该没有理由要求一个单独的硬编码项目名称。如果有外部工具期望名称一致，那么为什么该工具在调用docker-compose之前不设置项目名称？

my_project_network_on_my_localhost在我看来错了。为什么在外部网络中需要项目名称？它不需要与撰写项目名称匹配。

dnephin 于 2017-11-23

my_project_network_on_my_localhost对我来说似乎是错误的。

这只是一个例子。我的本地开发计算机上的网络设置与生产服务器上的网络设置不同。我的docker-compose.yml许多其他设置也经常与生产环境不同，例如，我在其中定义了实用程序容器，用于构建项目特定的内容或维护数据库等。

据我了解，最初， docker-compose （或更好的fig ）背后的主要思想是，将所有这些冗长的docker命令行选项组织起来，以在简单的yaml文件。这就是为什么感觉如此怪异，以至于只剩下一个选项。但是我似乎以某种方式错过了这不再是背后的主要思想。

mikehaertl 于 2017-11-24

我的docker-compose.yml中的许多其他设置通常也与生产环境不同，例如，我在其中定义了实用程序容器，用于构建项目特定的东西或维护数据库等。

我们在这里有相同的工作流程。在我们的案例中，“常见”的docker-compose定义几乎没有任何意义，但这是在开发，测试，登台和生产之间真正共享的唯一东西。
开发设置的主要部分在单独的文件中定义，自动合并通过.env文件完成。测试设置相同。

因为在我们的案例中它位于文件夹中，所以我们可以执行以下操作

(cd tests && docker-compose up -d)
(cd tests && docker-compose ps)
(cd tests && docker-compose run php codecept run)

用于测试...或这个

(cd production && docker-compose logs -f --tail 100)

进行生产（奖金：您可以在生产中定义DOCKER_HOST以指向另一台机器，但只能使用docker-compose ）。

但是，是的，它是一个文件夹，而不是文件-并需要在两个位置使用cp .env-dist .env进行工作，否则它将因无效的撰写文件而失败。实际上，我只是想分享这个恕我直言的简洁工作流程。

schmunk42 于 2017-11-24

我仍然不明白这一点。应该没有理由要求一个单独的硬编码项目名称。如果有外部工具期望名称一致，为什么该工具在调用docker-compose之前不设置项目名称？

@dnephin有原因。

是的，有工作环境。要求是使其更加方便和可预测。

这是一个使用硬编码项目名称的示例：traefik的docker配置默认以以下格式为容器创建主机规则： <service>.<project>.<domain> 。这种格式不容易更改。对于我们的开发人员来说，将相同的fqdns用于我们的docker-compose服务非常有益。如果我们可以使用零配置设置，那就太好了，因为它是保证一致性的唯一方法是：a）强制他们为克隆使用特定的目录名称b）手动指定traefik的规则。都糟透了。

这是另一个：引用使用docker-compose构建的图像。如果我们不能保证项目名称，那么我们就不能保证这些图像名称，也不能自信地引用它们。当然，我们可以为每个定义对image_name进行硬编码，但坦白地说，这是多余的，因为我们想使用Convention_，但仅担心选择使用不同文件名的开发人员在我们的工具中会遇到非常令人惊讶的故障。

thedeeno 于 2017-11-25

👍6

伙计们，如此多的讨论...这是什么状态，我可以在.docker-compose文件中设置默认项目名称吗？
还是在该主题中需要更多讨论？

Hronom 于 2018-03-07

👍20 😄6

与其他工具（例如PyCharm）一起使用时，将项目名称存储在docker-compose.yml文件中非常有意义。

最好将其存储在相同的YAML文件中，但如果需要可以覆盖它。

askoretskiy 于 2018-03-19

👍28

我认为此问题的核心来自于以下事实：默认项目名称只是（应该说_naively_？）作为当前目录的基本名称。这有效地将文件系统名称空间（分层）压缩到一个平面，这由于名称冲突而成问题。例如，这会导致在~/fooproject/master和~/barproject/master运行服务的人员遇到问题。

我确实认为项目名称并不重要。因此，使docker-compose变得可靠的一种方法是基于完整路径生成项目名称（即home_flaviovs_fooproject_master ）？

不过，我喜欢这个持久的想法。能够将项目名称提交给Git是一个常见的用例。也许在.env之前读取.env.default文件是一个简单的解决方案（BTW也将处理长期存在的＃210）？

flaviovs 于 2018-04-08

👍4

我通过用自己的函数包装docker-compose二进制文件解决了这个问题，因此我可以在任何地方调用该函数。这将加载.env文件，并在任何地方使用正确的docker-compose文件。

显然，您可以将其扩展为每个项目或某些功能。我认为可能有缺点，但我还没有发现。

DEFAULT_DOCKER_COMPOSE=~/my-project

function dcompose() {
    pushd $DEFAULT_DOCKER_COMPOSE &> /dev/null;
    /usr/local/bin/docker-compose $@;
    popd &> /dev/null;
}
## maintain auto complete
function _dc {
    pushd $DEFAULT_DOCKER_COMPOSE &> /dev/null;
    _docker_compose;
    popd &> /dev/null;
}

complete -F _dc dcompose

helmus 于 2018-04-18

我在图片冲突方面遇到问题，而且我无法在docker-compose.yml中设置project_name看起来很不可思议，因为它看起来非常合乎逻辑且正直。实际上，首先从项目文件夹中获取名称是一个坏主意。在许多情况下，项目文件夹可能类似于/ home / project1 / repository，/ home / project2 / repository等，在这种情况下，docker生成了与repository_app类似的图像名称。

vedmant 于 2018-05-10

@vedmant您可以在docker-compose.yml设置图像名称，只需使用image和build 。

schmunk42 于 2018-05-10

👍1

那么...现在如何用同名文件夹上的项目分隔？

docker-compose -f /foo/bar up -d
docker-compose -f /foo/foo/foo/bar down

bscheshirwork 于 2018-05-29

👍2

也许这已经被提出。但是为什么不对version: 4进行重大更改并添加一些新关键字以允许从docker-compose.yml设置项目名称呢？

glensc 于 2018-07-06

👍10

我的.docker-compose / project-name不起作用...
-项目名称有效

MyJoiT 于 2018-07-31

我也想在docker-compose.yml中设置项目名称。

我的用例是，我有一个docker-compose.yml文件，其中包含一个Web应用程序和一个Postgress数据库服务。
我还想要单独的docker-compose.yml文件用于临时任务-基本上描述了我想用docker-compose Orchestarte的临时任务。这些临时任务需要利用与主项目中相同的服务/网络/卷。

我想与docker-compose协调的临时任务的示例可能是。将数据迁移到postgress数据库中。与docker-compose协调工作很有用，因为该任务可能涉及与当前服务一起拆分其他服务和卷，网络等，以完成该任务。

因此，为了实现此目的，我可以创建一个单独的docker-compose.adhoctask.yml文件来表示该任务，以便仅在需要时才可以按需运行该任务。因为它与原始docker-compose文件位于同一目录中，所以默认情况下它具有相同的项目名称，因此可以访问相同的网络，卷等？和东西的作品。

但是，当我不希望这个临时任务yml文件与主docker-compose.yml驻留在相同的顶级目录（甚至相同的存储库）中时，就会出现问题。例如，也许我想将临时任务docker-compose.adhoc.yml放在一个子文件夹中，并将该任务需要的DOCKERFILE和资产很好地隔离/分组，这是它自己的关注点。一旦将其移动到子文件夹，它的项目名称就不再匹配。这意味着它不再有权访问主项目中定义的相同卷/网络等。

如果我可以在docker-compose.yml和docker-compose.adhoc.yml指定projectname -那么我可以根据需要构造它们（甚至将它们放在单独的仓库中）并且仍然执行它们而不必不断指定其他命令行参数或切换环境变量。

dazinator 于 2018-08-07

👍10

对我来说这是一个真正的问题，因为它会导致命名冲突

我在结构中有几个项目

/company
    /ab   # project prefix
        /backend   # actual project
        /webapp
    /cd
        /backend
        /webapp

现在，当我在一个项目中启动docker-compose时，它将创建网络backend_default并为未使用backend_显式命名的容器添加前缀。现在，如果我要启动另一个项目，返回正确的文件夹并首先运行docker-compose down以防止冲突-否则它将在同一网络中启动新容器，然后在关闭它们时，它将抱怨orhans（如果没有）。

fprochazka 于 2018-08-13

👍5

对我来说也是一个问题。我有多个项目，并使用docker-compose在单台机器（每个分支的机架）上进行动态演示。

/project-1
    /dev # docker-compose.yml inside
    /master # docker-compose.yml inside
    /feature
        /new-feature # docker-compose.yml inside
/project-2
    /dev # docker-compose.yml inside
    /master # docker-compose.yml inside

因此，“主”和“开发”在项目之间是冲突的。一个.docker-compose文件可以解决这个问题。

simplesmiler 于 2018-08-24

👍1

@simplesmiler冒着重蹈覆辙的危险， .env已经解决了这个问题。

shin- 于 2018-08-24

@ shin- .env通常用于不在版本控制中的机密。

@simplesmiler想要的是一种将项目名称提交到版本控制_的方法，同时将.env保留在版本control_之外。

据我所知，仍然没有办法轻松地做到这一点。

thedeeno 于 2018-08-24

@thedeeno并不是他们的帖子所说的。你们一起工作吗？如果不是，我们不应该假定别人的用例超出了明确编写的用例。

shin- 于 2018-08-24

我们不在一起工作。那是我对他们问题的解释。完全公平地说，我可能是错的，而且我可能是在假设。

我希望我们能一起工作，以便我们可以喝杯咖啡。我希望你不要认为我在这里很混蛋。

也许我只是错误地记住了这个线程：是否有一种方法可以将项目名称提交到版本控制，同时忽略.env ？

thedeeno 于 2018-08-24

有没有办法将项目名称提交到版本控制，同时保持.env被忽略？还是这仍然是缺少的功能？

不是现在。正如我几个月前提到的^ 1，计划是将docker-compose.env作为可包含在版本控制中的辅助环境文件。它已经使优先事项清单有所下滑，但我希望能尽快解决。

1 / https://github.com/docker/compose/issues/745#issuecomment -345054893

shin- 于 2018-08-24

👍4 ❤2 😕2

这真是个好消息！接受公关吗？

thedeeno 于 2018-08-24

很久以前我放弃了希望，但让我们再尝试一次：

我认为这里的许多人仍然无法理解为什么我们被迫为此设置第二个文件。

据我了解，这里有些人中断了他们的项目设置。但是对于该线程中的大多数而言，这不是问题。那么，这几个人又如何对所有缺少此功能的其他人施加此限制呢？为什么我们不能有几个选项来配置名称，然后再决定呢？

从逻辑上讲，这甚至没有任何意义： docker-compose.yml缺少此设置非常明显，以至于我什至不敢相信在手册中寻找该选项时会丢失。您几乎可以在其中配置设置的每个其他方面。对我来说，这是配置逻辑中的明显突破。

mikehaertl 于 2018-08-25

👍24 😄1

我认为有人可以说，（几乎） docker-compose.yml中的所有设置都由项目名称“限定范围”。

schmunk42 于 2018-08-28

如＃4841中所建议，用于指定要使用哪个.env文件的选项（即--env-file ）应该非常有用。

roipoussiere 于 2018-08-28

👍2 ❤1

@roipoussiere参见https://github.com/docker/compose/issues/4841#issuecomment -414543951

schmunk42 于 2018-08-28

谢谢@ schmunk42。
但这意味着我必须创建一个类似以下的层次结构：

.
├── project_a
│   ├── .env
├── project_b
│   ├── .env

而不是像这样更简单的东西：

.
├── a.env
├── b.env

roipoussiere 于 2018-08-28

👍4

是的，另请参阅https://github.com/docker/compose/issues/745#issuecomment -345054893-您可能需要在新窗口中将其打开，因为有时它会隐藏在这里：nerd_face：

schmunk42 于 2018-08-28

我第二次提出了--env-file提案。为此做了一张票。如果需要此选项，请去喜欢它。

nickredmark 于 2018-09-06

👍2 ❤1

因此，我只阅读了关于此错误/功能的一些评论，而讨论仍在继续且开放，这一事实使我得出这样的结论：自最初开放以来已经有4年了，仍然没有解决方案？我们可以做出部分决定然后继续前进吗？

arvera 于 2018-12-19

👍7 😄4 ❤2 🎉2

我承认，我还没有读完整个问题以及所有相关问题，但是围绕该主题存在一些有趣的问题，这使问题比乍看之下更加复杂。例如，众所周知， .env通常用于秘密值，因此通常从版本控制中忽略它。

但是，假设您正在使用Stripe，这恰好允许您拥有测试密钥和实时密钥，也就是AKA。 2组键可使用。在开发中，使用测试键非常普遍，而在生产中，最终将使用实时键。

这自动意味着您不能单独使用.env来处理秘密值，因为在每个环境中您将拥有不同的键，并且您不必在运行文件之间切换文件中的值开发人员或产品中的应用程序（那会很疯狂，而且容易出错）。

您可能最终要做的是创建.env和.env.prod文件，并从版本控制中忽略这两个文件。这样，您可以在开发中使用测试/开发键，然后在开发撰写文件中使用env_file进行引用。

但是随后在生产中，您在生产撰写文件中同时引用了.env和.env.prod 。

但是，您看到了这一切吗？现在，Docker Compose不允许您使用可选的env_file文件。如果文件不存在，那么当您尝试运行Docker Compose时，Docker Compose就会崩溃。

因此，如果您打算将其与env_file一起使用，则最终您将自动需要.env文件存在，并且这也不限于Stripe。许多Web框架都有某些特定于环境的设置，但会在开发和生产中发生变化（例如，在Flask中SERVER_NAME ）。

因此，这意味着我们仅限于提交给版本控制的.env_example文件，并且期望最终用户将该文件重命名为.env ，然后该文件内部将包含我们的老朋友COMPOSE_PROJECT_NAME 。

现在提出了问题。我们实际上是否需要设置项目名称的另一种方法？我不相信我们这样做，但是我相信设置自定义项目名称在任何项目中都是一个好主意，或者至少是文件夹名称以外的其他名称，因为您很容易遇到名称冲突。

nickjj 于 2018-12-30

请问这个问题在某些路线图上吗？

landsman 于 2019-01-06

👍1

这种情况的用例是在您的项目具有多个docker-compose文件的情况下修改COMPOSE_PROJECT_NAME（例如，一个用于dev，test，也许一个基础，也许一个本地测试等）的文件。最多2个彼此不同的环境。

在我们的情况下，我们可以通过在makefile中创建COMPOSE_PROJECT_NAME来解决这种docker-compose限制。

我想从撰写yaml本身中看到此可配置的内容。

cdobbyn 于 2019-02-19

👍8

这还开放吗？哦，我的上帝...

brunobertechini 于 2019-03-16

😄22 👀9 🚀5

已订阅。我还希望能够在撰写yaml文件上设置项目名称。

这是永远的🤦

lopezator 于 2019-06-06

👍21 ❤3

拥有此功能将非常有帮助

F-Yousri 于 2019-06-12

在我正在研究的项目中，此功能将非常受欢迎

HairyMike 于 2019-07-11

👍2

好的，所以从这个长线程中，我们可以得出结论，项目名称将不在docker-compose.yml文件中，因为主要开发人员反对此名称，并且不会合并任何此类拉取请求。

因此，我们能否回到最初的提案，然后在本期的顶部进行讨论：使项目名称持久化。对我来说，使用文件.docker-compose或目录.docker-compose听起来不错。但是，如果我们最终能够在实现该目标方面取得一些进展，那就太好了。

terjebraten-certua 于 2019-08-02

我将ENV变量添加到该替代列表中。

amancevice 于 2019-08-02

👎3 👍1

所有分歧的一个根本原因是该线程/问题是，对于许多人来说，如果它在ENV变量中，则它不起作用。他们希望能够将其提交到存储库（当然，可选，标准的建议是不提交。）

terjebraten-certua 于 2019-08-04

👍4

拥有ENV而不是yaml的内容与在不同项目之间共享yaml文件的理念相矛盾。实际上，它已正式记录在案： https ：//docs.docker.com/compose/extends/（例如，请参阅“示例用例”）。如果您使用单个基本yaml文件，然后覆盖dev，test和prod的文件，而上帝知道其他事情，那么以相同的项目名称运行它或通过ENV / cli设置项目名称是没有意义的。它只会创建N * N个组合，而N个有效。

timanovsky 于 2019-09-02

我遍历了其中的一些讨论，并看到了很多人希望在YML文件中配置项目名称的评论。但是，没有一项评论可以解释为什么不应该这样做。这些讨论可以追溯到很长一段时间。

当某人正在寻找一种易于使用的解决方案并发现没有一种简单的方法来设置项目名称时，该名称不需要用户仔细注意执行的命令行（这与您所使用的工具的核心思想相竞争）传递up并神奇地启动完整的服务器集群）-我很震惊，这是一个悬而未决的问题。如果对它为什么有问题或实施存在一些明确的解释，我将很感兴趣。

artnaseef 于 2019-09-13

👍10

一个不错的解决方案是在container_name属性中使用占位符（以及其他动态命名，例如音量，网络等）。

services:
  my_service:
    container_name: {project_name}_{service_name}_{instance_number} # default value

通过这样的配置，可以使用

services:
  my_service:
    container_name: fixedprojectname_{service_name}_{instance_number}

编辑：这不是一个完美的解决方案，因为在同一文件夹名称中使用2个不同项目的人会发生冲突

jderusse 于 2019-09-13

@jderusse

一个不错的解决方案是在container_name属性中使用占位符（以及其他动态命名，例如音量，网络等）。
services:
  my_service:
    container_name: {project_name}_{service_name}_{instance_number} # default value
通过这样的配置，可以使用
services:
  my_service:
    container_name: fixedprojectname_{service_name}_{instance_number}
编辑：这不是一个完美的解决方案，因为在同一文件夹名称中使用2个不同项目的人会发生冲突

我也在这样做，并认为这可以解决冲突问题，尽管我们仍然需要在.env文件中将COMPOSE_PROJECT_NAME变量设置为某个唯一值。

Ladeiras 于 2019-09-13

在这一点上，我真的只想了解维护者拒绝解决方案的原因。已经有请求解决方案的请求。

一旦我们知道出了什么问题，就可以进行修复。在这一点上，除了“被拒绝”之外，我没有其他反馈。

artnaseef 于 2019-09-13

👍4

我们有以下2条评论：

https://github.com/docker/compose/issues/745#issuecomment -345054893
https://github.com/docker/compose/issues/745#issuecomment -346487757

但是我必须承认，即使阅读这些评论，我也不完全理解为什么不只是将project_name添加到yaml文件中。对于那些认为这会降低其docker-compose.yaml文件的通用性的人，他们不应仅将名称放在yaml文件中，但请让我们其他人可以选择这样做。

terjebraten-certua 于 2019-09-16

👍13

好的，我正在努力阅读对其他评论的引用；除了可以帮助确保我阅读正确的东西并获得正确的内容的参考之外，至少还要简短地引用参考中的内容。

让我尝试总结一下我所关注的问题。任何帮助澄清这一点将不胜感激。

（1）在YML文件中添加项目名称可能会降低项目的可重用性，因为这将阻止或至少使运行一个以上项目名称的一个YML文件变得复杂。
（2）“由于无法证明添加该项目（以这种形式）是合理的，因此该项目的质量将遭受太多损失”
（3）“如果项目名称在撰写文件中，则任何两个项目都可以使用相同的名称，从而导致冲突，这将破坏两个项目。”

我对此有想法，但我将不加评论，直到我们就需要解决的问题达成共识。那合理吗？

artnaseef 于 2019-09-17

👍4 👀1

（4）以向后兼容的方式实现（值的优先级/顺序）

schmunk42 于 2019-09-17

（1）在YML文件中添加项目名称可能会降低项目的可重用性，因为这将阻止或至少使运行一个以上项目名称的一个YML文件变得复杂。

再有，有一种官方方法可以将配置分为基础和文件并继承-https: //docs.docker.com/compose/extends/。无法在基本配置中设置项目名称。

对我来说，我要寻找的主要用例是能够在本地运行项目的多个实例（开发，测试环境等）。

timanovsky 于 2019-09-17

👍3

也许解决方案是允许您显式设置项目名称或遍历路径。

如果我在yaml文件中像my-project一样显式设置项目名称，则可以简化项目的单个实例的工作，或者在我执行类似将所有docker文件添加到docker文件夹中的操作时跨多个项目。

.
├── project_a
│   ├── docker
│   │   ├── docker-compose.yml (project_name: my-project)
├── project_b
│   ├── docker
│   │   ├── docker-compose.yml (project_name: some-other-project)

但这对同一个项目的多个实例无济于事，那么如何遍历路径呢？

project_name: ../(*)这样的例子

.
├── project_a
│   ├── docker
│   │   ├── docker-compose.yml (project_name=project_a)
├── project_b
│   ├── docker
│   │   ├── docker-compose.yml (project_name=project_b)
├── project_b_copy
│   ├── docker
│   │   ├── docker-compose.yml (project_name=project_b_copy)

同样project_name: ../(../*)

.
├── dev
│   ├── project_a
│   │   ├── docker
│   │   │   ├── docker-compose.yml (project_name=dev_project_a)
├── test
│   ├── project_a
│   │   ├── docker
│   │   │   ├── docker-compose.yml (project_name=test_project_a)

如何指定遍历可能应该比我的经验更为深入，但是至少通过这样做，我认为我们可以灵活地涵盖所有用例。

rijnhard 于 2019-10-09

👍2

只是开个玩笑：这意味着在docker-compose.yml中配置一个固定的名称，我会创建一个我想要的名称的文件，然后设置project_name: name-of-the-file-named-like-the-name-i-want ？

ankon 于 2019-10-10

我目前在同一目录中加载了docker-compose文件。像dc-work.yml ， dc-server.yml等，它们都加载不同的，不相关的服务。

当我运行docker-compose up dc-A.yml ，然后运行docker-compose up dc-B.yml ，Docker告诉我有孤儿服务正在运行（当然，没有，这是由于该项目名称太老了）。

真的没有办法解决这个问题吗？将每个dc-A|B|C|etc.yml文件移到其自己的目录中，然后遍历每个文件以加载我的所有服务似乎是浪费时间，还是我错过了一些东西？

flatline-studios 于 2019-11-08

👍2

为什么未解决此问题？ @ cr7pt0gr4ph7在此处提供了清晰而直接的解决方案： https :

CharlieReitzel 于 2019-12-03

👍5

也遇到了这个问题，因为我们正在使用带有.docker文件夹的固定项目目录结构，该文件夹包含所有与docker相关的内容，所以我最终得到很多.docker项目名称-我正在研究微服务架构所以有很多东西是正常的...但是这个小小的事情一直困扰着->还有，PHPStorm等没有选择传递-p /-project-dir参数的选项，我不能确实为此使用.env，因为相信我，设置正确的值会被遗忘...

ThaDaVos 于 2019-12-11

开发人员，请让我们知道您希望如何解决它。

AyushyaChitransh 于 2019-12-18

😕1

也许在docker-compose文件中添加属性以设置项目名称？

ThaDaVos 于 2019-12-18

👍8 😄2

@AyushyaChitransh

开发人员，请让我们知道您希望如何解决它。

这是最好的总结：
https://github.com/docker/compose/issues/745#issuecomment -182296139

有很多讨论。无需进一步讨论。项目维护者只需要读取线程（多个）并做必要的事情即可。

CharlieReitzel 于 2019-12-18

👍1

对我来说仍然是这样： https :

schmunk42 于 2019-12-18

👍3

对我来说仍然是：＃745（评论）

是的，有一个现有的但较差的解决方案。这些评论已被否决，许多人已明确指出了这些问题。链接的注释根本无法解决这些主题中提出的大多数合法问题。

Tbh，这是一个有争议的问题。我们许多人已经使用docker-compose类型功能迁移到Kubernetes。这有点冗长。但是它正在运行，并且得到了云供应商的良好支持。

CharlieReitzel 于 2019-12-19

@AyushyaChitransh
我们要使用如下所述的机制来设置项目名称： https :

命令行参数
环境变量（.env文件）
直接在撰写档案中
资料夹路径

不要以为这有异议。

dazinator 于 2019-12-19

如上所述，它与可移植性有关，在使用container_name时，在某种程度上相似，它也不应该是docker-compose.yml 。您不能使用现有设置重复使用相同的配置。

如果您的工作流程要依赖文件夹路径，并且以某种方式将project-name注入到您的配置中，例如。通过合并多个组合文件，模板...-您最终会遇到相同的问题-覆盖现有堆栈。

不好意思这么说，但这应该作为wontfix ..（编辑）关闭或发布新的MAJOR（！）版本

schmunk42 于 2019-12-19

@ schmunk42

如果您的工作流程是依赖于文件夹路径，并且以某种方式将项目名称注入到您的配置中，例如。通过合并多个组合文件，模板...-您最终会遇到相同的问题-覆盖现有堆栈。

首先，项目名称只会由需要它的人在组合文件中设置，这恰恰是因为他们希望组合文件能够与现有堆栈一起使用。您可以将警告添加到围绕此设置的文档中。
其次，对于那些依赖特定项目名称的用户，请考虑以下事项：

如果撰写文件是从git仓库下载的，然后在下一次提交中，仓库所有者将其移动到另一个子文件夹怎么办？还是重命名了它所在的文件夹？由于可以移动文件，因此已经存在对工作流程的影响，这会影响项目名称。
如果您依赖于特定的项目名称，我们已经提出了一种机制来确保使用特定的项目名称，方法是在执行Docker compose时使用环境变量（.env文件）或使用命令行arg-两者都会覆盖碰巧在其中的任何值撰写文件（如果由于某种原因添加了文件）。

如果不解释上面的原因为什么不够好，或者提供解决方案的路径，将其作为wontfix结束并不是很有帮助。

dazinator 于 2019-12-19

👍15

我不希望我的工作流（或者整个团队的工作流）依赖于他们将代码签入到的文件夹的名称。

我对.env文件解决方案的主要问题是，该文件必须位于命令run的工作目录中-而docker-compose会将compose文件解析为父目录。因此，至关重要的是，所有开发人员要么（A）将代码检出到同名文件夹中（假定代码存储库根目录中的docker-compose.yml文件），要么（B）仅在以下位置运行docker-compose命令：存储库的根文件夹否则会创建冲突的堆栈，或者（C）它们具有不同的堆栈名称，并且所有文档和脚本都需要说replace stack name here 。

如果（C）是docker建议的“便携式”解决方案，则docker-compose CLI必须具有docker CLI命令的功能完整，即使如此，我仍然看到此功能的用例。

如果您的工作流程是依赖于文件夹路径，并且以某种方式将项目名称注入到您的配置中，例如。通过合并多个组合文件，模板...-您最终会遇到相同的问题-覆盖现有堆栈。

如果将项目名称添加到docker-compose文件中，则肯定是有原因的（就像docker-compose文件中的所有其他行一样）。可悲的是，即使只是重命名我已签出的文件夹（不对git进行任何跟踪更改），我也遇到了损坏的系统。

我不敢相信现在是2020年，我们仍然没有解决这个巨大的用例。这不是一个重大变化，是一个完全可选的功能，非常有意义。鉴于Kubernetes现在是docker的事实上的部署工具，我可以想象docker-compose主要在开发/本地部署中使用，并且在存储库的根目录中有一个docker-compose文件来在本地仓库中运行代码是非常流行的用例。

dc-pm 于 2020-03-12

👍10

@ dc-pm写道：“鉴于Kubernetes现在是码头工人事实上的部署工具”

我现在不再写docker-compose文件。对于无法生产的产品而言，没有足够的收益。 Kubernetes也有它的怪癖。但是它得到了云供应商的广泛支持。

实话实说，即使在我的开发环境中处理容器每天也太麻烦了。我只是运行程序...

CharlieReitzel 于 2020-03-12

😄2 ❤1

@ dc-pm写道：

我不敢相信现在是2020年，我们仍然没有解决这个巨大的用例。

这不仅是因为它尚未得到修复，而且开发人员还积极拒绝对其进行修复。

我怀疑问题是，开发此软件的青少年没有足够的经验来理解此用例的含义，或听取大量有经验的用户的要求。在这一点上，我怀疑他们是否在一个有多个堆栈的环境中工作，甚至可能在团队中工作。坦率地说，否则，_这将是一个非常明显的增强功能！_

DavidAntliff 于 2020-03-14

👎14 😄3 👍2

一些友好的提醒...
开源开发人员不是您的“雇员/学院”，在大多数情况下，他们大多是免费工作。
如果这显然对您来说是一个问题，请花一些时间研究解决方案（并进行PR）。

责怪不是解决方案。

https://github.com/docker/code-of-conduct/blob/master/code-of-conduct-EN.md

agravelot 于 2020-03-14

👍11 👎4 ❤3 😄1

当开发人员反对时，很难推动更改...

2020年3月14日星期六，03：19，Antoine Gravelot [email protected]
写道：

一些友好的提醒...
在大多数情况下，开源开发人员不是您的“员工/学院”
他们主要是免费工作。
如果这显然对您来说是一个问题，请花一些时间研究解决方案
并推动公关。
责怪不是解决方案。
https://github.com/docker/code-of-conduct/blob/master/code-of-conduct-EN.md
-
您收到此邮件是因为您发表了评论。
直接回复此电子邮件，在GitHub上查看
https://github.com/docker/compose/issues/745#issuecomment-598991880 ，或者
退订
https://github.com/notifications/unsubscribe-auth/ABAXP2DRD7H4YI7KQ7B2URLRHLLQ5ANCNFSM4AZMCNWA
。

rijnhard 于 2020-03-17

👍9

@agravelot我认为已经有一些PR，可能并不理想。但是通过所有讨论，所有者非常明确地设定了他们不希望使用此功能的期望。这与编码无关。

timanovsky 于 2020-03-17

👍3

@agravelot对您的延迟

我只是简单地强调一下这个想法的支持，尽管在很长的时间范围内都得到了明确的支持，但这个想法却无数次被听到。我们的行为准则中定义的整个重点（通常是OSS）是允许人们贡献代码并尊重所有想法。

已经编写了多个请求请求，但是如果可以解决这种情况，我很乐意编写另一个请求。

有什么更具建设性的前进方式？

dc-pm 于 2020-03-31

👍4

已经编写了多个请求请求，但是如果可以解决这种情况，我很乐意编写另一个请求。

是的，开发人员应该继续进行审查，或者将其关闭为“无法解决”（可能是争论）……保持开放多年，没有任何官方反馈，这只是在浪费贡献者的时间（广义上来说））。 IMO，这也是不尊重。

meden 于 2020-04-07

👍3

嗨，大家好，我想作为一个用户分享我的用例。因此，我有2个docker-compose.yml文件，一个用于开发环境，一个用于生产。它们位于同一文件夹中。它们都有同名的服务-称为“数据库”。我想同时部署这两个服务-正是因为我正在谈论的是容器化，所以我可以任意扩展。它们具有不同的“ container_name”值。

所以我跑：

macbook@fuck-fuck autocat-server % docker-compose -f ./compose-dev.yml up -d database
Creating network "autocat-server_autocat-dev" with the default driver
Creating database-dev ... done
macbook@fuck-fuck autocat-server % docker-compose -f ./compose-prod.yml up -d database
Creating network "autocat-server_autocat-prod" with the default driver
Recreating database-dev ... done

请注意，当我清楚地引用位于“ prod”项目中的服务时，它说“正在重新创建数据库-dev”。实际上覆盖现有容器。数据库被终止，容器被后者替换。

我这样做的前提是，单独的“ docker-compose.yml”文件意味着单独的项目，但显然这不是现实生活中的事情。服务部署到的项目由“ docker-compose.yml”的位置确定。为了使它们成为单独项目的一部分，我需要在环境变量中单独指定项目名称。终于可以这样处理：

macbook@fuck-fuck autocat-server % COMPOSE_PROJECT_NAME=autocat-prod docker-compose -f ./compose-prod.yml up -d database
Creating network "autocat-prod_autocat-prod" with the default driver
Creating database-prod ... done
macbook@fuck-fuck autocat-server % COMPOSE_PROJECT_NAME=autocat-dev docker-compose -f ./compose-dev.yml up -d database
Creating network "autocat-dev_autocat-dev" with the default driver
Creating database-dev ... done

对于单命令部署而言，如此之多，真是个笑话。我认为，.yml是在这种情况下指定项目名称的好地方。

另外，我可以将服务放在一个项目中-通过给它们提供不同的名称：“ database-dev”和“ database-prod”。这种方法的唯一问题是，有一个关于先前实例化的服务变为孤立的警告，因为在另一个docker-compose.yml中未提及该服务。

macbook@fuck-fuck autocat-server % docker-compose -f ./compose-prod.yml up -d database-prod                
Creating network "autocat-server_autocat-prod" with the default driver
Creating database-prod ... done
macbook@fuck-fuck autocat-server % docker-compose -f ./compose-dev.yml up -d database    
WARNING: Found orphan containers (database-prod) for this project. If you removed or renamed this service in your compose file, you can run this command with the --remove-orphans flag to clean it up.
Creating database-dev ... done

这是没有道理的，为什么必须这样。实际上为什么一定要这样呢？

EDIT1：@ dc-pm @CharlieReitzel whatchu怎么想？您能对我的用例发表任何评论吗，以防万一它无效:)
EDIT2：我已经将两个撰写文件都放到了单独的目录中，瞧

isaac-weisberg 于 2020-04-10

👍13

oo？

MaxmaxmaximusGitHub 于 2020-05-26

❤2

维护者，有人吗？
开发人员等待6年！

lon9man 于 2020-10-05

👍4

嗨！我在compose-spec中创建了一个问题，将项目名称添加到compose模式中，因为它可以控制我们可以添加到compose文件中的内容。
将project-name属性添加到compose规范后，我们可以在docker-compose中开始实施。

aiordache 于 2020-10-05

👍10

Compose: 建议：使项目名称持久化。

提案：使项目名称持久化

档案位置

征求意见

最有用的评论

所有274条评论

〜/ projects / sketches / sketch-42 / docker / docker-compose.yml

CLI参数：

信封文件：

yml文件中具有项目名称的建议解决方案：

相关问题