<p>The official solution is documented here: <a href="https://docs.microsoft.com/en-us/azure/app-service/environment/create-ilb-ase#dns-configuration" rel="nofollow noreferrer">MS Docs: Create ILB ASE - DNS Configuration</a></p>
<p>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.</p>
<p>MS propose creating the DNS entries in your internal DNS:</p>
<blockquote>
<p>Create Zone {ASE Name}.appserviceenvironment.net</p>
<ul>
<li>Type: Primary Zone</li>
<li>Store the zone in AD: True</li>
<li>Zone Replication: To all DNS servers in the domain</li>
<li>Zone Name: {ASE Name}.appserviceenvironment.net</li>
<li>Allow only secure updates: true</li>
</ul>
</blockquote>
<blockquote>
<p>Create A Record under {ASE Name}.appserviceenvironment.net</p>
<ul>
<li>Name: *</li>
<li>IP: {ASE's Private IP}</li>
</ul>
</blockquote>
<blockquote>
<p>Create A Record under {ASE Name}.appserviceenvironment.net</p>
<ul>
<li>Name: *</li>
<li>IP: {ASE's Private IP}</li>
</ul>
</blockquote>
<blockquote>
<p>Create Child Zone under {ASE Name}.appserviceenvironment.net</p>
<ul>
<li>Name: scm</li>
</ul>
</blockquote>
<blockquote>
<p>Create A Record under scm.{ASE Name}.appserviceenvironment.net</p>
<ul>
<li>Name: *</li>
<li>IP: {ASE's Private IP}</li>
</ul>
</blockquote>
<p>However, whilst awaiting the DNS creation I tried a workaround which turned out to be sufficient for the pipeline's needs...</p>
<p>Add the below script to your pipeline, ahead of the deployment task:</p>
<pre class="lang-yaml prettyprint-override"><code>- script: |
    sudo -- sh -c -e &quot;echo '{ASE's Private IP}    {ASE Name}.appserviceenvironment.net' &gt;&gt; /etc/hosts&quot;;
    sudo -- sh -c -e &quot;echo '{ASE's Private IP}    scm.{ASE Name}.appserviceenvironment.net' &gt;&gt; /etc/hosts&quot;;
    sudo -- sh -c -e &quot;echo '{ASE's Private IP}    {AppName}.scm.{ASE Name}.appserviceenvironment.net' &gt;&gt; /etc/hosts&quot;;
  displayName: 'Fake DNS entries required for deployment'
</code></pre>
<p>HOWEVER; the above fix only fixes the pipeline's deployment.</p>
<p>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.</p>
<p>Whilst testing the service / awaiting DNS changes, our developers just updated their local device's hosts files to work around that issue: <code>{ASE's IP}  {appServiceName}.{ASE Name}.appserviceenvironment.net</code></p>

CC BY-SA 4.0
2021-10-07T09:47:25.010Z
2021-10-07T11:55:42.423Z
2021-10-07T11:55:42.423Z
JohnLBevan
<h2>Issue</h2>
<p>We're getting the error:</p>
<blockquote>
<p>##[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</p>
</blockquote>
<p>When running the below pipeline task:</p>
<pre class="lang-yaml prettyprint-override"><code>- 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'
</code></pre>
<p>The full output of this task is:</p>
<blockquote>
<p>Azure App Service Deploy Zip-file to: {appServiceName}</p>
<p>View raw log</p>
<p>Starting: Azure App Service Deploy Zip-file to: {appServiceName}</p>
<p>==============================================================================</p>
<p>Task         : Azure App Service deploy</p>
<p>Description  : Deploy to Azure App Service a web, mobile, or API app using Docker, Java, .NET, .NET Core, Node.js, PHP, Python, or Ruby</p>
<p>Version      : 4.184.4</p>
<p>Author       : Microsoft Corporation</p>
<p>Help         : <a href="https://aka.ms/azureappservicetroubleshooting" rel="nofollow noreferrer">https://aka.ms/azureappservicetroubleshooting</a></p>
<p>==============================================================================</p>
<p>Got service connection details for Azure App Service:{appServiceName}</p>
<p>Trying to update App Service Application settings. Data: {&quot;WEBSITE_RUN_FROM_PACKAGE&quot;:&quot;1&quot;}</p>
<p>App Service Application settings are already present.</p>
<p>Package deployment using ZIP Deploy initiated.</p>
<p>##[error]Failed to deploy web package to App Service.</p>
<p>##[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</p>
<p>App Service Application URL: http://{appServiceName}.appserviceenvironment.net</p>
<p>Finishing: Azure App Service Deploy Zip-file to: {appServiceName}</p>
</blockquote>
<p>Note: content in curly braces is where I've replaced deployment specific strings with generic names.</p>
<h2>Context</h2>
<p>One of our teams has started using Azure DevOps pipelines to deploy code in a GitHub repo to an App Service in an App Service Environment.</p>
<p>We're using the App Service Environment because the app requires access to resources in our private network (internal API and LDAP servers).</p>
<p>The app itself is exposed publicly, though this is done via an Application Gateway, with the app service configured as the backend pool, rather than the app service being public facing.</p>
<p>Since we're deploying to a private ASE, we've created our own Azure Scale Set Release Agent, using an image created from the <a href="https://github.com/actions/virtual-environments/blob/main/images/linux/Ubuntu2004-README.md" rel="nofollow noreferrer">MS Ubuntu 2004 agent</a>.</p>
<p>A lot of components in this tech stack are new to all members of the team; so it's very likely we've done something wrong somewhere; but our lack of experience with these tools means we're not sure where...</p>
<h2>Question</h2>
<p>Does anyone know of a likely cause for the error we're seeing?</p>
<p>Failing that, any tips on useful steps to help us track the source of these issues would be appreciated.</p>

<azure-devops><azure><azure-pipelines>
Deployment Error: getaddrinfo ENOTFOUND <appServiceName>.scm.<appServiceEnvironment>.appserviceenvironment.net
JohnLBevan
# Deployment Error: getaddrinfo ENOTFOUND <appServiceName>.scm.<appServiceEnvironment>.appserviceenvironment.net

(Asked by: username_0 on 2021-10-06)

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}.appserviceenvironment.net {appServiceName}.scm.{appServiceEnvironment}.appserviceenvironment.net:443
App Service Application URL: http://{appServiceName}.appserviceenvironment.net
Finishing: Azure App Service Deploy Zip-file to: {appServiceName}

Note: content in curly braces is where I've replaced deployment specific strings with generic names.
Context
One of our teams has started using Azure DevOps pipelines to deploy code in a GitHub repo to an App Service in an App Service Environment.
We're using the App Service Environment because the app requires access to resources in our private network (internal API and LDAP servers).
The app itself is exposed publicly, though this is done via an Application Gateway, with the app service configured as the backend pool, rather than the app service being public facing.
Since we're deploying to a private ASE, we've created our own Azure Scale Set Release Agent, using an image created from the MS Ubuntu 2004 agent.
A lot of components in this tech stack are new to all members of the team; so it's very likely we've done something wrong somewhere; but our lack of experience with these tools means we're not sure where...
Question
Does anyone know of a likely cause for the error we're seeing?
Failing that, any tips on useful steps to help us track the source of these issues would be appreciated.

**Tags:** azure-devops, azure, azure-pipelines


---

## 1 answers

### Answer by username_0 on 2021-10-07. Score: 2 | Accepted answer

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


---

