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


Chronological Thread 
  • From: Sölvi Páll Ásgeirsson < >
  • To:
  • Subject: [chef] Re: Re: Re: Re: Re: Re: Re: RE: Re: App cookbooks
  • Date: Thu, 9 Jan 2014 17:05:28 +0000

We do something similar as well for WCF webservices.

The build process delivers a .zip file, containing a certain structure.
The app-delivery cookbook is then super-general and driven by a databag, which defines which services to install and where, some configuration attributes, etc.

hth,
Sölvi


On Thu, Jan 9, 2014 at 1:13 PM, Brian Akins < " target="_blank"> > wrote:
Currently, we are playing with "packing" apps in a common format - .tar.gz - like "slugs" in heroku and using metadata (currently in data bags) to setup environment variables, etc.  The metadata may tell chef to essentially "do a search for this and shove it in this environment variable" - sort of like heroku's add-on ecosystem.  The slugs are just like heroku's - they include the runtime (node, ruby, java).  We had been doing a cookbook per app and that quickly got out of handle - we have hundreds of apps and dozens of developers across multiple business units.

The thought process was that we could deploy any app as long as it was packaged in a slug and had this metadata. We could completely change how we do the actual deployments, but the "contract" with app developers remains the same.  Also at the same time we started following "12 factor" (-ish) for application development as well.

Still very early in the process of trying this out - call it "alpha."  But as one who was on the ops team and now leads a dev team, I can say this is working better than the "old way."




Archive powered by MHonArc 2.6.16.

§