Docker swarm网络调试

我使用docker swarm和stack在docker中创建了一个服务，但不知何故，在服务副本中运行的应用程序无法连接到其他副本

这里有更多的细节。我有三个节点：一个管理节点和两个工作节点。在与manager相同的节点上，我运行一个注册表，它是我使用docker堆栈部署到workers的映像的源

下面是我的docker stack配置文件的外观：

version: "3.2"
services:
  compute:
    image: openmpi-docker.registry:443/openmpi
    ports:
      - "2222:22"
    deploy:
      replicas: 4
      restart_policy:
        condition: none
      placement:
        constraints: [node.role != manager]
    networks:
      - openmpi-network
networks:
  openmpi-network:
    driver: overlay
    attachable: true

正如您所猜测的，该图像包含openmpi分布。它启动sshd并打开端口22

我可以使用以下命令连接到其中一个服务：

ssh -p 2222 -i ./user-ssh/docker_id <worker node>

这就像预期的一样，我看到4个不同的主机名

所以我的下一个测试涉及mpi

mpirun -H 10.0.1.3,10.0.1.4,10.0.1.5,10.0.1.6 hostname

这个命令应该执行完全相同的操作，只是它应该使用mpirun而不是ssh。但不知怎的，这失败了

所以我想使用strace查看mpirun的具体挂起位置，但使用SYS_PTRACE功能是不可能的。如果使用swarm，似乎没有办法设置它。因此，我尝试创建另一个容器，而不是在swarm中，它共享相同的覆盖网络：

docker run --network openmpi_openmpi-network   --rm -it openmpi-docker.registry:443/openmpi bash

此处

openmpi\u openmpi-network

是由“docker stack”创建的网络的名称。最初我打算用“特权”来运行它，但结果证明我不需要它

然后，我从根用户切换到普通用户，用相同的IP地址运行相同的mpi命令，该命令正常工作。所以我没有遇到同样的问题

在其他情况下，类似问题的解决方案只是关闭防火墙，但我很确定我没有在容器中安装防火墙。我自己从debian:9映像创建了映像，我安装的唯一服务器是sshd。这仍然不能解释在swarm中启动容器和使用

docker run启动容器之间的区别

这让我感到奇怪。首先，如何调试此类问题？第二，在swarm中启动服务和在网络方面手动启动服务有什么不同

如果你能帮我回答这两个问题，我将不胜感激

更新

我尝试使用“-mca oob_base_verbose 100”运行mpirun，结果如下。通信时间相对较长，但关键区别在于发起通信的节点的行为

I在启动器节点的某个MPI运行时的工作日志打印以下内容：

...
[3365816c2c1e:00033] [[39982,0],2] oob:tcp:init adding 10.0.1.4 to our list of V4 connections
[3365816c2c1e:00033] [[39982,0],2] TCP STARTUP
[3365816c2c1e:00033] [[39982,0],2] attempting to bind to IPv4 port 0
[3365816c2c1e:00033] [[39982,0],2] assigned IPv4 port 57161
[3365816c2c1e:00033] mca:oob:select: Adding component to end
[3365816c2c1e:00033] mca:oob:select: checking available component usock
[3365816c2c1e:00033] mca:oob:select: Querying component [usock]
[3365816c2c1e:00033] oob:usock: component_available called
[3365816c2c1e:00033] [[39982,0],2] USOCK STARTUP
[3365816c2c1e:00033] SUNPATH: /tmp/openmpi-sessions-1000@3365816c2c1e_0/39982/0/usock
[3365816c2c1e:00033] mca:oob:select: Inserting component
[3365816c2c1e:00033] mca:oob:select: Found 2 active transports
<Log output from other nodes>
[3365816c2c1e:00033] [[39982,0],2]: set_addr to uri 2620260352.0;usock;tcp://10.0.1.7,172.18.0.5:48695
[3365816c2c1e:00033] [[39982,0],2]:set_addr checking if peer [[39982,0],0] is reachable via component usock
[3365816c2c1e:00033] [[39982,0],2]: peer [[39982,0],0] is NOT reachable via component usock
[3365816c2c1e:00033] [[39982,0],2]:set_addr checking if peer [[39982,0],0] is reachable via component tcp
[3365816c2c1e:00033] [[39982,0],2] oob:tcp: ignoring address usock
[3365816c2c1e:00033] [[39982,0],2] oob:tcp: working peer [[39982,0],0] address tcp://10.0.1.7,172.18.0.5:48695
[3365816c2c1e:00033] [[39982,0],2] PASSING ADDR 10.0.1.7 TO MODULE
[3365816c2c1e:00033] [[39982,0],2]:tcp set addr for peer [[39982,0],0]
[3365816c2c1e:00033] [[39982,0],2] PASSING ADDR 172.18.0.5 TO MODULE
[3365816c2c1e:00033] [[39982,0],2]:tcp set addr for peer [[39982,0],0]
...

