krispenner avatar image
0 Votes"
krispenner asked ajkuma-MSFT commented

Linux VNet Integration GA Issues

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= // 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.

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
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: 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.

· 2
5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

@krispenner, Welcome to Microsoft Q&A. Thanks for posting the question.

I have responded to your thread on GitHub. Once again apologies for any inconvenience with this problem, I completely understand the frustration here.

While I'm checking on this issue with the detailed information you had shared and also discussing on this internally, as mentioned in the GitHub thread, kindly reach out to us. We will follow-up on this further.

0 Votes 0 ·

For community: Just to keep this thread updated. We are discussion on this issue offline with Kris, answering his questions, we will update the thread with our findings soon.

0 Votes 0 ·
ajkuma-MSFT avatar image
1 Vote"
ajkuma-MSFT answered

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.

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)

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 script:
export ASPNETCORE_URLS=<What you’d like it to be>

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.

5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

krispenner avatar image
0 Votes"
krispenner answered ajkuma-MSFT commented

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.

· 1
5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

Thanks again Kris for taking time to share the summary of our discussions to benefit the community.

0 Votes 0 ·