在工作中、团队协作时,可能遇到的问题,如集成测试等场景。但是作为偏前端的全栈,锅从天上来,不是你想甩就能甩,尤其面对测试等比较强势的团体(bug创造者),你必须有强大的心理承受能力+冷静的分析。
我会记录一次次的经历,复盘分析和分享,以便大家以后能不背锅而爱工作(#^.^#)
一 上下文环境描述
- 部署使用docker compose
- 应用是nodejs app
- 数据库使用sqlite, prisma引擎
- 宿主机 ubuntu server,一个远程的虚拟机内
- 网络环境是内网nat
- 前端应用使用iframe集成到主应用
二 问题沟通记录
- 测试:提bug了,升级版本后看不到页面,报502,已截图
- 我:这关我啥事,我这边都没用到nginx
- 测试:是你这边的页面打不开!而且是xx提交新版本之后,之前都没问题的
- 我:那我看看
- 我:是从jenkins下载的最新archive包吗?
- 测试:是的啊!你看就是这儿
- 我:(好像没错)看看你的部署yml文件
- 测试:就改了个版本号(捣鼓了一阵)
- 我:那你把版本改回去看看
- 测试:之前是没问题的
- 我:先回退看看是不是没问题
- 测试:奇怪,也报错了(捣鼓一阵)
- 我:这是网络问题(巴拉巴拉一阵,报错有prisma push的时候,无法访问一个地址)
这时候,锅其实在我们这边了,内网docker部署,按理说,不该还需要访问外网的。但之前不知道这个,心里分析了下,应该是同步schema的时候,命令还是配置不对,但我们可不能认怂,改或者亲自研究可需要不少时间,所以:必须甩出去,然后悄悄改好!
- 我:你访问下这个网址,curl localhost:3000
- 测试:连不上 (remote reset, nodejs没跑起来,能脸上才怪)
- 我:curl一下这个报错的prisma地址
- 测试:也连不上
- 我:复制链接,在外面windows跑
- 测试:可以访问
- 我:这就是校验版本(我看页面是一个hash值,盲猜是校验hash确定版本完整性的)
- 测试:该咋办?
- 我:在里面ping一下baidu
- 测试:咦,ping不通
- 我:测试下route
- 测试:route没问题啊,是xxx.254
- 我:之前能启动?
- 测试:是的
- 我:是不是改什么网络配置了?巴拉巴拉(这时候一定要专业,脱口而出一大堆路由、防火墙、Nat的关键字)
- 测试:我没改啊
- 我:那可能是IT改了(反正不是我改的,而且网络都是IT部门控制的)
- 测试:那这就不好办了,还要测试呢
- 我:咦,你试着外面ping一下百度,拿到ip再里面ping ip
- 测试:ip可以通(一通操作)
- 我:那是dns出问题了
- 测试:哦,我确实改过一点东西,改了dnsname(说着cat了一个文件)
- 我:这里配置不对吧(虽然没见过这文件,但是个yml类似的,里面有route字段盲猜是路由配置to-via,还有个nameservices,我看就赔了一个本地的地址)
- 测试:这是配的ad域得地址
- 我:还加两行,114.114和8.8
- 测试:之前也没啊,就把这个默认路由所在ip改成了现在这个
- 我:先改了试试(我盲猜是因为以前默认路由作为dns服务时,它会把dns请求继续往上抛直到某个默认的DNS去)
- 测试:好了,可以通了(佩服)
- 我:那就好,以后改网络配置要注意啊(然后潇洒的走回去了)
三 复盘总结
- 先别接锅,没确定是我们的问题,不要假定是我们的问题(哪怕我们也有问题),不然会错过一些额外的原因,毕竟一次获得更多收获更好
- 别觉得麻烦,反正都是上班时间,就当离开休息下,毕竟指导人定位问题,比自己一直写代码会轻松一点点,尤其是写太久
- 要好好根据场景过一遍相关的知识点,哪怕不是很熟悉,关键字或者它的描述要记得
四 知识点解析
4.1 域名访问都需要DNS解析
只要是通过非ip使用http,都需要经过dns解析,Domain Name Solve,它类似于一个将域名映射到某个ip地址(http是基于ip协议的,所以发送出去之前需要知道目的地ip)
4.2 DNS解析先经过主机配置的ip映射
主机一般可以定义dns解析,例如windows的hosts文件,linux一般在/etc/hosts
4.3 DNS其次解析会经过DNS服务器
如果主机的配置没有包含目标域名,则会请求dns服务器
五 DNS服务器配置
5.1 windows
通过设置-网络和internet-连接界面配置
5.2 CentOS 配置自定义DNS服务器地址
5.2.1 编辑网络配置文件
在CentOS中,DNS服务器地址可以通过修改网络接口配置文件或全局的DNS配置文件来进行。
修改网络接口配置文件(适用于使用NetworkManager
的系统):
一般网络配置文件位于 /etc/sysconfig/network-scripts/ifcfg-<interface_name>
,例如:
sudo vi /etc/sysconfig/network-scripts/ifcfg-eth0
在文件中,找到或添加如下的配置:
DNS1=8.8.8.8
DNS2=8.8.4.4
修改、增删、保存文件并退出。
5.2.2 重启网络服务
为了使更改生效,必须重启网络服务或系统。
sudo systemctl restart NetworkManager
或者,针对特定的网络接口重启服务:
sudo ifdown eth0 && sudo ifup eth0
5.2.3 验证DNS设置
可以通过以下命令验证DNS是否配置正确:
cat /etc/resolv.conf
5.3 Ubuntu 配置自定义DNS服务器地址
Ubuntu系统上,特别是使用systemd-resolved
的版本,可以通过Netplan或直接配置DNS进行设置。
5.3.1 使用Netplan配置(Ubuntu 18.04及以后)
Netplan是Ubuntu的新网络管理工具,配置文件通常位于 /etc/netplan/
目录下。例如,编辑 50-cloud-init.yaml
文件:
sudo vi /etc/netplan/xxx.yaml
在对应的网络接口下,找到 nameservers
部分,修改为你想要的DNS服务器地址:
network:
version: 2
ethernets:
eth0:
dhcp4: yes
nameservers:
addresses:
- 8.8.8.8
- 8.8.4.4
保存并退出后,测试Netplan配置:
sudo netplan try
如果没报错就可以应用配置:
sudo netplan apply
5.3.2 通过 systemd-resolved
配置(推荐)
对于使用 systemd-resolved
的Ubuntu版本,可以通过 systemd-resolved
进行配置:
编辑 /etc/systemd/resolved.conf
文件:
sudo nano /etc/systemd/resolved.conf
找到或取消注释 DNS=
行并添加自定义DNS服务器:
DNS=8.8.8.8 8.8.4.4
保存并退出后,重启 systemd-resolved
服务:
sudo systemctl restart systemd-resolved
5.3.3 验证DNS设置
与CentOS类似,可以通过以下命令查看配置是否生效:
cat /etc/resolv.conf
如果你使用的是 systemd-resolved
,可以使用 systemd-resolve --status
查看详细信息。
六 总结
6.1 修改DNS服务器地址要小心
如果需要指向自定义的域名,若是单个地址,修改hosts文件会更快更稳。指向某个自定义dns服务器时,不要去掉了原来的dns服务器地址,而是添加地址
6.2 url不可达先分析DNS其次是路由
如果不是ip的地址,切勿忘记先检查DNS,哪怕觉得没有改什么
希望从我这次经历,前端想转后端的小伙伴等,能够学会分析和定位网络问题哈。有什么想补充的,欢迎留言