「Docker」- 常见错误汇总

  FROM JENKINS AUTOMATION

更新日期:2019年08月29日

#5 GitHub / DNS Issue #255

# 相关链接:
DNS Issue #255
DNS/IPV6 Problem #153
What does it mean when I get a server failure when connecting to a router with DNS protocol

# 问题描述:
宿主机centos 4.18.12-1.el7.elrepo.x86_64,镜像apline。在容器里PING某个域名,在进行DNS解析时会有一段时间的延迟。

使用tcpdump抓包,发现:在容器中,当PING某个域名时,发出两次DNS查询,一个IPv4的A记录,一个IPv6的AAAA记录。当DNS查询记录为A类型时,是整正常的。当DNS查询类型为AAAA时,返回的DNS状态码是SERVFAIL(RCODE=2)。当然,我们的DNS服务器中并没有IPv6的记录,但是返回SERVFAIL是不正常的(我查了返回SERVFAIL的原因)。但是,在容器中PING百度时是正常的。因为BAIDU的IPv6返回的不是ServFail状态,而是IPv6地址。

使用PING -4时,马上返回结果,因为值进行了IPv4的A记录解析。然后,结合「DNS Issue #255」中的描述,我们将问题的焦点放在了DNS上,DNS服务器是BIND,使用它的了DLZ技术。

!!!这里面有很多猜疑的成分,由于不具备某些方面的知识,正确的思路是:在PING出现问题的时候,进行调试,堆栈追踪,找到程序的行为,然后确定是DNS返回的SERVFAIL导致了程序的延迟,然后了解SERFFAIL的状态值、含义、返回原因,然后综合处理问题。

# 问题原因:
问题是DNS服务器返回SERVFAIL状态导致的。该状态导致了PING命令延迟。(这里面存在猜疑的成分,但是结论的可信度还是很高的)

还有一方面,好多程序开始尝试同时进行IPv4的A记录和IPv4之上的AAAA记录的解析。在PHP的CURL中,也出现了类似的现象,但是我没有进行验证,只是相信是同样的原因。时间成本太高了,还有很多其他的事情要做,又不是只解决这个一个问题。

# 解决方法:
解决方法由以下几个:

  • 从根本上解决DNS服务器返回SERVFAIL状态的。(我们采用的方案)
  • 更换镜像或者依赖程序类库,来使得解析的时候只进行IPv4的A记录解析。(不根本,影响后期IPv4切换)
  • 调整容器,修改/etc/resov.conf配置,设置timeout和attempts选项,减少重试和超时。(不根本,时间粒度大,影响体验,最多就是暂缓问题)
  • 调整容器,在/etc/hosts手动绑定。(反对,最多就是暂缓了问题,依旧没有解决问题)
  • 还有一些其他的办法,最后都被过滤掉了。技术不可行,或者工作量太大。

该问题特定于BIND的DLZ技术,问题已经记录在「BIND DLZ」中。

#4 are you trying to connect to a tls-enabled daemon without tls

问题描述:
非Root用户执行docker命令时,产生如下错误:

Post http:///var/run/docker.sock/v1.19/auth: dial unix /var/run/docker.sock: permission denied. Are you trying to connect to a TLS-enabled daemon without TLS?

问题原因:
这实际上是一类问题,非Root用户管理Docker时,权限不足的问题。

Docker进程运行时,使用了Unix socket,默认属于root用户和root组,所以只有root能访问。

如果非root用户想要管理,则需要使用sudo,或者使用其他方法(见下文)。

解决办法:
Manage Docker as a non-root user

#!/bin/sh

groupadd docker

usermod -aG docker "target user"

systemctl restart docker.service

# !!! 使用docker组所授予的权限等同于root用户。
# !!! 对戏系统安全的影响,参考:https://docs.docker.com/engine/security/security/#docker-daemon-attack-surface

#3 exec user process caused “exec format error”

exec user process caused “exec format error” when run container with CMD on RHEL
启动容器时产生该错误。

该镜像的CMD是一个SHELL脚本,该将本没有添加「shebang」,导致运行时无法识别脚格式。

在启动脚本中添加「shebang」,即「#!/bin/sh」

#2 x509: cannot validate certificate because of not containing any IP SANs

# TODO 使用自签名的SSL证书情况下,如何登录Registry

#1 想不到的错误

在我的Debain中运行:docker run --rm -t -i centos:6.10 /bin/bash

直接退出,退出码为139;但是执行其他的ls或者cat之类的命令是正常的。

centos:6.10的镜像也可以在CentOS Linux release 7.4.1708 (Core)上正常运行;

使用dmesg查看系统输出:

[2023147.282206] docker0: port 2(veth2016d06) entered blocking state
[2023147.282209] docker0: port 2(veth2016d06) entered disabled state
[2023147.282463] device veth2016d06 entered promiscuous mode
[2023147.286060] IPv6: ADDRCONF(NETDEV_UP): veth2016d06: link is not ready
[2023147.967258] eth0: renamed from veth4bc81c0
[2023147.991101] IPv6: ADDRCONF(NETDEV_CHANGE): veth2016d06: link becomes ready
[2023147.991191] docker0: port 2(veth2016d06) entered blocking state
[2023147.991196] docker0: port 2(veth2016d06) entered forwarding state
[2023148.163593] bash[21306] vsyscall attempted with vsyscall=none ip:ffffffffff600400 cs:33 sp:7ffce2f568d8 ax:ffffffffff600400 si:7ffce2f57f76 di:0
[2023148.163598] bash[21306]: segfault at ffffffffff600400 ip ffffffffff600400 sp 00007ffce2f568d8 error 15
[2023148.363842] docker0: port 2(veth2016d06) entered disabled state
[2023148.363977] veth4bc81c0: renamed from eth0
[2023148.487894] docker0: port 2(veth2016d06) entered disabled state
[2023148.493036] device veth2016d06 left promiscuous mode
[2023148.493044] docker0: port 2(veth2016d06) entered disabled state

应该是内核版本导致的系统调用失败(我的猜测)。具体原因就不知道了,不是那个方向啊。




文章摘要:Cloud-native_Technologies:Docker:z.Error_List_(Docker)

原文链接:「Docker」- 常见错误汇总