Keystone has stopped binding to 0.0.0.0 by default

HI, I am always very keen to deploy and test new releases as soon as possible, in the case of the recent release its seems there is a breaking change that causes the healthcheck config and endpoints declared in extendExpressApp config to be blocked when not using localhost.

I have a micro services setup using AWS ECS Fargate fronted by a Elastic Load Balancer. When i attempted to deploy the recent update to our staging server the keystone service kept failing on rolling update because the container was failing ELB health checks. I was bemused as the Fargate health checks were satisfied but the ELB not.

To prove the recent release was the cause I rolled back and the health checks were successful and the service was deployed.

In respects of the rollback test I decided to do some digging. With a version of the keystone service that was deploying successfully I logged the headers on the request to the health check end point. These logs would appear each for the Fargate container health check and the ELB health check. The first distinct difference noticed was the host header.

Host header for the Fargate health check which was visible before and after update: “localhost:3000” Host header for the ELB which was visible only before the update: “10.0.1.224:3000”

So Fargate is using localhost and ELB using private IP address, which would be expected.

Therefore to replicate / prove this on a local machine:

Start Keystone before the 20221117 upgrades. Execute a curl command to invoke health check endpoint using localhost. curl http://localhost:3000/healthcheck : SUCCESS Execute a curl command to invoke health check endpoint using IP. curl http://192.168.0.10:3000/healthcheck : SUCCESS Start Keystone after the 20221117 upgrades. Execute a curl command to invoke health check endpoint using localhost. curl http://localhost:3000/healthcheck : SUCCESS Execute a curl command to invoke health check endpoint using IP. curl http://192.168.0.10:3000/healthcheck : Failed to connect, Connection Refused.

I have not yet dug into the change set for the upgrade and so have not yet discovered which of the upgraded packages is the culprit. I will try and look into this more later if the Keystone team have not yet responded.

Look forward to the conversation about this issue.

Thanks in advance.

[dnmahendra]

All container builds stopped working after upgrading to "@keystone-6/core": "3.1.1". Getting the same error as above connection refused. This is happening because the host is binding to localhost inside the container. Setting this option server.options.host to 0.0.0.0 resolved the problem. This option is not documented well.

[dcousens]

Thanks @dnmahendra for the easy explanation 💛 The behaviour has accidentally been introduced by https://github.com/keystonejs/keystone/pull/8078, I’ll follow this up