App cookbooks

Chef Infra (archive)
1

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

2

I like the idea of one cookbook per app.

It allows for expandability and scaling opportunity.

If that makes sense :slight_smile:

Best Regards,
JJ Asghar
e: jj.asghar@peopleadmin.com | c: 512.619.0722 | o: 512.977.5876

From: “Mark H. Nichols” <chef@zanshin.netmailto:chef@zanshin.net>
Reply-To: <chef@lists.opscode.commailto:chef@lists.opscode.com>
Date: Thursday, January 2, 2014 at 3:33 PM
To: <chef@lists.opscode.commailto:chef@lists.opscode.com>
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.nethttp://zanshin.net/

3

In our case, I have to disagree, since most of our devs don't want to
deal with devops. We have a lot of apps, but not very much server
complexity for any one app. We have a git hook based deploy process, so
if a single cookbook can provision servers based on a data structure in
data bags, I think I can limit the ops side to those who deal with
server provisioning, and have the server set up ready to accept a git
push to deploy the app. Having all the servers provisioned with chef,
though, will help standardize all the environments. Eventually, the
cookbooks will need very little maintenance, and I won't have to create
a new cookbook every time we start a new app - just add some data values
and bootstrap the new servers.

Later I may add a rails app to manage the data bag data, allowing for
quick provisioning of new app servers.

On 1/2/14 5:13 PM, JJ Asghar wrote:

I like the idea of one cookbook per app.

It allows for expandability and scaling opportunity.

If that makes sense :slight_smile:

Best Regards,
JJ Asghar
e: jj.asghar@peopleadmin.com | c: 512.619.0722 | o: 512.977.5876

From: "Mark H. Nichols" <chef@zanshin.net mailto:chef@zanshin.net>
Reply-To: <chef@lists.opscode.com mailto:chef@lists.opscode.com>
Date: Thursday, January 2, 2014 at 3:33 PM
To: <chef@lists.opscode.com mailto:chef@lists.opscode.com>
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 http://zanshin.net/

--
David Morton
dmorton@wested.org

4

I just finished refactoring our eight or so application cookbooks into a single one with LWRP’s for different application layers and I’m pretty happy with it so far. All of our applications at the moment are Rails with Sidekiq for workers and Unicorn for the web servers running behind nginx. The way I ended up breaking things down was an LWRP for each one of those pieces, and recipes inside the cookbook for each application (so app1_web uses the app_web resource, app1_app uses the app_unicorn resource, etc.) We use runit for process supervision so each application has a data bag for it’s environment that gets put into the shared/env directory for that application. Standardizing on configuration for things like unicorn, nginx, sidekiq, etc. has made my life a whole lot easier now, and if there’s things I might need to tweak per application like unicorn worker counts or which ssl cert to use for an application’s web resource, I’ve just added those as attributes on the LWRPs.

Tony

--
Tony Burns
Operations Engineer / Software Developer
Quad Learning, Inc.
1150 17th St Ste 310, Washington, DC 20036
c. 608.799.2000 p. 202.525.1078 f. 202.652.1075

On Jan 2, 2014, at 18:25, David Morton dmorton@wested.org wrote:

In our case, I have to disagree, since most of our devs don't want to deal with devops. We have a lot of apps, but not very much server complexity for any one app. We have a git hook based deploy process, so if a single cookbook can provision servers based on a data structure in data bags, I think I can limit the ops side to those who deal with server provisioning, and have the server set up ready to accept a git push to deploy the app. Having all the servers provisioned with chef, though, will help standardize all the environments. Eventually, the cookbooks will need very little maintenance, and I won't have to create a new cookbook every time we start a new app - just add some data values and bootstrap the new servers.

Later I may add a rails app to manage the data bag data, allowing for quick provisioning of new app servers.

On 1/2/14 5:13 PM, JJ Asghar wrote:

I like the idea of one cookbook per app.

It allows for expandability and scaling opportunity.

If that makes sense :slight_smile:

Best Regards,
JJ Asghar
e: jj.asghar@peopleadmin.com | c: 512.619.0722 | o: 512.977.5876

