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

cool-egg-852

03/06/2020, 4:15 PM
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

gorgeous-egg-16927

03/06/2020, 4:19 PM
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

cool-egg-852

03/06/2020, 4:21 PM
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

gorgeous-egg-16927

03/06/2020, 4:21 PM
Rule of thumb, I try to keep them under 300 LoC
But there are always exceptions to that
c

cool-egg-852

03/06/2020, 4:22 PM
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

gorgeous-egg-16927

03/06/2020, 4:24 PM
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

cool-egg-852

03/06/2020, 4:27 PM
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

swift-painter-31084

03/06/2020, 4:48 PM
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

cool-egg-852

03/06/2020, 4:52 PM
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).