Channels
#dotnet
Title
m
millions-journalist-34868
11/20/2021, 11:00 PMHi everyone. I was wondering how you organize you infrastructure code ? Samples I have currenlty seen often are contained in a single file that describe the whole stack. But the samples I have seen are Pulumi samples which are simple, does someone have a big project to share as an example to show how the code is organized.
đź’ˇ 1
w
worried-city-86458
11/21/2021, 1:51 AMp
powerful-football-81694
11/21/2021, 11:25 AM@millions-journalist-34868 We started out with a single file just to get started, but we have since gradually decomposed our Pulumi code in various ways
For example, we have extracted a bunch of reusable resources into class libraries to avoid duplication and repetition
But more importantly, we have made each microservice in our whole environment “own” its own infrastructure code
So we have a top level Pulumi C# project that defines a custom stack (strongly typed)
đź‘Ť 1
And each microservice has its own class library project (which also references the Pulumi libraries) that defines a custom resource for that microservice
Each microservice custom resource encapsulates all the Azure resources required by that microservice, and provides outputs for the things that might be used as inputs to other resources
So it’s all very neatly and hierarchically structured and encapsulated
Each microservice custom resource is used and configured much like any other standard resource, with the same constructor signature pattern of a name and an
ArgsInput<T>Let me know if there’s anything more specific you’d like to know..
m
millions-journalist-34868
11/21/2021, 11:34 AMAnd where do you put shared resources (key vaults or app configuration for instance).m ? They are taken as input for the different microservices that need them ?
I am wondering when ( for what number of resources) do you know that it's time to separate things into multiple files, projects.
p
powerful-football-81694
11/21/2021, 1:25 PMFunny you should mention Key Vault and App Config
Those are exactly what we call our two “global” resources
We manage those outside of Pulumi (basically manually in a separate resource group)
And we query for them by known names, from the Pulumi program, to get a reference to them
So we can use their outputs (like resource ID, vault name, etc.) as inputs to other things
As to your second question, the number of resources has never been a factor for us in the decomposition
For us it’s more about logical ownership
The logical components of our solution should own their own infrastructure, basically
đź‘Ť 1
Whether that’s a single resource or a hundred, doesn’t matter
l
limited-rainbow-51650
11/22/2021, 4:14 PM@millions-journalist-34868 another criterium I use to define what goes together is the lifecycle of the resources. We create component resources bundling all resources which need to be set up together and cleaned up together. We do not care if this goes over a provider boundary. E.g. we have a microservices abstraction spanning 4 providers: Google Cloud (for IAM), Kubernetes (for Deployment & Service), Hashicorp Vault (for secrets), Datadog (for the service monitoring)
I think it is clear we do not use any Helm/Kustomize/YAML stuff. We go full-stack Pulumi.
đź‘Ť 1
m
millions-journalist-34868
11/22/2021, 5:45 PMThanks all for your answers. Unfortunately there are not many open source samples (especially for .NET with Azure provider) that demonstrate these concepts which seem very interesting.
p
powerful-printer-57241
11/25/2021, 11:09 AMThis is how we do it: https://developers.mews.com/declarative-infrastructure-as-code-with-pulumi/