Docker容器内启动的子容器无法解析API主机的网络配置问题

这个问题我之前也碰到过，核心原因其实很简单：通过容器内的docker.sock启动的子容器，默认不会加入你的docker-compose项目创建的自定义网络。

直接运行curl-test服务时，docker-compose会自动把它拉进项目专属的网络里，Docker内置的DNS能直接把api这个服务名解析成对应的容器IP，所以请求正常。但network-test通过宿主机的docker.sock启动子容器时，子容器默认连接的是宿主机的默认bridge网络，这个网络里根本找不到api服务的DNS记录，自然就报"could not resolve host api"了。

下面给你两个靠谱的解决方案：

方案1：显式指定子容器加入compose的自定义网络 #

首先得搞清楚你的compose项目用的网络名称：

• 如果没在compose文件里自定义网络，默认网络名是[你的项目文件夹名]_default（比如项目放在my-demo文件夹，网络就是my-demo_default）
• 更推荐的是在compose文件里手动指定固定网络名，避免依赖文件夹名称，比如：

  version: '3.8'
  networks:
    app-net:
      name: app-net  # 固定网络名，不会随文件夹变化
  services:
    api:
      image: your-api-image
      networks:
        - app-net
      ports:
        - "3000:3000"
    network-test:
      image: docker:cli
      volumes:
        - /var/run/docker.sock:/var/run/docker.sock
      networks:
        - app-net
    curl-test:
      image: curlimages/curl
      command: curl http://api:3000
      networks:
        - app-net
  

然后修改network-test里启动curl-test的命令，加上--network参数指定这个网络：

docker run --network app-net curlimages/curl curl http://api:3000

这样子容器就会加入到compose的专属网络，DNS解析自然就正常了。

方案2：让子容器共享network-test的网络命名空间 #

如果你不想记网络名称，可以直接让子容器复用network-test容器的网络环境，启动命令改成这样：

docker run --network container:network-test curlimages/curl curl http://api:3000

--network container:xxx参数会让新容器直接使用指定容器的网络栈，这样子容器和network-test处于同一个网络环境，自然能访问到api服务。这种方式更灵活，不用关心具体的网络名称。

本质上就是要让子容器和api服务处于同一个Docker网络里，只要满足这个条件，服务名解析就没问题啦。

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