https://pulumi.com logo
Join Slack
Powered by
Anyone have an opinion on doing a resource per fil...
# general
c
Anyone have an opinion on doing a resource per file or grouping resources into a “component” file? For example, if I have a project deployed to kubernetes. We have the 
Deployment
, several `CronJob`s, 
Service
, 
VirtualService
(istio), 
HorizontalPodAutoscaler
, 
PodDisruptionBudget
, a CloudSql database, database users, etc. Would you recommend: * app.ts (contains the resources deployed to kubernetes, AKA, the “application”) * database.ts (contains the resources to create the database and the users * index.ts (requires the other 2 Or would you recommend: * app/deployment.ts * app/virtualService.ts * app/podDisruptionBudget.ts * cronJobs/cronJob1.ts * database/instance.ts * database/user1.ts
g
I usually prefer to manage related resources within a ComponentResource class, and I split up the files by class rather than resource. So closer to option 1 than option 2.
But the real answer is, “whatever works for your team”. 🙂
c
How long are your files typically?
Like I have one right now that is around 1000 lines. And navigating between resources is more of a burden because of that.
g
Rule of thumb, I try to keep them under 300 LoC
But there are always exceptions to that
c
What would you do though in this situation where it needs to be this? Trying to figure out the best architecture. Right now I’m considering mirroring the helm style of one resource per file.
I do kind of wish there was a recommended standard way to handle this all in pulumi. Obviously nothing works for absolutely everyone, but a general recommendation. Lot of the examples are just 
index.ts
which doesn’t seem like a real world scenario.
☝️ 1
g
The main tradeoff to consider is how easy it is to reference any variables you need. Splitting up the files requires more planning on which variables to export. Usually I start with one big index.ts file, and then split out components as it makes sense.
For example, if you have a Deployment + Service that references it, it requires more work to sync up selectors, labels, ports, etc. if they are in separate files.
c
For us I think that part is actually rather easy. We’ve built up, and are continuing to build up a configuration object that is used for every application. A large part of our infrastructure code is the same. We haven’t gone the way of a ComponentResource because right now it’s a bit easier to have the flexibility. We just finished getting to a configuration object from the old flat structure.
Though it is my goal to make more use of ComponentResources in the future so we can achieve better grouping.
I appreciate the input. We’ll have to keep on investigating.
👍 1
s
One of the pros of using ComponentResource is that you get namespacing and hierarchy among your Pulumi resources. Pulumi's resource graph visualization looks prettier, but I'm pushing for this more internally and haven't found other pros of this approach aside from component reuse. Idea?
c
I wish there was an easier way to do the namespacing and heirarchy to be honest.
It shouldn’t need to depend on ComponentResource.
Introduce new options in the 
options
? parameter of every resource:
Copy code
new Resource('name', {}, {
  'namespace': 'namespaceName'
}
Or something like that. The downside to ComponentResource is that it’s more of a hassle to use. Always have to remember to set 
parent: this
, the constructor, etc., etc. Much easier to just work with raw resources.
This could just be a downside to the TypeScript SDK, but that’s generally a reason we don’t make use of it, code reuse aside (as we may or may not even want code reuse in some cases as we like to explicitly see a lot of our resources).
Open in Slack
PreviousNext
Powered by