Docker 的普及促使众多应用迁至其上部署，得益其诸多优势。然而，相较于传统非 Docker 环境中各应用通过 127.0.0.1:端口 即可轻松互访，Docker 容器若未经端口映射，彼此间端口则无法直接相通。是否存在更优方案以应对这一挑战？
1 场景描述
场景简述：alpine-client 与 alpine-server 两容器，前者访问后者监听之端口，以此探析 Docker 内部容器间端口访问机制。
2 建立两个容器
2.1 通过 Dockerfile 构建镜像
由于这次测试功能很简单，可以通过一个 Dockerfile 来创建容器，一个镜像加载成两个容器，容器里执行的代码不同而已。
2.1.1 创建 Dockerfile 文件此 Dockerfile 可以用做一个通用的模板，包含了基本功能框架，用户可以自行在此基础上修改。
# 以 alpine:3.10 为基础镜像 FROM alpine:3.10 # 设置镜像源为清华大学镜像 RUN echo “https://mirrors.tuna.tsinghua.edu.cn/alpine/v3.10/main” > /etc/apk/repositories && echo “https://mirrors.tuna.tsinghua.edu.cn/alpine/v3.10/community” >> /etc/apk/repositories && apk update && apk upgrade # 安装依赖包及工具 RUN apk add –no-cache bash netcat-openbsd # 设置工作目录 WORKDIR /root # 拷贝需要的文件，支持通配符 # COPY *.sh /root/ # 在 Dockerfile 中添加Entrypoint test.sh，根据需要添加即可 # ENTRYPOINT [“/bin/bash”, “-c”, “/root/test.sh”]简单解释一下这个 Dockerfile 模板文件：
1）引用基础镜像这个必须有（此语句后面的语句都是可选项），且必须是第一句。我习惯引用 alpine 镜像，体积小巧、功能强大。
2）设置镜像源先改写镜像路径文件，并运行 update、upgrade，使更改生效。关于镜像源，清华、阿里、根据您的喜好选择就可以了，主要是用来加快软件安装速度。
3）安装依赖包及工具使用 RUN 命令来执行依赖包及工具的安装，安装工作最好是在一个命令里执行完成，这样镜像就不会添加很多层，导致镜像文件变大。其中”&;是用来将分行的命令字符串串接起来，”&&”是用来按序依次安装多个命令。
4）设置工作目录设置工作目录后，容器内部默认目录就是设置的工作目录，方便操作。
5）拷贝需要的文件这一步可以将需要的文件从本机拷入镜像文件。
6）执行 ENTRYPOINT 入口脚本（或者使用CMD）当容器启动时，会执行此处指定的脚本或命令。
2.1.2 编译镜像 docker build -t alpine-net:1.0.0 . 2.2 生成容器生成 alpine-client 容器：
docker run -itd –name alpine-client alpile-net:1.0.0生成 alpine-server 容器：`
docker run -itd -p 8888:8888 –name alpine-server alpile-net:1.0.0alpine-server 容器加了一个端口映射，将 alpine-server 里监听的 8888 端口映射到该容器的宿主机的 8888 端口。
3 获取 IP 地址
3.1 获取 alpine-client 相关 IP 地址
3.1.1 获得 alpine-client 容器本身的 IP 地址在 alpine-client 终端输入：
ifconfig
运行后返回结果如下：
eth0 Link encap:Ethernet HWaddr 02:42:AC:11:00:02
inet addr:172.17.0.2 Bcast:172.17.255.255 Mask:255.255.0.0
UP BROADCAST RUNNING MULTICAST MTU:65535 Metric:1
RX packets:197 errors:0 dropped:0 overruns:0 frame:0
TX packets:89 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:22832 (22.2 KiB) TX bytes:5821 (5.6 KiB)lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:7 errors:0 dropped:0 overruns:0 frame:0
TX packets:7 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:524 (524.0 B) TX bytes:524 (524.0 B)得到两个 IP ，127.0.0.1 和 172.17.0.2
3.1.2 获取 alpine-client 容器网关 IP 地址在 alpine-client 终端输入：
route -n
运行后返回结果如下：
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 172.17.0.1 0.0.0.0 UG 0 0 0 eth0
172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0得到网关 IP 地址：172.17.0.1。
3.1.3 获取 alpine-server 容器网关 IP 地址同上操作，过程略。
可以得到 alpine-server 相关地址：
alpine-server 本机地址：127.0.0.1 和 和 172.17.0.3
alpine-server 网关地址：172.17.0.14 测试访问
在 alpine-server 的终端里输入网络端口监听命令：
nc -lk 8888 # 监听 8888 端口监听 8888 端口，测试让 alpine-client 连接。以下如果没有特殊说明，默认命令行运行窗口为 alpine-client 的终端窗口
4.1 通过容器名称访问
nc alpine-server 8888返回：
nc: getaddrinfo: Name does not resolve提示：目标容器名 alpine-server 找不到，所以连接失败！
4.2 通过容器 IP 访问
nc 127.17.0.3 8888连接失败！说明容器端口并没有对“隔壁”容器开放。
4.3 通过网关 IP 访问
nc 127.17.0.1 8888连接失败！说明容器端口映射，并不是映射到网关上。
4.4 通过 docker 宿主机名访问
docker 提供了一个宿主机名：host.docker.internal，所有容器都可以访问到这个主机名。测试：
nc host.docker.internal 8888连接成功！且在 alpine-client 输入的信息可以成功发送到 alpine-server，且实现的是双向通讯。可以通过 host.docker.internal 这个主机名可以访问到容器映射/出来的端口，但无法访问到容器内部的端口。
4.5 通过 docker-compose 创建容器的方案
此部分在我的博文《docker安装、调试qsign签名服务器》里已经应用过，此处就不再赘述。这种方式的 docker-compose.yml 文件已经定义好了容器之间的关系，将各个容器纳入一个统一的网卡里，灵活性稍差一点，推荐用在成熟、稳定的项目里。
此文描述的方式是采用“分离式”，各个容器是独立的，容器之间的联系通过映射端口的方式，通过 host.docker.internal 进行连接，便于动态灵活调整连接关系，以及系统的扩展等。
5 总结
在未实施容器分组编排的场景中，本文深入探究并揭示了一种利用 host.docker.internal 实现容器间直接互访的有效途径。相较于传统的基于 IP 地址的访问方式，选用 host.docker.internal 作为连接标识具有显著优势：
1）稳定性增强：在容器内部的配置文件中，可以将 host.docker.internal 作为固定的目标地址进行硬编码（即“写死”）。此举消除了因依赖动态分配或可能变动的 IP 地址而导致的配置脆弱性。当容器重启、迁移或者网络环境发生调整时，IP 地址可能会发生变化，而使用 host.docker.internal 则能确保连接指向始终有效，无需随 IP 变动而频繁更新配置。
2）简化管理：采用 host.docker.internal 作为连接字符串，简化了容器间交互的管理复杂度。运维人员无需跟踪每个容器的具体 IP 地址，也不必在 IP 变化时手动调整关联容器的配置文件。这种抽象化的寻址方式使得容器间的依赖关系更为清晰，易于理解和维护。
3）兼容性与可移植性提升：host.docker.internal 是 Docker 系统内建的特殊域名，旨在提供一种标准、跨平台的方式来访问宿主机提供的服务。这意味着无论宿主机的实际IP如何变化，或者在不同的部署环境中（如开发、测试、生产），只要支持 Docker，该域名即可确保容器间的互访顺利进行。这种设计增强了容器应用在不同环境中的兼容性和可移植性。综上所述，在无编排工具介入的情况下，利用 host.docker.internal 进行容器间的互访是一种既稳健又便捷的选择。它不仅避免了因 IP 变动引发的连接失败问题，还简化了管理流程，提升了应用在不同 Docker 环境下的适应性。
暂无评论内容