Follow me on Twitter Twitter_16
Subscribe to my RSS feed Rss_16
Posted about 9 years ago

Should I put configs in the package or use a configuration management tool

I stumbled across this extremely long interesting video from DevOps Days Mountain View 2011. Jordan Sissel (Loggly), Joshua Timberman (Opscode), Phil Hollenback (Yahoo Mail), and Noah Campbell (DTO Solutions) discuss how they manage configs in their deploys.

There were three options discussed:

  1. Config management tool (i.e. Chef).
  2. Creating config packages and having application package dependencies push them onto the server.
  3. Create a config service that can be used to pull down configs on package install.

There was a lot of back and forth and several points made, but the pros and cons that stuck out in my mind were:

Option Pros Cons
Config Management Tool Can easily change configs on multiple servers. (It was argued that this could be accomplished by updating and deploying a new package) Server provisioning/deploy is not complete after dpkg completes. We must wait on configs to update.
Configuration tool can get in the way when trying to make/test quick changes to configs in an emergency.
Package Configs are auditable (via dpkg) and can be easily compared/reverted to initial version A new package must be deployed just to update configs.
Config service/database Extremely simple and good for giant infrastructure (10,000+ servers). Home brewed solution.
The implementation discussed here only pulled configs on package deploy.

Some other interesting points in the video:

  • Packages should not template/install configs because the whole point of a package is to guarantee the same code goes to all environments. However, when packages are generating files in post install scripts, that can no longer be guaranteed.
  • FPM is a great tool for generating simple packages (especially configs).
  • Packages can be a valuable way to install configs for Nagios, and other application centric systems.
comments powered by Disqus