Compose: 由Compose创建的容器的默认命名方案

不幸的是不，对不起。

这里也是一样。 此子弹功能应该是可选的。 在up或build命令上传递标志以将其关闭有多难？

我同意-这应该是可选的。 现在，只有降级到1.22才能运行几个使用Docker Compose的程序。

我同意，这应该是可选的。 我们根本不需要此特性，并且很多bash脚本都使用旧的命名格式。

对我们来说一样，我们必须保持1.22不变，因为我们使用“来自……的体积”功能并依赖旧的命名方案。 请在1.24中将其设为可选功能。

此功能使升级后很难引用容器。

我不明白这种改变的意义。 当前，docker和compose均未提供任何服务发现。 因此，如果我想从容器内部获取主机名，该怎么办？ 推出我自己的服务发现？

顺便说一句，这种变化有什么好处？ 真的值得打破向后兼容性吗？

默认的_slug名称更改是正确的方法，但是无法通过环境变量或命令行选项禁用它，这会破坏许多现有的工作流程。 请考虑将此功能请求添加某种标记以恢复<= 1.22.0 docker-compose命名行为。

抱歉，“ external_links”现在无法使用。 我必须知道链接它的容器的名称。
+1（可选）

@ shin-这种新行为完全毁了很多。 在该随机slug之前，可以解决从另一个文件中的一个docker-compose文件启动的容器，例如

services:
  app:
    image: app
    external_links:
      - "other-project_other-app_1:other-app"
networks:
  default:
    external:
      name: other-project_default

就是这样。 现在，这根本不起作用。

这东西怎么至少不是可选的？

我相信，码头工人组成死亡的又一步。

因此，有一种解决方法。 container_name参数按原样使用，而未使用slug 。 至少，这有帮助。

@ shin-，请不要认为这是关于slug未与container_name一起使用的错误报告。 保持原状。 我实际上是在这里装袋。

好家伙！ https://github.com/ansible/ansible/issues/47978

尽管我了解了更改背后的动机，但它却极具破坏性，尤其是因为没有宽限期，至少不能给开发人员时间来调整其脚本。 考虑到这种命名约定，很多脚本都是永久存在的。 基本上，此更改使docker-compose 1.23与任何其他docker-compose非向后兼容。

@ shin-您个人以及所有docker-compose和docker团队个人都应该已经了解了什么是向后不兼容的更改，以及如何将其应用于整个行业所广泛采用的项目。

首先，向后不兼容的更改并不是要破坏您先前保证不做的事情。 没人关心这个东西是否被没人使用。

向后不兼容的更改是当您破坏用户群真正依赖的东西时。 并没有什么保证，因为毕竟是Apache 2.0和整个项目provided on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND 。 用户决定他们依赖什么。 您（整个团队）应该开始学习如何知道谁在使用您的项目，原因和方式。

其次，您应该学习如何对用户群进行这种更改。 这种“随机后缀”肯定会破坏用户使用external_links和volumes_from 。 因此，在没有显式设置container_name情况下，或者在可能出现这种情况时，不建议使用不当警告。 请考虑以下文件以熟悉“其他人的工作”：

• https://www.python.org/dev/peps/pep-0004/
• http://api.mongodb.com/python/current/compatibility-policy.html
• https://docs.openstack.org/python-novaclient/pike/reference/deprecation-policy.html
• https://docs.djangoproject.com/en/dev/internals/release-process/#deprecation -policy

第三，@ shin-，您个人应该学习如何与那些不是您的项目的直接贡献者，只是您的用户，但同时又非常忙碌，忠于您的项目，足以投资自己的宝贵资源的人交谈提交申请和参与讨论，唯一的希望是为项目的未来发展带来一些意义，并避免在迁移到另一个解决方案上避免投入更多的资源。

第四，Docker团队正试图从Docker赚钱，但这与Docker本身无关。 Docker可以成为一件好事的唯一途径就是，如果整个Docker基础设施证明值得付出。 如果开发团队大多数时候将产品转回社区，我看不出它是面向用户成功的产品。

第五，再次，我们所有人都是您的学院和朋友，而不是敌人，我们真的在尽一切努力帮助您。 而且由于我们是您的朋友，因此从Docker堆栈中流离失所将是痛苦的，但是顺便说一句，现在，告别看起来一点也不现实。

这是一个重大的版本变更的可怕实现，它完全破坏了部署我们框架的能力，我什至无法想象会有多少其他人在绝对预警为零的情况下遇到同样的问题。 除非有人手动寻找docker的最新变更日志，否则他们对此一无所知，而且我想大多数人不会这样做

