Hello, following this <https://docs.dagster.io/dep...
# ask-community
a
Hello, following this https://docs.dagster.io/deployment/guides/kubernetes/deploying-with-helm#configure-your-user-deployment but not sure how to add the environment variables. I have a local .env file which needs to be available there. Anyone else faced this?
Also, how would we consume it in the code? @daniel
d
Hey abhishek - somebody from the team will get to your question later today. Most of the team is active during US business hours on weekdays so we appreciate giving it a day before pinging the thread
1
a
the user code helm chart provides three different ways to pass env vars to your deployment: https://github.com/dagster-io/dagster/blob/master/helm/dagster/charts/dagster-user-deployments/values.yaml#L73-L100
d
Here's a command that will create a kubernetes secret for you from a .env file:
Copy code
kubectl create secret generic yoursecretnamegoeshere --from-env-file=.env
Then you can reference that secret in the helm chart using the envSecrets field in Adam's link
The easiest place to reference it may be in the envSecrets field on your user code deployment: https://docs.dagster.io/deployment/guides/kubernetes/deploying-with-helm#step-61-configure-the-deployment Then it will also be included in any runs for that code as well
a
To use it in the code, I can still use os.getenv()?
d
yeah, it still includes it as an environment variable
🎉 1
a
Thanks. I will try this.
I'm getting this error in the pod where dagster is running - I haven't been able to test if the variables I add using the
kubectl create secret..
command can be accessed via os.getenv() yet as this error came up. There are 2 pods with names like
dagster-dagster-user-deployments-spina..
and one of the pod has a code related error and 2nd pod has this DAGSTER_HOME error. Are they related?
I see this is set in the values.yaml which is a default.
d
Ah is there a DAGSTER_HOME in your .env file? Try taking it out
a
if I change something in the values.yaml, should I just run the below command to refresh the pods?
helm upgrade --install dagster dagster/dagster -f values.yaml
I actually added
--inject-env-vars-from-instance
argument here as shown in the snapshot below but now am trying to remove it. However, my changes in values.yaml aren't propagating.. I keep seeing the pods in status
CrashLoopBackOff
and as soon as I delete them, they restart but I don't think my changes in values.yaml are being taken. For the above issue, I just added a single secret instead of using my .env file and my .env file doesn't have DAGSTER_HOME. The DAGSTER_HOME error is coming in one dagster-dagster-user-deployment- pod and the other has some other code related error, if that helps.
d
Yeah, if you change the values.yaml then a helm upgrade should apply it
You could try helm uninstalling first if you want to be sure
And yeah, taking out inject-env-vars-from-instance should help
a
this is the first time I'm working with k8s and helm. Learning as I go.. what would be the command for uninstall?
d
a
I shouldn't have to delete the pods, right? helm upgrade should just update it, right?
d
That's corect, helm upgrade should be updating the configuration of the pods
❤️ 1
a
okay, removing the dagster release and then adding it again helped. back to the code related error. I saw that we are not able to use Upper Case environment variables names in the values.yaml file, is this correct?
d
I've used upper case environment variables before without issue
what error are you seeing?
a
All good now! 🙂
🎉 1
Thanks so much! I must have asked some really stupid questions but it feels good to successfully deploy this on my own! 🙂
last one (hopefully), as we add more pipelines to it, we just need to keep on adding more deployments under
dagster-user-deployments
? Is that it?
d
that's right, you can have multiple user code deployments. you can also add additional jobs to the same user code deployment though if you want
a
Got it. I was talking in terms of opening this up to other teams, DS/ML/DE.. now different teams can just add their deployments. From CI/CD POV, we would need to run that helm upgrade command to refresh the server each time docker is updated? What are the best practices for CI/CD here?
d
I think that's maybe worth a new post
since this one has gotten quite long
❤️ 1
D 1
a
couldn't agree more, thanks so much Daniel!!
condagster 1