So, this is a very weird issue and I can’t figure it out… I’m following MS documentation on running the DevOps agent from a Docker container, and the following code is always failing.
Print-Header "1. Determining matching Azure Pipelines agent..."
$base64AuthInfo = [Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes(":$(Get-
Content ${Env:AZP_TOKEN_FILE})"))
$package = Invoke-RestMethod -Headers @{Authorization = ("Basic $base64AuthInfo") }
"$(${Env:AZP_URL})/_apis/distributedtask/packages/agent?platform=win-x64&`$top=1"
$packageUrl = $package[0].Value.downloadUrl
Write-Host $packageUrl
Print-Header "2. Downloading Azure Pipelines agent..."
$wc = New-Object System.Net.WebClient
$wc.DownloadFile("$packageUrl", ".agent.zip")
with the error
Exception calling "DownloadFile" with "2" argument(s): "The operation has timed out"
At C:azagentagentGet.ps1:39 char:1
$wc.DownloadFile("https://vstsagentpackage.azureedge.net/agent/3.232. …
CategoryInfo : NotSpecified: (:) [], ParentContainsErrorRecordException
FullyQualifiedErrorId : WebException
Here’s why it’s confusing…
- The same script works from the host computer (so it’s not host-URL connectivity)
- The dockerfile has instructions, before running that code, to download java from the internet, which is also working, so it’s not the process not having access to the internet
- Replacing the WebClient with an
Invoke-RestMethod
call just hangs forever, highlighting that it can’t reach the URL
2
Answers
Nevermind... the issue ended up being the VPN on the host, which is weird because the host can execute the script fine, but the request is blocked when it's coming from the container.
Disconnecting from the VPN allowed both scripts (host and container) to work.
According to the error message, the problem is timeout. So, please make sure your network is fast and stable. Agent installation packages are generally larger. Even if other parts of the script have Internet access, there may be specific connectivity issues between the Docker container and the Azure DevOps agent download URL.
I tested this script and get the
$packageUrl
Url: https://vstsagentpackage.azureedge.net/agent/3.232.3/vsts-agent-win-x64-3.232.3.zipYou can test it by trying different methods of accessing the URL from within the Docker container to check if the connection is fine.
If it cannot access this
$packageUrl
in the Docker, there is a workaround that you can download the agent.zip in advance and place it in the required location. This avoids downloading it in Docker.