@ shin-此更改对现有工作流程具有极高的破坏性，应提供一个标记，以免产生中断。 依靠docker-compose的可预测性，编写脚本和自动化服务已经花费了数千个小时的开发时间。 如果没有适当的服务发现，团队允许自动定位单个容器的计划是什么？

我尝试使用docker-compose container_name指令，但是它对GitLab无效。
但是在Mac Os Mojave上，我最新版本的docker-compose似乎可以正常工作。 不知道发生了什么:)

我的.gitlabci.yml文件正在从tmaier下载最后一个图像（应该是1.23.1）。

嘿，我希望提出一些一般性评论，以解决这里表达的一些关注：

• 我绝对知道这会破坏某些脚本。 从1.23.0-rc1开始我们的发行说明在最顶部如此。 这是一种“撕掉创可贴”的情况，其中短暂的疼痛帮助我们以更健康的基础向前迈进。
• 当前解决方案的好处很多，并在这个长期存在的问题中得到部分体现：＃1516-尤其是在这里多次报道了与docker-compose run有关的问题：＃4688＃4549＃5240
• 服务发现不应该成为问题，因为应该使用服务名称（而不是容器名称）和网络别名（在其关联的网络上是静态的）来处理它。 您可以阅读网络文档，以获取有关该
• 我认为这会使Compose项目中的volumes_from和external_links更加难以使用。 请注意，即使在进行此更改之前，也无法保证Compose会尊重给定容器名称的“预期”格式（请参见例如＃6155或＃3415中提到的前缀），从而使其易于运行并存在缺陷从长远来看会陷入晦涩的问题。
  
  
  
  • 允许来自不同项目的容器进行通信的推荐方法是让它们共享external网络并使用其他服务的别名。 同样，跨项目的volumes_from应该改用external命名卷。
  
  
• 我对如何更好地传达此更改的建议感兴趣。 作为参考，此更改已在我们的发行说明中列出，并自9月26日发布的1.23.0-rc1起可以进行测试。1.23.0 GA发布了一个多月后，并且知道该更改将引起争议，我们将其作为重大警告放在变更日志的顶部。 如果我还有更多要做的事情可以使此更改可见，那么我很高兴在下一次考虑像这样的危险更改时听取并做这些事情。
  
  
  
  • 另一方面，如果这里的总体思路是“永远不要做出任何重大改变，或者让我无限期退出所有选择”，那么我相信你们中的大多数人都知道这不是一种健康，合理的方法关于维护一个像Compose一样大小的软件项目，它已经跳了很多圈，以保持与各种Docker Engine版本，Compose文件格式和不推荐使用的惯用法的向后兼容性。
  
  

让我知道这里是否有未解决的问题。 我了解这对许多人来说是一个主要的减速带，当我们应对不可预见的情况时，脾气可能会爆发。 花点时间进行升级并暂时固定Compose版本。 很高兴为诸如“如何在没有可预测名称的情况下执行XYZ”之类的问题提供帮助？ 直到那时，在这个线程上还是在Slack上。 并且请谨慎考虑您在这些论坛上与其他人进行交互的方式，请仔细检查您共享的信息是否正确（我已经看到一些线程被提及或重定向到与该更改无关的地方，这会产生不必要的警告感，并且不会帮助在这里遇到误导的问题人员），也不会使对话脱轨。 感谢您的时间和耐心等待。

在通信方面，我希望这样的更改可以事先通过一些通信渠道进行传达和解释，基本上是按照您在此线程中所做的方式进行，说明原因以及目前要做的事情，但是要先进行所有的后果。

@ shin-您尚未阅读我的最新评论和我提供的链接，对吗？

您的最后一个看上去很友善，但感觉却一样。

我对如何更好地传达此更改的建议感兴趣。

TL; DR

• 介绍docker-compose.yml新的version docker-compose.yml
• 以external_links添加DeprecationWarning到文档的链接，该文档描述了更新并为愿意迁移的用户提供了示例解决方案。
• 支持新版本之前所有组合文件格式版本的旧行为。

作为参考，此更改已在我们的发行说明中列出

变更日志是供贡献者使用的东西。 用户不阅读。 用户安装了docker-compose并祈祷它在昨天之后仍然可以使用。

另一方面，如果这里的总体思路是“永远不要做出任何重大改变，或者让我无限期退出所有选择”，那么我相信你们中的大多数人都知道这不是一种健康，合理的方法关于维护一个像Compose一样大小的软件项目，它已经跳了很多圈，以保持与各种Docker Engine版本，Compose文件格式和不推荐使用的惯用法的向后兼容性。

我对你有个好消息。 您已经保证“永远不要做出任何重大改变，或者让我无限期退出所有选择”。 而且，您还有一个功能。 这是version的docker-compose.yml文件。 因此，请考虑尽快还原此更改，并为下一个version引入该更改。

很高兴为诸如“如何在没有可预测名称的情况下执行XYZ”之类的问题提供帮助？ 直到那时，在这个线程上还是在Slack上。

请在该线程的另一个docker-compose.yml中提供external_links和未定义container_name外部卷的解决方案（如我们所见，它并不总是有效）。

这是用户使用项目的一种流行方式。 您的大多数用户都使用docker-compose进行本地开发。 通常一个开发中有几个相互关联的项目。 在这种情况下，通常的做法是将多个docker-compose文件定向到同一网络，并为来自不同项目的服务定义external_links ，以便能够在开发人员的机器上相互访问。

不要使对话脱轨

@ shin-到目前为止，我读过的所有涉及您的对话都因为您不采取任何措施解决人们遇到的问题而变得脱轨。

认真的说，以这种态度不断拒绝用户的请求，并在避免避免更好地将此项目传递给其他人的情况下，迫使社区苦苦挣扎。

PS：对不起，另一个“ offtopic”评论。 您也可以随时锁定此问题。

请在此线程的另一个docker-compose.yml中提供未定义container_name的external_links和外部卷的解决方案（因为我们看到它并不总是起作用）。

已经做到了，请参考我之前的评论：

允许来自不同项目的容器进行通信的推荐方法是让它们共享external网络并使用其他服务的别名。 同样，跨项目的volumes_from应该改用external命名卷。

您的帖子的其余部分都是多余的，我不会回应。 我在这里，愿意讨论，但不必欺负您。

老实说，@ shin-

我对有关如何更好地传达此更改的建议感兴趣

我看不出您对“感兴趣”。 在构建组成文件并将其标记为“ spam”（笑）之前关闭有关拉取图像的票证，这告诉我您绝对不对该社区的建议感兴趣。 我真的不知道您要实现什么目标，但我认为与社区保持关系应该由其他人来承担。

我在这里，愿意讨论

即使我们提供纯粹的立功论据，您也可以忽略它们。 那为什么要打扰呢？

PS。 将其标记为offtopic，继续进行，向我们展示您如何尊重我们的观点。 看到这么多不同意见的投票会痛吗？

已经做到了，请参考我之前的评论：

抱歉，我在那儿看不到有效的示例解决方案。

您的帖子的其余部分都是多余的，我不会回应。 我在这里，愿意讨论，但不必欺负您。

抱歉，如果您有那样的感觉。 请考虑支持当前docker compose文件版本的旧行为，并介绍将以新方式运行的新格式版本。 这是为用户群提供良好解决方案的唯一选择。

请。 考虑再次阅读这两条评论，并提出我愿意帮助您的想法：

• https://github.com/docker/compose/issues/6316#issuecomment -438564025
• https://github.com/docker/compose/issues/6316#issuecomment -438934935

重新沟通：我们是通过Docker for Mac获得更新的，并且似乎没有显示任何更改日志来指出此更改，因此花了一些时间才弄清楚为什么我们的环境变量发生了更改。

一旦知道了这一点，我便借此机会将我们的配置从v1升级到v3，并使用服务名而不是环境变量进行链接，这实际上使事情变得更加整洁。

FWIW，一种向后兼容的黑客，可在由compose创建的容器中执行：

docker container exec -it $(docker container ls -f name=expected -q) cmd

一旦知道了这一点，我便借此机会将配置从v1升级到v3，并使用服务名而不是环境变量进行链接，这实际上使事情变得更加清晰

您能否在此处提供一个简短的示例，说明跨不同docker-compose文件方法链接的服务名称？

docker container exec -it $(docker container ls -f name=expected -q) cmd

不过，这与docker-compose无关。

@lig这可以解决由expected名称的更改。 如果不是为了更改命名方案，则此替代方法将不存在。

