嘿，这个问题我刚好在实际运维Swarm集群时碰到过，咱们一步步来拆解～

1. 执行docker service inspect mystack_web看不到depends_on是否正常？ #

完全正常！

原因很简单：depends_on只是docker-compose（或者docker stack deploy时）用来控制启动顺序的临时配置，它并不会被Swarm集群持久化存储到服务的元数据里。Swarm本身的服务编排逻辑是基于服务发现和健康检查来处理依赖可用性的，而不是靠depends_on这个静态配置。所以当你用docker service inspect查看服务详情时，自然看不到这个条目。

2. 如何查看指定Docker服务的依赖关系？ #

既然service inspect拿不到depends_on，那咱们可以通过这些方式来梳理依赖：

• 回到原始栈文件查看
  最直接的方式就是打开你部署栈时用的docker-compose.yml（或stack.yml），直接查看目标服务的depends_on配置项，这是你最初定义的依赖关系的唯一静态记录。

• 通过环境变量/服务DNS推断依赖
  大多数服务会通过环境变量或者Swarm内置的服务DNS来引用依赖的服务（比如web服务会配置DB_HOST=mystack_db）。你可以用以下命令提取目标服务的环境变量：

  docker service inspect mystack_web | grep -A 15 "Environment"
  

  或者查看服务的网络配置，看它和哪些服务共享同一个Overlay网络（只有在同一网络的服务才能互相访问）：

  docker service inspect mystack_web | grep -A 10 "Networks"
  

• 查看栈内服务的运行关联
  用docker stack ps mystack查看整个栈的服务实例运行状态，结合服务名称的命名规则（比如mystack_web和mystack_db同属一个栈），可以快速推断出服务间的依赖关系（通常web服务依赖数据库服务）。

• 检查共享资源（网络/卷）
  如果服务间通过共享卷或者网络来实现依赖（比如缓存服务和应用服务共享卷），可以通过docker service inspect的Mounts和Networks字段来查看，这些共享资源也是间接的依赖标识。

额外小贴士：Swarm中正确处理服务依赖的姿势 #

别依赖depends_on来保证服务的可用性！Swarm里更可靠的方式是给依赖服务配置健康检查，比如给数据库服务添加健康检查规则：

services:
  db:
    image: mysql:8.0
    healthcheck:
      test: ["CMD", "mysqladmin", "ping", "-h", "localhost"]
      interval: 10s
      timeout: 5s
      retries: 3
  web:
    image: my-web-app:latest
    # 不需要depends_on，Swarm会等db服务健康后再启动web实例

这样Swarm会自动等待依赖服务进入健康状态后，再启动当前服务，比depends_on的顺序控制要靠谱得多。

内容的提问来源于stack exchange，提问作者hichamx