Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cache should interpolate env at runtime #4096

Closed
4 tasks
Warxcell opened this issue Jun 28, 2022 · 8 comments
Closed
4 tasks

Cache should interpolate env at runtime #4096

Warxcell opened this issue Jun 28, 2022 · 8 comments
Labels
waiting-for-answer Waiting for answer from author

Comments

@Warxcell
Copy link
Contributor

Warxcell commented Jun 28, 2022

Issue workflow progress

Progress of the issue based on the Contributor Workflow

Make sure to fork this template and run yarn generate in the terminal.

Please make sure Mesh package versions under package.json matches yours.

  • 2. A failing test has been provided
  • 3. A local solution has been provided
  • 4. A pull request is pending review

Describe the bug

env at cache is interpolated at build time, which makes impossible to run same docker image in different environments.

To Reproduce
Steps to reproduce the behavior:

cache:
  redis:
    host: '{env.REDIS_HOST}'
    port: '{env.REDIS_PORT}'

and run mesh build

Expected behavior

{env...} to become process.env.... on build.

Environment:

  • OS: all
  • @graphql-mesh/...: all
  • NodeJS: all

Additional context

image

@ardatan
Copy link
Owner

ardatan commented Jun 29, 2022

The image you shared is created at build time and I see it is not interpolated during build time so Mesh will interpolate it during actual runtime.

@Warxcell
Copy link
Contributor Author

Hm, maybe I did something wrong then, yesterday I was very tired. Will try again later today.

@Warxcell
Copy link
Contributor Author

Warxcell commented Jun 29, 2022

Something weird is happening. When using

cache:
  redis:
    host: '{env.REDIS_HOST}'
    port: '{env.REDIS_PORT}'

running it locally (in and out container) - it works. When its deployed to production Kubernetes - it doesn't work anymore.

│ [ioredis] Unhandled error event: Error: connect ETIMEDOUT                                                                                                                                                                                                                                                                         

After changing to

cache:
  redis:
    url: 'redis://{env.REDIS_HOST}:{env.REDIS_PORT}'

Its still working locally (no container) - but image cannot be build.

#17 [builder 8/8] RUN yarn build && yarn tsc
#17 sha256:767d11b51edd14822fce5f20bc170185e6fdfcbc7ed013fa4510cc487a0a0f29
#17 0.302 yarn run v1.22.19
#17 0.313 warning package.json: License should be a valid SPDX license expression
#17 0.322 $ mesh build
#17 1.225 💡 🕸️  Mesh Cleaning existing artifacts
#17 1.233 💡 🕸️  Mesh Reading the configuration
#17 1.500 💥 🕸️  Mesh TypeError [ERR_INVALID_URL]: Invalid URL
#17 1.500     at new NodeError (node:internal/errors:388:5)
#17 1.500     at UR...

@ardatan
Copy link
Owner

ardatan commented Jul 20, 2022

Make sure you have environment variables set in your Kubernetes setup.

@ardatan ardatan added the waiting-for-answer Waiting for answer from author label Jul 20, 2022
@Urigo Urigo mentioned this issue Aug 11, 2022
22 tasks
@ironest
Copy link

ironest commented Jan 30, 2023

I am also facing the same problem (even thought in a slightly different flavour than @Warxcell)
In short:

  1. I provide my .meshrc config as:
cache:
  redis:
    host: "${REDIS_HOST}"
    port: "${REDIS_PORT}"
    password: "${REDIS_PWD}"
  1. I then generate my mesh through graphql-mesh build

  2. When I inspect the code generated (inside .mesh/index.ts), I unexpectedly find plain and simple all my values (below an example of what gets generated)

const cache = new (MeshCache as any)({
    ...({ host: 'redistore.tardis.svc.cluster.local', port: '6379', password: 'defaultRedisPassword' } as any)

It does seem like env variables are not computed at runtime.
Is there a way we can push even further our env variables into the generated mesh as actual env variables?

Ideally my team will keep the mesh under source control and... having secrets over there is not really a best practice.

@ardatan
Copy link
Owner

ardatan commented Jan 30, 2023

You should use {env.REDIS_HOST} instead because ${} is handled by YAML processor while {} is handled by Mesh itself.
https://the-guild.dev/graphql/mesh/docs/guides/dynamic-vars

Closing this issue for now. Feel free to create a new one with a reproduction if you have any further issues. Thanks!

@ardatan ardatan closed this as completed Jan 30, 2023
@ironest
Copy link

ironest commented Jan 31, 2023

Thank you @ardatan it works now.

@quangchuc
Copy link

Hello, I'm facing maybe the same problem when deploying the GraphQL Mesh gateway to a cloud provider through Docker and Kubernetes.
In our .meshrc.ts, we have an env variable like this:
const plugins: YamlConfig.Config['plugins'] = [ { operationFieldPermissions: { permissions: [{ if: 'context.headers.auth_key == env.AUTH_KEY', allow: ['*'] }] } }, ];

For other env variables in the app, we do use {env.VARIABLE} syntax, for example:
endpoint: '{env.API_URL}'

We have an .env file inside Docker image that contain those variables. Locally, I run the docker image locally and it works. However, when deploying with Kubernetes, it seems like those env variables are not computed at run time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
waiting-for-answer Waiting for answer from author
Projects
None yet
Development

No branches or pull requests

4 participants