https://pulumi.com logo
Join Slack
Powered by
This message was deleted.
# general
s
This message was deleted.
s
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
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
Correct - whatever you 
new
up, Pulumi will manage its lifecycle.
f
what if want to select what we create from that dll?
s
For example?
f
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
Make a separate Pulumi program for each API.
f
is that the best way?
s
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
this is not a department with 5 engineers
s
You can refactor to ComponentResources once you have something up and running.
f
there will be various teams that they will want to reference pulumi dll's but nobody wants to maintain 100 pulumi projects!
s
What's the first deliverable that you need to deliver?
f
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
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
Our customers are those teams. We have 5.
s
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
ok so 5 executables for now and then refactor ( if I need to)
s
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
Yes I understand! Thanks Josh!
s
No problem and good luck!
f
Pulumi weekend!
s
FYI, you can also define Azure DevOps resources with Pulumi. There's an ADO provider.
f
s
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
yes! Thanks for taking time to answer my questions!
s
f
👍
2 Views
Open in Slack
PreviousNext
Powered by