Compose: 版本3中的Depends_on

depends_on在v3中仍然存在，但是不会移植运行状况检查依赖项（因此是扩展语法）。

高温超导

但是我写了一个docker-compose v3，我尝试在swarm上进行部署，但是depends_on无法正常工作，因为容器没有以必须启动的方式启动。

您使用的是docker-compose还是docker stack deploy吗？

我正在使用docker stack deploy
我尝试将其部署在7台机器上

在docker-compose v3上实现健康检查依赖项等价的东西是什么？ 如果要在v3中删除该功能，则基本上不要使用它，或者至少应该有一个迁移路径。

有什么打算将其引入新的docker-compose v2.1中，然后将其删除至v3？ 我目前正在为我们的应用程序设置不同的撰写文件，但我不想使用在下一版本中将被删除的功能，因此无法使用更新到新的docker-compose文件版本。

目前，您应该假定新的depends_on语法不会移植到v3，因为我们目前尚无这样做的计划。

我知道这不是很多人想要的答案，但是我希望至少可以帮助您弄清楚一些。

请问为什么不在计划中？ 我认为这样做非常有用。

它给出了清晰的信息，但没有解释。 您能详细说明为什么吗？ 以及其他选择（如果存在）？
Depends_on为我们提供了一种真正依赖服务的简便方法，而不是在容器内部进行处理（这可能意味着用一些等待脚本包装第三者的形象并必须对其进行维护）。

@ shin-那么为什么要在2.1中完全实现呢？ 如果人们使用它并依赖它，他们将永远无法升级。 出于所有应有的尊重，你们这方面的计划似乎非常糟糕。

那么，什么是V3支持depends_on语法？ https： // docs。码头工人。 v3撰写文件中的我...

@mustafaakin

请问为什么不在计划中？ 我认为这样做非常有用。

@hsmade

您能详细说明为什么吗？ 以及其他选择（如果存在）？

来自https://github.com/docker/docker/issues/30404#issuecomment -274825244

depends_on与docker stack deploy一起使用时是空操作。 群集模式服务在失败时会重新启动，因此没有理由延迟启动。 即使它们几次失败，它们最终也会恢复。

@brettmc

那么，v3支持的depends_on语法是什么？

使用docker-compose ，v3支持的语法是列表语法（类似于2.0所使用的语法）。 如果您使用的是docker stack deploy ，则将不遵守依赖项（请参阅上面的说明）

第3版格式是从外部docker-compose工具转向集成的docker stack解决方案的第一步。 当前的实现有其怪癖正在研究中。 支持docker-compose的版本3格式是为了帮助实现这一过渡。 自从首次引入fig / Compose以来，Docker中的许多事情已经发生了变化和改进，这意味着许多以前有意义的事情现在已经过时了。 docker stack是使用新概念的崭新开始，摒弃了一些较笨拙的语法和概念，从volumes_from到depends_on 。
如果您对其中的某些更改有特别的担忧，请在正在积极对其进行迭代的docker / docker存储库中报告这些更改。
如果您尚未准备好过渡到Docker服务和docker stack ，请随时继续使用v2格式。 尽管可以合理地假设该项目在将来的某个时刻将是日落，但它会提前宣布。 之后，该代码将保持可用并开源。

谢谢。 现在有道理了。

群集模式服务在失败时会重新启动，因此没有理由延迟启动。 即使它们几次失败，它们最终也会恢复。

恕我直言，这不是一个好方法。 并非所有服务都能正确检测到它们依赖的其他服务尚未准备就绪，它们会尝试多次然后失败，因此容器可能会在以后死亡。 我们仍然需要引入入口点包装器脚本，这不是很好。 健康检查依赖性非常好，但是它不支持群体模式。

群集模式服务在失败时会重新启动，因此没有理由延迟启动。 即使它们几次失败，它们最终也会恢复。

嘿大家！
这是否意味着例如，如果我有一个可以非常快速地运行和完成其工作的服务（并且应该仅按设计运行一次），它将一次又一次地……反复地启动？

@ Marvel77默认情况下是，但是您可以使用deploy.restart_policy部分来覆盖该行为： https :

@ shin-非常感谢！

@mustafaakin实际上，最佳实践是（IMHO）与您所依赖的服务建立容错连接。 例如，如果您使用数据库，则可能会延迟启动直到它响应为止。 但是，如何处理数据库的重启？ 您的应用应该能够从中恢复，然后您也不必依赖于'depend_on'。
从某种意义上说，弃用是一件好事。 这些便利使我们变得懒惰。

@hsmade但是几乎所有的init（upstart，systemd）都依赖于关系。 因此，不是懒惰，而是有意义的。 在您准备好网络设备之前，SSHD守护程序不会启动。 我无法控制我拥有的所有系统，是的，我可以使我的系统具有容错能力。 但是假设A依赖于B。A需要花一些时间来初始化，这不是很确定。 那么，如何在B上编写重启策略？ 永远重启？ 如果您不想要那怎么办？

这个问题比Compose更大，Compose只是启动它们。 Swarm是使它们运行的​​原因，因此我认为Swarm应该处理这种对健康关系的依赖。

