Docker 连接问题(从自托管 Linux Docker 代理到 Azure DevOps 服务)
Docker connectivity issues (to Azure DevOps Services from self hosted Linux Docker agent)
我正在寻找一些关于调试一些极其痛苦的 Docker 连接问题的建议。
特别是,对于 Azure DevOps 服务 Git 存储库,我 运行 自托管(本地)docker 化 Linux CI (根据 https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/docker?view=azure-devops#linux 设置),几个月来一直运行良好。
所有这些都在公司网络上运行,自上周以来,我的 docker 容器的网络连接变得非常不稳定:
具体来说,它会间歇性地断开网络连接,这也可以通过 Azure DevOps 代理的日志看到,然后不断尝试重新连接。
下载 Git LFS 对象时尤其会发生这种情况。通过 GIT_TRACE=1 启用额外跟踪会突出显示大量连接失败和重试:
trace git-lfs: xfer: failed to resume download for "SHA" from byte N: expected status code 206, received 200. Re-downloading from start
在这样的 LFS pull / fetch 中,有时容器甚至会停止响应,因为 docker container list
命令只响应:
Error response from daemon: i/o timeout
因此守护进程无法自行恢复,需要手动重启(以恢复 CI)。
我还看到了网络性能的显着差异:
- 在不同机器容器实例(从同一图像创建)中手动克隆相同的Git存储库(包括LFS对象,全部从头开始),花费更少在我的开发笔记本电脑上(通过 VPN 从家里连接)不到 2 分钟,而在容器 运行 两台不同的 Win10 机器(公司网络,实际位于办公室,因此没有 VPN。
- 显然这与主机网络连接本身无关,因为在容器外克隆相同的 Win10 主机(公司 network/offices)仅需 14 秒!
因此我怀疑一些网络配置问题(例如 Hyper-V vEthernet 适配器?防火墙?代理?或任何其他看门狗误入歧途?),但经过三天的调试,我不太确定如何进一步调查这个问题,因为我 运行 没有想法和专业知识。有什么想法/建议/提示吗?
我应该添加 LFS 配置选项(such as lfs.concurrenttransfers and lfs.basictransfersonly) did not really help, similarly for git config http.version(或只是删除一些较大的文件)
更新
它实际上似乎与自托管代理无关,而是我公司网络中更普遍的 docker 网络配置问题。
运行 以下在我的 VPN 机器(运行 来自家里)上运行速度始终如一:
docker run -it
ubuntu bash -c "apt-get update; apt-get install -y wget; start=$SECONDS;
wget http://cdimage.ubuntu.com/lubuntu/releases/18.04/release/lubuntu-18.04-alternate-amd64.iso;
echo Duration: $(( SECONDS - start )) seconds"
与powershell下载对比(在主机上):
$start=Get-Date
$(New-Object
net.webclient).Downloadfile("http://cdimage.ubuntu.com/lubuntu/releases/18.04/release/lubuntu-18.04-alternate-amd64.iso",
"e:/temp/lubuntu-18.04-alternate-amd64.iso")
'Duration: {0:mm}
min {0:ss} sec' -f ($(Get-Date)-$start)
企业网络
- Docker:1560 秒(=26 分钟!)
- Windows 主机系统:持续时间:00 分 15 秒
开发笔记本电脑(VPN,在家):
- Docker:144 秒(=2 分 24 秒)
- Windows 主机系统:持续时间:02 分 16 秒
查看 https://github.com/docker/for-win/issues/698 中讨论的问题(以及对我不起作用的建议解决方法),这似乎是 Windows / hyper-v 的一个重要问题 ..
当我的公司决定最终从 Win10 1803 升级到 1909(WSL 附带,取代 Hyper-V)时,整个问题“自行解决”..
现在一切都运行得非常顺畅(我保留了 运行 这些测试近 20 次)
我正在寻找一些关于调试一些极其痛苦的 Docker 连接问题的建议。
特别是,对于 Azure DevOps 服务 Git 存储库,我 运行 自托管(本地)docker 化 Linux CI (根据 https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/docker?view=azure-devops#linux 设置),几个月来一直运行良好。
所有这些都在公司网络上运行,自上周以来,我的 docker 容器的网络连接变得非常不稳定:
具体来说,它会间歇性地断开网络连接,这也可以通过 Azure DevOps 代理的日志看到,然后不断尝试重新连接。
下载 Git LFS 对象时尤其会发生这种情况。通过 GIT_TRACE=1 启用额外跟踪会突出显示大量连接失败和重试:
trace git-lfs: xfer: failed to resume download for "SHA" from byte N: expected status code 206, received 200. Re-downloading from start
在这样的 LFS pull / fetch 中,有时容器甚至会停止响应,因为
docker container list
命令只响应:Error response from daemon: i/o timeout
因此守护进程无法自行恢复,需要手动重启(以恢复 CI)。
我还看到了网络性能的显着差异:
- 在不同机器容器实例(从同一图像创建)中手动克隆相同的Git存储库(包括LFS对象,全部从头开始),花费更少在我的开发笔记本电脑上(通过 VPN 从家里连接)不到 2 分钟,而在容器 运行 两台不同的 Win10 机器(公司网络,实际位于办公室,因此没有 VPN。
- 显然这与主机网络连接本身无关,因为在容器外克隆相同的 Win10 主机(公司 network/offices)仅需 14 秒!
因此我怀疑一些网络配置问题(例如 Hyper-V vEthernet 适配器?防火墙?代理?或任何其他看门狗误入歧途?),但经过三天的调试,我不太确定如何进一步调查这个问题,因为我 运行 没有想法和专业知识。有什么想法/建议/提示吗?
我应该添加 LFS 配置选项(such as lfs.concurrenttransfers and lfs.basictransfersonly) did not really help, similarly for git config http.version(或只是删除一些较大的文件)
更新
它实际上似乎与自托管代理无关,而是我公司网络中更普遍的 docker 网络配置问题。
运行 以下在我的 VPN 机器(运行 来自家里)上运行速度始终如一:
docker run -it
ubuntu bash -c "apt-get update; apt-get install -y wget; start=$SECONDS;
wget http://cdimage.ubuntu.com/lubuntu/releases/18.04/release/lubuntu-18.04-alternate-amd64.iso;
echo Duration: $(( SECONDS - start )) seconds"
与powershell下载对比(在主机上):
$start=Get-Date
$(New-Object
net.webclient).Downloadfile("http://cdimage.ubuntu.com/lubuntu/releases/18.04/release/lubuntu-18.04-alternate-amd64.iso",
"e:/temp/lubuntu-18.04-alternate-amd64.iso")
'Duration: {0:mm}
min {0:ss} sec' -f ($(Get-Date)-$start)
企业网络
- Docker:1560 秒(=26 分钟!)
- Windows 主机系统:持续时间:00 分 15 秒
开发笔记本电脑(VPN,在家):
- Docker:144 秒(=2 分 24 秒)
- Windows 主机系统:持续时间:02 分 16 秒
查看 https://github.com/docker/for-win/issues/698 中讨论的问题(以及对我不起作用的建议解决方法),这似乎是 Windows / hyper-v 的一个重要问题 ..
当我的公司决定最终从 Win10 1803 升级到 1909(WSL 附带,取代 Hyper-V)时,整个问题“自行解决”.. 现在一切都运行得非常顺畅(我保留了 运行 这些测试近 20 次)