开开心心打开电脑,wsl2一跑,再拽两个cd命令,docker一跑,bug未到断网先到。
噢,又是美好而又值得纪念的一天。

排查过程与思路

导火索是docker容器内go包拉不下来,拉了一遍又一遍,逐渐开始怀疑人生。

怀疑人生系列一:go包代理可能是个内鬼

使用的go包代理是https://goproxy.cn/,所以怀疑可能是代理是个出现了问题,goproxy之前是有出现过不稳定的情况,然而实践验证后发现是自己想太多。

go包拉取报错Get "https://goproxy.cn/github.com/xxx/xxx/@v/v0.0.0-xxx.zip": dial tcp: lookup goproxy.cn,所以首先反应的是在容器内ping该网址以及其他常用网址,发现都是GG。容器内ping不通,自然想到跑来宿主机ping,一ping更是GG,报错ping: www.xxx.com: Temporary failure in name resolution

怀疑人生系列二:wsl2可能罢工了

根据上个系列,怀疑是win宿主机的wsl2网卡或者dns解析出了问题,对着相关配置一番排查,发现并无异常,毕竟平时也很少动网卡配置。由于还使用netsh端口转发,排查过程略过不表,结论是无关。所以这个系列又完结了。

怀疑人生系列三:没有什么复杂的环境出问题,是重启一次解决不了的

根据人生经验,如果环境出了问题解决不了怎么办?那就重启一次。如果重启一次还是解决不了怎么办?那就重启两次。

因为wsl2先出的问题,只好对wsl2先下手。重启之后,果然不出所料,ping一下,立马起飞。

感觉人生都要起飞时,docker命令一跑,再到容器一ping,炸了。

退出容器一ping,wsl2也炸了。

不是说好的没有什么环境出问题是重启一次解决不了的吗?

怀疑人生系列四:谁动了我的奶酪

几经周折,怀疑人生终于快要完结。很明显,docker动了我的奶酪。

但是此时,又一个疑惑产生,真正的原因是因为我写的是docker-compose文件容器使用的network导致,还是docker服务的network导致的呢。

排查这个问题太难了,我选择启动docker服务ping一次,启动docker-compose容器再排查一次。事实是,我选择启动docker服务之后ping了一次,就抓到了这个罪魁祸首,就是docker服务。

使用route -n或者ifconfig就能发现网段是真的冲突了。

Snipaste_2023-01-17_11-29-36.jpg

噢,空气都变香甜了。

放开那个网段

因为wsl2的ip如果没有设置为静态,默认是自动分配,所以今天wsl2和docker的网段终于遇上了。

在此之前,从未想到,原来这tm也能冲突。

解决思路一:指定dockr0网段ip
1、停止docker服务 service docker stop
2、删除docker0网卡 ip link del docker0 down
3、在docker配置文件vim /etc/docker/daemon.json指定自己想要的网段ip

{
  "bip":"172.17.19.0/24"
}

解决思路二:重启大法

理论上来说,这次wsl2网段和docker0网段撞车是因为wsl2自动分配ip导致,那么只需要开机重启,wsl重新分配ip之后可能就不冲突了。重启win宿主机的次数越多,不冲突的概率就越大。

nice,既然已经有了扎实的理论基础,那我选择解决思路二。

手动滑稽^_^

没有什么问题是重启一次解决不了的,如果有,那就重启两次。

哇噢,又是美好的一天,从重启电脑开始。


本文由 大古 创作,采用 知识共享署名 3.0,可自由转载、引用,但需署名作者且注明文章出处。

还不快抢沙发

添加新评论