Application configuration patterns - chef-boneyard/chef-summit-2014 GitHub Wiki

Application configuration patterns

Friday, Metropolitan, 1400

Convener

Nathan Smith

Participants

Summary of Discussions

Feature flag configs, and opposite end is using chef, dump into config file, databags, vault etc. What does chef do.

Fiery cookbook, has secrets, API key, put in chef vault, what dir, not in chef vault, put in node attribute, fieri Environment variable are really cross platform. Use the 12 factor approach 12factor

myapp.net maps to databags and attributes

rev cookbook and rev the binary. Cookbook with only application versions in it and put it into the manifest. Seems to work quite well. Combine chef and rundeck.

Setup using bamboo, abstract out the version release. Bamboo handles the progression through the environments, and use rundeck. Nexus handles the version.

deploy resource in chef, perceived not as good as capistrano?

Chef as source of truth. Put the version of java aartifact into the cookbook version?

Berkflow, has the pattern where the version of cookbook is in the application. Very specific pattern.
Trying to match the cookbook to the app version, becomes incredibly complex, as there may become a reason to decouple.

chef managing your vesion explicity by setting attributes. Possible to deploy artifacts from Jenkins and update the attributes on the node.

Do you pin the attribute, to the cookbook or do you do you decouple them. Both patterns are common, and mostly depends on who is actually deploying to the end point.

The source of truth. fpm, omnibus - this is covered on the hackday,Saturday

Progression of source of truth from rpms -> chef node info fpm'd into an rpm. rpm -qa was the source of truth for what's on a server. Over two years there was a shift. Many rpms were just jars. Also started loading npm packages on some nodes. Started to realize that chef knows the truth.

There is more than one way to do it, but not more than 5 ways to do it;

"application manifest" cookbook

  • a cookbook that contains attributes of all apps and their versions...this is a version-able cookbook
  • because it's a cookbook, it can be explicitly locked to an environment...declaring, explicitly, what apps/versions are run in a given environment (yay!)
  • QAs are happy cause they can test new app/versions against prod app/versions (using a new "application manifest" cookbook version with the new app/version details updated).

What will we do now? What needs to happen next?

⚠️ **GitHub.com Fallback** ⚠️