https://pulumi.com logo
Join Slack
Powered by
This message was deleted.
# getting-started
s
This message was deleted.
l
Yes, if the relationship is stack = environment, then the Pulumi stack file is perfect.
e
We do have a couple of issues about how best to handle environment data https://github.com/pulumi/pulumi/issues/8402 and https://github.com/pulumi/pulumi/issues/7048.
f
one possible alternative is stack/environment specific config object in your language of choice
In python I've got a dict of stack name -> stack config objects that I call at the entrypoint
w
yeah relationship in my case is stack = environment. Just straightforward dev, tst, stg, prd etc. I guess I can store config variables in a stack and then get those through the language I use (this is documented)?
e
w
ah yes, just what i saw. ok that makes sense. one last question. I provisioned my pulumi program, specifically to create Auth0 resources. In order for that to happen, I created auth0 config variables (client secret, etc). In my Pulumi program, these exist in the yaml file. Can I remove them from the yaml file? as theyre plaintext.
for the above question, i can put the variables as system environment variables on my machine. the bit im confused about is does any config variable defined in my stack need to be in yaml file too?
m
@witty-vegetable-61961 If you want to use the Pulumi Config API, then yes, they’ll need to be in your Pulumi.stackname.yaml file. If you’d rather access them from your program as environment variables, you should be able to do that through your language’s built-in facilities (e.g., 
process.env.SOME_VAR
in the case of a Node.js program). However, it’s common practice to store secret values as secrets (so in ciphertext) in your Pulumi.stackname.yaml files. You can do this by passing the 
--secret
CLI option as described here: https://www.pulumi.com/docs/intro/concepts/secrets/
It’s considered safe to check these values into source control as well.
w
thats hepful cnunciato, let me re-review. in that case, i will use config variables and chck in cipher text. That will be the most straightforward way, nice and easy!
m
Awesome, sounds good! I generally think so too. 🙂
a
Fun fact - I did a livestream with pulumi/Auth0 a few weeks ago, and it included adding auth0 secrets to the stack config as encrypted values :)

https://youtu.be/0hEmuhyNF4o▾

✨ 3
w
Thanks Matt! @miniature-musician-31262 you said "they’ll need to be in your Pulumi.stackname.yaml file". Presumably this is a manual process for a program already made. How would I still get the encrypted value? (I'll check that vid tonight).
m
It’d be “manual” in that you’d run 
pulumi config set someKey someSecretValue --secret
with the appropriate stack selected, yes, to get the encrypted value into the config. Once that’s there, you can use (eg., in TS)
Copy code
const config = new pulumi.Config();
const mySecret = config.requireSecret("someKey");
.. and then use 
mySecret
in your program in the normal way. Make sense?
And when you read the value into the program with 
requireSecret
, Pulumi will track 
mySecret
as a secret throughout the life of the program. This is all explained in the secrets docs here: https://www.pulumi.com/docs/intro/concepts/secrets/#using-configuration-and-secrets-in-code
w
@miniature-musician-31262 that all makes sense. I should clarify my question - what I was wondering is if the pulumi config command creates the addition in the yaml file as well as the pulumi UI. The former I am not sure about. I ran the config command but i am not seeing any change in pulumi. going to troubleshoot...
m
Yes, there’s a nuance here, you’re right: 
pulumi config set
creates the config entry (and the stack file, if one doesn’t already exist), but does not persist the entry in the backend (i.e., the Pulumi Service) until you run an update with it. This is intentional and allows you to preview configuration changes without affecting any systems that have already been deployed. I’m pretty sure this is mentioned in the docs, but it’s probably easy to miss. Lemme see.
Yeah, I’m not finding it — which is doubly frustrating because I’m pretty sure I wrote it! Will post back here if I do. But that’s basically how it works — you can 
pulumi config set
all day long, but the value won’t be written to your stack’s state in the Service until you run 
pulumi up
.
w
ah gotcha! and just to be sure, pulumi up will also add the addition to the config file? i will get my pulumi program in order and do an up.
l
pulumi config set
writes it to the config file. Are you looking in the correct one? It's always written to the stack file (Pulumi.<dev>.yml) and not the project file (Pulumi.yml).
You should be able to find changes that various tools make to your files by using 
git status
, 
git diff
or similar. This is also handy for finding changes made by your package manager, code editor, etc.
w
sorted it, was in the wrong stack! i have a stack called dev and one called organisationname/dev. The ui only lists the dev stack however. How do I see the other stack in the ui?
I made some amendments to my code, used standard c# constructs like loops etc. In seconds created myself a bunch of apps in Auth0! Really like Pulumi! I will treat this program as a learning curve I think and make a new one with everything I've learnt above. Thanks guys!
🍻 2
l
The organisationname/dev stack is probably in your org account and the dev one is in your personal. There's a dropdown at the top of the page to switch.
w
ah yes i saw that! ok thanks for that tip. ive deleted the program, will recreate and check.
ok so recreatd my program. I get this error: error: could not validate provider configuration: 1 error occurred: * : invalid or unknown key: test when i have created a config variable.
l
Without code, it didn't happen... 😉
w
ha, i ran this command: pulumi config set test XXXXXXXXXXXXXX
and then do a pulumi up.
e
Your code needs to look up the config value with the key "<project-name>:test"
w
yup, just got it sorted. seems to work now.
all good now. thanks guys. this has been very educational, i understand the pulumi workflow quite well and enough to write production ready code. liking it!
👍 3
12 Views
Open in Slack
PreviousNext
Powered by