Question

我们在运行Alpine映像（基于php：7-alpine的PHP编写器）时遇到问题。

它在AWS的EC2实例中运行，我们注意到下载软件包会花费太多时间。

事实证明，这是DNS解析问题，需要花费太多时间来解析域。

示例：

第一个午餐是作曲家的容器：

docker run --rm -it composer sh

然后在容器内部运行：

time curl https://packagist.org/packages/list.json?vendor=composer  --output list.json
% Total    % Received % Xferd  Average Speed   Time    Time     Time  
Current
                             Dload  Upload   Total   Spent    Left  
Speed
100   174    0   174    0     0     58      0 --:--:--  0:00:03 --:--:--    48
real    0m 3.61s
user    0m 0.01s
sys 0m 0.00s

但是我们使用-4选项将ipv4明确用于curl命令，它的运行速度更快：

time curl -4 https://packagist.org/packages/list.json?vendor=composer  --output list.json
% Total    % Received % Xferd  Average Speed   Time    Time     Time  
Current
                             Dload  Upload   Total   Spent    Left  
Speed
100   174    0   174    0     0    174      0 --:--:-- --:--:-- --:--:--  1359
real    0m 0.13s
user    0m 0.01s
sys 0m 0.00s

进一步的调查显示，将options single-request-reopen添加到/etc/resolv.conf只能解决基于Debian的图像的问题，而不能解决高山的问题。

一种快速的解决方法是运行容器，并通过添加此选项--net=host将主机网络附加到该容器，但是我们正在运行Jenkins构建，因此我们不希望将此选项添加到所有Makefile中。项目。

以下是nslookup给出的结果：

time nslookup google.com
nslookup: can't resolve '(null)': Name does not resolve

Name:      google.com
Address 1: 216.58.207.174 muc11s04-in-f14.1e100.net
Address 2: 2a00:1450:4016:80a::200e muc11s12-in-x0e.1e100.net
real    0m 2.53s
user    0m 0.00s
sys     0m 0.00s

Answer 1

A great explanation about the issue and possible solutions: https://www.weave.works/blog/racy-conntrack-and-dns-lookup-timeouts

带有DNS解析的Docker Alpine映像问题（缓慢）

1 个答案: