Hey All, I've started using Pulumi to spin up some...
# aws
s
Hey All, I've started using Pulumi to spin up some resources on AWS. Basically what I want is: 1. Provision a bastion host. 2. Provision an RDS 3. Provision a K8s cluster. 4. Provision some other resources (DNS, S3 buckets, etc). 5. Deploy the app. 6. Be able to remove some of the resources (to reduce costs when not needed) while others should be always available. With that in mind, I wonder what's the best way to design the solution: 1. What should be the project (account, env, etc)? 2. What should be a stack? Dev, staging, production? The bastion host is one stack and the K8s cluster is another? 3. How to reference stacks? If anyone has a reference to how a "real-life" app should be provisioned and deployed with Pulumi, it would be a great help!
Hey Guys, Any pointers regarding this one, would be highly appreciated šŸ™
a
This is how I've approached this: ā€¢
project
is a "self-contained" workload that includes most dependencies for it to run ā€¢
stack
is the environment (dev, prod, test etc.) I then layer the projects (workloads): ā€¢
landing_zone
-> Configures identities, permissions and resources which are shared across workloads ā€¢
hubspoke
-> Provisions networking for an environment. This is where I usually have VPN or in your case a bastion host ā€¢
app_zone
-> Provisions an application runtime environment ā€“ container service, container registry, secret store, centralized logging, data stores shared by multiple applications (SQL/blob etc...) ā€¢
<app_workload> (multiple)
-> A single application workload, usually containerized All of these projects have dev/prod/test stacks and they will usually have dependencies in the form of stack references to upstream projects... `<app_workload>`s will require a reference to which
app_zone
it should run in. An app_zone will need a private network/subnet which it will reference from
hubspoke
and so on...
Projects/workloads will export stack outputs for the things that are to be consumed by downstream projects. See docs for how to do that: https://www.pulumi.com/learn/building-with-pulumi/stack-references/ https://www.pulumi.com/docs/using-pulumi/stack-outputs-and-references/
Also recommend reading this post by @billowy-army-68599 https://leebriggs.co.uk/blog/2023/08/17/structuring-iac Really solid advise on how to structure projects based on their 1. Rate of change ā€“ f.x. general account configurations or networking will probably change less often than an application workload. 2. Resource lifecycle ā€” think self-contained workloads containing most of the dependencies for it to run
Pulumi docs also have a pretty good chapter on organizing projects: https://www.pulumi.com/docs/using-pulumi/organizing-projects-stacks/