码头连接问题(从自托管的Linux代理到Azure DevOps服务)

Question

我正在寻找一些关于调试一些极其痛苦的码头连接问题的建议。

特别是，对于Azure DevOps服务Git存储库，我运行的是一个自托管(本地)文档化Linux (根据https://learn.microsoft.com/en-us/azure/devops/pipelines/agents/docker?view=azure-devops#linux设置)，它已经运行了几个月了。

所有这些都是在公司网络上运行的，自上周起，我的码头集装箱的网络连接变得非常不稳定：

• 具体来说，它断断续续地松开了网络连接，这种连接也可以通过Azure DevOps代理的日志看到，后者会继续尝试重新连接。
• 在下载Git对象时尤其会发生这种情况。通过GIT_TRACE=1启用额外的跟踪会突出显示许多连接失败和重试： 跟踪git-lfs: xfer:未能从字节N:预期状态代码206恢复下载"SHA“，接收200。从头开始重新下载
• 在这样的LFS拉/取过程中，有时容器甚至停止响应，因为docker container list命令只响应： 守护进程的错误响应: i/o超时

因此，守护进程无法自行恢复，需要手动重新启动(以恢复CI)。

我还看到了网络性能的显著差异：

• 手动克隆不同机器上的容器实例(从同一映像创建)中相同的Git存储库(包括LFS对象，都是从头开始的)，在我的dev膝上型计算机上(通过VPN从家里连接)只需不到2分钟，而相同的操作很容易占用20分钟(!)在运行两台不同Win10机器的容器上，(公司网络，物理位置在办公室，因此没有VPN )。
• 显然，这与主机网络连接本身无关，因为在容器之外的同一Win10主机(公司网络/办公室)上克隆只需14秒！

因此，我怀疑一些网络配置问题(例如，与超-V vEthernet适配器？防火墙？代理？或者其他的看门狗误入歧途？)，但经过三天的调试，我不太确定如何进一步调查这个问题，因为我的想法和专业知识正在耗尽。有什么想法/建议/暗示吗？

我应该补充一点，LFS配置选项(如lfs.concurrenttransfers和lfs.basictransfersonly)并没有真正的帮助，类似于git配置http.version (或者只是删除一些更大的文件)。

更新

它实际上似乎并不是关于自我托管的代理，而是一个更一般的码头网络cfg问题，在我的公司网络。

在我的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)

公司网络

• 码头工人: 1560秒(=26分钟！)
• Windows主机系统:持续时间: 00分钟15秒

开发膝上型计算机(VPN，来自家庭)：

• 码头: 144秒(=2分24秒)
• Windows主机系统:持续时间: 02分16秒

看看https://github.com/docker/for-win/issues/698中讨论的问题(以及对我来说不适用的解决方案)，这似乎是Windows / hyper-v的一个重要问题。

Answer 1

当我的公司最终决定从Win10 1803年升级到1909年(这是WSL，取代Hyper-V)时，整个问题“解决了”。现在一切都是超月运行的(我连续运行这些测试近20次)