解决一个看似简单的docker拉取镜像问题 - Docker

测试同学反馈他们有个测试机器断电恢复后无法去拉取Docker镜像了，然后发来了系统登录信息。原本以为这是一个简单的由墙造成的镜像拉取问题，大概率就是设置的代理未生效或者因为断电造成的数据损坏，结果还是低估了问题的难度。

注：从测试同学提供信息看系统是 LInux，有root权限，服务器在公司内并可以访问Internet。

解决思路

以下是处理这个问题的大致思路：

复现问题，通过问题现象或报错找问题的原因；
检查服务配置文件，确认配置文件正确；
检查服务是否正常；
检查进程是否正常；
检查服务日志、内核消息是否存在异常；
最后可以采用重装服务的方式兜底；

处理经过

以下是处理这个问题的经过：

登录服务器，确认服务器信息，通过motd信息查看是Ubuntu 22.04.5 LTS (GNU/Linux 5.15.0-157-generic x86_64)，系统负载正常、无资源压力；

执行docker info发现可以执行，并且输出信息中查看Docker服务端版本是28.1.1+1，但确实没有代理设置相关信息；

查看默认的docker配置文件 /etc/docker/daemon.json ，确认配置文件正常，格式、语法、权限、配置都完全正确；

通过 journalctl -xe -u docker.service 查看服务日志，确认服务正常，没有报错；

通过 systemctl status docker.service 检查Docker服务状态正常，docker.service 文件路径和内容正常；

因为之前注意到docker info中显示的客户端和服务端版本较高，所以查看Docker官方文档看看有无变更，发现没有变更；

进入测试同学指定的docker compose目录执行docker compose pull，发现确实无法拉取，提示“Error Get "https://registry-1.docker.io/v2/": read tcp 10.0.2.181:52072->198.44.185.131:443: read: conne...”，确实没有使用代理；

为了让docker加载配置文件/etc/docker/daemon.json，使用 dockerd 的 --config-file 参数修改systemd unit 文件后执行，发现不起作用；

使用 dmesg 命令检查内核和Apparmor等消息没有发现问题；

使用 ps 命令检查docker的进程，发现了问题：

从结果可知，这个机器上运行有Kubernetes组件，且有两个 dockerd 进程，一个是我们常见的/usr/bin/dockerd进程一个是snap的dockerd进程，因此必须把snap这个干掉；

通过 snap services 列出运行中服务，通过 snap stop docker.dockerd 停止服务，通过 snap remove docker --no-wait --purge --terminate 命令强制删除；

再次执行 docker info，发现新的问题，原先可以正常显示，但现在服务端提示“Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?”，这通常表示docker客户端还是有问题，正常应该是“/run/containerd/containerd.sock”这个

于是计划重新安装 Docker 引擎，先尝试使用 apt upgrade 升级，再清理docker后重新安装Docker engine发现问题依然存在，怀疑是 k3s.service 的影响，于是经过沟通后先停止 k3s 服务，重启 containerd.service 和 docker.service 后解决。

根因分析

造成这个问题的原因可能是由于测试同学需要测试的对象较多，而日常维护不到位，断电重启后服务自启动后存在了冲突。

改进建议

测试环境需要注意环境整洁，使用后注意整理和还原；
积累知识和总结经验；
统一包管理工具，命令行环境中尽量减少snap的使用；