@joebowbeer更改后的主要问题是有关跨docker-compose文件的链接。 我知道，有一种方法可以找到通过docker cmd由docker-compose启动的容器。 但这对这个主题有一点帮助:(

@ shin-我想我们都还在等待为什么我们需要docker composer来生成大量行容器名称的解释。

对我来说，很明显没有人会出于理智的状态而出于生产目的使用作曲家。 Compose是一个强大的项目，可以在本地进行测试。 我不认为将docker swarm perk /功能添加到大量用于仅本地测试的工具的吸引力。 如果我们需要类似群集的容器名称，则可以使用swarm。 对？

这里的第二个大问题是：为什么没有通过参数将其作为选项功能包括在内？ 我没有在论坛和社区中看到有人呼吁将此行为作为默认行为。 因此，我们可能应该将其作为新的arg引入： docker-compose up --slug 。 简单，优雅，不会破坏任何人的脚本。

  * On the flipside, if the general takeaway here is "don't make any breaking change ever, or let me opt out of all of them indefinitely", I'm sure most of you realize that it's not a healthy, reasonable way to go about maintaining a software project the size of Compose, which already jumps through a lot of hoops to maintain backward-compatibility with a wide array of Docker Engine versions, Compose file formats, and deprecated idioms.

过去，在企业中工作时，我们倾向于采用“两个主要版本”的规则来打破变更-在一个版本中弃用，在另一个版本中删除。 我不太确定该如何选择加入，但是_temporary_选择退出将是非常值得的。

Docker-compose似乎没有主要版本的概念，但是我看不到如何将临时“禁用此”选项（无论是从命令行还是在撰写文件中）限制为一个或两个版本（1.23和可能为1.24）将构成“无限期”。

鉴于这似乎与非Linux用户的自动更新有关，因此很多人感到惊讶，而不是让剩下的四分之一的人“在更新脚本时使用此命令行标志运行”。我们有一大堆开发人员，他们必须手动降级和/或放弃他们正在执行的更新脚本的工作。

这一重大变化是一场灾难。 突然中断了许多自动部署。 请不要再这样做。

* Introduce the new `version` of the `docker-compose.yml` 
* Add `DeprecationWarning` for `external_links` with a link to a document which describes the update and provides a sample solution for those willing to migrate.
* Support the old behavior for all compose file format versions prior the new one.

太有道理了...不知道为什么不这样做。

我在这里，愿意讨论，但不必欺负您。

@ shin-很明显，这里的讨论为零，因为您没有考虑提出的合理建议。 另外，如果有人被欺负-您就是-通过这一重大变化，您实际上在欺负全世界的许多开发人员。

很多人（可能是我和其他人）不将compose用于群体模式。 由于过去存在的问题，我为撰写文件指定了较低的版本，在该问题中，假设使用撰写文件来为群体定义服务。 我发现指定的版本与在docker节点上产生的结果相关联，并且通过将版本锁定为较低的值，我将能够获得一致的结果，并且仍然可以进行更新以与docker版本保持兼容我在跑。 显然，我不能期望在这里进行正确的版本控制。

我们可以对docker-compose进行docker化，以确保它们不会突然破坏我们的东西吗？

我认为最好的解决方案是在docker-compose.yml文件中引入一个新的配置选项，在该选项中，可以将slug部分添加到容器名称中。

s / disabled / enabled /。 至少在现有的撰写文件版本上。

此行为需要与撰写文件的版本号相关联。 无论此行为是否“指定”，它都已被广泛使用，因此是向后不兼容的更改。 如果在升级二进制文件时不能保证撰写文件的功能无法正常工作，为什么还要在此版本规范？ 弃用撰写文件规范（当然，在运行docker-compose时会发出很多警告），然后再将其删除，这绝对是我的错，我所有的东西都不再起作用，但希望我能仔细阅读您的发行版有特权在我的脸上打印警告消息的程序的注释？

像这样进行更改似乎是对规范的行为进行版本控制的一种很好动机，除了其格式以外：您可以通过警告弃用其他人的代码假设。 我认为，在许多外部问题上打上名字，这足以说明这一点。 看到传统行为被破坏，这样代码不会变得复杂，但是不能立即应用这样的更改，真是太好了。 我可以期待关于组成容器名称的其他假设会被打破吗？ 服务名称将始终位于容器名称中，还是可以像可预测名称一样被删除？

这确实让我想起了何时一致网络设备命名在Linux中得到广泛采用（但这与命名... idk恰恰相反）。 许多代码已经为ethN进行了硬编码（并且仍然存在于一些令人惊讶的地方），但并没有真正改变。 然而有一个办法让回到systemd系统旧的行为（以及在其他系统上，但它可以改变）加入net.ifnames=0内核ARGS。

（对不起，第二次通过的咆哮，但我认为我的第一个并没有很建设性。）

似乎此更改使--scale选项无效。 因为必须知道随机后缀才能到达服务的扩展实例。

例如，多个服务实例作为Nginx的上游服务器。

编辑：更多信息，请参见＃6365

哇，真是太可怕了。 👎

我们应该如何获取随机生成的字符串以供脚本使用？

我也遇到了这个问题，并希望对以后向后不兼容的更改表示建议。 我们也有依赖于project_service_index格式的脚本，许多人在Mac上使用这些脚本。 在理想的情况下，我们将能够控制人们使用的Docker for Mac版本，但是现在人们会在出现自动升级对话框时进行升级。

我的问题和建议是：

1）升级对话框没有显示出此重大更改的迹象，因此我们没有明显了解此更改。 在理想情况下，我们将检查每个升级的所有发行说明，但是目前我们不这样做。 因此，如果在更新对话框中明确调用类似这样的重要操作，将不胜感激。

2）由于1），没有明显的警告。 如果在之前的升级中提出了这样的更改，那就太好了。 例如，在最新版本之前进行升级将显示诸如“容器命名方案在下一版本中正在更改，请升级脚本”之类的内容。

3）我了解，在阅读了此线程之后，不能保证我们使用的命名方案，并且我意识到可以使用更好的方法来引用容器。 但是，我们每个人都忙于工作，需要计划任务，因此，作为脚本的维护者，我无法立即将对容器名称的使用转换为更好的名称。 我很高兴使用推荐的最佳实践，但需要时间来迁移我们的代码。 因此，为这样的更改制定弃用策略将是很棒的。

这里的关键要点是，世界上的大多数人都假设使用了一个容器命名方案，这对于他们使用docker compose至关重要，并且在没有明显的弃用策略的情况下更改默认行为可能对这些工作流程有害。

人们并不总是按预期使用软件，而当他们的假设失败时，所有权就落在那些人身上。 但是，一些简单的沟通可以帮助我们为将来的变化做准备，并有助于激励我们采用最新的最佳实践。

如果您以前依赖docker container exec -it project_php_1 bash ，则不能再使用它。

您必须使用docker ps查找服务ID。

但是，您不能使用docker ps -q --filter=name=project_php因为这将在名为project_php和project_php_xdebug的服务上匹配，或者在其他与project_php匹配的内容上匹配。

以前可读的docker container exec -it project_php_1 bash现在必须变为：

docker container exec -it \
    $(docker ps -q \
        --filter label=com.docker.compose.project=project \
        --filter label=com.docker.compose.service=php) \
    bash

这是一个考虑周全的更改。

@jtreminio FWIW，从项目中您仍然可以执行docker-compose exec php

感谢所有花时间分享对变更的想法的人。 我们同意这处理不当，对我们来说有点过分热情，并且在Compose 1.23.2中已部分恢复（我们为docker-compose run创建的容器保留了随机后缀，这使我们可以更优雅地处理它们：＃4688＃4549＃5240，如最初预期的那样。

让我知道是否有任何未解决的问题需要解决。

是否有计划添加命令行选项来关闭--no-slug或更可取的是--slug以便默认设置像以前一样工作。

1.23.2恢复为以前的状态。

仅还原了docker-compose up但未还原docker-compose run

感谢您的快速解决！！

2018年11月28日晚上8：09，Joffrey F [email protected]写道：

感谢所有花时间分享对变更的想法的人。 我们同意这处理不当，并且对我们有些过分狂热，并且在Compose 1.23.2中已部分恢复它（我们为docker-compose run创建的容器保留了随机后缀，这使我们可以更优雅地处理这些后缀：＃ 4688＃4549＃5240，如最初预期的那样。

让我知道是否有任何未解决的问题需要解决。

-
您收到此邮件是因为您发表了评论。
直接回复此电子邮件，在GitHub上查看，或使该线程静音。

@ shin-我认为这将在某个时候返回-可能在1.24（因为这是一个重大更改？）。 如果是这样，您是否可以与社区合作以了解和推荐使用轻巧机制的人，而这些人却没有弹？ 不确定进行对话的最佳地点。

https://github.com/docker/compose/issues/6316#issuecomment -442666873

从<project>_<service>_<index>变为<project>_<service>_<index>_<slug>

这是一个错误而不是功能。
谢谢！
考虑一下与ansible_connection=docker ...😔一起运行的ansible剧本。
我们应该给出明确的container_name吗？ 否则我们将继续使用随机的<slug> !!更新库存。
真的很糟糕！