「Docker」- 常见错误汇总 @20210315

#6 构建镜像是，执行 chown -R 非常慢

Docker images and files chown
Recursive chown is really slow #388

问题描述：
如果在Dockefile中包含chown -R /path/foo命令，则构建镜像时间将非常久。

问题原因：
由与Docker使用写时复制策略，所以chown命令执行时，会将上层镜像文件全部复制到当前层，然后再修改权限，再写入文件系统。

在「使用chown -R命令」与「不使用chown -R命令」情况下，分别构建两个镜像，使用docker history命令可以看到镜像层。你会发现在包含chown -R命令时，镜像层将消耗很多空间。

解决办法：
不应该使用chown之类大批量修改文件的命令。

#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 笔记中。

#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

#3 Error response from daemon when pulling a specific image tag from DTR

-「Error response from daemon when pulling a specific image tag from DTR」
TODO Error response from daemon: manifest for xxx/xxx/xxx:xxx not found

#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

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

相关文章

「Docker」- 获取帮助和改进
「Docker」- 日志驱动（Logging Driver）
「Docker」- 借助工具，以树形图的形式，查看镜像层
「Docker」- 保存镜像到本地
「Docker」- 安装（Debian/Ubuntu）

参考文献

Docker frequently asked questions (FAQ) | Docker Documentation