Deploy container to Azure App Service always fails on first attempt

Question

I have two different custom images in two different repo in our Azure Container Repository.

I also have two App services configured to run containers though they both share the same App Service Plan.

I'm using an Azure Devops release pipeline with the Azure App Service deploy task to deploy updates to the App services. The process seems to work and the App Services are working fine. The only problem is that we're trying to enable CI/CD and the release pipeline always fails on the first attempt. Re-deploy and it works fine. I've duplicated the task in the pipeline with the expectation that the first will fail and the second will work. This appears to do the trick as a work around but is hardly a good solution. The only error message I get is

2020-03-16T13:47:07.8359865Z ##[error]Error: Failed to fetch Kudu App Settings. Error: Ip Forbidden (CODE: 403)
2020-03-16T13:47:07.9494964Z ##[warning]Error: Failed to update deployment history. Error: Ip Forbidden (CODE: 403)

Answer 1

Thanks for asking question! If I have understood right, deployment failed with Error: Failed to fetch Kudu App Settings. Error: Ip Forbidden (CODE: 403).

It looks like it needs Whitelisting the IP Addresses. Could you please go to your app service> Networking> Access Restrictions blade and allow the rule under the scm site. "Same restrictions as xxxx.azurewebsites.net".

Answer 2

I'm seeing the opposite of this. We're only allowing certain IP's to reach the web app. The "Same restrictions as <app-url>" option had already been enabled. I disabled this option which allows any IP to reach scm site and the deploy worked on first try. That sounds like deploy agent and/or the container registry needs to be added to the whitelist.

Now my concern is that we're using Azure Container Registry and Azure Devops Host Agents for this and the reference I can't find for these IP's is this linkhosted. Which points to an IP list that can change weekly. I would hope to be able to handle that better than having to monitor a weekly file.