From: "Mark H. Nichols" chef@zanshin.net
Reply-To: chef@lists.opscode.com
Date: Thursday, January 2, 2014 at 3:33 PM
To: chef@lists.opscode.com
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

--
David Morton
dmorton@wested.org

5

+1

i dont think theres any universal rule. Chef cookbook reusability is same
as code reusability in any other software projects. if you have commonality
across application cookbooks you should definitely consider moving them
into a single lwrp/hwrp and model the variable parts as resource
attributes. this will also avoid node/role attribute cluttering.

we host jvm, ruby etc applications. jvm apps reuse a common cookbook,
while the ruby apps reuse a different parent cookbook. initially we didn't
had multiple apps from same stack, and dedicated cookbooks for inidividual
apps. now that our services/apps have grown and we see clear commonality
within the jvm, ruby services we have refactored the cookbook to be more
dry (and also why_run support etc.. which we wanted to do anyway). Also, we
try not to go beyond 3 degree of inheritance (base + app_common + app_foo),
we still have terminal cookbooks (app specific, app_foo) , but they are
very thin (only consume the lwrp) and dictates only how the resources are
assembled (attribute directed branching etc)

again, it really depends your apps (number, commonality, code quality) etc.

cheers
ranjib

On Thu, Jan 2, 2014 at 4:01 PM, Tony Burns tabolario@gmail.com wrote:

I just finished refactoring our eight or so application cookbooks into a
single one with LWRP’s for different application layers and I’m pretty
happy with it so far. All of our applications at the moment are Rails with
Sidekiq for workers and Unicorn for the web servers running behind nginx.
The way I ended up breaking things down was an LWRP for each one of those
pieces, and recipes inside the cookbook for each application (so app1_web
uses the app_web resource, app1_app uses the app_unicorn resource, etc.) We
use runit for process supervision so each application has a data bag for
it’s environment that gets put into the shared/env directory for that
application. Standardizing on configuration for things like unicorn, nginx,
sidekiq, etc. has made my life a whole lot easier now, and if there’s
things I might need to tweak per application like unicorn worker counts or
which ssl cert to use for an application’s web resource, I’ve just added
those as attributes on the LWRPs.

Tony

--
Tony Burns
Operations Engineer / Software Developer
Quad Learning, Inc.
1150 17th St Ste 310, Washington, DC 20036
c. 608.799.2000 p. 202.525.1078 f. 202.652.1075

On Jan 2, 2014, at 18:25, David Morton dmorton@wested.org wrote:

In our case, I have to disagree, since most of our devs don't want to
deal with devops. We have a lot of apps, but not very much server
complexity for any one app. We have a git hook based deploy process, so if
a single cookbook can provision servers based on a data structure in data
bags, I think I can limit the ops side to those who deal with server
provisioning, and have the server set up ready to accept a git push to
deploy the app. Having all the servers provisioned with chef, though,
will help standardize all the environments. Eventually, the cookbooks will
need very little maintenance, and I won't have to create a new cookbook
every time we start a new app - just add some data values and bootstrap the
new servers.

Later I may add a rails app to manage the data bag data, allowing for
quick provisioning of new app servers.

On 1/2/14 5:13 PM, JJ Asghar wrote:

I like the idea of one cookbook per app.

It allows for expandability and scaling opportunity.

If that makes sense :slight_smile:

Best Regards,
JJ Asghar
e: jj.asghar@peopleadmin.com | c: 512.619.0722 | o: 512.977.5876

From: "Mark H. Nichols" chef@zanshin.net
Reply-To: chef@lists.opscode.com
Date: Thursday, January 2, 2014 at 3:33 PM
To: chef@lists.opscode.com
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

--
David Mortondmorton@wested.org

6

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 jj.asghar@peopleadmin.com
Sent: Thursday, January 02, 2014 6:13 PM
To: chef@lists.opscode.com
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 :slight_smile:

Best Regards,
JJ Asghar
e: jj.asghar@peopleadmin.com | c: 512.619.0722 | o: 512.977.5876

