Good evening, what's the Pulumi best practice with...
# general
a
Good evening, what's the Pulumi best practice with manging a lot of configuration? For example, we have 10+ Kubernetes clusters with different node types, size, disk configuration but common Pulumi code between them i.e for loop through the 10 different Kubernetes config. Looking at the Pulumi docs it says you should set it via the CLI using config set which adds it to the stack. I'd prefer to do it via code and store it in a Git Repo but I seem to be going down the root of using YAML to feed into Python Pulumi code which seems to be going against the Pulumi grain. Another example is a large series of NSG rules across different Azure subscriptions. What's the best way to handle common Pulumi code with large variation via configuration? Cheers!
f
I would build a component resource 🙂
you can then create one or many stacks for each… if you go the many route, it would probably make sense to create pulumi config values for each distinctive difference between clusters..
l
We have an integration testing framework written in go that allows doing a deployment programmatically including the specification of config: https://github.com/pulumi/examples/blob/master/testing-integration/examples_test.go#L29-L31
a
@future-barista-68134 Thank you for getting back to me. I'm not sure how that helps in this situation. I still need to store some sort of list of configs. Where do I store all these different config options? A more straight forward example is I have 20 unique and 10 common NSG rules for each envrionemnt dev, stage, qa etc... whats the best practice to store these values?
f
though it’s not clear in the docs, you can manually setup config in the
Pulumi.stackname.yaml
file.. which generally should be checked in to source code.. in your case it looks like structured config setup might be useful.. see: https://www.pulumi.com/docs/intro/concepts/config/#structured-configuration
a
If I delete a stack won't that also be deleted? We did have that orignally but removed it
Thank you for providing support on this. its much appreciated
f
Correct.. and you can setup the config variables to be either required or optional in the code so that you know you have to set them. See: https://www.pulumi.com/docs/reference/pkg/nodejs/pulumi/pulumi/#Config-get and https://www.pulumi.com/docs/reference/pkg/nodejs/pulumi/pulumi/#Config-require.
a
Are there any big examples out there for the use of this? Concerned with the deletion part for each stack as we have large configurations.
f
If it’s tracked in source, it shouldn’t be hard to go back to and also you could also create a “default” config file that you could copy when creating a new stack to simplify the process
a
That's a very valid point. You can type check as well ?
f
Also I’d recommend a stack per k8s cluster to help reduce the huge config if possible.. for type checking that’s a good question.. there are type checking config calls you could make like https://www.pulumi.com/docs/reference/pkg/nodejs/pulumi/pulumi/#Config-requireNumber and https://www.pulumi.com/docs/reference/pkg/nodejs/pulumi/pulumi/#Config-requireBoolean