Closed iamarno closed 3 years ago
Hi @iamarno Thank you for your feedback! We will review and provide an update as appropriate.
@iamarno, Apologies for the delay in responding! Typically, the WEBSITES_PORT works and yes as stated in the doc, we’re planning to deprecate ‘PORT’ app setting and to use ‘WEBSITES_PORT’ exclusively. To understand how exactly you’re testing the App setting for port and get more clarity on the scenario/issue you’re experiencing, could you please send an email to AzCommunity[at]Microsoft[dot]com referencing this GitHub issue. As I will work with you offline, I will now proceed to close this thread. Thanks again for reporting the issue.
This probably shouldn't have been closed because I ran into this exact same issue. PORT works, WEBSITES_PORT is not recognized.
Thanks @KurtSmith, you may track the issue here #31771. Thanks for sharing your feedback!
I finally got mine to work by using PORT instead of WEBSITES_PORT. Still, only about a day wasted. Why is this issue closed when it's still a big issue?
I have been discussing on this internally with the product team and the content author, this is being reviewed further and I’ll post back as soon as I have more update. I understand the trouble, Steve. Apologies for the inconvenience caused! This is being reviewed.
Hi! I am having the same issue here. I am trying to deploy my app for a couple of days now, tried numerous tutorial methods but to no avail. I tried Dan Taylor's tutorial https://www.youtube.com/watch?v=DPBspKl2epk&t=690s and Deployed according to his specific methods, but still has an error of:
Container goodnewsworkvs_0_129f6dbb didn't respond to HTTP pings on port: 8400, failing site start.
I have put Expose and Listen to Dockerfile set to 8400, and Fixed the WEBSITES_PORT to 8400 . I have also tried using PORT instead of WEBSITES_PORT and it still does not work.
I am at my wits end and have no clue on how to proceed, please anyone out there help me.
Here is my Subscription ID:
Any help would be very much appreciated.
Thank you very much and I hope you have a great rest of your day.
Edited: PII
Hi @AlbertSugi I think you shouldn't post your subscription ID here, but however. Let me point some things out.
@AlbertSugi, as @iamarno mentioned it is not recommended to post PII information (including subscription ID) on the public forum. Thanks, Arno!
Hi @iamarno @AjayKumar-MSFT Thanks very much for the input! I do make my docker listen to 8400, and I have tried adding PORT instead of WEBSITES_PORT at 8400, but probably needs to add both? Should the docker include ngunicorn installed? I still dont really understand how azure wraps our app.
Thanks a lot again for the feedback and I will let you guys know if i figured it out!
Just confirming that this has just happened to me also. Using WEBSITES_PORT, I could see that the environment variable was being passed as an argument to docker in the logs docker run ... -e WEBSITES_PORT=3000 ...
however that was not being reflected in the port binding mapping on that same command (-p).
# With WEBSITES_PORT=3000
# Expected command:
docker run -p <host-port>:3000 ... -e WEBSITES_PORT=3000 ...
# Actual Command:
docker run -p <host-port>:8081 ... -e WEBSITES_PORT=3000 ...
# with WEBSITES_PORT=3000 + PORT=3000
# Expected command:
docker run -p <host-port>:3000 ... -e WEBSITES_PORT=3000 -e PORT=3000 ...
# Actual Command:
docker run -p <host-port>:8081 ... -e WEBSITES_PORT=3000 -e PORT=3000 ...
For me (docker .netcore linux app service in Canada Central) on Free tier it works without any additional configuration changes and picks up the correct port (80). When I scale it up to P1V2 it doesn't. Setting WEBSITES_PORT doesn't work and PORT seems to get overwritten from what I set it to in app config. Free Tier working without any enviroment variables set:
2020_01_15_RD501AC5656534_docker.log:
2020-01-15 20:53:42.970 INFO - Pulling image: kdutt.azurecr.io/mvcauthsample:213
2020-01-15 20:53:43.228 INFO - 213 Pulling from mvcauthsample
2020-01-15 20:53:43.229 INFO - Digest: sha256:d6f14f9e5b0ebd8876822518f3dbcbb3d33ecf470baa3ea22ba3d70213957eda
2020-01-15 20:53:43.229 INFO - Status: Image is up to date for kdutt.azurecr.io/mvcauthsample:213
2020-01-15 20:53:43.247 INFO - Pull Image successful, Time taken: 0 Minutes and 0 Seconds
2020-01-15 20:53:43.345 INFO - Starting container for site
2020-01-15 20:53:43.345 INFO - docker run -d -p 3298:80 --name kdutt_0_b540aa33 -e WEBSITES_ENABLE_APP_SERVICE_STORAGE=false -e WEBSITE_SITE_NAME=kdutt -e WEBSITE_AUTH_ENABLED=False -e PORT=80 -e WEBSITE_ROLE_INSTANCE_ID=0 -e WEBSITE_HOSTNAME=kdutt.azurewebsites.net -e WEBSITE_INSTANCE_ID=e72ac5b17c6574f3ced950f54941e20cb3d62e26a50b6ece889ededb334459e9 kdutt.azurecr.io/mvcauthsample:213
2020-01-15 20:53:43.345 INFO - Logging is not enabled for this container.
Please use https://aka.ms/linux-diagnostics to enable logging to see container logs here.
2020-01-15 20:53:45.344 INFO - Initiating warmup request to container kdutt_0_b540aa33 for site kdutt
2020-01-15 20:53:49.059 INFO - Container kdutt_0_b540aa33 for site kdutt initialized successfully and is ready to serve requests.
P1V2
2020-01-15 21:35:49.270 INFO - docker run -d -p 3346:3346 --name kdutt_0_f5685e12 -e PORT=3346 -e WEBSITES_ENABLE_APP_SERVICE_STORAGE=false -e WEBSITES_PORT=80 -e WEBSITE_SITE_NAME=kdutt -e WEBSITE_AUTH_ENABLED=False -e WEBSITE_ROLE_INSTANCE_ID=0 -e WEBSITE_HOSTNAME=kdutt.azurewebsites.net -e WEBSITE_INSTANCE_ID=518ba45d6184f6a3519235f21225af4816219d136bf638834cb4cefb1e692de7 kdutt.azurecr.io/mvcauthsample:212
2020-01-15 21:35:49.271 INFO - Logging is not enabled for this container.
Please use https://aka.ms/linux-diagnostics to enable logging to see container logs here.
2020-01-15 21:35:50.451 INFO - Initiating warmup request to container kdutt_0_f5685e12 for site kdutt
We're trying to deploy a Docker image with a dotnet core project.
Before, it was actually doing:
docker run -d -p 3298:80 --name ..........
Then something changed, and it's starting with
docker run -d -p 7686:7686 --name ..........
Why? Feels like it's tied to these issues.
I'm experiencing the same issues. I've tried using PORT, WEBSITES_PORT, -e PORT etc and it doesn't seem to respect the values in any consistent fashion. I could swear this all used to work fine.
I also have some issues when deploying a docker image with a dotnet core project
Dockerfile:
#See https://aka.ms/containerfastmode to understand how Visual Studio uses this Dockerfile to build your images for faster debugging.
FROM mcr.microsoft.com/dotnet/core/aspnet:3.0-buster-slim AS base
WORKDIR /app
EXPOSE 80
FROM mcr.microsoft.com/dotnet/core/sdk:3.0-buster AS build
WORKDIR /src
COPY ["pswebapi.csproj", ""]
RUN dotnet restore "./pswebapi.csproj"
COPY . .
WORKDIR "/src/."
RUN dotnet build "pswebapi.csproj" -c Release -o /app/build
FROM build AS publish
RUN dotnet publish "pswebapi.csproj" -c Release -o /app/publish
FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "pswebapi.dll"]
Error from the logs:
2020-01-18 18:02:43.659 INFO - Logging is not enabled for this container.
Please use https://aka.ms/linux-diagnostics to enable logging to see container logs here.
2020-01-18 18:02:44.181 INFO - Initiating warmup request to container webapibrajzore_0_66ddf497 for site webapibrajzore
2020-01-18 18:02:44.310 ERROR - Container webapibrajzore_0_66ddf497 for site webapibrajzore has exited, failing site start
2020-01-18 18:02:44.312 ERROR - Container webapibrajzore_0_66ddf497 didn't respond to HTTP pings on port: 80, failing site start. See container logs for debugging.
2020-01-18 18:02:44.326 INFO - Stoping site webapibrajzore because it failed during startup.
Must I set some settings in Configuration -> Application settings in Azure?
Apologies for the delay and any inconvenience with this. Couple of things to review:
If you're using VNet integration preview feature, you will need to modify your application in order to integrate with VNet. This is a temporary limitation during VNet Preview release, we will remove the limitation before GA. In your application, please use the PORT environment variable as the main web server’s listening port, instead of using a hardcoded port number. The PORT environment variable is automatically set by App Service platform at startup time. Kindly checkout this document for more details on this topic.
For Windows Container, if you're using the Windows 2016 base image, could you please use the Windows Server 2019 base image (for example: microsoft/aspnet:4.7.2-windowsservercore-ltsc2019). An added benefit of this change will be faster load times and higher cost effectiveness due to significantly smaller image size. Please check this announcement for more info on this: https://azure.microsoft.com/en-us/updates/windows-server-2019-support-added-to-public-preview-of-windows-container-support/
If the issue still persists, could you share the WebApp name directly here or indirectly and the base image you're leveraging for a closer look.
@AjayKumar-MSFT Not sure what VNet integration means, but for Linux containers PORT is still not working. This is what I see when setting PORT and WEBSITES_PORT. - docker run -d -p 0:8080 --name tiny-api_api_3_dc7b3363 -e PORT=5000 -e WEBSITES_ENABLE_APP_SERVICE_STORAGE=false -e WEBSITES_PORT=5000 -
I'm running a dotnet core app and I suppose I can set the port just like the example doc. I haven't tried. Even if it works, this isn't ideal.
@AjayKumar-MSFT I'm running a Node Express app with super simple setup just for testing, in the application I already set app.listen(process.env.PORT)
. But this is what I see with setting PORT and WEBSITES_PORT to 8000
: docker run -d -p 7211:8000 --name test-db_0_62aaa67c
. Then the app stucks at Initiating warmup request to container test-db_0_62aaa67c
and eventually failed. Same case if I do not set PORT and WEBSITES_PORT. This is very frustrating, what is going on here?
@AjayKumar-MSFT I'm running a Node Express app with super simple setup just for testing, in the application I already set
app.listen(process.env.PORT)
. But this is what I see with setting PORT and WEBSITES_PORT to8000
:docker run -d -p 7211:8000 --name test-db_0_62aaa67c
. Then the app stucks atInitiating warmup request to container test-db_0_62aaa67c
and eventually failed. Same case if I do not set PORT and WEBSITES_PORT. This is very frustrating, what is going on here?
Were you able to sort this one? I also deployed the most basic nodejs app from MS tutorial and still getting error?
@AjayKumar-MSFT I'm running a Node Express app with super simple setup just for testing, in the application I already set
app.listen(process.env.PORT)
. But this is what I see with setting PORT and WEBSITES_PORT to8000
:docker run -d -p 7211:8000 --name test-db_0_62aaa67c
. Then the app stucks atInitiating warmup request to container test-db_0_62aaa67c
and eventually failed. Same case if I do not set PORT and WEBSITES_PORT. This is very frustrating, what is going on here?Were you able to sort this one? I also deployed the most basic nodejs app from MS tutorial and still getting error?
this is what i get aswell. is there a solution for it ?
I have the same problem too, azure guys, please!
Also getting the same problem, why has this been closed?
Hey guys: I happened to stumble upon these same problems a while ago and there should be a couple of things you guys have to check on:
#!/usr/bin/env python3
from flaskapp import app
if __name__ == '__main__':
app.run(host='0.0.0.0',port="8400",debug=True)
#app.run(host='172.17.0.1',port="3306",debug=True)
FROM tiangolo/uwsgi-nginx-flask:python3.7
FROM ubuntu:latest
ENV LISTEN_PORT=8400
EXPOSE 8400
For full deployment from start to finish, you can consult this video (python) but hopefully it works with other languages: https://youtu.be/DPBspKl2epk
Hopefully this helps you guys! Cheers!
Apologies everyone, you're still seeing the same issue. To clarify, use app setting WEBSITES_PORT to set the port for your own docker image while for blessed images use PORT environment variable as the listening port. We will make this more clear in the document.
In case you're leveraging Linux App Service with VNet integration -As mentioned in this document for Linux App Service VNet integration (Preview) - During Preview you will need to modify your application in order to integrate with VNet. This is a temporary limitation during VNet Preview release, we will remove the limitation before GA. In your application, please use the PORT environment variable as the main web server’s listening port, instead of using a hardcoded port number. The PORT environment variable is automatically set by App Service platform at startup time.
Thanks Albert for sharing the solution that worked for you with the community.
Took a bit of trial/error for me, but here's what I've found. I had a docker image that I wanted to use was one I didn't create, but publicly available on docker hub.
The port was set to 8030, but could be overridden by using the PORT environment variable.
I tried setting PORT to 80 and saw it was being utilized correctly via the startup command: -e PORT=80
.
However, I did also see this in the logs:
ERROR: [main] Error starting http listener on port: 80 listen tcp :80: bind: permission denied
I decided to only use WEBSITES_PORT and it worked.
-e WEBSITES_PORT=8030
On another instance, I had WEBSITES_PORT=8030, but it didn't work. I set PORT to blank via the Configurations tab and things started working. So, that's my new go-to configuration.
I have a simillar issue. On linux server I am using startup.sh to run my java solr service which run on port 80. But azure says it could not ping http 80. I could not figure it out.
2020-05-17T01:35:39.621944065Z STARTUP_FILE=/home/startup.sh
2020-05-17T01:35:39.621992864Z STARTUP_COMMAND=
2020-05-17T01:35:39.622000264Z Copying /home/startup.sh to /tmp/startup.sh and fixing EOL characters in /tmp/startup.sh
2020-05-17T01:35:39.632796986Z Running STARTUP_FILE: /tmp/startup.sh
2020-05-17T01:35:39.913577852Z Waiting up to 180 seconds to see Solr running on port 80Finished running startup file '/tmp/startup.sh'. Exiting with exit code 0.
2020-05-17T01:35:40.603Z ERROR - Container mmsolr for site mmsolr has exited, failing site start
2020-05-17T01:35:40.614Z ERROR - Container mmsolr_0_c884866e didn't respond to HTTP pings on port: 80, failing site start. See container logs for debugging.
2020-05-17T01:35:40.618Z INFO - Stopping site mmsolr because it failed during startup.
+1 here.
Running Azure Web App on Linux for a NodeJS application and facing the same issue. Not working with WEBSITES_PORT or PORT.
I was struggling with this today and have just got it working after setting BOTH PORT and WEBSITES_PORT values. Either one on its own didn't work.
+1 this is an issue. My workload is a jekyll site that listens on 4000. My dockerfile is exposing 4000, setting the LISTEN_PORT env var to 4000, and serving on 4000.
App Service config settings for both WEBSITES_PORT and PORT only toggle the host mapping.
In my case, I end up with -p [randomport]:4000 every time. When I need -p 4000:4000.
There doesn't appear to be any way to specify the container port binding in a single container deployment on App Service.
@AjayKumar-MSFT kindly request you reopen this issue
+1 experienced same issue. I tried to deploy a linux docker image (a .net core web app) to Azure App service and got the following errors:
2020-06-11T17:55:59.454Z ERROR - Container for site testdeletable has exited, failing site start 2020-06-11T17:55:59.455Z ERROR - Container didn't respond to HTTP pings on port: 80, failing site start. See container logs for debugging.
Setting BOTH PORT and WEBSITES_PORT values does not work for me :(
Having the same problem with a django app in a container. Set both PORT and WEBSITES_PORT to 8000 and I get the same thing as @wbsmolen , a random port every startup.
docker run -d -p 1674:8000 --name django-XXXXX -e PORT=8000 -e WEBSITES_ENABLE_APP_SERVICE_STORAGE=false -e WEBSITES_PORT=8000 -e WEBSITE_SITE_NAME=django-XXXXX -e WEBSITE_AUTH_ENABLED=False -e WEBSITE_ROLE_INSTANCE_ID=0 -e WEBSITE_HOSTNAME=django-XXXXX.azurewebsites.net -e WEBSITE_INSTANCE_ID=[redacted] acr.azurecr.io/image:latest
This feature clearly does not work, and either the docs need to be redacted to remove this instruction or a high-priority bug needs to be raised with the app service team.
I reached out to some Microsoft stakeholders who should be able to escalate this.
In the interim, and without excusing/disregarding the core issue here, I added a docker-compose.yml file in the same directory as my dockerfile. The docker-compose explicitly exposes 4000:4000. This opened up the port for me.
The weird thing is this is a single container deployment. The app service config isn’t set to call docker-compose.yml. I didn’t touch the app service config (kept both WEBSITES_PORT and PORT at 4000).
Sharing this as an anecdotal bandaid.
Thanks, @wbsmolen , that may get me unstuck
I am having the same issue, with a rust app in a container, specifying both PORT and WEBSITES_PORT gives me a random port every startup.
@wbsmolen How did your compose file look? And did you add it to any commands, etc? I would really appreciate any help, I really need this working.
That's the thing, it wants to decide what ports your app uses.
You should not specify a port yourself on the env vars WEBSITE_PORT
or PORT
. In my node app, I simply listen to process.env.PORT
and the Azure App Service sets the appropriate number.
So, I am quite not sure whether this issue is open or not!
We wasted time trying to fix our apps and or the way we were deploying via AZ CLI but after trying to deploy to Azure a simple example from plotly we found out that it's apparently a well-know issue (Yes, Bing brought me here).
I also followed the recommendation from Configure a custom Linux container for Azure App Service:
az webapp config appsettings set --resource-group <resource-group-name> --name <app-name> --settings WEBSITES_PORT=8000
NADA!
We are migrating some apps to Azure Services and this is a show-stopper: any next step, hack, patch we can use?
After working with Microsoft we found the actual issue, which is not related to what it is discussed here. The error message was misleading !!! The actual issue had to do with Plotly | Dash: The port was not the issue but the application object, which is documented in Deploying Dash Apps
In this case I had to create a server global object and change the gunicorn command to:
gunicorn startup:server
Everyone, apologies for all the frustration and inconvenience with this issue. We have relayed this issue to our product engineering and have been discussing on this internally. We will respond on this shortly.
For those the issue still persists, please share one of your WebApp name directly or indirectly .
We strive to provide great experience, once again apologies for all the trouble with this. Thanks for your patience and co-operation.
We are encountering this same issue -
docker run -d -p 9931:8080 --name <VALUE> -e PORT=8080 -e WEBSITE_SITE_NAME=<VALUE> -e WEBSITE_AUTH_ENABLED=False -e WEBSITE_ROLE_INSTANCE_ID=0 -e WEBSITE_HOSTNAME=<VALUE> -e WEBSITE_INSTANCE_ID=<VALUE> -e HTTP_LOGGING_ENABLED=1 appsvc/node:12-lts_20200522.6
So, I am quite not sure whether this issue is open or not!
We wasted time trying to fix our apps and or the way we were deploying via AZ CLI but after trying to deploy to Azure a simple example from plotly we found out that it's apparently a well-know issue (Yes, Bing brought me here).
I also followed the recommendation from Configure a custom Linux container for Azure App Service:
az webapp config appsettings set --resource-group <resource-group-name> --name <app-name> --settings WEBSITES_PORT=8000
NADA!
We are migrating some apps to Azure Services and this is a show-stopper: any next step, hack, patch we can use?
Don't set the port through WEBSITE_PORT, and listen to PORT in your app. PORT is implicitly set by Azure so we can share machines with others.
We are encountering this same issue -
docker run -d -p 9931:8080 --name <VALUE> -e PORT=8080 -e WEBSITE_SITE_NAME=<VALUE> -e WEBSITE_AUTH_ENABLED=False -e WEBSITE_ROLE_INSTANCE_ID=0 -e WEBSITE_HOSTNAME=<VALUE> -e WEBSITE_INSTANCE_ID=<VALUE> -e HTTP_LOGGING_ENABLED=1 appsvc/node:12-lts_20200522.6
And again. Don't set the environment variable yourself, not through WEBSITE_PORT or PORT. Instead, just use it directly in your app.
Guys, 3 times I've been answered this. Just LISTEN to it, don't SET it! The port is set implicitly for you. And no, you are not stupid. Microsoft's docs on this just isn't very clear.
This issue rose because one couldn't set the PORT, as you could before. They changed it silently. That's why Microsoft still has this open, cause they obviously screwed this one up.
@peturh - I had set the PORT/WEBSITE_PORT through other troubleshooting methods. The Docker container will not start and the following errors continue to appear in the log:
2020-07-06T17:36:48.951Z ERROR - Container <CONTAINER> for site <SITE> has exited, failing site start
2020-07-06T17:36:48.959Z ERROR - Container <CONTAINER> didn't respond to HTTP pings on port: 8080, failing site start. See container logs for debugging.
It's been a stab in the dark trying to understand A) why this started because the site was working fine and B) how to resolve it. A series of forum searches led me to this post, so again, just trying different suggestions in an attempt to identify this problem.
@peturh - I had set the PORT/WEBSITE_PORT through other troubleshooting methods. The Docker container will not start and the following errors continue to appear in the log:
2020-07-06T17:36:48.951Z ERROR - Container <CONTAINER> for site <SITE> has exited, failing site start 2020-07-06T17:36:48.959Z ERROR - Container <CONTAINER> didn't respond to HTTP pings on port: 8080, failing site start. See container logs for debugging.
It's been a stab in the dark trying to understand A) why this started because the site was working fine and B) how to resolve it. A series of forum searches led me to this post, so again, just trying different suggestions in an attempt to identify this problem.
Again, DON'T SET the port, not through WEBSITE_PORT or PORT. Just listen to it, because it's set implicitly for you.
@peturh - I had set the PORT/WEBSITE_PORT through other troubleshooting methods. The Docker container will not start and the following errors continue to appear in the log:
2020-07-06T17:36:48.951Z ERROR - Container <CONTAINER> for site <SITE> has exited, failing site start 2020-07-06T17:36:48.959Z ERROR - Container <CONTAINER> didn't respond to HTTP pings on port: 8080, failing site start. See container logs for debugging.
It's been a stab in the dark trying to understand A) why this started because the site was working fine and B) how to resolve it. A series of forum searches led me to this post, so again, just trying different suggestions in an attempt to identify this problem.
Again, DON'T SET the port, not through WEBSITE_PORT or PORT. Just listen to it, because it's set implicitly for you.
It's been removed but the error above still persists. I ended up on this thread based on comments from https://github.com/MicrosoftDocs/azure-docs/issues/46401. Not arguing about the port setting, simply trying to resolve the issue with the Docker container not starting with very little information from Azure or the support forums to figure it out.
Guys, 3 times I've been answered this. Just LISTEN to it, don't SET it! The port is set implicitly for you.
I believe this is only correct if someone is using the Azure App Service VNet Integration feature. For others, the port must be set, cf. https://docs.microsoft.com/en-us/azure/app-service/containers/tutorial-custom-docker-image#configure-environment-variables
Apologies everyone for the delay and frustration with this issue.
There was a bug found with Linux App Services using VNet integration and managed identities (MSI). The ASPNETCORE_URLS environment variable was being overwritten by Azure and it should not have been. A fix has already been completed and deployment is pending at this time.
Adding some of the frequently asked question, we will work with author to make appropriate changes in the document to bring more clarity.
Do I need to use the PORT variable still in code, this restriction was supposed to be removed with Linux Container with VNet 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) https://docs.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://github.com/MicrosoftDocs/azure-docs/issues/58350 - 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.
https://docs.microsoft.com/en-us/azure/app-service/containers/app-service-linux-faq#built-in-images
@AjayKumar-MSFT Very timely update, much appreciated. I opened just recently a SO issue at https://stackoverflow.com/questions/62997168/deploying-containerized-linux-asp-net-core-to-azure-webapp-fails-due-to-port-80 (a test project at https://github.com/veikkoeeva/dockerservice, probably need to refactor port code a bit) and linked here, so link also from here to there. I'm using containerized WebApp in sub-VNET and I understand it will be fixed once deployment has completed.
@AjayKumar-MSFT Can WEBSITES_PORT
take in multiple values eg: 80 and 443?
@AjayKumar-MSFT Can
WEBSITES_PORT
take in multiple values eg: 80 and 443?
Apologies for the delay! It's only one value. By default, App Service assumes your custom container is listening on port 80.
@AjayKumar-MSFT
I have the same error.
"2020-10-28T17:33:35.452Z ERROR - Container lunchtimecontainerapi_0_afba9f03 didn't respond to HTTP pings on port: 80, failing site start. See container logs for debugging. 2020-10-28T17:33:36.397Z INFO - Stopping site lunchtimecontainerapi because it failed during startup."
I'm using Azure Docker Container on a Linux App Service without MSI and without VNet integration. I have removed PORT and WEBSITES_PORT settings so now it defaults to port 80 but that doesn't matter.
Can someone explain me how I now deploy a container that is exposing the port 8080? I tried it with a new dockerfile. I've tried it with a docker-compose file and I've tried to add/edit the PORT and WEBSITES_PORT variable. Without success.
@AjayKumar-MSFT This would be the app: https://metaboanalyst.azurewebsites.net/
Thanks!
I want to deploy the following dockercontainer from docker-hub: manubi/metaboanalyst:latest The container is exposing a webapp at port 8080/MetaboAnalyst
Any ideas are welcome! Thanks!
I was only able to set the docker exposed port with PORT. WEBSITES_PORT is not working at all.
Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.