[chef] Re: Re: Re: RE: Re: App cookbooks

[Mark Swinson < >]

I'm not a devops , but a developer currently building a web service.

I see infrastructure as code as another consideration to bring

in when developing an app, which allows me to bring DRY principles to the 

area of infrastructure.

I'm starting to use patterns such as using databags to 'spec' what I want my

service to look like, with the intention of once my cookbooks are mature, only

using databags to provision common use services.*

(although I'm not sure how well this will scale).

Obviously, every ones use case is different, but it sounds like it might be possible

to write a general purpose tool to abstract out these patterns in the way cookbooks are used to provision a server. Something I'm thinking about as I haven't seen anything like it.

The service developer checks in a

'manifest file' with their app, saying 'this is what I need to run my app'

So - simplistically, something like a yaml file defining the following:

base:

  -users etc

stack:

  (provision ruby / java .. )

services:

  myservice:

    stack: ...

    repository_url: (git/nexus etc)

which in turn is used to build a databag, which is used by a cookbooks/LWRPs to provision a server.

I thought this could be used as a means to provisioning the developers sandbox environment , as well as used indirectly to create integration and production configurations 

Thoughts?

On 5 January 2014 20:26, Lamont Granquist < " target="_blank"> > wrote:

If you went the whole way and had one cookbook for deploying apps, with databag-driven config for what-app-gets-deployed-where-and-how-its-configured, then you could front end the data bags with a webservice and let entirely chef-naive users control configuring and deploying applications without needing any devops-ey intervention.  With app-per-cookbook you're actually a little more limited in that you need people familiar with chef and git or whatnot to be tightly coupled to the deployment process.

I keep hoping that someone in the Chef community would start using data bags more like a real database and writing web front-ends that sit in front of them for application and user management, but so far I haven't seen that pattern pop up yet...

On 1/3/14 6:26 AM, Dylan Northrup wrote:

Personally, the rule of thumb I have is use a shared cookbook until complexity of applications diverges to the point it "makes sense" to split the cookbook into multiple different ones. It's largely a matter of taste, but I've been bitten too many times by code fixes not being deployed everywhere.  By having multiple apps use the same cookbook, I use change inertia in my favor to stave off the cookbook split until it's absolutely necessary (and, in the process, helping insure fixes made to a cookbook affect as many apps/services/sites as possible).  Works for me, but YMMV.

On Fri, Jan 3, 2014 at 12:31 AM, Kadel-Garcia, Nico < " target="_blank"> > wrote:

One cookbook per app means modularity. Changes in one small, well built application do not impinge on the other applications, and enhancements to the logic or attributes are not so reliant on avoiding conflict with interwoven applications.

---

From: JJ Asghar < " target="_blank"> >
Sent: Thursday, January 02, 2014 6:13 PM
To: " target="_blank">
Subject: [chef] Re: App cookbooks

 

I like the idea of one cookbook per app.

It allows for expandability and scaling opportunity.  

If that makes sense :)

Best Regards,

JJ Asghar

e: " target="_blank"> | c: 512.619.0722 | o: 512.977.5876

From: "Mark H. Nichols" < " target="_blank"> >
Reply-To: < " target="_blank"> >
Date: Thursday, January 2, 2014 at 3:33 PM
To: < " target="_blank"> >
Subject: [chef] App cookbooks

All -

What’s the community consensus on cookbooks to deploy applications. One per app? Or a generalized cookbook that can deploy any app (as long as it follows a set pattern)?

Thanks,

Mark

--

mark nichols | (t|a.n) @zanshin | (w) zanshin.net