Azure App Service + Node container failed to respond to HTTP Pings, Websites_Port already set

Question

Azure App Service + Node container failed to respond to HTTP Pings, Websites_Port already set

B Campbell 26

I have a Node-Sails backend service that runs locally in Docker without issue (it checks a DB every minute so I can see if it's working), but after deploying to Azure App Service (on the free tier) the app gets killed for 'not responding to HTTP pings'.

Some details

My Dockerfile has 'EXPOSE 9007' since that's the port I'm using
Azure Application Settings has WEBSITES_PORT=9007 - this was all I needed to do for a separate app, although that was a React frontend on 9006 whereas this is a sails rest service
To deploy I'm doing 'docker build .' locally and then pushing the image to Azure Container Registry
Inbound traffic Access Restrictions are switched off
I've no options for Outbound traffic as I'm using the Free tier at the moment
Navigating to the App Service URL times-out (eventually showing the Azure broken app page), as does trying to access a GET endpoint on the URL.
Outbound traffic works as I can see it's able to query my DB
The Docker run string looks right from the logs - docker run -d --expose=9007 --name {my service name} -e WEBSITES_ENABLE_APP_SERVICE_STORAGE=false -e WEBSITES_PORT=9007 -e WEBSITE_SITE_NAME={my service name} -e WEBSITE_AUTH_ENABLED=False -e WEBSITE_ROLE_INSTANCE_ID=0 -e WEBSITE_HOSTNAME={my service name} -e WEBSITE_INSTANCE_ID={some long uuid} -e WEBSITE_USE_DIAGNOSTIC_SERVER=False {my ACR name and image tag}
Things I've tried already
Also setting PORT=9007 in Application Settings (no effect)
Increasing the timeout with WEBSITES_CONTAINER_START_LIMIT (it took longer before it was killed)
Changing the WEBSITE_SWAP_WARMUP_PING_PATH to one of the defined service endpoints (no effect)
Added the ICMP module to the service and started it listening when the sails app starts (no effect, no log of it receiving a ping)
Added a default route to the service to respond to any incoming traffic (no effect)
Added an index.html file (no effect)

Whenever I restart the service I get the same result from the log-streaming service; it says it's warming-up until the timeout expires, then it shuts down. When it shuts down it also shows me the log from Sails, proving that the container was actually up and running and talking to the outside world while the warmup said it was silent.

Questions

What exactly is an HTTP ping, because I understood ping was an ICMP operation? Is Azure actually doing an HTTP GET request, or something else?
Is there something I'm missing in my Node/Sails service that could be blocking these 'pings'?
As far as I can tell there are zero network restrictions on this App Service, so why can't I access it externally for the few minutes it runs before Azure shuts it down again?

Lex Li (Microsoft) 6,037 Reputation points Microsoft Employee

2022-10-08T06:33:18.373+00:00

Instead of binding your Node.js HTTP server to localhost:9007, bind it to 0.0.0.0:9007 and try again.

1 answer

Your answer

Lex Li (Microsoft) 6,037 Reputation points Microsoft Employee

2022-10-08T06:33:18.373+00:00

Instead of binding your Node.js HTTP server to localhost:9007, bind it to 0.0.0.0:9007 and try again.

Answer 1

ajkuma 28,036 Microsoft Employee Moderator

LostVoyager-0056, Apologies for the delay from over the weekend.

Thanks for sharing great details about your scenario and things you have tried already.
Kindly try the suggestion by lextm to change the binding. As code is listening on localhost, then it will not be accessible outside that specific container, hence, the app will fail to start. To get past this, make the app code listen on 0.0.0.0

As I understand you’re hardcoding the port. Just to isolate, try with port 8080.
If you haven't done, change this to use process.env.PORT.
const port = process.env.port || 8080;

Just to confirm, you mentioned that you used WEBSITES_CONTAINER_START_LIMIT vs WEBSITES_CONTAINER_START_TIME_LIMIT? -Yes, by default, if your container does not respond after 230 seconds, it will time out. (try with this - WEBSITES_CONTAINER_START_TIME_LIMIT app setting, set to 1800.

ajkuma 28,036 Reputation points Microsoft Employee Moderator

2022-10-10T12:55:01.663+00:00

Additionally,

--The Free(F1) and Shared (D1) App Service plans (ASP) are base tiers that run on the same Azure VMs as other apps. Lower compute resources. These tiers are intended to be used only for development and testing purposes.
So, just to isolate/test -based on your scenario you can leverage the least cost Basic tier ( B1) or higher and then scale-down.

--All Azure Web Apps run in a secure environment called a sandbox. See this doc for Sandbox restrictions.

--Additionally, just to highlight, by default, Sails will be listening on port 1337. You can specify the app setting sails_port to desired port value.
Set start script in package.json as NODE_ENV=production node app.js.

Review sample nodejs Sails
B Campbell 26 Reputation points

2022-10-10T15:05:22.417+00:00

Thanks all for the suggestions!

@Anonymous I've managed to set the host, but I get the same result (w + w/o WEBSITES_PORT=8080)-
B Campbell 26 Reputation points

2022-10-10T15:06:10.36+00:00
@Anonymous I've tried changing the port to 8080 (and tried it both with and without the WEBSITES_PORT setting, as I think 8080 is auto-detected by Azure?) but still same result; container starts, I see that it's talking to my DB, and then it's shut down.

I've added a separate Express server to the Sails app.js file and it's still not getting through. Code extract -

const express = require('express') const server = express() const options = { index: 'index.html' } server.use('/', express.static('/home/site/wwwroot', options)) server.listen(process.env.PORT || '0.0.0.0:8080', () => { console.log('Express server listening on port ' + process.env.PORT) })

When I run the app with the above, and without specifying WEBSITES_PORT, then it actually responds to Azure and doesn't kill the container. But then Sails fails to start because EADDRINUSE.

I may have typod in my initial post, but the time taken to shut down the container changed as expected so I had the right one in Azure.

Thanks for the info about the sandbox networking; I had suspected there was something like that in place, however it seems to be contradicted by the other pages which state to use WEBSITES_PORT if you're using a custom container listening on a different port. Does WEBSITES_PORT actually configure port mapping between the container and Azure, or something else?
ajkuma 28,036 Reputation points Microsoft Employee Moderator

2022-10-11T19:20:28.76+00:00

Yes, you’re right, if container listens to port 80 or 8080, App Service is able to automatically detect it.

Just to clarify, built-in containers is predefined container is selected for you. In this case, PORT environment is used.
However on Custom containers (as in your case)– you have full control over the container - App Service has no control about which port your container listens on. What it does need is to know which port to forward requests to.

If it listens to any other port, you need to set the WEBSITES_PORT app setting to the port number, and App Service forwards requests to that port in the container. The WEBSITES_PORT app setting does not have any effect within the container, and you can’t access it as an environment variable within the container.

Typically, the error EADDRINUSE occurs when the port number, listen() tries to bind the server which is already in use. So, in your case, there must be running a server on a specific port already. Kindly review all the settings where port value is used.

I’ll also follow-up with you privately for some additional info to review internal logs. I will leave this thread open for other users to share more insights.
B Campbell 26 Reputation points

2022-10-12T07:19:36.857+00:00

I believe the EADDRINUSE message was caused by this Express server trying to listen on the same port as the Sails.js server is using (which itself is built on Express), when I remove the code snippet above that error goes too.

As I've been struggling with this issue for quite some time, I decided to try creating a Container Instance with the same Docker image instead, and that method works perfectly. The container launches and is accessible on the specified port (now 8080) without issue. But the Container Instance has vastly reduced options compared to the App Service (e.g. it doesn't spin-down), and it seems that to change the port for example I have to delete the CI and create a new instance with the new setting, so I don't think that's going to be a permanent solution.

I'll respond to your PM separately, thank you.
ajkuma 28,036 Reputation points Microsoft Employee Moderator

2022-10-13T11:47:42.473+00:00

LostVoyager-0056, Apologies you're still experiencing this issue. Thanks for the follow-up and sharing additional info. I'm following-up with you privately.

Share via

Azure App Service + Node container failed to respond to HTTP Pings, Websites_Port already set

Some details

Things I've tried already

Questions

1 answer

Your answer