https://pulumi.com logo
#general
Title
# general
f

fierce-dinner-64337

11/18/2022, 8:05 PM
@here Hello everyone! My team(me basically) has been tasked to deploy Azure infra using Pulumi. I understand that I need to do something like a console app that will list the resources that we need ( APIM, AKS etc etc). On my terminal I can play with some basic commands to try to deploy infra and then destroy. My plan is to keep the pulumi c# code on a different repo KYC.Pulumi My question is around the integration with Azure Devops. I've found several articles that explain how to preview, build and deploy. However, the Pupumi repo will list all infra components that I might not need for a given API. For example, I want to deploy only an App Service with Cosmos or AKS setup with SQL etc etc. My point is that I want to selectively deploy and not deploy all components listed in my pulumi repo. How do I control that? ANy ref?
s

stocky-restaurant-98004

11/18/2022, 8:38 PM
I'm not sure what you mean "list all infra components", Pulumi is declarative, so if you
new
something up, it will create it (or change if necessary). If something is in Pulumi state and it's not longer in your Pulumi program, it will delete it.
If you're referring to `ComponentResource`s, I recommend you hold off on using them until you're very comfortable with the basics.
f

fierce-dinner-64337

11/18/2022, 8:40 PM
I need to get comfortable soon.
Let le rephrase
the pulumi console project will be responsible to provision azure stack (api management, cosmos, sql, aks bla bla)
When we do smtg like pulumi -up it will create whatever we have on that dll, right?
s

stocky-restaurant-98004

11/18/2022, 8:41 PM
Correct - whatever you
new
up, Pulumi will manage its lifecycle.
f

fierce-dinner-64337

11/18/2022, 8:42 PM
what if want to select what we create from that dll?
s

stocky-restaurant-98004

11/18/2022, 8:42 PM
For example?
f

fierce-dinner-64337

11/18/2022, 8:43 PM
Imagine that this pulumi console repo will be referenced by an x number of API's that will have different needs
for instance API A will need App services and SQL but API B will only need AKS and Cosmos, so I don't want to deploy all components that are listed on my pulumi dll's
an example is the terraform modules.
s

stocky-restaurant-98004

11/18/2022, 8:44 PM
Make a separate Pulumi program for each API.
f

fierce-dinner-64337

11/18/2022, 8:45 PM
is that the best way?
s

stocky-restaurant-98004

11/18/2022, 8:45 PM
The analogy of a TF module in Pulumi is a ComponentResource, but I recommend you skip them for now until you are sure you need them.
f

fierce-dinner-64337

11/18/2022, 8:45 PM
this is not a department with 5 engineers
s

stocky-restaurant-98004

11/18/2022, 8:46 PM
You can refactor to ComponentResources once you have something up and running.
f

fierce-dinner-64337

11/18/2022, 8:47 PM
there will be various teams that they will want to reference pulumi dll's but nobody wants to maintain 100 pulumi projects!
s

stocky-restaurant-98004

11/18/2022, 8:47 PM
What's the first deliverable that you need to deliver?
f

fierce-dinner-64337

11/18/2022, 8:48 PM
I have 2 weeks to set up infra (infra includes resource groups, AKS, KeyVault, APIM, Redis). They want to do a Poc and then make it official but the mandate is pulumi. They are 100% sure. I
(they use Azure DevOps)
I don't mind the tool, I think its great, its the deadline that make me freak out
s

stocky-restaurant-98004

11/18/2022, 8:50 PM
If you want to make a shared infra component library, that can sometimes be helpful, but at the same time, making an abstraction before you're ready can cause more pain the long run. Especially with infrastructure where breaking changes can be non-starters (like you can't take down the prod DB or have a virtual network get re-created).
How many app teams do you need to create infra for?
f

fierce-dinner-64337

11/18/2022, 8:51 PM
Our customers are those teams. We have 5.
s

stocky-restaurant-98004

11/18/2022, 8:52 PM
5 teams? 5 separate Pulumi programs should be manageable.
Refactor to ComponentResource if necessary, but copy/paste is not always bad. You have to really write a few programs to make sure that a ComponentResource is useful - that it's actually abstracting something.
f

fierce-dinner-64337

11/18/2022, 8:53 PM
ok so 5 executables for now and then refactor ( if I need to)
s

stocky-restaurant-98004

11/18/2022, 8:53 PM
Unless there are shared components, like an AKS cluster or something.
If there's shared stuff, like everything is deployed into the same virtual network, then put that in its own stack and add whatever stack outputs you need so the app teams can deploy into those shared resources.
But the key thing IMO is to get one team up and running end to end before you do any refactoring. Start with that.
f

fierce-dinner-64337

11/18/2022, 8:56 PM
Yes I understand! Thanks Josh!
s

stocky-restaurant-98004

11/18/2022, 8:56 PM
No problem and good luck!
f

fierce-dinner-64337

11/18/2022, 8:56 PM
Pulumi weekend!
s

stocky-restaurant-98004

11/18/2022, 8:56 PM
FYI, you can also define Azure DevOps resources with Pulumi. There's an ADO provider.
f

fierce-dinner-64337

11/18/2022, 8:57 PM
s

stocky-restaurant-98004

11/18/2022, 8:58 PM
Defining pipelines in code has been very helpful for me in the past. If all the pipelines are the same and just differ by the source repo, THAT would be a good place to try a ComponentResource. When you're ready to try them, keep them in the same repo as they are used. Publishing them to NuGet can be helpful, but it comes with considerable maintenance overhead.
But first things first: I recommend you try to get one team's infra working end-to-end from your machine, then maybe move on to creating a pipeline.
f

fierce-dinner-64337

11/18/2022, 9:00 PM
yes! Thanks for taking time to answer my questions!
s

stocky-restaurant-98004

11/18/2022, 9:01 PM
f

fierce-dinner-64337

11/18/2022, 9:01 PM
👍
2 Views