This message was deleted.
# getting-started
s
This message was deleted.
s
For your first bullet point, absolutely yes. The structure of your Pulumi k8s resources will be identical to the yaml files, so the knowledge you gain is directly transferrable to the yaml approach.
1
c
FYI this was proven to be very true. Intellisense and adding resources made this easy to translate from yaml to add new things. Only thing I'm super unclear on that i probably need to invest in learning is components concepts so I can begin making building blocks like helm would. Right now it's a little too messy and intertwined for my liking, not much better "in practice" than a helm chart for testing and such. Lots to learn!
p 1
s
There's Pulumi abstractions that are made for that like Components, but honestly I haven't used those (yet). I've found that simply wrapping related components in a function has been a very simple way to group resources. For example, you might have a function that accepts an object with key/value pairs as the equivalent of helm's
value.yaml
overrides, and the body of the function can just construct the deployment, configmaps, service, etc. and
return
them so they're accessible to the rest of the program.
1
c
I just noticed this and found out I did the same 🙂 Just broke them up (a bit overkill probably) each into an internal/name package to ensure I wasn't pulling anything between packages and then main has all the required pieces.