Deployment Error: getaddrinfo ENOTFOUND <appServiceName>.scm.<appServiceEnvironment>.appserviceenvironment.net

Issue

We're getting the error:

##[error]Error: Error: Failed to deploy web package to App Service. Error: getaddrinfo ENOTFOUND {appServiceName}.scm.{appServiceEnvironment}.appserviceenvironment.net {appServiceName}.scm.{appServiceEnvironment}.appserviceenvironment.net:443

When running the below pipeline task:
- task: AzureRmWebAppDeployment@4
enabled: true
displayName: 'Azure App Service Deploy Zip-file to: $(arm_appServiceFrontend)'
inputs:
appType: 'webApp'
azureSubscription: '$(armServiceConnectorForTestEnvironment)'
WebAppName: '$(arm_appServiceFrontend)'
# the deployment step has a hidden step that downloads the published artifacts but it places the
# artifact in the wrong catalogue. To work around that I have to place my self in the correct
# path below.
packageForLinux: './../$(publishedArtifactName)/$(frontEndProjectName).zip'


The full output of this task is:

Azure App Service Deploy Zip-file to: {appServiceName}

View raw log

Starting: Azure App Service Deploy Zip-file to: {appServiceName}

==============================================================================

Task : Azure App Service deploy

Description : Deploy to Azure App Service a web, mobile, or API app using Docker, Java, .NET, .NET Core, Node.js, PHP, Python, or Ruby

Version : 4.184.4

Author : Microsoft Corporation

Help : https://aka.ms/azureappservicetroubleshooting

==============================================================================

Got service connection details for Azure App Service:{appServiceName}

Trying to update App Service Application settings. Data: {"WEBSITE_RUN_FROM_PACKAGE":"1"}

App Service Application settings are already present.

Package deployment using ZIP Deploy initiated.

##[error]Failed to deploy web package to App Service.

##[error]Error: Error: Failed to deploy web package to App Service. Error: getaddrinfo ENOTFOUND {appServiceName}.scm.{appServiceEnvironment}.appserviceenvir

The official solution is documented here: MS Docs: Create ILB ASE - DNS Configuration

You need to have DNS entries for your ASE so that the deployment task can reach it; but if you have an internal only ASE, those entries aren't created in public DNS, and MS don't manage private DNS.

MS propose creating the DNS entries in your internal DNS:

Create Zone {ASE Name}.appserviceenvironment.net

• Type: Primary Zone

• Store the zone in AD: True

• Zone Replication: To all DNS servers in the domain

• Zone Name: {ASE Name}.appserviceenvironment.net

• Allow only secure updates: true

Create A Record under {ASE Name}.appserviceenvironment.net

• Name: *

• IP: {ASE's Private IP}

Create A Record under {ASE Name}.appserviceenvironment.net

• Name: *

• IP: {ASE's Private IP}

Create Child Zone under {ASE Name}.appserviceenvironment.net

• Name: scm

Create A Record under scm.{ASE Name}.appserviceenvironment.net

• Name: *

• IP: {ASE's Private IP}

However, whilst awaiting the DNS creation I tried a workaround which turned out to be sufficient for the pipeline's needs...

Add the below script to your pipeline, ahead of the deployment task:
- script: |
sudo -- sh -c -e "echo '{ASE's Private IP} {ASE Name}.appserviceenvironment.net' >> /etc/hosts";
sudo -- sh -c -e "echo '{ASE's Private IP} scm.{ASE Name}.appserviceenvironment.net' >> /etc/hosts";
sudo -- sh -c -e "echo '{ASE's Private IP} {AppName}.scm.{ASE Name}.appserviceenvironment.net' >> /etc/hosts";
displayName: 'Fake DNS entries required for deployment'


HOWEVER; the above fix only fixes the pipeline's deployment.

The FQDN for the app service is still not present; and the IP alone won't work since all apps on the ASE will have the same IP / we need hostname resolution.
In our case we had an AppGateway in front of the app service; so you could pick the app service you're after from the list... but that's resolved to an FQDN, which then fails as the AppGateway can't resolve that FQDN to an IP... So you do need your DNS to be updated.

Whilst testing the service / awaiting DNS changes, our developers just updated their local device's hosts files to work around that issue: {ASE's IP} {appServiceName}.{ASE Name}.appserviceenvironment.net

StackExchange DevOps Q#14793, answer score: 2