Good afternoon everyone! I'm new to Pulumi, and I...
# generalb
best-lifeguard-91445
05/13/2020, 8:22 PMGood afternoon everyone! I'm new to Pulumi, and I'm looking for baseline / best practices for organizing stacks within a pulumi project. For example: should I have a "VPC" construct in a separate file, and export the values to be made available elsewhere? I guess I'm looking for a well-architected / modular starter project. (Typescript preferred) or blog/tutorial on organization and modularity.
best-lifeguard-91445
05/13/2020, 8:26 PMI came across this:
https://www.pulumi.com/docs/intro/concepts/organizing-stacks-projects/
https://www.pulumi.com/docs/guides/crosswalk/kubernetes/
However, I was wondering how you guys were handling this in the 'real world' so to speak.
f
future-barista-68134
05/13/2020, 9:10 PMThe highest-level quick answer is to start with a single project and only start to consider breaking up the project when it reaches a certain level of complexity. That complexity being the time when it becomes desirable to separate the deployment lifecycle for a subset of the infrastructure.
For stacks, the recommendation is to have a stack per independent deployment of the same infrastructure. The most common layout being a stack per environment. Prod, staging, dev, etc. That way you can maintain a single Pulumi program and simple pass in configs to describe the difference in the environments.
I agree it would be great to have the “best-practice” project and guide and have added an item to our list of blogs/guides 🙂
I’m sure there are others who have insight here as well.
👍 1
b
best-lifeguard-91445
05/13/2020, 9:21 PMThanks for the feedback!
l
little-cartoon-10569
05/13/2020, 9:48 PMIt can also be helpful to have multiple stacks per environment in cases where some infra is updated more frequently than others. For example, you might have a devVpc stack that sorts your VPC, subnets, NACLs etc and never changes, and a devWebApp stack that you can change as often as you need without risking the static network resources.
little-cartoon-10569
05/13/2020, 9:50 PMAlso "ownership" can influence stack design in orgs that have multiple responsible groups. A stack per team or department might work. devKubes, devDbs, devCdn....
👍 1
a
ancient-megabyte-79588
05/14/2020, 4:50 AMJust to add a small anecdote, I started doing my kubernetes development in a single monolithic stack. I soon discovered that the frequency in which I stand-up/teardown the actual k8s cluster is drastically less frequent than the frequency of of making changes to services in the cluster. So I broke the two apart into separate stacks. I'm writing a large series of blog posts that uses that technique now.
ancient-megabyte-79588
05/14/2020, 4:50 AMAlso, as @little-cartoon-10569suggested, ownership (and by association deployment frequency) can certainly play a role in determining which approach.
ancient-megabyte-79588
05/14/2020, 4:52 AMHonestly, I understand why the tutorials are all monolithic stack examples, but it is so easy to do the microstacks with the platform, it should almost be the default as I expect that people doing anything more complicated than basic deployments of single apps are going to run up against the desire (or need) to break the stacks apart.
ancient-megabyte-79588
05/14/2020, 4:54 AMI think people need to avoid swinging too far in the other direction! You won't want a stack per "thing" to deploy. That would be crazy. So the guidance of start with one is sound, but there should be a next paragraph that says "When you encounter <condition>, consider doing a multi-stack approach by doing <insert guidance here>".
b
best-lifeguard-91445
05/14/2020, 2:46 PMDave - I'd love to read your blog/tutorial when you have it available.
👍 1
a
ancient-megabyte-79588
05/14/2020, 8:29 PMI'll certainly post it here.
ancient-megabyte-79588
05/25/2020, 5:20 PM@best-lifeguard-91445 Here it is! https://westerndevs.com/kubernetes/kubernetes-my-journey/
ancient-megabyte-79588
05/25/2020, 5:21 PMThe pulumi parts start at the 8th post in the list