Linux VNet Integration GA Issues

Question

When Linux VNet integration was in preview, we had to ensure our ASP.NET Core web application listened on the port specified in the environment variable 'PORT'. This limitation was removed with GA however that is not the case with my app services. Also, my ASPNETCORE_URLS environment variables is being overridden with "http://+:8081" and I'm not sure why.

Without VNet:
WEBSITE_PORT=5000 // as per my web app settings
ASPNETCORE_URLS=http://0.0.0.0:5000 // as per my docker image environment variable
PORT=5000 // as provided by the web app

With VNet:
WEBSITE_PORT=5000 // as per my web app settings
ASPNETCORE_URLS=http://+:8081 // overridden by the web app for some reason, would like to understand why?
PORT=8081 // as provided by the web app

I wonder if I need to somehow enabled the GA version of the VNet integration?
I tried deleting my app service and re-creating it to see if that would help, but it did not.

Questions:

1. Why is the ASPNETCORE_URLS environment variable overridden to http://+:8081 by the web app when a VNet is connected?
2. Why is PORT still required in my ASP.NET Core code, the announcements said this was no longer required.

I've also noticed that the MSI token service container sets the ASPNETCORE_URLS env var to http://+:8081
https://hub.docker.com/layers/appsvc/msitokenservice/2002261706/images/sha256-48785c8d37d1101dd99b2ab2fc7c3b75ca6f672eb873312b20163dc1feb125f2?context=explore
I wonder if this is somehow related to what I'm seeing above, if that is even the true MS Azure used image for MSI.

Further to this, and may be related, the MSI (managed service identity) does not work after a few hours and I need to restart the app service.
The logs show the request to: http://169.254.134.2:8081/msi/token?resource=https://management.azure.com/&api-version=2019-08-01 fails with 500 status code.

This is affecting all 20 of my Linux App Services. This all started this week. I believe all of this is related to the changes with the VNet integration for Linux App Services that went GA (from Preview status) last month.

Answer 1

Based on our offline discussions. Updating the thread with answers to benefit the community.

Do I need to use the PORT variable still in code, this restriction was supposed to be removed with GA?

You don’t need to use the PORT variable.
The automatic port detection detects the port (port 80 is the default), we will attempt to detect which port to bind to your container, but you can also use the WEBSITES_PORT app setting and configure it with a value for the port you want to bind to your container. However, the web server in your custom image may use a port other than 80. You tell Azure about the port that your custom container uses by using the WEBSITES_PORT app setting. For a different port - Use the EXPOSE instruction in your Dockerfile to expose the appropriate port (E.g 5000) and use the WEBSITES_PORT app setting on Azure with a value of "5000" to expose that port.

https://learn.microsoft.com/azure/app-service/containers/tutorial-custom-docker-image#configure-environment-variables

Do I need to use WEBSITES_PORT? This was also not supposed to be required as Azure was supposed to "auto-detect" my port I am listening on.

Kindly use app setting WEBSITES_PORT to set the port for your own docker image (from dockerhub/ACR/private registry)
https://learn.microsoft.com/azure/developer/python/tutorial-deploy-containers-02

Can I use ASPNETCORE_URLS in the DOCKER image, currently this is ignored but this is the preferred way from the ASP.NET Core development team.

You can just overwrite that environmental variable before aspnetcore app starts.
If there is an init.sh script:
export ASPNETCORE_URLS=<What you’d like it to be>

https://learn.microsoft.com/en-us/azure/app-service/containers/app-service-linux-faq#built-in-images

Overriding ASPNETCORE_URLS variable was identified as bug, (with Linux App Service using VNet integration and managed identity) a fix will be deployed soon, but not sharing ETA at this time.

Answer 2

If you are using VNet integration with Managed Identity enabled on a Linux App Service and you rely on the ASPNETCORE_URLS in your custom DOCKER image, then Azure will unintentionally override your ASPNETCORE_URLS environment variable with http://+:8081 which Microsoft has identified as a bug. A fix is ready but their deployment time is unknown as of now.

What I ended up doing is setting the WEBSITES_PORT environment variable in my DOCKER image which tells Microsoft the port I'm listening on. I then detected the WEBSITES_PORT variable in my code and if present I would listen on that port. I believe using WEBSITES_PORT can also speed-up the start-up time, because without it, I noticed Azure was attempting to connect to port 80 first and when that failed tried other ports.