4

I was wondering what the general consensus is when it comes to one large CHEF recipe vs a lot of smaller ones.

As an example, say you want to deploy a Radius server, would you have seperate recipes for:

  • MySql DB (just the software)
  • MySql DB config (database, table creation, grants, etc.)
  • Radius pkg install
  • Radius configuration files

Or would you have all of that in 1 or 2 large recipes?

My take on in would be to have a lot of small recipes, each one doing a very specific task, but I am not sure what is considered best practise.

Kosie
  • 173
  • 3
  • 1
    Interesting questions. I'm definetely not an expert of *Chef* but I would say better to have small recipes rather than a large one to track down issues. – Alexandre Roux Aug 03 '17 at 11:36

1 Answers1

3

IMO, smaller is better. Small recipes let you split the infra up as it grows. For example, today you might deploy RADIUS and a SQL backend on one server, but down the line it might make sense to consolidate SQL backends. Additionally, testing small units is easier. If the SQL backend lives elsewhere, you don't have to converge the whole thing in kitchen to test a template change or what have you.

But this needs to balance with other concerns; if you follow the smaller is better principle too closely you'll have recipes with single resources and a giant list of includes. Nobody wants to repeat that work, so the DRY principle -- Don't Repeat Yourself -- is the common counterbalance.

jldugger
  • 14,342
  • 20
  • 77
  • 129