search

open-dollar / od-subgraph

2 stars 0 forks source link

Create private network for graph node #10

Closed jahabeebs closed 11 months ago

jahabeebs commented 11 months ago

Protect render deployment:

1) Determine which ports need to be public (so anyone running the app can query the subgraph), and which need to be closed (only for us to check status, update subgraphs, etc) 2) Create a private network based on 1 3) Document how to connect in readme

jahabeebs commented 11 months ago

@pi0neerpat I made the following changes:

There are a couple reasons I made these changes: 1) Render does not support accessing specific ports within the domain publicly, for example if we try to access URL:8000 the request will never complete. Instead, Render maps the specific port you want to bind to (for example, 8000 if you want to access the explorer) by us specifying a single PORT variable, which is then exposed publicly so that a user can simply access URL to access the GraphQL playground. This means we can only specify one public port per deployment. 2) Because of 1, I expose the JSON-RPC admin server in one web service (see Render for name, mapped to 8020) and the GraphQL playground in another (a web service named od-subgraph-image, mapped to 8000). Of course the ideal scenario would be that we can pass in some kind of authorization header whenever we deploy a new subgraph but this doesn't seem possible out of the box currently, see issue: https://github.com/graphprotocol/graph-tooling/issues/880. So for now we can keep the RPC URL internal use. 3) Our IPFS node has to be a web service because otherwise if we try to deploy our subgraph to it by specifying the URL then it will fail. Authorizing on a per-request basis is not supported and related to this issue (https://github.com/graphprotocol/graph-tooling/issues/880). Just like the RPC repo we would just have to keep this endpoint for internal use.

If it's not enough to have endpoints that we use internally and we want to find a way to be able to pass in authorization whenever we access our IPFS or RPC web services via the CLI then we would need to find another strategy beyond what render provides, maybe standing up some service that can read an access token header that we pass in via a cli and then it either rejects or forwards the request?

jahabeebs commented 11 months ago

@pi0neerpat I managed to configure nginx to properly route via protected and unprotected routes. We now have a username and password scheme that we can use (I've added these as env variables in render in the nginx service).

just two things: 1) can we merge #9 and then I can update that readme to include private network instructions? 2) we can't use IPFS with nginx + authorization for now because "Error: Failed to upload file to IPFS: Request cannot be constructed from a URL that includes credentials" which means we can't run our command line scripts for creating and deploying a subgraph unless you can think of a different way we can pass auth given our current nginx.conf (see private file in render)

I will DM you monday with credentials

pi0neerpat commented 11 months ago

Recommend using nginx to clean the url, before forwarding the request to IPFS