从一个小问题探讨解题思路

最新推荐文章于 2024-03-20 10:44:14 发布

运维Linux和python

最新推荐文章于 2024-03-20 10:44:14 发布

阅读量1.5k

点赞数 1

文章标签： java linux docker 分布式编程语言

本文链接：https://blog.csdn.net/TM6zNf87MDG7Bo/article/details/123587484

版权

序言

前奏一响，心一动，就是跑路的信号，从入门到删库。。。你看这篇文章，她像不像一封辞职信。

运维的终点在哪儿？如果运维的终点是没有运维，那么这一切又将有什么存在的含义？

风言风语

问题背景：

在容器升级的过程中，一般做的第一步就是把镜像从镜像仓库下载到本地机器，从而能大大加快升级时间，提升问题的解决效率，从而就会执行指令docker pull imagename:imagetag，出现报错如下：

Error response from daemon: Get https://registry-1.docker.io/v2/: 
dial tcp: lookup registry-1.docker.io on 
10.0.2.2:53: server misbehaving

解决思路：

首先看到报错信息，第一感觉就是无法解析网络，从而使用ping镜像仓库的地址，发现是可以解析并联通的。
再看报错中的url很奇怪，我们使用的url是私有的镜像仓库，这个地址是不对的，另外显示server misbehaving，第一眼看过去，还以为是说服务器不作为，翻译一下，看到是服务端异常。
查看一下相关的资料，大部分都是说无法解析地址，需要修改resolve配置文件
优先解决url不对的问题，从而使用docker login进行登录私有镜像仓库，再次尝试pull，问题解决。

如果你碰到了这个问题你该怎么解决？

在看到问题的时候，做的第一件事是判断优先级，这是一个紧急问题还是一个普通问题还是一个故障，如果是故障，那么就影响迅速收集业务的影响范围，五分钟之内发出故障通知。

优先级定了之后，就需要整理下思路该如何去解决了，首先观察告警信息，有没有碰到过，碰到过就按照既定方案走即可，如果没碰到，就要看下报错的细节，例如上面的报错中，关键字有镜像的url地址，报错的是在哪个dns服务器上进行解析报错的，其中的error response说明也已经链接上了docker进程。

大致的报错信息已经整理完成，这个时候应该想想相关的架构了，当使用docker pull的时候，命令会发送到dockerd进程，然后使用dockerd的配置去连接镜像中心，包括用户名，密码，url。。。这个地方主要思考的是理论结合目前具体的报错，来猜测目前的问题可能出现在哪儿，也进一步加深对理论的掌握，从而知行合一，其实蛮难的。

后面就是尝试一些具体的解决方案，看看是否能解决，从而逐步缩小问题可能出现的路径，可能是配置，可能是去查看一些其他的日志，是单独发生的还是整体发生的，从而判断是客户端问题还是服务端的问题。

如果没有思路怎么办，那就只能查一查，或者问问人。。。所以思路一般来自于对系统架构的了解，如果对架构不了解，那么这些问题都不知道从何下手。。。有的时候你会发现架构很简单，但是解决问题也无从下手，其实这是正常的，因为理论只是宏观上解决思路，而具体的报错需要了解很多的细节，就像一个小小的配置文件中的配置项。

看了这篇文章，你可能会掌握：

1 理论如何联系实际，不是空谈理论，也不是只着眼于现实，现实只是一个个问题的拼凑，不能成体系，而理论恰恰弥补这种缺陷。

2 理论的存在是让我们能解决未知的问题，让我们有一个排查的大方向，所以看理论的时候，可以演练这种情况，给自己提出一些问题，让自己来解，从而也有一个实际的经验可以参考。

--春风