25 October 2014
From ChefConf 2012
- Documented standards and communicated best practices (wiki page, hands-on training before using it)
- Robust testing workflow
- Linting with rules derived from your standards (Foodcritic)
- Chef testing workflow…
- Standard prod dev test
- Take a real production node and remove it from the production “pool” and flip it into the test pool
- Do your testing, then flip it back to production
knife-env-diff to compare environments, helps keep dev and prod in sync
knife-spork has 4 stages…
- Check (looking at versioning info for a cookbook)
- Bump (auto increment the cookbook’s version number)
- Upload (Knife upload and freeze)
- Promote (Set environment constraints equal to the specified version)
- You can freeze a cookbook to prevent updates
- Beware automatic package upgrades!
- Be specific with your recipes so you don’t get bit by upgrades if you know you need a specific version
- Instead of using Chef to upgrade packages do an install and specify the version. Upgrade leads to way too many unknowns.
- When collecting metrics find a way to also include Chef pushes so you can see if Chef is the culprit
- Monitor Chef run times
- Create an “out of band” server in case the Chef server is down. Because it is down you can’t use Knife. They use
- Be careful with configs that are distributed with packages. They may overwrite Chef-generated configs. Make sure Chef replaces them before you bounce the service, watch the resource order
- Can you replicate your on-site Chef to Hosted Chef as a DR measure?