我仍然不明白为什么以及如何避免指定子网的需要。
Open MPI需要的不仅仅是主机之间的SSH连接。请尝试
mpirun--mca oob\u base\u verbose 100
查看您的处境。@GillesGouaillardet通过默认打开的MPI尝试所有可用子网进行更新。如果给定子网上的流量被防火墙丢弃，那么
oob/tcp
可能需要一段时间才能回落到另一个子网上（用户通常会在这种情况发生之前放弃）。由于
10.0.1.0/24
是
oob/tcp
的有效子网，您可能还需要将此子网传递到
btl/tcp
进行MPI通信。因此，您的
mpirun
命令行将是
mpirun--mca oob_tcp_如果包含10.0.1.0/24--mca btl_tcp_如果包含10.0.1.0/24…
作为旁注，如果您只需要容器，
singularity
是在考虑HPC的情况下构建的，并且完全由OpenMPI支持。谢谢您的建议，但我需要CRIU对我的容器的支持，所以我认为奇点不适合我。
...
[3365816c2c1e:00033] [[39982,0],2] oob:tcp:init adding 10.0.1.4 to our list of V4 connections
[3365816c2c1e:00033] [[39982,0],2] TCP STARTUP
[3365816c2c1e:00033] [[39982,0],2] attempting to bind to IPv4 port 0
[3365816c2c1e:00033] [[39982,0],2] assigned IPv4 port 57161
[3365816c2c1e:00033] mca:oob:select: Adding component to end
[3365816c2c1e:00033] mca:oob:select: checking available component usock
[3365816c2c1e:00033] mca:oob:select: Querying component [usock]
[3365816c2c1e:00033] oob:usock: component_available called
[3365816c2c1e:00033] [[39982,0],2] USOCK STARTUP
[3365816c2c1e:00033] SUNPATH: /tmp/openmpi-sessions-1000@3365816c2c1e_0/39982/0/usock
[3365816c2c1e:00033] mca:oob:select: Inserting component
[3365816c2c1e:00033] mca:oob:select: Found 2 active transports
<Log output from other nodes>
[3365816c2c1e:00033] [[39982,0],2]: set_addr to uri 2620260352.0;usock;tcp://10.0.1.7,172.18.0.5:48695
[3365816c2c1e:00033] [[39982,0],2]:set_addr checking if peer [[39982,0],0] is reachable via component usock
[3365816c2c1e:00033] [[39982,0],2]: peer [[39982,0],0] is NOT reachable via component usock
[3365816c2c1e:00033] [[39982,0],2]:set_addr checking if peer [[39982,0],0] is reachable via component tcp
[3365816c2c1e:00033] [[39982,0],2] oob:tcp: ignoring address usock
[3365816c2c1e:00033] [[39982,0],2] oob:tcp: working peer [[39982,0],0] address tcp://10.0.1.7,172.18.0.5:48695
[3365816c2c1e:00033] [[39982,0],2] PASSING ADDR 10.0.1.7 TO MODULE
[3365816c2c1e:00033] [[39982,0],2]:tcp set addr for peer [[39982,0],0]
[3365816c2c1e:00033] [[39982,0],2] PASSING ADDR 172.18.0.5 TO MODULE
[3365816c2c1e:00033] [[39982,0],2]:tcp set addr for peer [[39982,0],0]
...

mpirun -H 10.0.1.3,10.0.1.4,10.0.1.5,10.0.1.6  --mca oob_tcp_if_include 10.0.1.0/24  hostname