1

Following the environment cookbook pattern (specifically using an app.rb recipe for deployment), if I have an application consisting of a front-end client, a back-end API, and some services, (each different Visual Studio projects & potentially running on different nodes) should each component be a recipe in the overall environment cookbook or each have their own cookbook?

I'm thinking that each component is itself a different application and should therefore have their own environment cookbook.

Otherwise I can't picture how the environment's app.rb recipe would deploy the application considering there are multiple nodes.

Am I thinking this through correctly? How have others implemented distributed applications with Chef?

Edit: After mulling things over for a couple days, I'm backpedaling and settling on the one environment cookbook pattern:

Thought Exercise - "MyApp"

"MyApp" consists of two software components compiled separately and residing on different nodes:

  1. WebApp
  2. REST API

The current cookbook setup:

myapp environment cookbook
- recipes
  - webapp.rb
  - restapi.rb

Is this logical or should each software component be its own cookbook instead?

In the current system, a release artifact looks like (each recipe knows how to deploy its artifact):

myapp-vX.X.X artifact
- webapp.tar.gz
- restapi.tar.gz
- cookbooks.tar.gz
Current releases:
  • 1.0.0 - Initial development
  • 1.0.1 - Bug fix in webapp
  • 1.1.0 - New feature added to API and bug fixes in webapp
Current environment 
Dev        Test        Prod
1.1.0      1.1.0       1.0.1

"We need to move the webapp fixes in 1.1.0 up to prod, but we aren't done testing the new API feature." - Manager

Problem: The "MyApp" production environment requirements are different than the environment's v1.1.0 cookbook residing in dev and test.

Possible Solutions
  1. Cut a 1.0.2 release without the API feature and promote it up through the environments. Then promote 1.1.0 back to dev and test; now we're back where we started, but the bug fixes are in prod as desired.
  2. Re-architect cookbooks: make the webapp and API components be separate cookbooks.
    • Each have their own versions (API 1.0.0 could live with webapp 1.0.1 in prod)
    • They produce their own deployment artifacts like before but the artifacts are published to app-specific repos (ex. myapp-webapp) instead of the "MyApp" artifact repo.
    • The new "myapp" environment would just define the version of each application component cookbook it needs.
    • The result: API v1.0.0 would be deployed alongside webapp v1.0.1 in production.
    • Problems:
      • Even though these pieces of software are part of the same logical distributed application, their shared data are not logically grouped together. Ex: both might need to define the API endpoint in an attribute (default[:myapp][:api][:endpoint]).
      • It may be difficult to keep track of cross-compatibility. "Is version 1.0.1 of the webapp compatible with v1.2.0 of the API?"

There seem to be many ways to skin this cat, but if you can't tell, I'm liking option #1 more. I'd love to get more feedback before I decide on an answer. Does this make sense?

JoelWilson
  • 404
  • 3
  • 13

1 Answers1

0

I think you are correct. Since each is it's stand alone VS project it should be it's own application cookbook. This allows you to version control each individual cookbook and alter their individual deployments. This de-couples them all from one another allowing you to make changes to each deployment code without affecting other working code accidentally.

The environment cookbook is the cookbook that contains things that are specific of all instances of the env, for instance every node uses ruby or python and needs that installed.

An application cookbook is something specific to each application, so your thought process is correct, this should not be in the environment it should be on the application level. Note also that application configuration can be done at the environment level and trickle down, but the actual deployment it self should be an application cookbook.

Stephen Carman
  • 999
  • 7
  • 25
  • Thanks for the reply. I've been banging my head against this since I posted the question. I think the environment cookbook can be applied in this situation. Although instead of having one "app.rb" file to deploy the application, I will have a recipe for each software component of the entire "application" which can perform its own deployment. I'll post my solution once I have it figured out. – JoelWilson Dec 19 '14 at 00:42
  • @JoelWilson be carefull with multiples recipes in the same cookbook, you'll hit a parallel devellopement limit one day where you wish recipe B to go to prod but not recipe C but recipe C was in QA before B and you'll have a nightmare managing the cookbook version to prod. Any independent code should have its own cookbook to manage that. – Tensibai Dec 19 '14 at 08:46
  • @JoelWilson it's the idea of loose coupling of software components, so you have the flexibility to be able to deploy and use whatever you want without worrying about things that aren't dependencies. Putting it all in on cookbook recipe makes every component dependent on the component before it running correctly or being what you want in your environment. – Stephen Carman Dec 19 '14 at 15:56
  • @Tensibai I redefined my question with more detail and an example. What do you think? I'd love to be persuaded in the right direction, whichever that may be. – JoelWilson Dec 19 '14 at 23:50
  • @JoelWilson not that much to add to previous comment. Your #1 preferred way is valid but I just can tell it turns into a nightmare when it comes to do it in real. Chef will not solve dependencies/compability problems in your place. You don't have to use the same pattern in cookbooks than in build, so the deployment code could be on a different scheme than your build code. Managing the version of your components will anyway have to be done at some point, having separates cookbooks helps promoting them in the pipeline usually but see forecourt case :) try it and keep it or not after a while – Tensibai Dec 22 '14 at 06:57