skip to Main Content

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…

  1. The same script works from the host computer (so it’s not host-URL connectivity)
  2. 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
  3. Replacing the WebClient with an Invoke-RestMethod call just hangs forever, highlighting that it can’t reach the URL

2

Answers


  1. Chosen as BEST ANSWER

    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.


  2. Exception calling "DownloadFile" with "2" argument(s): "The operation has timed out"

    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.zip

    You 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.

    Login or Signup to reply.
Please signup or login to give your own answer.
Back To Top
Search