My pipeline uses a Linux Agent VM (Ubuntu 24.04) that cannot connect to my App Service.
Pipeline YAML:
...
# Agent VM image name
vmImageName: 'ubuntu-24.04'
# Root folder under which your composer.json file is available.
rootFolder: $(System.DefaultWorkingDirectory)
stages:
- stage: Build
displayName: Build stage
variables:
phpVersion: '8.2'
jobs:
- job: Buildjob
pool:
vmImage: $(vmImageName)
steps:
...
- script: |
echo "starting nslookup..."
sudo nslookup -debug xxx.appserviceenvironment.net
workingDirectory: $(rootFolder)
displayName: 'NSLookup'
It currently outputs:
** server can't find xxx.appserviceenvironment.net: NXDOMAIN
What typically needs to happen for a Linux Agent VM to connect to an existing App Service? Do I only have to configure this VM with the appropriate DNS entries?
Edit #1: or maybe, I need to modify the Network Security Group of the App Service to allow traffic from there?
When you run
nslookup xxx.appserviceenvironment.net
on a Microsoft-hosted Ubuntu agent and see “NXDOMAIN,” it simply means that hostname lives in a private DNS zone inside your App Service Environment (ASE), not on the public internet. Microsoft-hosted agents have no access to that private DNS, so they can’t resolve or reach the App Service. You can read more about how ASE private endpoints use their own DNS in the Azure App Service private endpoint documentation.
To fix this, you need an agent inside the same virtual network as the ASE. The most straightforward way is to spin up an Ubuntu VM in that VNet (or a peered VNet that shares its private DNS). During VM creation in the Azure Portal, choose the same VNet/subnet used by your ASE so that the VM automatically inherits the private DNS settings.
Once the VM is running, SSH into it and verify you can resolve and reach the App Service:
# You should see a private IP instead of "NXDOMAIN"
nslookup xxx.appserviceenvironment.net
# You should see a successful HTTPS connection
curl -v https://xxx.appserviceenvironment.net
If you see a private IP and curl connects without error, you’re in the right network.
Next, download and configure the Azure Pipelines agent on that VM. Follow Microsoft’s guide for self-hosting an agent on Linux:
# Create a folder and download the agent
mkdir myagent && cd myagent
wget https://vstsagentpackage.azureedge.net/agent/2.301.1/vsts-agent-linux-x64-2.301.1.tar.gz
tar xzf vsts-agent-linux-x64-2.301.1.tar.gz
chmod +x config.sh
# Run the configuration script (replace with your org URL and PAT)
./config.sh \
--unattended \
--url https://dev.azure.com/YourOrgName \
--auth pat \
--token YOUR_PERSONAL_ACCESS_TOKEN \
--pool Default
# (Optional) Install as a service so it starts on boot
sudo ./svc.sh install
sudo ./svc.sh start
You can find the full instructions here: Azure Pipelines Linux self-hosted agent.
After the agent registers, you’ll see it under Project Settings < Agent pools in Azure DevOps. Now, any pipeline job that targets this self-hosted agent can resolve xxx.appserviceenvironment.net and deploy to the App Service without DNS errors.
If you’d rather not manage a VM yourself, the only alternative is to expose a public endpoint for the App Service (for example, move it out of the private ASE or switch to a regular App Service Plan). Then a Microsoft-hosted agent could connect to yourapp.azurewebsites.net without private DNS. The trade-off is that you lose the network isolation that an ASE provides.