From: “Mark H. Nichols” <chef@zanshin.netmailto:chef@zanshin.net>
Reply-To: <chef@lists.opscode.commailto:chef@lists.opscode.com>
Date: Thursday, January 2, 2014 at 3:33 PM
To: <chef@lists.opscode.commailto:chef@lists.opscode.com>
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.nethttp://zanshin.net/

7

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 <
NKadelGarcia-consultant@scholastic.com> 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 jj.asghar@peopleadmin.com
Sent: Thursday, January 02, 2014 6:13 PM
To: chef@lists.opscode.com
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 :slight_smile:

Best Regards,
JJ Asghar
e: jj.asghar@peopleadmin.com | c: 512.619.0722 | o: 512.977.5876

From: "Mark H. Nichols" chef@zanshin.net
Reply-To: chef@lists.opscode.com
Date: Thursday, January 2, 2014 at 3:33 PM
To: chef@lists.opscode.com
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

8

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
<NKadelGarcia-consultant@scholastic.com
mailto:NKadelGarcia-consultant@scholastic.com> 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 <jj.asghar@peopleadmin.com
<mailto:jj.asghar@peopleadmin.com>>
*Sent:* Thursday, January 02, 2014 6:13 PM
*To:* chef@lists.opscode.com <mailto:chef@lists.opscode.com>
*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: jj.asghar@peopleadmin.com <mailto:jj.asghar@peopleadmin.com> |
c: 512.619.0722 <tel:512.619.0722> | o: 512.977.5876
<tel:512.977.5876>


From: "Mark H. Nichols" <chef@zanshin.net <mailto:chef@zanshin.net>>
Reply-To: <chef@lists.opscode.com <mailto:chef@lists.opscode.com>>
Date: Thursday, January 2, 2014 at 3:33 PM
To: <chef@lists.opscode.com <mailto:chef@lists.opscode.com>>
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
<http://zanshin.net/>
9

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 lamont@opscode.com 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 <
NKadelGarcia-consultant@scholastic.com> 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 jj.asghar@peopleadmin.com
Sent: Thursday, January 02, 2014 6:13 PM
To: chef@lists.opscode.com
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 :slight_smile:

Best Regards,
JJ Asghar
e: jj.asghar@peopleadmin.com | c: 512.619.0722 | o: 512.977.5876

From: "Mark H. Nichols" chef@zanshin.net
Reply-To: chef@lists.opscode.com
Date: Thursday, January 2, 2014 at 3:33 PM
To: chef@lists.opscode.com
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

10

On Sun, Jan 5, 2014 at 8:26 PM, Lamont Granquist lamont@opscode.com wrote:

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...

At a previous employer, we did just that - we built a user management
system with a data bag as the system of record. Each user's details were
in a data bag item, and Chef was responsible for managing user accounts in
as many systems and applications as we could reasonably teach it to do so.
For the few where this wasn't practical, we had an LDAP service (built on
ldapjs) which authenticated against the data bag items. On the front end,
a Rails webapp allowed managers to create accounts for new users, and
individual users to update their passwords.

It worked well, but didn't readily lend itself to an open source release.
I wonder whether other folks have built similar things and found
themselves in the same boat.

On the other hand, we discarded a similar approach for application
management in favour of a web service backed by a relational database. The
nature of data bags (no relationships, no partial updates, last writer wins
& no CAS, etc) rendered them unattractive for modelling the complexity we
had to manage in that area.

Another factor in that environment was our use of the open-source Chef
server - without data-bag level ACLs, any web-app storing data in a data
bag needs a full admin client. We could live with this for the user
management app, but it was a showstopper for other potential applications.

Zac

11

On 1/6/14 7:04 AM, Zac Stevens wrote:

On Sun, Jan 5, 2014 at 8:26 PM, Lamont Granquist <lamont@opscode.com
mailto:lamont@opscode.com> wrote:

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...

At a previous employer, we did just that - we built a user management
system with a data bag as the system of record. Each user's details
were in a data bag item, and Chef was responsible for managing user
accounts in as many systems and applications as we could reasonably
teach it to do so. For the few where this wasn't practical, we had an
LDAP service (built on ldapjs) which authenticated against the data
bag items. On the front end, a Rails webapp allowed managers to
create accounts for new users, and individual users to update their
passwords.

