我对多克群有意见。我曾尝试用Docker Swarm模式部署我的应用程序。但是我不能按顺序排列我的服务，尽管我使用了depends_on（建议不支持Docker堆栈部署）。如何通过按订单启动的服务来部署
服务1启动服务2等待服务1请帮帮我。
41zrol4v1#
Swarm不支持此功能。群是为高可用性而设计的。当遇到问题（服务或主机失败）时，服务将按失败的顺序重新启动。如果您的服务之间有明确的依赖关系，并且它们无法处理等待其他服务可用或重新连接的问题，则您的系统将无法工作。您的服务应该以一种可以处理任何时间重新部署的任何服务的方式编写。
eivnm1vs2#
没有业务流程系统推荐或支持此功能。所以忘了它，因为这是一个非常糟糕的主意。应用程序基础结构（这里是容器）不应该依赖于数据库的健康状况，但应用程序本身必须依赖于数据库的健康状况。你看出区别了吗？例如，应用程序可能会显示错误消息“尚未就绪”或“此功能已禁用，因为ElasticSearch已关闭”等...因此，即使可以实现这种模式（在kubernetes中也称为“wait-for”，您可以使用initContainer来“等待”另一个服务启动和就绪），我也强烈建议将这种逻辑移到您的应用程序中。
initContainer
2条答案
按热度按时间41zrol4v1#
Swarm不支持此功能。
群是为高可用性而设计的。当遇到问题（服务或主机失败）时，服务将按失败的顺序重新启动。
如果您的服务之间有明确的依赖关系，并且它们无法处理等待其他服务可用或重新连接的问题，则您的系统将无法工作。
您的服务应该以一种可以处理任何时间重新部署的任何服务的方式编写。
eivnm1vs2#
没有业务流程系统推荐或支持此功能。
所以忘了它，因为这是一个非常糟糕的主意。
应用程序基础结构（这里是容器）不应该依赖于数据库的健康状况，但应用程序本身必须依赖于数据库的健康状况。
你看出区别了吗？
例如，应用程序可能会显示错误消息“尚未就绪”或“此功能已禁用，因为ElasticSearch已关闭”等...
因此，即使可以实现这种模式（在kubernetes中也称为“wait-for”，您可以使用
initContainer来“等待”另一个服务启动和就绪），我也强烈建议将这种逻辑移到您的应用程序中。