我已经用docker swarm部署了硒网格。
docker-compose.yml
version: '3.7'
services:
hub:
image: selenium/hub:3.141.59-mercury
ports:
- "4444:4444"
volumes:
- /dev/shm:/dev/shm
privileged: true
environment:
HUB_HOST: hub
HUB_PORT: 4444
deploy:
resources:
limits:
memory: 5000M
restart_policy:
condition: on-failure
window: 240s
healthcheck:
test: ["CMD", "curl", "-I", "http://127.0.0.1:4444/wd/hub/status"]
interval: 1m
timeout: 60s
retries: 3
start_period: 300s
chrome:
image: selenium/node-chrome:latest
volumes:
- /dev/shm:/dev/shm
privileged: true
environment:
HUB_HOST: hub
HUB_PORT: 4444
NODE_MAX_INSTANCES: 5
NODE_MAX_SESSION: 5
deploy:
resources:
limits:
memory: 2800M
replicas: 10
entrypoint: bash -c 'SE_OPTS="-host $$HOSTNAME" /opt/bin/entry_point.sh'
问题是，当hub的状态为unhealthy时，群集几乎永远不会重新启动它。仅仅几次，我注意到它已成功重启。据我了解，它应该一直重新启动，直到healthcheck成功或永久消失，但是容器只是在unhealthy状态下运行。
[我尝试完全排除restart_policy，以防它弄乱了蜂群模式，但没有效果。
另外：似乎chrome容器（所有副本）在成功重新启动hub后重新启动。 docker-compose.yml中未指定该关系，这是怎么回事？
我的设置可能出什么问题了？
docker events --filter event=health_status
对于第二个问题：-每当集线器重新启动时，所有节点都将重新启动，这是可以预期的，因为集线器将与所有节点保持会话，并且当您重新启动集线器时，它将重置所有会话并设置新节点。
restart_policy省略。群集模式将为您恢复发生故障的容器，并且该策略在群集模式之外进行处理，并可能导致意外行为。接下来，要调试运行状况检查，因为已为它配置了多次重试，超时和开始时间，所以要检查容器。例如。您可以运行以下命令：docker container inspect $container_id --format '{{json .State.Health}}' | jq .
的输出将显示容器的当前状态，包括一段时间内所有运行状况检查结果的日志。如果显示该容器重试失败超过3次且运行不正常，请检查服务状态：
docker service inspect $service_name --format '{{json .UpdateStatus}}' | jq .
这应该显示当前是否有正在进行的更新，推出变更是否导致任何问题。另一件事是内存限制。如果没有相应的内存预留，则调度程序可能会将限制用作预留（我需要对此进行测试），如果您没有其他容器未预留的10G可用内存，则调度程序可能会失败重新安排服务。一种简单的解决方案是指定一个较小的保留，您要确保在计划容器时该保留在节点上始终可用。例如：
deploy: resources: limits: memory: 5000M reservations: memory: 1000M