It worked well, but didn't readily lend itself to an open source
release. I wonder whether other folks have built similar things and
found themselves in the same boat.

On the other hand, we discarded a similar approach for application
management in favour of a web service backed by a relational database.
The nature of data bags (no relationships, no partial updates, last
writer wins & no CAS, etc) rendered them unattractive for modelling
the complexity we had to manage in that area.

Another factor in that environment was our use of the open-source Chef
server - without data-bag level ACLs, any web-app storing data in a
data bag needs a full admin client. We could live with this for the
user management app, but it was a showstopper for other potential
applications.

Zac

You make an interesting point that if you go down that road you kind of
wind up eventually with enough complexity that you want a relational
database. The large account management system that I used previously
that was based around LDAP, CFEngine and a bunch of Perl hit limitations
where we really wanted a relational database. Of course Chef servers do
have a relational database now, but we don't expose any of that
functionality....

12

It worked well, but didn't readily lend itself to an open source release.
I wonder whether other folks have built similar things and found
themselves in the same boat.

We did something similar at EA in terms of building a front-end:
http://lanyrd.com/2013/ldndevops-january/scbzkw/.

S.

On 6 January 2014 14:04, Zac Stevens zts@cryptocracy.com wrote:

On Sun, Jan 5, 2014 at 8:26 PM, Lamont Granquist lamont@opscode.comwrote:

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...

At a previous employer, we did just that - we built a user management
system with a data bag as the system of record. Each user's details were
in a data bag item, and Chef was responsible for managing user accounts in
as many systems and applications as we could reasonably teach it to do so.
For the few where this wasn't practical, we had an LDAP service (built on
ldapjs) which authenticated against the data bag items. On the front end,
a Rails webapp allowed managers to create accounts for new users, and
individual users to update their passwords.

It worked well, but didn't readily lend itself to an open source release.
I wonder whether other folks have built similar things and found
themselves in the same boat.

On the other hand, we discarded a similar approach for application
management in favour of a web service backed by a relational database. The
nature of data bags (no relationships, no partial updates, last writer wins
& no CAS, etc) rendered them unattractive for modelling the complexity we
had to manage in that area.

Another factor in that environment was our use of the open-source Chef
server - without data-bag level ACLs, any web-app storing data in a data
bag needs a full admin client. We could live with this for the user
management app, but it was a showstopper for other potential applications.

Zac

13

Check out http://rove.io

Seems like a good starting point for a web fronted for configuring nodes
with chef.

Can not speak of personal experience yet, but it looks really promising...

Cheers, Torben
On Jan 6, 2014 4:57 PM, "Sam Pointer" sam.pointer@opsunit.com wrote:

It worked well, but didn't readily lend itself to an open source release.

I wonder whether other folks have built similar things and found
themselves in the same boat.

We did something similar at EA in terms of building a front-end:
http://lanyrd.com/2013/ldndevops-january/scbzkw/.

S.

On 6 January 2014 14:04, Zac Stevens zts@cryptocracy.com wrote:

On Sun, Jan 5, 2014 at 8:26 PM, Lamont Granquist lamont@opscode.comwrote:

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...

At a previous employer, we did just that - we built a user management
system with a data bag as the system of record. Each user's details were
in a data bag item, and Chef was responsible for managing user accounts in
as many systems and applications as we could reasonably teach it to do so.
For the few where this wasn't practical, we had an LDAP service (built on
ldapjs) which authenticated against the data bag items. On the front end,
a Rails webapp allowed managers to create accounts for new users, and
individual users to update their passwords.

It worked well, but didn't readily lend itself to an open source release.
I wonder whether other folks have built similar things and found
themselves in the same boat.

On the other hand, we discarded a similar approach for application
management in favour of a web service backed by a relational database. The
nature of data bags (no relationships, no partial updates, last writer wins
& no CAS, etc) rendered them unattractive for modelling the complexity we
had to manage in that area.

Another factor in that environment was our use of the open-source Chef
server - without data-bag level ACLs, any web-app storing data in a data
bag needs a full admin client. We could live with this for the user
management app, but it was a showstopper for other potential applications.

Zac

14

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.”

15

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 brian@akins.org 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."