事情是这样的，在搭建流水线时，我首先部署了一台虚拟机来跑gitlab服务和jenkins服务，两者都以容器的形式来进行运行，并且容器内部的端口都通过映射到宿主机来实现容器间端口的互通。
但是在做着做着，我发现在Jenkins的页面在做项目配置的时候，一直显示拉取不到仓库的代码，一直报错No route to host。
在进入容器内部是可以ping通宿主机的，但是telnet宿主机的222端口却死活不通。
为此，我查询了大量文档，说是docker容器网络要改成主机模式，什么容器内部没有安装git客户端啥的，公钥私钥配置错误之类的，自己反复检查了几遍也发现根本就不是这些问题，问AI也只会重新大改容器，而不解释如何排查出真正的原因。
后来，我向外界寻求技术支持，远程帮助我解决了这个问题。
在他的指导下，大概意思就是，我的服务器在最开始启动容器之前便一直在开启着Firewalld服务，然后在启动docker容器的同时，docker会自动添加对应的iptables的规则。
但是经排查发现对于那几个我要用到的端口的规则，Firewalld是缺少的。
如果要在启动防火墙的情况下启动那些容器，并且Jenkins容器可以访问到gitlab容器的80端口或者是22端口，都需要配置相应的防火墙规则，才会让容器内部也产生相应的iptables规则。因为我把gitlab容器的4433端口映射到了宿主机的4433，22端口映射到了宿主机的222。
所以应该要添加firewalld规则，如下。
fire-cmd --zone=public --add-port=4433/tcp --permanent
fire-cmd --zone=public --add-port=222/tcp --permanent
fire-cmd --zone=public --add-port=7070/tcp --permanent (jenkins的7070被映射到了宿主机的8080)
firewall-cmd --reload
然后再重新启动容器才能实现，容器间的端口互通。
或者直接在关闭firewalld的情况下再启动容器，也不会有容器间不通的情况。
然后基于这种情况我再换了关键词去网上搜索，觉得以下这篇文章似乎就是讲的我这种情况
https://www.jb51.net/server/336273xq7.htm
我理解的大概意思就是：
网络模式为桥接模式下的docker容器在访问宿主机时，数据会以docker0的虚拟网桥的地址发送给宿主机，但是宿主机的firewalld并没有设置允许docker0的网段的流量，所以会被防火墙拦截。从而导致了No route to host的结果。
所以，要解决这个问题，要么先添加好firewalld的规则，再启动docker容器，要么直接关闭firewalld再启动容器，都可以解决这些问题。