Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

azd CDN changing January 2025 #4661

Open
danieljurek opened this issue Jan 6, 2025 · 8 comments
Open

azd CDN changing January 2025 #4661

danieljurek opened this issue Jan 6, 2025 · 8 comments
Assignees
Labels
Milestone

Comments

@danieljurek
Copy link
Member

danieljurek commented Jan 6, 2025

This issue primarily impacts downloaded versions of installer scripts (which should be updated to the latest by visiting https://aka.ms/install-azd.ps1 and https://aka.ms/install-azd.sh), GitHub Actions users (who need to upgrade to azure/setup-azd@v2), some Azure DevOps instances which need to upgrade to the latest version of setup-azd@0, and custom logic that depends on hostnames.

The CDN endpoint for downloading and installing azd is changing. This is because the Edgeio provider is retiring their CDN service effective January 15, 2025.

Depending on hostnames for azd install is not supported. We recommend using the install scripts or supported installation channels like WinGet, Choco, and brew.

The CDN at azdrelease.azureedge.net and the much older unsupported azure-dev.azureedge.net will be taken offline in the coming days.

Impacted:

  • azure/setup-azd GitHub Action
  • Older downloaded versions of install-azd.ps1 and install-azd.sh scripts
  • Any hardcoded references in your system to the older CDN endpoints
  • Firewall rules that enable traffic to the *.azureedge.net CDN hosts

Actions:

  • Ensure you are using the latest GitHub Action (v2) for azure/setup-azd in your workflows.
  • Ensure you are using the latest Azure DevOps task version.
  • Ensure any custom install scripts reference the new host name. File paths after the host name will not change.
  • Update any firewall rules which allow traffic to azdrelease.azureedge.net to instead use the new hostname.

Not impact:

  • The azd client and Azure Developer CLI VSCode extension are not directly impacted
  • WinGet, Choco, brew installers
  • GitHub releases
  • Normal usage of https://aka.ms/install-azd.ps1
    and https://aka.ms/install-azd.sh scripts. Those have already been updated.
@TWolversonReply
Copy link

On

Ensure you are using the latest Azure DevOps task version.

There is only one version, from what I can see? setup-azd@0 indicates using the first (and only) available task version as I understand the Azure DevOps naming convention. This also suggests that ADO tasks have to be pinned (can't automatically roll forward to the latest major version). Is there to be a new version published that will use the updated CDN?

@danieljurek
Copy link
Member Author

@TWolversonReply -- The version of the Azure DevOps extension which uses the latest hostname is 0.17.0. In many cases, Azure DevOps will upgrade and use the latest version of extension automatically. In some cases, administrator action may be needed to upgrade an extension.

Using the task setup-azd@0 will work if you have 0.17.0 installed in your DevOps org. In most cases, repos using Azure DevOps will not have to take any special action to start using the new CDN.

@markwragg
Copy link

I'm getting intermittent failures installing AZD using the latest version (0.15.0) of the Azure DevOps setup-azd@0 task today. There's no useful output when it fails (even with system diagnostics enabled on the run), but if I rerun the pipeline enough times it eventually succeeds.

Output when it fails:

##[debug]Evaluating condition for step: 'Install AZD'
##[debug]Evaluating: SucceededNode()
##[debug]Evaluating SucceededNode:
##[debug]=> True
##[debug]Result: True
Starting: Install AZD
==============================================================================
Task         : Setup Azure Developer CLI
Description  : Install azd
Version      : 0.15.0
Author       : AzureDeveloperCLI
Help         : 
==============================================================================
##[debug]Using node path: /agent/externals/node20_1/bin/node
##[debug]system.debug=True
##[debug]DistributedTask.Tasks.Node.SkipDebugLogsWhenDebugModeOff=True
##[debug]agent.TempDirectory=/agent/_work/_temp
##[debug]loading inputs and endpoints
##[debug]loading ENDPOINT_AUTH_SYSTEMVSSCONNECTION
##[debug]loading ENDPOINT_AUTH_SCHEME_SYSTEMVSSCONNECTION
##[debug]loading ENDPOINT_AUTH_PARAMETER_SYSTEMVSSCONNECTION_ACCESSTOKEN
##[debug]loading SECRET_SYSTEM_ACCESSTOKEN
##[debug]loaded 10
##[debug]Agent.ProxyUrl=undefined
##[debug]Agent.CAInfo=undefined
##[debug]Agent.ClientCert=undefined
##[debug]Agent.SkipCertValidation=undefined
##[debug]Agent.Version=4.248.0
##[debug]set task variable: hasRunMain=true
##[debug]Processed: ##vso[task.settaskvariable variable=hasRunMain;issecret=false;]true
##[debug]version=undefined
using version: latest
The Azure Developer CLI collects usage data and sends that usage data to Microsoft in order to help us improve your experience.
You can opt-out of telemetry by setting the AZURE_DEV_COLLECT_TELEMETRY environment variable to 'no' in the shell you use.

Read more about Azure Developer CLI telemetry: https://github.com/Azure/azure-dev#data-collection
Installing azd from https://azd-release-gfgac2cmf7b8cuay.b02.azurefd.net/azd/standalone/release/latest/azd-linux-amd64.tar.gz
Finishing: Install AZD

Output when it succeeds

##[debug]system.debug=True
##[debug]DistributedTask.Tasks.Node.SkipDebugLogsWhenDebugModeOff=True
##[debug]agent.TempDirectory=/agent/_work/_temp
##[debug]loading inputs and endpoints
##[debug]loading ENDPOINT_AUTH_SYSTEMVSSCONNECTION
##[debug]loading ENDPOINT_AUTH_SCHEME_SYSTEMVSSCONNECTION
##[debug]loading ENDPOINT_AUTH_PARAMETER_SYSTEMVSSCONNECTION_ACCESSTOKEN
##[debug]loading SECRET_SYSTEM_ACCESSTOKEN
##[debug]loaded 10
##[debug]Agent.ProxyUrl=undefined
##[debug]Agent.CAInfo=undefined
##[debug]Agent.ClientCert=undefined
##[debug]Agent.SkipCertValidation=undefined
##[debug]Agent.Version=4.248.0
##[debug]set task variable: hasRunMain=true
##[debug]Processed: ##vso[task.settaskvariable variable=hasRunMain;issecret=false;]true
##[debug]version=undefined
using version: latest
The Azure Developer CLI collects usage data and sends that usage data to Microsoft in order to help us improve your experience.
You can opt-out of telemetry by setting the AZURE_DEV_COLLECT_TELEMETRY environment variable to 'no' in the shell you use.

Read more about Azure Developer CLI telemetry: https://github.com/Azure/azure-dev#data-collection
Installing azd from https://azd-release-gfgac2cmf7b8cuay.b02.azurefd.net/azd/standalone/release/latest/azd-linux-amd64.tar.gz
##[debug]Agent.Version=4.248.0
##[debug]Processed: ##vso[task.prependpath]/agent/_work/4/s/azd-install
azd installed to /agent/_work/4/s/azd-install
##[debug]which '/agent/_work/4/s/azd-install/azd'
##[debug]found: '/agent/_work/4/s/azd-install/azd'
##[debug]/agent/_work/4/s/azd-install/azd arg: version
##[debug]exec tool: /agent/_work/4/s/azd-install/azd
##[debug]arguments:
##[debug]   version
/agent/_work/4/s/azd-install/azd version
azd version 1.11.1 (commit ae08ceba17c7078c547df9ee5f97e9e7ceb2fe53)
##[debug]Agent environment resources - Disk: / Available 16538.09 MB out of 74244.74 MB, Memory: Used 1077.00 MB out of 6921.00 MB, CPU: Usage 56.55%

##[debug]Process exited with code 0 and signal null for tool '/agent/_work/4/s/azd-install/azd'
##[debug]STDIO streams have closed and received exit code 0 and signal null for tool '/agent/_work/4/s/azd-install/azd'
Finishing: Install AZD

The task succeeds either way, but then when my pipeline comes to use azd in a later task its not there on the occasions its failed to install. It seems like it doesn't successfully download, but that doesn't cause the task to fail, it just ends successfully.

@danieljurek
Copy link
Member Author

@markwragg -- Thanks for reporting. Would you mind sharing the general location where these DevOps agents are hosted? We have seen a couple of failures with the new CDN in England previously and this information may help with diagnosing and fixing the issue.

I've also opened an issue to improve error logging: #4674

@markwragg
Copy link

I think the agents are in Azure North Europe region. It's a self hosted VMSS, but I didn't set it up so will check and confirm tomorrow.

@markwragg
Copy link

markwragg commented Jan 9, 2025

@markwragg -- Thanks for reporting. Would you mind sharing the general location where these DevOps agents are hosted? We have seen a couple of failures with the new CDN in England previously and this information may help with diagnosing and fixing the issue.

I've also opened an issue to improve error logging: #4674

Our agents are all hosted in Azure, north europe. This is still a problem today, having to run the pipeline multiple times before the task successfully downloads the installer.

@danieljurek
Copy link
Member Author

@markwragg -- Given that the download succeeds some of the time I think that could rule out an agent or network configuration that would prevent talking to the new CDN host. I've tried to reproduce the behavior on VMs in North Europe and have successfully downloaded files from the CDN every time.

If you're still seeing the issue, can you run the following on an agent? If so, when the download fails do you get header outputs?

      - pwsh: |
          try { 
              $result = Invoke-WebRequest -Uri https://azd-release-gfgac2cmf7b8cuay.b02.azurefd.net/azd/standalone/release/latest/azd-linux-amd64.tar.gz
              $result.Headers | Format-Table -AutoSize -Wrap
          } catch { 
              Write-Host "Failure: Invoke-WebRequest threw an error"
              $_ | Write-Host
              $_.Exception.Response.Headers | Format-Table -AutoSize -Wrap
              exit 1
          }
        displayName: Try downloading azd

@markwragg
Copy link

@danieljurek I don't seem to be experiencing the issue today. Yesterday it was occurring 4 out of 5 attempts but I haven't seen it at all today. My guess it was a temporary issue with the new CDN that is now resolved.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants