HashiCorp Nomad任务组内任务间内网连通性配置问题咨询

核心疑问直接解答 #

• 同一Nomad任务组内的任务不存在默认互访权限，连通能力完全取决于作业里配置的网络模式，你当前遇到的连接拒绝就是网络模式配置错位导致的。
• 纯组内服务互通不需要强制启用Nomad Connect，有改动量极小的轻量实现方案。

你当前配置的报错根因 #

你现在给每个任务单独配置了mode = "host"的独立网络配置：

• host网络模式下，容器直接共享宿主机的网络栈，Docker配置里的port_map规则完全不生效，Nomad会给每个声明的端口随机分配一个宿主机高位端口做映射
• 这种配置下每个任务独立占用宿主机网络栈，组内没有共享网络上下文，你如果按记忆里的3306/5000/4000固定端口去访问其他服务，实际根本没有对应端口在监听，自然会触发连接拒绝
• 单任务独立配置host网络的设计，本身是为了单任务独占宿主机固定端口的场景，根本不支持同组内的服务互通

最简实现方案（零额外组件开销） #

把原来分散在每个任务下的网络配置上移到任务组层级，统一配置一次组级网络即可，不需要逐任务重复写网络规则：

1. 删掉每个task块内部resources下的所有network配置
2. 在group块的resources部分统一声明网络规则，把网络模式从host换成bridge，同时把三个服务的端口在组级别做固定映射
   改完的核心配置片段参考：

group "group" {
  count = 1
  # 组级统一网络配置，全组任务共享同一个虚拟网络空间
  resources {
    network {
      mode = "bridge"
      port "db" {
        static = 3306
      }
      port "app1" {
        static = 5000
      }
      port "app2" {
        static = 4000
      }
    }
  }
  task "db" {
    driver = "docker"
    config {
      image = "dbimage"
      port_map {
        db = 3306
      }
    }
    env {
      MYSQL_DATABASE = "db"
      MYSQL_ROOT_PASSWORD = "pass"
    }
    service {
      name = "db"
      port = "db"
    }
    resources {
      memory = 256
    }
  }
  # app1、app2的task块同理，保留原有的image、env、service配置，删掉各自块里的network配置即可
}

这种配置的实际运行效果：

• 同组所有任务被接入同一个独立的虚拟网桥网络，等效于所有容器运行在同一个本地二层网络里
• 组内互访不需要做服务解析，直接用localhost加对应固定端口就能打通，比如app1的代码里直接写localhost:3306就能访问db服务，不会出现连接拒绝
• 原有的service注册逻辑、Nomad注入的地址变量完全兼容，对外暴露端口的行为和你之前的配置一致，不需要额外改服务发现的逻辑

关于Nomad Connect的适用场景 #

• 只有当你需要实现跨任务组的服务访问、服务网格流量管控、mTLS加密、细粒度访问策略时，才需要开启Nomad Connect能力
• 单任务组内部的服务互通，上述组级bridge网络模式是改动最小、性能开销最低的方案，没有任何额外组件依赖

常见踩坑提醒 #

• 只要有一个任务单独配置了host网络模式，组内的共享网络空间就会失效，必须确保所有任务的网络权限都走组级统一配置
• 组级bridge网络下的静态端口不要在不同任务的port_map中重复声明，避免同网络空间下的端口冲突

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