@mustafaakin我认为您无法将在容器化环境中运行的微服务与经典的init系统进行比较。 那真的没有道理。 我认为微服务的思想是它们是独立的，最小的实体。 他们对自己的API等有非常清晰的定义。他们不应该假设自己的外部世界处于任何状态。 是的，它需要一个数据库，但是不，您不能假设它在那里。 就像我试图说的那样，知道您对启动的依赖性是您最少的问题，在故障消失时妥善处理它更为重要，并且也应解决前者。

但是话又说回来，这些是我对此事的想法，我可能是错的;）

是的，对于微服务来说没有意义，但是并不是所有的东西都是微服务，我在容器中运行Hadoop。 Docker不仅适用于微服务。 就像我说的那样，它对于我可以控制的环境非常有用，但是在我无法控制的环境中，它需要包装服务的入口点。 刚刚通过healcheck的depends_on解决了这个问题，我只是认为将其包含在Swarm中也很棒。 选择性地重新启动只是一个懒人的选择。

伙计们

我认为存在一种对“容错”的误解和一种“首次初始化”的误解。
同意这种方法听起来对第一个方法足够好，但是后一种方法确实很痛苦。
我可以想象不仅是我自己，而且通常来说，通常需要以某种特定的顺序启动服务，因为它们或多或少地相互依赖。

在初始化阶段连续重启并在某个时候等待服务以正确的顺序启动就像噩梦一样，如果情况更糟，则无法计划启动过程的任何“停机时间”。 不仅更糟，而且有时会说需要一些更改的“维护”时间，并且没人能够预测系统实际启动将花费多少时间，因为不同的服务会一遍又一遍地重新启动。再次等待正确的订单。
我已经尝试并等待着看它如何与7个容器一起使用，并且在20分钟内_swarm_仍然没有弄清楚它，并且整个服务仍然处于关闭状态。
因此，甚至无法说明恢复和恢复整个基础架构将花费多少时间，因为实际上不知道_initial启动_将花费多长时间。
对我来说听起来很荒谬。

我认为如果没有这种可预测性，我就无法完全投入“生产”中，即使这种情况很少发生（完全崩溃），也永远不会发生。
但是，如果仍然发生这种情况，我将当场，将面临恢复ASAP的挑战，就在那时和压力下，我绝对不知道我的容器将启动多少时间，只是因为它们在_startup._期间继续自行重启。

@ozlatkov这确实应该发布在

@ shin-谢谢！ 我已将其移至docker / docker tracker：

https://github.com/docker/docker/issues/31333

我认为Docker团队假设使用Docker Swarm确实很糟糕。 Compose应该是一个功能齐全的独立工具。

但是，我们在测试管道中确实使用了Docker Compose，并且这样的基本功能删除（没有提供可行的替代方案）确实会对用户产生巨大的负面影响。

我目前正在从我的团队成员那里审查非常丑陋的PR，他们试图为此提出各种解决方法（因为我们严重依赖此功能），包括永久使用Compose2.X。

Docker应该通过删除许多团队已经依赖的关键功能来帮助我们实现目标，而不是使其变得更加困难。

请重新考虑将所有这些都移植到Docker Compose 3中。

非常感激。

现在是第100次：如果您不打算使用群集服务，则没有理由使用v3格式。

这是否意味着团队致力于为使用compose作为独立开发工具的2.X格式提供支持？

确实是我的问题：Compose团队是否致力于永远支持v2格式？

如果v2格式计划在任何时候弃用，我们将无法在Docker Compose上实现标准化。

我觉得这迫使所有容器进入init container模式，删除了docker restart策略并创建了一种用于启动命令的方法。 是否应该假设> = v3的compose将朝这个方向发展，以专注于堆栈和创建应用程序包？ 如果是的话，您能指出我如何维护Docker堆栈中的启动顺序吗？ 是wait-for-it.sh或dockerize那里的方法吗？

栈的docker-compose.yml的声明式等效项是什么？

嗨，大家好，如果我打算使用docker stack并摆脱docker-compose，什么是最佳做法？

这似乎是解决方案，但是用一些骇人听闻的脚本来初始化容器听起来不是一个好习惯。 可以？

谢谢。

@mustafaakin感谢您的

@VinceOPS我不确定“最佳实践”，但我一直在使用运行状况检查和restart: always因此它会循环运行直到\\（ツ）_ /¯

@hutchic但是正如上面的对话中所提到的，它不能有结束日期，某种形式的故障循环重启。

为什么Docker团队在版本3中删除了此功能并拒绝在其中添加这些功能？

@ tianhao-au请参阅https://github.com/moby/moby/issues/31333 （和https://github.com/moby/moby/issues/31333#issuecomment-409143581）上的讨论

对于撰写，我还在https://github.com/moby/moby/issues/31333#issuecomment -333265696（具有x-depends_on ）中留下了一个建议

从字面上看，这种功能上的改变就是为什么我不再使用docker-compose了。 如果我在生产环境中使用docker而在生产环境中本地使用docker-compose，则现在需要使我的docker容器在dev中的行为与在生产中的行为完全不同。 在生产中，我依靠业务流程系统来确保部署的运行状况和顺序。 在开发领域，业务流程是由docker-compose完成的。 现在，我正在编写一堆错误的脚本，以检查事物的运行状况以协调系统。 如果我要这样做，为什么不只写一些golang来管理我的docker并完成它。 有点生气，它掉了。 只是我的2p

尝试使用最新的docker-compose版本使事情更加适应未来，并偶然发现了这个问题。 这真是难过;这真是伤心。