如何将Jenkins与多Docker容器搭建连接？两种场景求最优方案

我之前在项目里遇到过几乎一模一样的网络连通问题，分享几个亲测有效的方案，覆盖你的两种场景：

场景1：Jenkins部署在宿主机，连接独立Compose启动的容器 #

你提到宿主机无法ping通容器、SSH连接失败，核心原因是默认情况下，Docker自定义网络（Compose默认创建的网络）和宿主机物理网络是隔离的，宿主机不能直接通过容器名称解析，甚至可能无法访问容器所在的子网。可以用下面两种方案解决：

方案A：端口映射+宿主机IP访问 #

既然Node和Mongo容器已经暴露了22端口，直接在它们的docker-compose.yml里把22端口映射到宿主机的不同端口，避免冲突：

services:
  node-app:
    image: your-node-image
    ports:
      - "2222:22"  # 宿主机2222端口映射到容器22端口
    # 其他配置...
  mongo-db:
    image: your-mongo-image
    ports:
      - "2223:22"
    # 其他配置...

之后在Jenkins里配置SSH服务器时，直接用宿主机IP+对应映射端口（比如192.168.1.100:2222）就能连接到Node容器，192.168.1.100:2223连接Mongo容器。

方案B：自定义网络+宿主机路由配置 #

如果不想用端口映射（避免端口占用问题），可以创建一个可被宿主机访问的自定义网络：

1. 先创建自定义网桥网络：

docker network create --subnet=172.25.0.0/16 jenkins-docker-net

2. 在Node/Mongo的docker-compose.yml里指定使用这个网络：

networks:
  default:
    external:
      name: jenkins-docker-net

3. 给宿主机添加路由，让宿主机能访问这个子网：

# 先查看这个网络对应的网桥名称，比如br-xxxxxx
docker network inspect jenkins-docker-net | grep "Gateway"
# 添加路由（替换br-xxxxxx为实际网桥名称）
ip route add 172.25.0.0/16 dev br-xxxxxx

完成后，宿主机就能直接ping通容器的IP，Jenkins也可以通过容器IP+22端口SSH连接。如果想用容器名称访问，还可以在宿主机配置Docker DNS解析（比如安装dnsmasq并转发DNS请求到Docker的DNS服务器），不过IP访问更直接可靠。

场景2：Jenkins容器与独立Compose容器的跨Compose网络连通 #

你遇到的问题是Docker Compose默认会为每个项目（默认是目录名）创建独立的网络，即使名称相同也会生成不同的网桥。解决核心是让两个Compose的容器加入同一个共享网络：

最优方案：创建外部共享网络 #

1. 先创建一个全局的外部网络：

docker network create shared-build-net

2. 在Jenkins的docker-compose.yml里配置使用这个外部网络：

services:
  jenkins:
    image: jenkins/jenkins:lts
    networks:
      - shared-build-net
    # 其他配置...
networks:
  shared-build-net:
    external: true

3. 在Node/Mongo的docker-compose.yml里同样配置使用这个外部网络：

services:
  node-app:
    image: your-node-image
    networks:
      - shared-build-net
    # 其他配置...
  mongo-db:
    image: your-mongo-image
    networks:
      - shared-build-net
    # 其他配置...
networks:
  shared-build-net:
    external: true

这样两个Compose里的容器都会加入同一个网络，Jenkins容器可以直接通过容器名称+22端口（比如node-app:22）SSH连接，不需要任何端口映射，网络完全隔离且易于迁移。

关于当前部署方案的评估 #

你当前把Jenkins部署在宿主机、挂载容器卷到宿主机的方案，不是最优解：

• 耦合度高：宿主机和容器的存储、网络绑定紧密，迁移到新环境时需要重新配置卷挂载、网络路由，不符合容器化“一键部署”的初衷；
• 扩展性差：如果后续需要多节点部署容器，宿主机无法直接访问其他节点的容器；
• 维护成本高：宿主机的环境变化（比如系统升级、Docker版本更新）可能直接影响Jenkins和容器的连通性。

更推荐的方案是把Jenkins容器化，配合外部共享网络（场景2的方案），这样整个部署可以通过两个docker-compose.yml一键启动，完全符合你“在其他环境中复制部署”的需求。

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