1. Docker pull 时报错如下：

-bash-4.2# docker pull hub.yj.com/test/dep_client:test
Error response from daemon: Get http://hub.yj.com/v2/: dial tcp: lookup hub.yj.com on 218.2.135.1:53: server misbehaving

如下图：

原因解析：

本地无法解析该域名（hub.yj.com），需要配置域名对应的DNS

解决方案：

vi /etc/resolv.conf

修改前：

# Generated by NetworkManager
nameserver 218.2.135.1

修改后：

# Generated by NetworkManager
nameserver 172.16.6.107  # 此行为增加部分，该IP为hub.yj.com域名对应的DNS地址
nameserver 218.2.135.1

再次docker pull即可成功

2. docker pull时报错如下：

[root@yunjia-03-centos7-135-in ~]# docker pull hub.yj.com/test/dep_client:test
Error response from daemon: Get https://hub.yj.com/v2/: dial tcp 172.16.6.253:443: getsockopt: connection refused

或者

[root@yunjia-03-centos7-135-in ~]# docker pull hub.yj.com/test/dep_client:test
Error response from daemon: Get https://hub.yj.com/v2/: dial tcp: lookup hub.yj.com on 218.2.135.1:53: read udp 172.16.6.104:57822->218.2.135.1:53: i/o timeout

原因解析：

主要原因是因为docker配置文件中没有配置该仓库地址，增加仓库地址即可

解决方案：

vi /etc/docker/daemon.json

修改前：

{
  "registry-mirrors": ["https://zanh3wut.mirror.aliyuncs.com"],
  "insecure-registries": ["172.16.6.108:8089"]   
}

修改后：

{
  "registry-mirrors": ["https://zanh3wut.mirror.aliyuncs.com"],
  "insecure-registries": ["172.16.6.108:8089","hub.yj.com"]   # 增加该仓库信息hub.yj.com
}

重启docker服务

-bash-4.2# systemctl restart docker

再去docker pull就可以成功pull了。

3. docker内部ping不通某服务的IP地址

现象：

进入docker里面，telnet或者ping某个服务或IP地址不通，但是退出docker后是通的。

原因：服务器需要做内部转发。

解决方案：

编辑服务器的/etc/sysctl.conf文件（docker外面的服务器），在文件最后增加如下内容：

#开启网桥模式
net.bridge.bridge-nf-call-ip6tables=1
net.bridge.bridge-nf-call-iptables=1
net.bridge.bridge-nf-call-arptables=1
#开启转发
net.ipv4.ip_forward=1

执行命令使其生效：

[root@VCS01 ~]# sysctl -p
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1
net.bridge.bridge-nf-call-arptables = 1
net.ipv4.ip_forward = 1
[root@VCS01 ~]#

能看到刚才新增的内容即生效了。

再进入docker验证就可以正常通了。

4. docker swarm部署服务后无法启动问题

   现象：

   部署完服务后服务无法启动，通过docker logs查看日志也没有任何日志，容器状态如下：

   

   排查方法：

   通过docker service ps --no-trunc {serviceName}命令可以看到容器的启动日志，如下：

   

   可以看出来是因为镜像地址或名称不对导致的，这时候我们就可以很快定位到问题原因了