Мне нужен совет по устранению некоторых чрезвычайно болезненных проблем с подключением Docker.
В частности, для репозитория Git Azure DevOps Services я использую автономный (локальный) dockerized Linux CI (настройка в соответствии с https://docs.microsoft.com/en-us/azure/devops/pipelines/agent/docker?view=azure-DevOps#linux), которая уже несколько месяцев работает нормально.
Все это работает в сети компании, и с прошлой недели сетевое соединение моего док-контейнера стало очень нестабильным:
В частности, он периодически теряет сетевое подключение, что также видно в журналах агента Azure DevOps, который затем продолжает попытки восстановить подключение.
- # P5 #
# P6 #
- # P7 #
# P8 #
# P9 #
Также я вижу заметные различия в производительности сети:
- Ручное клонирование одного и того же репозитория Git (включая объекты LFS, все с нуля) в экземплярах контейнера (созданных из одного образа) на разных машинах, занимает менее 2 минут на моем портативном компьютере разработчика (подключенном из дома через VPN), тогда как та же операция легко занимает до 20 минут (!) В контейнерах, на которых работают две разные машины Win10 (корпоративная сеть, физически расположенная в офисах, следовательно, нет VPN.
- Ясно, что речь идет не о самом подключении к сети хоста, поскольку клонирование на одних и тех же хостах Win10 (сеть / офисы компании) вне контейнеров занимает всего 14 секунд!
Следовательно, я подозреваю некоторые проблемы с конфигурацией сети (например, что-то с адаптером Hyper-V vEthernet? Брандмауэр? Прокси-сервер? Или какой-либо другой сторожевой таймер сбился с пути?), Но после трех дней отладки я не совсем уверен, как дальше исследовать эту проблему , так как у меня заканчиваются идеи и опыт. Есть мысли / советы / подсказки?
Я должен добавить, что параметры конфигурации LFS (, например lfs.concurrenttransfers и lfs.basictransfersonly) не помогли, аналогично для https://git-scm.com/docs/git-config#Documentation/git-config.txt-httpversion (или просто удалив несколько файлов большего размера)
ОБНОВЛЕНИЕ
на самом деле, похоже, это не о самообслуживаемом агенте, а более общая проблема 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 host sys: Продолжительность: 00 мин. 15 сек.
Портативный компьютер для разработчиков (VPN, из дома):
- Докер: 144 секунды (= 2 минуты 24 секунды)
- Windows host sys: Продолжительность: 02 мин. 16 сек.
Рассмотрение вопросов, обсуждаемых в https://github.com/docker/for-win/issues/698 (и предложенный обходной путь, который у меня не сработал), похоже, это нетривиальная проблема с Windows / hyper-v ..
