Mesh not working in Docker desktop

[sesmi123]

Hi,

I have a requirement to run the mesh server in local docker desktop as well as kubernetes cluster. The docker image for the mesh server works as expected when deployed in kubernetes. But the same image when run in a docker container directly, it is not connecting. This is the Dockerfile:

FROM node:latest
WORKDIR /gql-mesh
COPY . .
RUN npm install
ENV NODE_ENV=production
ENV DEBUG=1
EXPOSE 4000
CMD npm run start

I used the command docker run -d -p 4000:4000 <<image-name>> to start container.
The container logs show that the server started successfully. However it is not accessible at http://localhost:4000/graphql. A curl to this url from inside the container shell gives error: server returned error: HTTP/1.1 400 Bad Request

Any thoughts on why it is not accessible?

[jamesmmchugh]

I had what I think is the same issue. The process by default binds to 127.0.0.1 loopback IP, which is not accessible outside of the container, and instead needs to be bound to 0.0.0.0. You can configure this in the .meshrc.yaml using the hostname property in the serve config: https://www.the-guild.dev/graphql/mesh/docs/config-reference#serve

[ardatan]

Mesh defaults to 0.0.0.0
https://github.com/Urigo/graphql-mesh/blob/master/packages/cli/src/commands/serve/serve.ts#L58

[jamesmmchugh]

The logs provided say it's binding to 127.0.0.1 in this particular case, perhaps in that case it has been set explicitly in meshrc?

[jamesmmchugh]

I had the exact same issue using this docker image https://github.com/onelittlenightmusic/graphql-mesh-docker

When I overrode their default meshrc config (which does explicitly set the hostname to 0.0.0.0) with my own that didn't include hostname.

Admittedly, I didn't look into it for long after seeing the hostname option in the default config, and I can't see how that conditional would fail.

[jamesmmchugh]

I realised in my case the docker image has an old version of mesh on it, where the default was 127.0.0.1 rather than 0.0.0.0, it seem this was changed at some point in the past.

I can't comment on the version being used in this issue, but their logs explicitly state it's bound to 127.0.0.1 - so i think my comment regarding setting the hostname might still resolve their issue.