Graphql-engine: Running hasura console via CLI in docker container

[codepunkt]

Hello!

I'm trying to run hasura console in docker container no#1 and then access the console on port 9695 on my host machine.

The JavaScript of the hasura console application needs access to both the graphql engine (running in docker container no#2) and the migration service spun up by running hasura console in docker container no#1.

The URLs that the JavaScript tries to talk to are based on two things:

• The endpoint configuration of config.yaml in docker container no#1
• The --address flag used to start hasura console with in docker container no#1, which defaults to localhost when not set.

Because the hasura console application is only available inside docker container no#1 when started with the default --address of "localhost", but is not available on the host machine of docker container no#1, i need to start it with --address 0.0.0.0 to have it bind to all available interfaces so it's not only reachable inside of container no#1, but also on the host machine.

Because the graphql engine is running in docker container no#2, which happens to be set up in a docker-compose.yml with docker container no#1 and a third run running postgres, i need to configure the endpoint in config.yaml to the docker compose service name of the second container, which is endpoint: http://graphql-engine:8080.

This is the only configuration where the console actually starts, because it can access docker container no#2 from docker container no#1 and where the started console is then actually reachable by my docker host, because it is bound to all available interfaces.

The problem:

The console web application now tries to talk to both http://graphql-engine:8080 and http://0.0.0.0 when accessed from the browser of my host machine - both of which are not available.

You can work around the first of those requests by having both container no#1 and container no#2 on the same network, so the graphql engine can be reached with endpoint: http://localhost:8080 - which also works on the docker host when port 8080 is exposed to the host.

I did not find any workarounds for the --address and the resulting requests to 0.0.0.0 though. Is there anything that i'm missing?

Would it be possible to add another configuration option to differentiate between the interfaces the graphql engine is actually served on and the URL that the clientside javascript uses to access it?

[shahidhk]

This is a known issue and we have some potential solutions.

The console served by CLI is designed to be run from a developers machine and not from any sort of webserver.

Will you be able to elaborate on what the use case here is, where you're unable to run the hasura cli locally?

[codepunkt]

We have packages that don't install/build under windows, which is why we develop in linux docker containers.

[shahidhk]

Are you saying the hasura CLI doesn't work on Windows?

[shahidhk]

Or it is just a matter of convenience where you'd prefer everything to be inside docker containers?

[codepunkt]

It's a matter of convenience. We wouldn't use Hasura/Postgres if they weren't available in official docker images. Development has to be done in a linux based container anyways, because parts of it don't work on windows.

We could possibly run the hasura CLI on windows, but that'd be a pain to do (no automatic installation, having it connect to graphql-engine running in a container, being forced to link files into the dev container etc).

Aside from that, we get "An attempt was made to access a socket in a way forbidden by its access permissions" by the windows executable and i can't tell why. Might be a windows/network/firewall configuration thing - which i might be able to fix, but which might also be company wide settings?

[shahidhk]

Got it. We'll ideate on how we can make the experience smoother. 😀

For migrations you'd have to mount the directory inside the container anyway.

Do let us know if there's an ideal workflow that you would like see. Helps in our ideation/brainstorming 😄

[codepunkt]

It'd probably be okay if there were additional options for the URLs the console's javascript is connecting to, something like endpoint and clientEndpoint, aswell as --address and clientAddress.

I know the naming is off, but you get the idea 😉

[shahidhk]

Thanks @codepunkt. We have an implementation at https://github.com/hasura/graphql-engine/pull/1780 and we should get to merging it soon.

[xorander00]

I'm having a similar issue as well. In my case, it's the ServiceWorker (/sw.js) that the console is trying to fetch, but the hasura is upstream on a different path, so it 404s.

I haven't delved into it yet, but from some quick searching on this repo, it looks like the console is using CRA? If so, then you should be able to inject the appropriate PUBLIC_URL environment variable (although I can't remember off the top of my head if this only happens during build-time or if applies at run-time as well).

Another option would be to let nginx configure a header using proxy_set_header, and then read that in hasura and pass it onto CRA. This approach is more flexible since it keeps that config where it's relevant, in nginx.conf.

Anyway, just my $0.02. Not a show stopper in my case because it's just the service worker that's not loading, and from the looks of it, it's not mandatory.

[Sevensidedmarble]

I'd like to chime in and say I'd love to be able to serve the console from the same docker-compose file as I do the hasura instance itself.

[BlueSeph28]

is there a workaround to do this without this pull request or creating a new container by my own?
I've run console manually, but doesn't work.

INFO console running at: http://localhost:8081/
The port 8081 is binded for my container, but I receive in my browser.

This page isn’t working localhost didn’t send any data. ERR_EMPTY_RESPONSE

I have this configuration for docker-compose

````
version: '3'
services:
hasura:
environment:
- HASURA_GRAPHQL_DATABASE_URL=postgres://[some pass]:[some user]@db:5432/[some db]
- HASURA_GRAPHQL_ENABLE_CONSOLE=false
image: hasura/graphql-engine:v1.0.0-rc.1.cli-migrations
container_name: hasura
volumes:
- ./hasura-migrations:/hasura-migrations
networks:
- hasura-db
ports:
- "8081:8080"
- "8082:8081"
restart: always
command: hasura-cli console --console-port 8081 --api-port 8081 --no-browser
db:
environment:
- POSTGRES_USER=[some user]
- POSTGRES_PASSWORD=[some pass]
- POSTGRES_DB=[some db]
image: postgres:11.4-alpine
container_name: db
restart: always
networks:
- hasura-db

networks:
hasura-db:
````

[shahidhk]

We're ideating on a simpler solution for this where all CLI APIs are protected by admin secret and all that needs to be done is to expose them correctly.

[kevintelford]

Same as @Sevensidedmarble - for convenience we'd love to just run the console and track migrations from docker-compose, instead of introducing the Hasura CLI tool. The CLI tool itself has its uses obviously, but for some colleagues and responsibilities it'd be great to have one less boundary here.

Regardless, great work on this and thanks! Super useful service.

[Sevensidedmarble]

It looks like #3570 is pretty close, will that add the feature we want? And if so what's the time table on merging?

[shahidhk]

@Sevensidedmarble Yes, #3570 will address this issue. We're blocked on some console related changes for this to go in. Expecting to be in 1.3 or 1.4 release.

[vorpus]

for convenience we'd love to just run the console and track migrations from docker-compose, instead of introducing the Hasura CLI tool.

@kevintelford What is your current workaround for this? Make migrations on a local instance and sync with version control?

[plmercereau]

Hello, any idea on when it will be solved? Or a workaround while waiting?
Thanks

[peterldowns]

What's the status on this? We're running hasura inside kubernetes, and would like to avoid exposing our hasura endpoint publicly but still access the console. To access the console in such a situation, we would like to run kubectl proxy and then, with the graphql engine container running behind a service called hasura, run

hasura console \
  --endpoint 'http://localhost:8001/api/v1/namespaces/staging/services/hasura/proxy' \
  --admin-secret '<our-special-secret>'

Right now this works in that the cli program is able to auth correctly (hasura metadata apply works correctly), but the console is not actually accessible in the browser due to cross origin issues. It seems the that the browser console, running on domain http://localhost:9695/, attempts to make network requests directly to the endpoint on the host http://localhost:8001, which gets blocked with CORS issues:

I see that from above the plan to proxy requests through the cli (#1440) was abandoned in favor of #3570, which also seems to have been abandoned as of July of this year. What do you recommend we do? I would really like to not publicly expose our hasura instance if at all possible (in our own webapp we proxy requests to it through our backend).